From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
The "retry strategy" text in RFC 5321 was written more on the
assumption that most cases would be connection failures, rather
than 4yz-induced retries. It does not differentiate between the
two because, when 4yz really meant "system down or going down"
or "no service right now" on a global, rather than
sender-selective basis, it was reasonable to assume that a retry
within a short period of time would get a connection failure.
Understood, however the use of 4yz during the RCPT TO: phase has been common
for a long time now. 5321 seems to also acknowledge this in stating the
following definition for the 450 response:
450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons)
Am I being too simplistic in thinking we could formalize a retry= extension
that could be used here (as well as other contexts)? In practice many
MTA's simply tag each queue item with a timestamp at which time retries can
be valid with actual queue runs being scheduled on a regular basis (skipping
over messages not available yet for retry). For these types of systems
having the client read the response and adjust the retry time tag should not
be that difficult, and not rely upon any queuing system changes. This could
apply for greylisting, server not accepting mail (for whatever reasons),
pizza and beer break, or other unanticipated outages (either planned or
automated). On the protocol side, no need for extending the basic response
codes either.
Best Regards,
-- Tim