Qmail At 10 Years — Reflections On Security

os2man writes "Qmail is one of the most widely used MTAs on the Net and has a solid reputation for its level of security. In 'Some thoughts on security after ten years of qmail 1.0' (PDF), Daniel J. Bernstein, reviews the history and security-relevant architecture of qmail; articulates partitioning standards that qmail fails to meet; analyzes the engineering that has allowed qmail to survive this failure; and draws various conclusions regarding the future of secure programming. A good read for anyone involved in secure development."

Comments

license

[raffe]

The good thing is that is easy to work with and works really good. The bad thing is that the license is NOT FOSS. Sure, you can see the code and modify it but....from authors site:

If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

Re:license

[Znork]

"The good thing is that is easy to work with and works really good."

I'd heard that it was really good too. Then I noticed that if I wanted IPv6 support I'd have to patch and compile it myself. Thanks for playing, but there are more modern secure MTA's available.

"The bad thing is that the license is NOT FOSS."

Yep, and that's probably why qmail ends up lacking in some areas. Perhaps it could be called a security feature, but I prefer spending time learning applications that dont depend on some single person for having any future at all.

Re:license

[larien]

Between the non-FOSS license and the author's enormous ego, it becomes difficult to get anything done with qmail. Sure, it's secure, but it's a pain to do certain things. One of my biggest bugbears with it was that he didn't seem to see a problem where a mail sent to multiple group aliases might end up appearing twice in users' inboxes if a user was in more than one of the lists. It caused us some confusion when we started using qmail and all responses seemed to be "why wouldn't you want multiple copies of the same mail in your inbox?".

Yes, some of his refusal to compromise mean that qmail is still secure, but in terms of usability, it's a bitch unless you're willing to work with patches & diffs to add the functions you need.

Re:license

[MichaelSmith]

If the program is not functional, it doesn't matter how secure it is.

In wonder how much of the worlds spam traffic is a result of qmail sending bounces from a different socket connection and process, instead of sending the response back through the connection which the message arrived in.

But yeah it is very secure. Back when I first ran servers on the internet I bought a book on configuring sendmail. The ultimate conclusion in the book was to run qmail.

Re:license

[irc.goatse.cx troll]

