Mailing List Archive

Charles Cazabon wrote:
> > > But I'm afraid it came too late for qmail to be saved. The world had
> > > basically moved on from qmail by the time it became public domain.

> But if you mean: what do I recommend to my clients? Then the answer to that
> is: whatever will (a) suit their needs best and (b) do so with the least
> setup, operational, and maintenance costs. The answer to this latter question
> is qmail, sometimes - but certainly not as frequently as it was ten years ago.

To expand on this point, please remember that a stock qmail-1.03 tarball won't
compile on modern Linux systems due to a a glibc bug. Were I an aspiring admin
looking to install qmail, I'd Google "qmail" and have to know to read down to
the fourth link that explains that there are patches on a qmail.org mirror.

But qmail.org isn't cr.yp.to. And qmail-1.03 isn't netqmail-1.06, so just how to
get a working MTA starts to seem a little more daunting than the "apt-get
install <something>" I'm used to typing when I want a software package
installed.

These are not insurmountable problems, but someone who isn't aware of these
quirks won't necessarily know how to solve them, especially when many distros
contain a self-supplied and supported MTA in the default install or as a
installation option. I don't think anyone is saying that there isn't a place for
qmail on today's Internet. At the same time, it's been largely left unchanged
for nearly 16 years at this point and I'd be surprised if anyone runs a totally
stock qmail-1.03 install anymore. Remember, the ./INSTALL steps still call to
put a tcp-env line in your inetd.conf file, so there's some interpretation as to
what a stock install really is. The package has not adapted to the times, and
that does not help to foster adoption.

As an old qmail admin for many years, I know how to patch it and tweak it to get
it running: how to handle conf-cc, how to make sure svscanboot runs at system
start, but there are new inits out there, and I still haven't memorized how to
handle Upstart versus systemd versus something else shiny and new. I'm sure that
there are package maintainers out there who have worried about all of this for
me, and they've gone to the added trouble of moving everything out of
/var/qmail, which violates the stipulation of DJB's "Information for
distributors" and just makes me itchy.

I know how to make a qmail system that I'm happy with using. I've been doing it
for a long time and I remember when most of these new incompatibilities were
introduced over time into the underlying operating systems. Architectures
change. Platforms introduce breaking changes. Is it their fault? Yep. Are they
going to fix it just for us? Probably not. It's frustrating, but as Charles
points out, what will work best for a given client may not be your favorite pet
program and it's unethical to force it upon them just because you like it so
much.


Toby

Thus said "Toby Betts" on 12 Apr 2014 21:32:11 -0700:

> At the same time, it's been largely left unchanged for nearly 16 years
> at this point and I'd be surprised if anyone runs a totally stock
> qmail-1.03 install anymore. Remember, the ./INSTALL steps still call
> to put a tcp-env line in your inetd.conf file, so there's some
> interpretation as to what a stock install really is.

I still run a stock qmail-1.03. If there is no reason to patch it, I
don't patch it. I primarily run it unpatched on internal systems where
all I need is either mini-qmail, QMQP, or some other part of qmail that
doesn't require patching. Also, using qmail with daemontools/ucspi-tcp
does not mean that one is not running stock qmail.

> The package has not adapted to the times, and that does not help to
> foster adoption.

I would argue that it has weathered the times. :-)

> It's frustrating, but as Charles points out, what will work best for a
> given client may not be your favorite pet program and it's unethical
> to force it upon them just because you like it so much.

If you are forcing anything upon anyone, you are not engaging in a
voluntary relationship typically required to transact business with
others. :-) Why not explain the rock solid performance and zero
maintenance configuration and all the other benefits that one gets when
using qmail. Give the customer a choice, but also develop a plan for the
customer. As for upgrades, maybe the problem is the OS, not qmail, in
not providing an easy mechanism to replace/integrate components into the
OS. I never seem to have problems with upgrading OpenBSD, and it doesn't
require adding -include /usr/include/errno.h to conf-cc either.

Also, by running qmail on OpenBSD, there is no need to patch qmail for
greylisting as one can simply leverage OpenBSD's spamd which is superior
in my opinion.

Andy
--
TAI64 timestamp: 40000000534aa96b