--On Thursday, March 18, 2021 11:37 +0100 Alessandro Vesely
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.
"Avoid" and "stops"? Only maybe. If some variation on
greylisting is applied because the server doesn't approve of,
e.g., the IP address of the sender or the combination of the
reverse-path and one or more of the recipients, a published
maximum on the number of RCPT commands doesn't have anything to
do with it. And, for a variety of reasons, that might result
in a 4yz code after DATA, not anything but 250 codes after the
I see this feature as useful, but we should not over-sell it,
even to each other.
ietf-smtp mailing list