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

[Viktor Dukhovni <[e-mail]>]

> On Mar 11, 2021, at 11:13 PM, John C Klensin <[e-mail]> wrote:
> 
>  [...]
>  MAIL FROM:<[e-mail]>
>  250 ...
>  RCPT TO:<[e-mail]>
>  250 ...
>  RCPT TO:<[e-mail]>
>  250 ...
>  RCPT TO:<[e-mail]>
>  250 ...
>  [...]
>  RCPT TO:<[e-mail]>
>  552 ...
> 
> Now, upon getting that first 552, does EXIM

It is time to introduce an analogy to a famous Gary Larson THE FAR SIDE
cartoon, "What dogs hear":

	https://www.flickr.com/photos/sluggerotoole/153603564

The server may yell:

   ...
   250 <[e-mail]> at your service
   250 <[e-mail]> at your service
   552 <[e-mail]> too many recipients.
   552 <[e-mail]> too many recipients.
   552 <[e-mail]> too many recipients.
   ...

But all the sending client hears is:

   ...
   2.. ...
   2.. ...
   5.. ...
   5.. ...
   5.. ...
   ...

the client will stash away the full error code and text for
inclusion in the bounce, just in case some user or postmaster
can make some sense of it, but otherwise all those carefully
specified digits in the SMTP RFCs play no role whatsoever.

Servers are far too likely to send some random 5XX code that
does not mean exactly what the RFC intends it to mean, and in
any case the last two digits make no difference, the command
is either accepted, soft-failed or rejected permanently, and
the first digit had better signal that correctly, the rest
is irrelevant forensic information for whoever might care
to read the tea leaves.


> (1) Assume it is really like a 550, i.e., that
> <[e-mail]> is, at least for traffic coming from
> <[e-mail]>, a more or less permanently unavailable or
> non-existent address, continue with other addresses, but never
> retry <[e-mail]> and basically tell whomever or
> whatever you got the message from that it is undeliverable for
> that address.

This of course, and ditto with Postfix, Sendmail, or any other
mainstream MTA you're like to run across.


> If so, continue that "no retry" behavior for
> <[e-mail]> and the (potentially) hundreds of addresses
> that follow.

Sure, but any mainstream MTA will not send 100's of addresses
in a single envelope to strangers, since there's no reason to
expect the remote peer to be willing to accept more than 100
recipients, and by the time the message transaction has been
amortised over 100 recipients most of the benefit of batching
has been achieved.

Also list managers typically send mail to one recipient at a
time (VERP), and people rarely send mail to more than 100 readers,
so larges envelopes beyond first O(100) don't have any measurable
positive impact on MTA throughput.

> If one does not follow the advice about treating 552 as if were
> 452 and basically ignores Section 4.5.3.1.10 (since, wrt 552, it
> offers no alternate interpretation), I can justify any of the
> above on the basis of text I can find in 5321.  I may be missing
> something (wouldn't be the first time, even this week), but that
> looks like it.

Any such justification is divorced from the "What dogs hear"
reality, did the server say "2..", "4.." or "5.."? 

> So what does exim actually do?

Naturally, treats the "2XX" recipients as delievered (assuming
DATA or BDAT LAST was accepted), retries the "4XX" recipients
separately, and bounces the "5XX" recipients.  That's the only
correct client behaviour.

> For everyone else: is there any desire to narrow the options in
> 5321bis so that guidance is given as to which of the above
> options is acceptable?

Regardless of what the RFC says, client MTAs will continue to
be dogs.  The RFC can align with this reality or live in some
make believe alternative universe.

-- 
	Viktor.