Spam and extra MX records

[Mark E. Mallett]

On Tue, Apr 15, 2008 at 09:44:35AM -0400, Neil Joseph Schelly wrote:
> 1 - Set a fake MX record for a nonexistent server, or for a server that won't 
> listen on port 25 for your _highest_ MX value.  Since a lot of spam will skip 
> your lowest MX (primary) right away for a less-loaded backup MX with 
> potentially less reliable spam filtering in place, the assumption is that a 
> lot more spam will make it through a backup MX.  I've already confirmed that 
> that does happen a lot.  The theory here is that by setting a non-operational 
> backup MX record, spam bots will try and then give up on sending spam your 
> way.  Real mail should never try the fake MX record unless all your real mail 
> servers are down, in which case, you've got other issues to worry about.

Still, somebody can try a backup MX for a variety of reasons you might
not predict: like an accept queue temporarily full on the primary, a
transient routing glitch, and so forth.  There are so many, um,
interesting mail programs out there and you can't tell what some of them
will do when they think they have fallen all the way to your backup MX
and then gotten rejected by an RST (as opposed to timing out).  I've
sometimes set things up such that the backup MX always gives a 4xx,
which does not seem as fraught with error (although no backup at all is
probably better these days).


> 2 - Set a fake MX record for a nonexistent server, or for a server that won't 
> listen on port 25 for your _lowest_ MX value.  Essentially, this would make 
> it look like your primary mail server is always down and every incoming 
> message would have to get retried to your first "backup" MX. Again, the 
> assumption is that spam bots will give up after failing to send to the first 
> MX they try, whereas real email will try your next higher MX record in 
> priority until it completes a delivery.

I wouldn't do it to a nonexistent server; you'll just cause timeout
delays for all your legit senders, and they won't like it.  The other
one -- pointing to something that will instantly refuse the connection --
even has a name: "nolisting", see http://nolisting.org/ .  Some
folks say it works pretty well -- for now.  It also increases the work
for the sender, but only slightly.  But it seems to me that with it you
lose some ability to profile the senders, and that you can work out
other ways to throttle those senders (at the expense of some
horsepower).  I've set it up for a couple of cases when getting massive
blowback for a particular domain (as a couple of ours are right now, for
example); i.e. an extreme reaction to an extreme situation.

mm