check_dynamic_reverse_dns

[andi]

hi all...

i love magicSpam.com.. but not all of our clients like it allready, too.
most claims, we get concerning rule 'check_dynamic_reverse_dns', however i think, this rule should be enabled because this is very effective.

but there are quite a lot of rejected senders with reverse dns as follows:

# host 217.5.214.110
110.214.5.217.in-addr.arpa is an alias for 110.0.214.5.217.in-addr.arpa.
110.0.214.5.217.in-addr.arpa domain name pointer tcmail53.telekom.de.

# host 212.25.14.40
40.14.25.212.in-addr.arpa is an alias for 40.32-63.14.25.212.in-addr.arpa.
40.32-63.14.25.212.in-addr.arpa domain name pointer quarantine.spamchek.net.

as it looks like, there are several IP-provider setting-up rDNS as above.

what do you suggest?

regards,
andi

[magicspam]

Hello Andi,

Thank you for your post.

We openly admit that this is a bit of a new condition for us. More to the point, the act of an ISP offering CNAME record allocation only as the means for creating rDNS falls marginally within the definitions of an approach known as FCrDNS (forward-confirmed dns) but does not fall within the SMTP Best Practices standards. Now.. this stated, the SMTP best practices standards is primarily driven within the North America market so we are of course open to investigating this further.

This has been brought to the attention of our developers, however, we should point out that the act of supporting this style of rDNS is *highly* likely to affect performance on a cumulative level. Reviewing the logic required to support this type of lookup:

Current Method:

1 DNS query sent for PTR record type

FCrDNS approach:

1 DNS query sent for PTR record type
1 DNS query sent for A record type

and.. add the CNAME capability if no A record found...

1 DNS query sent for CNAME record type

so in order to support this we then look at upwards levels of 3 times the DNS lookups for each email received.

We will let you know what our developers say about this but in the meantime, do the people who have complained about this mentioned to you who their upstream provider is? Have they contacted them and requested a proper FQDN PTR record?

[andi]

hi,
thank you for reply.

i see the point with affecting performance, but there are quite a lot of mailservers aroung europe (mostly german servers) using improper rDNS or PTR-records as alias. but there are also servers from outside europe.

for sure, we recommit all to http://www.linuxmagic.com/best_practice ... e_dns.html, but appreciation seems to be quite small.. as it looks like, not many mailserverprovider perform such dynamic rDNS-checks and due to this fact, they believe, that it would be our fault to block thier (urgend und important) mails...

if have two more examples, just claimed by customers this afternoon:

# host 70.238.46.251
251.46.238.70.in-addr.arpa is an alias for 251.128.46.238.70.in-addr.arpa.
251.128.46.238.70.in-addr.arpa domain name pointer mis-usmail2.incat.com.

this 1st example is from sender of '@tatatechnologies.com (http://www.tatatechnologies.com/global/), not very easy to tell them, that THEY are wrong.. and if they will check PTR at some online tool like eg. http://www.emailtalk.org/PTR.aspx, everything looks fine for them..

and, 2nd example:

# host 212.25.14.40
> 40.14.25.212.in-addr.arpa is an alias for
> 40.32-63.14.25.212.in-addr.arpa. 40.32-63.14.25.212.in-addr.arpa
> domain name pointer quarantine.spamchek.net.

this 2nd one points me to http://www.faqs.org/rfcs/rfc2317.html and said, that for classless reverse subdelegation there would not be any other possibility for PTR?! - this one did allready open a topic at http://www.gossamer-threads.com/lists/s ... ers/157741

well,
to calm the situation for now, i just disabled 'check_dynmaic_reverse_dns' on our mailservers

[magicspam]

Thank you for the detailed information.

One other temporary work around you could implement in the interim would be to add entries for those ISP's in question that are unwilling to fix things, or don't have the ability to implement direct PTR records into your /etc/hosts file. Provided your /etc/nsswitch.conf file is in the format 'hosts: files dns' then this will bypass the records in question.