This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[8.201] RDNS missing

I saw the other thread but it is locked currently.

I have been noticing a large increase of 'RDNS missing' entries in the Mail Log.

Typically a user sends me a message that they have not been getting mail (often the client sends it from a gmail or such to inform them).  Verify the log and see the RDNS entries.  Pop over to MXToolbox and run their checks and see it labeled as OK on the RDNS check.

So I am at a loss as to why it is occurring.

For example: seagullscientific.invisionzone.com - this is a support forum for label software, it got a RDNS missing despite it appears to be all correct (unless i'm missing something).  Astaro logged it as coming from 208.67.212.34


This thread was automatically locked due to age.
  • maybe I'm not correct with this guys but this problem is anywhere because of ISP's who maintain the record of the Ip 
    The RDNS problem is not your ASG fault, but the ISP fault. I leave this feature unchecked since i have reuputation ip "on" (Greylisting) 
    I didn't find any spam email from 7 months
  • oldeda,

    The issue is that there are two different things - rDNS and FCrDNS - that Astaro is now treating as one setting.  The RFC for rDNS technically states that a mail server must have a PTR giving the IP address a hostname, and that there must be a matching A record that gives the hostname the same IP address.  The RFC does not state that the HELO/banner from a mail server must match that same hostname, only that the PTR and A records for a given IP address must exist.  So there are many mail servers that are set up absolutely correctly when referencing the RFC that do not pass Astaro's rDNS tests.

    I've been involved with Novell GroupWise, for example, since back when it was a WordPerfect product.  GroupWise many many years ago ALSO had this misuse of the rDNS rule, and we had to lobby Novell to change it (which they did a number of years ago, and like Astaro made it a choice).  I have no problem with Astaro giving us more ways to block spam, but it needs to be done according to the RFC.  One could argue til the cows come home whether the RFC is just unduly vague, and really originally meant it should be treated as FCrDNS, but obviously since there is actually a name for FCrDNS it's been decided that rDNS and FCrDNS truly are not the same, and should not be treated the same!

    Danita
  • OK, here is the command to change the behavior of the 8.202 SMTP Proxy back to the old way of checking rDNS.  This changes the exim.conf file, so it should survive a reboot as well as a configuration restore.
    This is what Astaro Support did for one of my customers.  I plan on doing it for my own Mail Security customers right after they upgrade.
    Remember, doing anything at the command line can void support, so, if you have any hesitation and you have an Astaro Support contract, open a ticket and ask them for help.
    That's my CYA, and you take your own risks! [:)]

    Here's the one-line command to do from root:

    sed -i '404s/\$host_lookup_failed/${lookup dnsdb{ptr=$sender_host_address}{0}{1}}/' /var/chroot-smtp/etc/exim.conf

    Then you must restart the SMTP Proxy:

    /var/mdw/scripts/smtp restart

    Again, do this at your own risk.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • You are a wonderful person Bob!

    I made the change, turned rDNS back on, and am blocking at least one a minute now (update - make that over 5 a minute).  And thus far, every entry I've checked is "correctly" being blocked as not having a PTR.  I have seen none blocked that do have PTRs, so it looks to be working!

    Thanks for sharing.

    Danita
  • Hmm, then i wonder why the mxtoolbox rdns check passes. That is typically what I use to verify settings.

    Though now I see what you mean. Hmmm...