Spam and extra MX records

Neil Joseph Schelly neil at jenandneil.com
Fri Apr 18 09:38:06 EDT 2008


Thanks for everyone's responses here.  I wanted to reply with some responses 
after having a chance to review everyone's ideas.

> I was told by a few people to use a proper blacklist
I'm not sure how this was related - I wasn't asking about blacklists and I 
never meant to suggest that this would be a lone spam-blocking measure.  
Blacklists are part of the calculation, for sure.

Ben Scott said:
> These may or may not work right now.  I suspect they'll foil some
> spam attempts right now.
> <snip>
> Mostly, though, I'm against these kinds of things because they are a
> doomed strategy.  If enough people start doing it, the spammers *will*
> adapt. 
That was the goal, yes.  Any particular spam prevention technique is at best a 
temporary measure.  Spam and viruses filtering is and always will be a moving 
target unfortunately, so techniques that work now are all that you can ever 
really implement.

One thing that makes this false MX idea rather interesting in terms of 
effectiveness longevity though is that it increases the costs of the spammers 
somewhat.  Spam is motivated by tremendously low cost of distribution and 
high message counts.  They do depend on the ability to send as many messages 
as possible as quickly as possible.  This technique could slow them down a 
lot, at a minimal cost to legitimate senders, though I do recognize that the 
legitimate senders may be further inconvenienced if this idea becomes 
popular.

Brian Chabot said:
> I once added an high numbered MX entry in a few domains which pointed to
> localhost.
> While it really did reduce the incoming spam, I recall someone getting a
> bit irate about spooling my mail on a GNHLUG server till my server was
> back up... <G>
My intention was not to do a false MX record until I had redundant MX hosts to 
accept incoming mail to begin with.  But since the RFCs only really require 
you to check a second MX and not go through all possible MXs to deliver a 
message, this false MX idea can cause problems with some hosts finding your 
backup MX, if it becomes necessary.  The real MX may already be the second 
try if you have a false MX.

> I've heard a 5 second connection delay helps, too. (Whatever the SMTP
> "wait" response is...)
I've heard that as well, but generally, I find that a reverse DNS check offers 
enough of a delay to confuse a lot of incoming spam hosts.  It's really _any_ 
amount of delay that traps those guys.  I use Exim and it by default rejects 
SMTP synchronization issues, where a sender sends in the EHLO information 
before the server sends its banner.  Any spam bot that doesn't follow proper 
send/response protocol won't get through.

Mark Mallett said:
> even has a name: "nolisting", see http://nolisting.org/ .
I hadn't known there was a name or a site. Thanks for that.

Anyway, I've decided to forgo this experiment.  I was having trouble getting 
SpamAssassin to use Bayesian filtering and not self-destruct at the traffic 
load it put through the BDB, then the MyISAM, then the InnoDB tables.  I 
noticed without it that I was still getting some through and I was looking 
for something to fill the gap.  I've resolved the performance problems with a 
really cool dual-db setup I came up with that's giving me awesome 
performance.

Especially when Bayesian filtering is involved, the motivation to prevent spam 
from hitting my spam filter is gone, because the Bayesian filtering will 
learn from it.  So the false MX records may prevent some spam from coming in, 
but with good Bayesian filtering again, I'd also be at a loss.

I would say a new first-priority MX records seems like a bad idea, since it 
could very well interfere with ever having a backup MX at all.  But a false 
second MX when you have only one MX server yourself could probably work as a 
good stop-gap in the meantime.  And to prevent Ben from getting mad at you if 
you do that, make it point to something that isn't localhost. ;-)
-N


More information about the gnhlug-discuss mailing list