On 2/13/2019 7:22 AM, Дилян Палаузов wrote:
My reading of:
retryhint = "retry=" time-delay
time-delay = ( [days "-"] hours ":" minutes ":" seconds) / totalsecs
totalsecs = 6*DIGIT ; 0-999999
is that retry=0 and retry=00:00:00 is the same.
Format wise, that would be the same time-delay -- zero seconds. It
was not the intent of the original HARRIS Greylisting concept and the
SMTP-GREY draft to drive a client to retry immediately by explicitly
issuing a time-delay (block time, retry hint) of zero seconds.
I don't think I like the idea of using an explicit time-value of zero
as way to try to drive a client to retry immediately.
What is the problem with immediate retry, when we are not talking about
greylistting, but about Too many recipients in this transaction?
We are talking about the concept of "greylisting" when using 4yz as a
way to perform any form of load and/or spam controls. Its a form of a
throttle whether it was "too many recipients," "too much mail," or
"too many connections," etc. You are telling the client to "slow
down," "Backoff" and "try again later." The operative word here is
For the unsolicited, unauthenticated mail sender, specific to the
limit of RCPT TO field, the client is allowed 100 (per SMTP spec). The
compliant SMTP client should know this protocol limit and the
developer should program the SMTP outbound system around this limit
and also be ready to handle a 4yz issued at any point in the SMTP
session, including before the limit is reached and possibly after the
first one. Regardless of the 4yz reasons, the MTA needs to be ready.
Specific to SMTP-GREY, an explicit hint of zero time, is not defined,
nor expected and would not be backward compatible with my existing
code and possibly clients who may be reading the reply hints in the
many forms that exist today.
Here is an idea: Why Zero? Why not use block time of 1 sec? Unless
we are dealing with "Quantum Entanglement," this should work in the
way you are looking for, no?
ietf-smtp mailing list