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 11:52 -0500 Todd Herr
<todd.herr=[e-mail]> wrote:

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

What I had not done on Wednesday, or recently enough before
then, was to carefully read the entirety of Section 4.5.3.1.10,
which explicitly calls for the behavior someone, I think you,
mentioned in a previous message, i.e., server accepts recipients
up to the limit, then generates a 452 for each succeeding RCPT
command.  Client then continues processing with the recipients
up to that point, sends the message, and then requeues the
message for additional recipients.  And the client is expected
to treat a 552 in response to RCPT as if it were a 452.  Nothing
there prohibits the client from sending messages to the
recipient addresses who got the 452 (or 552) one at a time or
even treating the very first 452 (or 552) as an indication that
it should send QUIT or RSET and start sending the message in one
recipient at a time mail transactions.  It also provides for the
server to indicate to the client that it is just not willing to
accept mail transactions with a number of recipients larger than
it wants to accept with a 503 response after DATA.

Up to that point, I think the text is consistent with what we
have been told about current practice, including treating a 552
response code as if it were temporary.  Referring back to
Wednesday's discussion and slide (I believe Slide 6), the
sentence highlighted is entirely consistent with current
practice and probably needed to keep that practice valid.  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.  I
personally think that would be a bad idea because we have no way
of knowing about all possible cases and that change probably
wouldn't accomplish anything anyway. 

That suggests that, if changes are needed, there are probably
three of them, the first two in the third paragraph of that
section ("If an SMTP server has..."), not in the first one:

(1) As I have suggested elsewhere, more explanatory
cross-references in this over-complicated document would be a
good idea.  So:

OLD:
	If an SMTP server has an implementation limit on the
	number of RCPT commands and this limit is exhausted,

NEW/PROPOSED:
	If an SMTP server has an implementation limit on the
	number of RCPT commands and this limit is exhausted (See
	Section 7.8),

Comment:
Section 7.8 ("Resistance to Attacks"), which explicitly mentions
large numbers of recipients, is not quite right for this.  More
generally, we've talked informally about flexibility for
"operational necessity" for years (I even used that phrase in
G.1) but it does not appear elsewhere in the document.  I think
it would be helpful to clarity to re-title 7.8 to "Resistance to
Attacks and Local Operational Requirements" (or something
similar) and probably to add a sentence or two there that would
indicate that attack resistance is not the only issue that might
justify local restrictions.  If people agree, text welcome.

Alexey, I have tentatively added the above as G.15.  Unless no
one agrees that the above is at least worth further discussion,
please make a ticket.

(2) That paragraph also says that the server MUST use a 452
response code in the "too many recipients" case.  I think we
should be reluctant to remove the recommendation.  Especially
given the "look at first digit only" rule, 452 is clearly better
than 552.  However, if people are uncomfortable with a MUST that
is generally violated, I recommend a SHOULD with an additional
sentence that indicates that many implementations do not follow
that recommendation.  The only justification I can think of for
removing the recommendation entirely would be if harm was
generally caused if 452 were returned.  Given the "examine first
digit" rule. it is hard to imagine such harm except in
implementations that are seriously broken.

(3) Unless we are going to overhaul things in ways radically
different from the above and unless anyone has serious
objections (and raises them soon) I intend to patch Section 4 to
better indicate the role of "too many recipients" codes in the
scheme of things.

   john