I have dealt with qmail for ten years. It is a complete joy once you have it up and running. You literally can stop thinking about it because it always works. However, getting it up and running requires adding in antispam, antivirus, virtual mailboxes, some additional protective and administrative patches, some extra stuff for SMTP-AUTH, SSL/TLS, reporting, and perhaps a few more patches for fun.
Patches, you say? Well, I'm glad you really like source code, because that's exactly what you'll be dealing with to get all of this up and running. I've done it many times before manually and it takes around ten hours to do it.
While Aaron's point is that djb's code, vision and discipline are possibly unmatched (I concur on all counts), the software (principally qmail) is antiquated in the sense that nobody needs just that one part in order to run a semi-modern email system.
So, as you start downloading the .tgz for qmail and begin studying it like good campers, remember that this wonderful code is, by itself, not up to the job that it purports to serve.
-- Lots of love,
Someone who currently runs two qmail systems and will never go to the trouble of setting one up again
> I've done it many times before manually and it takes around ten hours to do it.
This is exactly why I've been using Postfix (or, preferably, get Google or someone else to handle it for me).
Easy to install is a feature, and a pretty close cousin of the "shipping" feature.
DJBs software is interesting mostly from an academic perspective. In the real world, it's hard to justify using something else, when apt-get gets the job done in literally seconds.
I haven't used qmail, but I use djbdns. The complete installation, possibly including a few patches, is less work than figuring out how to set up BIND's configuration. It's available in Debian from apt-get.
It's good that it's so easy to figure out how to use, because I touch it less than once a year, so I've completely forgotten about it. That's great software.
It is hard to imagine the serious, rational, objective argument that could exist for running BIND instead of djbdns, if those are your two choices. There are viable alternatives to qmail (Postfix and Exchange), but there aren't really viable alternatives for djbdns, and djbdns is less opinionated than qmail is.
I've only setup a single BIND server, and chose that due to previous exposure to the zone file format. It got the job done, pretty quickly even, but I'll definitely consider djbdns next time the need arises.
Next time around, take a look at PowerDNS. You like flat files as your zone backend? Supported. You want an SQL backend? Supported. You want an LDAP backend? Supported. And so on and so on.
DNSSEC is a disaster. Even if you liked the protocol today, having support for it in your DNS server wouldn't help you.
It's true though; thirteen root nameserver operators do run BIND. You know what's worse? The tens of millions of people that like The Black Eyed Peas. >shudder< - what's wrong with me?
If code I write is hard to deploy to your system, I don't think my code can be to blame. Rather, it's the fault of the system/language in which we are working.
If no one can use your code, it doesn't matter how beautiful, well-thought-out, or well-written it is. Software exists for the purpose of being executed. If your project cannot be deployed with a reasonable amount of effort, it's worse than bad software, it's a waste of time.
What about easy-to-install software that makes it easy for Bad People to ruin the Internet and to compromise your server (and potentially your entire organization)?
That is bad too. If I had to pick between "secure + customizable but hard to setup" and "easy to set up, but is a one giant gaping security problem", I think I would rather have the first.
Software is about collaboration, like a relationship; one person shares their ideas (qmail), another shares his (your site's configuration), and both parties do better than the sum of their parts. Easy-to-install software that doesn't require thought or communication is a one-way conversation; nice in the short term, but not something you want to be with for the rest of your life.
I hate this attitude. If your code targets my system, I should be able to install it without editing it.
You certainly should, but it isn't the coder's responsibility to make this possible. It's the language/system designer's.
Just because C doesn't let you deploy nicely has nothing to do with djb's ability to create beautifully architected code, which is what Aaron is praising. I'm sure djb could have written equally beautiful code in Squeak Smalltalk, and it would have been a breeze to deploy, but had no impact on how elegant the code itself was.
C does let you deploy nicely. A makefile and some discipline are almost all you need. Granted it's not always easy to write a sane makefile, but that is the coder's and not the installer's responsibility.
I don't think it's every C coder's responsibility to know how to make and ship good makefiles. It's certainly is helpful if she does, but it seems silly to say that's a responsibility, just as it isn't the responsibility of an artist to know the laws governing international sales of her artwork.
Sure, but it all depends on the coder's goals. If there's a competing option that's easier to install, prospective users may go with something else. If the coder doesn't care and isn't looking for users, then that's fine.
QMail doesn't target Linux? Oh, wait, you mean it doesn't target me and others who doen't want to invest the effort in installing it. That's fine, I use Postfix and it works well enough for my needs.
So what? Comparative programs have the same issue therefore it is not an issue? I'm not disputing that QMail is an improvement over Sendmail; in fact, I'm not disputing QMail at all. I've never deployed it, nor do I plan to do so.
I'm merely expressing my belief that in code that is meant to be used in production, facilitation of deployment is part of the problem scope. This is especially so when proper deployment is critical (as is the case with a mail server for example.) If QMail make deployment more difficult than it could be, then that is a problem with QMail. It might be the result of a worthwhile trade off. It might be better than it's competitors. But it's still a problem.
I agree with you. DJB wrote secure code that works very well and donated it to the public domain; if you want it to be Perfect For Your Needs, you are going to need to do that yourself. You are a unique snowflake, and your needs differ from DJB's.
"You suck for not doing enough work" is no way to treat someone giving you free software.
If DJB doesn't want to make his software useful, that's his right. We simply won't use it and the most perfect code in the world can pathetically fade into oblivion.
Patches, you say? Well, I'm glad you really like source code, because that's exactly what you'll be dealing with to get all of this up and running. I've done it many times before manually and it takes around ten hours to do it.
While Aaron's point is that djb's code, vision and discipline are possibly unmatched (I concur on all counts), the software (principally qmail) is antiquated in the sense that nobody needs just that one part in order to run a semi-modern email system.
So, as you start downloading the .tgz for qmail and begin studying it like good campers, remember that this wonderful code is, by itself, not up to the job that it purports to serve.
-- Lots of love,
Someone who currently runs two qmail systems and will never go to the trouble of setting one up again