The LIMITS SMTP Service ExtensionOraclened.freed@mrochek.com
Art
Internet-DraftThis document defines a “Limits” extension for the Simple Mail
Transfer Protocol (SMTP) and an associated limit registry.
This extension provides the means for an SMTP server to inform the
SMTP client of limits the server intends to apply to the protocol
during the current SMTP session. The client is then able adapt its
behavior in order to conform to those limits.The Simple Mail Transfer Protocol provides the ability to
transfer multiple email messages from one host to another, each with
multiple recipients, using a single or multiple connections.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
client.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.SMTP servers have always been able to announce a limit, in a
reply, which means that the client first needed to issue a command. The
mechanism specified here avoids the overhead of that interactions, by
announcing limits prior to any substantive interaction.The “Limits” extension provides the means for a server
to inform a client about specific limits in effect for
a particular SMTP session. This information, combined with the
inherent flexibility of SMTP, makes it possible for clients
to avoid server errors and the problems they cause.Limits are registered with the IANA. Each registration includes
the limit name, value syntax, and a description of its semantics.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, RFC 2119
.This specification uses the Augmented Backus-Naur Form
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 .Extensions to SMTP are defined in Section 2.2 of .The name of the extension is “Limits”. Servers implementing this
extension advertise an additional “LIMITS” EHLO 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: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.In order to achieve consistent behavior, all limits MUST be
registered with the IANA, as described below.Limit names MUST be comprehensible, but also should
be kept as short as possible. The use of commonly understood
abbreviation, e.g., “MAX” for “maximum”, is encouraged.When a limit is associated with a particular SMTP, its name
SHOULD begin with the name of that command.Limit names SHOULD end with one or more terms that describe
the type of limit.The SMTP “Pipelining” extension is commonly used
to improve SMTP 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 below. But
counting the total number of RCPT TOs is simple, whereas
counting 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 session
progresses, based on their obtaining more information.
This extension does not cover in-session limitation changes.Section 4.5.3.1 of specifies minimum values for
various server sizes, limits, and timeouts, e.g., servers must
accept a minimum of 100 RCPT TO commands (section 4.5.3.1.8).
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.SMTP requires that EHLO command be reissued Under certain
circumstances, e.g., after successful authentication
or negotiation of a security layer .Servers MAY update their 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.An initial set of limits are specified in the following sections.Name: MAILMAXValue syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximumDescription: RCPTMAX specifies the maximum number of transactions
(MAIL FROM commands) the SMTP will accept in a single session. The
count includes all MAIL FROM commands, regardless of whether they
succeed or fail.Security Considerations: See Name: RCPTMAXValue syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximumDescription: RCPTMAX specifies the maximum number of RCPT TO commands
the SMTP 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.Security Considerations: See Name: RCPTDOMAINMAXValue syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximumDescription: RCPTMAX specifies the maximum number of different domains
that can appear in a recipient (RCPT TO) address within a single
SMTP session. This limit is imposed by some servers that bind to
a specific internal delivery mechanism on receipt of the first
RCPT TO command.Security Considerations: See 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 , which provides servers with the
ability to indicate message size, indicates that such abuse is
rare and unlikely to be a significant problem.The IANA is requested to add “LIMITS” to the SMTP Service
Extension 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:The name of the limitThe syntax of the limit value, if the limit has one. Use of
is preferred but not required.A description of the limit’s semanticsSecurity considerations for the limitThe IANA is also requested to register the limits specified in
this document.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Augmented BNF for Syntax Specifications: ABNFInternet 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]Simple Mail Transfer ProtocolThis 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]SMTP Service Extension for Command PipeliningThis memo defines an extension to the Simple Mail Transfer Protocol (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]SMTP Service Extension for Secure SMTP over Transport Layer SecurityThis 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]SMTP Service Extension for AuthenticationThis document defines a Simple Mail Transport 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.This document obsoletes RFC 2554. [STANDARDS-TRACK]SMTP Service Extension for Message Size DeclarationThis 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]A lot of people have helped make this specification possible. The author wishes
to thank Laura Atkins, Alex Brotman, Dave Crocker, Viktor Dukhovni,
Jeremy Harris, Todd Herr, Matthias Leisi ,
John Klensin, John Levine, and Michael Peddemors for their contributions.