(moved over from the current "SMTP traffic control" thread to stand out from
the greylisting discussion a little)
Mail that's delivered quickly, in a minute or so, vs mail that sometimes takes
a half hour to deliver makes a difference to the end user. Both due to the
noticeable delay, and the annoyance of conversations arriving out of order.
Sometimes mailservers want to shed load, or prioritize one source of traffic
over another. The only way to do that within SMTP that doesn't require you to
keep a session open is to respond with a 4xx deferral and wait for the client
to retry.
An ESMTP client, such as your ISP smarthost, will wait a while before retrying
in response to a 4xx deferral. The RFCs say they should wait at least 30
minutes the first time.
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.
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.
Cheers,
Steve