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
#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,
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
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.
--
James McMillan
V.P. Of Information Technology
www.TheNetMark.com
412 New Broadway
Brooklawn, NJ 08030
888.767.8750 X106
