ietf-smtp
[Top] [All Lists]

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

2019-12-15 22:57:33


--On Sunday, December 15, 2019 22:30 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:

[ 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.

Noting that I am nearly neutral on this question even though I
am in favor in principle in anything that would remove
requirements for unnecessary workarounds from 5321bis, thereby
making it shorter and less convoluted, I have a question that, I
believe, complements Victor's.  At present, RFC 5321 (and its
predecessors) insist that a server should accept up to 100 RCPT
commands.  I know of several, possibly many, systems that have
been configured, based on operational experience, to use much
lower limits.  Is it appropriate for us to lower the limit in
the 5321bis (and, if so, to what?) and/or to insert text
encouraging a somewhat more flexible approach to that limit?

best,
   john



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp