On Aug 11, 2010, at 10:19 AM, Dave CROCKER wrote:
On 8/11/2010 9:53 AM, Murray S. Kucherawy wrote:
"Long delays after the<CRLF>.<CRLF> is received can
result in timeouts and duplicate messages. Deferring
detailed message analysis until after the SMTP
connection has closed can result in non-delivery
notifications, possibly sent to incorrect addresses. A
receiver-SMTP MUST carefully balance these two
considerations, i.e., the time required to respond to
the final<CRLF>.<CRLF> end of data indicator and the
desirable goal of rejecting undeliverable or
unacceptable messages at SMTP time."
I like this text. I think it reflects current operational realities quite
nicely.
Although we can't offer a precise algorithm, because we don't know enough and
because network variances make this problematic to do at all, the draft text
doesn't provide any assistance beyond "thar be dragons". At the least, we
should try to offer tradeoffs, factors, and may even (sudder) a heuristic.
For example, a delay time of up to 2 seconds is probably pretty safe.
Many of the things you're going to want to do in that time will take
longer than that. There's a long tail, but I'd expect to see some
processing take a minute or more in rare cases.
What's the failure mode at that point in the transaction - are we
defending against a transport failure, or the client violating spec
with timeouts or...?
Cheers,
Steve