On Dec 4, 2019, at 5:14 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
Again, this is not a proposal, a contribution to a WG, or an
assumption that a WG will be formed (or by what mechanism). It
is just a contribution to give people an idea of what we are up
against, and what at least some of the outstanding issues are,
to consider if there is a proposal to move forward [...]
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
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
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).
Indeed shortly after 5321 appeared Postfix briefly had code to treat
552 as 452, which caused sufficient breakage for that to be reverted
fairly quickly. The document needs to be update to remove that mistake,
and the onus for any behaviour changes is on any remaining (likely none)
MTAs that still some decades later return the wrong error code for
"too many recipients".
I don't know whether it is worth mentioning that in the same section
we have:
When a conforming SMTP server encounters this condition, it has at
least 100 successful RCPT commands in its recipient buffer. If the
server is able to accept the message, then at least these 100
addresses will be removed from the SMTP client's queue. When the
client attempts retransmission of those addresses that received 452
responses, at least 100 of these will be able to fit in the SMTP
server's recipient buffer. Each retransmission attempt that is able
to deliver anything will be able to dispose of at least 100 of these
recipients.
Which I heartily endorse, but it sadly does not match today's reality
very well. The "too big to fail" cloud email providers have taken the
liberty to flout the requirement to accept at least 100 valid recipients
per envelope, and senders have had to hand-tune ad-hoc limits. I don't
know what, if anything can or should be done here to reconcile theory vs.
practice. :-(
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp