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

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

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.

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

Re:license

[Antique Geekmeister]

Ahh, I see your point. SPF version one is even better that way, by dropping it at the "FROM" line for the bounce address before even getting to the "From:" line and bouncing back to a forged target. That's probably a bigger advantage during a big email worm attack, rather than during a spam attack. But I see your point.

Re:license

[QuietLagoon]

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

It is an awful package to work with. If you want to do anything (like, say, IPv6 support) beyond the very, very basic things that were coded in qmail many years ago, you have to apply dubious thrid-party patches. Patches that are not coordinated, patches that conflict with each other, patches that introduce nasty bugs.

qmail configuration files are cryptic (though, to be fair, not nearly as bad as Sendmail's config files). You have to install qmail with the directory structure djb wants, otherwise you violate the license.

qmail has not seen development by the author (djb) in many years.

Look to Postfix if you want to use a simple, modern, secure and up-to-date MTA.

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

[Antique Geekmeister]

Oh, that's "outside the scope" of the Qmail security, just like what chunk of the filesystem software lives on is "outside the scope" of any of Dan Bernstein's packages. By focusing on a particular, small, tractable problem, and then stomping on everyone else's conventions, he makes very "secure" packages that leave the other problems "to the reader". Bernstein doesn't want to play there, and doesn't allow repackaging, so he will never have to.

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

[Jeremy Kister]

Did you read the article? He released qmail to the public domain...

package it up and put it under whatever license you want :)

Re:license

[gmack]

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.

How many SMTP servers could you have possibly run if you didn't know that it's possible for the server to refuse the email in the first place and let the SENDING mail server handle the bounce message?

Refusing the email during the SMTP handshake results in a faster bounce for the user and less CPU and network time wasted between the mail servers.

And don't get me started on how Barracuda spam filters depend on an immediate refusal to detect address guessing and how that whole feature is made useless by Qmail not doing things properly.

Re:license

[nacturation]

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. Group alias != mailing list. If those multiple copies are the result of different Message-IDs, then you should get multiple copies. However, if your CEO sends out an internal announcement and copies five distribution groups that you're a member of then you'll get only one message since that's the equivalent of doing a "RCPT TO: <you@yourdomain.com>" five times.

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

[Kadin2048]

Only if they're actually different messages.

If they're the exact same message just relayed to you twice, then it doesn't make sense to deliver two copies; you should get one -- and the problem you're describing regarding filing is a MUA one, not an MTA issue. (IMO, a good MUA would let you have the same message in two views/folders, and show it in multiple threaded discussions if it's referred to there.)

But anyway, aside from that, I agree that qmail sucks and I hate it for many reasons besides its handling of duplicate messages. I prefer postfix.

Re:license

[Antique Geekmeister]

It's *possible* to refuse it in the first place, and better to refuse it earlier in the process, I agree. (That's part of why I like classic SPF: break the connection when they forge the sending address, even before they get to the recipient's email address.) I thought you were suggesting that the MTA drop the message, rather than bouncing it, and I've seen that sort of policy done. I take it that dropping it on the floor is not what you meant?

And yes, Barracudas are their own bit of fun to administer.

Re:license

[petermgreen]

You only need to send a bounce if you have accepted the mail.

Ideally incoming servers should never bounce mails they should accept the mails for legitimate addresses they know how to deliver to and reject all others.

Re:license

[gmack]

I would never set my mail server to just drop incoming email since then no one knows something went wrong and bad assumptions get made when legit emails don't get replied to.

I hate it all the more since a few years ago I ended up on a broken MTA blacklist (thanks Qmail) thanks to the constant backscatter and several providers just accepted and then dropped everything coming from my mail server with no error.

Took me forever to figure out what was going wrong.

Re:license

[portnoy]

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.

Uh, no. The *document* is being placed in the public domain. There is no change to the software licensing.

Re:license

[Antique Geekmeister]

Have you looked carefully at that documentation? Without actually spending hours reading the source code, and deducing its layout, it's hopeless because it's either too casual, or at too deep a level that's simply not useful to installers. Worse, it's in an odd enough "man" format that it spews ""Esc" all over its output without serious re-editing, which is prevented by Dan's unique licensing model. To quote:

        You may distribute a precompiled package if installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above;

Ooops! Repairing the man pages is forbidden for compiled binaries! Frankly, I don't count that mess as documentation. Would you?

Second, while his web page on his licensing is clear, the implications are not, and it's not in the tarball. Oops! Once again, you have to go searching for how to fix it, and can't distribute a patch inside the tarball. And you say it's in the public domain? Read the PDF again. The PDF is public domain, Qmail most certainly is not.

Last, you have a point about /var/qmail/bin and /var/qmail/spool. But the Linux and UNIX filesystem hierarchies clearly state that the binaries should be over in /usr. /usr/lib/qmail would be appropriate for these, but once again, Dan's precious and unique licensing interferes.

Re:license

[nuzak]

I believe the multiple copies business is thanks to VERP. Which was a good idea, executed poorly, to the point of being abusive to the resources of receivers. But don't tell that to djb unless you want to get yourself banned from his litle fiefdom. Dan Bernstein makes Theo de Raadt look like the Queen of Nice and a master of reasoned diplomacy.

I think the only major qmail installation left these days is Yahoo.

Now if I could find a reasonable alternative to djbdns... I'm sure there's something out there, but the alternatives just don't seem to get the same exposure.

Re:license

[nuzak]

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.

Did you forget a link around "This PDF"? Because the licensing page still has the old terms.

Re:license

[nuzak]

If they're the same message, they should have the same Message-id, and even if it's split up by qmail, it might conceivably be the province of the MUA or the local MDA to collapse them into a single copy. Arguably qmail isn't helping, but it is pretty ambiguous who has what responsibility here.

Re:license

[homer_ca]

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.

Not exactly. You can return an SMTP 5xx error for an unknown recipient, and any compliant MTA will understand that as a permanent failure. You can also send an SMTP 4xx error for a temporary failure, and the sender's MTA will know to retry later.

Now many MTAs don't check for unknown users in the initial handshake, either because they don't have directory info available or they're just configured to accept all mail and bounce it later. While that's still correct, it's much worse for spam in practice.

Re:license

[nuzak]

Ah, "This PDF" would be TFA. Thwack. Use the proper Slashdot Standard Acronym next type ;)

Re:license

[zsazsa]

Please read this comment of Russ Nelson's confirming the placement of qmail into the public domain.

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

[XenonOfArcticus]

Russ, I read the PDF and enjoyed it very much. I'm a big fan of qmail and run it on all of my machines. But maybe I missed it, I didn't see Dan mention anything about a license change for qmail, or maybe I'm misinterpreting what you said by "a dedication of qmail to the public domain". Could you enlighten me?

Re:license

[Antique Geekmeister]

Now, *that* is an interesting cite. But I suspect that he's going to redefine "public domain" the same way he seems to define "security hole", by limiting it so severely that it's not what other people mean by it.

Re:license

[Antique Geekmeister]

The PDF is very interesting. I agree with many of its hard-won lessons. But like Linus Pauling becoming hung up on vitamin C, Dan's obsessions interfere with using his other work.

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.

Re:license

[maz2331]

QMail isn't a program or a "product" it is a modular toolkit for creating kick-ass mail servers. I have pretty well standardized on it for whatever I roll out, and it just works beautifully.

I do swap out the SMTP module and use the LinuxMagic "magicsmtpd" instead to gain some features. The nice thing is that a flaw THERE won't affect other parts of the system since qmail modules don't even trust each other.

IF you just want something you pop a CD in and install with a few clicks, then stay away from qmail. On the other hand, if you want to build a really kick-ass mail server it is the heart of your toolkit.

And... if you want an easy way to roll out a base system look up "qvcs" on SourceForge. It will take you from a base OS load to a working decent qmail, VMailMgr, and SquirellMail box in one shot. You can then adjust it to your heart's content.

Re:license

[kashani]

I left qmail for the greener grass that is Postfix years ago and wondered why I didn't do it sooner. Everything your like, need, or want Postfix does easier and faster than qmail even after you've tracked down the fifteen odd patches you'd need to run qmail properly.

I also highly recommend PostfixAdmin for virtual mail hosting with Postfix, Mysql/Posgres, and your favorite imap server.

kashani

Re:license

[Ice Station Zebra]

I love the fact that your sig is for ledger:SMB which is based off on of the worst web based products ever, sql-ledger. Guess you know a lot about brain dead algorithms.

1. Has there been something new in the smtp RFC's in the past 5+ years? Not really.
2. Ever hear of netqmail?
3. I think my first paragraph covers this.

Re:license

[einhverfr]

I share your view of SQL-Ledger. Unfortunately, forking was a matter of supporting some projects I inherited (and the fact that SQL-Ledger was for a time the best FOSS SMB accounting app available, which says alot about the competition or lack thereof). Take a look at what we are doing in /trunk to see where we are going. By 1.3, we will be well on our what to a full, secure rewrite and re-design of the code. Interestingly, our code is shrinking considerably with each major release.

