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 7:18 PM, John C Klensin <[e-mail]> wrote:
> 
> 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),

I am having trouble piecing together the fragments here, with
context not present in this message.  Therefore, I am posting
a proposed update with commentary:

4.5.3.1.10.  Too Many Recipients Code

<quote 1>
   RFC 821 [1] incorrectly listed the error where an SMTP server
   exhausts its implementation limit on the number of RCPT commands
   ("too many recipients") as having reply code 552.  The correct reply
   code for this condition is 452.
</quote 1>

The above is correct and needs no changes.

<quote 2>
                                     Clients SHOULD treat a 552 code in
   this case as a temporary, rather than permanent, failure so the logic
   below works.
</quote 2>

The above is not followed by any of the major MTAs (Exim, Postfix,
or Sendmail, nor any others reported).  It MUST be scrapped.  If
the server responds with 552, the recipient in question will
almost always be immediately bounced by the sending client.

Note, that the 552 in reply to "RCPT" will not be taken to mean
anything about the message as a whole, earlier or subsequent recipients.
If any recipients are ultimately not rejected the partially accepted
message envelope will be relayed by the client unless the server
rejects the "DATA" command.

There are no clients that abort the MAIL transaction to start again
with smaller recipient batches.  Some could take 552 (when not too
deeply pipelined) as a single to defer even recipients not yet
mentioned, that'd be fine.  I don't know of any that do that.

Instead clients typically limit the number of recipients per
envelope to somewhere south of 100 (perhaps hand-tuned for mail
destined to some of the 800lb gorilla providers), and just send
all the RCPT commands they intended to send, with perhaps the
tail of the list ending up deferred.

<quote 3>
   When a conforming SMTP server encounters this condition, it has at
   least 100 successful RCPT commands in its recipients buffer.  If the
   server is able to accept the message, then at least these 100
   addresses will be removed from the SMTP client's queue.
</quote 3>

I wish that were true.  It would certainly aid interoperability.
But the said 800lb gorilla providers have felt free to dictate
arbitrary limits below the RFC requirements, and the rest of us
have needed to make adjustments if we want to deliver list mail
to these players.  So long as the server is willing to defer
(4XX) 100-N recipients or more without prejudicing any it already
accepted, it will interoperate with clients that expect to be able
to send up to 100, despite the lower limit.

If a server both sets a lower limit, and prevents clients that
overshoot that limit from sending even the initially accepted
recipients, then the server is outside the interoperability
regime defined by the specification.  Email to the server will
only work if clients are willing to hand-tune their MTAs for
the server in question.  Such hand-tuning is not always possible
by server name or IP (in Postfix we can only hand tune envelope
recipient counts by destination domain, before the domain's
MX hosts are known).  Therefore, such servers are particularly
likely to impede email delivery when acting as MX hosts for a
large and varying set of email domains.


<quote 4>
                                                             When the
   client attempts retransmission of those addresses that received 452
   responses, at least 100 of these will be able to fit in the SMTP
   server's recipients buffer.  Each retransmission attempt that is able
   to deliver anything will be able to dispose of at least 100 of these
   recipients.
</quote 4>

Largely correct, except that again with the 800lb crowd the actual
number may be well south of 100.  And yet even the 800 pounders
should not feel quite so much at liberty to violate the specs.
Don't know what other MTAs, but Postfix expects the server (by
default) to accept 50 recipients without friction.

Another reason for fewer than 100 is when servers want have the
envelope split by some server-specific classification of recipients,
that may affect recipient-specific downstream content transformations.
In such a case the server might 452 every recipient in a class that is
different from that of the first accepted recipient.  The remaining
recipient classes would then need to be tried in a separate transaction.

Such a policy is risky when the number of distinct recipient classes is
more than a "handful", as a message sent to a large list may then
require more retries than a client is able to schedule before the message
expires.

On the other hand, messages with a large number recipients are most often
sent by mailing-list software that does automated bounce processign, and
arranges for each recipient to be associated with a separate envelope
sender address, so that bounces can be tracked back to the intended
recipient.

Only large mailings by an occasional human to a large list of friends,
romans, countrymen, ... 

<quote 5>
   If an SMTP server has an implementation limit on the number of RCPT
   commands and this limit is exhausted, it MUST use a response code of
   452 (but the client SHOULD also be prepared for a 552, as noted
   above).
</quote 5>

Yes, the server MUST respond with 452 when the intent is to have
the client "split the envelope", and send the remaining recipients
that were not accepted in a separate batch.

If, on the other hande, based on the sequence of presented recipient
addresses the server has somehow concluded that the client is a spammer,
it can of course with full knowledge of the fact that the recipients will
NOT be retried, send 552 or better yet at that point, 554.

<quote 6>
           If the server has a configured site-policy limitation on the
   number of RCPT commands, it MAY instead use a 5yz response code.  In
   particular, if the intent is to prohibit messages with more than a
   site-specified number of recipients, rather than merely limit the
   number of recipients in a given mail transaction, it would be
   reasonable to return a 503 response to any DATA command received
   subsequent to the 452 (or 552) code or to simply return the 503 after
   DATA without returning any previous negative response.
</quote 6>

This is problematic and generally pointless.  It serves no purpose and
breaks interoperability.  Clients can always send multiple copies in
separate envelopes, so such absolute limits (below 100) damage
interoperability and don't achieve the desired goal of actually stopping
the same message arriving to more than a given number of recipients.

The solution is quite simple delete the above text, the overall picture
is much simpler.  Respond with 4XX to defer and 5XX to permanently reject
a given RCPT.  There's no reason for the specification to dwell on all
the creative ways in which a decision to reject might be made.

The key thing in this section is to specify that "452" MUST be used when
the client should retry the recipient separately because too many were
sent so far to process in a single batch on the server.  The number of
"452" replies the server is willing to send without blocking message
delivery or imposing punitive delays that'll prevent transaction
completion needs to be at least 100 minus the number of initially accepted
recipients.

-- 
	Viktor.