ietf-smtp
[Top] [All Lists]

[ietf-smtp] Obsoleting RFC5321 552 -> 452 workaround (was: draft-klensin-rfc5321bis-01)

2019-12-16 21:30:33
[ 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