[Top] [All Lists]

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

2019-12-16 22:36:56
On Dec 16, 2019, at 10:57 PM, Keith Moore 
<moore(_at_)network-heretics(_dot_)com> wrote:

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.

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

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

(IMO, even "mailbox quota exceeded" should be treated as a temporary error, 
but the retry frequency should be reduced to something like once per day.   
Some quota exceeded errors really are brief in nature, but some users simply 
stop reading their mail for an extended period of time.)

One comment on the quota issue, I think that whether to return 552 or 452 for
over-quota mailboxes is best left to the *receiving* system, that system has
better knowledge of its policies and/or user habits, rather than second-guessed
by the sending system.  That is, if the receiving system sends 552, then no
retries, and if sends 452 then retries, I don't think the sender has enough
information to make a better choice.


ietf-smtp mailing list