RDNS missing 8.201 -NOT A BUG

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

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