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)."
For some time a few years ago, spammers used to IGNORE the primary MX and send to secondary MXs preferentially.
Since in our case, the 2ndary MX was a dumb sendmail relay only without knowledge of the user DB, it shot the traffic load out thru the roof with bounces to junk spam that, because they couldn't be rejected during the actual delivery attempt, hammered our backup relay.
This is just a dumb idea.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
"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.
You must be the fastest typist in the known universe...
Whiney Mac Fanboy is a subscriber. They (subscribers) get to see the articles before us mortals. First post isn't hard when you can reply to the article before the article is available to the unwashed masses.
he has results that dispute it. If he does, he didn't post them to his page.
If you take a look at his page, he says that he used DNSBL.
DNSBL host != spam-bot
Spam-bots are a subset of the hosts that would be listed in a DNSBL.
Next time, before attacking someone, you might want to work on your reading comprehension skills. You'll look like much less of a fool.
It sounds like a function called MailHurdle that's built into Mirapoint email filters.
It works wonderfully. We've been using for about a year at my organization. It works by initially rejecting all incoming mail from unknown servers. If the server is legit, it will retry the email, and on that retry, MailHurdle will allow the mail through.
It instantly eliminated well over half of our incoming spam. Very clever technique, and it certainly works.
The kept the IPs handy, not even bothering to check DNS.
I handled other domains on the same servers, so I'd still see the requests come in
I think this article has it backwards. Spammers often times will go after your secondary MX records instead of your primary. This strategy = waste of time.
Evolution: love it or leave it
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.
Sorry - you're right. What I was thinking of was *unlisting* which is linked to right near the bottom of that same page (and reproduced here for convenience):
l
http://www.joreybump.com/code/howto/unlisting.htm
Except it wasn't filled in consistently.
These are incorrectly checked:
(X) Many email users cannot afford to lose business or alienate potential employers
(x) Dishonesty on the part of spammers themselves
(x) It will stop spam for two weeks and then we'll be stuck with it
(x) Asshats
The plan loses no email that is distributed by an actual mail server. Even the crappiest actual mail server out there follows the rules by checking another MX server, and if it doesn't it's going to lose a lot of mail anyway. Supporting multiple MX records isn't some obscure part of the standard, it's a major requirement, and all actual mail servers do.
And spammers can't 'lie' their way around it. They can use software that operates correctly in the first place, but the years have demonstrated exactly how long it takes them to switch. I have no idea how long the spam software pipeline is, but spammers have operated software that is broken in many ways, and people have been consistently using that brokenness to block spam for years.
If this reduces spam for a time and then stops reducing spam, I'm failing to see what the problem is. I'm still checking that the MAIL FROM domain is a real domain, and it's astonishing how much spam doesn't even bother to do that. Or checking that the HELO is not a negative number. (I have no idea what that's about.)
And we won't be 'stuck' with it. It doesn't change anything. People can point to a fake MX server for however as long as they want, and then switch back to just having their one real one, whenever they want.
And the 'asshats' check box is used to mean people can abuse or break the system. I have no idea why it was checked.
About the only one correctly checked complain is:
(X) Eternal arms race involved in all filtering approaches
Yes, it's an arms race, and, yes, it will lose power over time as spammer's crapware adapts. Aaaand? At the very least we cost spammers money, and upgrading spam software is insanely expensive. We didn't hurt ourself in the slightest.
If corporations are people, aren't stockholders guilty of slavery?
...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
The acknowledgements don't say anything about running specific software, or making any changes to software.
I've been doing nolisting for about three months now, and it required:
1) Making three A records, mx1.example.com, mx2.example.com, and mx3.example.com, all of them pointed to my IPs (Don't abuse the internet by directing traffic randomly elsewhere, people.) with mx2 being my already existing mail server and the other two being IPs without mail servers.
2) Set all the domains I felt like it to use those 3 MX records in order.
That was it. I didn't touch my mail server at all, I didn't even bother with firewalls, because my server already has a firewall setup.
If corporations are people, aren't stockholders guilty of slavery?
How did this get marked insightful? Sending a temporary failure SMTP response code is not a bounce, and should not result in the generation of a bounce message except from psychotic MTAs.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS