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.
+1
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.