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

license

[raffe (28595)]

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: [cr.yp.to]

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: It works really well? was: license

[by Anonymous Coward]

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

Amazingly, this is already flamebait. Yes, some people like it. No, other people absolute despise the djb-preferred way of doing things. Me, I'm one of those heretical djb-dislikers. I'm not saying you can't have your preferences, though; I am pointing out they're not universal. If you want the lowdown on large-scale qmail deployments today, ask NANAE.

Re:license

[Znork (31774)]

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

[einhverfr (238914)]

I run Qmail still. I intend to move to Postfix fairly soon.

There is only *one* reasonable advantage of Qmail, that the security engineering is one of the best I have seen (there is still room for improvement, for example a missing rcpthosts file should not turn a SMTP server into an open relay-- it is better to fail to safe conditions and reject everything).

The major disadvantages are:
1) I don't see any attempts by DJB to modernize the software. I would therefore suggest that the project has been orphane

Re:license

[larien (5608)]

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:

[ta bu shi da yu (687699)]

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

[MichaelSmith (789609)]

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

[Antique Geekmeister (740220)]

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 (5917)]

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 [e-mail] 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:

[gmack (197796)]

The lack of SPF should be no excuse to allow for a broken mail server implementation. When I set up a server the ability for a user to gain a shell on the system is only one of the forms of security I look at. I also need to consider if any of the resources on my machine can be used by an outside to inflict harm on other servers. I need to make sure that my name servers can't be used for a reflector attack, my CGI scripts can't be used to send email to other people and my email server can't be used to re

Re:

[Antique Geekmeister (740220)]

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* suc

Re:license

[Russ Nelson (33911)]

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 [cr.yp.to]
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.

Re:license

[Carewolf (581105)]

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:

[Asmodai (13932)]

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

[irc.goatse.cx troll (593289)]

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 (906264)]

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 [cr.yp.to], 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 (33911)]

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.

Re:Qmail going public domain?

[fimbulvetr (598306)]

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:

[Russ Nelson (33911)]

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

Good article

[BadAnalogyGuy (945258)]

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 (5917)]

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:

[ta bu shi da yu (687699)]

Ah... so it appears.

Re:

[ta bu shi da yu (687699)]

Unless you chroot down a directory. But... I missed his original point, which was to briefly elevate privileges and then drop them.

Re:

[Eunuchswear (210685)]

No, if you chdir to /home/test/root, then chroot to /home/test/root, then chdir to .. you'll still be in /home/test/root.

From man 2 chroot:

The .. entry in the root directory is interpreted to mean the root
directory itself. Thus, .. cannot be used to access files outside the
subtree rooted at the root directory.

How root gets out of a chroot is:

1. make, or find, a directory under the current chroot
2. chroot there, but don't chdir there
3. now ".." in the

Qmail and the patchset of doom

[Neo-Rio-101 (700494)]

I'd use Qmail, except that the licence means that in order for Qmail to scale, it has to be patched about fifteen squillion times over ... all thanks to the restrictive licence.

Sure it may be fast and secure... but unfortuantely scalable it is not (and if it is, it is far from obvious how).
Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

Re:

[MichaelSmith (789609)]

I'd use Qmail, except that the licence means that in order for Qmail to scale, it has to be patched about fifteen squillion times over ... all thanks to the restrictive licence.

Seeing that netqmail is distributed legally as a qmail distribution plus patches with a script which applies the patches, I wonder if I could get away with releasing a patched qmail as a repository in a DSCM tool like mercurial [selenic.com] since that just maintains the base version plus optional patches.

Re:

[incubus^ (154787)]

I heard Yahoo! use it... or a derivative.

I used it in an ISP environment but at a certain point it becomes impossible to manage. The qmail queue is like a tub of nitroglycerine - fine, but if you touch it, it explodes.

Qmails strength its its simplicity. It then achieves security because it is a simple program. For small mail installations it is fine, high performance, small footprint, etc. Each component part is easy to debug.

It becomes unwieldily when you need to do things which aren't simple, queue ma

Re:

[aproposofwhat (1019098)]

Yes - Yahoo! use it (or so the headers report).

