Erwin Hoffmann <feh@fehcom.de> wrote:
>
> So this is your coffin nail for qmail?
Not at all. I'll still be running qmail for my own use, and consulting for
clients about it, in a decade's time. But see my other message.
> While you guided over 15 years the community with your wisdom (in my
> book I referenced you as 'answering machine' for qmail),
I truly lol'd at that ;)
> it would certainly be helpful to have some kind of retrospective view and to
> understand, why other packages like Postfix and Exim are more popular these
> days.
See my other message for some of my reasoning.
Yes, it would be nice to see qmail come into the 21st century. If someone
wanted to do the work, here a few points off the top of my head, in no
particular order, that they might want to address:
Working on qmail's code is difficult, or an interesting challenge if you
prefer a less negative term. djb's code is efficient and correct, but it
isn't exactly what you'd call obvious or commented. If you want to implement
a new MTA feature, and you look at what it would take to implement in qmail vs
in some other MTA, qmail loses out heavily here.
qmail's architecture, of mutually distrusting but cooperating processes, is
very good from a security point of view. It does make it more difficult to do
some things -- as you no doubt noticed in implementing recipient verification
during SMTP acceptance of messages. In general, the rigid
compartmentalization does exactly what it was designed to do - makes it
difficult to get information between the processes that wasn't designed into
the communications in the first place.
Code no longer has to be obtuse low-level C, hand-optimized for performance at
the expense of readability, to get "good enough" performance these days, due
to Moore's Law supplying more than ample CPU cycles and memory space. You
could get *much* more maintainable, extensible code simply by replacing some
of the qmail processes with equivalents written in a higher-level language,
and still have it more than fast enough to deliver all the mail you ever
wanted to deliver.
The internet mail infrastructure has moved on. If you were starting an MTA
from scratch these days, you would probably want to design in right from the
beginning many of the features which are more difficult to implement today
with qmail than with other MTAs: recipient verification, DKIM support, SPF
(bleh), TLS/SSL (specifically with STARTTLS) for all network protocols, SMTP
AUTH, ... Yes, you can add all of these things today, but if you just download
netqmail and "go", you're not going to get them.
Shipment with OSes at least as an optional replacement for other MTAs. This
might come automatically after addressing the other points, but it might not
either. And as long as you have to go hunting for it (rather than just
installing it from your OS's packaging system), qmail will remain a niche
product. Getting OSes to include it might require running qmail in a less
djb-esque fashion as well -- for example, I don't recall seeing anyone write
up how to run qmail under upstart or systemd, despite those systems having
vastly more traction than svscan ever will, even if svscan is technically
superior in many ways.
I'm sure there are other points that could be addressed.
> There is, however, an important community still relying on qmail.
Absolutely. As I said, if you already have time invested in setting up and
running qmail infrastructure, then chances are you're going to continue to use
qmail for your systems when you expand or evolve them. That's to be expected.
> In addition, some kind of 'mono culture' is certainly not helpful.
Agreed.
> Problem 1: How to spread the news. Unfortunately, qmail.org does
> neither reflect the needs for a contempory mail admin, nor does it
> bundle the developments. qmailrocks is a different story.
Ya... I've never cared for qmailrocks as it always seemed to me (whether this
was the intent or not) to be a "Here, run this script and with zero
understanding you'll have a qmail system up and running in minutes" kind of
thing.
> Problem 2: Unlike other email packages, qmail developers are
> isolated. There is no forum, nobody to bundle their activities, and
> perhaps provide a 'product' out of it.
Agreed. Maybe there's enough interest to have a public git repo and public
development mailing list, issue/feature request tracker, release notes,
roadmap... maybe there isn't.
> Problem 3: To many ways to go/fail. For qmail, there exist a lot of
> specialized solutions (I contributed some). However - and unlike
> Postfix - there is no major path. In fact: You can install Postfix
> today and it works as contempory MTA solution. With qmail, you have
> to look for a lot of (contradictory) patches -- and you find those
> at very many locations.
Yes, exactly. So if you didn't already have a historical reason to pick
qmail, it's unlikely an admin facing a choice between them would pick qmail,
no? Which was eactly my point...
> Anyway, I will continue to support qmail and develop it further --
> hopefully in a direction DJB likes.
I still use it and support it, and provide consulting and development to
clients. It was not my intent to declare qmail dead, like poor Yorick ;)
Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:
http://pyropus.ca/software/ Read
http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html --------------------------------------------------------------------------
Srejector_20140407.115834:2, (24.6 KB)