Slashdot Mirror
Fight Spam With Nolisting
An anonymous reader writes with the technique of Nolisting, which fights spam by specifying a primary MX that is always unavailable. The page is an extensive FAQ and how-to guide that addressed the objections I immediately came up with. From the article: "It has been observed that when a domain has both a primary (high priority, low number) and a secondary (low priority, high number) MX record configured in DNS, overall SMTP connections will decrease when the primary MX is unavailable. This decrease is unexpected because RFC 2821 (Simple Mail Transfer Protocol) specifies that a client MUST try and retry each MX address in order, and SHOULD try at least two addresses. It turns out that nearly all violators of this specification exist for the purpose of sending spam or viruses. Nolisting takes advantage of this behavior by configuring a domain's primary MX record to use an IP address that does not have an active service listening on SMTP port 25. RFC-compliant clients will retry delivery to the secondary MX, which is configured to serve the role normally performed by the primary MX)."
in response to:
> (x) It will stop spam for two weeks and then we'll be stuck with it
There is another anti spam technology called (doubleverify?), if a message smells like spam the smtp server rejects it saying unavailable and waits for the sender to send it again (an hour or so later). For people who use it it works fine, but people who use it are in the minority, thus spammers won't bother writing new systems that keep track of what was rejected etc. They appeal to the (cheap) masses.
Same here, unless this becomes widely popular few spammers will adopt it. Thus there's a chance for this to work (hopefully, unlike doubleverify this is not patented)
Nature journal lied in Britannica vs Wikipedia Ask to retrac
It amuses be a bit. I have the ultimate in no listing for one of my domains. =-)
I used to received about 6 million spams a day across 3 relays for this domain.
I removed all MX records for the domain, and the hostnames have nothing to do with the domain (so A record lookups won't help), but 30 days later I still was receiving over 2 million spams a day. After about 6 months the number really started falling off.
I run a mail system that pushes ~3million messages per day. Not huge, not small.
We have thousands of domains pointed to our mail servers and secondary MX servers. Looking at the long run stats, I'd be tempted to completely disregard this technique.
When we take a primary down for maintenance, the secondaries and alternate primaries (same weight MX) see the load almost immediately.
I second the opinion that if this has any effect, it's only for low volume applications, with few/one domain.
We generally see more hits straight to the secondaries by spammers hoping for less rigorous checking. It would be interesting to profile IPs connecting to secondaries without being seen at the primary assuming a primary is always available - I bet that a very high percentage of these connections to secondaries could be viewed as spam.
The problem remains that most tricks of this sort - including greylisting - are eventually circumvented by spammers once the trick gains critical mass. Lets not forget that there are a lot of broken, yet not open relay, mail servers out there. Good engineers and administrators quickly find that Jon Postel's words ring true with their customers "Be liberal in what you accept, and conservative in what you send." - don't let your RFC enforcing configuration be responsible for delaying/blocking the delivery of that big contract your PHB was waiting for!
But they're often slow to respond. Hell, I changed a DNS record when I moved servers once and spammers will still going after the other server, with no DNS record pointing to it, for 6 months because they use static caches.
Many people were already using this trick, probably hoping it wouldn't show up as lead story on slashdot.
In some ways, selfish ways, it's like the story of the two hikers who face a bear. The first hiker immediately sits down and starts putting on his running shoes. The other says, "What are you doing? You can't outrun the bear!" The first hiker says, "I don't have to outrun the bear. I just have to outrun you."
Many spammers, faced with a failed attempt at sending mail, do not bother to retry or try other MX. Instead, they just move on to the next target in the list, since trying a new target is just as easy as retrying an old target. No real difference to them. But it means you just push your spam attempts onto other people who haven't elected to bend the standards to divert the spammers.
The "good" spam sending programs run many threads, timeouts don't punish them, their limit is more the bandwidth. Attempts to divert spammers onto others who have not tried the tricks should create an ethical question. Are we just arranging for the bear to eat our friend?
Has it been over a year since you last donated to the Electronic Frontier Foundation
Just an aside on greylisting: I run a large mail server and we WERE using greylisting. However we have found that many firewalls and anti-spam appliances that act as email proxies cannot respond to the 451 or 421 "try again" response used by greylisting. The appliances bounce the message back to the sender reporting it as a server failure. Unfortunately, this user group includes an ever growing number of goverment agencies and public schools. My best guess is that these appliances have no way to store the message should the first attempt at delivery fail.
:-(
I sincerely doubt that most of them would ever try more than the primary MX when delivering mail either.
Non-complience with the standards by email handling programs just makes it easier for the spammers by taking away a postmasters anti-spam tools
Flowchart:
Check out my sci-fi/humor trilogy at PatriotsBooks.
I was reading the article, and suddenly port knocking came to mind. It wouldn't be a far stretch to modify an SMTP server to only reject connections on the lower priority IP address if the source had not tried to first connect to the higher priority IP address.
Instead of blocking the connection to the primary at a firewall or using an "unused" IP address, the primary SMTP server could give a greeting banner and then immediately return a "temporarily unavailable" status code (and cache who was connecting there).
In other words, an RFC compliant MTA should be connecting to the higher priority host as defined by DNS first, then fail over to the lower priorty host, in order. If an MTA tried to connect directly to the secondary MX first it could be rejected with a temporary failure status code which a spammer is likely to ignore. It would require the SMTP receiver to keep a cache of who had connected to what IP addresses within a certain time period which would eat up some memory depending on traffic load. We already cache reverse DNS lookups and RBL lookups, so it could probably be done.
With this setup you would have two MX records for your primary mail server that your SMTP server would be active and listen on. It would just track the order of connections to ensure that the remote MTA was following the rules before it allowed the source to get past the greeting banner.
From the link...
--snip log example--
This spammer got stuck for 47 minutes. Current spamd sets its socket receive buffer size to one character, forcing the sender to send one TCP packet for each byte of data, even if its a non-compliant "dump and disconnect" mailer. Of course, the spammer nearly immediately tries to retransmit the spam. Repeatedly.
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
First, at least some botnets will hit secondary MX-es first. The reason for this is because one person too many out there think that the secondary MX gets invoked only when the first one fails and do not put full sets of antispam software on it.
Second, as far as detecting SPAM is concerned the fact that a system has tried your first MX is valuable information. So while the first MX may not accept the message it should still be available to record the attempt. As a result, if you have multiple level different priority MX-es you can vastly improve on standard greylisting. The first MX resets with the usual "greylisted for 300 seconds, come again". After that system expects that you appear on the second, third, etc in the correct order and try on all MX-es of equal value before going up. In other words your connection pattern should follow the one of a normal MTA. Zombie writers are too lazy to do that (and that takes too much resources as far as they are concerned) so they fail the test and get their greylist timeout pushed up. Normal MTAs get their greylist timeout adjusted down and may even be allowed in on one of the last MX-es. I have done that using exim/mysql and I know a few other people who do that as well (trivial actually). In fact, looking at my mail logs it looks like yahoo does something similar for receiving mail and I can bet that they are not the only ones.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I use qconfirm myself but there's also tmda and others.
*If* you are serious about getting rid of the spam then just do it. The technical part is readily available.
I deployed that almost a year ago and never looked back. I still see the occassional spam in a
mailing list folder because those go through unfiltered for obvious reasons but I couldn't care less.
My inbox has been spam-free since then and that's what matters.
I don't quite get why people are still bothering with greylisting, spamassassin, razor, dcc, bayes and
the ilk. I tried them all and they're more trouble than it's worth. You get false positives, false negatives,
it's a stupid game that you can't win.