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

[John C Klensin <[e-mail]>]

--On Wednesday, March 17, 2021 10:44 -0700 Ned Freed
<[e-mail]> wrote:

> Typos fixed.
> 
>> +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}}
> 
> The primary purpose of this document is to create the
> extension and associated
> registry. The only reason some initial entries are included is
> that it's very
> helpful to have some examples to emulate. Building the entire
> registry is not
> the goal, because doing so requires that we reach consensus on
> every limit
> people can think of. This is a sure-fire recipe for document
> failure.
> 
> If past discussions are any indication, getting consensus on
> how to handle
> greylisting is going to be difficult. I don't want to make
> this document
> dependent on that.
> 
> 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.
> 
> The question then becomes is such an announcement - one that
> applies to all
> transient failures, useful. 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.

FWIW, strong agreement.

And, before we go overboard on this, I would encourage everyone
to review and think about the wise advice [1] in the last two
paragraphs of Section 2.2.1 or RFC 5321.

Personally and wearing no hats, I like the idea of a new
"LIMITS" extension and EHLO keyword.   However, I think we could
easily go overboard and start adding limits parameters on a
principle closer to "might be a neat idea" than to "strong
demonstrated need and evidence of willingness to both advertise
and use".     

If I thought anyone would pay attention, I'd argue for a much
stronger requirement for a new parameter than "Specification
required".  I don't, but I think that, not only should we be
careful that any parameters included in the spec are of clear
applicability and usefulness but that text discouraging vanity
parameters or parameters that would be of value to only one
implementation model would be desirable.  That text might be as
simple as a reference to that statement in 5321 -- perhaps
either at the end of Section 1 or as part of new comments in
Section 6 encouraging people to not go overboard.

best,
   john


[1] While that text is carried forward from RFC 1425, I didn't
write or even suggest it (IIR, Marshall Rose did), so I claim no
credit.
> 
> 				Ned
> 
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp