[Top] [All Lists]

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

2021-03-19 09:55:31

--On Thursday, March 18, 2021 11:37 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

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
RCTP commands.

Nothing prevents a server from advertising a limit at the
beginning of session based on the sender's reputation at that

And yes, nothing prevents a limit from subsequently being adjusted during the
session, based on whatever, so that the originally advertised limit no longer
applies. This happens all the time with the SIZE extension on limited-resource
servers; it doesn't mean that SIZE isn't useful.

I see this feature as useful, but we should not over-sell it,
even to each other.

Agreed. There's already a paragraph in the document saying that it doesn't
attempt to deal with in-session limit changes. I think that's sufficient.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>