[Mimedefang] DNS Lookups in MD - Was RBL and DNS lookups

[Kevin A. McGrail]

>> The first is to check for valid MX records on the sender.  I use this to
>> reject email and it works VERY well.
>
> What's your hit rate for this?  In particular, what's your hit rate for
> messages that *only* this catches?

On my main server, I blocked 1904 emails out 16584 using Invalid MX Checks

> Already tested.  For me, it only stops about 1% from getting to SA that
> wasn't being stopped through non-network tests.  That's not worth the
> code or the DNS lookup.

I block about 11.5% with this after using Sendmail's doesn't resolve block. 
We also have a lot of old domains on this server and having watched 
dictionary attacks ignore one domain and heavily attack another, this 
doesn't surprise me.  However, I can tell you that we have this routine on 
live servers with a very high effectiveness and virtually no 
false-positives.  I won't run block routines that have the potential for 
false-positives.

>> if ($sender ne '<>') {
>
> Why would you restrict it this way?  If someone is bouncing and they
> don't have a valid MX, then you never sent them mail anyway, and it's a
> spoof.  So, *anything* without a valid MX should be tossed.

For one thing, most ISPs frown heavily upon rejecting bounce messages.  It's 
a pretty easy way to end up on "name an ISPs" internal blacklist.

On the other hand, I have no idea what I would check as the From for the mx 
status.

>> The second is a reverse DNS check that I then use to score with in
>> SpamAssassin.  It has some pros and cons.  The pro is that it works very
>> well.
>
> Again, tested, and in just 14 checks that weren't already being
> stopped, it yielded 2 erroneous results.
>
> Even with just scoring that's too dangerous, as any score that did
> enough to matter would likely push something into "spam territory".

My policy on this is as follows:

This test is based on AOL's reverse pointer rules.  AOL uses this test to 
outright block email.  We use it ONLY to score email.


>> #REVERSE DNS CHECK
>>     if ($authorized_sender < 1) {
>>       $res = Net::DNS::Resolver->new;
>>
>>       $suspect_spammy_country_tlds = 1;
>>
>>         $packet = $res->send($RelayAddr);
>
> Your Net::DNS::Resolver->send is the complete waste of cycles I was
> talking about...just pass $RelayHostname into this code that checks for
> "valid" reverse DNS, because sendmail has already done the lookup for
> you.

I will concede that this is true but I use this routine in more places 
including as an initial verification step for user signups, mailing lists, 
etc.  However, the cycles lost in making a second call to DNS when I always 
run a local cache seem minimal.  If that is your main issue with the test, 
that is very easy to fix.

> Again, what are your stats on what is stopped *solely* by this check.
> In other words, how many extra bad e-mails (as a percentage) would you
> deliver if you did not have this check?

None. I use this rule only to score emails not to block them.  However, on 
one server, I marked 1636 emails as missing a ptr and 3934 as suspect out of 
14960.  So the check affected over 37% of our traffic.  Even if you can use 
it only to add/subtract even 1/2 of a point in the SA scoring algorithm, I 
believe it is worth it.

> For me, none of the reverse DNS checks stop enough extra to be worth
> wasting DNS bandwidth (even with a caching DNS server).

I don't look at individual rules.  I look at the overall ecosystem.  This 
rule MIGHT be a false positive but I have other rules that try and balance 
those out.  Plus I can use this rule + that rule + a lack of a reverse 
pointer to pinpoint an AHA!

My $0.02,
KAM