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

[gmack]

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

Unpatched Qmail is a form of an open relay. A couple years after running it for the first time someone started bouncing email off it and eventually it got so bad that I had thousands of emails in my queue at any given moment. This has been the case for every customer I've run into that is using Qmail.

People need to stop referring to Qmail as "secure." It just isn't.

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.

Re:license

[einhverfr]

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 orphaned.
2) Since it is not open source, nobody can pick it up, modernize it, and release a version with compliance of newer standards (i.e the ones which have come out in the last 10 years, meaning you are stuck with pop-before-smtp and the like :-( ).
3) While the security engineering is good, the overall software engineering leaves a lot to be desired. In particular a lot of really braindead algorithms are used.

The article is an interesting one to read though.

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:Good article

[Eunuchswear]

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 old chroot is its real parent, not itself.
   

Of course DJB was suggesting that you drop root privs immediately after the chroot, so this is moot.

Re: It works really well? was: license

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

Qmail and the patchset of doom

[Neo-Rio-101]

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:Qmail and the patchset of doom

[Gricey]

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 management, scaling to a godzillion users, policy based mail routing, multiple actions on a mail before its delivered, db lookups, intelligent filtering, etc. These things are either unavailable or a third party (after the fact) bolt-on.

If it's license wasn't so badly the suck, then it probably would be as current and featureful as any other MTA in wide use today. As a result of its silly license, the barrier to maintain and extend it is too high for most people and it's stuck in 1997.

-- incubus

Re:Qmail and the patchset of doom

[discord5]

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
• writing a perl/bash/whatever script that goes somewhere in the Big Qmail Picture
• muttering curses and djb's name for the licensing

I can't really bring myself to bashing qmail over these things because it's served me well and I've hardly had any "unexpected" things happen to me, which is something I can't really say of other MTAs I've tried and I've never had any security problems (altough you might want to read this page). There's a lot of information available on qmail, and you can check out this guide (although this may now be quite dated). An indispensible tool is qmHandle for inspecting and manipulating the qmail queue in case something did go wrong.

Finally, I have to admit that when I left that company my own mailhosting services are currently being run by postfix, simply because I don't have the time to build my own qmail packages whenever I need some feature. If you look at the postfix design, any qmail user will see similarities and the fact that you're not patching and rebuilding it whenever you need feature X sort of grows on you.

I know that if I were to start hosting a large mailserver, I'd have a hard time deciding between the two and I'd do a lot of testing before I made a choice.

Re:pdf?

[Anonymous Coward]

google html of the pdf (perhaps as bad in some ways as a pdf):

http://preview.tinyurl.com/33lvkr

The patches make it still worthwhile

[rainer_d]

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/
http://mail-toaster.org/

Re:The patches make it still worthwhile

[gmack]

Not even close to true. Postfix Admin 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.

One of the most widely used ???

[inflex]

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.

Re:One of the most widely used ???

[wfWebber]

There, Googled it for ya:

http://www.securityspace.com/s_survey/data/man.200710/mxsurvey.html

And, at 0.17%, I'd say it wasn't as widely used as the poster wants us to think.

Re:One of the most widely used ???

[tokul]

Server provided banner - 1,521,596 - 85.95%
Server banner identifies software in use - 921,048 - 52.03%

Qmail does not provide banner that allows to identify software. 0.17% is for Qmail toaster.

Re:One of the most widely used ???

[thanosk]

Well the way that survey was conducted it relies on the 220 answer from the MTA
to identify which Mail server it is.
Qmail does NOT identify itself and as a result it cannot be counted using this method

Also note that for only 52% of the queried MTA they were able to determine the
software used.

Re:Is a sandbox a security solution?

[ta bu shi da yu]

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

Re:I just love qmail

[tokul]

> 1. How do you start / stop your MTA? /etc/init.d/... or delete a file and recreate it to restart.

http://cr.yp.to/daemontools/svc.html

svc -d /service/qmail - stops
svc -u /service/qmail - starts
svc -t /service/qmail - terminates the service and daemontools restart it.

> 2. How do you configure software? Config files or adding and removing files from a magic directory?

http://www.qmail.org/qmail-manual-html/man5/qmail-control.html

> 3. How do you kick the mail queue? Buggered if I can remember.

send ALRM to qmail-send process.

kill -s ALRM `pidof qmail-send`

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.

Re:Which is worth more...

[Russ Nelson]

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

[Craig Davison]

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:DJB is a cool guy!

[Just Some Guy]

I think he's neat!

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