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