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
> #ifdef's.

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

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, 

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

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.


Steve      |President & Systems Administrator,  Kingston Online Services
           |(e pluribus unix)  Multiple-T3/OC3  URL: http://www.kos.net/
           |Business and Education partners in SouthEastern Ontario
           |"Through the firewall, out the router, down the OC3, across the
           |backbone, bounced from satellite, it's nothing but net."

Reply via email to