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

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

[ta bu shi da yu]

And thus the fallacy of "super-security". Security is only as good as what it allows a user to do. Sure, my computer will be secure if I put in a locked room with no access to the Internet, but it wouldn't be very useful.

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

That said, qmail is actually still pretty useful. However, pride cometh before a fall. The author's arrogance is going to let him down one day.

Re:license

[Asmodai]

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

Last time I had to reconstruct a particular email's flow through various MTAs including Qmail ended at the Qmail MTA since it the log files it uses offer little to system administrators to do proper troubleshooting.

That alone is one major reason to never ever consider it for production use.

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).

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?

[fimbulvetr]

Good solid code outside of the fact that he:

Hard codes port numbers.
Uses non-descript variables.
Forces interpretations one way without allowing changing.
Hard codes directory structures.
Has to write a monitoring program to monitor his daemons and restart on failures instead of just spending more time making sure his daemons are solid to begin with. Here's a note: If you need a different tool to restart your process when it fails, perhaps you should consider looking into why the process failed in the first place?

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.

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.

Re:I just love qmail

[gwynevans]

Well, I've got to say that I have found daemontools to be rather useful in a few scenario's where I need to have some controllable, 'always-up' processes. As for qmail, however, while I've not needed to use it, I have looked at it & while it did look useful back at the start, even then it seemed to me that djb could have done with a little more 'third-party' input to provide a less 'focused' view...

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.

Postfix makes for a good read

[andawyr]

A good read for anyone involved in secure development.

You would be wanting the Postfix source code, then. I've learned a tremendous amount about how secure, well designed software can be constructed. Wietse is a very smart guy, and his code is some of the tightest code I've seen. Go through it, and you'll be a better software developer for it.

I've never looked at the qmail code. It could be just as good, I don't know.

Re:license

[buanzo]

Yes, for example, you have Courier-MTA, which is a lovely and complete GNU GPLv2 package that closely follows standards and has lots of wonderful features, and a great filters API. For instance, you can implement SPF, Antivirus, Greylisting, several useful whitelistings and spamassassin in 5 minutes just by installing the pythonfilter package. http://www.courier-mta.org/ Although, to be fair, it lacks some milter-like filter API.

Re:An example, please?

[Gadzinka]

This kind of seems to contradict the above.

Not at all. DJB just carefully picks where to be ueberstrict, just to make fun of the others[1], and where to completely ignore useful function, just because he had a dream that it's bad[2].

Robert

[1] like rejecting SMTP transactions which use LF for line termination (RFC states it must be CR/LF), but most smtp servers of the time accepted either, while some "challenged" servers sent mail with LF only;

[2] qmail will never deliver mail to secondary MX; or tertiary etc; If primary MX for the address is dead, then you're screwed;