[ Reposting, since the original message turned into a thread about
recipient count limits. Perhaps this attempt might elicit some
discussion on the original question.
I don't know whether this the right forum in which I should
look to find community consensus on what looks like a work-around
in RFC5321 that seems to have long outlived its use-by date. ]
To whit:
One outstanding defect in 5321 is still present in the bis draft:
https://tools.ietf.org/html/draft-klensin-rfc5321bis-01.html#section-4.5.3..1.10
<https://tools.ietf.org/html/draft-klensin-rfc5321bis-01.html#section-4.5.3.1.10>
RFC 821 [8] incorrectly listed the error where an SMTP server
exhausts its implementation limit on the number of RCPT commands
("too many recipients") as having reply code 552. The correct reply
code for this condition is 452. Clients SHOULD treat a 552 code in
this case as a temporary, rather than permanent, failure so the logic
below works.
while at the same time:
https://tools.ietf.org/html/draft-klensin-rfc5321bis-01.html#appendix-G
<https://tools.ietf.org/html/draft-klensin-rfc5321bis-01.html#appendix-G>
o Revised the reply code sections to add new 521 and 556 codes,
clarify relationships, and be explicit about the requirement for
clients to rely on first digits rather than the sequences in
Section 4.3.2.
...
If an SMTP server has an implementation limit on the number of RCPT
commands and this limit is exhausted, it MUST use a response code of
452 (but the client SHOULD also be prepared for a 552, as noted
above).
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.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp