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

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

--On Thursday, March 11, 2021 22:07 +0000 Jeremy Harris
<[e-mail]> wrote:

> On 11/03/2021 21:18, John C Klensin wrote:
>> If it
>> is in need to changing, it would be to change the SHOULD to a
>> MUST since that appears to be what everyone is doing anyway.
> 
> 
> No, it is not.  Exim does not treat a received 5xx as a 4xx.

Jeremy,

I'm happy staying with MUST --up to the WG-- but would, on
principle, like to understand what EXIM is doing and why.  In
particular, a mail transaction, with EXIM as client, looks like:

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

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

(2) Take the first one of those (the one with
<[e-mail]>) as a fatal error for more RCPT commands as
a class, skip any other target addresses you have queued up, and
move immediately to DATA (or, in principle, some
extension-enabled command).  If this option is taken, the status
of the addresses in that first problem RCTP command and those
not sent at all is uncertain relative to actions outside the
mail transaction.
 
(3) Assume it really is a fatal error (based on the "first
digit" rule, treating it more like 554, or assuming that the
server is really out of memory and would not be able to accept
DATA or the content that follows)  and send either RSET or QUIT
as the next command.  Again, status relative to trying again is
not specified.  In particular, the spec would allow the client
to give up and bounce the message, try again with the same
address list, or try again with a subset of that list, including
opting for one mail transaction per recipient with each getting
a copy of the same message.

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.

So what does exim actually do?

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?  Note that if we do so, we move into the
territory of telling implementations what to do (which the spec
does already) and then telling them what to do if they ignore
the first requirement/instruction, a strategy to which the IESG
has been known to take exception even if no one objects on Last
Call.

    john