I am a huge DJB fan but even I gave up on qmail - it's just a bit too
much of a pain (I still run djbdns though). Postfix has been working
very well for me, however.
How about just bolt in any one of the following:
http://search.cpan.org/~rhandom/Mail-Spool-0.50/lib/Mail/Spool.pm
http://search.cpan.org/~davidnico/TipJar-MTA-queue-0.02/queue.pm
http://search.cpan.org/~zacs/Mail-Queue-DB-0.03/lib/Mail/Queue/DB.pm
and if you really want to stick to the qmail interface, this would be a
start.
http://search.cpan.org/~giff/Mail-Qmail-Queue-0.02/README.pod
Tim
Robin H. Johnson wrote:
On Fri, Jun 01, 2007 at 01:02:03PM -0400, Guy Hulbert wrote:
On Fri, 2007-06-01 at 09:33 -0700, Robin H. Johnson wrote:
My basic outline was to take the architecture of qmail, and
incrementally replace the parts of qmail with Perl re-implementations.
qpsmtpd was built as a qmail-smtpd replacement in the first place, so
this is a reasonable route to take.
What problem(s) are you trying to solve ? The answer for qpsmtpd is
obvious (to me) but I don't see any reason to replace the rest.
Pain of maintenance.
Why not just install qmail ?
A little background here.
Background
----------
Starting nearly 4 years ago, and up until about a month ago, I've been
Gentoo's qmail maintainer. I am _painfully_ aware of the process of
patching qmail. The Gentoo qmail package at it's peak had approximately
30 different patches, getting it closer to the feature-set presently
available in other more-updated MTAs.
http://viewcvs.gentoo.org/viewcvs.py/gentoo-x86/mail-mta/qmail/qmail-1.03-r15.ebuild?hideattic=0&rev=1.47&view=markup
^^^ Look at the src_unpack function, and all of the epatch statements
therein.
The problem was, maintaining a build that can apply 30 patches is a LOT
of work. We had to abide by DJB's rules of not modifying the original
qmail tarball, and also wanted to keep patches separate wherever
possible (to allow updating specific patches).
Long term, this meant that if you changed a patch early in the stack,
there was a significant non-zero probability that you would have to
change a patch later in the stack.
This got to be so much work, that we didn't get very many revisions of
the package out, and eventually changed our policy that if you want to
patch up qmail, you do it on your own (with netqmail), and keep the
pieces when it breaks.
On moving forward
-----------------
If there is any MTA that I think is closest to a good design, it's
qmail. It's also modular enough that incremental replacement is easily
possible.
Why move qmail to Perl? For the same exact reason that qpsmtpd is such a
large improvement over qmail-send. Ease of maintenance and plugin
support.
Here's the rough outline and implementation order
qmail-smtpd - qpsmtpd, already exists
qmail-remote - outgoing mail is important to me, I have a need for routing
based on envelope sender.
The rest of the components would be nice to have in Perl for
extensibility and future work, but I don't have a personal need to
replace them right now.
qmail-queue
qmail-inject
qmail-send
qmail-rspawn
qmail-lspawn
qmail-local
