Network Working Group N. Freed Internet-Draft Oracle Intended status: Standards Track March 15, 2021 Expires: September 16, 2021 The LIMITS SMTP Service Extension draft-freed-smtp-limits-01 Abstract This 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. 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 September 16, 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 September 16, 2021 [Page 1] Internet-Draft LIMITS Extension March 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction The Simple Mail Transfer Protocol [SMTP] 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. 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. Freed Expires September 16, 2021 [Page 2] Internet-Draft LIMITS Extension March 2021 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]. 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: limits-param = limit-name-value [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 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. 3.3. Interaction With Pipelining The SMTP "Pipelining" extension [PIPELINING] 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. Freed Expires September 16, 2021 [Page 3] Internet-Draft LIMITS Extension March 2021 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 cover in-session limitation 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 SMTP requires that EHLO command be reissued Under certain circumstances, e.g., after successful authentication [AUTH] or negotiation of a security layer [STARTTLS]. 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. Freed Expires September 16, 2021 [Page 4] Internet-Draft LIMITS Extension March 2021 4. Initial Limits An initial set of limits are specified in the following sections. 4.1. MAILMAX Limit Name: MAILMAX Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: 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 Section 5 4.2. RCPTMAX Limit Name: RCPTMAX Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: 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 Section 5 4.3. RCPTDOMAINMAX Limit Name: RCPTDOMAINMAX Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum Description: 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 Section 5 Freed Expires September 16, 2021 [Page 5] Internet-Draft LIMITS Extension March 2021 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] 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. Security considerations for the limit The IANA is also requested to register the limits specified in this document. Freed Expires September 16, 2021 [Page 6] Internet-Draft LIMITS Extension March 2021 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, . [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [PIPELINING] 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, . 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, . [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, . [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . Appendix A. Acknowledgements 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. Freed Expires September 16, 2021 [Page 7] Internet-Draft LIMITS Extension March 2021 Author's Address Ned Freed Oracle Email: ned.freed@mrochek.com Freed Expires September 16, 2021 [Page 8]