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 > analysis. > > 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 > me. 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. Cheers, Steve
