[Top] [All Lists]

Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}

2021-03-18 05:37:46
On Wed 17/Mar/2021 18:44:04 +0100 Ned Freed wrote:

+Value syntax:  %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum
+Description: GREYLISTING specifies the minimum number of seconds
+that a client should wait before retrying to submit the same message.
+The presence of this limit implies that the client MAY receive a
+transient 4xx response.  See {{GREYLISTING}}


That said, I don't see why this limit necessarily has anything to do  with
greylisting. It's about how to long to wait before retying after a transient
failure, irrespective of why the delay occurred. If could be greylisting, it
could be exceeding a rate or connection limit, it could be one of the sources
for validating recipients is down, it could be the spam filtering system is
down, etc. RETRYDELAY would be a much better name for it.

Good point. By observing RCPTLIMIT, a client can avoid re-queuing delays. It stops just before reaching the limit and then starts a new transaction right away. However, this won't work if 452 was issued to split recipients according to a different criterion than the local max number.

The question then becomes is such an announcement - one that applies to all
transient failures, useful.

Applying RETRYDELAY to all transient failures doesn't seem to me to be the right thing to do. However, distinguishing among transient failures conflicts with the dog rule.

My sense is that the utility is marginal given the lengthy list of possible
causes and the fact that the best retry period for different causes could be
very different, which I note that the approach taken in the original
proposal allows.

In this moment I'm unable to think of varying delay lengths. Some considerations, for example how often a server updates some DCC database or how long does it take to reboot, may suggest a retry interval common to all transient failures that require a delay. That is, most 4xx, except splitting recipients, where immediate retry is better. So, two categories may suffice.

How about NORETRYDELAY=452?  (Just kidding...)


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>