Steve Atkins wrote:
Hence https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/ 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
discussion.
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.
--
Sincerely
Hector Santos
http://www.santronics.com