idnits 2.17.1 draft-freed-smtp-limits-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 15, 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 260, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft Oracle 4 Intended status: Standards Track March 15, 2021 5 Expires: September 16, 2021 7 The LIMITS SMTP Service Extension 8 draft-freed-smtp-limits-01 10 Abstract 12 This document defines a "Limits" extension for the Simple Mail 13 Transfer Protocol (SMTP) and an associated limit registry. This 14 extension provides the means for an SMTP server to inform the SMTP 15 client of limits the server intends to apply to the protocol during 16 the current SMTP session. The client is then able adapt its behavior 17 in order to conform to those limits. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 16, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 The Simple Mail Transfer Protocol [SMTP] provides the ability to 54 transfer multiple email messages from one host to another, each with 55 multiple recipients, using a single or multiple connections. 57 In order to conserve resources as well as protect themselves from 58 malicious clients, it is necessary for servers to enforce limits on 59 various aspects of the protocol, e.g., a limit on the number of 60 recipients that can be specified in a single transaction. 62 Additionally, servers may also wish to alter the limits they apply 63 depending on their assessment of the reputation of a particular 64 client. 66 The variability of the limits that may be in effect creates a 67 situation where clients may inadvertently exceed a particular 68 server's limits, causing servers to respond with temporary (or in 69 some cases, permanent) errors. This in turn can lead to delays or 70 even failures in message transfer. 72 SMTP servers have always been able to announce a limit, in a reply, 73 which means that the client first needed to issue a command. The 74 mechanism specified here avoids the overhead of that interactions, by 75 announcing limits prior to any substantive interaction. 77 The "Limits" extension provides the means for a server to inform a 78 client about specific limits in effect for a particular SMTP session. 79 This information, combined with the inherent flexibility of SMTP, 80 makes it possible for clients to avoid server errors and the problems 81 they cause. 83 Limits are registered with the IANA. Each registration includes the 84 limit name, value syntax, and a description of its semantics. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 91 [KEYWORDS]. 93 This specification uses the Augmented Backus-Naur Form [ABNF] 94 notation and its core rules to define the formal syntax of the 95 "Limits" extension. 97 This specification makes extensive use of the terminology specified 98 and used in [SMTP]. 100 3. The "Limits" SMTP Extension 102 Extensions to SMTP are defined in Section 2.2 of [SMTP]. 104 The name of the extension is "Limits". Servers implementing this 105 extension advertise an additional "LIMITS" EHLO keyword. The 106 associated parameter is used by the server to communicate one or more 107 limits, each with an optional value, to the client. The syntax of 108 the parameter is: 110 limits-param = limit-name-value [SP limit-name-value] 111 limit-name-value = limit-name ["=" limit-value] 112 limit-name = 1*(ALPHA / DIGIT / "-" / "_") 113 limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";" 115 This extension introduces no new SMTP commands, and does not alter 116 any existing command. However, it is possible for a LIMITS parameter 117 to be associated with another SMTP extension that does these things. 119 3.1. Limits 121 In order to achieve consistent behavior, all limits MUST be 122 registered with the IANA, as described below. 124 3.2. Limit Naming Conventions 126 Limit names MUST be comprehensible, but also should be kept as short 127 as possible. The use of commonly understood abbreviation, e.g., 128 "MAX" for "maximum", is encouraged. 130 When a limit is associated with a particular SMTP, its name SHOULD 131 begin with the name of that command. 133 Limit names SHOULD end with one or more terms that describe the type 134 of limit. 136 3.3. Interaction With Pipelining 138 The SMTP "Pipelining" extension [PIPELINING] is commonly used to 139 improve SMTP performance, especially over high latency connections. 140 Pipelining allows entire transaction to be sent without checking 141 responses and in some cases it may be possible to send multiple 142 transactions. 144 The use of pipelining affects limits in an important way: Since a 145 pipelining client cannot check intermediate command responses without 146 stalling the pipeline, it cannot count the number of succesful versus 147 failed responses and adjust its behavior accordingly. Limit 148 designers need to take this into account. 150 For example, it may seem like it would be better to impose a limit on 151 the number of succesful RCPT TO commands as opposed to the way the 152 RCPTMAX limit is specified in Section 4.2 below. But counting the 153 total number of RCPT TOs is simple, whereas counting the number of 154 successful RCPT TO stalls the pipeline. 156 3.4. Varying Limits 158 This extension provides an announcement as part of the reply to an 159 EHLO command. Some servers vary their limits, as a session 160 progresses, based on their obtaining more information. This 161 extension does not cover in-session limitation changes. 163 3.5. Interaction With SMTP Minimums 165 Section 4.5.3.1 of [SMTP] specifies minimum values for various server 166 sizes, limits, and timeouts, e.g., servers must accept a minimum of 167 100 RCPT TO commands (section 4.5.3.1.8). Unfortunately, the reality 168 is that servers routinely impose smaller limits than what SMTP 169 requires, and when this is done it's especially important for clients 170 to be aware that this is happening. 172 For this reason there is no requirement that the limits advertised by 173 this extension comply with the minimums imposed by SMTP. 175 3.6. Multiple EHLO Commands 177 SMTP requires that EHLO command be reissued Under certain 178 circumstances, e.g., after successful authentication [AUTH] or 179 negotiation of a security layer [STARTTLS]. 181 Servers MAY update their limits any time the protocol requires 182 clients to reissue the EHLO command. Clients MUST discard any 183 previous limits in favor of those provided by the most recent EHLO. 184 This includes the case where the original EHLO provided a set of 185 limits but the subsequent EHLO did not; in this case the client MUST 186 act as if no limits were communicated. 188 4. Initial Limits 190 An initial set of limits are specified in the following sections. 192 4.1. MAILMAX Limit 194 Name: MAILMAX 196 Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum 198 Description: RCPTMAX specifies the maximum number of transactions 199 (MAIL FROM commands) the SMTP will accept in a single session. The 200 count includes all MAIL FROM commands, regardless of whether they 201 succeed or fail. 203 Security Considerations: See Section 5 205 4.2. RCPTMAX Limit 207 Name: RCPTMAX 209 Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum 211 Description: RCPTMAX specifies the maximum number of RCPT TO commands 212 the SMTP will accept in a single transaction. It is not a limit on 213 the actual number of recipients the message ends up being sent to; a 214 single RCPT TO command may produce multiple recipients or, in the 215 event of an error, none. 217 Security Considerations: See Section 5 219 4.3. RCPTDOMAINMAX Limit 221 Name: RCPTDOMAINMAX 223 Value syntax: %x30-39 0*5DIGIT ; 0 not allowed, 6 digit maximum 225 Description: RCPTMAX specifies the maximum number of different 226 domains that can appear in a recipient (RCPT TO) address within a 227 single SMTP session. This limit is imposed by some servers that bind 228 to a specific internal delivery mechanism on receipt of the first 229 RCPT TO command. 231 Security Considerations: See Section 5 233 5. Security Considerations 235 A malicious server can use limits to overly constrain client 236 behavior, causing excessive use of client resources. 238 A malicious client may use the limits a server advertises to optimize 239 the delivery of unwanted messages. 241 A man-in-the-middle attack on unprotected SMTP connections can be 242 used to cause clients to misbehave, which in turn could result in 243 delivery delays or failures. Loss of reputation for the client could 244 also occur. 246 All that said, decades of operational experience with the SMTP "SIZE" 247 extension [SIZE], which provides servers with the ability to indicate 248 message size, indicates that such abuse is rare and unlikely to be a 249 significant problem. 251 6. IANA Considerations 253 6.1. SMTP Service Extension Registry 255 The IANA is requested to add "LIMITS" to the SMTP Service Extension 256 Registry: 258 Keywords: LIMITS 259 Description: Server limits 260 Reference: [RFCxxxx] 262 6.2. SMTP Server Limits Registry 264 The IANA is requested to create a new registry for SMTP server 265 limits. The policy for this registry is "Specification Required". 266 Registry entries consist of three required values: 268 1. The name of the limit 270 2. The syntax of the limit value, if the limit has one. Use of 271 [ABNF] is preferred but not required. 273 3. A description of the limit's semantics 275 4. Security considerations for the limit 277 The IANA is also requested to register the limits specified in this 278 document. 280 7. References 282 7.1. Normative References 284 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 285 Specifications: ABNF", STD 68, RFC 5234, 286 DOI 10.17487/RFC5234, January 2008, 287 . 289 [KEYWORDS] 290 Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [PIPELINING] 296 Freed, N., "SMTP Service Extension for Command 297 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 298 September 2000, . 300 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 301 DOI 10.17487/RFC5321, October 2008, 302 . 304 7.2. Informative References 306 [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 307 Extension for Authentication", RFC 4954, 308 DOI 10.17487/RFC4954, July 2007, 309 . 311 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service 312 Extension for Message Size Declaration", STD 10, RFC 1870, 313 DOI 10.17487/RFC1870, November 1995, 314 . 316 [STARTTLS] 317 Hoffman, P., "SMTP Service Extension for Secure SMTP over 318 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 319 February 2002, . 321 Appendix A. Acknowledgements 323 A lot of people have helped make this specification possible. The 324 author wishes to thank Laura Atkins, Alex Brotman, Dave Crocker, 325 Viktor Dukhovni, Jeremy Harris, Todd Herr, Matthias Leisi , John 326 Klensin, John Levine, and Michael Peddemors for their contributions. 328 Author's Address 330 Ned Freed 331 Oracle 333 Email: ned.freed@mrochek.com