The LIMITS SMTP Service Extension
draft-freed-smtp-limits-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9422.
|
|
|---|---|---|---|
| Author | Ned Freed | ||
| Last updated | 2021-04-18 (Latest revision 2021-03-15) | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-06)
by Paul Kyzivat
Ready w/issues
|
||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 9422 (Proposed Standard) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-freed-smtp-limits-02
Network Working Group N. Freed
Internet-Draft Oracle
Intended status: Standards Track April 18, 2021
Expires: October 20, 2021
The LIMITS SMTP Service Extension
draft-freed-smtp-limits-02
Abstract
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 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 https://datatracker.ietf.org/drafts/current/.
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 October 20, 2021.
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
(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 Simplified BSD License text as described in Section 4.e of
Freed Expires October 20, 2021 [Page 1]
Internet-Draft LIMITS Extension April 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
connections.
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
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 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 needed to issue a command. The mechanism specified here
avoids the overhead of that approach 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 or LMTP
session. This information, combined with the inherent flexibility of
these protocols, 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.
Freed Expires October 20, 2021 [Page 2]
Internet-Draft LIMITS Extension April 2021
2. Terminology
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
[KEYWORDS].
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 abbreviation, 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 October 20, 2021 [Page 3]
Internet-Draft LIMITS Extension April 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 hand in-session limit changes.
3.5. Interaction With SMTP Minimums
Section 4.5.3.1 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 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.
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 October 20, 2021 [Page 4]
Internet-Draft LIMITS Extension April 2021
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.
3.7. 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 5
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 5
Freed Expires October 20, 2021 [Page 5]
Internet-Draft LIMITS Extension April 2021
4.3. RCPTDOMAINMAX Limit
Name: RCPTDOMAINMAX
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
command.
Restrictions: None.
Security Considerations: See Section 5
5. 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.
6. IANA Considerations
6.1. SMTP Service Extension Registry
The IANA is requested to add "LIMITS" to the SMTP Service Extension
Registry:
Keywords: LIMITS
Description: Server limits
Reference: [RFCxxxx]
Freed Expires October 20, 2021 [Page 6]
Internet-Draft LIMITS Extension April 2021
6.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
document.
7. References
7.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,
<https://www.rfc-editor.org/info/rfc5234>.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[PIPELINING]
Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
September 2000, <https://www.rfc-editor.org/info/rfc2920>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
Freed Expires October 20, 2021 [Page 7]
Internet-Draft LIMITS Extension April 2021
7.2. Informative References
[AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954,
DOI 10.17487/RFC4954, July 2007,
<https://www.rfc-editor.org/info/rfc4954>.
[LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
DOI 10.17487/RFC2033, October 1996,
<https://www.rfc-editor.org/info/rfc2033>.
[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,
<https://www.rfc-editor.org/info/rfc1870>.
[STARTTLS]
Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
Appendix A. Acknowledgements
A lot of people have helped make this specification possible. The
author wishes to thank Claus Assmann, Laura Atkins, Alex Brotman,
Dave Crocker, Viktor Dukhovni, Jeremy Harris, Todd Herr, Matthias
Leisi, John Klensin, Valdis Klētnieks, John Levine, Alexey
Melnikov, Keith Moore, Michael Peddemors, Rolf E. Sonneveld, and
Alessandro Vesely for their contributions.
Author's Address
Ned Freed
Oracle
Email: ned.freed@mrochek.com
Freed Expires October 20, 2021 [Page 8]