[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-07 11:43:21

On Wed, Feb 07, 2007, Tony Finch wrote:

[perform a single "scan" of the message]
[[...]] The model would then be that the MTA
scans, decides whether to accept for each recipient, commits if necessary,
then returns all the replies at once. This is why I had been arguing for
using exactly the LMTP style of final reply.

If you have "all the replies" then you can also generate a "final
reply" (its the minimum of all reply codes, I do that currently in
my test sink) and transmit it together with the others. This makes
error handling in the server _much_ simpler.

[vs. perform individual "scans" of the message per recipient]
[[...]] If you are going to do time-consuming things after data,
especially in a way that increases with envelope size, then LMTP becomes
painful: you want to trickle out the replies as they become available, but
you don't want to have to repeatedly commit the same message. As Claus
pointed out, Eric's draft allows a single commit point after the
per-recipient replies and before an overall final reply, which fixes the

This means the second model (final reply code) is more general and
doesn't have the drawbacks of the first one (LMTP). Moreover, it
is trivial to "embed" the LMTP model into the second by adding the
final reply code (see above). So I don't see a reason to go with
the LMTP model.