On 2/11/2019 11:39 AM, Paul Smith wrote:
On 11/02/2019 16:09, Hector Santos wrote:
However, problematically, a server issuing a "retry=00:00:00" hint
would translate to a no block time delay and the client can try
again when it decides to try again.
The key point is that a server issuing ANY 'retry=' means that the
client can try again when it decides to try again. That is even if the
client understands the 'retry=' hints. It's a *hint*.
The client may look at "retry=00:05:00" and say "that's too short,
I'll try again in 20 minutes, or at "retry=04:00:00" and say "that's
too long, I'll try again in 1 hour".
The client is what determines when it will retry. Basing any scheme
around the server being able to control that is doomed to failure.
Of course, yes, the server is only providing a hint for a minimum
retry time. It is saying it is not a good idea to try again before the
block time has expired, otherwise it will be a wasted failed attempt
further delaying delivery.
Since there is no clear recommendation for a blocking time delay
(other than to keep it short as possible), this specification offers
the "retry=time-delay" hint as a method to alleviate the uncertainty
in the wasted attempts and delays in timely mail delivery.
So we are in agreement here.
But I am not sure why a "retry=0" was suggested. Is Dilyan suggesting
that client should try immediately when it sees an explicit
"retry=time-value" with a time-value of zero?
My only point is that a SMTP-GREY does not define an explicit
time-value of zero. But software wise with existing code, I don't see
any other interpretation other than basic fall thru logic of keeping
with the client's normal retry schedule, and not to be interpreted as
retry immediately, don't wait.
In our code, the normal logic is to get the next retry time (in secs)
from the retry tables as a function of # of attempts thus far and also
socket error, if any. If the response string has a reply hint (value
is greater than zero), this hint time is used to replace the next time
already.
The logic is like this:
// logic fo 4yz response string.
nSecs = GetNextAttemptSecs(nAttempts, nLastError);
if (nSecs == 0) return CREATE_BOUNCE;
nHintSecs = ExtractRetryHint(sResponseString);
if (nHintSecs > 0) nSecs = nHintSecs
nSecs is then used to calculate the next attempt time based on the
last attempt time.
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. As you said,
the client will decide anyway. Plus, now, you get into the idea of a
Zero vs Null in the parser function and a new return value
interpretation is required, i.e. return a negative value to mean "No
Hint" provided.
nHintSecs = ExtractRetryHint(sResponseString);
if (nHintSecs > -1) nSecs = nHintSecs;
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp