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.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp