Re: Qmail-Specific?

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 15, 2010 at 12:36:34AM +0000, Sabahattin Gucukoglu wrote:
> I'd be willing to write an SMTP client that injected QMQP-received
> mails to accommodate QMQP, if that is preferable to having EZMLM do
> this itself.

I don't see there doing much point is such a proxy.  Since ezmlm doesn't
itself do QMQP, it would be necessary at some point to add a protocol
sender into ezmlm itself to interoperate with non-qmail systems (unless
installing mini-qmail is considered acceptable of course).  At that
point, basically any protocol is possible.

However, given that the MTA under discussion accepts QMQP and that QMQP
provides *exactly* the semantics currently required by ezmlm (VERP for
posts, and envelope follows the message) with the minimum amount of
overhead, that is certainly the path of least resistance in the case of
adding a protocol, and would be my first target if I go down that route.

> >> The right way is to use RFC 1893 DSNs, rather than VER{P,H}.
> >=20
> > DSNs can't inject the sender's email address into the header or footer,
> > giving customized unsubscribe instructions (among other things).
> >=20
> DSN is certainly appropriate for bounce handling, however
> unsubscription can take advantage of the sender's return address when
> s/he makes an unsubscription request.

Unsubscription already uses the sender's return address.  The problem
comes when the subscriber is receiving messages forwarded to them from
some other address, and can't (for whatever reason) determine from the
headers what address is actually subscribed.  With customized outgoing
messages, the sender could put an unsubscribe link into every list post
that contained the recipient email address.  For example:

  To unsubscribe, e-mail: [email protected]

DSN can't do that.  The point is to make it as easy as possible for the
recipient of the message to get off the list.  There are other things
you can do with customization, of course, that's just the most obvious
for mailing lists.

> > 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
> I would expect the implementation details of the MTA to cover your first =
two questions.

That is what I'm asking.  How is it done?  Are there *any* MTAs that can
queue up more than one email in a single transaction, such that (1) the
process is efficient, and (2) they either all queue or all do not queue?
I've never heard of such a thing.  I've seen one or two rather intrusive
patches for qmail that would allow for arbitrary substitutions within
messages, but at least the one was not public when I saw it.

> The advantage of doing VERP is simply that less state has to be
> maintained for a given list message, rather than a message for each
> recipient of that message, namely, who the last person you sent mail
> for was.

This is partly true, but the amount of state required is more than just
who the last person you sent mail to.  If the process is interrupted
(server crash or reboot, SIGXCPU, stray OOM killer, whatever), what
restarts it?  If there were subscribers added or removed, how do you
preserve the state of the list that you had been sending from?  Once you
consider all the corner cases, and consider the need for a protocol
sender as described above, you may as well just add a retry mechanism
and call it a dedicated MDA or mini MTA.

>   This could roll into the work being done now to get transaction checkpo=
int standardised:
> http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rf=
c1845bis.html

Interesting, but not quite what would be useful for a mailing list, at
least not directly.  In RFC terminology, a SMTP transaction is a single
message.  I am speaking of something more like a database transaction,
which consists of multiple (customized) messages at once.

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

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAkt5bzIACgkQ6W+y3GmZgOhfcACfU+GyBFsyaUmGQhEDuEhyOM8Y
bB0An3ew+TlgI5D3HBa3yuq7TAK2jY1g
=VCYv
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--