[Top] [All Lists]

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

2010-08-13 14:35:30

Steve Atkins wrote:
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.

While that's correct, the annoyance occurs because it is the last step before accepting the message. SMTP extensions can be used to anticipate certain actions; for example, draft-vesely-vhlo fantasizes about retrieving DKIM keys at the beginning of a transaction. Unlike internal/local actions, external lookups may affect timeouts beyond an admin's control.

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.

Introducing reputation systems is not going to reduce it.

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.


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.

Caching naturally favors /large/ senders, irrespectively of legitimacy.

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