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

[John C Klensin <[e-mail]>]

(top post)

Victor,

Thanks.  I'm now fairly sure I understand what you are saying.
It leads to another question,  mostly just to clarify the
implications of what you are suggesting.  We know there isn't
much precision in the second and third digits of response codes,
with the overloading of 552 as an example.  It is also the
reason we have RFC 3463 and its updates for when the server
wants to supply fine-grained information.

If SMTP clients are not paying attention to those codes anyway,
we could save many pages of 5321bis by tearing all the theory
and details of the specific three-digit codes out, specifying
that servers MAY reply with the traditional codes if they want
to but otherwise can just send x99 or some such thing and, if
they feel like being informative should just use extended codes
of the RFC 3463 variety, which actually do provide information.

Would you suggest that and, if not, why not?   Or, put
differently, where is the stopping point between your "what dogs
hear" model and doing that?

   john




--On Friday, March 12, 2021 00:16 -0200 Viktor Dukhovni
<[e-mail]> wrote:

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