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

From: Todd Herr <[email-masked]>
Date: Mon, 8 Mar 2021 16:40:19 -0500

On Tue, Feb 16, 2021 at 8:19 AM Todd Herr <[email-masked]> wrote:

> On Mon, Feb 15, 2021 at 8:42 AM Alexey Melnikov <[email-masked]>
> wrote:
>
>> Hi,
>>
>> On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote:
>> > Hi all,
>> >
>> > The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code)
>> > currently says:
>> >
>> >     RFC 821 [3] 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.  Clients SHOULD treat a 552 code in
>> >     this case as a temporary, rather than permanent, failure so the
>> logic
>> >     below works.
>> >
>> > John noted that this suggestion may have outlived its usefulness
>> > and/or be inconsistent with current practice. Should it be removed
>> > and/or explicitly deprecated?
>>
>> I did a bit of digging and it doesn't look like Sendmail emits 552 or
>> treats it as 442 if received from other MTA.
>> Postfix code has this commented out with a note that this workaround
>> creates more problems than it solves, due to other meaning of 552.
>>
>> Do people have information about other MTAs (not necessarily open source)
>> on this topic?
>>
>>
> I've reached out to a few large mailbox providers and a couple of
> commercial MTA vendors on this question. Still collecting answers, but hope
> to post results here by the end of the week.
>

Long delayed and incomplete results from an informal survey of a few
providers and commercial MTA vendors (all of whom I've suggested should
make their presence known here..)

Google: Emits 452, treats 552 as permanent failure
Microsoft: Emits 550, treats 552 as permanent failure (probably)
Proofpoint MTA: No default configuration for too many recipients, so emits
whatever admin wants; treats 552 as permanent failure.

If I receive any more information, I'll post it.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*m:* 703.220.4153

`

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Mar 2021 02:22:14 -0200

> On Mar 8, 2021, at 7:40 PM, Todd Herr <[email-masked]> wrote:
> 

Are you sure that Microsoft emits "5XX" for the N+1st recipient
after accepting N == max configured recipients?

For what value of "N" are you observing this?  Is pipelining a
factor and how far ahead of the server is the client willing to
get before the 5XX responses set in?

Hard rejecting recipients when <= 100 (the smallest required rcpt
count servers are expected to support per 5321) would be rather
badly broken.  There's a good reason why the "too many recipients"
code is expected to be 452, if one wants to force envelopes to be
99 recipients or fewer.

At more than 100 recipients, it is still a good idea to reject with
452, but the client is on shakier ground for wanting to go there,
it should split the envelope barring prior knowledge that the server
is willing to accept more.

> Proofpoint MTA: No default configuration for too many recipients,
> so emits whatever admin wants; treats 552 as permanent failure.

Again, 5XX before the 101st recipient just because the envelope
has too many in one go would be wrong.  The way to encourage
the sender to split envelopes is to reject the excess ones with
452.

All that said, the RFC text in question is bogus, no client I
know of honours it.

-- 
	Viktor.

---

From: Todd Herr <[email-masked]>
Date: Thu, 11 Mar 2021 11:52:00 -0500

> get before the 5XX responses set in?

I'm sure of nothing. In the context of this working group's work on this
ticket, I asked folks who work at various mailbox providers and commercial
MTA vendors the following questions:

   1. Does your MTA emit status code 552 in response to RCPT TO when there
   are too many recipients for the current message?
   2. If your MTA encounters 552 in response to issuing a RCPT TO command
   as a client, does it treat it like a 452 code (TEMPFAIL) or 552 (PERMFAIL)?

(I also made a point of recommending that they subscribe to this mailing
list and participate in the working group's activities.)

The answers I received to my questions were reported in my previous post to
this thread.

> the sender to split envelopes is to reject the excess ones with

I'm just the messenger...

> All that said, the RFC text in question is bogus, no client I
I believe that's where we landed during the discussion on Wednesday.

-- 

`

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Mar 2021 16:18:54 -0500

--On Thursday, March 11, 2021 11:52 -0500 Todd Herr
<todd.herr=[email-masked]> wrote:

>...

> I believe that's where we landed during the discussion on

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

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 11 Mar 2021 22:07:49 +0000

On 11/03/2021 21:18, John C Klensin wrote:
> If it
> 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.
-- 
Cheers,
   Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Mar 2021 21:29:55 -0200

> On Mar 11, 2021, at 7:18 PM, John C Klensin <[email-masked]> wrote:
> 

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.

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Mar 2021 20:13:27 -0500

> 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:<[email-masked]>
  250 ...
  RCPT TO:<[email-masked]>
  250 ...
  RCPT TO:<[email-masked]>
  250 ...
  RCPT TO:<[email-masked]>
  250 ...
  [...]
  RCPT TO:<[email-masked]>
  552 ...

Now, upon getting that first 552, does EXIM

(1) Assume it is really like a 550, i.e., that
<[email-masked]> is, at least for traffic coming from
<[email-masked]>, a more or less permanently unavailable or
non-existent address, continue with other addresses, but never
retry <[email-masked]> 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
<[email-masked]> and the (potentially) hundreds of addresses
that follow.

(2) Take the first one of those (the one with
<[email-masked]>) 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Mar 2021 00:16:47 -0200

> On Mar 11, 2021, at 11:13 PM, John C Klensin <[email-masked]> wrote:
> 
>  [...]

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 <[email-masked]> at your service
   250 <[email-masked]> at your service
   552 <[email-masked]> too many recipients.
   552 <[email-masked]> too many recipients.
   552 <[email-masked]> 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.

> 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

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.

> something (wouldn't be the first time, even this week), but that

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.

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Mar 2021 22:08:50 -0500

Hi.

This is another long note, so a semi-summary first although I
would encourage everyone to read all the way through.  I think
Victor's note exposes two key issues and a couple of things not
directly related to this ticket:

(1) Independent (at least for now) about what clients do when
they get a 552, have enough servers switched to sending 452
rather than 552 when "too many recipients" is intended that the
text about interpretation of the 552 code as a 4yz one can
actually be removed (or retained only in an historical note).

(2) As I read Victor's note, there were many places where my
response was "that is what the spec say to do already".  That
implies that either Victor and I are reading the same text
differently (in which case I think some clarification effort is
in order) or that he and I are having problems understanding
each other.  I don't yet have a strong opinion as to which it
is; probably his response to this note will help with that.

In addition...

* The requirement of 100 minimum recipients is a key part of
Victor's explanation.  We may need to look at that type of limit
as well as the "size" ones that are now part of ticket #14
(whether there or in a separate ticket).  However, if we want to
minimize changes, I believe that the "operational necessity"
principle (see prior note) is sufficient to cover that case.

* Victor has made the 100 pound Gorilla argument.  I think that
argument is a serious challenge for the WG and its decisions
about scope and goals.  I'll try to address that soon in a
separate note.

Again, please keep reading.

 
> context not present in this message.

Sorry.  Was trying to keep the message from getting even
longer... and to encourage people to read the entire section.

>  Therefore, I am posting
>    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>
> 

Good.  We are on the same page so far.

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

For whatever it is worth, I don't know what it means to "bounce
a recipient".   The spec only talks about bouncing messages.
More important, I would hope that the client would accumulate
undeliverable addresses and include them in a single "bounce"
message, not send one bounce message per undeliverable recipient
for reasons I hope are obvious.  The former is certainly
consistent with behavior I've observed with other 5yz responses
to RCPT commands.   "Immediately" would imply one bounce message
per recipient.

And, of course, if the the SMTP sender getting the 552 message
from its receiver is operating in some sort of relay mode so it
can simply return the code in real time to whatever it got the
message from, that changes the story (and is not what we usually
think of as a "bounce".

But see below.

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

See my questions to Jeremy, but, if that is what they are doing,
then they are conforming to the requirement to treat 552 as 442,
because that is exactly the behavior one would expect 442 to do.
Whether they (or you) think about that as conforming behavior
doesn't make a lot of difference.  If there is a difference it
is in your suggestion above about an immediate bounce.  

And that immediate bounce, or even returning the 552 code to an
earlier SMTP sender, raises another problem.  One of the most
important principles in SMTP-land, going back to 821, is that
one does not report a message as undeliverable and then deliver
it anyway.  "Delayed" messages are an odd case for which 821->
2821-> 5321 do not have any provision, but, if the message (or,
if you prefer, address) is bounced, that is the end of it -- the
only way that message is going to be delivered to that recipient
is if the originator creates and sends what, as far as SMTP is
concerned, is a new message.

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

Good.  Again, you are describing behavior consistent with the
client treating the 552 as equivalent to 452 (or some other 4yz
code).

> tail of the list ending up deferred.

Again, consistent with treating the 552 as a 442, whether they
precisely follow the rest of the description in that section or
not.

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

But that is an issue with the current semi-hard limit of a
minimum or 100, not with the 452/552 requirements.  And, while
the text is not as precise as we might like it, clients (and,
for that matter servers) are allowed to pick lower limits under
the "Resistance to Attack" / Operational necessity principle.
So there is nothing in the above that is non-conforming, even to
the current text in 4.5.3.1.10.   And, fwiw, I note your
explanation above uses "defer" and "4XX" together, not 552.

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

Yes.  And still consistent with what 5321bis says.  In
particular, note the comments in the first paragraph of Section
7.9.

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

See above.  And a separate note to follow about the 800lb
argument.

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

Again,  5321 now allows clients and/or servers to pick a limit
lower than 100 and encourages / specifies orderly behavior when
that is done.  Modulo the recommendation to use 452 for clarity
rather than 552, that is what everyone you have described seems
to be doing in practice.

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

Yep.   If you think it is useful for either 5321bis or the A/S
to explicitly point that out and discuss it, please suggest how
and where to do that.  My personal guess (and so-far weak)
preference is that the A/S is headed for a discussion of the
practical issues and tradeoffs associated with the various cases
and options.  In particular, from the standpoint of 5321 "more
retries... before the message expires" is not 5231bis-level SMTP
problem.

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

Agreed.  See above.  Independent of where I stand personally, I
suggest that any attempt to further expand Section 3.9 to talk
about these issues would get considerable resistance from within
the WG, including from (but not limited to) those who have
suggested that 3.9 be removed entirely.   That is another
argument for taking the above discussion to the A/S.

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

Agreed.  And I think that is what the text says.  If you think
it needs clarification to distinguish between those two cases,
please say so and encourage opening of another ticket.

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

But that is precisely intended to allow for the 552/554 response
you are suggesting above.    So, "pointless", perhaps not.  More
confusing than it ought to be, maybe.  Suggestions welcome.

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

However, what I thought we heard Wednesday morning was that a
number of servers continue to send 552 where 452 is now
preferred ("preferred" may be a little weak).   As long as that
is the case, then the purpose of that extended section is to try
to explain ways to handle the situation, including both
receiving 452 and receiving 552 in a situation where it is
intended to be interpreted as 452.  If we are convinced that all
of the SMTP servers on the Internet (or enough that others don't
count -- and I'm counting gorillas who feel free to define their
own standards as one each, not by their user or daily message
counts) have followed the advice of 5321 so that no server is
any longer sending 552 when 452 (and breaking up the mail
transaction and resending) is intended, then the section should
be significantly reworked, possibly including a historical note
for servers that are still in existence but we cannot identify.  

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

And, modulo the limit of 100, which I continue to believe is
either a separate issue or no problem at all given the current
text in 5321, I believe that is exactly what that current text
says.

Again, suggested clarification welcome.

   john

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Mar 2021 23:51:51 -0500

On Thu, Mar 11, 2021 at 10:08:50PM -0500, John C Klensin wrote:

> (1) Independent (at least for now) about what clients do when they get
> a 552, have enough servers switched to sending 452 rather than 552
> when "too many recipients" is intended that the text about
> interpretation of the 552 code as a 4yz one can actually be removed
> (or retained only in an historical note).

I two decades of monitoring the Postfix users list, I've seen no reports
that I can recall of users having problems delivering mail to some
recipients due to servers incorrectly replying 552 when an envelope size
limit is exceeded.

For any 5XX "RCPT" response, Postfix arranges to bounce the message for
the recipient in question (delayed until all currently scheduled
recipients are delivered, deferred or fail, and thus consolidated across
affected failed recipients), so any non-negligible population of problem
servers would have surfaced at least a few times in the last 20 years.

> (2) As I read Victor's note, there were many places where my response
> was "that is what the spec say to do already".  That implies that
> either Victor and I are reading the same text differently (in which
> case I think some clarification effort is in order) or that he and I
> are having problems understanding each other.

Likely some of both, but I think more on the communication side.  Absent
nods in acknowledgement or quizzical looks, it is much to hard to know
when to keep it brief and when to elaborate a point.  Async
communication is fundamentally limited here, especially when multicast,
and not every reader needs the same level of detail.

> * Victor has made the [800] pound Gorilla argument.  I think that
> argument is a serious challenge for the WG and its decisions about
> scope and goals.  I'll try to address that soon in a separate note.

> a recipient".

It means that the message will not be delivered for that recipient, and
if any bounce is to be sent (non-empty envelope sender and not DSN
NOTIFY=..., which excludes failure), then this recipient will be
reported in the bounce.  Redundantly, overeloborating the point,
the recipient WILL NOT be included in any attempts to retry the
message delivery.  This should be clear now I hope.

> undeliverable addresses and include them in a single "bounce" message,
> not send one bounce message per undeliverable recipient for reasons I
> hope are obvious.

So obvious, I didn't bother to make it explicit. :-)

> then they are conforming to the requirement to treat 552 as 442,

No, definitely NOT.  A 4XX (read my reply in lieu of Jeremy, though of
course he is still quite welcome to answer for himself) results in the
recipient being added to the list of recipients to retry, while a 5XX
causes the recipient to be dropped from the list of still pending
recipients for the message and to be added to the list of recipients
to be bounced.

Perhaps you're imagining some message-level scope for these replies,
but replies to "RCPT" don't have message-level scope, they're only
about that particular recipient and nothing else.  It is full
steam ahead to deliver the message to all the 2XX recipients if
at least one has been accepted (and DATA or BDAT is accepted)
regardless of any 4XX or 5XX to some proper subset of the recipients.

> is in your suggestion above about an immediate bounce.  

Again no.  5XX "erases" the recipient, "4XX" puts the recipient
on the "try later" list.  So they're manifestly quite different.

> concerned, is a new message.

You appear to me to be thinking within a model where a message has an
atomic envelope with an indivisible group of recipients, but of course
each recipient's fate is an independent event, and MTAs routinely "split
the envelope" for any number of reasons.

When some of the recipients in an envelope that the sender had attempted
to deliver in a single transaction (had not intended to split) are
accepted, and some are temporarily deferred (and the rest rejected) the
envelope is dynamically split with the accepted batch delivered via
the first transaction, the deferred batch retried separately, and
the rejected batch included in a bounce (consolidated across all
the scheduled pre-split envelopes envelopes of the same message).

In any case you keep talking about *messages* in a context ("RCPT"
replies) which is per-recipient.  Again a 4XX or 5XX reply to "RCPT" is
NOT about the message, it signals the status of just *that* one
recipient.

> client treating the 552 as equivalent to 452 (or some other 4yz

Absolutely not.  See above.  They are fundamentally incompatible
(for the affect "RCPT"), and don't convey anything about the
transaction as a whole (unless *all* recipients temp or hard
fail).

> precisely follow the rest of the description in that section or

Still, and emphatically, nope, the two are NOT the same.

> minimum or 100, not with the 452/552 requirements.

Let's, at least for now, move on from any distraction that 452 is
functionaly equivalent to 552, it simply isn't.  And switch to the issue
of the 100 "limit" (minimum the server is required to accept, and
hence maximum a sensible client should attempt by default, barring
prior arrangements, special local knowledge, ...).

> And, while the text is not as precise as we might like it, clients
> (and, for that matter servers) are allowed to pick lower limits under
> the "Resistance to Attack" / Operational necessity principle.  So
> there is nothing in the above that is non-conforming, even to the
> current text in 4.5.3.1.10.   And, fwiw, I note your explanation above
> uses "defer" and "4XX" together, not 552.

A server is free of course to respond however it likes, but if it wants
to be interoperable, it needs to take into account that compliant
clients aren't psychic, and may legitimately attempt up to 100
recipients.  If the server wants to accept fewer recipients *per
transaction*, say 20, it needs to be willing to soft-fail (4XX/defer) up
to at least 80 subsequent "RCPT" commands, without tarpitting or other
barriers to having at least the first 20 recipients delivered.

If a client choose to initiate transactions for over 100 recipients with
"strangers", it may needs to be prepared to slow down and perhaps treat
the first "452" it encounters as a strong hint to perhaps defer all the
rest, without even attempting to try and include them.

There appears to be some logic in Exim's source code along these lines,
to stop when at least one recipient got a 2XX or 5XX when subsequently a
452 is seen.  That logic is not always a good idea, because 452 can also
signal other per-recipient resource limits, and the decision to defer
everyone else can substantially delay the remaining recipients (perhaps
beyond the message expiration time).  But this is a plausible heuristic
if it is correct in a sufficient supermajority of cases.  I guess, since
it is in the code, it is working out mostly okay...

So this is one case in which Exim appears to be reading more into the
server's reply that just the 2XX, 4XX, 5XX trichotomy.  There is no such
logic in Postfix, and none likely any time soon.

> rather than 552, that is what everyone you have described seems

[ I'm ignoring the 452/552 equivalence catnip. ]

Note that an Exim-like strategy of truncating the envelope at the first
452 works poorly in this case.  Because if the various recipients
classes (as is most likely) are sprinkled randomly through the envelope,
with high probability only one or two get through per transaction, and
as soon as there's a new class, the rest are deferred.  An envelope with
100 recipients and say 5 recipient classes, might then take ~80 retries
to deliver (and likely would never get to the tail of the list).

So the key thing here is "orderly" deferral of the 100-N recipients,
when choosing to accept N-at-a-time, where orderly does not imperil
the delivery of the first N.

> If you think it is useful for either 5321bis or the A/S

Perhaps, but lack of clear protocol guidance for servers can mean that
servers end up doing counter-productive things that harm the ecosystem,
by imposing capricious burdens on clients that the client has no way to
anticipate.  Where to explain what keeps the ecosystem in balance is a
judgement call.  I tend to favour over-communicating such messages, but
other approaches are also possible.

> please say so and encourage opening of another ticket.

Once the "treat 552" as 452" text goes away, and it is clear that all
"5XX" replies are permanent errors for the recipient in question, the
servers may mostly do as they see fit, but if it were up to me, I'd
include the "100-N" 4xx guidance for servers that wish to receive only
short envelopes, and are expecting clients retry (and ultimately
typically succeed) the rest in some separate transaction.

> confusing than it ought to be, maybe.  Suggestions welcome.

I am talking about 4XX after N < 100.  If a server determines that a
message is spam after it hits 3 honeypot addresses in the first 20 it
can start replying 5XX for the rest, though frankly I'd prefer to not
expose that side-channel as to which addresses are the honeypots and
which not.  Simpler to just reply "5XX" to DATA, or all BDAT commands.

> preferred ("preferred" may be a little weak). 

If there are such servers, that's their problem, as mentioned above, in
20 years of helping a community of users keep their MTAs humming, I've
seen no reports I can recall of such instances.

> As long as that
> intended to be interpreted as 452.

Two MTAs with a combined market share of IIRC ~90% by server count
(though not email volume, given the concentration of email hosting by
the 800 pounders) have no 552 to 452 downgrade heuristics, that ship has
sailed over the horizon and is not coming back.

> If we are convinced that all

Yes, that section has long outlived its usefulness.  The Postfix
changelog says:

    20010520
        RFC 2821 recommendation: treat a RCPT 552 reply as if the
        server sent 452. Files: smtp/smtp_proto.c, lmtp/lmtp_proto.c.

    20010607
        Safety: dropped the RFC 2821 compliant code that treats
        552 RCPT TO replies as 452. It created more problems than
        it solved. Files: smtp/smtp_proto.c, lmtp/lmtp_proto.c.

The feature lasted but a few weeks, before it was withdrawn almost 20
years ago, never to reappear.  I think that says everything that needs
to be said.

> text in 5321, I believe that is exactly what that current text

Still not going for the catnip (again).  Been there, done that... :-)

-- 
    Viktor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Mar 2021 00:21:57 -0500

(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
<[email-masked]> wrote:

> It is time to introduce an analogy to a famous Gary Larson THE
> FAR SIDE cartoon, "What dogs hear":
> 
>> <[email-masked]> and the (potentially) hundreds of
>> addresses that follow.
> 
> 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.
> 
>> 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?
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Mar 2021 01:13:46 -0500

> of the RFC 3463 variety, which actually do provide information.

Indeed, but I over-simplified somewhat.  A few of the distinctions
are broadly useful:

    * 40X and 50X codes are syntax errors.

    * 421 and 521 are server-initiated disconnects.

    * IIRC SASL is a bit more picky about some of the codes as well.

    * Otherwise, 4XX and 5XX are what dogs hear, but
      of course these are still useful as a forensic
      after-the-fact diagnostic aid.

So my take is that at the SMTP protocol layer, the fine-grained codes
are mostly cosmetic, the first digit suffices.  But for debugging
problems later, they are somewhat useful, at least to the postmaster of
the site that replied with those code when a problem report includes the
server's response.

> hear" model and doing that?

I would not suggest that servers go out of their ways to perversely
invent novel codes.  Aside from syntax errors and "Goodbye" X21
responses, servers can IMHO pretty much otherwise stick to just four
mostly interchangeable response codes: 450, 454, 550 and 554.

I can't say I'd miss most of the rest.  So I would certainly not invest
much energy in adding new precision to the existing codes, or even
necessarily keeping all the current distinctions in place, but I'm
curious to hear what others have to say about that.

Below is the list of all the codes that Postfix has built-in knowledge
of in the SMTP server, and the number of times seen in the source code.
(in addition users can set arbitrary 4XX/5XX codes in access rules):

       4 500 -- Syntax
      49 501
       4 502
      17 503
       2 504

       2 220 -- Connection
       2 221
       9 421
       2 521

       1 235 -- AUTH Success
       1 334 -- AUTH continue
       1 530 -- AUTH FAIL
       1 535

      12 250 -- OK
       1 252 -- VRFY

       1 354 -- DATA continue

       1 452 -- The reason we're here :-)
       1 552 -- The reason we're here :-)

      14 450 -- Sorry, you lose
       6 454
       7 550
       7 554

       3 458 -- ETRN
       1 459

       3 553 -- Mostly EAI misuse
       2 555 -- DSN misuse

The frequency count in lines of code is not necessarily indicative of
actual frequency of use.

So best-effort is made to use the closest approximate standard code to
the reason for a failure (there's not always a good match), but the
client code only cares about [45] and  [45]21 as special
connection-layer termination codes.

The simpler "dog" model works remarkably well.

-- 
    Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 12 Mar 2021 15:33:11 +0000

> whatever you got the message from that it is undeliverable for

Up to here, this is what Exim does.

> <[email-masked]> and the (potentially) hundreds of addresses

Contingent on 552 responses also for these following RCPT commands
(you didn't specify the response code, so I'm assuming here)
any such further 5xx responses to RCPTs would be dealt with
in the same way as the first one above.

> extension-enabled command).

No, Exim does not do this.

> as the next command.

No, Exim does not do this.  It proceeds to send further RCPTs (if
available for the message) and to send DATA (or equivalent).
-- 
Cheers,
   Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 12 Mar 2021 15:46:12 +0000

On 11/03/2021 23:29, Viktor Dukhovni wrote:
> arbitrary limits below the RFC requirements

This is outside the current work item, but:

We should consider a new method for the server to advertise limits
on RCPT before use; this would be more efficient given pipelining.

Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters
   MAX=nnn
   SINGLE_DOMAIN

These would be advisory for the client; the server would still have
to apply limits via responses to RCPT commands, and the client MUST
NOT take any different action to command responses based on the EHLO
keyword seen.  The client SHOULD choose command sequences based
on the EHLO keyword parameters, for example by issuing no more than
<nnn> RCPT commands in any single transaction performed on this connection.
-- 
Cheers,
   Jeremy

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Mar 2021 07:53:21 -0800

> Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters

If this is pursued, I suggest it be for /any/ limitation the server 
applies, not just addressing limits.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 12 Mar 2021 16:07:23 +0000

On 12/03/2021 15:53, Dave Crocker wrote:
> If this is pursued, I suggest it be for /any/ limitation the server applies, not just addressing limits.

Certainly.  Did you have a case in mind that isn't covered by
the above two parameters?

(I should have specified "taking one or more parameters from the list...")
-- 
Cheers,
   Jeremy

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Mar 2021 08:23:07 -0800

> (I should have specified "taking one or more parameters from the list...")

max line length\
max number of lines
max number of characters for total message
MIME limits (eg., nesting depth)
Unicode or other character limits

I'm not advocating for particular and am not sure any of the above are 
of practical interest, nevermind sufficient interest to standardize, but 
I think they serve as plausible examples.

d/

---

From: Todd Herr <[email-masked]>
Date: Fri, 12 Mar 2021 11:52:45 -0500

On Fri, Mar 12, 2021 at 11:23 AM Dave Crocker <[email-masked]> wrote:

> [snip]
Don't we already have this with SIZE?

-- 

`

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Mar 2021 15:07:00 -0200

> On Mar 12, 2021, at 1:46 PM, Jeremy Harris <[email-masked]> wrote:
> 
> 

I think think these would be fine extensions.  Given Dave C.'s point
perhaps:

    LIMITS RCPT=nnn SINGLEDOMAIN ...

unlike SIZE or DSN there's no need for any additional keywords in the
client's MAIL or RCPT commands, this is just advisory data from the
server to the client that aids interoperability.

A sufficiently sophisticated server might even tune such limits based
on the IP reputation and EHLO name of the connecting client.

The "LIMITS" keyword would then have an IANA registry for the individual
parameters, that might not even need standards action, just expert review
and specification required?

-- 
	Viktor.

---

From: Laura Atkins <[email-masked]>
Date: Fri, 12 Mar 2021 17:16:22 +0000

> On 12 Mar 2021, at 16:23, Dave Crocker <[email-masked]> wrote:
> 
> I'm not advocating for particular and am not sure any of the above are of practical interest, nevermind sufficient interest to standardize, but I think they serve as plausible examples.

Is there a place for ‘max connections’ - a number of places already limit the number of maximum connections that any sending system can make at one time. A way to mechanically advertise that might be useful. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Mar 2021 10:04:11 -0800

> On Fri, Mar 12, 2021 at 11:23 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

So, you are saying that it was a good idea for me both to list a variety 
of possibilities and to note that I wasn't advocating for any of them 
but merely meant them as examples?

I agree...

d/

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 12 Mar 2021 20:11:51 +0000

This may not work well in practice.  It's entirely possible that the number of permitted recipients (or any similar limitation) could change during the session as more is learned about the sender.  Such as once MAIL FROM is sent, the receiver decides that the sender is less trustworthy and will now change the max recipients on a single message.

Also, I realize the receiver could just not advertise this extension.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: Emailcore <[email-masked]> On Behalf Of Dave Crocker
> Sent: Friday, March 12, 2021 1:04 PM
> To: Todd Herr <todd.herr=[email-masked]>; Dave Crocker
> <[email-masked]>
> Cc: [email-masked]; Jeremy Harris <[email-masked]>
> Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT
>
>
> So, you are saying that it was a good idea for me both to list a variety of
> possibilities and to note that I wasn't advocating for any of them but merely
> meant them as examples?
>
> I agree...
>
>
> d/
>
> --
> Dave Crocker
> Emailcore mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/emailcore
> __;!!CQl3mcHX2A!WRXcfsJK23Rxorgw9sWm46wZmQusf8fl7BUkvDW471HsBjYa
> IlOSNUXx1Pina_ELXZIX$

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Mar 2021 12:21:58 -0800

On 3/12/2021 12:11 PM, Brotman, Alex wrote:
> This may not work well in practice.  It's entirely possible that the number of permitted recipients (or any similar limitation) could change during the session as more is learned about the sender. 

I have two responses:

    1.  Wow.

    2.  Don't advertise a number.

If the practice is widespread, then yeah, it's probably not worth doing 
the particular option.

d/

---

From: Michael Peddemors <[email-masked]>
Date: Fri, 12 Mar 2021 12:25:55 -0800

We do that.. rate limiter changes depending on sending pattern..

On 2021-03-12 12:21 p.m., Dave Crocker wrote:
>> This may not work well in practice.  It's entirely possible that the 
>> number of permitted recipients (or any similar limitation) could 
>> change during the session as more is learned about the sender. 
> 
> I have two responses:
> 
>     1.  Wow.
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "John Levine" <[email-masked]>
Date: 12 Mar 2021 15:32:24 -0500

>> Unicode or other character limits

I don't think it is a good idea to provide standard ways to say that an
implementation doesn't comply with a standard.  There's a line length limit
in the spec, it's not hard to support.

>Is there a place for ‘max connections’ - a number of places already limit the number of maximum connections that
>any sending system can make at one time. A way to mechanically advertise that might be useful. 

Intereesting question but then I ask max connections from what, a single IP, a /24,
something else?  I also worry this could be close to saying here's how to DDoS me.

Also for this particular case I'd say the excess connection should greet
with 421 and enhanced status code (it's be 4.3.7) to say too many connections.

R's,
John

---

From: Laura Atkins <[email-masked]>
Date: Sat, 13 Mar 2021 14:55:05 +0000

> On 12 Mar 2021, at 20:32, John Levine <[email-masked]> wrote:
> 
> something else?  

That would be for the folks advertising to say what they’re using and what they’re limiting by. The limits are actively in place, it’s just do we want to describe them in a more formal way. 

> I also worry this could be close to saying here's how to DDoS me.

The limits I was thinking of are policy not technology. Alex brings up a good point that the limits are not set in stone but do change depending on the reputation of the sender / mailstream / IP address. 

> with 421 and enhanced status code (it's be 4.3.7) to say too many connections.

Makes sense. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Ned Freed <[email-masked]>
Date: Mon, 15 Mar 2021 07:59:09 -0700 (PDT)

The idea of a limits extension has come up several times before, but
for various reasons never went forward.

I think this extension is an important thing to have, so I've put together the
beginnings of a specification:

  https://datatracker.ietf.org/doc/draft-freed-smtp-limits/

(I've tried to incorporate most of the ideas I've seen on the list, but have
probably missed some.)

Since this isn't directly relevant to emailcore, furthr discussion should be
taken to the ietf-smtp list, which I have cc'ed.

				Ned

P.S. One thing that's definitely missing is an acknowldgements section.
Apologies for the omissiom, but I ran out of time. It will be the first thing I
add to -01.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 15 Mar 2021 22:40:13 +0100

Hi, Ned,

> Apologies for the omissiom, but I ran out of time. It will be the first thing I

In chapter 4 there is a copy/paste error: all three paragraphs within 
this chapter refer to:

"Description: RCPTMAX specifies the maximum number of [...]"

This should be:

"Description: MAILMAX specifies the maximum number of [...]" (par. 4.1)

and

"Description: RCPTDOMAINMAX specifies the maximum number of [...]" (par. 
4.3)

which makes me think you wrote par. 4.2 before you wrote the other 
paragraphs :-)

/rolf

---

From: Ned Freed <[email-masked]>
Date: Mon, 15 Mar 2021 15:00:38 -0700 (PDT)

> which makes me think you wrote par. 4.2 before you wrote the other

Got me on that one!

				Ned

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 28 Mar 2021 13:58:02 +0100

> 	number of RCPT commands and this limit is exhausted (See

This looks like a good idea to me.

> one agrees that the above is at least worth further discussion,

https://trac.ietf.org/trac/emailcore/ticket/48

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 28 Mar 2021 14:02:46 +0100

Hi John,

Trying to concentrate on the specific text about treating 552 in response to RCPT TO as 452: based on feedback from Victor and Jeremy (and I can confirm that Isode's MTA is doing the same), I don't believe implementations are actually 552 in response to RCPT TO as 452. So I think the SHOULD requirement should be removed, with possibly some note in the document that this has changed. Do you agree?

Best Regards,
Alexey

---

From: Hector Santos <[email-masked]>
Date: Sun, 28 Mar 2021 09:52:24 -0400

> Trying to concentrate on the specific text about treating 552 in response to RCPT TO as 452: based on feedback from Victor and Jeremy (and I can confirm that Isode's MTA is doing the same), I don't…

Since 2003 or so, wcSMTP issues:

     if ((MaxRecipients > 0) && (TotalRecipients+1 > MaxRecipients)) {
         Send("552 Maximum (%d) Recipients reached.\r\n",MaxRecipients);
         smtplog("RCPT: Maximum (%d) Recipients reached.",MaxRecipients);
         return TRUE;
     }

Where MaxRecipient is by default zero (0).  Any defined value would be 
system wide -- not per AUTHorized user although I should probably add 
that for the next update. <g>

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Mar 2021 21:53:49 -0400

--On Sunday, 28 March, 2021 14:02 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Hi John,
> 
> Trying to concentrate on the specific text about treating 552
> in response to RCPT TO as 452: based on feedback from Victor
> and Jeremy (and I can confirm that Isode's MTA is doing the
> same), I don't believe implementations are actually 552 in
> response to RCPT TO as 452. So I think the SHOULD requirement
> should be removed, with possibly some note in the document
> that this has changed. Do you agree?

Yes.  But, again, up to the WG.

best,
  john

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Mar 2021 22:00:09 -0400

--On Sunday, 28 March, 2021 09:52 -0400 Hector Santos
<hsantos=[email-masked]> wrote:

> Where MaxRecipient is by default zero (0).  Any defined value
> would be system wide -- not per AUTHorized user although I
> should probably add that for the next update. <g>

Hector,

RFC 5321 said, in 2008, to use 452 for this case.  The only
justification I can see for leaving in the text that Alexey and
others have proposed removing would be if leaving it there a bit
longer would cause you to bring wcSMTP into compliance.  If the
reality is that either you know about the change and will get
around to it someday regardless of what 5321bis says or that
nothing we say (or don't say) in 5321bis will make any
difference, then it seems to me that we should eliminate
confusing text that no longer applies to a significant number of
other MTAs.

Which is it?  Are you suggesting retaining that text and, if so,
why?

  john

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Mar 2021 08:13:18 -0400

On 3/28/2021 10:00 PM, John C Klensin wrote:
> Hector, RFC 5321 said, in 2008, to use 452 for this case. The only 
> reality is that either you know about the change and will get around 
> to it someday regardless of what 5321bis says or that nothing we say 
> (or don't say) in 5321bis will make any difference, then it seems to 
> me that we should eliminate confusing text that no longer applies to 
> a significant number of other MTAs. Which is it? Are you suggesting 
> retaining that text and, if so, why?

I agree it would be better to use 452  and keep the expected SMTP 
state machine working with the 4yz (temporary) and 5yz (permanent) 
logic.  I have no comments regarding the suggested text changes.

I probably thought about it back in 2821bis and decided to leave it 
alone since it was an 821 design. Making it 452 might have created an 
unknown situation at the time.

On the receiver side, for the next update, I will make a change to use 
452 with an undocumented (why muddy the h2o) switch option to use 552 
just in case a revert is necessary.

On the client side, the SMTP client will permanently fail the 
transaction when a 5yz is seen for RCPT. No special case for 552. For 
our list server when prepared to go direct to SMTP, a 55z code will 
make the list member inactive. With 452, an error count is incremented 
for the member but not made inactive.  I need to relax this. The list 
server should check for 552 and not make the user inactive.  As long 
as no hash treatment to the limited list members is done, I don't see 
any other impact.

Thanks