[Top] [All Lists]

Re: Changing RFC 5322 guidance about crlf.crlf response delay

2010-08-11 12:41:00

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 

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...?


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