Re: Qmail-Specific?

--St7VIuEGZ6dlpu13
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 11, 2010 at 01:13:08PM +0000, Sabahattin Gucukoglu wrote:
> Can a wrapper script do this to pass the necessary environment to ezmlm p=
rograms, given that it can parse out the extension part?

If the wrapper script could figure out the right variables, sure.  You'd
have to adjust the ezmlmrc as well to build the right links and such.

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

If I'm reading that right, this would seem to require that ezmlm send to
Postfix via QMQP (or SMTP).  I don't know that the sendmail interface is
adequate to the needs of ezmlm.  What happens if there are more
recipients than can be passed on the command line, for example?

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

That would have to be sick, yeah.

> 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.

I am willing to help.  I would love to be able to say that ezmlm-idx
works with more than just qmail.

> If nothing else, connection caching can be done by an MTA
> holding deliveries for multiple recipients at any given time.

This presumes that connection caching is a net benefit for a MTA.

> The right way is to use RFC 1893 DSNs, rather than VER{P,H}.

DSNs can't inject the sender's email address into the header or footer,
giving customized unsubscribe instructions (among other things).

>   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.

Actually, the biggest problem with doing message personalization in
ezmlm is not connection caching or other delivery issues.  How do you
reliably queue up large numbers of messages without starving other users
of the disk and/or the queue (depending on how the MTA dequeues the
messages)?  And what happens if the process is interrupted?  The
complete set of messages needs to be effectively queued as a single
transaction, and that can't happen when the messages are personalized
outside of the MTA without some alternate kind of queueing process.

--=20
Bruce Guenter <[email protected]>                http://untroubled.org/

--St7VIuEGZ6dlpu13
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkt0akQACgkQ6W+y3GmZgOgN8QCffqUs8oPMLloFbbXqSRyDgwlX
ackAn0JjWMaHNX5cZStKReHslVTBudRL
=CtkY
-----END PGP SIGNATURE-----

--St7VIuEGZ6dlpu13--