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

[Alessandro Vesely <[e-mail]>]

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
--