rfc9422.original.xml   rfc9422.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY EOverbar "&#275;">]> <!-- from original, but 275 = x0113 ]>
= e-macron, not overbar -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- JcK: From -04a, converted to RFCXMLv3 and processed manually
thereafter -->
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<!-- -04a: Converted from Ned's -03 20221103
-04b: Started 20221107: first round of changes, posting version
-05a: Started 20221110: IESG change of status, maybe Dave's
comments of 2022-11-10 about changes Dave would have
approved.
Fixed typo per Gene Hightower email 20221202
-05b 2023-06-27 - started updates corresponding to Dave's review
and encouraged by Murray
-05c 2023-07-27 - more of that set of updates. Posting version
-05d 2023-07-28 Fixed typo in Ned's passing date. Real posting version
-05e 2023-08-03 Put in fake email address for Ned per email conversation
with Murray. Added snark note at the beginning. Post after giving
IESG until the end of the day. Posting version.
-06a 2023-08-03 Started in response to Murray's AD review (see
email). Added the point to the Github bug report about the
author email address mess.
06b 2023-09-05. Corrected XML errors in 06a, reworked
IANA registration per email with Murray and existence
of draft-klensin-iana-consid-hybrid. Posting version.
07a 2023-09-06 Started to correct typos.
07b 2023-10-04 Corrections and changes for Last Call comments,
including IANA ones. Posting copy 2023-10-23 per note from
Murray dated 2023-10-22
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -freed-smtp-limits-07" number="9422" submissionType="IETF" category="std" consen sus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRefs="tru e" symRefs="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-freed-smtp-limits-07"
category="std" obsoletes="" updates="" submissionType="IETF"
xml:lang="en" sortRefs="true" symRefs="true" version="3"
consensus="true">
<!-- xml2rfc v2v3 conversion 3.15.2 --> <!-- xml2rfc v2v3 conversion 3.15.2 -->
<front> <front>
<title abbrev="LIMITS Extension">The LIMITS SMTP Service Extension</title> <title abbrev="LIMITS Extension">The LIMITS SMTP Service Extension</title>
<seriesInfo name="Internet-Draft" value="draft-freed-smtp-limits-07"/> <seriesInfo name="RFC" value="9422"/>
<author initials="N." surname="Freed" fullname="Ned Freed"> <author initials="N." surname="Freed" fullname="Ned Freed">
<organization> (deceased) </organization> <organization/>
<address> <address/>
<!-- Bogus email, per rejection of version without it, support
ticket [rt5.ietf.org #19962], and discussion with Murray and
another few IESG members at, and shortly after IETF 117 -->
<email> ned.freed@deceased.alt </email>
</address>
</author> </author>
<author initials="J." surname="Klensin" fullname="John C. Klensin"> <author initials="J." surname="Klensin" fullname="John C. Klensin">
<organization/> <organization/>
<address> <address>
<postal> <postal>
<street>1770 Massachusetts Ave, Suite 322</street> <street>1770 Massachusetts Ave, Suite 322</street>
<city>Cambridge</city> <city>Cambridge</city>
<region>MA</region> <region>MA</region>
<code>02140</code> <code>02140</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>john-ietf@jck.com</email> <email>john-ietf@jck.com</email>
</address> </address>
</author> </author>
<date year="2023" month="October" day="23"/> <date year="2024" month="February"/>
<area>ART</area> <area>ART</area>
<keyword>Internet-Draft</keyword> <keyword>SMTP</keyword>
<keyword>SMTP</keyword>
<keyword>LMTP</keyword> <keyword>LMTP</keyword>
<keyword>Message Submission</keyword> <keyword>Message Submission</keyword>
<keyword>ESMTP</keyword> <keyword>ESMTP</keyword>
<keyword>Extension</keyword> <keyword>Extension</keyword>
<abstract> <abstract>
<t>This document defines a "Limits" extension for the Simple Mail <t>This document defines a LIMITS extension for the Simple Mail
Transfer Protocol (SMTP), including submission, as well as the Transfer Protocol (SMTP), including submission, as well as the
Local Mail Transfer Protocol (LMTP). It also defines an associate d Local Mail Transfer Protocol (LMTP). It also defines an associate d
limit registry. The extension provides the means for an SMTP, sub mission, limit registry. The extension provides the means for an SMTP, sub mission,
or LMTP server to inform the client of limits the server intends to apply or LMTP server to inform the client of limits the server intends to apply
to the protocol during the current session. The client is then ab le to adapt to the protocol during the current session. The client is then ab le to adapt
its behavior in order to conform to those limits.</t> its behavior in order to conform to those limits.</t>
</abstract> </abstract>
<note>
<t> RFC Editor: Please remove this note before publication.
Please also remove the problematic email address.</t>
<t> This version (-07) of the draft, and the immediately prior
ones (-05 and -06)
show a deliberately bogus address for the late Ned Freed
because, at the time of its posting, the
IETF's I-D submission tools and mechanisms, apparently even
including tools available to the Secretariat for manual
posting, insisted that all authors have email addresses, even
authors who had passed away.</t>
<t>After a delay of some days after -05 was posted, the issue was
formally reported at
https://github.com/ietf-tools/datatracker/issues/6114</t></note>
</front> </front>
<middle> <middle>
<section anchor="problems" numbered="true" toc="default"> <section anchor="problems" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Simple Mail Transfer Protocol provides the ability to <t>The Simple Mail Transfer Protocol provides the ability to
transfer <xref target="SMTP" format="default"/> or submit transfer <xref target="RFC5321" format="default"/> or submit
<xref target="SUBMIT" format="default"/> multiple email messages <xref target="RFC6409" format="default"/> multiple email message
s
from one host to another, each with one or more recipients, from one host to another, each with one or more recipients,
using a single or multiple connections.</t> using a single or multiple connections.</t>
<t>The Local Mail Transfer Protocol <t>The Local Mail Transfer Protocol
<xref target="LMTP" format="default"/> provides the ability <xref target="RFC2033" format="default"/> provides the ability
to deliver messages to a system without its own mail queues. Lik e to deliver messages to a system without its own mail queues. Lik e
SMTP, it allows multiple messages with multiple recipients.</t> SMTP, it allows multiple messages with multiple recipients.</t>
<t>In order to conserve resources as well as protect themselves from <t>In order to conserve resources as well as protect themselves from
malicious clients, it is necessary for servers to enforce limits malicious clients, it is necessary for servers to enforce limits
on various aspects of the protocol, e.g., a limit on the number on various aspects of the protocol, e.g., a limit on the number
of recipients that can be specified in a single transaction.</t> of recipients that can be specified in a single transaction.</t>
<t>Additionally, servers may also wish to alter the limits they <t>Additionally, servers may also wish to alter the limits they
apply depending on their assessment of the reputation of a particular apply depending on their assessment of the reputation of a particular
client.</t> client.</t>
<t>The variability of the limits that may be in effect creates a <t>The variability of the limits that may be in effect creates a
situation where clients may inadvertently exceed a particular server's situation where clients may inadvertently exceed a particular server's
limits, causing servers to respond with temporary (or in some limits, causing servers to respond with temporary (or in some
cases, permanent) errors. This in turn can lead to delays or even cases, permanent) errors. This in turn can lead to delays or even
failures in message transfer.</t> failures in message transfer.</t>
<t>The "Limits" extension provides the means for a server <t>The LIMITS extension provides the means for a server
to inform a client about specific limits in effect for to inform a client about specific limits in effect for
a particular SMTP or LMTP session in the EHLO or LHLO command response. a particular SMTP or LMTP session in the EHLO or LHLO command response.
This information, combined with the This information, combined with the
inherent flexibility of these protocols, makes it possible for clients inherent flexibility of these protocols, makes it possible for clients
to avoid server errors and the problems they cause.</t> to avoid server errors and the problems they cause.</t>
<t>SMTP and LMTP servers have always been able to announce a limit using <t>SMTP and LMTP servers have always been able to announce a limit using
distinguished syntax in a reply, but this approach requires that the distinguished syntax in a reply, but this approach requires that the
client first needs to issue a command. The mechanism specified here client first needs to issue a command. The mechanism specified here
avoids the overhead of that approach by announcing limits prior to any avoids the overhead of that approach by announcing limits prior to any
substantive interaction.</t> substantive interaction.</t>
<t>Limits are registered with the IANA. Each registration includes <t>Limits are registered with the IANA. Each registration includes
the limit name, value syntax, and a description of its semantics.</t> the limit name, value syntax, and a description of its semantics.</t>
</section> </section>
<section anchor="Terminology" numbered="true" toc="default"> <section anchor="Terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<!-- Murray complained (email 2023-08-03 14:54 -0700) that text
did not exactly match RFC 8174. New version below. ... <t>
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDE "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
D", "MAY", ",
and "OPTIONAL" are to be interpreted as described in BCP "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119" format="default"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8174" format="default"/>.</t> --> be
<t> The key words "MUST", "MUST NOT", "REQUIRED", interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
"SHALL", "SHALL target="RFC8174"/> when, and only when, they appear in all capitals, as
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOM shown here.
MENDED", </t>
"MAY", and "OPTIONAL" in this document are to be interp
reted as <t>This specification uses the Augmented Backus-Naur Form
described in BCP 14 <xref target="RFC5234" format="default"/> notation and
<xref target="RFC2119" format="default"/> its core rules to define the formal syntax of the LIMI
<xref target="RFC8174" format="default"/> TS extension.</t>
when, and only when, they
appear in all capitals, as shown here.</t>
<t>This specification uses the Augmented Backus-Naur Form
<xref target="ABNF" format="default"/> notation and
its core rules to define the formal syntax of the "Lim
its" extension.</t>
<t>This specification makes extensive use of the terminology specified <t>This specification makes extensive use of the terminology specified
and used in <xref target="SMTP" format="default"/>.</t> and used in <xref target="RFC5321" format="default"/>.</t>
</section> </section>
<section anchor="Extension" numbered="true" toc="default"> <section anchor="Extension" numbered="true" toc="default">
<name>The "Limits" SMTP Extension</name> <name>The LIMITS SMTP Extension</name>
<t>Extensions to SMTP are defined in Section 2.2 of <xref target="SMTP" fo <t>The extension mechanism for SMTP is defined in Section 2.2 of the curre
rmat="default"/>. <xref target="LMTP" format="default"/> nt
SMTP specification <xref target="RFC5321a"/>.
<xref target="RFC2033" format="default">LMTP</xref>
inherits SMTP's extension mechanism.</t> inherits SMTP's extension mechanism.</t>
<t>The name of the extension is "Limits". Servers implementing this <t>The name of the extension is LIMITS. Servers implementing this
extension advertise an additional "LIMITS" EHLO (LHLO in LMTP) keyword. The extension advertise a LIMITS as a keyword in the response to EHLO
(LHLO for LMTP). The
associated parameter is used by the server to communicate one or associated parameter is used by the server to communicate one or
more limits, each with an optional value, to the client. The syntax more limits, each with an optional value, to the client. The syntax
of the parameter is:</t> of the parameter is:</t>
<artwork type="abnf" name="" align="left" alt=""><![CDATA[ <sourcecode type="abnf"><![CDATA[
limits-param = limit-name-value 0*[SP limit-name-value] limits-param = limit-name-value 0*[SP limit-name-value]
limit-name-value = limit-name ["=" limit-value] limit-name-value = limit-name ["=" limit-value]
limit-name = 1*(ALPHA / DIGIT / "-" / "_") limit-name = 1*(ALPHA / DIGIT / "-" / "_")
limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";" limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";"
]]></sourcecode>
]]></artwork> <t>This extension introduces no new SMTP commands and does not
<t>This extension introduces no new SMTP commands, and does not
alter any existing command. However, it is possible for a alter any existing command. However, it is possible for a
LIMITS parameter to be associated with another SMTP extension LIMITS parameter to be associated with another SMTP extension
that does these things.</t> that does these things.</t>
<section anchor="limits" numbered="true" toc="default"> <section anchor="limits" numbered="true" toc="default">
<name>Limits</name> <name>Limits</name>
<t>In order to achieve consistent behavior, all limits MUST be <t>In order to achieve consistent behavior, all limits
<bcp14>MUST</bcp14> be
registered with the IANA, as described below.</t> registered with the IANA, as described below.</t>
</section> </section>
<section anchor="limit-naming-conventions" numbered="true" toc="default"> <section anchor="limit-naming-conventions" numbered="true" toc="default">
<name>Limit Naming Conventions</name> <name>Limit Naming Conventions</name>
<t>Limit names MUST be comprehensible, but also should <t>Limit names <bcp14>MUST</bcp14> be comprehensible, but also should
be kept as short as possible. The use of commonly understood be kept as short as possible. The use of commonly understood
abbreviations, e.g., "MAX" for "maximum", is encouraged.</t> abbreviations, e.g., "MAX" for "maximum", is encouraged.</t>
<t>When a limit is associated with a particular command, its name <t>When a limit is associated with a particular command, its name
SHOULD begin with the name of that command.</t> <bcp14>SHOULD</bcp14> begin with the name of that command.</t>
<t>Limit names SHOULD end with one or more terms that describe <t>Limit names <bcp14>SHOULD</bcp14> end with one or more terms that des
cribe
the type of limit.</t> the type of limit.</t>
</section> </section>
<section anchor="interaction-with-pipelining" numbered="true" toc="default "> <section anchor="interaction-with-pipelining" numbered="true" toc="default ">
<name>Interaction With Pipelining</name> <name>Interaction with Pipelining</name>
<t>The "Pipelining" extension <xref target="PIPELINING"
<t>The "Pipelining" extension <xref target="RFC2920"
format="default"/> is commonly used format="default"/> is commonly used
to improve performance, especially over high latency to improve performance, especially over high latency
connections. Pipelining allows entire transaction connections. Pipelining allows an entire transaction
to be sent without checking responses and in some cases it may be to be sent without checking responses, and in some cases it may be
possible to send multiple transactions.</t> possible to send multiple transactions.</t>
<t>The use of pipelining affects limits in an important way: Since <t>The use of pipelining affects the LIMITS extension in an important wa y: Since
a pipelining client cannot check intermediate command responses a pipelining client cannot check intermediate command responses
without stalling the pipeline, it cannot count the number of without stalling the pipeline, it cannot count the number of
successful versus failed responses and adjust its behavior accordingly. successful versus failed responses and adjust its behavior accordingly.
Limit designers need to take this into account.</t> Limit designers need to take this into account.</t>
<t>For example, it may seem like it would be better to impose a limit <t>For example, it may seem like it would be better to impose a limit
on the number of successful RCPT TO commands as opposed to the on the number of successful RCPT TO commands as opposed to the
way the RCPTMAX limit is specified in <xref target="RCPTMAX" format="default"/> below. But way the RCPTMAX limit is specified in <xref target="RCPTMAX" format="default"/> below. But
counting the total number of RCPT TOs is simple, whereas counting the total number of RCPT TOs is simple, whereas
counting the number of successful RCPT TO stalls the pipeline.</t> counting the number of successful RCPT TO stalls the pipeline.</t>
</section> </section>
<section anchor="varying-limits" numbered="true" toc="default"> <section anchor="varying-limits" numbered="true" toc="default">
<name>Varying Limits</name> <name>Varying Limits</name>
<t>This extension provides an announcement as part of the reply to <t>This extension provides an announcement as part of the reply to
an EHLO command.</t> an EHLO command.</t>
<t>Some servers vary their limits, as a session <t>Some servers vary their limits, as a session
progresses, based on their obtaining more information. progresses, based on their obtaining more information.
This extension does not attempt to handle in-session limit changes.</t> This extension does not attempt to handle in-session limit changes.</t>
</section> </section>
<section anchor="interaction-with-smtp-minimums" numbered="true" toc="defa ult"> <section anchor="interaction-with-smtp-minimums" numbered="true" toc="defa ult">
<name>Interaction With SMTP Minimums</name> <name>Interaction with SMTP Minimums</name>
<t>Section 4.5.3.1 of <xref target="SMTP" format="default"/> <t>SMTP specifies minimum values for
specifies minimum values for various server sizes, limits, and timeouts
various server sizes, limits, and timeouts, e.g., servers <xref format="default" target="RFC5321b"/>, e.g., servers must
must accept a minimum of 100 RCPT TO commands
accept a minimum of 100 RCPT TO commands (section 4.5.3.1 <xref target="RFC5321c"/>).
.8). Unfortunately, the reality is that servers routinely impo
Unfortunately, the reality is that servers routinely imp se smaller
ose smaller
limits than what SMTP requires, and when this is done it is especially limits than what SMTP requires, and when this is done it is especially
important for clients to be aware that this is happening. </t> important for clients to be aware that this is happening. </t>
<t>For this reason there is no requirement that the limits <t>For this reason there is no requirement that the limits
advertised by this extension comply with the minimums imposed advertised by this extension comply with the minimums imposed
by SMTP.</t> by SMTP.</t>
</section> </section>
<section anchor="multiple-ehlo-commands" numbered="true" toc="default"> <section anchor="multiple-ehlo-commands" numbered="true" toc="default">
<name>Multiple EHLO Commands</name> <name>Multiple EHLO Commands</name>
<t>These protocols require that the EHLO command (LHLO in LMTP) be <t>These protocols require that the EHLO command (LHLO in LMTP) be
reissued under certain circumstances, e.g., after succe ssful reissued under certain circumstances, e.g., after succe ssful
authentication <xref target="AUTH" format="default"/> or negotiation of a securi authentication <xref target="RFC4954" format="default"/> or negotiation of a sec
ty layer <xref target="STARTTLS" format="default"/>.</t> urity layer <xref target="RFC3207" format="default"/>.</t>
<t>Servers MAY return updated limits any time the protocol requires <t>Servers <bcp14>MAY</bcp14> return updated limits any time the protoco
l requires
clients to reissue the EHLO command.</t> clients to reissue the EHLO command.</t>
<t>Clients MUST discard any <t>Clients <bcp14>MUST</bcp14> discard any
previous limits in favor of those provided by the most recent previous limits in favor of those provided by the most recent
EHLO. This includes the case where the original EHLO provided EHLO. This includes the case where the original EHLO provided
a set of limits but the subsequent EHLO did not; in this a set of limits but the subsequent EHLO did not; in this
case the client MUST act as if no limits were communicated.</t> case, the client <bcp14>MUST</bcp14> act as if no limits were communicated.</t>
</section> </section>
<section anchor="syntax-errors-in-the-limits-parameter-value" numbered="tr ue" toc="default"> <section anchor="syntax-errors-in-the-limits-parameter-value" numbered="tr ue" toc="default">
<name>Syntax Errors in the LIMITS Parameter Value</name> <name>Syntax Errors in the LIMITS Parameter Value</name>
<t>Syntax errors in the basic parameter syntax are best handled by <t>Syntax errors in the basic parameter syntax are best handled by
ignoring the value in its entirety; in this case clients SHOULD ignoring the value in its entirety; in this case, clients <bcp14>SHOULD</bcp14>
proceed as if the LIMITS extension had not been used.</t> proceed as if the LIMITS extension had not been used.</t>
<t>Syntax or other errors in the value syntax of a specific <t>Syntax or other errors in the value syntax of a specific
limit, including unrecognized value keywords, are limit, including unrecognized value keywords, are
best handled by ignoring that limit; in this case the cli best handled by ignoring that limit; in this case, the cl
ent ient
MUST <!-- changed from SHOULD per Dave Crocker note <bcp14>MUST</bcp14>
2022-11-10 -->
proceed as if that limit had not been specified.</t> proceed as if that limit had not been specified.</t>
<t>It is possible that future specification may create <t>It is possible that a future specification may create
multiple limits that are interrelated in some way; in thi multiple limits that are interrelated in some way; in thi
s case s case,
that specification MUST specify how an error in the value that specification <bcp14>MUST</bcp14> specify how an err
syntax of or in the value syntax of
one limit affects the other limits.</t> one limit affects the other limits.</t>
</section> </section>
<section anchor="caching-of-limit-settings-between-sessions" numbered="tru e" toc="default"> <section anchor="caching-of-limit-settings-between-sessions" numbered="tru e" toc="default">
<name>Caching of Limit Settings Between Sessions Involving the <name>Caching of Limit Settings between Sessions Involving the
Same Client and Server SMTP</name> Same Client and Server SMTP</name>
<t>Clients MAY cache limits determined during one session <t>Clients <bcp14>MAY</bcp14> cache limits determined during one session
and use them to optimize their behavior for subsequent and use them to optimize their behavior for subsequent
sessions. However, since servers are free to adjust their sessions. However, since servers are free to adjust their
limits at any time, clients MUST be able to accommodate limits at any time, clients <bcp14>MUST</bcp14> be able to accommodate
any limit changes that occur between sessions.</t> any limit changes that occur between sessions.</t>
</section> </section>
</section> </section>
<section anchor="initial-limits" numbered="true" toc="default"> <section anchor="initial-limits" numbered="true" toc="default">
<name>Initial Limits</name> <name>Initial Limits</name>
<t>An initial set of limits is specified in the following sections.</t> <t>An initial set of limits is specified in the following sections.</t>
<section anchor="mailmax-limit" numbered="true" toc="default"> <section anchor="mailmax-limit" numbered="true" toc="default">
<name>MAILMAX Limit</name> <name>MAILMAX Limit</name>
<t>Name: MAILMAX</t> <dl>
<t>Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum</t> <dt>Name:</dt><dd>MAILMAX</dd>
<t>Description: MAILMAX specifies the maximum number of transactions <dt>Value syntax:</dt><dd>%x31-39 0*5DIGIT ; "0" not allowed, six-digit
maximum</dd>
<dt>Description:</dt><dd>MAILMAX specifies the maximum number of transac
tions
(MAIL FROM commands) the server will accept in a single session. The (MAIL FROM commands) the server will accept in a single session. The
count includes all MAIL FROM commands, regardless of whether they count includes all MAIL FROM commands, regardless of whether they
succeed or fail.</t> succeed or fail.</dd>
<t>Restrictions: None.</t> <dt>Restrictions:</dt><dd> None.</dd>
<t>Security Considerations: See <xref target="Seccons" format="default"/ <dt>Security Considerations:</dt><dd> See <xref target="Seccons" format=
></t> "default"/></dd>
</dl>
</section> </section>
<section anchor="RCPTMAX" numbered="true" toc="default"> <section anchor="RCPTMAX" numbered="true" toc="default">
<name>RCPTMAX Limit</name> <name>RCPTMAX Limit</name>
<t>Name: RCPTMAX</t> <dl>
<t>Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum</t> <dt>Name:</dt> <dd>RCPTMAX</dd>
<t>Description: RCPTMAX specifies the maximum number of RCPT TO commands <dt>Value syntax:</dt><dd> %x31-39 0*5DIGIT ; "0" not allowed, six-digit
maximum</dd>
<dt>Description:</dt> <dd>RCPTMAX specifies the maximum number of RCPT T
O commands
the server will accept in a single transaction. It is not a limit the server will accept in a single transaction. It is not a limit
on the actual number of recipients the message ends up being sent to; on the actual number of recipients the message ends up being sent to;
a single RCPT TO command may produce multiple recipients or, in the a single RCPT TO command may produce multiple recipients or, in the
event of an error, none.</t> event of an error, none.</dd>
<t>Restrictions: None.</t> <dt>Restrictions:</dt> <dd>None.</dd>
<t>Security Considerations: See <xref target="Seccons" format="default"/ <dt>Security Considerations:</dt> <dd>See <xref target="Seccons" format=
></t> "default"/></dd>
</dl>
</section> </section>
<section anchor="rcptdomainmax-limit" numbered="true" toc="default"> <section anchor="rcptdomainmax-limit" numbered="true" toc="default">
<name>RCPTDOMAINMAX Limit</name> <name>RCPTDOMAINMAX Limit</name>
<t>Name: RCPTDOMAINMAX</t> <dl>
<t>Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum</t> <dt>Name:</dt> <dd>RCPTDOMAINMAX</dd>
<t>Description: RCPTDOMAINMAX specifies the maximum number of different <dt>Value syntax:</dt> <dd> %x31-39 0*5DIGIT ; "0" not allowed, six-digi
domains t maximum</dd>
<dt>Description:</dt> <dd>RCPTDOMAINMAX specifies the maximum number of
different domains
that can appear in a recipient (RCPT TO) address within a single that can appear in a recipient (RCPT TO) address within a single
session. This limit is imposed by some servers that bind to session. This limit is imposed by some servers that bind to
a specific internal delivery mechanism on receipt of the first a specific internal delivery mechanism on receipt of the first
RCPT TO command.</t> RCPT TO command.</dd>
<t>Restrictions: None.</t> <dt>Restrictions:</dt> <dd>None.</dd>
<t>Security Considerations: See <xref target="Seccons" format="default"/ <dt>Security Considerations:</dt> <dd>See <xref target="Seccons" format=
></t> "default"/></dd>
</dl>
</section> </section>
</section> </section>
<section anchor="example" numbered="true" toc="default"> <section anchor="example" numbered="true" toc="default">
<name>Example</name> <name>Example</name>
<t>A server announces two limits it implements to the client, along <t>A server announces two limits it implements to the client, along
with various other supported extensions, as follows:</t> with various other supported extensions, as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
S: [wait for open connection] S: [wait for open connection]
C: [open connection to server] C: [open connection to server]
skipping to change at line 346 skipping to change at line 297
C: EHLO example.org C: EHLO example.org
S: 250-mail.example.com S: 250-mail.example.com
S: 250-SMTPUTF8 S: 250-SMTPUTF8
S: 250-LIMITS RCPTMAX=20 MAILMAX=5 S: 250-LIMITS RCPTMAX=20 MAILMAX=5
S: 250-SIZE 100000000 S: 250-SIZE 100000000
S: 250-8BITMIME S: 250-8BITMIME
S: 250-ENHANCEDSTATUSCODES S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING S: 250-PIPELINING
S: 250-CHUNKING S: 250-CHUNKING
S: 250 STARTTLS S: 250 STARTTLS
]]></artwork> ]]></artwork>
<t>The client now knows to limit the number of recipients in a transaction <t>The client now knows to limit the number of recipients in a transaction
to twenty and the number of transactions in a session to five.</t> to twenty and the number of transactions in a session to five.</t>
</section> </section>
<section anchor="Seccons" numbered="true" toc="default"> <section anchor="Seccons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>A malicious server can use limits to overly constrain client behavior, <t>A malicious server can use limits to overly constrain client behavior,
causing excessive use of client resources.</t> causing excessive use of client resources.</t>
<t>A malicious client may use the limits a server advertises to optimize <t>A malicious client may use the limits a server advertises to optimize
the delivery of unwanted messages.</t> the delivery of unwanted messages.</t>
<t>A man-in-the-middle attack on unprotected SMTP connections can <t>A man-in-the-middle attack on unprotected SMTP connections can
be used to cause clients to misbehave, which in turn could result be used to cause clients to misbehave, which in turn could result
in delivery delays or failures. Loss of reputation for the client in delivery delays or failures. Loss of reputation for the client
could also occur.</t> could also occur.</t>
<t>All that said, decades of operational experience with the <t>All that said, decades of operational experience with the
SMTP "SIZE" extension <xref target="SIZE" format="default"/>, SMTP "SIZE" extension <xref target="RFC1870" format="default"/>,
which provides servers with the which provides servers with the
ability to indicate message size, indicates that such abuse is ability to indicate message size, indicates that such abuse is
rare and unlikely to be a significant problem.</t> rare and unlikely to be a significant problem.</t>
<t>Use of the Limits extension to provide client-specific information - as <t>Use of the LIMITS extension to provide client-specific information - as
opposed to general server limits - unavoidably provides senders w ith opposed to general server limits - unavoidably provides senders w ith
feedback about their reputation. Malicious senders can exploit th is feedback about their reputation. Malicious senders can exploit th is
in various ways, e.g., start by sending good email and then, once their in various ways, e.g., start by sending good email and then, once their
reputation is established, sending bad email.</t> reputation is established, sending bad email.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="smtp-service-extension-registry" numbered="true" toc="def ault"> <section anchor="smtp-service-extension-registry" numbered="true" toc="def ault">
<name>SMTP Service Extension Registry</name> <name>SMTP Service Extension Registry</name>
<t>The IANA is requested to add "LIMITS" to the SMTP Service <t>The IANA has added "LIMITS" to the "SMTP Service
Extension Registry:</t> Extensions" registry:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl>
Keywords: LIMITS <dt>EHLO Keyword:</dt><dd>LIMITS</dd>
Description: Server limits
Reference: [RFCxxxx]
Note: See "SMTP Server Limits Regisry" below.
]]></artwork> <dt>Description:</dt><dd>Server limits</dd>
<dt>Reference:</dt><dd>RFC 9422</dd>
<dt>Note:</dt><dd>See "SMTP Server Limits" registry.</dd>
</dl>
</section> </section>
<section anchor="smtp-server-limits-registry" numbered="true" toc="defa ult"> <section anchor="smtp-server-limits-registry" numbered="true" toc="defa ult">
<name>SMTP Server Limits Registry</name> <name>SMTP Server Limits Registry</name>
<!-- following removed in -07, per message from Murray 2023-10-2 <t>The IANA has created a new registry in the "MAIL
2 Parameters" group for SMTP server limits. The policy for
<t>
<cref>Discussion is underway about incorporating a
variation on the "two options" or "hybrid" registration
model described in Section 8.1.1 of
draft-ietf-emailcore-rfc5321bis into a
revision of RFC 8126 or updating that RFC as described i
n
draft-klensin-iana-consid-hybrid. If that option become
s
available and generally accepted before work on this
specification is complete, this subsection should
probably be modified to use it, rather than having those
registrations depend on "Specification Required". The
latter, as defined in RFC 8126, satisfies neither those
who prefer a barrier-free registration system nor those
who prefer significant community review and input.</cref
>
</t> -->
<t>The IANA is requested to create a new registry in the Mail
Parameters group for SMTP server limits. The policy for
this registry is "Specification Required". this registry is "Specification Required".
Registry entries consist of these required values:</t> Registry entries consist of these required values:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The name of the limit.</li> <li>The name of the limit.</li>
<li>The syntax of the limit value, if the limit has one. <li>The syntax of the limit value, if the limit has one.
This syntax MUST conform to the provisions of This syntax <bcp14>MUST</bcp14> conform to the provisi ons of
<xref target="Extension"/> above. <xref target="Extension"/> above.
In most cases, the syntax will consist of a keyword In most cases, the syntax will consist of a keyword
designating the limit type followed by a limit value, designating the limit type followed by a limit value,
using a "name=value" form as illustrated by the using a "name=value" form as illustrated by the
registrations created by this specification in registrations created by this specification in
<xref target="initial-limits"/> above. <xref target="initial-limits"/> above.
Use of <xref target="ABNF" format="default"/> Use of ABNF <xref target="RFC5234" format="default"/>
is preferred but not required. If there is no limit is preferred but not required. If there is no limit
value, that should be explicit in the registration value, that should be explicit in the registration
request and the registry.</li> request and the registry.</li>
<li>A description of the limit's semantics.</li> <li>A description of the limit's semantics.</li>
<li>Restrictions, if any, on the use of the limit. If the limit is spe cific <li>Restrictions, if any, on the use of the limit. If the limit is spe cific
to any of SMTP, message submission, or LMTP, it should be documented to any of SMTP, message submission, or LMTP, it should be documented
here.</li> here.</li>
<li>Security considerations for the limit</li> <li>Security considerations for the limit.</li>
</ol> </ol>
<t> The Designated Expert(s) appointed under the <t> The Designated Expert(s) appointed under the
"Specification Required" procedure should check that "Specification Required" procedure should check that
registration requests are consistent with the requirements registration requests are consistent with the requirements
and intent of the extension mechanisms associated with and intent of the extension mechanisms associated with
SMTP <xref target="SMTP"/>, SMTP <xref target="RFC5321"/>,
<xref target="Extension"/> above, and the provision of this <xref target="Extension"/> above, and the provision of this
specification more generally and offer advice specification more generally and offer advice
accordingly.</t> accordingly.</t>
<t>The IANA is also requested to register the limits <t>The IANA has registered the limits
specified in <xref target="initial-limits"/> of this specified in <xref target="initial-limits"/> of this
document.</t> document.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC2920" to="PIPELINING"/>
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC5321" to="SMTP"/>
<displayreference target="RFC1870" to="SIZE"/>
<displayreference target="RFC2033" to="LMTP"/>
<displayreference target="RFC3207" to="STARTTLS"/>
<displayreference target="RFC4954" to="AUTH"/>
<displayreference target="RFC6409" to="SUBMIT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"/> 119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8174.xml"/> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
920.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
e.RFC.5321.xml"/>
<reference anchor="RFC5321a">
<front>
<title> Simple Mail Transfer Protocol</title>
<author initials="J." surname="Klensin"
fullname="John C. Klensin"/>
<date year="2008" month="October"/>
</front>
<seriesInfo name="RFC" value="5321"/>
<refcontent>Section 2.2</refcontent>
</reference>
<reference anchor="PIPELINING" target="https://www.rfc-editor.org/info/r
fc2920">
<front>
<title>SMTP Service Extension for Command Pipelining</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<date month="September" year="2000"/>
<abstract>
<t>This memo defines an extension to the Simple Mail Transfer Prot
ocol (SMTP) service whereby a server can indicate the extent of its ability to a
ccept multiple commands in a single Transmission Control Protocol (TCP) send ope
ration. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="60"/>
<seriesInfo name="RFC" value="2920"/>
<seriesInfo name="DOI" value="10.17487/RFC2920"/>
</reference>
<reference anchor="ABNF" target="https://www.rfc-editor.org/info/rfc5234
">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="SMTP" target="https://www.rfc-editor.org/info/rfc5321
">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="October" year="2008"/>
<abstract>
<t>This document is a specification of the basic protocol for Inte
rnet electronic mail transport. It consolidates, updates, and clarifies several
previous documents, making all or parts of most of them obsolete. It covers th
e SMTP extension mechanisms and best practices for the contemporary Internet, bu
t does not provide details about particular extensions. Although SMTP was desig
ned as a mail transport and delivery protocol, this specification also contains
information that is important to its use as a "mail submission" protocol for "sp
lit-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="SIZE" target="https://www.rfc-editor.org/info/rfc1870
"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 870.xml"/>
<title>SMTP Service Extension for Message Size Declaration</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="J. Klensin" initials="J." surname="Klensin"> 033.xml"/>
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</author> 207.xml"/>
<author fullname="N. Freed" initials="N." surname="Freed"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<organization/> 954.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="K. Moore" initials="K." surname="Moore"> 409.xml"/>
<organization/>
</author> <reference anchor="RFC5321b">
<date month="November" year="1995"/> <front>
<abstract> <title> Simple Mail Transfer Protocol</title>
<t>This memo defines an extension to the SMTP service whereby an S <author initials="J." surname="Klensin"
MTP client and server may interact to give the server an opportunity to decline fullname="John C. Klensin"/>
to accept a message (perhaps temporarily) based on the client's estimate of the <date year="2008" month="October"/>
message size. [STANDARDS-TRACK]</t> </front>
</abstract> <seriesInfo name="RFC" value="5321"/>
</front> <refcontent>Section 4.5.3.1</refcontent>
<seriesInfo name="STD" value="10"/> </reference>
<seriesInfo name="RFC" value="1870"/>
<seriesInfo name="DOI" value="10.17487/RFC1870"/> <reference anchor="RFC5321c">
</reference> <front>
<reference anchor="LMTP" target="https://www.rfc-editor.org/info/rfc2033 <title> Simple Mail Transfer Protocol</title>
"> <author initials="J." surname="Klensin"
<front> fullname="John C. Klensin"/>
<title>Local Mail Transfer Protocol</title> <date year="2008" month="October"/>
<author fullname="J. Myers" initials="J." surname="Myers"> </front>
<organization/> <seriesInfo name="RFC" value="5321"/>
</author> <refcontent>Section 4.5.3.1.8 </refcontent>
<date month="October" year="1996"/> </reference>
<abstract>
<t>SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provi
de a mechanism for transferring mail reliably and efficiently. The design of th
e SMTP protocol effectively requires the server to manage a mail delivery queue.
This memo provides information for the Internet community. This memo does not
specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2033"/>
<seriesInfo name="DOI" value="10.17487/RFC2033"/>
</reference>
<reference anchor="STARTTLS" target="https://www.rfc-editor.org/info/rfc
3207">
<front>
<title>SMTP Service Extension for Secure SMTP over Transport Layer S
ecurity</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<date month="February" year="2002"/>
<abstract>
<t>This document describes an extension to the SMTP (Simple Mail T
ransfer Protocol) service that allows an SMTP server and client to use TLS (Tran
sport Layer Security) to provide private, authenticated communication over the I
nternet. This gives SMTP agents the ability to protect some or all of their com
munications from eavesdroppers and attackers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3207"/>
<seriesInfo name="DOI" value="10.17487/RFC3207"/>
</reference>
<reference anchor="AUTH" target="https://www.rfc-editor.org/info/rfc4954
">
<front>
<title>SMTP Service Extension for Authentication</title>
<author fullname="R. Siemborski" initials="R." role="editor" surname
="Siemborski">
<organization/>
</author>
<author fullname="A. Melnikov" initials="A." role="editor" surname="
Melnikov">
<organization/>
</author>
<date month="July" year="2007"/>
<abstract>
<t>This document defines a Simple Mail Transport Protocol (SMTP) e
xtension whereby an SMTP client may indicate an authentication mechanism to the
server, perform an authentication protocol exchange, and optionally negotiate a
security layer for subsequent protocol interactions during this session. This e
xtension includes a profile of the Simple Authentication and Security Layer (SAS
L) for SMTP.</t>
<t>This document obsoletes RFC 2554. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4954"/>
<seriesInfo name="DOI" value="10.17487/RFC4954"/>
</reference>
<reference anchor="SUBMIT" target="https://www.rfc-editor.org/info/rfc64
09">
<front>
<title>Message Submission for Mail</title>
<author fullname="R. Gellens" initials="R." surname="Gellens">
<organization/>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="November" year="2011"/>
<abstract>
<t>This memo splits message submission from message relay, allowin
g each service to operate according to its own rules (for security, policy, etc.
), and specifies what actions are to be taken by a submission server.</t>
<t>Message relay is unaffected, and continues to use SMTP over por
t 25.</t>
<t>When conforming to this document, message submission uses the p
rotocol specified here, normally over port 587.</t>
<t>This separation of function offers a number of benefits, includ
ing the ability to apply specific security or policy requirements. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="72"/>
<seriesInfo name="RFC" value="6409"/>
<seriesInfo name="DOI" value="10.17487/RFC6409"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="true" toc="default"> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> The concept for this extension came from, and was developed <t> The concept for this extension came from, and was developed
by, Ned Freed and most of this specification, including by, Ned Freed and most of this specification, including
substantially of the technical details, was written by him. substantially all of the technical details, was written by him.
Unfortunately, he became ill and eventually passed away in Unfortunately, he became ill and eventually passed away in
May 2022 without being able to complete the document and May 2022 without being able to complete the document and
manage it through IETF Last Call. His contributions to the manage it through IETF Last Call. His contributions to the
Internet, work in the IETF, and the personal style that Internet, work in the IETF, and the personal style that
made both possible are irreplaceable and greatly missed. made both possible are irreplaceable and greatly missed.
With the support of the With the support of the
community, John Klensin picked the document up, responded to community, John Klensin picked the document up, responded to
some additional feedback, and got the document into what is some additional feedback, and got the document into what is
believed to be a finished state. In the interest of believed to be a finished state. In the interest of
preserving this as Ned's document, a few comments that preserving this as Ned's document, a few comments that
proposed additional features and options were set aside for proposed additional features and options were set aside for
future work rather than our having to guess at whether Ned future work rather than our having to guess at whether Ned
would have approved of them.</t> would have approved of them.</t>
<t> The acknowledgments below are divided into two parts, those <t> The acknowledgments below are divided into two parts, those
written by Ned and those associated with input to the written by Ned and those associated with input to the
document after his passing.</t> document after his passing.</t>
<section anchor="acknow-ned" numbered="true"
toc="default"> <ul><li><t>Acknowledgments from the Last Version Prepared by
<name>Acknowledgments from the Last Version Prepared by Ned Freed</t>
Ned Freed</name>
<t>A lot of people have helped make this specification <t>A lot of people have helped make this specification
possible. The author wishes possible. The author wishes to thank <contact
to thank Claus Assmann, Laura Atkins, Alex Brotman, Richa fullname="Claus Assmann"/>, <contact fullname="Laura Atkins"/>,
rd Clayton, <contact fullname="Alex Brotman"/>, <contact fullname="Richard
Dave Crocker, Viktor Dukhovni, Arnt Gulbrandsen, Jeremy Clayton"/>,
Harris, Todd Herr, <contact fullname="Dave Crocker"/>, <contact fullname="Viktor D
Mike Hillyer, Matthias Leisi, John Klensin, ukhovni"/>,
Valdis Kl&EOverbar;tnieks, <!-- Klētnieks --> <contact fullname=" Arnt Gulbrandsen"/>, <contact fullname="Jer
John Levine, Alexey Melnikov, Keith Moore, Michael Peddem emy Harris"/>,
ors, Hector Santos, <contact fullname="Todd Herr"/>, <contact fullname="Mike Hillye
George Schlossnagle, Rolf E. Sonneveld, and Alessandro Ve r"/>,
sely for their <contact fullname="Matthias Leisi"/>, <contact fullname="John K
contributions and reviews.</t> lensin"/>,
</section> <contact fullname="Valdis Klētnieks"/>, <contact fullname="John
<section anchor="acknow-jck" numbered="true" Levine"/>,
toc="default"> <contact fullname="Alexey Melnikov"/>, <contact fullname="Keith
<name>Acknowledgments from Versions Subsequent to Ned Moore"/>,
Freed's Passing</name> <contact fullname="Michael Peddemors"/>, <contact fullname="Hec
tor Santos"/>,
<contact fullname="George Schlossnagle"/>, <contact fullname="R
olf E. Sonneveld"/>,
and <contact fullname="Alessandro Vesely"/> for their contribut
ions and reviews.</t>
</li>
<li><t>Acknowledgments from Versions Subsequent to Ned
Freed's Passing</t>
<t> Additional helpful suggestions were received when the draft <t> Additional helpful suggestions were received when the draft
was requeued in the last part of 2022 and thereafter. Re views and was requeued in the last part of 2022 and thereafter. Re views and
suggestions from Alex Brotman, Dave Crocker, Gene Hightow suggestions from <contact fullname="Alex Brotman"/>, <con
er, tact fullname="Dave Crocker"/>,
Murray S. Kucherawy, Barry Leiba, John Levine, and <contact fullname="Gene Hightower"/>, <contact fullname="
Phil Pennock were Murray S. Kucherawy"/>,
<contact fullname="Barry Leiba"/>, <contact fullname="Joh
n Levine"/>, and
<contact fullname="Phil Pennock"/> were
especially helpful in identifying errors and suggesting especially helpful in identifying errors and suggesting
clarifying some issues with the document without changing clarifying some issues with the document without changing
Ned's fundamental issues or very much of his text.</t> Ned's fundamental issues or very much of his text.</t>
<t> IETF Last Call comments (and comments immediately before <t> IETF Last Call comments (and comments immediately before
it started) from people not listed above that resulted in it started) from people not listed above that resulted in
document changes were received from document changes were received from
Amanda Baber (for IANA), Linda Dunbar, Paul Kyzivat, <contact fullname="Amanda Baber"/> (for IANA), <contact f
and Phil Pennock.</t> ullname="Linda Dunbar"/>, and
</section> <contact fullname="Paul Kyzivat"/>.</t>
</section> </li>
</ul>
<section numbered="true" toc="default">
<name>Change Log After Version -03 (the last version prepared
entirely by Ned Freed)</name>
<t>RFC Editor: Please remove this section before
publication</t>
<section numbered="true" toc="default">
<name>Changes between draft-freed-smtp-limits-03 (2021-07-12)
and -04</name>
<t>Version 03 of this draft was posted by Ned Freed on
2021-07-12 and appeared to be
nearly ready for IETF Last Call at that point. Unfortunately,
with
Ned Freed's illness and untimely passing in May 2022, the draf
t was
allowed to expire and drop off the radar. This appendix
documents changes starting with draft-freed-smtp-limits-04, i.
e.,
after the last draft Ned Freed personally edited.</t>
<ul>
<li> UPgraded from RFCXMLv2 to v3 and added the initial
note below the abstract and this (redundant) Appendix.
no other intentional changes other than....</li>
<li> Adjusted
<xref target="syntax-errors-in-the-limits-parameter-val
ue"/>
to slightly clarify the intent in the second case.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Changes between draft-freed-smtp-limits-04 (2022-11-08)
and -05</name>
<ul>
<li> Corrected a few typographical and minor grammatical and
stylistic issues. </li>
<li> Made multiple small changes and corrections reflecting
comments from the mailing list.</li>
<li> In the hope that this version will soon be ready for IETF
last call, removed the introductory note and restructure
d
and rewrote the acknowledgments, moving much of that
introductory material there as well as acknowledging
input and other comments since work on the document was
restarted somewhat over a year ago.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Changes between draft-freed-smtp-limits-05 (2023-08-03)
and -06</name>
<ul>
<li>Added some words about Designated Experts and a comment
about hybrid to
<xref target="smtp-server-limits-registry"/>.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Changes between draft-freed-smtp-limits-06 (2023-09-05)
and -07</name>
<ul>
<li> Revised IANA Considerations
(<xref target="iana-considerations"/>) to reflect
comments in IANA review dated 2023-10-02.</li>
<li>Corrected several typographical errors and small
editorial issues.</li>
<li> Updated Acknowledgments.</li>
</ul>
</section> </section>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 66 change blocks. 
496 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.48.