Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452?

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 15 Feb 2021 13:41:50 +0000

Hi,

On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote:
> Hi all,
> 
> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) 
> currently says:
> 
>     RFC 821 [3] 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.
> 
> John noted that this suggestion may have outlived its usefulness
> and/or be inconsistent with current practice. Should it be removed
> and/or explicitly deprecated?

I did a bit of digging and it doesn't look like Sendmail emits 552 or treats it as 442 if received from other MTA.
Postfix code has this commented out with a note that this workaround creates more problems than it solves, due to other meaning of 552.

Do people have information about other MTAs (not necessarily open source) on this topic?

Best Regards,
Alexey

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 15 Feb 2021 23:26:33 +0000

> Do people have information about other MTAs (not necessarily open source) on this topic?

Exim:

  As a server, there is a configuration option (default: 452)
  for too-many-recipients.
  The documentation describing it doesn't mention standards.
  553 is emitted for other conditions.

  As a client, there is no special handling for a 552; the initial
  5 is taken as for any other 5xx.
-- 
Cheers,
   Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 15 Feb 2021 23:37:32 +0000

>   553 is emitted for other conditions.

552, sorry.

-- 
Cheers,
   Jeremy

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 15 Feb 2021 15:40:08 -0800

On 2021-02-15 3:26 p.m., Jeremy Harris wrote:
>> I did a bit of digging and it doesn't look like Sendmail emits 552 or 
>> treats it as 442 if received from other MTA.
>> Postfix code has this commented out with a note that this workaround 
>> creates more problems than it solves, due to other meaning of 552.
>>

Hmmm.. why should this be a temporary failure?

  lmprintf("550 Too many invalid user RCPT's sent. Exiting.\r\n");

Permanent failure seems to be the proper response, otherwise an email 
client MAY foolishly keep trying to send to the whole list again and 
again..

And of course, another MTA may as well, when we KNOW it will fail the 
next time and the next time..

Sorry, someone will have to enlighten me..

However, it should be noted.. there 'could' be alternate cases, where 
for instance, in environments with rate limiters, it could be different 
for authenticated connections (outbound rate limiters) vs inbound rate 
limiting (MTA->MTA) vs system capabilities (Max memory limits etc 
triggered by too many RCPTS)

I don't think even in MTA-MTA traffic we want it treated as a temporary 
error, why keep trying to perform an action that will not succeed.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 15 Feb 2021 15:46:20 -0800

> error, why keep trying to perform an action that will not succeed.

Oh, to avoid confusion.. MagicMail SMTP returns..

rcpt_checks/max_rcpts.c:    return "452 Too many recipients (#4.5.3.1)";

However, the question remains.. why should it be temporary? We have 
always just done this according to RFC, but it doesn't seem logical, as 
the remote client/MTA will just queue up that batch for retry, no?

---

From: Todd Herr <[email-masked]>
Date: Tue, 16 Feb 2021 08:19:49 -0500

> Do people have information about other MTAs (not necessarily open source)
I've reached out to a few large mailbox providers and a couple of
commercial MTA vendors on this question. Still collecting answers, but hope
to post results here by the end of the week.
-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:*

`

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 16 Feb 2021 14:09:48 +0000

On 15/02/2021 23:46, Michael Peddemors wrote:
> However, the question remains.. why should it be temporary? We have always just done this according to RFC, but it doesn't seem logical, as the remote client/MTA will just queue up that batch for retry, no?

It depends what command is being responded to.

It it was a RCPT command, after several such had been accepted, a 4xx
should mean that the accepted batch are still ok for DATA, and the
remainders will need to go as a separate transaction.

Even as a response to end-of-data it's not totally unreasonable - I might imagine,
say, a disk-space check failing *because of* the number of accepted recipients.
Unusual, and I don't know if any MTA in existence does that, but possible.

On the other side of the coin, I can imaging anti-spam configured MTA deliberately
permanently-rejecting an entire message because it regards the attempted number
of RCPT commands as excessive.  So, both 4xx and 5xx are reasonable and
should mean what they mean for other "xx".
-- 
Cheers,
   Jeremy