[Top] [All Lists]

Re: [ietf-smtp] draft-klensin-rfc5321bis-01

2019-12-14 15:07:06
On Dec 4, 2019, at 5:14 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 

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:

   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:

   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

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

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. :-(


ietf-smtp mailing list