stormbrew

I’ve long been a fan of djb’s method of writing software. Over the years, three of his tools have served me very well: djbdns, daemontools, and qmail.

But djb has a dark side. He has some strange views on filesystem layout (I’m no booster of the linux standard layout, but his views on layout are just plain strange) that I can get over if not work around. More importantly, though, are his views on licensing. The GPL makes me cringe (another blog post for another time), but djb goes a whole other direction: You can’t modify his code and redistribute it. You can distribute patches, you can distribute his pristine copy, but you can not and must not distribute an altered version wholesale, in source or in binary.

Which would be fine, if it ever got updated. But it’s been years now, and the world of internet mail (and spam) has changed drastically since then. Namely, backscatter. To a lot of people familiar with email tech, this is nothing at all new. But to qmail, it’s like it’s still 1999.

For the uninitiated, backscatter is when spam sends to known-bad addresses with a reply-to that goes to their real target, a known-good (or plausibly-good) address. The known-bad bounces back to the known-good, giving someone spam from a sender who didn’t actually mean to do anything bad. This results in a very bad reputation for the previously innocent mail server.

Think of it like sending a letter with no stamp and the address of the person you’re sending it to to get around paying for postage (note: I have no idea how this works and am not endorsing any form of mail fraud).

The right thing to do, nowadays, is for a mail server to immediately reject an undeliverable email with an error (like a 404 code from a web server). Because of a quirk in how qmail is designed, it can’t do that, though. It will accept all mail for all domains it knows about and then reject it later if it can’t deliver through a bounce. Which makes it a prime target for backscatter.

The process for solving this with qmail involves a fairly tedious and possibly risky set of steps. You have to patch your copy of qmail to add scriptable hooking to the e-mail accept phase. You then have to add a script to this system, written in probably bash or perl script, that will go through and do all the processing qmail intends to do later on to figure out if it’s deliverable. If it’s not, it’ll return an error code. If it is, it’ll let it go through the normal qmail process.

This completely breaks the rather beautiful design of qmail. At this point, you may as well be using postfix, which is less beautiful but actually designed for plugins and has more modern notions about what to do about backscatter anyways.

So from being a djb booster, there’s now only one product of his I recommend: djbdns. Still the simplest, cleanest little dns server you can run. Daemontools has fallen out of favour to runit, which has similar modernizations and a less restrictive license.

So postfix seems to be where it’s at for email servers these days. I always felt I had a better understanding of how qmail worked, though. Maybe someday someone will ground-up rewrite it like they did with daemontools/runit.