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:40 p.m., Michael Peddemors wrote:
> 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.

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?



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