Re: [ietf-smtp] Obsoleting RFC5321 552 -> 452 workaround

["Peter J. Holzer" <[e-mail]>]

On 2019-12-16 22:57:26 -0500, Keith Moore wrote:
> On 12/16/19 10:30 PM, Viktor Dukhovni wrote:
>     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.
> 
> I think it would make sense for 5321bis to
> 
> a) restate that a genuine "too many recipients" error (i.e. too many RCPT TO
> commands issued, or perhaps too many RCPT TO commands with distinct recipient
> addresses issued) MUST be reported via a 452 error code.

Agree.

> b) remove the recommendation that 552 in response to RCPT TO be treated as a
> per-recipient temporary error

Agree.

> c) [maybe] state that 552 has in past versions of the SMTP specification been
> used to indicate "too many recipients", but has also unfortunately been used to
> indicate other errors which should not be treated as temporary per-recipient
> errors.

I don't think that the use for other - permanent - errors was
unfortunate. That was correct. What was unfortunate was that an error
code from the wrong category ("5" instead of "4") was used in the first
place. I thought that maybe the author of RFC 821 intended the error to
be permanent, but the "Too Many Recipients Scenario" on page 63 shows
that this is not the case. Here the 552 code is clearly treated as a
transient error. I don't know why. Maybe it was just a typo. I don't
think it matters much at this point.

>   So if a client implementation wishes to treat 552 as a per-recipient
> temporary error, it should perhaps limit the number and/or frequency of
> attempts to resend that message to that recipient.

I would rather state that some servers might still implement the error
from RFC 821 (do we have any data whether such servers exist at all and
how common they are) and that client may choose to accomodate them, but
should not generally treat 552 as a temporary errors. This might be
accomplished for example with a per-destination configuration option or
maybe some heuristics (e.g. based on the number of RCPT commands or the
text of the error message).


> (IMO, even "mailbox quota exceeded" should be treated as a temporary error, but

Yup, but that should be decided by the server, not the client. The
client should not decide that a 5xx return code was really meant to be a
4xx or vice versa.

> the retry frequency should be reduced to something like once per day.

Yes, but again, how can the client know what retry frequency is
appropriate? 

I vaguely remember that there was a draft for an extension where the
server could communicate  a hold time to the client. Something like "try
again in 5 seconds" for too many recpients or "try again in 24 hours"
for a full mailbox.

        hp


-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [e-mail]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"