On 12/16/19 10:30 PM, Viktor Dukhovni wrote:
This work-around was briefly trialed in Postfix about ten years back and
quickly abandoned. It led to substantial volumes of mail clogging the
queue until all ~5 days of retries expire. The reason being that not
all 552 errors at "RCPT TO" are in fact "too many recipients" errors,
and indeed given that servers are required to send "452", the majority
of these were hard mailbox quota errors or similar. Treating these
as 452 and retrying was harmful to both sending and receiving systems.
I therefore seek community consensus (is there a WG for this, is this
list sufficient, ....?) to drop the work-around from 5321bis. Servers
have now had plenty of time (over a decade) to switch from 552 to 442
on too many recipients.
I think it would make sense for 5321bis to
a) restate that a genuine "too many recipients" error (i.e. too many
RCPT TO commands issued, or perhaps too many RCPT TO commands with
distinct recipient addresses issued) MUST be reported via a 452 error code.
b) remove the recommendation that 552 in response to RCPT TO be treated
as a per-recipient temporary error
c) [maybe] state that 552 has in past versions of the SMTP specification
been used to indicate "too many recipients", but has also unfortunately
been used to indicate other errors which should not be treated as
temporary per-recipient errors. So if a client implementation wishes
to treat 552 as a per-recipient temporary error, it should perhaps limit
the number and/or frequency of attempts to resend that message to that
recipient.
(IMO, even "mailbox quota exceeded" should be treated as a temporary
error, but the retry frequency should be reduced to something like once
per day. Some quota exceeded errors really are brief in nature, but
some users simply stop reading their mail for an extended period of time.)
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp