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

[Michael Peddemors <[e-mail]>]

On 2021-02-15 3:26 p.m., Jeremy Harris wrote:
> On 15/02/2021 13:41, Alexey Melnikov wrote:
>>> 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?
> 
> 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.

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.