Slashdot Mirror
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."
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!
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?
READY.
PRINT ""+-0
Count yourself lucky that it doesn't all go under /djb
http://michaelsmith.id.au
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.
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
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/
Windows 2000 - from the guys who brought us edlin
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.
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:
Bogtha Bogtha Bogtha
One swallow does not a fellatrix make
The programming model used by DJB is more or less:
,,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.
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
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...
Bastard Operator From 193.219.28.162
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: /etc/init.d/... or delete a file and recreate it to restart.
1. How do you start / stop your MTA?
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.
Already pointed this out, but DJB is just gaining access to chroot, then dropping privileges.
XML is like violence. If it doesn't solve the problem, use more.
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.
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".
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.
http://bash.org/?7565
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?
Don't piss off The Angry Economist
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.
Hands in my pocket
And one heck of a decent guy, too. Unless he's destroying your career for no real reason.
Dewey, what part of this looks like authorities should be involved?
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;
Bastard Operator From 193.219.28.162