I've encountered problems with users sending to multiple recipients in the same domain from a Yahoo! account, where Qmail sends the email not just once, but N times (where N is the number of users), resulting in N^2 emails being processed by the recieving server.

I conclude from this behaviour that Qmail is fundamentally broken, and am a firm believer in Postfix (all hail the mighty Big Blue!).

:P

Re:

[discord5 (798235)]

Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

At my previous job we used to run qmail for our mailhosting boxes. I can tell you that we were really happy with qmail back then, with the right patches it can be a really flexible mailserver, and once you're used to how it works you'll be in SMTP bliss. However, when you need functionality that isn't provided by qmail, you're doing one (or some) of the following:

• patching qmail, recompiling, testing, deploying
• writi

Security by not evolving

[gullevek (174152)]

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.

Re:

[fruey (563914)]

I used Postfix for a long time. I'm no longer an MTA admin, but looking at QMail install procedure & Postfix procedure, I decided that Postfix was the way to go. It probably still is.

One other thing was that DJB's quirks (even if he may be right about a lot of the things he believes in) mean you have to adopt his style of doing things to get things to work. It's the same with djbdns.

The paper is still a worthwhile read though, if you're a serious software engineer you should, like him, be looking back o

The patches make it still worthwhile

[rainer_d (115765)]

Bill Shupp's patch plus Matt Simerson's Mail-Toaster Perl-library still make a difference.
With postfix or sendmail, you've got to write all the provisioning-tools yourself, but qmail+vpopmail+qmailadmin delivers something out-of-the-box.

http://www.shupp.org/ [shupp.org]
http://mail-toaster.org/ [mail-toaster.org]

Re:The patches make it still worthwhile

[gmack (197796)]

Not even close to true. Postfix Admin [sourceforge.net] does everything vpopmail does and more. I used to run qmail+qmail for years several years before I switched over and I can tell you Postfix Admin does a better job.

qmail and reiserfs

[MichaelSmith (789609)]

In the PDF at the end of section four he talks about making compromises in the design of the configuration files and the inadvisability of working around file system problems. I can't quote it because my PDF reader is doing strange things with selection but it occurred to be that DJB has some approaches to software in common with Hans Reiser, and that maybe DJB is the right person to drive reiserfs development in the future.

Re:

[ta bu shi da yu (687699)]

You aren't use Envince, are you? I'm having problems also.

Re:

[ta bu shi da yu (687699)]

If so... bug has been filed [gnome.org].

Re:

[MichaelSmith (789609)]

You aren't use Envince, are you? I'm having problems also.

Yes, I am. When I select text in the right column of text the entire left column gets selected.

Re:

[aproposofwhat (1019098)]

I hope DJB's not married...

One of the most widely used ???

[inflex (123318)]

Where did the submitter get their information from for saying that it's one of the most widely used mail servers ? I suppose if you "widen" your limits a fair way it could come in as being moderately popular.

Sendmail, Postfix, Exchange... sure, they're up there in the high levels.

Anyhow, would love to see a site/page showing the breakdown of mail servers around the net.

Secure programming by DJB

[Gadzinka (256729)]

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

Re:

[Gadzinka (256729)]

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 et

I just love qmail

[deniable (76198)]

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:

[deniable (76198)]

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.

security is paramount

[Edgewize (262271)]

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.

Postfix makes for a good read

[andawyr (212118)]

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:File system layout standards

[MichaelSmith (789609)]

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

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

Re:

[Craig Davison (37723)]

It makes perfect sense. Your package manager installs binaries in /usr/bin and /usr/lib. You don't want to write to those directories yourself so you don't conflict with the package manager. Binaries you compile yourself go in an alternate set of directories, /usr/local/bin and /usr/local/lib.

Re:

[ta bu shi da yu (687699)]

Already pointed this out, but DJB is just gaining access to chroot, then dropping privileges.

Re:

[Russ Nelson (33911)]

It's funny how many people bitch about the license when IN THE PDF UNDER DISCUSSION djb announced that qmail was going into the public domain. So, now that qmail is Open Source, will you be sticking with it?

Re:

[Just Some Guy (3352)]

I think he's neat!

And one heck of a decent guy [slashdot.org], too. Unless he's destroying your career for no real reason.