[Top] [All Lists]

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

2010-08-11 13:57:48

On Aug 11, 2010, at 11:16 AM, Dave CROCKER wrote:

On 8/11/2010 10:28 AM, Steve Atkins wrote:
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.

I believe that, to be meaningful, the guidance is going to have to specify a 
number that balances between leaving enough time for useful analysis versus 
avoiding the vast majority of timeouts.

I suggested two minutes in my wording, though I don't expect it to commonly 
exceed fifteen seconds.

A specification that encourages retransmission is a Bad Thing.  A 
specification that does not leave enough time for 'most' useful analysis is 
also not helpful.  Note that 'most' is a statistical assessment and that 
ultimately this topic is an efficiency hack.  Having some analysis be 
required to be deferred isn't wonderful, but it's better than having to defer 
all of it.

Taking your comment, I'll ask about a revision up to one minute for server 

However the idea that every message submission across the net will require 
the sending side to hold for one minute, every time, bothers the heck out of 

They're required to hold for ten minutes now. That won't often be needed, but 
they're required to do so if the SMTP server feels so inclined. 

The actual length of time an SMTP server will require an SMTP client to wait 
while it delivers the message is going to be driven by the operational 
requirements of the SMTP server (whether that be content-based analysis, 
internal proxying or even just waiting for an IO slot to write the message to 
disk), not by any RFC limits.

But that open connection consumes a significant amount of resources at both the 
sender and the receiver, so there's already a significant pressure to reduce it 
at large receivers. So I wouldn't expect it to increase without limit. But if 
there's a choice between occasionally keeping a connection open for another 
minute (possibly while you wait for other attempted deliveries from the same 
sender) and accepting mail for delivery that will then need to be bounced or 
discarded any decent engineer is going to do anything they can to avoid 
accepting that mail until they've made a delivery decision.

(The other alternative to holding the connection open at that point is simply 
to return a 450 response to <crlf>.<crlf>, then make delivery decisions at your 
leisure and cache those for when the SMTP client attempts redelivery. This 
causes howls of outrage from the SMTP client end of the relationship - and also 
causes much the same breakage as greylisting does).

I don't believe that legitimate senders of email are likely to commonly see 
really long delays at the end of data, and I don't much care if other senders 
are inconvenienced.

But none of that is going to change based on any changes to 5321#6.1 - all 
we're able to do there is modify the wording to more accurately reflect 
existing practice. Providing some background might convince implementors to 
make better decisions, but I suspect that's going to affect primarily the SMTP 
client developer, if anyone.


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