From: Jorey Bump (no email)
Date: Mon Aug 08 2005 - 11:19:25 EDT
Covington, Chris wrote:
>>But when I looked at my mail stats the next day, I noticed something
>>interesting: During this test, the number of rejections by
>>RBLs and other anti-UCE measures dropped dramatically from
>>the norm, without any noticeable interruption from the
>>legitimate servers I used in my test. I thought it might be a
>>fluke, so I decided to test it again, setting my first
>>priority MX to another public IP that has nothing listening
>>on port 25, and the secondary MX pointed to my regular mail server.
>
>
> I think it's an interesting idea but to work as effectively as
> greylisting you would also need a non-responding tertiary MX because a
> lot of ratware likes to deliver to the backup MXes to avoid the commonly
> lower UCE restrictions compared to the primary. Or maybe the ratware
> only delivers to the 2nd MX, not the lowest priority one, etc.
This is a builtin advantage of this approach. Remember, this is the
original problem I was trying to solve. Direct-to-secondary-MX ratware
applications seem to be interested only in the existence of a backup MX,
which is provided in the DNS lookup. I considered your idea about
nonresponding tertiaries, but that could break things with legitimate
mailers if your *real* (specified as secondary) MX went down. :)
> It would
> be interesting to see the statistics.
Yes, I've been lax in this area. One of the challenges, however, is that
it requires continuous monitoring of DNS connections. It's impossible to
derive meaningful statistics from these in a limited time window, due to
DNS caching (not only by popular resolvers, but also the permanent type
builtin to some malware). You would also need to monitor all of the
authoritative nameservers for a domain.
In any case, watching these with tethereal or tcpdump is interesting,
and all of the popular MTAs I've tested perform the query on the
secondary MX after receiving the primary as NXDOMAIN.
> I also think NXDOMAIN would cause
> mail from your domain to be rejected by zealous MXes.
I'm watching for this in the logs since implementing sender
verification, and haven't seen any, yet. You're right that it could
cause a problem. It seems a little overzealous to reject on this
criteria, unless there is *no* valid MX listing for the domain. It's not
a definite flag like listing 127.0.0.1 as an MX.
|
|
|