--On Wednesday, March 17, 2021 10:44 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> 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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp