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

[Todd Herr <[e-mail]>]

On Wed, Mar 10, 2021 at 11:22 PM Viktor Dukhovni <[e-mail]>
wrote:

> > On Mar 8, 2021, at 7:40 PM, Todd Herr <[e-mail]> wrote:
> >
> > Google: Emits 452, treats 552 as permanent failure
> > Microsoft: Emits 550, treats 552 as permanent failure (probably)
>
> Are you sure that Microsoft emits "5XX" for the N+1st recipient
> after accepting N == max configured recipients?
>
> For what value of "N" are you observing this?  Is pipelining a
> factor and how far ahead of the server is the client willing to
> get before the 5XX responses set in?
>

I'm sure of nothing. In the context of this working group's work on this
ticket, I asked folks who work at various mailbox providers and commercial
MTA vendors the following questions:

   1. Does your MTA emit status code 552 in response to RCPT TO when there
   are too many recipients for the current message?
   2. If your MTA encounters 552 in response to issuing a RCPT TO command
   as a client, does it treat it like a 452 code (TEMPFAIL) or 552 (PERMFAIL)?

(I also made a point of recommending that they subscribe to this mailing
list and participate in the working group's activities.)

The answers I received to my questions were reported in my previous post to
this thread.


> Hard rejecting recipients when <= 100 (the smallest required rcpt
> count servers are expected to support per 5321) would be rather
> badly broken.  There's a good reason why the "too many recipients"
> code is expected to be 452, if one wants to force envelopes to be
> 99 recipients or fewer.
>
> At more than 100 recipients, it is still a good idea to reject with
> 452, but the client is on shakier ground for wanting to go there,
> it should split the envelope barring prior knowledge that the server
> is willing to accept more.
>
> > Proofpoint MTA: No default configuration for too many recipients,
> > so emits whatever admin wants; treats 552 as permanent failure.
>
> Again, 5XX before the 101st recipient just because the envelope
> has too many in one go would be wrong.  The way to encourage
> the sender to split envelopes is to reject the excess ones with
> 452.
>

I'm just the messenger...

>
> All that said, the RFC text in question is bogus, no client I
> know of honours it.
>
>
I believe that's where we landed during the discussion on Wednesday.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*m:* 703.220.4153

`

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.