On Wed 17/Mar/2021 18:44:04 +0100 Ned Freed wrote:
+GREYLISTING Limit
+-------------
+
+Name: GREYLISTING
+
+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...)
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp