[Top] [All Lists]

Re: Processing after the end of DATA

2010-08-11 10:31:00

On 08/11/2010 03:42 PM, Dave CROCKER wrote:
But as Tony notes, the specific nature of the action after <CRLF>.<CRLF>
wasn't my question. My question was solely about SMTP Receiver delay in
making the response... for whatever reason -- and note that spam
filtering was actually the trigger condition for the question, not
message relaying. But again, the details weren't part of the question.

True. Sorry about contributing to topic drift.

I think my answer is that the receiver's permissible delay is governed by three concerns:

1. Doing as much as possible so as not to provoke blowback. Wasting an SMTP client's time is not so bad, wasting a human reader's time is very bad.

2. Staying within the client's specified time limit, ie. n minutes minus RTT, and noting that RTT can still be high: "The client is not required to wait longer than n minutes, and while the network is less temperamental now than it the past, RTTs of 1-2 minutes may still be observed". (In the nineties an Indian friend of mine suffered RTTs up to half an hour. I'm just guessing that two minutes may be possible now, since people do use VPN over TCP and such horrors.)

3. Accommodating standards-violating clients and NATboxes that drop connections much too quickly. "Implementers should keep in mind that in the past, some NAT implementations and clients have been observed to drop connections after less than a minute" or whatever.

I think that could/should grow a paragraph mentioning these factors, without upper case, and that they apply to all the client timeouts in principle, but particularly in practice.