[Top] [All Lists]

Re: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3

2019-02-11 11:36:50
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;


ietf-smtp mailing list