Re: Qmail-Specific?

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

On Mon, Feb 15, 2010 at 10:53:48PM +0000, Sabahattin Gucukoglu wrote:
> I'm still not clear why you need special handling in the case of
> interruptions: if your submissions to the MTA are interrupted, start
> where you left off; if the queue run is interrupted, the MTA will
> simply begin where it left off.  Why do you want to ensure an entire
> VERP-style delivery is transactional?  I must be missing something.

The issues are: Performance -- with one message per recipient, the MTA
has to separately queue up potentially thousands of messages.  Disks are
getting faster, but that's still an expensive proposition, and can
seriously impact other users of the disk on the same system.
Reliability -- does the message get to all the recipients exactly once?
If the sending process is interrupted (due to taking a long time to
queue up all the messages), there is the address list could easily
change before the next run.  With the introduction of non-file address
list databases, this can mean not just duplicated delivery occasionally
but actually reordering the list for some kinds of storage.

So, to make this work reliably, ignoring the performance issues, it
needs to store the message to be delivered plus a snapshot of the
address list.  In order to handle interruptions, it also has to store an
indication of which addresses have been delivered, and some mechanism
needs to be set up to restart delivery if needed.

> Oh, well, if it's so unimportant a consequence of a failure to have a
> retry occasionally send duplicates in exchange for subscription
> updates, I think the best thing for you to do is to simply never
> return a submission status of zero to the incoming job until you've
> made a VERP explosion to the submitting MTA.  Then, you can rely on
> the client coming back if the job doesn't succeed the first time
> around, or of the queue on the sending host to do the same thing.

This does achieve "at least once" semantics on message queueing, but I
imagine there are lots of lists that would object to duplicated messages
being "unimportant".

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

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAkt94JMACgkQ6W+y3GmZgOiV4QCeLPV/jaysE422f8RbBLwtvbwp
ydgAoIKyggqUAy1iwoSeeMCUdAlOzyn3
=op9E
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--