Claus,
CF> Well, RFC 2821 is a bit misleading here. A "fast" response to the final
CF> dot is not really necessary to avoid duplicate messages.
In fact, 25 years of experience are the basis for that language.
Delays in closing off transmission of the content very much DO lead to
duplicates. At every revision to Internet mail specifications, we have
pushed for less and less processing to be done interactively and more to
be deferred, for just this reason.
CF> The receiving MTA can take all the time it needs to process the message
CF> as long as it can still abort processing.
People forget that connections can terminate abnormally, such as through
a network outage. Robustness against network vagaries (delay, loss,
etc.) is one of the better indicators that a protocol is ready for
"internet prime time".
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg