[Top] [All Lists]

Re: draft-atkins-smtp-traffic-control

2011-10-28 19:15:49

Steve Atkins wrote:

Hence  It's 
a very lightweight approach that allows a server to tell a cooperating client 
how long it would like the client to wait before retrying. I suspect it has 
some issues that the IETF process might object to and I'm not sure that 
extending the idea to 5xx and 2xx responses is as good an idea as it seemed at 
first, but I think it's a useful concrete example to use as a basis for 

Applying it to 5yz and 2yz unquestionably deals with SMTP protocol standard changes, expectations in protocol behavior.

A server that's doing greylisting could certainly benefit from this, but I'm not particularly interested in either focusing on the implications for greylisting nor expanding it to do other things that greylisters might find useful in this thread.

Focus is lost when you attempt to remove greylisting realities from the "temporary rejection time delays" issues.

In other words, if you remove this, your proposal boils down to two reasons to exist:

  #1 Real Server Controls at Load Limiting
  #2 Wishful Server Controls at Connection Sharing/Holding clients

For #2, you have no control - its wishful and that only way to deal violators is drop the connection. For #1, when these server issues a "wait=" time, it will be behaving like a Greylisting server because the specification will now need to define how the server will enforce the "wait=" time.

How will the server track the original sender to make sure it doesn't try again before the wait= time expires?

Just saying, Good luck in trying to get a generic SMTP traffic control using a "wait=" method without touching base with the whole, for lack of a better term, "Greylisting" concept.


Hector Santos