Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 1 subscriber
  • Views 13666 views
  • Users 0 members are here
Options
Suggested
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

RDNS missing 8.201 -NOT A BUG

Michael_A
Since applying the 8.103, 8.200 and 8.201 (I did them all together) updates there is now a problem with RDNS checks. I have reported this to support who has not provided a solution yet and have had to simply disable this check.

A user sending an email with this problem will get the error RDNS missing and the Mail Manager will report the same in the SMTP Log.

The problem seems to occur when a senders email comes from an IP where the RDNS for that IP does not match the sender's MX record. This is all good and well but but emails from the likes of ups.com and irs.gov are getting rejected among many others. On the first complaint it seemed like the issue had to be with the sender since other emails were getting through but after 2 days and examination of 5 updated systems it appears we have been given a new 'feature' with the only remedy for now being to disable RDNS checks.


This thread was automatically locked due to age.
Parents
  • 0
    Sure..

    As a sysadmin I have most of a small hosting enviroment at home - including an ASG.

    This ASG connect to my company with a SSL site2site VPN tunnel where some nutcse 10 years ago configured the internal domain ( .com ) to be the same as the external domain, insted of using .local or the like inside.
    This basically means I have to route my dns request for the company domain to the internal DNS servers at the company.

    So for the company DNS request it looks like this if I ask for a company server or the like :

    home pc -> home ASG -> site2site SSL -> company ASG - company DNS server

    If I ask for anything else.. :

    home pc - > home ASG -> ISP DNS

    Now the fun part is that I ( like many other sysadmins ) have my own mailserver at home and I realized that when someone writes me a mail from the company the PTR in my home ASG will try to resolve the RDNS for the company mailserver - which would be fine it the check was done against ISP DNS or public DNS like google DNS.
    In this rare case however the domain name matches the internal company domain and the RDNS request is routet to the internal DNS server of the company which replies with the LAN IP of the server.

    This will result in a failed PTR / RDNS check since the ASG is fully aware of the public IP of the mailserver and it fully aware of the hostname of the mailserver ( the public one ) - but fails because it gets the internal IP becuase of this DNS route that I really only want my home client PC's to follow.

    I Hope that makes sense.. its a minor problem though.
Reply
  • 0
    Sure..

    As a sysadmin I have most of a small hosting enviroment at home - including an ASG.

    This ASG connect to my company with a SSL site2site VPN tunnel where some nutcse 10 years ago configured the internal domain ( .com ) to be the same as the external domain, insted of using .local or the like inside.
    This basically means I have to route my dns request for the company domain to the internal DNS servers at the company.

    So for the company DNS request it looks like this if I ask for a company server or the like :

    home pc -> home ASG -> site2site SSL -> company ASG - company DNS server

    If I ask for anything else.. :

    home pc - > home ASG -> ISP DNS

    Now the fun part is that I ( like many other sysadmins ) have my own mailserver at home and I realized that when someone writes me a mail from the company the PTR in my home ASG will try to resolve the RDNS for the company mailserver - which would be fine it the check was done against ISP DNS or public DNS like google DNS.
    In this rare case however the domain name matches the internal company domain and the RDNS request is routet to the internal DNS server of the company which replies with the LAN IP of the server.

    This will result in a failed PTR / RDNS check since the ASG is fully aware of the public IP of the mailserver and it fully aware of the hostname of the mailserver ( the public one ) - but fails because it gets the internal IP becuase of this DNS route that I really only want my home client PC's to follow.

    I Hope that makes sense.. its a minor problem though.
Children
  • 0 in reply to Vels
    Now the fun part is that I ( like many other sysadmins ) have my own mailserver at home and I realized that when someone writes me a mail from the company the PTR in my home ASG will try to resolve the RDNS for the company mailserver - which would be fine it the check was done against ISP DNS or public DNS like google DNS.
    In this rare case however the domain name matches the internal company domain and the RDNS request is routed to the internal DNS server of the company which replies with the LAN IP of the server.


    In this particular case you should properly configure your home ASG to treat the company mailserver (i.e. the IP address that is seen in the smtp.log for mails sent by your company mailserver) as a trusted upstream host by adding it to the Mail Security -> SMTP -> Relaying -> Upstream host list. This will cause the RDNS checks to be skipped for your company mailserver. Also other AntiSpam features such as greylisting will benefit from knowing the upstream hosts of your setup.

    Rationale: Doing reverse DNS checks or greylisting for your known company mail server doesn't make any sense, because you know that they are administered properly, so they will never send you any junk mail. And in the unlikely case they do send you junk, you know who to beat for it... [;)]

    Regards,
    mlenk
Cookie Information Banner