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

[Alessandro Vesely <[e-mail]>]

On Tue 19/Jan/2021 17:24:55 +0100 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?


Yes, at least the last sentence (Clients... works.) should go away.

In that case, the parenthesized snippets two paragraphs below should be removed 
to.  The end of that section is not clear to me.  AIUI, I'd change it like so:

OLD:
    If an SMTP server has an implementation limit on the number of RCPT
    commands and this limit is exhausted, it MUST use a response code of
    452 (but the client SHOULD also be prepared for a 552, as noted
    above).  If the server has a configured site-policy limitation on the
    number of RCPT commands, it MAY instead use a 5yz response code.  In
    particular, if the intent is to prohibit messages with more than a
    site-specified number of recipients, rather than merely limit the
    number of recipients in a given mail transaction, it would be
    reasonable to return a 503 response to any DATA command received
    subsequent to the 452 (or 552) code or to simply return the 503 after
    DATA without returning any previous negative response.


NEW:
    If an SMTP server has an implementation limit on the number of RCPT
    commands and this limit is exhausted, it MUST use a response code of
    452.  If the server has a configured site-policy limitation on the
    number of RCPT commands, it MAY instead use a 5yz response code.  In
    particular, if the intent is to prohibit messages with more than a
    site-specified number of recipients, rather than merely limit the
    number of recipients in a given mail transaction, it would be
    reasonable to return a 503 response to any DATA command received
    subsequent to the 552 code.

I omitted "or to simply return the 503 after DATA without returning any 
previous negative response."  503 is "Bad sequence of commands".  The omitted 
phrase says it makes sense to issue 503 after a sequence of positive RCPTs, and 
I cannot see anything wrong in that sequence.

552 makes sense if, in response to the nth RCPT command, the server got a 
memory fault.  For example, it called realloc() with a size argument of 0 due 
to overflow, realloc() returned NULL, so the server lost the whole buffer and 
replied 552.  It could not accept DATA.


Best
Ale
--