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)."
"Greylisting" is where an SMTP server refuses messages for a certain amount of time. You set the criteria on why the message would be refused and how long the server would refuse to accept it.
It's been pretty much defeated now because so many spammers have their machines try to hammer the message through until it does go through.
I'm using greylisting right now and the only advantage is that many times a spammer will end up on an RBL during the 15 minutes that I'm refusing his messages.
Remember, the spammers have, effectively, unlimted bandwidth and unlimited processing power at their disposal.
This probably works in many cases, but as a mail system admin I can tell you that it can fail and will cause problems for legitimate mail delivery. Over the past few months I remember seeing a few messages stuck in my Postfix mail queue, that didn't ever seem to make it out to the recipient's MX. These were domains with deliberately non-functioning MX, and I could not figure out why Postfix was not trying the other MX even though it was up and running. In one case I also tried mailing the recipient domain through gmail, which ALSO failed after many days of retrying. Again I am not sure why the scheme failed to work, but it did fail through both Postfix and gmail which are two very legitimate mail servers.
If you'd bothered to RTFA (which I did a month or so ago) you would notice that the secondary server will only accept mail which was first rejected by the primary.
This means that servers *must* be RFC-compliant to deliver mail to a no-listed server - they must try to deliver to servers in the published order, and must try at least two.
The big advantage with no-listing is that if the sending server immediately tries the secondary after the primary fails, here is almost no delivery delay.
The big disadvantage of course is that an RFC-compliant spammer gets almost no delay either.
I run a fairly low-key server, which I only use for my family, so I am not sure how relevant my data is.
I remember at one point last year checking on the usage my backup MX gets and was surprised to see a lot of mail coming through it. Surprised because my primary server is (almost) always available. Upon a closer inspection I was astounded by what I found: all the email that came through the backup MX was spam for the past year was spam. No exceptions!
Certainly, mine is an extreme case, but I think the trend is very clear.
...and encourage readers to RTFA, where I've addressed many of the issues brought up in these comments. I also encourage people to try the technique, if they are in the position to do so (admins only, this is not a solution for endusers), and evaluate it for themselves. Or not. It's true that most new antispam solutions are dreamed up by crackpots. I might be a crackpot. If this possibility concerns you, don't be an early adopter. Wait and see.
It's true, in my experience, that Nolisting stops some spam with no false positives (in my experience). And that's a Good Thing. But it doesn't stop significantly more spam than a combination of other techniques, which I also implement. Some of those techniques use a lot of resources, such as content filters (often powered by perl) and virus scanners. Nolisting provides a way to free up some of those resources, possibly resulting in better performance and even hardware savings. These savings can be significant at large sites that currently scan each and every message that arrives.
Nolisting can be bypassed. I don't make any wild claims. Spammers can get past it easily by going directly to the secondary MX. Guess what? They already do that, and have been doing that well before greylisting was introduced. Nolisting significantly reduces the percentage of spam my MX processes, thereby freeing up resources. It's just one part of a layered solution.
I've limited secondary MX access by extending Nolisting into Unlisting (Port Knocking for SMTP): http://www.joreybump.com/code/howto/unlisting.html . It's wildly effective, except for one serious problem: A retry might originate from a different IP. This appears to be legal, and seems to be the result of load balancing strategies adopted by some important sites. For that reason I don't recommend it. It will randomly block messages from gmail, for example. You can't reasonably predict the IP a multihomed host will use for a retry, so be very skeptical of any approach that claims to have solved this problem.
Unwanted email is annoying. When it carries a payload, it is potentially dangerous. But I don't really view this as a security issue. I don't buy the argument that Nolisting is security by obscurity, and therefore bad. It's a form of access control, a gatekeeper, a prophylactic. It's an apple a day, not a cure for cancer. It's not addicting, fattening, or life-threatening. Try it, if you're looking for ways to improve the health of your mail system. Discontinue use immediately at the first sign of complications. Side effects include more sleep and time spent with your kids.
Nolisting rarely introduces delays. As I point out in the article, most relays retry immediately. Any relay that cannot get beyond Nolisting is seriously, seriously noncompliant. While I don't suggest Nolisting as a complete replacement for Greylisting, it is a viable alternative for sites that experience problems with Greylisting and find the delays it introduces to be unacceptable. As the name implies, Nolisting is meant to used without dependence on whitelists. Wider adoption and testing will determine if this ideal has been realized.
Like Greylisting, Nolisting breaks infrastructure to some degree. Many admins find this distasteful. I know I do. If Nolisting becomes widely adopted, logs will become fatter with "Connection refused" errors when the primary MX doesn't respond. I'm sorry for that. But our logs are already fat with 45x errors from Greylisting, RBL disconnections, SpamAssassin scores, etc. Nolisting might even help to make logs smaller, if you currently see a lot of these messages. Time will tell. Keep an open mind, and remember that we often make concessions to improve a system's overall health. Just reducing the possibility of another zombie being created on the Internet creates benefits for everyone.
Try it before you draw a c