My issues with Qmail have tended to stick to only a few of the standards (no support for 2554, for example, without patches). Yes netqmail is helpful but without active maintenance of the main application, this means that Qmail is more or less frozen on old archaic standards. (any standards later than 2821 aren't even mentioned by DJB in his reerence, as well, nor are critical extensions for preventing spam and the like).

The second issue is that DJB seems to like to break as many conventions as possible. He does not seem to try to follow standards such as those of file system layout much at all. Unlike many others. One gets the impression that anything one runs that he wrote that it is at best tacked on to the side of the *nix OS and doesnt really integrate well (HTML-based help pages often replace MAN pages, files and scripts are not where one expects them to be, and so forth). These can't be corrected because any changes have to be approved by him personally.

Finally DJB does some generally braindead things (such as extremely stupid sources of random numbers (such as getpid()), and the extreme phobia of any sort of parsing results in strange bugs when it comes to compatibility with certain email clients. These algorithms are braindead because they don't take into account future standards which could be intended to be backward compatible and yet cause strange bugs to mysteriously appear in the server software, and because they are otherwise brittle.

Having said this, I generally agree with all of DJB's points about security with the exception of the categorization that least privilege is a distraction. In reality it is one level which helps to reduce the severity of security bugs as they occur. This is thus one aspect of defense in depth (which is to minimize the amount and types of damage that can be done at every point in execution). In fact, this idea of privilege separation is one of the basic mechanisms behind Qmail's lack of trusted code.

Re:license

[VVelox]

Nah, the log files it produces are quite useful. It would just mean you don't know what you are looking for or etc.

Re:license

[Russ Nelson]

Crap. Somehow I thought that the linked document was the one for his talk, in which he released qmail to the public domain. Apologies, my bad.

Re:license

[Russ Nelson]

After presenting that paper, he also published the slides from the presentation in which he dedicated qmail to the public domain. Somehow I confused the paper with the slides, so yes, my apologies for making wrongful accusations.

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

[HonIsCool]

Drop root privileges after chroot()?

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

[ta bu shi da yu]

Ah... so it appears.

Re:Good article

[stevied]

Note that djb says an *empty* directory. Assuming that you can't mkdir() in that directory, then there's nowhere to move the chroot to. I presume that's why he explicitly mentioned the emptiness :)

Re:Good article

[ta bu shi da yu]

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

Re:Good article

[zootm]

His discussion of running untrusted code in "prisons" is interesting, and I wonder what, if any, accomodation for this type of programming Windows has.

Windows Vista introduced Protected Mode for IE, which presumably does this sort of thing. I assume this sort of sandboxing can be applied to other processes too, but I've not looked into it.

Re:Good article

[caluml]

It's also really stupid in this day and age that you need to be root to bind to Require root to bind to ports below 1024.
I'd untick it in a flash.

Re:Good article

[caluml]

Repeated, converting less-thans to <

It's also really stupid in this day and age that you need to be root to bind to <1024. There's just NO need for that any more that I can see. Can we get a compile time kernel option? <*> Require root to bind to ports below 1024.
I'd untick it in a flash.

PS. Postfix is much more friendly.

Re:Good article

[Eunuchswear]

Uh, if the directory is empty where can you "chroot down" to?

Re:Good article

[amorsen]

It's also really stupid in this day and age that you need to be root to bind to <1024. There's just NO need for that any more that I can see.

You trust all your software to not try to bind to port 25 and steal your mail? Or to port 80 and deface your web site? If you trust all your software, why not just run everything as root in the first place?

Re:Good article

[caluml]

You trust all your software to not try to bind to port 25 and steal your mail? Or to port 80 and deface your web site? Frankly, yes. If I can't trust a Listen 80 statement in Apache, who can I trust. Plus, if something's already bound there, other things can't bind. My system boots, it starts Apache and Postfix - nothing else can bind to those ports. Also, I don't generally run software I can't "trust".

Re:Good article

[ta bu shi da yu]

I could be misreading something I suppose. When I read "empty" directory, it seems to me to be a directory without any files or directories.

If you chroot to /home/test/root/ then chroot to /.. then it will chroot to /home/test.

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

[eneville]

I think the openbsd installation allows www-root to bind to :80. Of course, you have the source, why don't you take a look and make the alterations, I'm all for something like a system where you put the ports you don't mind about in /proc/sys/net/ipv4/ports file or something.

Re:Good article

[caluml]

Sure, if you have untrusted users on your box. Plus, you can use things like LIDS or GRsec to restrict things like what capabilities programs have. Like I say, a compile option, or possibly a sysctl entry.

Re:Good article

[ta bu shi da yu]

The superuser can escape from a 'chroot jail' by doing 'mkdir foo; chroot foo; cd ..'.

Re:Good article

[Antique Geekmeister]

And if you don't bother to install an HTTP daemon, then I get to take it away from you and you have to break mine to get your port back. That's too awkward to manage.

Re:Good article

[caluml]

Huh? If, when I'm adminning a box, and I try and start apache, a quick netstat -planet shows yourapp.pl bound to tcp/80, I'm sorry, but it gets a swift kill.

Re:Good article

[Eunuchswear]

Is that not what I just said?

Re:Good article

[nuzak]

All this port 1024 business is is just a default setting, and defaulting to locking down a sensitive port range makes a lot more sense than defaulting to having it open.

Wouldn't a decent access control implementation like GRsec or SELinux be able to open or close port ranges independently of the process's euid? I'm not experienced with either one, so I don't know if they can, but it seems reasonable to me.

Re:Good article

[nuzak]

Should have been "port < 1024". Good old slashdot and its web-0.9 post editor.

Re:Good article

[evilviper]

(It's really unfortunate that you have to be root to chroot() to start with.)

No, it would be a HUGE security hole to do otherwise.

Re:Good article

[lwiniarski]

Amen.

I'm always surprised at the level of animosity he seems to get. I guess
bad programmers don't like to hear scientific reasons about why their programs
have so many bugs. ...and probably that's why they are bad programmers in the first place.

Re:Good article

[ta bu shi da yu]

No... my understanding is that it will take you to the directory above the chroot'ed directory.

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

[MichaelSmith]

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 since that just maintains the base version plus optional patches.

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

[aproposofwhat]

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

[mrjackson2000]

1 patch. John Simpson has made a combined patch set including some of his own improvements/fixes. he also has alot of other documentation and is quite active on a couple mailing lists related to qmail.

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

[harmonica]

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

RTFA: section 1.2 lists big users (source: qmail.org).

Re:Qmail and the patchset of doom

[bdowne01]

Yup, we do. Not much patching either--since most of the tricky stuff is done via vpopmail. We did replace qmail-smtpd with a drop in from LinuxMagic for the valid user checking piece.

Re:Qmail and the patchset of doom

[NerveGas]

As far as scaling, in an instance on old P3s with a regular IDE disk, by turning off fsync and logging, it blazes through mail without any patches at all. Tens of thousands per minute, the limits are the network and DNS. Fast enough that undergoing multiple crazy-rate dictionary spam attacks at once, it would take as long as a few seconds to a quarter minute for an email to go through, but not worse.

Now, you might say that turning off logging and fsync are cheating - in fact, they're just eliminating bottlenecks external to qmail (namely, disk latency and syslog overhead). Yes, you run the risk of losing the email in progress if you crash, but a 20-50x speedup is quite a bonus for taking that risk.

In fact, many years ago, with a Celeron 450, 128 megs, a SLOW ide drive, and just a DSL line, it took around 45 seconds to deliver a thousand emails, and that was with logging and fsync turned on, if I recall.

In summary, my point is that once you eliminate bottlenecks outside of qmail, it's really quite fast. It can certainly be made faster with patches, but it's not exactly a slouch by itself.

Re:Qmail and the patchset of doom

[turbidostato]

"you obviously haven't used it much."

You haven't, either.

"i have been using it with a database of gazillion users for many a year now"

Thus, you haven't used Qmail, but Qmail *plus* patches. Now, have been you so lucky to have to apply any two sets of patches? Chances are they won't cleanly apply or even if they apply cleanly, then you won't have the ubersecure inception from EJB's brilliant mind.

Not to diminish EJB merit (not that his ego were going to suffer, anyway), but I can say I build perfectly secure computers: I provided an iron mass, then you apply third party patches as needed.

Re:Qmail and the patchset of doom

[rayvd]

The ISP I used to work at did. We used qmailtoaster. Made upgrading and redeploying much easier.

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.

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:Which is worth more...

[portnoy]

THE PDF UNDER DISCUSSION says no such thing. If djb is relicensing the code, he should say so publically; not just to you.

Re:Which is worth more...

[bdowne01]

Yes it does.

Re:Which is worth more...

[shutdown -p now]

Well, it still sucks at present, and better alternatives have been available for a long time. Why bother improving it?

Re:Which is worth more...

[NerveGas]

Interesting. Where does it say so? I saw no mention of it, other than a note stating that the paper itself was in the public domain. In case I missed something, I searched for "domain" and "license", and found nothing.

Re:Which is worth more...

[bdowne01]

Slide 10: http://cr.yp.to/talks/2007.11.02/slides.pdf 2007.11: $500 ! $1000; qmail placed into public domain.

Re:Which is worth more...

[NerveGas]

Cool. Thankyaverymuch.

Re:Which is worth more...

[Paul Crowley]

OK, so as the GP poster said, the PDF under discussion says no such thing. I'm glad to hear another PDF does though.

Re:Which is worth more...

[Russ Nelson]

You're right; I'm wrong. djb released qmail to the public domain (which isn't relicensing; public domain isn't a license; it's no need for a license.) in the slides for the presentation of the paper, not in the paper itself. I was confused.

Re:File system layout standards

[MichaelSmith]

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

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

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.

Re:Security by not evolving

[buga]

I agree with the parent a hundred percent. Qmail is too much of a chore to setup and admin. And when something does go wrong, it's very hard to troubleshoot. Personally I prefer postfix anytime. I have done setups for both and just prefer the config layout for postfix. Of course you can change the postfix config layout anytime, since it's configurable.

Re:Security by not evolving

[fruey]

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 over your last 10 years and asking yourself if you're better today, and whether you were right to adopt certain approaches.

Re:Security by not evolving

[monkeySauce]

EXACTLY. I couldn't have said it better myself.

After taking a peek a qmail once, I ran the hell away from it. I've used courier-mta in the past and these days I use postfix and couldn't be happier.

Re:Security by not evolving

[Trogre]

Given that we have Postfix, I'm left wondering why anyone would even bother with Qmail?

Re:pdf?

[Anonymous Coward]

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

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

qmail in the public domain?

[sekra]

According to one of DJB's slides it might happen this month that qmail will be placed into public domain. I hope this will become true as it might help qmail to get rid of its obsolescence.

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

[nuba]

vpopmail can be used with postfix

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.

Re:The patches make it still worthwhile

[rainer_d]

Well, and where are the commandline tools?
I only see a web-interface.

qmail and reiserfs

[MichaelSmith]

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:qmail and reiserfs

[ta bu shi da yu]

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

Re:qmail and reiserfs

[ta bu shi da yu]

If so... bug has been filed.

Re:qmail and reiserfs

[aproposofwhat]

I hope DJB's not married...

Re:qmail and reiserfs

[MichaelSmith]

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:qmail and reiserfs

[ta bu shi da yu]

Thought so. I just filed a bug about this one.

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:One of the most widely used ???

[inflex]

So... qmail is like the 'dark matter' of the internet - people postulate it's there but we can't directly detect it ;)

Re:One of the most widely used ???

[ElForesto]

The number of servers using a given software is not indicative of the volume they handle. I'd imagine that Yahoo! is probably accounting for a lot more than 0.17% of all e-mail traffic. Conversely, how many of those Exchange servers are installed on Small Business Server and handle maybe 5 accounts? Based on my own experience, I'd say a whole lot of them.

Re:One of the most widely used ???

[DavidTC]

I'm better that a lot of those sendmail installs aren't doing anything, either.

Re:One of the most widely used ???

[tokul]

So... qmail is like the 'dark matter' of the internet - people postulate it's there but we can't directly detect it ;)

You can detect it. Standard Qmail has very distinctive "relaying denied" and "max message size" error messages.

Re:One of the most widely used ???

[SuperBanana]

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.

They got their information by smoking crack; Postfix is hot the tail of sendmail, which is currently #1: http://www.porcupine.org/postfix-mirror/postfix-mailchannels.pdf

Qmail is damn well near the bottom, behind MXLogic, Exchange, Postini, Postfix, "other", "unknown", and Sendmail. Disclaimer: the survey represents fingerprinted public servers.

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?

[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: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:Qmail going public domain?

[bdowne01]

While I agree with the first four points, I have to disagree on the last. While the possibility his daemon might die is a valid one, having a wrapping process to watch it and restart it is just good admin practice. Sun obviously thought it was a good idea, since they've incorporated something almost identical in Solaris 10.

Re:Qmail going public domain?

[DavidTC]

Everyone who actually cares moved to postfix or exim a long time ago.

Re:Qmail going public domain?

[Antique Geekmeister]

I usually prefer to let it stay failed until an admin can find what broke it, especially with a good quality monitoring system in place. But that particular behavior of Dan's is not one I fault him for.

Re:Qmail going public domain?

[Bandman]

This sounds so familiar, almost like something I'd heard before many years ago....

Could it be inetd?

Re:Qmail going public domain?

[bdowne01]

That's because you're an admin. The better alternative is to notify of the failure and get it restarted immediately so the service can continue to be used by it's consumers?

Re:Qmail going public domain?

[bdowne01]

It's not the same; you're not familiar with how daemontools (or Sun's version) works. What happens if inetd dies?

Re:Qmail going public domain?

[fimbulvetr]

I've been a sysadmin for many years and can safely say that _never_ once in all my jobs on all of my systems has a processed *just died* and was capable of being restarted while dismissing the reasons it died in the first place.

In fact, many times restarting the job without human intervention would have led to some pretty serious consequences.

In all, if you have a process dying - shouldn't you be looking at why it's dying and not how to restart it?

Re:Qmail going public domain?

[bdowne01]

It happens. Just like car accidents and lotteries. But, for some reason, these conversations always focus on the process "just dying", which admittedly isn't often. What often happens more is when someone accidentally kills a really important daemon, like SSHD, and your server is 3000 miles away. That's the idea.

Notify and restart.

Re:Qmail going public domain?

[Antique Geekmeister]

It depends on the service and the response time. If a daemon like SSHD fails, for example, I want to know why it happened before I restart that daemon. Same for MySQL or Postgres: I want to know what slapped them down before I restart that service, because restarting it may corrupt data even worse. Similarly, for DNS, I want changes to show up for new clients when I tell it to reload, not when the next client connects.

For some lightweight or only occasionally necessry processes with other built-in redundancies and fallback states, such as SMTP, it can make more sense to have them inetd managed. But then you can use xinetd for most of those, which Dan apparently dislikes.

Re:Qmail going public domain?

[bdowne01]

I must be just too busy to be that picky about it. For instance, pretend you're a one-man shop with four dozen servers a datacenter couple thousand miles away. Those little things (in particular your SSHD example) can be the difference between making money and spending money. In fact, without some level of automation like that I'd be willing to boast it's nearly impossible.

My repetitive mantra in this series of threads is "notify and restart". That way you can look into it when you can, and not have to. As I mentioned elsewhere as well, the "just died" scenario admittedly doesn't happen very often, but what does is accidentally doing something like that. SSHD again, would be a prime example.

Re:Qmail going public domain?

[Antique Geekmeister]

For what you describe, I'd use a remote console, not an auto-restart. But as long as the notification is included, I can see where a restart is reasonable. But if that auto-restart simply grunds the spilled entrails of the failed service deeper into the system, I'm extremely unhappy with such assertive auto-restart sytems as Mr. Bernstein's daemontools.

Re:Qmail going public domain?

[fimbulvetr]

Again, it seems to me if you have someone with the ability to kill sshd on your server, killing sshd on your server, your problems lie elsewhere then "
Man I really wish I had some automated way of restarting that when my retardard brother billo kills it using sudo".

Re:Qmail going public domain?

[kashani]

No, it's true. qmail was fantastic in '97 and around '99 or '00 was probably the peak in major installs. Around '02 most of your major MTAs has surpassed qmail in functionality, performance, and ease of use. Yes even Sendmail. I switched to Postfix and find it superior in every way to software that has not changed since May '98.

kashani

Re:Qmail going public domain?

[gullevek]

Thats a fact? At least for me. I gave up on qmail a long time ago ...

Re:Qmail going public domain?

[Bandman]

I've got it! We'll run ANOTHER inetd, to save that one! //turtles all the way down

Re:Qmail going public domain?

[bdowne01]

No, that is not it either. Init spawns svscan, which monitors the service. If svscan dies, it's respawned by init. If init dies, you have other problems. It's really not as convoluted as you're making it sound. Sun Microsystems--a company of some really smart engineers--literally duplicated this system almost exactly in Solaris 10. The command to manage it is literally one character off (svc vs. svcs). It's a good idea (tm).

Re:Qmail going public domain?

[Paul Crowley]

That's great news! It isn't anywhere in the PDF btw - you may owe an apology to a Slashdot poster. Thanks!

Re:Qmail going public domain?

[andi75]

I once hopped into the car to drive to a site after typing

# /sbin/ifconfig eth1 down

Upps, I wanted to shut down eth0 instead (eth1 was the connection to the outside world...). Turns out the old 'think before you type' advice from sudo is actually good. Oh, and I never made that (or a similiar) mistake again (so far...).

Re:Qmail going public domain?

[Bandman]

In my experience, random service blockages (whether the daemon dies or not) are caused by bounds exceptions; things like running out of disk space, crossing a "too many processes" line, or something similar. My problem has never been another admin randomly killing things, but my enviornment may be different than many. I run ~ 80 linux servers throughout 4 data centers, but I'm one of two admins.

Re:Qmail going public domain?

[splutty]

Following your idea of administrating machines, you invalidate all currently running clusters.

Remember that in a production environment, it's often a *lot* more important to get something back up and running than it is to find out what went wrong *before* you restart it. With good monitoring (that's where you're absolutely right), you should be able to analyze afterwards what has gone wrong, then copy everything to a QA or D/T environment, and try to recreate the same circumstances to make it fail again.

At no point in time should the human factor be a limit to whether a production environment is up or not (arguably, most of the time this is not the case, but as a good admin you'll try to minimize this as much as possible)

Re:Qmail going public domain?

[Bandman]

Definitely an argument for out-of-bounds administration if I've heard one (and I've been there. /etc/init.d/networking restart while ssh'd in is not a good idea (although if you do it while in a 'screen' session, it works fine)).

Re:Qmail going public domain?

[vidarh]

I'm not worrying if svscan will die either. It's never happened to me, in years of production use on tens of servers. However, the difference between daemontools and inetd is that daemontools can monitor running and logging of any type of service, while inetd is just for handling network connections, and provides tools for managing the various services and check their status.

Re:Qmail going public domain?

[fimbulvetr]

A properly configured cluster would demote failed server/service from the cluster until repromoted. If your db instance failed due to a transient disk problem, would you really want it to bounce?

If your apache server was failing due to a segfault (Either misconfigured or bad module, etc) where said module was only used on the last page (Say CURL or something for authorize.net) and it was one of ten servers in the cluster, would you want a daemon to keep bringing the service back up so 1/10 of purchasing customers would receive a page cannot be found error when their CC was being authorized?

If your mail server had misconfigured permissions on a vital directory and died when trying to write to said directory, thus rejecting the message and ultimately dying again, would you really want 1/X servers bouncing messages due to disk full? Fuck no. Let the other 9 servers handle it, that's why you have 9 more - remember?

Re:Qmail going public domain?

[fimbulvetr]

Quote:

Remember that in a production environment, it's often a *lot* more important to get something back up and running than it is to find out what went wrong *before* you restart it.

Also, this is absolutely wrong. As a sysadmin your number one goal is to NOT LOSE DATA. Your number two goal should be to make sure the system isn't down. Your third goal should be to make sure no portion of the system is down. All in that order.

With a malfunctioning server posing as a server running at 100% ability, you are subjecting your self to data loss AND the perception that the system is down.

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.

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

Re:Secure programming by DJB

[myowntrueself]

and offer a prize for successful hack of your software.

And when someone does find a successful hack stick your fingers in your ears and yell LALALALALALAICANNOTHEARYOULALALALALA

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

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:I just love qmail

[MikeBabcock]

Although I appreciate your frustration, anyone who's worked both with and without init.d structures has been through this before.

That said, most qmail installations don't need restarting for any reason for many moons, so unless you were fiddling with it, or it was improperly configured in the first place (both not a fault of daemontools or qmail itself), then it probably isn't even relevant.

Re:I just love qmail

[Antique Geekmeister]

And refuses to document it. Don't forget that DJB's infamous "LOC" or lines of code tends to leave out things like documentation, configuration examples, software installers that put things in the right places, or his other bugaboo, "parsers" to pre-test the configuration files and make sure they're valid.

Re:I just love qmail

[rainer_d]

> Who buries a service startup in a combination of inittab and the /srv (?) directory?

Well, I hate it when someone starts daemontools from inittab.
I usually create a normal startupscript. The BSDs I use don't have inittab anyway.
The directory is called "service", in FreeBSD-land usually ln'ed to /var/service, where again the symlinks to the supervise-directories sit.
FreeBSD also has a plugin-mechanism for mail-related commands. If setup correctly, "mailq" calls qmail-qstat.
Obviously, your guy forgot to de-install the original MTA.

Re:I just love qmail

[merc]

I think you're really touching on my first issues with qmail, at least when I was new to qmail. Aside from what has already been discussed to death here (and rightfully so) about all of the patches required to get a functioning qmail system running I have always been frustrated by a lack of a centralized concise configuration system.

Too much of qmail's runtime configuration is inconsistent. If you spawn qmail from inetd(8) then you need to wrap it with tcp-env and a bunch of other junk. If you use UCSPI then it's configured completely different. An inappropriate number of configuration options live in the form of obscure command-line switches and environment variables. I remember when I was new to qmail I spent 4 hours just trying to determine what version of qmail I was running.

I would like to throw a "thanks!" out there to websites like life-with-qmail and qmailrocks that document qmail to great lengths.

Re:I just love qmail

[myowntrueself]

and I hate anything touched by djb.

Including Maildir???

I have to say, despite his obvious insanity, the Maildir format was created in one of his, admittedly rare, lucid moments.

Re:I just love qmail

[NerveGas]

So.... don't use daemontools. You can start qmail from a regular init.d script just fine...

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

[deniable]

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

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

That would be too obvious and useful.

I too agree.

[www.sorehands.com]

I don't usually see much on real software development and design here (outside of book reviews).

While some of the things are "Duh!!" people don't think of it. Many of the metrics programmer skill is based on LOC and bugs per LOC. This type of metric is counterproductive. Articles on the subject correctly reward low bug count more than LOC. But none of this takes into account the efficiency of the code, therefore encourages slow code with no bugs, and lots of lines. He is right, I think some developers (including myself) have the tendency to microoptimize the interesting code.

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:security is paramount

[harmonica]

You can debate DJB's personal approach to security, but you cannot fault his priorities.

While his emphasis on security is commendable, the various problems with qmail (as others have pointed out) make it less or not at all usable. If the secure software isn't used, nobody wins. To put it differently, he places usability at such a low level that the security bonus of his software is outweighed. In the end, it does make his priorities appear questionable.

Re:security is paramount

[Sentry21]

secure system that doesn't do what needs to be done is worthless. Is qmail secure? Yes. Does it do what people need an MTA to do? No. Is it maintainable? No.

To me, qmail is akin to openBSD - secure by default, useless by default. The only difference is that with OpenBSD, it's easy to add 'functionality' via installing apps, whereas with qmail, you have to recompile every time you need a new feature, and doing so disclaims any guarantee of security.

Re:security is paramount

[larry bagina]

Anyway, if it was secure at any cost, why is is reliant on the OS providing that?

Read the PDF. In particular, the part about using OS protection mechanisms rather than reinventing the wheel.

Re:security is paramount

[RWarrior(fobw)]

> You can debate DJB's personal approach to security, but you cannot fault his priorities.

Concur. Even beyond that, there's still plenty to respect about the software as well, that many folks don't bother thinking about.

True, Dr. Berstein can be a screaming asshole at times. However, if you RTFA, you'll see that even screaming assholes can learn from their mistakes, and Dr. Berstein has learned from some of his -- even to the point of acknowledging that he was saved from one of his mistakes only by a lack of bugs.

True, his software operates in a fundamentally different way than most daemons you're used to dealing with. That doesn't make it bad or evil or stupid, merely different. On the other hand, if you can't handle things that are different, you shouldn't try to simultaneously administer Samba and Apache, since they're different from one another as well.

False, his software isn't "undocumented." There are excellent resources available on the net (and at your local bookstore) for the software. The fact that Dr. Berstein didn't write them doesn't mean they're not useful. When in doubt, consult eg thedjbway or qmail.org or LWQ (Dave Sill's excellent howto, which is actively supported on the mailing list) or LWDJBDNS.

True, the people on the mailing lists can seem to be assholes. However, it has been my experience that if I scrupulously adhere to ESR's suggestions on How To Ask Smart Questions, I get much more helpful responses than when I do not. On the occasions when I've needed to go to the mailing list for help, when I failed to be clear and intelligent, I got useless garbage back. When I ask intelligent questions, I get back answers that either tell me what the mistake I made was, or (more often) point me in the right direction so I can solve the problem myself. Sometimes, just writing the question up will reveal the problem to me. If you don't like that, it's not a flaw in the software -- it's a flaw in your thinking.

There are lots of reasons I use djb software, but the most important is this: Once it's set up, I can forget it. In seven years of running qmail, I've once had to seriously jack with it after getting it going, and on that occasion I can't say definitively the flaw was in qmail (but I can say definitively that the trigger was me and my not paying attention to the box). I've never had to update for a security hole for either qmail or djbdns. It is one less thing to have to jack with, and I have plenty of other things that need my attention.

Its FAR from secure

[Alan Doherty]

qmail gives the impression of security from a programatic standpoint, and was designed to be so. but unfortunatly wasn't designed for or by someone who understood the security needs/wants of a mail administrator or how those may change. otherwise it would never have been be one of the biggest contributers to backscatter {see end of http://en.wikipedia.org/wiki/Backscatter also security is seldom achieved through feature stripping which appears to be the case the fact it is still used by many non-proffessionals is a testiment more to its original and ongoing hype and buy-in to the myth by the uninformed

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:qmail is not suitable for use

[XanC]

Could you explain what's spam-supporting about callbacks?

Re:qmail is not suitable for use

[Kazin]

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. Sure, you may not like Qmail. But your arguments lose strength when you suggest that sendmail is superior. I'm laughing right now.

Re:qmail is not suitable for use

[wikinerd]

qmail be avoided in favor of superior packages such as sendmail, postfix, and exim

Can't see any reason to use sendmail when postfix and exim are available.

qmail. 10 years and still in beta

[ThirdPrize]

oops! thats gmail.

Of course it's secure

[nmg196]

Of course it's secure - it hardly does anything. To even get the most rudimentary features a mail server needs to have, you have to patch the living daylights out of it and link it up with loads of third party software. You end up losing the security anyway when you add these features. It's not a usable mail server in it's native form for most companies - it's just far too basic and takes too long to configure for most real-world setups.

Look at how much extra stuff and TIME it takes to get a small qmail based mail server usable:

http://www.qmailrocks.org/install_rh.htm

I got a comparable Windows based server up and running in under 20 minutes. Try doing that with qmail.

Once again, it's only free if your time has no value.

Re:Of course it's secure

[beheaderaswp]

I knew there would be a day when a Windows MTA would be compared to Qmail. I didn't think I'd live to see it- but I knew it would happen.

Let's forget for a moment that Qmail (or sendmail/postfix) takes a long time to setup.

And let's remember that in the big-dog multi domain server world, a Windows server fails.

It takes me a about a day (with testing and hardware verification) to get a traditional MTA up and running for multi domain use- complete with on the fly virus scanning and spam filtering (at zero software cost). Draw your own conclusion Vs. "Uptime".

But in reality, I often question the sanity of admins who use Qmail since I can't rationalize wanting to live that "close to the code". It's not 1997 anymore, and there are huge swaths of FOSS which have sufficient Q&A to get the job done. Working from source, which is an excellent skill, certainly doesn't garner the advantages it once did.

So in essence your comparing "Current Crap (Windows)" to "Oldish Crap (Qmail)" and declaring a winner. Fine.

But the time payoff comes from the machine being up for a year without incident- not the install time.

If you are worried about install time, I've got a copy of ASIP Server V5 around here somewhere- it will install in about 5 minutes. Just don't plug it into *anything*.

Re:Of course it's secure

[nmg196]

> And let's remember that in the big-dog multi domain server world, a Windows server fails.

Er no! It certainly doesn't. Millions of companies use Windows mail servers with no problems or complaints. It's only linux fanboys that think that Windows keeps crashing. Usually that's because they don't actually use it themselves and don't really have a clue if it crashes often or not. Personally, I've never seen a blue screen of death in my entire life. I've never had to reboot a server because it's just crashed (except for our one Linux box, which runs out of RAM every few weeks for reasons that not even RedHat are able to tell us). Even my Vista workstation hasn't been rebooted for three weeks (and even that was only so I could flash my RAID controller BIOS).

> So in essence your comparing "Current Crap (Windows)"

It's spelt "you're". Why do people stop taking English after the age of 8.

I'm not comparing any Windows "Crap". The mail server software I use on Windows is FAR from crap (no I'm not talking about Exchange). You're assuming the software I'm using is crap without even knowing what it is!

> But the time payoff comes from the machine being up for a year without incident- not the install time.

The only linux boxes I've seen which have uptimes of a year, are unmaintained ones which aren't being used. How can you patch a kernel without rebooting the machine? I've NEVER EVER seen a modern Windows server crash or lock up. The only reason my servers ever go down is because I've told them to. I think you're thinking of Windows 3.1 from 10 years ago which admittedly crashed fairly often.

Re:Of course it's secure

[beheaderaswp]

Well not to enter into a personal discourse...

And your nit picky spelling issues aside.

1. I happen to admin 6 Windows Server 2003 boxes.

And....

2. I have gone a year where the *nix KERNEL didn't need an upgrade against the machine's application. Assuming the KERNEL update wasn't needed- no reboot. There's no reason to patch for local security issues on a mail server that only allows hardware terminal access (Aside from SMTP). Especially where uptime issues are considered. Additionally, I actually READ the patch notes and patch where appropriate- you apparently just download stuff and put it on "you're" (just for fun!) machine.

And....

3. If you've never seen Windows Server 2003 bluescreen- you haven't been running it. Seriously? What kind of fanboi are you? I never claimed to never have a kernel panic on a UNIX box. In "your" (fun fun) whole life you've never seen a bluescreen?

And you are right- millions of companies do use Microsoft technologies. Millions of ISP's and infrastructure providers DO NOT. The idea that an MS server is up to snuff for multi-domain (in the hundreds) mail service, core routing, or security/security appliance use is just inane. Additionally, the idea that the MS technologies are close enough to RFC is just as ignorant.

But going back to the original point. You compared MS Server 2003 to Qmail. Both are crap (for various and sometimes different reasons), the MS server doesn't scale well, Exchange is an (sometimes) undocumented mess, and the registry when messed up takes down whole *machines* since all that config info is in the same place.

So my dear, British, photo retouching friend what was your point?

There are many reasons a company might choose a Windows server for their e-mail. But they are not ISVs/ISPs.

Apparently- your not on the big iron either... So you are forgiven.

Re:Of course it's secure

[Creepy Crawler]

> And let's remember that in the big-dog multi domain server world, a Windows server fails.

---Er no! It certainly doesn't. Millions of companies use Windows mail servers with no problems or complaints. It's only linux fanboys that think that Windows keeps crashing. Usually that's because they don't actually use it themselves and don't really have a clue if it crashes often or not. Personally, I've never seen a blue screen of death in my entire life. I've never had to reboot a server because it's just crashed (except for our one Linux box, which runs out of RAM every few weeks for reasons that not even RedHat are able to tell us). Even my Vista workstation hasn't been rebooted for three weeks (and even that was only so I could flash my RAID controller BIOS).

There is a major problem with Windows and Microsoft that you do not talk about: licensing for a server. Good luck dealing with the cost for 100 people on a domain, with mail server. And if you accept the corporate agreement, you accept that the BSA goons can invade your business. As a case study, look at that guitar string manufacturer in northern Indiana.

Also, what is an experienced admin (I assume you are either that, or a consultant) using Vista on your work computer? Most Windows admins I know run 2k for getting the job done, or XP for some game compatibility (ahem). None that I know would touch Vista, and have outright told companies that getting it would be ruinious.

However, I can perfectly understand running Vista in a virtual computer environment, or an el-cheapo machine from Circuit City. We do need to keep up on the times, even if we do not agree with it. How else can we make proper assessments without looking at it? I'm just frankly shocked that you are running it in a corporate environment (where else would you run a workstation?).

And about that Linux issue, have you upgraded your kernel? That sounds surely a memory leak vs the kernel. Try recompiling the kernel using what's on Kernel.org . It's been well known that Red Hat adds a lot more in than the standard kernel. If not, try recompiling the server daemons you commonly use vs lint.

Frankly, there's no reason why a Linux machine needs rebooting every 3-4 weeks. Thats what we see in the Windows world far more often. Do a little footwork and you can turn 3-4 weeks to 3-4 years.

> So in essence your comparing "Current Crap (Windows)"

---It's spelt "you're". Why do people stop taking English after the age of 8.

If the grammar is the most you can point out, it must have been a rather sturdy statement.

---I'm not comparing any Windows "Crap". The mail server software I use on Windows is FAR from crap (no I'm not talking about Exchange). You're assuming the software I'm using is crap without even knowing what it is!

SInce you did not state what mail server you DO use, what have we to expect but Exchange? That is the de-facto standard for Windows Server installations.

---The only linux boxes I've seen which have uptimes of a year, are unmaintained ones which aren't being used. How can you patch a kernel without rebooting the machine? I've NEVER EVER seen a modern Windows server crash or lock up. The only reason my servers ever go down is because I've told them to. I think you're thinking of Windows 3.1 from 10 years ago which admittedly crashed fairly often.

I think we can come to a consensus on this issue concerning servers: Graphical display code is inherently unstable. Remote graphical interfaces take a magnatude more bandwidth than an interactive text based interface. Why are you using servers that will not function if the graphical subsystem fails to init, or crashes due to a Admin based bug from 3rd party software?

I use Linux and FreeBSD because I can rely on a single program doing that one thing well. I can then separate those processes so a Linux/BSD machine will run 5 "apps" for every Windows based machine. If I use Xen, I could separate those processes further by virtual computer rather than a

Re:Of course it's secure

[Abcd1234]

There's no reason to patch for local security issues on a mail server that only allows hardware terminal access (Aside from SMTP).

Well that's just silly. All you need is one remote exploit that gives a user access to a non-privileged shell, and you're boned. Local exploits are only local as long as there are no remote exploits...

Re:Of course it's secure

[attributed insanity]

In "your" (fun fun) whole life

You win points for irony: you accidently got it right. "You're" is a contraction of "you are", and is what you should have put here to annoy the GP. "Your" denotes possession, and his whole life *is* his.

Re:Of course it's secure

[beheaderaswp]

Yea ok...

It's only silly if you have no idea what your code is *doing*.

If your mail daemon is the only exposed service, fixing a kernel bug having to do with wget isn't going to solve anything. A successful buffer overflow against sendmail is going to allow arbitrary remote code execution anyway. Fixing a kernel problem related to "X" when sendmail uses "Y" doesn't = justification for a kernel update.

If uptime is the premium, and you cannot afford to make code changes because of an impending kernel update, you leave the kernel update until it *does* something effective for you.

But of course your knowledge base has to extend past "yum update". Perhaps if I only had *one* server to maintain I might dump every software update on the planet onto it (regardless of whether I need them or not). But with over 50 servers, some running exotic code? No way. Kernel replacements are stressful to administrators. You do them when you have to. In fact in the "old days" most update tools left the kernel out of the upgrade tools for exactly that reason.

Thus, you have to understand what your code is doing. Of course this relates to kernel updates only (as I've mentioned). Updates on other binaries are mandatory.

Besides- I can promise you this... if the hacker gets to the point where thy can remotely execute code via a sendmail buffer overflow- the box is toast anyway... right?

Are ya really gonna leave a half hacked box in service?

See what I mean?

Re:Of course it's secure

[beheaderaswp]

Personally I'm glad his whole life, and his Windows servers are his.

I don't want either of them.

Re:Of course it's secure

[Abcd1234]

A successful buffer overflow against sendmail is going to allow arbitrary remote code execution anyway.

Sure, but the point is a buffer overflow in sendmail may only get you local, non-privileged access (obviously this depends on your configuration... OTOH, I would *hope* you're smart enough to have your public-facing services running as non-privileged users). But once you're there, all you need is a local privilege escalation bug for your box to be fully compromised.

Of course, it's up to you to judge the odds of this happening. But the idea that a local compromise is only a danger if you can gain access to the console is simply naive.

Re:Of course it's secure

[beheaderaswp]

You're missing the point.

The box comes offline at the buffer overflow attack- NOT the privileged compromise!

Apparently my reading of this is that it's ok with you for a remote attacker to get unprivileged shell access- and secure it from there. Sorry. Whatever happened to detecting/correcting the buffer overflow in the service?

Do you seriously leave a box online with a buffer overflow issue? Besides- if they are going to get shell access (unpriv) the box is toast anyway? Right?

Not to be an ass here, but I'll assume for the moment that we both, you and I, have perfect security records (which thus far is true for me), and differing views on security. In that context I'd not find my comments either naive nor silly.

Re:Of course it's secure

[atamido]

There is a major problem with Windows and Microsoft that you do not talk about: licensing for a server. Good luck dealing with the cost for 100 people on a domain, with mail server.

Yeah, you're going to need some deep pockets to set up a very large multi-domain Exchange system. Of course, the only people that do that are large corporations, and that kind of money is chump change to them. Of course, it does completely marry them to Outlook/Active Directory/Windows, but that's pretty standard for large corporations anyway. (The seamless integration is pretty spectacular, with the drawback being vendor lockin.)

In a 200 person organization, that only needs email and none of the other features in Exchange/Outlook (do these exist?) you could set up just Qmail, or some other free solution for for much cheaper, and have a single admin that administers it and many other things. The problem is that when that admin leaves, good luck finding a person qualified to take his place. Exchange admins are easy to find, and easy to train, so long term costs can actually end up being lower with Exchange.

Also, what is an experienced admin (I assume you are either that, or a consultant) using Vista on your work computer? Most Windows admins I know run 2k for getting the job done, or XP for some game compatibility (ahem). None that I know would touch Vista, and have outright told companies that getting it would be ruinious.

If you have a single laptop in your organization, the updated wireless alone is reason to migrate to XP. Everyone has their preferences, but unless you're trying to nurse old hardware, XP has a number of benefits. Vista, however... Well, I don't think anything else negative needs to be said about it, so I will point out the one always overlooked benefit: Resolution independent scaling. Finally, 10cm of desktop space can be the same if you're running a 24" or 17" display at 1920x1200. No more squinting from text being super tiny, or screwed up windows from improper scaling. If they hadn't screwed up every other part of the OS, this would be a huge selling point. As it is, we are crossing our fingers for SP1 to unscrew things.

I think we can come to a consensus on this issue concerning servers: Graphical display code is inherently unstable. Remote graphical interfaces take a magnatude more bandwidth than an interactive text based interface. Why are you using servers that will not function if the graphical subsystem fails to init, or crashes due to a Admin based bug from 3rd party software?

I'm reasonably sure I haven't seen a 2003 box blue screen either. I have seen an application take over to the point that it is essentially locked, and I've had it hang on shutdown (presumably from a rogue process). I've also had Linux do the same thing, so I can't really complain.

I haven't seen many server apps that force some sort of GUI window to run, although they typically have a GUI configuration screen. I've had the GUI configuration screen lock up, but that doesn't take down the app or the system itself. Still, for latency sensitive applications like VoIP, you don't want a GUI mucking about. I assume this is one of the main reasons that Windows Server 2008 will have a GUI-less version. Personally, I wish Windows had been designed around the idea of connection via SSH to do command line configurations, but things mostly work as is.

Anyway, back on topic. Qmail sounds great for ISP level things. For corporate, I'd go Exchange 2007. For personal, there are too many options to list.

Re:Of course it's secure

[Abcd1234]

The box comes offline at the buffer overflow attack- NOT the privileged compromise!

When? How? Are you omnipotent? What makes you believe you can catch a non-privileged remote exploit before a local privilege escalation allows the attack to cover their tracks?

Basically, you're assuming you are a) plugging all remote exploit holes before an attacker has a chance to use them, and b) that, in the case of an exploit, you'll be able to catch it right away. Neither of these is, in my mind, a reasonable assumption.

So, running under the assumption that a remote exploit may happen, and that you may not immediately notice, it seems prudent to patch any local privilege escalation exploits, as well.

Re:Of course it's secure

[PitaBred]

Yeah... my fiancee used to work for one of the largest hosted Exchange providers in the world. Their exchange servers were a constant bane, and needed constant surveillance and maintenance, especially compared to their UNIX hosted offerings. Just because it DOES happen doesn't mean that large Windows-based server deployments are a good thing.

Re:Of course it's secure

[petermgreen]

A successful buffer overflow against sendmail is going to allow arbitrary remote code execution anyway
Indeed if you are using sendmail which does pretty much everything as root afaict then once they have broken sendmail your box is rooted anyway. IMO this is a good reason not to use sendmail.

more modern mail soloutions split the mail handling into multiple processes running with different privilages. If the user exploits a low privilage part and there are no local root exploits avilible the damage is limited. If there are local root exploits avilible then your box is rooted.

No software is perfect so the smart designer designs to limit the damage when a flaw is found. That means sensible privilage seperation in apps and making sure the machines running those apps don't have local root holes that will negate the benifit of the privilage seperation.

Besides- I can promise you this... if the hacker gets to the point where thy can remotely execute code via a sendmail buffer overflow- the box is toast anyway... right?
Once a user gets root it becomes much easier for them to both do damage not limited to the mail transport service (e.g. mess with users mailboxes or attack your network with a mac flood so it can start sniffing) and to cover thier tracks.

Re:qmail and \n

[tomstdenis]

It's part of the specs I reckon, check out the HTTP specs, same deal. You can't just send \n\n for two lines.

djbrocks

[main()]

I have to say I am sad to see so many negative reactions to djb and his software.

I'm not sure where the accusations of arrogance against Bernstein come from. I've never met the guy but having studied his code I would say, if anything, his programming style exudes humility. He doesn't trust client software, he doesn't trust the standard libraries and he doesn't trust himself. I think if you look closely at his "style" (for want of a better word) you will find a lot worth emulating.

Personally, I still use qmail and tinydns on my own boxes, where appropriate. At work I don't have any problem recommending his software either and have used qmail for projects relaying over 8 million messages a day without issue. Saying it "doesn't scale" is, in my opinion, untrue. Or at least misleading.

Anyway, djb, I for one salute you!

Si

Re:djbrocks

[ohtani]

His arrogance comes from his "I'm right you're wrong" attitude. Look at EVERYTHING he talks about. It's not even at the point of not trusting, it's at the point where he's simply bashing other pieces of software. He implements things like a one man version of Microsoft: his way, yet claims it's the standard.

Re:djbrocks

[rs79]

"I have to say I am sad to see so many negative reactions to djb and his software. "

I don't get it either. When I think of the history and my experiences with say, BIND and Sendmail I just shudder. I installed djbdns and qmail and while I'll admit it takes a but of time to get used to the way djb does things, ever since they've been installed they run so well it's just not funny. I never had to patch anything and it seems to work for tens of thousands or messages for various mailing lists a day

I've had minor conversations with djb ever since he was a grad student and he's always been polite. I've never asked him a stupid question though.

The security record is impressive and unique. For all the people who bitch and complain I say "lemme see your popular internet daemon code you wrote and its security record".

Look in the mirror, then ask yourself "is there a chance I'm being an unaccomplished whiney wanker?"

Re:djbrocks

[DavidTC]

...his programming style exudes humility. He doesn't trust client software, he doesn't trust the standard libraries...

Hey, lunatic, not trusting other people is not humility. It is often the opposite of humility, in that you are convinced you can do better than them.

Re:djbrocks

[vic-traill]

I have to say I am sad to see so many negative reactions to djb and his software.

Agreed. DJB is, in my experience of reading his USENET postings and documentation, certainly assertive in his writing, but the man is damn thorough and quite thoughtful. He's also prepared to argue his position at length and with plenty of vigour (to say the least) and this can piss people off.

I won't speak for anyone's experience with qmail other than my own; I converted a number of sendmail and mmdf (the MTA delivered with the SCO TCP/IP component about 12+ years ago, and an ancestor of pmdf) installations to qmail and I didn't find the setup particularly onerous or the documentation problematic, and there are lots of admins smarter and better than me out there. I will say that djb's docs have their own style and require a bit of getting used to, but this is the same reaction I've seen in many people the first time they've encountered a man page.

It's been a long time since I've admin'd an MTA, so I can't speak to setting up contemporary postfix or similar, but I can tell you that qmail was a blessing for me at the time, and I grabbed it and ran away from sendmail as quickly as I could. Even if you didn't like djb's security model, you couldn't deny that he had one, and that he applied it rigourously in the development of software. This was not my experience with sendmail.

Complaints about the number of required patches to qmail do resonate for me; my own feeling is that qmail suffered from a lack of author attention once the main development cycle(s) ended. This, combined with license restrictions, made it hard for qmail to evolve.

I've never read anything from djb that didn't make me stop and think. I admire him and his contributions; he doesn't just talk - he's a helluva walker as well.

Re:djbrocks

[wikinerd]

Hey, lunatic, not trusting other people is not humility. It is often the opposite of humility, in that you are convinced you can do better than them.

And do you think that this is a bad thing?

Re:djbrocks

[DavidTC]

I said it wasn't humility, not that it was good or bad.

Jeez, do people not actually read posts anymore before responding to them?

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:Postfix makes for a good read

[rs79]

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

Never mind the cert advisories against postfix.

You pick your priorities. Say what you will people do manage to find djb's tools useful and they're flawless in terms of security. Claim the prize and then we'll talk...

Re:Postfix makes for a good read

[PitaBred]

main() {
        printf("hello, world");
}

Is also flawlessly secure. Pretty useless though, just like Qmail. He won't fix bugs or mis-features in the software, which means that it's a perfectly secure, useless bit of software unless you only want to do something trivial with it. Do anything more, and you have to start patching it manually, which makes Postfix and it's CERT advisories a much better option than an unvalidated, third-party patch conglomeration tacked on to Qmail.

Re:Postfix makes for a good read

[Ice Station Zebra]

Yes, we really need an MTA that can connect to multiple databases. You never know when I will want my email connected up to my Oracle Peoplesoft database to automatically generate a bill everytime somebody spams me.

Re:File system layout standards

[sqldr]

If djb worked at a fire station:

Caller: my house is on fire!

DJB: your sprinkler system is configured wrong *click*

Extreme jail?

[IkeTo]

> Imagine running the jpegtopnm program in an "extreme
> sandbox" that doesn't let the program do anything other
> than read the JPEG le from standard input, write the
> bitmap to standard output, and allocate a limited amount of
> memory. Existing UNIX tools make this sandbox tolerably
> easy for root to create:
> ... (working on RLIMITs, do chroot, fork, setuid, etc etc)

Hm... even if not allowing the program to reuse the filesystem and other programs in the system is tolerable, it doesn't sound like a good idea that a program that want to *lower* its privilege has to run as root. If nothing else, the system administrators will probably go mad staring at all those suid root programs (much more mad than all the non-standard procedures needed to run the current programs of djb indeed). Unluckily for all of us, POSIX-compliant Unix is still the way to go. I expect that an "extreme sandbox" would be much easier to build (and much more useful!) with a system like Hurd, only that it won't be ready for use outside the Hurd developers' spare PC in any foreseeable future.

Re:Extreme jail?

[Creepy Crawler]

A FreeBSD jail does almost what you ask for. It can shut off kernel commands from the get-go, stop root progression, eliminate fs mounting tricks as seen in Linux chroot, and many other nasties. In the security modes, then we get into apphend-only files and not being able to mount kernel structures.

It really gets "nasty" for the hackers.

Re:Extreme jail?

[Russ Nelson]

I think the idea is that the program which runs jpegtopnm sets up the sandbox. But djb is pointing in the direction of "Change Unix so it's easier to drop privileges."

Re:qmail security holes

[illuminatedwax]

Oops, there's the mention of it buried in the paper. Thanks for letting me edit my comments Slashdot

rediffmail

[Russ Nelson]

Rediffmail uses qmail. 60M users and counting.

Sorry to say...

[Inoshiro]

Sounds like someone has a bad MUA behind their MTA. Upgrade to Cyrus IMAP. It's very smart and culls duplicates by message ID with a sliding window, tunable by the administrator.

This MTA behaviour is, like it or not, the correct behaviour at the MTA level. Postfix (my secure MTA choice for the past 9 years, and [IMO] a far superior one to Qmail) behaves identically regarding duplicates, as does every other MTA I've looked at. I wouldn't be surprised if this was written up in an RFC on SMTP as the correct behaviour.

Now if we're going to talk about incorrect behaviour, we should all jump on the 10.5.0 finder which is completely non-spatial!

Re:Sorry to say...

[DavidTC]

This MTA behaviour is, like it or not, the correct behaviour at the MTA level. Postfix (my secure MTA choice for the past 9 years, and [IMO] a far superior one to Qmail) behaves identically regarding duplicates, as does every other MTA I've looked at. I wouldn't be surprised if this was written up in an RFC on SMTP as the correct behaviour.

No it doesn't, and no it isn't. If postfix is handed one message, it will only hand that message to a person once, no matter how many times they end up in the expanded aliases.

qmail, IIRC, will expand each alias and remove duplicates from each alias, but if you address it to multiple aliases and those aliases include duplicate addresses, it will not remove them between aliases.

I.e., if you have a admin@example.com and an users@example.com, and they both contain some repeated addresses, mail sent to one of them will be correct, everyone gets one copy. If you have an everyone@example.com that contains both admin and users, and someone sends mail to everyone@example.com and users@example.com, everyone in users gets two copies.

This is probably because qmail is 'secure', which apparently means 'broken up into tiny pieces that talk poorly to each other', so it's probably breaking the mail up at RCPT level and parsing the two 'messages' separately.

Now, between mail servers, this can happen anyway, as you have no way to ensure that two RCPTs for a single message are handed to the same server at once, instead of the message being broken in half. But normally within the same mail server that doesn't happen, except, apparently, with qmail.

Oblig.?

[Ajaxamander]

http://bash.org/?7565

Huh

[localman]

I'm kinda surprised by all the complaining in this thread. Here's a very competent software engineer who created several highly secure and useful applications that we can all use for free, and he's giving us his retrospective thoughts on the engineering choices and...

Everyone is posting "djb sucks" and such? What a bunch of useless pricks we can be.

DJB - thanks for qmail. It's odd but pretty cool and has never fucked up my system. And I found the paper pretty interesting.

Cheers.

Re:Huh

[rs79]

"Here's a very competent software engineer who created several highly secure and useful applications "

He's not a software engineer, he's a math professor who write code for fun.

The software engineers are the ones who wrote the other daemons. The ones that have cert advisories against them.

Re:Huh

[localman]

Fair enough, though I would personally give someone who's produced what he does the honorary title of "software engineer" (if indeed that is a compliment).

Of course, I consider myself a software engineer and I'm just some dude who learned to hack Perl and Java on his own time for the web :)

Cheers.

Re:Is a sandbox a security solution?

[SuiteSisterMary]

Way to take a single line out of context. You should point out that the chroot is one step out of five or six or so.

Re:qmail security holes

[Russ Nelson]

I'm really disappointed that you didn't read TFA. "Example where qmail did badly: integer arithmetic."

Re:Help!

[bytesex]

No. Just give us her phone number and I'll see to it.

Re:File system layout standards

[Russ Nelson]

What if the file system layout standards are wrong? For example, the same piece of software can have two different installation locations: /usr and /usr/local depending on who compiled it. That's just wrong.

hating on the principle of least privilege?

[CoughDropAddict]

DJB makes an unusual and somewhat extreme claim in this paper: he says that the Principle of least privilege is "fundamentally wrong." I thought this was a strange thing for a security person to say, and I wrote a blog entry explaining why I think he's overreacting.

Re:hating on the principle of least privilege?

[nuzak]

I find his disparagement of POLA (Principle Of Least Authority, which is what it's usually called) somewhat puzzling, considering that his whole notion of reducing the TCB and all the unix syscalls he goes through to sandbox a process are pretty much the same thing.

It seems to me that DJB has been in academia too long, since he seems completely ignorant of modern OS facilities like mandatory access control, random number generation, and even the fact that directory access isn't O(n) on many filesystems these days. Of course qmail couldn't count on the existence of any of these back then, but to not even mention them now, even in passing, is somewhat telling.

DJB in section 5.2 doesn't even plug all the potential holes, as there could be more or less of them depending on the platform you're on. And of course, the sandboxing with all the chroot'ing and seteuid'ing and so forth has to run as root to start with, whereas a proper MAC implementation can impose a restrictive security context on any process without needing escalated privileges to start, nor needing to laboriously duplicate this byzantine security context setup with every process.

DJB is no dummy, but he's definitely not the Knuth of security either.

daemontools is awesome

[Nicolas MONNET]

And on my systems, svscan is started by svscan-boot from rc.local.

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:Is a sandbox a security solution?

[merc]

This is just my opinion of course, but what I think Alan was trying to say is that chroot(2) environments are no replacement for well-written, regression-tested peer reviewed software, nor a substitute for well-defined security policies and procedures. However I still love the risk mitigation that chroot environments provide.

It's like locking your car or the door to your house at night. It wouldn't prevent a determined intruder (although perhaps it could), but it's better than not using the feature at all. Nonetheless I would agree that if it gives you a false sense of security that's not good either.

Re:Secure? Ha.

[thanosk]

Of god.. of course it supports TLS. For heaven's sake do you research before flaming something but what am I thinking this is /. ... noone does that

Re:Is a sandbox a security solution?

[Chirs]

Alan's comment related to a discussion where the process in the chrooted environment still had root privileges. In the example in the article, the process also drops privileges and so cannot call chroot() to get back out of the jail.

Backscatter

[Slashdot Parent]

This is my biggest complaint about qmail, and I wish I had mod points right now.

You should see the hoops I had to jump through in order to convince qmail to reject spams/viruses during the SMTP session. It can be accomplished with qmail-qfilter, but it ain't pretty.

The problem is, I only run a personal mail server, and I haven't yet found another MTA that is as simple as qmail. This is a low priority for me, so I don't want to spend hours learning a new MTA.

Do you have a recommendation for a simple MTA that integrates well with clamav and spamassassin?

Re:Backscatter

[bdowne01]

We (I mean our company) use a drop-in replacement for qmail-smtpd called magic-smtpd. It lets you do exactly what you're looking to do. We also wrote some custom scripts against vpopmail to drop smtp sessions for invalid addresses during the conversation. Let me know if you're interested in it.

Re:Backscatter

[DavidTC]

Postfix and amavisd together do just fine.

And therein lies the problem

[A nonymous Coward]

Seems like everybody and his dog has a patchset for qmail. Unfortunately, many of them conflict with each other. Patchset A solves problems 1, 7, and 12, patchset B solves, 2,7 and 12, patchset C solves 1 and 15. You want to solve problems 1 and 7, but don't want the fixes for 12 or 15. Or you want A's fix for problem 7 but B's fix for problem 12.

Qmail was great in its day, but that day has come and gone. Maybe the public domaining of qmail will allow it to be distributed properly and make it viable again.

Re:And therein lies the problem

[mrjackson2000]

Thats whats nice with Johns patch set, he combines them all and makes sure they all play nice together. If there is one that he doesnt have he will add it if he finds it at all useful.

Re:And therein lies the problem

[Ice Station Zebra]

But doesn't everybody want to modify qmail and redistribute it in binary form? You'd think they would know how to fix conflicting patches easily enough.

Re:And therein lies the problem

[A nonymous Coward]

Yes, you might think that. The kernel doesn't have this problem except for a few bleeding edge people pulling right out of the test sources. Apache, gcc, nope, no problems there. But qmail has it, and I know of no other so-called stable release (ten years!) with this kind of problem.

That's EXACTLY what's wrong with John's patch set

[A nonymous Coward]

Who says I like ALL of the patches he chose? Suppose the patch he chose of the several that solve the same problem has side effects that I don't want, or that solves it in a manner I don't want.

The more patches lumped together, the greater the odds there will be something in it that is wrong for any arbitrary situation.

And if you don't lump them together, the greater the odds that they will conflict.

THAT is what is wrong with qmail's patch mentality.

Re:File system layout standards

[Wdomburg]

Putting executables under /var is "wrong". Relocatable installation is a feature.

Re:That's EXACTLY what's wrong with John's patch s

[myowntrueself]

Whats more, if you patch the hell out of qmail (in order to make it actually useful in a real-world situation for example) you effectively lose DJBs security 'guarantee' (such as it is).

(I say 'such as it is' because, IIRC Fyodor (spelling?) found a remote root exploit of the default install of qmail on (IIRC) OpenBSD and when it brought this to DJBs attention, DJB refused to recognise it as such).

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.

An example, please?

[Grendel Drago]

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.

I was under the impression that Bernstein's tools tended to take the RFC term "MAY" very literally, and don't always follow instructions that they don't have to. Is there an existing part of a protocol in question (SMTP or DNS) which a purportedly compliant tool (qmail or djbdns) fails to implement completely as defined by the RFC?

Double bonus, if you manage to make it non interoperable by nazi-strict implementation of protocol,

This kind of seems to contradict the above. This may sound naive, but isn't it the nonconforming software's problem if it's emitting illegal data?

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;

Re:An example, please?

[wikinerd]

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

Which really breaks an antispam trick that many servers use, putting fake MX records in your DNS after and before your real MX.

Re:An example, please?

[Gadzinka]

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

Which really breaks an antispam trick that many servers use, putting fake MX records in your DNS after and before your real MX.

Not only that. All the secondary MX-es are also called a backup MX-es, because that's what they are. I once had my private server die on me. It was located 250km away from me, so it took some week or so to replace the broken parts. Almost all the messages adressed to the domain on this server waited on backup MX (we inreased the time limit on retries). Except for the messages from the domains served by qmail, which managed to expire at the sender side.

Robert

If DJB designed datacenters

[Bandman]

DJB: I think you'll be happy to see that I've completed the construction on my absolutely secure data closet. I can promise you that no one will be getting unauthorized access. In fact, if you can find a way to get unauthorized access, I'll give you a prize.

Bystander: Where is it?

DJB: Why, right here!

Bystander: Where?

DJB: Right here, behind this door! What, are you stupid?

Bystander: That's not a door. At least, if it is, it doesn't appear to have a handle to open it with

DJB: Well of course not, idiot. A handle might allow someone to break in

Bystander: It's not much of a door without a handle, and besides, the fire marshal is going to be upset if you've got a door that someone can't get out of

DJB: It's a very secure door. No one can break in at all, and besides, what do I care what the fire marshal thinks. If he cared about securing facilities, he'd change his tune. I dropped by the fire station the other day, and there were door handles all over the place. I bet they get broken into all the time.

Bystander: So what if someone takes a prybar to the door and opens it?

DJB: Well, to tell you the truth, the door is just a patch...

LEAST widely used is more likely

[myowntrueself]

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

Cool so we can say that the total for qmail is somewhere in the 0.58% that didn't provide a banner.

Assuming that there are other MTAs which do not or are not configured to provide a banner we can safely say that the figure for qmail is *less than* (0.58% + 0.17%)

Yeah that qmail sure is a popular and widely used MTA. Sure is. Yep.

Re:qmail security holes

[illuminatedwax]

I'm disappointed that you didn't bother to read the comment I made immediately after I spotted it in TFA.

Qmail is Insecure

[Slashdot Parent]

Security is about way more than remote root holes. Sure there is no known remote root exploit in qmail, but I can abuse a qmail server to send out massive amounts of SPAM since qmail late-bounces instead of rejecting messages during the SMTP session.

10 years ago, generating bounces was OK, but that's not OK in 2007. Hasn't been OK for a few years now.

Postfix Admin FTW

[jnelson4765]

I'd have to agree - I just got done porting our mailsystem from the One Big Box(TM) to a more flexible set of 1U's - and Postfix Admin (with MySQL replication) works just as well managing our multiple-MX, separate-mailstore system as it did the previous monolithic box. It's simple to modify (some of the cleanest PHP code I've seen in some time), and not too confusing for our clients, who can manage their own mail and reset their own passwords. Makes for a lot less in the way of service calls.

I've messed with sendmail, exim4, postfix, and a little with Exchange, and I'll say that Postfix has made the effort I spent in learning its ways worth it. I'd hate to try to set up one of our current projects - a spam-filtering front end for an Exchange server, with LDAP lookups, greylisting, RBLs, the whole bit - on anything other than Postfix.

why I don't use qmail?

[wikinerd]

DJB is a competent and smart hacker (and by this I mean programmer, the correct word for people who break stuff is cracker), but I don't use his software for two reasons:

1. Strange licensing terms (or lack thereof): Not that licence-free software is inherently bad (in an ideal world we wouldn't have the need for licences so everything should be licence-free... but we don't live in an ideal world, do we?).
2. Strange implementation of standard RFCs (which is perfectly okay and acceptable if DJB writes qmail for his personal amusement, but NOT ok if he expects people to actually use qmail).

So, for me, qmail is good for reading the source or for hacking (by this I mean playing to learn). Would I put qmail on a production server? No!

I actually use exim, mostly because it's GPL and Debian default. Postfix would be good if it was GPL too (for the uninitiated, Postfix was started by the guy who wrote the old good SATAN).

I see that DJB has unpopular ideas, but I don't think this should make some of you bashing him whenever his name is mentioned in a forum.

Security at any cost

[Gadzinka]

Here, let me spell it for you:

#include "stdio.h"
 
int main(int argc, char *argv[]) {
  printf("Hello World!");
}

That's the most secure SMTP server ever, I just had to remove some parts, that potentially could make it insecure.

Robert

PS Reductio ad Absurdum is a valid tool. It just lets you see if your thesis takes all the borderline cases into account. In this case I am just trying to tell you, that the (lost) functionality cannot be the cost of security.

Re:Security at any cost

[Edgewize]

I'm tired of this bogus argument. If that were truly the cost of security, then yes, I would stand by your example as the best SMTP server ever written. There is no point in running an email server if the only way to do so is to necessarily expose yourself to vulnerability.

What you really mean to complain about is that DJB has refused to improve usability on the grounds that to do so would compromise security. That's what I was referring to with the phrase "personal approach to security".

If you can improve usability without compromising security, you should do so. If you can't, then don't. However, if you can't do it and someone else can, then maybe you should hand over the reigns of your software.

DJB refuses to do anything that would decrease security. If he thinks adding usability will decrease security, that doesn't mean that his priorities are wrong. It just means that you might want to find a better programmer to maintain your SMTP server.

Re:Security at any cost

[Gadzinka]

I'm tired of this bogus argument.

Which argument exactly?

The point I was trying to make with my implementation of SMTP server is that the state of the art is a careful ballance between usability and security. My example was 100% secure and 0% usable. Qmail at its inception was maybe 50% usable, but on today Internet it's 0%[1] usable, while still very secure.

There is no point in running an email server if the only way to do so is to necessarily expose yourself to vulnerability.

Let me counter you on this: there's no point in running an email server if it cannot serve mail.

Robert

[1] smtpd w/o ssl/tls and client auth is useless today, no buts and ifs, period. qmail also misses some other features, but it's been too long since my sysadmin days, to remember all of them; as for external patches doing just that, they're not part of qmail, so for the sake of this discussion they don't exist;

Re:Security at any cost

[Edgewize]

We're in complete agreement - there's no point in running an email server if it cannot serve mail OR if it compromises your security. I also share your opinion that qmail (without patches) is completely unusable. That doesn't change the fact that security should be the highest concern of software development, nor does it mean that DJB's priorities are incorrect.

It just means that software has a minimum bar of functionality and usability, and that qmail fails to meet that bar, which is neither here nor there in a discussion about the importance of security.

Pointing out the lack of usability in qmail is not a justification for decreased security, it just means that everyone should strive to be a better software engineer than DJB. :)

Patches ?! We don't need no stinkin...we ok we do

[sarkeizen]

...but it's not the problem you might think.

I'm surprised at the complaints about patching. For your average implementation there are single rollup patches that cover just about everything. We run several qmail based systems where I work. We find them stable and relatively easy to work with.

The only times we take them down is when those 'on-high' want to implement some weird business rule for email. I don't really like DJB's coding style but it is clean and consistent.

Re:File system layout standards

[Russ Nelson]

"perfect sense" to an insane person. Okay, so when I want to tell somebody what program to run, do I tell them /usr/bin/foobar or /usr/local/bin/foobar? Because, just as you say, there may already be a foobar in /usr/bin which the user didn't want to overwrite. The only way I can tell them is to execute another round-trip of question and answer to find out whether they compiled it themselves or whether it came as a package. With qmail, I can say "run /var/qmail/bin/qmail-qstat" and tell me the second number.

Re:File system layout standards

[Russ Nelson]

Errr, no. The executables in this case are specific to the machine, thus they *belong* in /var. Putting them anyplace else would be wrong.

Re:File system layout standards

[Wdomburg]

Erm, no. The /var directory is for variable files, not executables of any flavor. Depending on platform either /opt or /usr/local is the appropriate location for locally installed software (or increasingly software not managed by the native packaging system).

Re:File system layout standards

[Craig Davison]

Having two versions of the same program is silly. If they want to compile their own version of foobar, they should always remove the one installed by their package manager first. If they don't do that, well, I suppose there are worse ways to hose your system. Overwriting something in /usr/bin would be one of them, because when the time comes for your package manager to update that package, you'll have an inconsistent mess on your filesystem.

What you do is don't specify the path. Tell the person to run "foobar". If their shell is setup correctly, the program will run.

The Linux/UNIX world is perfectly happy with this setup. But we must all be insane, it couldn't just be you lacking understanding.

Re:Minix.

[SanityInAnarchy]

Only when I get the distinct impression that everyone's forgotten. Consider what I was replying to:

The good thing is that is easy to work with and works really good. The bad thing is that the license is NOT FOSS.

Easily sounded like someone in need of a history lesson.

So what's your excuse?