Next message: Tony Earnshaw: "Re: add blank line to postfix log"
I'm sorry if this has been discussed before, I don't want to start any
flame wars, and I'm happy to take my lumps if people consider this a
stupid idea, but I'd like to get some feedback from seasoned
administrators who deal with much larger volumes of mail than I
typically do.
About a year ago, I was investigating ways to fight direct-to-backup-MX
spam, and was trying to determine how many levels of priority different
popular mail servers would try before giving up delivery attempts. I
spent the afternoon trying various configurations that simulated various
kinds of failures. My results were inconclusive, and I was leaning
toward disabling backup MX servers for most of my sites, anyway, so I
called it quits.
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.
At this point, I had a setup similar to greylisting, in that first
attempt contacts failed, with only RFC-compliant mailers returning to
connect to my secondary MX. Since this was really my primary, I had all
the benefits of my anti-UCE measures, without the overhead of processing
connections from the hosts that didn't return. Rejections dropped by a
staggering 70%, with no false positives. It wasn't an important domain,
however, so I left this configuration in place for a few weeks before
testing it on another domain. Subsequent tests on other domains yielded
equally postive results.
Like greylisting, it relies on the fact that many viruses or ratware are
not RFC-compliant. It also shares the weakness that it will diminish in
usefulness as malware writers adapt. Unlike greylisting, however, a
smaller burden is placed on legitimate servers, mail is not noticeably
delayed, bad hosts never connect to the MTA, and configuration is a
simple DNS tweak.
There is nothing controversial about this, it is merely a domain with an
unresponsive primary MX and an active secondary MX. But I decided to
take it one step further, and it's this point on which I would like some
feedback: It seemed unfair to make legitimate hosts wait for a response
from the primary MX with no listener, so I pointed it to a nonexistent
host without any kind of RR, returning NXDOMAIN. My feeling is that this
encourages mail servers to try the secondary immediately. It's equally
effective, and it turns out that the only false positives I've
encountered are very poorly configured mail servers or connections that
would be rejected by my other anti-UCE measures, indicating more serious
problems.
My concern is that it violates RFC 2181, 10.3. MX and NS records:
This domain name must have as its value one or more address records.
And recent discussions about other DNS changes and anti-UCE measures
could result in problems if a host returned NXDOMAIN as the primary MX,
even though it may list other perfectly valid MX hosts.
I appreciate any feedback on this subject, and hope that it might be
considered a useful option in the fight against UCE. I would especially
be interested in hearing of anyone's experiences in using this approach,
good or bad.
