First, a slightly belated update: the spam flood to my server has been stopped in its tracks. Email and web services are back to normal, for localized values of ‘normal.’
Now, a small statistic, followed by a rant. This is high geekery; everyone not interested in hearing me gripe about mail servers should probably skip it.
Since this Thursday afternoon (when I finalized the new configuration), there have been 23,540 attempt to deliver mail to my mail server that were not pre-blocked by the spamhaus.org or sorbs.net antispam blacklists. Of those attempts, 19,166 of them were attempts to deliver mail to addresses which do not exist. Either they were “dictionary spam” (in which the spammer goes through a list of common first and last names, and attempts to deliver spam to every possible email@example.com), or “bounceback spam”, in which the spammer invents a fake address at someone else’s domain and forges that as the sender of the spam, so that any complaints or bounces go to the forged address instead of the spammer.
For those of you without a pocket calculator in the audience, that means that 81% of the emails sent to my mail server were to addresses that never existed.
This would merely be cause for hilarity, except that a design flaw in qmail, for years my mail server of choice, turned it into a complete debacle.
You see, the stock distribution of qmail does not validate the user portion of an email address until after the mail is accepted. In plainer English, that means that if you send mail to firstname.lastname@example.org, and I’m running qmail on blank.org’s mail server, qmail will happily accept that mail even if there is no such user as “bob”. Even if that mail is spam. Even if that mail contains a 300k image file. Even if that mail is spam and contains a 300k image file. And then, once qmail finally realizes that there is no Bob, qmail generates a new piece of email, a bounce message destined for the original sender, letting them know that the message wasn’t delivered, so not only have we spent time, disk and network bandwidth accepting a message that we never wanted in the first place, but we’re then going to spend MORE resources sending out an alert, quite probably to a sender address that was forged by a spammer in the first place.
Multiply that by thousands to millions of bogus messages a day and you have a problem. Add on top the CPU and disk utilization required by any minimally-responsible set of spam- and virus-filtering tools (spamassassin, crm114, clamav, etc) and you have a disaster. I run a very small mail server — a handful of domains, less than 20 users, less than 10 mailing lists — and the increased system and network load caused by accepting all of that bogus mail essentially took me off the air for a week, and came perilously close to blowing my ISP’s network quota and thus costing me quite a bit of money.
This was a defensible design decision in 1996, when you couldn’t sneeze without uncovering a new buffer overrun in sendmail, and massive email spam was a distant thundercloud on the horizon. Today? Not so much.
Luckily, this is a problem that has been solved a few times now. The qmail-validrcptto patch is probably the simplest way for most qmail administrators; if you’ve got some horribly abstruse setup going, it might be easier to use the qmail-spp plugin patch and write your own validator for the RCPT stage. But whatever you do, you should fix the problem: if you’re running a stock qmail or netqmail right now, you are acting as a spam amplifier whether you realize it or not.