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 4.5.3.2 could/should grow a paragraph mentioning these
factors, without upper case, and that they apply to all the client
timeouts in principle, but particularly 4.5.3.2.6 in practice.
Arnt