[Top] [All Lists]

Re: draft-atkins-smtp-traffic-control

2011-11-02 06:44:38

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