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
