<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"><!ENTITY EOverbar "ē">]> <!-- 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" consensus="true" obsoletes="" updates=""submissionType="IETF"xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"version="3" consensus="true">version="3"> <!-- xml2rfc v2v3 conversion 3.15.2 --> <front> <title abbrev="LIMITS Extension">The LIMITS SMTP Service Extension</title> <seriesInfoname="Internet-Draft" value="draft-freed-smtp-limits-07"/>name="RFC" value="9422"/> <author initials="N." surname="Freed" fullname="Ned Freed"><organization> (deceased) </organization> <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><organization/> <address/> </author> <author initials="J." surname="Klensin" fullname="John C. Klensin"> <organization/> <address> <postal> <street>1770 Massachusetts Ave, Suite 322</street> <city>Cambridge</city> <region>MA</region> <code>02140</code><country>USA</country><country>United States of America</country> </postal> <email>john-ietf@jck.com</email> </address> </author> <dateyear="2023" month="October" day="23"/>year="2024" month="February"/> <area>ART</area><keyword>Internet-Draft</keyword><keyword>SMTP</keyword> <keyword>LMTP</keyword> <keyword>Message Submission</keyword> <keyword>ESMTP</keyword> <keyword>Extension</keyword> <abstract> <t>This document defines a"Limits"LIMITS extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, 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 able to adapt its behavior in order to conform to those limits.</t> </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> <middle> <section anchor="problems" numbered="true" toc="default"> <name>Introduction</name> <t>The Simple Mail Transfer Protocol provides the ability to transfer <xreftarget="SMTP"target="RFC5321" format="default"/> or submit <xreftarget="SUBMIT"target="RFC6409" format="default"/> multiple email messages from one host to another, each with one or more recipients, using a single or multiple connections.</t> <t>The Local Mail Transfer Protocol <xreftarget="LMTP"target="RFC2033" format="default"/> provides the ability to deliver messages to a system without its own mail queues. Like SMTP, it allows multiple messages with multiple recipients.</t> <t>In order to conserve resources as well as protect themselves from malicious clients, it is necessary for servers to enforce limits on various aspects of the protocol, e.g., a limit on the number of recipients that can be specified in a single transaction.</t> <t>Additionally, servers may also wish to alter the limits they apply depending on their assessment of the reputation of a particular client.</t> <t>The variability of the limits that may be in effect creates a situation where clients may inadvertently exceed a particular server's limits, causing servers to respond with temporary (or in some cases, permanent) errors. This in turn can lead to delays or even failures in message transfer.</t> <t>The"Limits"LIMITS extension provides the means for a server to inform a client about specific limits in effect for a particular SMTP or LMTP session in the EHLO or LHLO command response. This information, combined with the inherent flexibility of these protocols, makes it possible for clients to avoid server errors and the problems they cause.</t> <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 client first needs to issue a command. The mechanism specified here avoids the overhead of that approach by announcing limits prior to any substantive interaction.</t> <t>Limits are registered with the IANA. Each registration includes the limit name, value syntax, and a description of its semantics.</t> </section> <section anchor="Terminology" numbered="true" toc="default"> <name>Terminology</name><!-- Murray complained (email 2023-08-03 14:54 -0700) that text did not exactly match RFC 8174. New version below. ... <t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>.</t> --><t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This specification uses the Augmented Backus-Naur Form <xreftarget="ABNF"target="RFC5234" format="default"/> notation and its core rules to define the formal syntax of the"Limits"LIMITS extension.</t> <t>This specification makes extensive use of the terminology specified and used in <xreftarget="SMTP"target="RFC5321" format="default"/>.</t> </section> <section anchor="Extension" numbered="true" toc="default"> <name>The"Limits"LIMITS SMTP Extension</name><t>Extensions to<t>The extension mechanism for SMTPareis defined in Section 2.2 of the current SMTP specification <xreftarget="SMTP" format="default"/>.target="RFC5321a"/>. <xreftarget="LMTP" format="default"/>target="RFC2033" format="default">LMTP</xref> inherits SMTP's extension mechanism.</t> <t>The name of the extension is"Limits".LIMITS. Servers implementing this extension advertisean additional "LIMITS"a LIMITS as a keyword in the response to EHLO (LHLOin LMTP) keyword.for LMTP). The associated parameter is used by the server to communicate one or more limits, each with an optional value, to the client. The syntax 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] limit-name-value = limit-name ["=" limit-value] limit-name = 1*(ALPHA / DIGIT / "-" / "_") limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";"]]></artwork>]]></sourcecode> <t>This extension introduces no new SMTPcommands,commands and does not alter any existing command. However, it is possible for a LIMITS parameter to be associated with another SMTP extension that does these things.</t> <section anchor="limits" numbered="true" toc="default"> <name>Limits</name> <t>In order to achieve consistent behavior, all limitsMUST<bcp14>MUST</bcp14> be registered with the IANA, as described below.</t> </section> <section anchor="limit-naming-conventions" numbered="true" toc="default"> <name>Limit Naming Conventions</name> <t>Limit namesMUST<bcp14>MUST</bcp14> be comprehensible, but also should be kept as short as possible. The use of commonly understood abbreviations, e.g., "MAX" for "maximum", is encouraged.</t> <t>When a limit is associated with a particular command, its nameSHOULD<bcp14>SHOULD</bcp14> begin with the name of that command.</t> <t>Limit namesSHOULD<bcp14>SHOULD</bcp14> end with one or more terms that describe the type of limit.</t> </section> <section anchor="interaction-with-pipelining" numbered="true" toc="default"> <name>InteractionWithwith Pipelining</name> <t>The "Pipelining" extension <xreftarget="PIPELINING"target="RFC2920" format="default"/> is commonly used to improve performance, especially over high latency connections. Pipelining allows an entire transaction to be sent without checkingresponsesresponses, and in some cases it may be possible to send multiple transactions.</t> <t>The use of pipelining affectslimitsthe LIMITS extension in an important way: Since a pipelining client cannot check intermediate command responses without stalling the pipeline, it cannot count the number of successful versus failed responses and adjust its behavior accordingly. Limit designers need to take this into account.</t> <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 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 number of successful RCPT TO stalls the pipeline.</t> </section> <section anchor="varying-limits" numbered="true" toc="default"> <name>Varying Limits</name> <t>This extension provides an announcement as part of the reply to an EHLO command.</t> <t>Some servers vary their limits, as a session progresses, based on their obtaining more information. This extension does not attempt to handle in-session limit changes.</t> </section> <section anchor="interaction-with-smtp-minimums" numbered="true" toc="default"> <name>InteractionWithwith SMTP Minimums</name><t>Section 4.5.3.1 of <xref target="SMTP" format="default"/><t>SMTP specifies minimum values for various server sizes, limits, andtimeouts,timeouts <xref format="default" target="RFC5321b"/>, e.g., servers must accept a minimum of 100 RCPT TO commands(section 4.5.3.1.8).<xref target="RFC5321c"/>). Unfortunately, the reality is that servers routinely impose smaller limits than what SMTP requires, and when this is done it is especially important for clients to be aware that this is happening.</t> <t>For this reason there is no requirement that the limits advertised by this extension comply with the minimums imposed by SMTP.</t> </section> <section anchor="multiple-ehlo-commands" numbered="true" toc="default"> <name>Multiple EHLO Commands</name> <t>These protocols require that the EHLO command (LHLO in LMTP) be reissued under certain circumstances, e.g., after successful authentication <xreftarget="AUTH"target="RFC4954" format="default"/> or negotiation of a security layer <xreftarget="STARTTLS"target="RFC3207" format="default"/>.</t> <t>ServersMAY<bcp14>MAY</bcp14> return updated limits any time the protocol requires clients to reissue the EHLO command.</t> <t>ClientsMUST<bcp14>MUST</bcp14> discard any previous limits in favor of those provided by the most recent EHLO. This includes the case where the original EHLO provided a set of limits but the subsequent EHLO did not; in thiscasecase, the clientMUST<bcp14>MUST</bcp14> act as if no limits were communicated.</t> </section> <section anchor="syntax-errors-in-the-limits-parameter-value" numbered="true" toc="default"> <name>Syntax Errors in the LIMITS Parameter Value</name> <t>Syntax errors in the basic parameter syntax are best handled by ignoring the value in its entirety; in thiscasecase, clientsSHOULD<bcp14>SHOULD</bcp14> proceed as if the LIMITS extension had not been used.</t> <t>Syntax or other errors in the value syntax of a specific limit, including unrecognized value keywords, are best handled by ignoring that limit; in thiscasecase, the clientMUST <!-- changed from SHOULD per Dave Crocker note 2022-11-10 --><bcp14>MUST</bcp14> proceed as if that limit had not been specified.</t> <t>It is possible that a future specification may create multiple limits that are interrelated in some way; in thiscasecase, that specificationMUST<bcp14>MUST</bcp14> specify how an error in the value syntax of one limit affects the other limits.</t> </section> <section anchor="caching-of-limit-settings-between-sessions" numbered="true" toc="default"> <name>Caching of Limit SettingsBetweenbetween Sessions Involving the Same Client and Server SMTP</name> <t>ClientsMAY<bcp14>MAY</bcp14> cache limits determined during one session and use them to optimize their behavior for subsequent sessions. However, since servers are free to adjust their limits at any time, clientsMUST<bcp14>MUST</bcp14> be able to accommodate any limit changes that occur between sessions.</t> </section> </section> <section anchor="initial-limits" numbered="true" toc="default"> <name>Initial Limits</name> <t>An initial set of limits is specified in the following sections.</t> <section anchor="mailmax-limit" numbered="true" toc="default"> <name>MAILMAX Limit</name><t>Name: MAILMAX</t> <t>Value syntax: %x31-39<dl> <dt>Name:</dt><dd>MAILMAX</dd> <dt>Value syntax:</dt><dd>%x31-39 0*5DIGIT ;0"0" not allowed,6 digit maximum</t> <t>Description: MAILMAXsix-digit maximum</dd> <dt>Description:</dt><dd>MAILMAX specifies the maximum number of transactions (MAIL FROM commands) the server will accept in a single session. The count includes all MAIL FROM commands, regardless of whether they succeed orfail.</t> <t>Restrictions: None.</t> <t>Security Considerations:fail.</dd> <dt>Restrictions:</dt><dd> None.</dd> <dt>Security Considerations:</dt><dd> See <xref target="Seccons"format="default"/></t>format="default"/></dd> </dl> </section> <section anchor="RCPTMAX" numbered="true" toc="default"> <name>RCPTMAX Limit</name><t>Name: RCPTMAX</t> <t>Value syntax:<dl> <dt>Name:</dt> <dd>RCPTMAX</dd> <dt>Value syntax:</dt><dd> %x31-39 0*5DIGIT ;0"0" not allowed,6 digit maximum</t> <t>Description: RCPTMAXsix-digit maximum</dd> <dt>Description:</dt> <dd>RCPTMAX specifies the maximum number of RCPT TO commands 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; a single RCPT TO command may produce multiple recipients or, in the event of an error,none.</t> <t>Restrictions: None.</t> <t>Security Considerations: Seenone.</dd> <dt>Restrictions:</dt> <dd>None.</dd> <dt>Security Considerations:</dt> <dd>See <xref target="Seccons"format="default"/></t>format="default"/></dd> </dl> </section> <section anchor="rcptdomainmax-limit" numbered="true" toc="default"> <name>RCPTDOMAINMAX Limit</name><t>Name: RCPTDOMAINMAX</t> <t>Value syntax:<dl> <dt>Name:</dt> <dd>RCPTDOMAINMAX</dd> <dt>Value syntax:</dt> <dd> %x31-39 0*5DIGIT ;0"0" not allowed,6 digit maximum</t> <t>Description: RCPTDOMAINMAXsix-digit 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 session. This limit is imposed by some servers that bind to a specific internal delivery mechanism on receipt of the first RCPT TOcommand.</t> <t>Restrictions: None.</t> <t>Security Considerations: Seecommand.</dd> <dt>Restrictions:</dt> <dd>None.</dd> <dt>Security Considerations:</dt> <dd>See <xref target="Seccons"format="default"/></t>format="default"/></dd> </dl> </section> </section> <section anchor="example" numbered="true" toc="default"> <name>Example</name> <t>A server announces two limits it implements to the client, along with various other supported extensions, as follows:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ S: [wait for open connection] C: [open connection to server] S: 220 mail.example.com ESMTP service ready C: EHLO example.org S: 250-mail.example.com S: 250-SMTPUTF8 S: 250-LIMITS RCPTMAX=20 MAILMAX=5 S: 250-SIZE 100000000 S: 250-8BITMIME S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-CHUNKING S: 250 STARTTLS ]]></artwork> <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> </section> <section anchor="Seccons" numbered="true" toc="default"> <name>Security Considerations</name> <t>A malicious server can use limits to overly constrain client behavior, causing excessive use of client resources.</t> <t>A malicious client may use the limits a server advertises to optimize the delivery of unwanted messages.</t> <t>A man-in-the-middle attack on unprotected SMTP connections can be used to cause clients to misbehave, which in turn could result in delivery delays or failures. Loss of reputation for the client could also occur.</t> <t>All that said, decades of operational experience with the SMTP "SIZE" extension <xreftarget="SIZE"target="RFC1870" format="default"/>, which provides servers with the ability to indicate message size, indicates that such abuse is rare and unlikely to be a significant problem.</t> <t>Use of theLimitsLIMITS extension to provide client-specific information - as opposed to general server limits - unavoidably provides senders with feedback about their reputation. Malicious senders can exploit this in various ways, e.g., start by sending good email and then, once their reputation is established, sending bad email.</t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="smtp-service-extension-registry" numbered="true" toc="default"> <name>SMTP Service Extension Registry</name> <t>The IANAis requested to addhas added "LIMITS" to theSMTP"SMTP ServiceExtension Registry:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ Keywords: LIMITS Description: Server limits Reference: [RFCxxxx] Note: SeeExtensions" registry:</t> <dl> <dt>EHLO Keyword:</dt><dd>LIMITS</dd> <dt>Description:</dt><dd>Server limits</dd> <dt>Reference:</dt><dd>RFC 9422</dd> <dt>Note:</dt><dd>See "SMTP ServerLimits Regisry" below. ]]></artwork>Limits" registry.</dd> </dl> </section> <section anchor="smtp-server-limits-registry" numbered="true" toc="default"> <name>SMTP Server Limits Registry</name><!-- following removed in -07, per message from Murray 2023-10-22 <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 in draft-klensin-iana-consid-hybrid. If that option becomes 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 IANAis requested to createhas created a new registry in theMail Parameters"MAIL Parameters" group for SMTP server limits. The policy for this registry is "Specification Required". Registry entries consist of these required values:</t> <ol spacing="normal" type="1"> <li>The name of the limit.</li> <li>The syntax of the limit value, if the limit has one. This syntaxMUST<bcp14>MUST</bcp14> conform to the provisions of <xref target="Extension"/> above. In most cases, the syntax will consist of a keyword designating the limit type followed by a limit value, using a "name=value" form as illustrated by the registrations created by this specification in <xref target="initial-limits"/> above. Use of ABNF <xreftarget="ABNF"target="RFC5234" format="default"/> is preferred but not required. If there is no limit value, that should be explicit in the registration request and the registry.</li> <li>A description of the limit's semantics.</li> <li>Restrictions, if any, on the use of the limit. If the limit is specific to any of SMTP, message submission, or LMTP, it should be documented here.</li> <li>Security considerations for thelimit</li>limit.</li> </ol> <t> The Designated Expert(s) appointed under the "Specification Required" procedure should check that registration requests are consistent with the requirements and intent of the extension mechanisms associated with SMTP <xreftarget="SMTP"/>,target="RFC5321"/>, <xref target="Extension"/> above, and the provision of this specification more generally and offer advice accordingly.</t> <t>The IANAis also requested to registerhas registered the limits specified in <xref target="initial-limits"/> of this document.</t> </section> </section> </middle> <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> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2920.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/> <referenceanchor="PIPELINING" target="https://www.rfc-editor.org/info/rfc2920">anchor="RFC5321a"> <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<title> Simple Mail TransferProtocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [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="Crocker"> <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 Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 TransferProtocol</title> <authorfullname="J. Klensin"initials="J."surname="Klensin"> <organization/> </author>surname="Klensin" fullname="John C. Klensin"/> <datemonth="October" year="2008"/> <abstract> <t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</t> </abstract>year="2008" month="October"/> </front> <seriesInfo name="RFC" value="5321"/><seriesInfo name="DOI" value="10.17487/RFC5321"/><refcontent>Section 2.2</refcontent> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1870.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2033.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4954.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6409.xml"/> <referenceanchor="SIZE" target="https://www.rfc-editor.org/info/rfc1870"> <front> <title>SMTP Service Extension for Message Size Declaration</title> <author fullname="J. Klensin" initials="J." surname="Klensin"> <organization/> </author> <author fullname="N. Freed" initials="N." surname="Freed"> <organization/> </author> <author fullname="K. Moore" initials="K." surname="Moore"> <organization/> </author> <date month="November" year="1995"/> <abstract> <t>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="10"/> <seriesInfo name="RFC" value="1870"/> <seriesInfo name="DOI" value="10.17487/RFC1870"/> </reference> <reference anchor="LMTP" target="https://www.rfc-editor.org/info/rfc2033">anchor="RFC5321b"> <front><title>Local<title> Simple Mail Transfer Protocol</title> <authorfullname="J. Myers"initials="J."surname="Myers"> <organization/> </author> <date month="October" year="1996"/> <abstract> <t>SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the 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/rfc3207"> <front> <title>SMTP Service Extension for Secure SMTP over Transport Layer Security</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"> <organization/> </author>surname="Klensin" fullname="John C. Klensin"/> <datemonth="February" year="2002"/> <abstract> <t>This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]</t> </abstract>year="2008" month="October"/> </front> <seriesInfo name="RFC"value="3207"/> <seriesInfo name="DOI" value="10.17487/RFC3207"/>value="5321"/> <refcontent>Section 4.5.3.1</refcontent> </reference> <referenceanchor="AUTH" target="https://www.rfc-editor.org/info/rfc4954">anchor="RFC5321c"> <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<title> Simple MailTransport Protocol (SMTP) extension 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 extension includes a profile of the Simple Authentication and Security Layer (SASL) 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/rfc6409"> <front> <title>Message Submission for Mail</title> <author fullname="R. Gellens" initials="R." surname="Gellens"> <organization/> </author>Transfer Protocol</title> <authorfullname="J. Klensin"initials="J."surname="Klensin"> <organization/> </author>surname="Klensin" fullname="John C. Klensin"/> <datemonth="November" year="2011"/> <abstract> <t>This memo splits message submission from message relay, allowing 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 port 25.</t> <t>When conforming to this document, message submission uses the protocol specified here, normally over port 587.</t> <t>This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]</t> </abstract>year="2008" month="October"/> </front> <seriesInfoname="STD" value="72"/> <seriesInfoname="RFC"value="6409"/> <seriesInfo name="DOI" value="10.17487/RFC6409"/>value="5321"/> <refcontent>Section 4.5.3.1.8 </refcontent> </reference> </references> </references> <sectionanchor="acknowledgements" numbered="true"anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t> The concept for this extension came from, and was developed by, Ned Freed and most of this specification, including substantially all of the technical details, was written by him. Unfortunately, he became ill and eventually passed away in May 2022 without being able to complete the document and manage it through IETF Last Call. His contributions to the Internet, work in the IETF, and the personal style that made both possible are irreplaceable and greatly missed. With the support of the community, John Klensin picked the document up, responded to some additional feedback, and got the document into what is believed to be a finished state. In the interest of preserving this as Ned's document, a few comments that proposed additional features and options were set aside for future work rather than our having to guess at whether Ned would have approved of them.</t> <t> The acknowledgments below are divided into two parts, those written by Ned and those associated with input to the document after his passing.</t><section anchor="acknow-ned" numbered="true" toc="default"> <name>Acknowledgments<ul><li><t>Acknowledgments from the Last Version Prepared by NedFreed</name>Freed</t> <t>A lot of people have helped make this specification possible. The author wishes to thankClaus Assmann, Laura Atkins, Alex Brotman, Richard Clayton, Dave Crocker, Viktor Dukhovni,<contact fullname="Claus Assmann"/>, <contact fullname="Laura Atkins"/>, <contact fullname="Alex Brotman"/>, <contact fullname="Richard Clayton"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Viktor Dukhovni"/>, <contact fullname=" ArntGulbrandsen, Jeremy Harris, Todd Herr, Mike Hillyer, Matthias Leisi, John Klensin, Valdis Kl&EOverbar;tnieks, <!-- KlÄ“tnieks --> John Levine, Alexey Melnikov, Keith Moore, Michael Peddemors, Hector Santos, George Schlossnagle, RolfGulbrandsen"/>, <contact fullname="Jeremy Harris"/>, <contact fullname="Todd Herr"/>, <contact fullname="Mike Hillyer"/>, <contact fullname="Matthias Leisi"/>, <contact fullname="John Klensin"/>, <contact fullname="Valdis KlÄ“tnieks"/>, <contact fullname="John Levine"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Keith Moore"/>, <contact fullname="Michael Peddemors"/>, <contact fullname="Hector Santos"/>, <contact fullname="George Schlossnagle"/>, <contact fullname="Rolf E.Sonneveld,Sonneveld"/>, andAlessandro Vesely<contact fullname="Alessandro Vesely"/> for their contributions and reviews.</t></section> <section anchor="acknow-jck" numbered="true" toc="default"> <name>Acknowledgments</li> <li><t>Acknowledgments from Versions Subsequent to Ned Freed'sPassing</name>Passing</t> <t> Additional helpful suggestions were received when the draft was requeued in the last part of 2022 and thereafter. Reviews and suggestions fromAlex Brotman, Dave Crocker, Gene Hightower, Murray<contact fullname="Alex Brotman"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Gene Hightower"/>, <contact fullname="Murray S.Kucherawy, Barry Leiba, John Levine,Kucherawy"/>, <contact fullname="Barry Leiba"/>, <contact fullname="John Levine"/>, andPhil Pennock<contact fullname="Phil Pennock"/> were especially helpful in identifying errors and suggesting clarifying some issues with the document without changing Ned's fundamental issues or very much of his text.</t> <t> IETF Last Call comments (and comments immediately before it started) from people not listed above that resulted in document changes were received fromAmanda Baber<contact fullname="Amanda Baber"/> (for IANA),Linda Dunbar, Paul Kyzivat, and Phil Pennock.</t> </section> </section> <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 draft 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-value"/> 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.<contact fullname="Linda Dunbar"/>, and <contact fullname="Paul Kyzivat"/>.</t> </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 restructured 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> </back> </rfc>