The log files are useless, last time I had to debug qmail it involved writing a bash script to race to strace as soon as the qmail process was ran (I forgot why I didn't just hook the parent process, but I digress).

Re:license

[Antique Geekmeister]

Not much. Most of it, according to the last numbers I saw from the notes of the MIT Spam Conference, is rootkitted Windows boxes. There are just too many of them and it's just too easy to get more for any such operational feature of the servers themselves to make much of a dent.

I agree that sendmail was horrid to configure. The m4 wrappers have made it better, and Postfix provides an easy to configure tool that actually allows you to rebundle it with the configurations you want. Dan Bernstein's precious ideas of no documentation, his own peculiar and poorly explained licensing, no publication of forks of his code, and mixing the binaries in with the mail spool itself for various reasons are so nasty that many of us working with open source won't touch his utilities.

Re:license

[Ed Avis]

But from an individual site's point of view, it does make a big difference to have your MTA drop incoming connections immediately on getting an invalid address, rather than accept the mail and send back a soft bounce. Lots of spam is sent to random.address@known.site in the hope of getting somewhere. While accepting these messages ties up the spammer's resources, it also ties up your machine's resources.

Re:license

[Russ Nelson]

No documentation?? Every executable has a man page, even executables that the system runs (e.g. qmail-local or qmail-remote).
His licensing isn't poorly explained. But then again, you can't run 'man' so no wonder you couldn't Google for "djb licensing" and find http://cr.yp.to/distributors.html
Your third allegation was true until the publication of this PDF which you obviously didn't read since it included a dedication of qmail to the public domain.
The binaries aren't "mixed in with the mail spool". Binaries are in /var/qmail/bin, the queue is in /var/qmail/queue.

1 for 4. 25%. That's a failing grade in every school I know of.

Good article

[BadAnalogyGuy]

I don't mean to be flippant, but this is a really good article. That it appears on Slashdot gives me a lot of hope that this site isn't just a hangout for system administrators but also for software engineers.

The concepts Bernstein discusses regarding increasing security are very interesting, if not exactly obvious. Fix bugs immediately. Reduce LOCs to reduce the probability of bugs. And execute as much code as possible in untrusted mode. His discussion of running untrusted code in "prisons" is interesting, and I wonder what, if any, accomodation for this type of programming Windows has.

It was really nice to see software engineering presented here for once. Thanks kdawson... kdawson? No way!

Re:Good article

[Ed Avis]

You're misunderstanding Alan Cox's message. The way djb is suggesting is to chroot() to somewhere empty and then drop root privileges so you can't chroot() again.

(It's really unfortunate that you have to be root to chroot() to start with.)

Re:File system layout standards

[MichaelSmith]

Geez, how about some thoughts about file system layout standards, after 10 years?

Count yourself lucky that it doesn't all go under /djb

Security by not evolving

[gullevek]

if you use qmail "out of the box" it might be secure, but its not usable nowadays anymore. You often have to compile in so many patches that at the end there is no security there anymore.

I rather start with an up to date MTA, rather then fight with something like qmail ever (EVER) again.

Just the fact that you have a fixed layout, fixed start tools that need to be there to actually start it, etc etc makes it so horrible, that I wouldn't touch it ever again with a 100 yard pole.

Qmail going public domain?

[Bogtha]

The bad thing is that the license is NOT FOSS.

Actually, that might be changing in the immediate future. Check out the slides to go with this talk, in particular, page 10 where there's a timeline including:

2007.11: $500 -> $1000;
qmail placed into public domain.

Re:Qmail going public domain?

[Russ Nelson]

I can confirm this. djb send me, John Levine and Dave Sill (prominent qmail book authors) an email saying that he was going to put qmail into the public domain.

Secure programming by DJB

[Gadzinka]

The programming model used by DJB is more or less:

Implement only a subset of protocols, ignore the parts that you don't like, or might be insecure or are too boring to implement. Bonus points if you ignore actual features depended on by the users. Double bonus, if you manage to make it non interoperable by nazi-strict implementation of protocol, ignoring the rule ,,be strict as possible when sending, and liberal as possible when receiving''. If you can destroy other systems functionality especially designed for email (like multiple mx-es?), huuuge karma boost.

Then refuse to implement needed features, pointing to third parties and their patches, and offer a prize for successful hack of your software. And ignore the insecurity of the patches. They're third party, after all.

Robert

PS I was so glad when some mature alternatives to sendmail and qmail apeared...

I just love qmail

[deniable]

I was in a weird situation where there were two of us looking after a company part time. The other guy, a typical djb fanboy, replaced *most*[1] of exim with qmail, vpopmail, and daemontools. Oh what fun this was when he was 'unavailable.' The included 'docs' were garbage. Here's some fun questions for the audience:
1. How do you start / stop your MTA? /etc/init.d/... or delete a file and recreate it to restart.
2. How do you configure software? Config files or adding and removing files from a magic directory?
3. How do you kick the mail queue? Buggered if I can remember.

Having a few years of experience looking after various 'nixes is nothing to being thrown at djb's stuff without warning. Add to this the attitude from the fanboys I've met [2] and I hate anything touched by djb. The other fun thing I can remember from some doc was djb's suggested solution to one problem was to change fork().

[1] mailq ran, but obviously freaked out.
[2] The worst examples of the stereotype, however, I've seen stuff posted online from some very nice people. My sample size was small but annoying.

security is paramount

[Edgewize]

Regardless of whatever else you might think of him or his software, DJB is a promoter of "security at any cost", for which everyone should give him some respect. If there's anything we should have learned in the past ten years, it's that you can't half-ass security.

Too much software is written as if security concerns are on equal footing with features and performance. That should never be true. If your program deals with untrusted input and has access to sensitive information, then security must be the primary concern during the entire development process. Security is not something that you can "patch in" after the architecture is settled.

There can be no trade-offs when it comes to core internet services. If one mail server is 10x faster than another but also contains a remote execution exploit, it is not 10x better -- it is useless.

You can debate DJB's personal approach to security, but you cannot fault his priorities.