Eh, correct me if I'm wrong, but wasn't the question like;

"Why should I use qmail?"
and not
"Why shouldn't I use qmail?"

Just trying to point us back in the right direction.

Steve Cole wrote:

On Tuesday 05 July 2005 15:13, Kyle Wheeler wrote:

Old? Yes. Hard to use without patches? Eh, I think netqmail has
addressed that "problem".

Don't quote problem.  It has real problems.  errno.h is a nice start.

netqmail is at best a hacked-together solution for a small set of problems. It offers very little functionality over the original qmail. A big thank-you to the maintainers of netqmail, however.

Stagnant? Depends on what you mean by that.

Hrm, let's see. It doesn't have a spam or antivirus subsystem, API, hooks, etc. at all. Slapping alternatives into qmail-queue works but it's the least elegant solution I can imagine. While other products are including in-process checking for spam & viruses (using libclamav, for example) with extensibility, we have... erhm... ugly, buggy, inefficient roll-it-yourself solutions to the problem. Inter7 has a more reasonable solution to the problem, but they have to eat, so it's partially commercial.

Don't even try to tell me that spam and virus activity isn't anything to do with e-mail today.

How about a management interface? vpopmail has limited visibility out there in the world because it's a separate package, and it could be more integrated if the qmail code wasn't locked up in a restrictive license. But all-in-all, it's an add-on in the broadest sense of the word. Other mail systems have this kind of support integrated, now.

What about logging? qmail's logging is poor, spotty, undocumented and depends on other packages to do the brunt of the work.

Effiency - in a modern mail system (vpopmail + spam + virus protection), qmail is a dog. If you run it clean without any features except shovelling files around, it will do just OK with a good deal of tuning. In stock form, it is nowhere near enterprise-ready (hell, won't even compile on most systems anymore). Dropping antispam/antivirus functionality to procmail and PERL scripts destroys a mail server in short order.

This has made a lot of qmail users turn to Barracuda or an outsourced spam/virus checking service. If they'd chosen something else as a mail server sometime after 1999 when it made sense, they wouldn't be required.

POP3, IMAP, POP3S, IMAPS. SMTP-AUTH, SQL support, fine-grained limitations, a finished QMTP. qmail's pop3 server is stone-age and everything else is just not there.

How about flow control? Need to say, "I need to limit senders to 1,000 addresses in a single e-mail. And furthermore, I need to limit them to a maximum of 512MB of data transfer per message. And another thing, I need to set up mailbox quotas with flexible accounting that doesn't depend on file system quotas - or UNIX users in fact." Some patches are available, but they're very hacky, buggy, and not well integrated into qmail.

actually really like the way qmail works for the purpose --- I know
exactly what it's doing, why, and how.

Good.  But you're not the only one using qmail.

while understandably hard or inconveninent for people who do not know C
or who prefer the ./configure interface for turning on features, is a
good way to do it for the security-paranoid who would rather trace out
each addition rather than review code and try to untangle giant webs of

If it was in the base tarball source, what's to prevent you from doing the same? This is a poor argument, IMHO.

I wish it had a license like that too. On the other hand, he put his
name (and $500) behind it - something he really couldn't do if just
anybody could add code to it and call it qmail.

Then he let it quietly age and more or less die. If it weren't for legacy mail systems and long-time believers, qmail would be dead right now. It more or less is... almost nobody ships it as a default, and from what I have seen, most distributions hack/slash/move/modify the crap out of it until a long-time qmail admin will be pulling out her hair in frustration trying to figure out what they did to the filesystem layout.

And really, putting everything in /var/qmail was ridiculous. So is daemontools, even if it works... but that's another discussion.

But look at it this way: there's nothing in the license that says you
can't take qmail, rename it to (mySweetMailserver, for example), and
release it under the GPL. That nobody's done that says something.

Yes, there certainly is.  The license (as I understand it) prohibits it.

I disagree - I find most of the code refreshingly straightforward.
Comments might help, but I think it's really pretty simple to decipher.

Many people disagree with you.  This is subjective, I guess.

It's looking mighty old these days...
You say that like "old" is a bad thing.

In the software industry, it's anathaema.

like the Franklin Stove, it still does exactly what it was designed to

How many Franklin Stoves are they selling today? :)

But in terms of complaints over nearly a decade, that's
a stunningly low number of "problems", none of them actually serious.

Quite untrue. vpopmail exists as a testament to a problem that qmail was capable of handling, but which was never realized. A lot of volunteers and a few small companies put a lot of work into vpopmail not because qmail couldn't do what they needed to do, but because they had serious problems with how it was done. Then again, had I undertaken it myself, I would have patched qmail for many of the things that vpopmail did... though I understand the design philosophy of retaining qmail's basic structures.

think it says something about the ease of maintenance, ease of patching,
and ease of configuration that qmail has lasted this long virtually
unchanged. "Creak"? Far from it.

No, I think it says quite a bit about how poor the alternatives were back in 1997. They were positively horrible. Today, you'll find that most of the patches being made are from long-standing qmail users (look at the age of many of the patches, btw) that just can't or won't take the time, energy, cost; risks involved with moving to another mail platform. I'm securely in this camp. I'm not moving, but I'm not totally happy with the status quo, either.

While it may be harder to install than ./configure && make && make
install, I don't see any reason to think qmail isn't up to the task

qmail itself isn't. Plain and simple. Without all the patches, tuning information and hard work of the admins that have used qmail for years, qmail would be completely irrelevant right now. In fact, I'd say that it is... netqmail and its patched friends are what are relevant, the qmail source code is just the chair that those stand on. Without those patches, most people couldn't even compile qmail anymore.

P.S. I've also paid Inter7 for consultation time to set up clamav with their spam/virus checking solution. Nothing ever came of it, but I never asked for any money back... because vpopmail has been quite good to me.


James McMillan
V.P. Of Information Technology
412 New Broadway
Brooklawn, NJ 08030
888.767.8750 X106

Reply via email to