[Top] [All Lists]

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

2019-12-16 22:48:53
On 12/16/19 11:36 PM, Viktor Dukhovni wrote:

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.

Sorry, I miswrote in my previous reply - "too many recipients" should be 451 of course.

I think you make a good point re: 452 vs. 552.   A server might do well to return 452 to mean "mailbox full" for some recipient, and 552 for "mailbox full" for another recipient, based on each individual recipient's usage history.


ietf-smtp mailing list