ietf-smtp
[Top] [All Lists]

Re: When to acknowledge messages for per-recipient data reply / deferred rcpt reply

2007-02-14 14:30:17
On Tue, 13 Feb 2007 10:57:13 CST, Grant Taylor said:

I think that (valid) recipients should be acknowledged as soon as 
(reasonably) possible.  I'm thinking about the number of sending systems 
that I've had to deal with that have had failed connections part way 
through transmission of messages.  If a recipient is acknowledged as 
soon as (reasonably) possible rather than waiting until all recipients 
have been processed it is more likely that sending systems will receive 
the acknowledgment prior to failed transmission, thus having fewer 
recipients that it needs to re-send the message for.

Do you have any firm statistics regarding what percent of "failed" were due
to actual TCP-level communications failures due to backhoe fade and dead
routers, against what percent was due to a time-out condition while the
receiving host went off and did things like virus/spam scan?

I'd expect that any production-scale system that actually allows for different
results for different recipients will want to make exactly 1 pass through the
body, accumulating N results in parallel, rather than make N passes through the
message.  As a result, all the replies will likely become ready fairly close
temporally to each other.  So there's no real expectation that for recipients
A, B, C, D we'll see A's reply much sooner than the others, unless A's
default policy is "accept with no checking at all" and B-D actually do some
checking.

I'm not sure I'd want to write the specs if we do the obvious alternative
of returning results out-of-order with respect to the ordering of RCPT TOs
originally sent - so if D is the "no checking" case, we return D A B C.

Attachment: pgpsiS8wGX6UR.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>