[Mimedefang] OT - Using rDNS sendmail hack - your experiences

[James Ebright]

Hello all, this is a bit off topic but relevant.

We finally decided it was probably time to implement AOL style reverse DNS
checks into our MTA. Since AOL has been doing it now for something like 6
months it is a pretty fair bet that most US customers that are legit have
corrected their DNS issues... or so we thought!

Why reinvent the wheel... we implemented a slightly modified version of this
sendmail m4 HACK here: http://www.cs.niu.edu/~rickert/cf/hack/require_rdns.m4

Which basically does this: 

1. Check relay for rDNS then check the response (gethostbyaddr check)
2. If there is not PTR record FAIL
3. If you cannot find DNS record for it at all, maybe DNS is down, TEMPFAIL
4. If there is rDNS (PTR) but it appears forged (different than forward or
result doesnt resolve), TEMPFAIL

Now we have been using the delay_checks feature for some time and you can add
some options to this HACK if you do delay_checks, we made our default entry
REJECT but frankly... we plan on putting any user level entrys to our access
file in with an explicit REJECT or OK as it just makes the file much easier to
read and understand.

We placed it after the delay checks feature (as Niel suggests) and above the
dnsbl entries in the mc file. Now I know the order really should not matter
much in the mc file but it does seem to run before dnsbl checks do.. and cuts
that load/traffic down considerably.

Implementing this actually has cut the load on this server (my test one before
I implement everywhere) in half! Not to mention the bandwidth savings which
should be apparrent after a few days trending (since it is catching it earlier
and avoiding even dnsbl checks in many cases, much less SA and most of MD checks.

Anyway, So far I have only identified one domain I have had to whitelist
(local mom-and-pop ISP) that was tempfailing due to a bad DNS setup, we have
notified them and hopefully they will correct their DNS soon, I asked if they
had customers that coudl not send to AOL... hehe, the answer was yes... we
have alot of problems with AOL!

So, my question is... I have been monitoring for about 6 hours now, will
probably let it go another day before pushing this change out to my other
servers... in the mean time.. any caveats from the peanut gallery? Any
horror/war stories on a similar implementation?

Jim
--
EsisNet.com Webmail Client