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

[Viktor Dukhovni <[e-mail]>]

> 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?

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.

All that said, the RFC text in question is bogus, no client I
know of honours it.

-- 
	Viktor.