RDNS missing 8.201 -NOT A BUG

This is the official support reply;

The recommendation on this issue is to disable RDNS.  Its a  known issue, and will be resolved in a future version/patch release.  The other option is to put in exceptions for the known or Good domains.


Kind regards,

Sophos Technical Support Team - Network Security

That reply from astaro doesn't seem right. Its a known issue[:O] How were the mails that had no RDNS handled for ups and irs etc before? They weren't rejected?
Thanks for the heads up but some clarification would be great. I haven't used v8.0 for a while so don't remember if there weren't any rdns settings in it at all?

The email domains have valid RDNS entries but they are from the sending SMTP server and may not match the MX record for the domain. I don't know if that is the issue or not just that something in the update caused otherwise previously working and perfectly valid emails to simply be rejected. 

There is no way to know this is happening unless you either get a complaint or you open the Mail Manager and look for it. If you open the Mail Manager and go to the SMTP Log and uncheck all but the RDNS you will quickly get a list of rejects and you can see if you are getting any valid domains rejected. 

I have to many to start marking them as Good so I simply had to turn off the RDNS check on all my systems.

As to the Astaro reply I can only say that 1) it makes it seem like there may be some flaws in the testing methods for such a program change and 2) the clock is now ticking to see how long it takes to fix this mistake.

I consider this product to be a wonderful piece of software and renew my licenses for 3 years at a time, with support. because it works and saves me time. When I find a problem I expect it to get fixed and we will all continue to be happy. 

I posted the problem here because I didn't see any other mention of it nor anything on the Astaro site and quite frankly others should be aware of such a serious email issue and I'd expect a quick response for Astaro fixing it. Their reply said they knew it was an issue so we'll simply have to evaluate them on how they handle it.

Add me to the list, have been battling this since the weekend.  

FYI - v 8.103 was working, issues began with upgrade to 8.2 and 8.201

As Michael pointed out, this is one of those "undocumented" additions that astaro seems to be aware of. Since it has been logged with support, lets see how quickly they handle it and get it fixed.

Heck this version 8.201 drives me insane..

First... part of our network was malfunctioning becuase of the site2site VPN bug where some, but not all traffic was SNATet and not send thru the tunnel == no traffic on the tunnel.

Then after 1½ day I discover huge amounts of our mail from customers and partners is rejected because of a bug in the PTR check..

This can't go on..

Thankfully for this thread I was confirmed in my discovery and have disabled the feature for now.

Does anybody know if there is a "Known issue" list somewhere? Being aware of this PTR bug could have saved me alot of angry people.

Michael_A,

please let me add a few comments about your reverse DNS issue you observed.

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.

Can you please provide some example smtp.log lines of such rejects? If you don't want to provide it publically, please send me a private message.

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.

No, the reverse DNS check only checks whether an IP maps back to a hostname, and additionally if that hostname resolves back to the same IP address. Nothing else should be checked by this feature, e.g. the sender's MX record is not at all involved in this check.

This is all good and well but but emails from the likes of ups.com and irs.gov are getting rejected among many others.

Did you check that the sender didn't fake the sender domain? I would not wonder about spam with forged sender address making it look like is coming from ups.com. I would wonder even less if the reverse DNS check (by accident and unrelated to the sender address) correctly rejects such spam due to the sending host's DNS setup.

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.

The reverse DNS check feature was already present in ASG 7 and didn't change at all since then. So, I don't understand why our support team should have claimed that it's a known issue. Yes, it is true that we had some support cases about reverse DNS in the past days. And the support team indeed opened a development ticket for one of these support cases. But in the end it turned out (for every single support case that I am aware of) that the feature was simply working as designed, i.e. all provided examples were legitimate rejects due to an incomplete or inconsistent DNS setup at the senders side.

So, I would appreciate very much if you could provide an evidence of legitimate mail being rejected due to the RDNS check.

Regards,
mlenk

Hi mlenk,

posted you a PM with a log snippet.
In my case I discovered it on my home version when testing mail flow via my work email account.

In any case, I believe I am able to replicate and I can if needed also provide you with access to the system and a valid email account on my home network you can test send to from a valid email server.

Best regards
Poul

Hi Poul,

thanks for your private message. Indeed, the public DNS for the IP address you've sent me in the private message seems to be okay, i.e. mails from that IP address should not get rejected due to the RDNS check.

The question is, why does it fail on your ASG? Can you please do the lookup for the IP address and for the returned PTR record again on the ASG? You can do so using the DNS Lookup in the WebAdmin, available under Support -> Tools -> DNS Lookup. Do you get the same results like at work?

Regards,
mlenk

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.