Re: Qmail-Specific?

On 10 Feb 2010, at 02:09, Bruce Guenter wrote:
> On Tue, Feb 09, 2010 at 09:23:15PM +0000, Sabahattin Gucukoglu wrote:
>> What parts of ezmlm are qmail specific, apart from the QMQP?  Why can =
only qmail use it?
>=20
> Technically, QMQP isn't qmail specific, though currently all QMQP
> servers that I am aware of deliver to qmail.

Okay, I found the spec, but it's by DJB and apparently just for DJB, =
seeing as how ESMTP PIPELINING seems to be better suited to this for all =
but the smallest deliveries ...

However, I find that Postfix has the ability to accept qmqp requests, =
which means sending from ezmlm to postfix direct is possible (google =
"ezmlm postfix").  Tangentially, I also found alternative mailing list =
managers, Enemies of Carlotta (no longer maintained) and mlmmj, both of =
which remove this requirement, behave quite like ezmlm, and work with =
any mailer using local-part additional data, something+other or =
something-other.

> The mechanism for ezmlm accepting messages is currently keyed to how
> qmail handles things -- the dot-qmail mechanism, and specifically
> wildcard handling through .qmail-something-default.  I understand
> Postfix at least has a similar but not quite identical mechanism, but =
it
> would require adapting ezmlm.
>=20
Can a wrapper script do this to pass the necessary environment to ezmlm =
programs, given that it can parse out the extension part?

> The mechanism for delivering messages requires qmail-queue.  This too
> could be adapted to any MTA that accepts a raw envelope in some form,
> except for one detail: VERP.  ezmlm depends on all list posts having a
> unique envelope sender in order to most efficiently handle bounces.  I
> have no idea how easy it would be to adapt that to another MTA.

> Now, I'm not exactly sure where the need for alternative mailing list =
managers came from.  Here's postfix's ancient VERP support:
http://www.postfix.org/VERP_README.html

And some sick bastard has even got it going with Sendmail's rewriting =
rules:
http://mlmmj.org/man/sendmail

Ezmlm-idx's database and MIME support are attractive features.  I'd love =
it if (ever I find the time, and) it worked with other MTAs like this.

> So that's pretty much three issues that are specific to qmail =
(wildcards
> for incoming messages, qmail-queue for delivery, and VERP), the first
> two of which should be easy to adapt to a different MDA or MTA.  If
> there are other other MTAs that do something equivalent to VERP, I =
would
> be interested in adapting ezmlm, provided others can help with =
testing.

And I will soon be looking for an MLM, and would be most pleased to give =
you a hand there before giving over to an alternative for my =
soon-to-be-Postfix installation and the myriad of nearly-obsolete and/or =
highly-bloated alternative MLMs.  In fact I imagine that at least for =
Postfix, it's the first two that will give you the most trouble, but I =
hope it should be reasonably straightforward.

> On that topic, I have been musing writing a MDA for ezmlm that was
> effectively a stripped down qmail-send+remote.  There are numerous
> advantages to integrating with an existing MDA, mostly to do with
> duplication of existing code and potential for resource abuse.  On the
> other hand, with a custom MDA, ezmlm could do substitutions in the
> message during delivery (ala VERH), something that qmail simply is not
> designed to do.

I have been meaning to write a general-purpose MTA myself, and imagine =
that it would be best to integrate mailing list functionality into it =
directly, for example to support closed operation at SMTP time and for =
cutting down on MLM-to-MTA communication normally implied by a separate =
MLM (a la XMailServer) to give best efficiency.  However for =
ezmlm+ver{h,p}, I suspect that the effort required to generate one =
transaction per recipient is better expended by the MLM rather than a =
custom MTA.  If nothing else, connection caching can be done by an MTA =
holding deliveries for multiple recipients at any given time.  The right =
way is to use RFC 1893 DSNs, rather than VER{P,H}.  Of course, for =
current large lists it is not yet attractive enough a proposition =
because until it's properly adopted it won't give you (or end-users) =
reliable bounce handling or unsubscription.  But doing message =
personalisation would make ezmlm more MTA-compatible, with the small =
downside that for maximum efficiency you would need to know how best to =
put mailers into queue-only mode to avoid the deficiencies that might be =
otherwise caused by eventual message submission over the time of a =
delivery, for the purposes of exploiting connection caches.

Cheers,
Sabahattin