The LIMITS SMTP Service Extension

Document Type Active Internet-Draft (individual)
Author Ned Freed 
Last updated 2021-07-12
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           N. Freed
Internet-Draft                                                    Oracle
Intended status: Standards Track                           July 12, 2021
Expires: January 13, 2022

                   The LIMITS SMTP Service Extension


   This document defines a "Limits" extension for the Simple Mail
   Transfer Protocol (SMTP), including submisssion, as well as the Local
   Mail Transfer Protocol (LMTP).  It also defines an associated limit
   registry.  This 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 13, 2022.

Copyright Notice

   Copyright (c) 2021 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
   ( 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 Simplified BSD License text as described in Section 4.e of

Freed                   Expires January 13, 2022                [Page 1]
Internet-Draft              LIMITS Extension                   July 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The Simple Mail Transfer Protocol provides the ability to transfer
   [SMTP] or submit [SUBMIT] multiple email messages from one host to
   another, each with multiple recipients, using a single or multiple

   The Local Mail Transfer Protocol [LMTP] provides the ability to
   deliver messages to a system without its own mail queues.  Like SMTP,
   it allows multiple messages with multiple recipients.

   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.

   Additionally, servers may also wish to alter the limits they apply
   depending on their assessment of the reputation of a particular

   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.

   The "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

   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.

   Limits are registered with the IANA.  Each registration includes the
   limit name, value syntax, and a description of its semantics.

Freed                   Expires January 13, 2022                [Page 2]
Internet-Draft              LIMITS Extension                   July 2021

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119

   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 specified
   and used in [SMTP].

3.  The "Limits" SMTP Extension

   Extensions to SMTP are defined in Section 2.2 of [SMTP].  [LMTP]
   inherits SMTP's extension mechanism.

   The name of the extension is "Limits".  Servers implementing this
   extension advertise an additional "LIMITS" EHLO (LHLO in LMTP)
   keyword.  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:

     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 not alter
   any existing command.  However, it is possible for a LIMITS parameter
   to be associated with another SMTP extension that does these things.

3.1.  Limits

   In order to achieve consistent behavior, all limits MUST be
   registered with the IANA, as described below.

3.2.  Limit Naming Conventions

   Limit names MUST be comprehensible, but also should be kept as short
   as possible.  The use of commonly understood abbreviations, e.g.,
   "MAX" for "maximum", is encouraged.

   When a limit is associated with a particular command, its name SHOULD
   begin with the name of that command.

Freed                   Expires January 13, 2022                [Page 3]
Internet-Draft              LIMITS Extension                   July 2021

   Limit names SHOULD end with one or more terms that describe the type
   of limit.

3.3.  Interaction With Pipelining

   The "Pipelining" extension [PIPELINING] is commonly used to improve
   performance, especially over high latency connections.  Pipelining
   allows entire transaction to be sent without checking responses and
   in some cases it may be possible to send multiple transactions.

   The use of pipelining affects limits in an important way: Since a
   pipelining client cannot check intermediate command responses without
   stalling the pipeline, it cannot count the number of succesful 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 limit on
   the number of succesful RCPT TO commands as opposed to the way the
   RCPTMAX limit is specified in Section 4.2 below.  But counting the
   total number of RCPT TOs is simple, whereas counting the number of
   successful RCPT TO stalls the pipeline.

3.4.  Varying Limits

   This extension provides an announcement as part of the reply to an
   EHLO command.  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.

3.5.  Interaction With SMTP Minimums

   Section of [SMTP] specifies minimum values for various server
   sizes, limits, and timeouts, e.g., servers must accept a minimum of
   100 RCPT TO commands (section  Unfortunately, the reality
   is that servers routinely impose smaller limits than what SMTP
   requires, and when this is done it's especially important for clients
   to be aware that this is happening.

   For this reason there is no requirement that the limits advertised by
   this extension comply with the minimums imposed by SMTP.

3.6.  Multiple EHLO Commands

   These protocols require that the EHLO command (LHLO in LMTP) be
   reissued under certain circumstances, e.g., after successful
   authentication [AUTH] or negotiation of a security layer [STARTTLS].

Freed                   Expires January 13, 2022                [Page 4]
Internet-Draft              LIMITS Extension                   July 2021

   Servers MAY return updated limits any time the protocol requires
   clients to reissue the EHLO command.  Clients MUST 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 this case the client MUST
   act as if no limits were communicated.

3.7.  Syntax Errors in the LIMITS Parameter Value

   Syntax errors in the basic parameter syntax are best handled by
   ignoring the value in its entirety; in this case clients SHOULD
   proceed as if the LIMITS extension wasn't used.

   Syntax errors in the value syntax of a specific limit are best
   handled by ignoring that limit; in this case the client SHOULD
   proceed as if that limit wasn't specified.

   It is possible that future specification may create multiple limits
   that are interrelated in some way; in this case that specification
   MUST specify how an error in one limit's value syntax affects the
   other limits.

3.8.  Caching of Limit Settings Between Sessions

   Clients MAY 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, clients MUST be
   able to accommodate any limit changes that occur between sessions.

4.  Initial Limits

   An initial set of limits are specified in the following sections.

4.1.  MAILMAX Limit

   Name: MAILMAX

   Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum

   Description: 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 or fail.

   Restrictions: None.

   Security Considerations: See Section 6

Freed                   Expires January 13, 2022                [Page 5]
Internet-Draft              LIMITS Extension                   July 2021

4.2.  RCPTMAX Limit

   Name: RCPTMAX

   Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum

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

   Restrictions: None.

   Security Considerations: See Section 6



   Value syntax: %x31-39 0*5DIGIT ; 0 not allowed, 6 digit maximum

   Description: 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 TO

   Restrictions: None.

   Security Considerations: See Section 6

5.  Example

   A server announces two limits it implements to the client, along with
   various other supported extensions, as follows:

Freed                   Expires January 13, 2022                [Page 6]
Internet-Draft              LIMITS Extension                   July 2021

   S: [wait for open connection]
   C: [open connection to server]
   S: 220 ESMTP service ready
   C: EHLO
   S: 250-SMTPUTF8
   S: 250-SIZE 100000000
   S: 250-8BITMIME
   S: 250-CHUNKING
   S: 250 STARTTLS

   The client now knows to limit the number of recipients in a
   transaction to twenty and the number of transaction in a session to

6.  Security Considerations

   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.

7.  IANA Considerations

Freed                   Expires January 13, 2022                [Page 7]
Internet-Draft              LIMITS Extension                   July 2021

7.1.  SMTP Service Extension Registry

   The IANA is requested to add "LIMITS" to the SMTP Service Extension

   Keywords: LIMITS
   Description: Server limits
   Reference: [RFCxxxx]

7.2.  SMTP Server Limits Registry

   The IANA is requested to create a new registry for SMTP server
   limits.  The policy for this registry is "Specification Required".
   Registry entries consist of three required values:

   1.  The name of the limit

   2.  The syntax of the limit value, if the limit has one.  Use of
       [ABNF] is preferred but not required.

   3.  A description of the limit's semantics

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

   5.  Security considerations for the limit

   The IANA is also requested to register the limits specified in this

8.  References

8.1.  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Freed                   Expires January 13, 2022                [Page 8]
Internet-Draft              LIMITS Extension                   July 2021

              Freed, N., "SMTP Service Extension for Command
              Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
              September 2000, <>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,

8.2.  Informative References

   [AUTH]     Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,

   [LMTP]     Myers, J., "Local Mail Transfer Protocol", RFC 2033,
              DOI 10.17487/RFC2033, October 1996,

   [SIZE]     Klensin, J., Freed, N., and K. Moore, "SMTP Service
              Extension for Message Size Declaration", STD 10, RFC 1870,
              DOI 10.17487/RFC1870, November 1995,

              Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <>.

   [SUBMIT]   Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,

Appendix A.  Acknowledgements

   A lot of people have helped make this specification possible.  The
   author wishes to thank Claus 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&#275;tnieks, John Levine, Alexey Melnikov, Keith Moore,
   Michael Peddemors, Hector Santos, George Schlossnagle, Rolf E.
   Sonneveld, and Alessandro Vesely for their contributions and reviews.

Freed                   Expires January 13, 2022                [Page 9]
Internet-Draft              LIMITS Extension                   July 2021

Author's Address

   Ned Freed


Freed                   Expires January 13, 2022               [Page 10]