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 _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/