[Top] [All Lists]

Re: draft-atkins-smtp-traffic-control

2011-11-02 11:43:10

On 11/2/11 6:07 AM, John C Klensin wrote:

--On Wednesday, November 02, 2011 19:25 +0800 Tim Kehres
<tim(_at_)kehres(_dot_)com>  wrote:

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
sender-selective basis, it was reasonable to assume that a
retry within a short period of time would get a connection
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
         mailbox busy or temporarily blocked for policy reasons)
Yes.  I know.  I wrote that text.  I'm not suggesting that this
newer usage is invalid, or even wrong.  I'm just suggesting that
(i) it is not precisely in line with the original model (which
may or may not be a problem) and (ii) that we did not rewrite
the discussion of the retry/queuing model, nor the maximum and
minimum timeout discussions, to reflect uses radically different
from "machine going down".  Perhaps we should have done that,
but we didn't.  From one point of view, the problem with this
practice vis-a-vis 5321 isn't that the statement you cite is
there but that the WG didn't follow up with a reanalysis of
waiting times.

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.
Let me try to be clear.   Again, I'm not advocating anything (or
pushing back on anything).  I just want to encourage people to
examine all of the options and tradeoffs.  So...

(1) Could we formalize such an extension?  Yes.  No problem.
Well within the extension model.  Whether we can reach consensu
on the details is a separate question but I believe the answer
is probably "yes", especially if it isn't purely an anti-spam

(2) Is it necessary to extend the basic response codes?  No.
There might be some advantages (as well as disadvantages) to
doing so.  IMO, someone needs to work out the use cases, the
relationships among various combinations of extended and
unextended servers, and so on and sort that out.

(3) Would such an extension be useful enough in practice, and
implemented and deployed enough in practice, to be worth the
trouble?  I don't know and don't have an opinion.

A short term "come back 15 minutes later" does not address a much greater concern. Within IPv4, categorization of dynamic or abusive sources currently abates a fair amount of undesired traffic prior to establishment of a connection. This abatement has become necessary for preserving resources within smaller networks. IPv6 will soon offer a prefix space about 400,000 times larger than IPv4 unicast space. The greater size of IPv6 and an inability to crawl its rDNS thwarts similar efforts at either collecting or publishing similar categorizations.

When receivers refuse to accept IPv6 due to failed traditional constraints, this IPv6 traffic will eventually become translated through various Large Scale NATs. After which, efforts to decide which traffic should be delayed or refused based upon the source address becomes impractical. Gray listing or applying address based bandwidth control is likely to produce undesirable results.

While SMTP could attempt to include an authentication process within SMTP exchanges, an existing structure based on tickets offers an extremely efficient alternative able to facilitate use of LSNs and offers better control than that found with "come back in 15 minutes".