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

Which is worth more...

[Anonymous Coward]

...writing a navel-gazing paper after ten years or re-licensing the code so it doesn't devolve into an antiquated relic burdened with conflicting and hacked up patches just so it can be barely useful to a modern userbase? This is one more area where the licensing rubber meets the road: when you can do an "apt-get install exim4" because the license allows for modified binaries versus a download / patch / fix conflicting patches / compile / fix broken code / compile / install cycle every time you need an MTA, with future patches for missing features a guarantee, admins will eventually vote with their fingers and stop installing qmail. Much like the free software belief that draconian licensing terms will eventually be the death of the licensors' products, the lack of a license will eventually do the same to djb products. The right licensing is freedom, and freedom adds more to the vitality of a piece of software than any post-decade academic paper will ever do. I guess we should have known the academic would value publishing over community-friendly, viable, real-world-issues-comprise-more-than-security software.

Call it an experiment and warn serious users away. Or free qmail. Until then, I'll be making sure I actively migrate away from it when given the opportunity.

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.

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

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.

Re:license

[Carewolf]

Seriously if the user has subscribed to multiple mailing lists and the same mail is send to more than one of them he SHOULD get more than one copy.

It is incredibly confusing when some stupid mail-provider along the way decides to snuff one copy. This means the mail doesn't appear where it should in my email-program. Each mail the the different mailing list creates a separate thread of responses WITHIN that mailing-list. That is TWO not ONE, but TWO different discussion threads, which should be represented with two entries in you email program.

Re:I just love qmail

[deniable]

I don't doubt the usefulness of daemontools, it's just that if you haven't seen its unique way of doing things you wouldn't believe it. Who buries a service startup in a combination of inittab and the /srv (?) directory? Once you know, it isn't a problem, but when someone 'forgets' to tell you, it can be quite frustrating.

qmail is not suitable for use

[Arrogant-Bastard]

Qmail -- whatever its security merits, and it does have some -- is not suitable for use on the public Internet because it fails to comply with not only de jure standards (RFCs) but de facto standards (best practices). The author has refused to correct these defects -- which is certainly his prerogative as an author, but has as a byproduct serious operational impact on not only users of the package, but other mail server operators who communicate with those run by users of the package.

It's my professional recommendation (based on nearly three decades of experience running mail systems) that qmail be avoided in favor of superior packages such as sendmail, postfix, and exim. (Although the latter, unfortunately, appears to be making increased use of an abusive, spam-supporting feature known as "callbacks".) These packages are actively maintained and their authors have made, and continue to make, efforts to make them standards-compliant and well-behaved (despite the increasing stress placed on them by all forms of mail-related abuse).

As an aside, readers interested in the history of qmail should query a Usenet archive for "a tribute to the programming style of Eric Allman".

Re:license

[Antique Geekmeister]

Also note: bouncing undeliverable email is part of the specification for SMTP, because mis-addressed or randomly guessed email is indistinguishable from temporarily undeliverable email. If you don't bounce it, the sender (who may be legitimate!) has no way to know it hasn't arrived. Dropping it on the floor becomes a real problem.

What you've described as an open relay really isn't: it's a "Joe Job", a forgery pretending to be from somewhere else, exactly what SPF was designed to block. Now, *throttling* such connections seems completely reasonable, but as someone who's run SMTP servers, I submit to you that discarding the messages silently is not.

Re:Qmail going public domain?

[Russ Nelson]

"Hard codes port numbers." Okay, *you* go ahead and change port 25. Tell me when you get everybody else to use a different number and then I'll change my code. (hint: I won't be holding my breath.) "Uses non-descript variables." Usually 'i' is an iterator, but you can use it any way you want. On the other hand, he calls the remote IP address "remoteip", the remote host "remotehost" and the remote user info "remoteinfo", but if you think that's non-descript, I wonder what variable names *you* would use. "Forces interpretations one way without allowing changing." I have no idea what you're talking about; so far you don't either. "Hard codes directory structures", yes, this is to prevent attackers from subverting the paths."Has to write a monitoring program to monitor his daemons..." Actually that's because Unix HAS NO monitoring program which allows you to send a signal to a child, which is why people resort to REALLY GROSS hacks like: kill -HUP `ps aux | grep processname | grep -v grep | awk print $1` . Then again, you'd probably complain if djb *didn't* provide daemontools.