| RFC 9422 | LIMITS Extension | February 2024 |
| Freed & Klensin | Standards Track | [Page] |
This document defines a 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.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9422.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Simple Mail Transfer Protocol provides the ability to transfer[SMTP] or submit[SUBMIT] multiple email messages from one host to another, each with one or more recipients, using a single or multiple connections.¶
The Local Mail Transfer Protocol[LMTP] provides the ability to deliver messages to a system without its own mail queues. LikeSMTP, it allows multiple messages with multiple recipients.¶
In order to conserve resources as well as protect themselves frommalicious clients, it is necessary for servers to enforce limitson various aspects of the protocol, e.g., a limit on the numberof recipients that can be specified in a single transaction.¶
Additionally, servers may also wish to alter the limits theyapply depending on their assessment of the reputation of a particularclient.¶
The variability of the limits that may be in effect creates asituation where clients may inadvertently exceed a particular server'slimits, causing servers to respond with temporary (or in somecases, permanent) errors. This in turn can lead to delays or evenfailures in message transfer.¶
The LIMITS extension provides the means for a serverto inform a client about specific limits in effect fora particular SMTP or LMTP session in the EHLO or LHLO command response.This information, combined with theinherent flexibility of these protocols, makes it possible for clientsto avoid server errors and the problems they cause.¶
SMTP and LMTP servers have always been able to announce a limit usingdistinguished syntax in a reply, but this approach requires that theclient first needs to issue a command. The mechanism specified hereavoids the overhead of that approach by announcing limits prior to anysubstantive interaction.¶
Limits are registered with the IANA. Each registration includesthe limit name, value syntax, and a description of its semantics.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This specification uses the Augmented Backus-Naur Form[ABNF] notation and its core rules to define the formal syntax of the LIMITS extension.¶
This specification makes extensive use of the terminology specifiedand used in[SMTP].¶
The extension mechanism for SMTP is defined in Section 2.2 of the current SMTP specification[RFC5321a].LMTP [LMTP]inherits SMTP's extension mechanism.¶
The name of the extension is LIMITS. Servers implementing thisextension advertise a LIMITS as a keyword in the response to EHLO(LHLO for LMTP). Theassociated parameter is used by the server to communicate one ormore limits, each with an optional value, to the client. The syntaxof the parameter is:¶
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 ";"¶
This extension introduces no new SMTP commands and does notalter any existing command. However, it is possible for aLIMITS parameter to be associated with another SMTP extensionthat does these things.¶
In order to achieve consistent behavior, all limitsMUST beregistered with the IANA, as described below.¶
Limit namesMUST be comprehensible, but also shouldbe kept as short as possible. The use of commonly understoodabbreviations, e.g., "MAX" for "maximum", is encouraged.¶
When a limit is associated with a particular command, its nameSHOULD begin with the name of that command.¶
Limit namesSHOULD end with one or more terms that describethe type of limit.¶
The "Pipelining" extension[PIPELINING] is commonly used to improve performance, especially over high latencyconnections. Pipelining allows an entire transactionto be sent without checking responses, and in some cases it may bepossible to send multiple transactions.¶
The use of pipelining affects the LIMITS extension in an important way: Sincea pipelining client cannot check intermediate command responseswithout stalling the pipeline, it cannot count the number ofsuccessful versus failed responses and adjust its behavior accordingly.Limit designers need to take this into account.¶
For example, it may seem like it would be better to impose a limiton the number of successful RCPT TO commands as opposed to theway the RCPTMAX limit is specified inSection 4.2 below. Butcounting the total number of RCPT TOs is simple, whereascounting the number of successful RCPT TO stalls the pipeline.¶
This extension provides an announcement as part of the reply to an EHLO command.¶
Some servers vary their limits, as a sessionprogresses, based on their obtaining more information.This extension does not attempt to handle in-session limit changes.¶
SMTP specifies minimum values for various server sizes, limits, and timeouts[RFC5321b], e.g., servers must accept a minimum of 100 RCPT TO commands[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.¶
For this reason there is no requirement that the limitsadvertised by this extension comply with the minimums imposedby SMTP.¶
These protocols require that the EHLO command (LHLO in LMTP) be reissued under certain circumstances, e.g., after successfulauthentication[AUTH] or negotiation of a security layer[STARTTLS].¶
ServersMAY return updated limits any time the protocol requires clients to reissue the EHLO command.¶
ClientsMUST discard anyprevious limits in favor of those provided by the most recentEHLO. This includes the case where the original EHLO provideda set of limits but the subsequent EHLO did not; in thiscase, the clientMUST act as if no limits were communicated.¶
Syntax errors in the basic parameter syntax are best handled byignoring the value in its entirety; in this case, clientsSHOULDproceed as if the LIMITS extension had not been used.¶
Syntax or other errors in the value syntax of a specific limit, including unrecognized value keywords, are best handled by ignoring that limit; in this case, the clientMUST proceed as if that limit had not been specified.¶
It is possible that a future specification may create multiple limits that are interrelated in some way; in this case, that specificationMUST specify how an error in the value syntax of one limit affects the other limits.¶
ClientsMAY cache limits determined during one sessionand use them to optimize their behavior for subsequentsessions. However, since servers are free to adjust theirlimits at any time, clientsMUST be able to accommodateany limit changes that occur between sessions.¶
An initial set of limits is specified in the following sections.¶
A server announces two limits it implements to the client, alongwith various other supported extensions, as follows:¶
S: [wait for open connection]C: [open connection to server]S: 220 mail.example.com ESMTP service readyC: EHLO example.orgS: 250-mail.example.comS: 250-SMTPUTF8S: 250-LIMITS RCPTMAX=20 MAILMAX=5S: 250-SIZE 100000000S: 250-8BITMIMES: 250-ENHANCEDSTATUSCODESS: 250-PIPELININGS: 250-CHUNKINGS: 250 STARTTLS¶
The client now knows to limit the number of recipients in a transactionto twenty and the number of transactions in a session to five.¶
A malicious server can use limits to overly constrain client behavior, causing excessive use of client resources.¶
A malicious client may use the limits a server advertises to optimize the delivery of unwanted messages.¶
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.¶
All that said, decades of operational experience with the SMTP "SIZE" extension[SIZE], which provides servers with the ability to indicate message size, indicates that such abuse is rare and unlikely to be a significant problem.¶
Use of the LIMITS 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.¶
The IANA has added "LIMITS" to the "SMTP ServiceExtensions" registry:¶
The IANA has created a new registry in the "MAIL Parameters" group for SMTP server limits. The policy for this registry is "Specification Required". Registry entries consist of these required values:¶
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[SMTP],Section 3 above, and the provision of this specification more generally and offer advice accordingly.¶
The IANA has registered the limits specified inSection 4 of this document.¶
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.¶
The acknowledgments below are divided into two parts, those written by Ned and those associated with input to the document after his passing.¶
Acknowledgments from the Last Version Prepared by Ned Freed¶
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,Arnt Gulbrandsen,Jeremy Harris,Todd Herr,Mike Hillyer,Matthias Leisi,John Klensin,Valdis Klētnieks,John Levine,Alexey Melnikov,Keith Moore,Michael Peddemors,Hector Santos,George Schlossnagle,Rolf E. Sonneveld, andAlessandro Vesely for their contributions and reviews.¶
Acknowledgments from Versions Subsequent to Ned Freed's Passing¶
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 S. Kucherawy,Barry Leiba,John Levine, andPhil 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.¶
IETF Last Call comments (and comments immediately before it started) from people not listed above that resulted in document changes were received fromAmanda Baber (for IANA),Linda Dunbar, andPaul Kyzivat.¶