5Internet Engineering Task Force (IETF) N. Freed
6Request for Comments: 9422
7Category: Standards Track J. Klensin
8ISSN: 2070-1721 February 2024
11 The LIMITS SMTP Service Extension
15 This document defines a LIMITS extension for the Simple Mail Transfer
16 Protocol (SMTP), including submission, as well as the Local Mail
17 Transfer Protocol (LMTP). It also defines an associated limit
18 registry. The extension provides the means for an SMTP, submission,
19 or LMTP server to inform the client of limits the server intends to
20 apply to the protocol during the current session. The client is then
21 able to adapt its behavior in order to conform to those limits.
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 7841.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 https://www.rfc-editor.org/info/rfc9422.
39 Copyright (c) 2024 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Revised BSD License text as described in Section 4.e of the
49 Trust Legal Provisions and are provided without warranty as described
50 in the Revised BSD License.
56 3. The LIMITS SMTP Extension
58 3.2. Limit Naming Conventions
59 3.3. Interaction with Pipelining
61 3.5. Interaction with SMTP Minimums
62 3.6. Multiple EHLO Commands
63 3.7. Syntax Errors in the LIMITS Parameter Value
64 3.8. Caching of Limit Settings between Sessions Involving the
65 Same Client and Server SMTP
69 4.3. RCPTDOMAINMAX Limit
71 6. Security Considerations
72 7. IANA Considerations
73 7.1. SMTP Service Extension Registry
74 7.2. SMTP Server Limits Registry
76 8.1. Normative References
77 8.2. Informative References
83 The Simple Mail Transfer Protocol provides the ability to transfer
84 [SMTP] or submit [SUBMIT] multiple email messages from one host to
85 another, each with one or more recipients, using a single or multiple
88 The Local Mail Transfer Protocol [LMTP] provides the ability to
89 deliver messages to a system without its own mail queues. Like SMTP,
90 it allows multiple messages with multiple recipients.
92 In order to conserve resources as well as protect themselves from
93 malicious clients, it is necessary for servers to enforce limits on
94 various aspects of the protocol, e.g., a limit on the number of
95 recipients that can be specified in a single transaction.
97 Additionally, servers may also wish to alter the limits they apply
98 depending on their assessment of the reputation of a particular
101 The variability of the limits that may be in effect creates a
102 situation where clients may inadvertently exceed a particular
103 server's limits, causing servers to respond with temporary (or in
104 some cases, permanent) errors. This in turn can lead to delays or
105 even failures in message transfer.
107 The LIMITS extension provides the means for a server to inform a
108 client about specific limits in effect for a particular SMTP or LMTP
109 session in the EHLO or LHLO command response. This information,
110 combined with the inherent flexibility of these protocols, makes it
111 possible for clients to avoid server errors and the problems they
114 SMTP and LMTP servers have always been able to announce a limit using
115 distinguished syntax in a reply, but this approach requires that the
116 client first needs to issue a command. The mechanism specified here
117 avoids the overhead of that approach by announcing limits prior to
118 any substantive interaction.
120 Limits are registered with the IANA. Each registration includes the
121 limit name, value syntax, and a description of its semantics.
125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
127 "OPTIONAL" in this document are to be interpreted as described in
128 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
129 capitals, as shown here.
131 This specification uses the Augmented Backus-Naur Form [ABNF]
132 notation and its core rules to define the formal syntax of the LIMITS
135 This specification makes extensive use of the terminology specified
1383. The LIMITS SMTP Extension
140 The extension mechanism for SMTP is defined in Section 2.2 of the
141 current SMTP specification [RFC5321a]. LMTP [LMTP] inherits SMTP's
144 The name of the extension is LIMITS. Servers implementing this
145 extension advertise a LIMITS as a keyword in the response to EHLO
146 (LHLO for LMTP). The associated parameter is used by the server to
147 communicate one or more limits, each with an optional value, to the
148 client. The syntax of the parameter is:
151 limit-name-value = limit-name ["=" limit-value]
152 limit-name = 1*(ALPHA / DIGIT / "-" / "_")
153 limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";"
155 This extension introduces no new SMTP commands and does not alter any
156 existing command. However, it is possible for a LIMITS parameter to
157 be associated with another SMTP extension that does these things.
161 In order to achieve consistent behavior, all limits MUST be
162 registered with the IANA, as described below.
1643.2. Limit Naming Conventions
166 Limit names MUST be comprehensible, but also should be kept as short
167 as possible. The use of commonly understood abbreviations, e.g.,
168 "MAX" for "maximum", is encouraged.
170 When a limit is associated with a particular command, its name SHOULD
171 begin with the name of that command.
173 Limit names SHOULD end with one or more terms that describe the type
1763.3. Interaction with Pipelining
178 The "Pipelining" extension [PIPELINING] is commonly used to improve
179 performance, especially over high latency connections. Pipelining
180 allows an entire transaction to be sent without checking responses,
181 and in some cases it may be possible to send multiple transactions.
183 The use of pipelining affects the LIMITS extension in an important
184 way: Since a pipelining client cannot check intermediate command
185 responses without stalling the pipeline, it cannot count the number
186 of successful versus failed responses and adjust its behavior
187 accordingly. Limit designers need to take this into account.
189 For example, it may seem like it would be better to impose a limit on
190 the number of successful RCPT TO commands as opposed to the way the
191 RCPTMAX limit is specified in Section 4.2 below. But counting the
192 total number of RCPT TOs is simple, whereas counting the number of
193 successful RCPT TO stalls the pipeline.
197 This extension provides an announcement as part of the reply to an
200 Some servers vary their limits, as a session progresses, based on
201 their obtaining more information. This extension does not attempt to
202 handle in-session limit changes.
2043.5. Interaction with SMTP Minimums
206 SMTP specifies minimum values for various server sizes, limits, and
207 timeouts [RFC5321b], e.g., servers must accept a minimum of 100 RCPT
208 TO commands [RFC5321c]). Unfortunately, the reality is that servers
209 routinely impose smaller limits than what SMTP requires, and when
210 this is done it is especially important for clients to be aware that
213 For this reason there is no requirement that the limits advertised by
214 this extension comply with the minimums imposed by SMTP.
2163.6. Multiple EHLO Commands
218 These protocols require that the EHLO command (LHLO in LMTP) be
219 reissued under certain circumstances, e.g., after successful
220 authentication [AUTH] or negotiation of a security layer [STARTTLS].
222 Servers MAY return updated limits any time the protocol requires
223 clients to reissue the EHLO command.
225 Clients MUST discard any previous limits in favor of those provided
226 by the most recent EHLO. This includes the case where the original
227 EHLO provided a set of limits but the subsequent EHLO did not; in
228 this case, the client MUST act as if no limits were communicated.
2303.7. Syntax Errors in the LIMITS Parameter Value
233 ignoring the value in its entirety; in this case, clients SHOULD
234 proceed as if the LIMITS extension had not been used.
236 Syntax or other errors in the value syntax of a specific limit,
237 including unrecognized value keywords, are best handled by ignoring
238 that limit; in this case, the client MUST proceed as if that limit
239 had not been specified.
241 It is possible that a future specification may create multiple limits
242 that are interrelated in some way; in this case, that specification
243 MUST specify how an error in the value syntax of one limit affects
2463.8. Caching of Limit Settings between Sessions Involving the Same
247 Client and Server SMTP
249 Clients MAY cache limits determined during one session and use them
250 to optimize their behavior for subsequent sessions. However, since
251 servers are free to adjust their limits at any time, clients MUST be
252 able to accommodate any limit changes that occur between sessions.
256 An initial set of limits is specified in the following sections.
262 Value syntax: %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
264 Description: MAILMAX specifies the maximum number of transactions
265 (MAIL FROM commands) the server will accept in a single session.
266 The count includes all MAIL FROM commands, regardless of whether
267 they succeed or fail.
271 Security Considerations: See Section 6
277 Value syntax: %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
279 Description: RCPTMAX specifies the maximum number of RCPT TO
280 commands the server will accept in a single transaction. It is
281 not a limit on the actual number of recipients the message ends up
282 being sent to; a single RCPT TO command may produce multiple
283 recipients or, in the event of an error, none.
287 Security Considerations: See Section 6
2894.3. RCPTDOMAINMAX Limit
293 Value syntax: %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
295 Description: RCPTDOMAINMAX specifies the maximum number of different
296 domains that can appear in a recipient (RCPT TO) address within a
297 single session. This limit is imposed by some servers that bind
298 to a specific internal delivery mechanism on receipt of the first
303 Security Considerations: See Section 6
307 A server announces two limits it implements to the client, along with
308 various other supported extensions, as follows:
310 S: [wait for open connection]
311 C: [open connection to server]
312 S: 220 mail.example.com ESMTP service ready
314 S: 250-mail.example.com
316 S: 250-LIMITS RCPTMAX=20 MAILMAX=5
317 S: 250-SIZE 100000000
319 S: 250-ENHANCEDSTATUSCODES
324 The client now knows to limit the number of recipients in a
325 transaction to twenty and the number of transactions in a session to
3286. Security Considerations
330 A malicious server can use limits to overly constrain client
331 behavior, causing excessive use of client resources.
333 A malicious client may use the limits a server advertises to optimize
334 the delivery of unwanted messages.
336 A man-in-the-middle attack on unprotected SMTP connections can be
337 used to cause clients to misbehave, which in turn could result in
338 delivery delays or failures. Loss of reputation for the client could
341 All that said, decades of operational experience with the SMTP "SIZE"
342 extension [SIZE], which provides servers with the ability to indicate
343 message size, indicates that such abuse is rare and unlikely to be a
346 Use of the LIMITS extension to provide client-specific information -
347 as opposed to general server limits - unavoidably provides senders
348 with feedback about their reputation. Malicious senders can exploit
349 this in various ways, e.g., start by sending good email and then,
350 once their reputation is established, sending bad email.
3527. IANA Considerations
3547.1. SMTP Service Extension Registry
356 The IANA has added "LIMITS" to the "SMTP Service Extensions"
361 Description: Server limits
365 Note: See "SMTP Server Limits" registry.
3677.2. SMTP Server Limits Registry
369 The IANA has created a new registry in the "MAIL Parameters" group
370 for SMTP server limits. The policy for this registry is
371 "Specification Required". Registry entries consist of these required
374 1. The name of the limit.
376 2. The syntax of the limit value, if the limit has one. This syntax
377 MUST conform to the provisions of Section 3 above. In most
378 cases, the syntax will consist of a keyword designating the limit
379 type followed by a limit value, using a "name=value" form as
380 illustrated by the registrations created by this specification in
381 Section 4 above. Use of ABNF [ABNF] is preferred but not
382 required. If there is no limit value, that should be explicit in
383 the registration request and the registry.
385 3. A description of the limit's semantics.
387 4. Restrictions, if any, on the use of the limit. If the limit is
388 specific to any of SMTP, message submission, or LMTP, it should
391 5. Security considerations for the limit.
393 The Designated Expert(s) appointed under the "Specification Required"
394 procedure should check that registration requests are consistent with
395 the requirements and intent of the extension mechanisms associated
396 with SMTP [SMTP], Section 3 above, and the provision of this
397 specification more generally and offer advice accordingly.
399 The IANA has registered the limits specified in Section 4 of this
4048.1. Normative References
406 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
407 Specifications: ABNF", STD 68, RFC 5234,
408 DOI 10.17487/RFC5234, January 2008,
409 <https://www.rfc-editor.org/info/rfc5234>.
412 Freed, N., "SMTP Service Extension for Command
413 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
414 September 2000, <https://www.rfc-editor.org/info/rfc2920>.
416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
417 Requirement Levels", BCP 14, RFC 2119,
418 DOI 10.17487/RFC2119, March 1997,
419 <https://www.rfc-editor.org/info/rfc2119>.
421 [RFC5321a] Klensin, J., "Simple Mail Transfer Protocol", Section 2.2,
422 RFC 5321, October 2008,
423 <https://www.rfc-editor.org/rfc/rfc5321>.
425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
427 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
429 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
430 DOI 10.17487/RFC5321, October 2008,
431 <https://www.rfc-editor.org/info/rfc5321>.
4338.2. Informative References
435 [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
436 Extension for Authentication", RFC 4954,
437 DOI 10.17487/RFC4954, July 2007,
438 <https://www.rfc-editor.org/info/rfc4954>.
440 [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
441 DOI 10.17487/RFC2033, October 1996,
442 <https://www.rfc-editor.org/info/rfc2033>.
444 [RFC5321b] Klensin, J., "Simple Mail Transfer Protocol",
445 Section 4.5.3.1, RFC 5321, October 2008,
446 <https://www.rfc-editor.org/rfc/rfc5321>.
448 [RFC5321c] Klensin, J., "Simple Mail Transfer Protocol",
449 Section 4.5.3.1.8, RFC 5321, October 2008,
450 <https://www.rfc-editor.org/rfc/rfc5321>.
452 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
453 Extension for Message Size Declaration", STD 10, RFC 1870,
454 DOI 10.17487/RFC1870, November 1995,
455 <https://www.rfc-editor.org/info/rfc1870>.
457 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
458 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
459 February 2002, <https://www.rfc-editor.org/info/rfc3207>.
461 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",
462 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
463 <https://www.rfc-editor.org/info/rfc6409>.
467 The concept for this extension came from, and was developed by, Ned
468 Freed and most of this specification, including substantially all of
469 the technical details, was written by him. Unfortunately, he became
470 ill and eventually passed away in May 2022 without being able to
471 complete the document and manage it through IETF Last Call. His
472 contributions to the Internet, work in the IETF, and the personal
473 style that made both possible are irreplaceable and greatly missed.
474 With the support of the community, John Klensin picked the document
475 up, responded to some additional feedback, and got the document into
476 what is believed to be a finished state. In the interest of
477 preserving this as Ned's document, a few comments that proposed
478 additional features and options were set aside for future work rather
479 than our having to guess at whether Ned would have approved of them.
481 The acknowledgments below are divided into two parts, those written
482 by Ned and those associated with input to the document after his
485 * Acknowledgments from the Last Version Prepared by Ned Freed
487 A lot of people have helped make this specification possible. The
488 author wishes to thank Claus Assmann, Laura Atkins, Alex Brotman,
489 Richard Clayton, Dave Crocker, Viktor Dukhovni, Arnt Gulbrandsen,
490 Jeremy Harris, Todd Herr, Mike Hillyer, Matthias Leisi, John
491 Klensin, Valdis Klētnieks, John Levine, Alexey Melnikov, Keith
492 Moore, Michael Peddemors, Hector Santos, George Schlossnagle, Rolf
493 E. Sonneveld, and Alessandro Vesely for their contributions and
496 * Acknowledgments from Versions Subsequent to Ned Freed's Passing
498 Additional helpful suggestions were received when the draft was
499 requeued in the last part of 2022 and thereafter. Reviews and
500 suggestions from Alex Brotman, Dave Crocker, Gene Hightower,
501 Murray S. Kucherawy, Barry Leiba, John Levine, and Phil Pennock
502 were especially helpful in identifying errors and suggesting
503 clarifying some issues with the document without changing Ned's
504 fundamental issues or very much of his text.
506 IETF Last Call comments (and comments immediately before it
507 started) from people not listed above that resulted in document
508 changes were received from Amanda Baber (for IANA), Linda Dunbar,
517 1770 Massachusetts Ave, Suite 322
519 United States of America
520 Email: john-ietf@jck.com