Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 1 subscriber
  • Views 13654 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
    Nicely spottet...

    Well I need to study more logs, perhaps the ones at work actually was caused by some of the customers not being on top of their DNS.

    In the case of my home firewall, it has a site2site connection to my work and the mail DNS resolver used the DNS request routing to my company network domain, which results in the internal LAN Ip to be returned for the company mailserver.

    This can be argued as being right or wrong, but it is unfortunate that the mail DNS resolver follows the internal DNS request routes insted of just using the assigned ( ISP assigned ) DNS servers. 
    I can't really think of any case where it would make sense for the mail dns resolver to follow a route over a site2site VPN to an internal domain dns server.

    In either case, this behavioure was not present pre 8.2, where I had PTR enabled on my home wall and could send mail from my company mail account to my private mailserver at home.

    I dont know if the above mentioned issues are simular.

    I will however spend some time going thru the logs on the company firewalls and see if it behaves correctly, which I actually (in this light if this ) suspect they do.
Reply
  • 0
    Nicely spottet...

    Well I need to study more logs, perhaps the ones at work actually was caused by some of the customers not being on top of their DNS.

    In the case of my home firewall, it has a site2site connection to my work and the mail DNS resolver used the DNS request routing to my company network domain, which results in the internal LAN Ip to be returned for the company mailserver.

    This can be argued as being right or wrong, but it is unfortunate that the mail DNS resolver follows the internal DNS request routes insted of just using the assigned ( ISP assigned ) DNS servers. 
    I can't really think of any case where it would make sense for the mail dns resolver to follow a route over a site2site VPN to an internal domain dns server.

    In either case, this behavioure was not present pre 8.2, where I had PTR enabled on my home wall and could send mail from my company mail account to my private mailserver at home.

    I dont know if the above mentioned issues are simular.

    I will however spend some time going thru the logs on the company firewalls and see if it behaves correctly, which I actually (in this light if this ) suspect they do.
Children
No Data
Cookie Information Banner