idnits 2.17.00 (12 Aug 2021) /tmp/idnits19803/draft-ietf-emailcore-as-04.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 document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (31 January 2022) is 103 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) == Outdated reference: A later version (-10) exists of draft-ietf-emailcore-rfc5321bis-08 == Outdated reference: A later version (-03) exists of draft-ietf-emailcore-rfc5322bis-02 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 1425 (Obsoleted by RFC 1651) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMAILCORE J.C. Klensin, Ed. 3 Internet-Draft 4 Intended status: Standards Track K. Murchison, Ed. 5 Expires: 4 August 2022 Fastmail 6 E. Sam, Ed. 7 31 January 2022 9 Applicability Statement for IETF Core Email Protocols 10 draft-ietf-emailcore-as-04 12 Abstract 14 Electronic mail is one of the oldest Internet applications that is 15 still in very active use. While the basic protocols and formats for 16 mail transport and message formats have evolved slowly over the 17 years, events and thinking in more recent years have supplemented 18 those core protocols with additional features and suggestions for 19 their use. This Applicability Statement describes the relationship 20 among many of those protocols and provides guidance and makes 21 recommendations for the use of features of the core protocols. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 4 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 58 2.1. Handling of the Domain Argument to the EHLO Command . . . 3 59 2.2. Use of Address Literals . . . . . . . . . . . . . . . . . 4 60 2.3. Use of Addresses in Top-Level Domains . . . . . . . . . . 4 61 2.4. Use of SMTP Extensions . . . . . . . . . . . . . . . . . 4 62 3. Applicability of Message Format Provisions . . . . . . . . . 5 63 3.1. Use of Empty Quoted Strings . . . . . . . . . . . . . . . 5 64 4. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5 65 5. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 73 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to 74 draft-ietf-emailcore-as-00 . . . . . . . . . . . . . . . 8 75 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to 76 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to 78 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to 80 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to 82 -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 In its current form, this draft is a placeholder and beginning of an 88 outline for the Applicability Statement that has been discussed as a 89 complement for proposed revisions of the base protocol specifications 90 for SMTP [RFC5321] (being revised as [I-D.ietf-emailcore-rfc5321bis]) 91 and Internet Message Format [RFC5322] (being revised as 92 [I-D.ietf-emailcore-rfc5322bis]). Among other things, it is expected 93 to capture topics that a potential WG concludes are important but 94 that should not become part of those core documents. 96 As discussed in [RFC2026], 97 "An Applicability Statement specifies how, and under what 98 circumstances, one or more TSs may be applied to support a 99 particular Internet capability." 101 That form of a standards track document is appropriate because one of 102 the roles of such a document is to explain the relationship among 103 technical specifications, describe how they are used together, and 104 make statements about what is "required, recommended, or elective". 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119] and 109 [RFC8174]. 111 2. Applicability of Some SMTP Provisions 113 Over the years since RFC 5321 was published in October 2008, usage of 114 SMTP has evolved, machines and network speeds have increased, and the 115 frequency with which SMTP senders and receivers have to be prepared 116 to deal with systems that are disconnected from the Internet for long 117 periods or that require many hops to reach has decreased. During the 118 same period, the IETF has become much more sensitive to privacy and 119 security issues and the need to be more resistant or robust against 120 spam and other attacks. In addition SMTP (and Message Format) 121 extensions have been introduced that are expected to evolve the 122 Internet's mail system to better accommodate environments in which 123 Basic Latin Script is not the norm. 125 This section describes adjustments that may be appropriate for SMTP 126 under various circumstances and discusses the applicability of other 127 protocols that represent newer work or that are intended to deal with 128 relatively newer issues. 130 2.1. Handling of the Domain Argument to the EHLO Command 132 If the Domain argument to the EHLO command does not have an address 133 record in the DNS that matches the IP address of the client, the SMTP 134 server may refuse any mail from the client as part of established 135 anti-abuse practice. Operational experience has demonstrated that 136 the lack of a matching address record for the the domain name 137 argument is at best an indication of a poorly-configured MTA, and at 138 worst that of an abusive host. 140 2.2. Use of Address Literals 142 The address-literal ABNF non-terminal is used in various places in 143 [I-D.ietf-emailcore-rfc5321bis] grammar however, for SMTP connections 144 over the public internet, an address-literal as the argument to EHLO 145 command or the Domain part of the Mailbox argument to the MAIL FROM 146 command is quite likely to result in the message being rejected as a 147 matter of policy at many sites, since they are deemed to be signs of 148 at best a misconfigured server, and at worst either a compromised 149 host or a server that's intentionally configured to hide its 150 identity. 152 2.3. Use of Addresses in Top-Level Domains 154 While addresses in top-level domains (TLDs) are syntactically valid, 155 mail to these addresses has never worked reliably. A handful of 156 country code TLDs have top level MX records but they have never been 157 widely used nor well supported. In 2013 [RFC7085] found 18 TLDs with 158 MX records, which dropped to 17 in 2021 despite many new TLDs having 159 been added. 161 Mail sent to addresses with single label domains has typically 162 expected the address to be an abbreviation to be completed by a 163 search list, so mail to bob@sales would be completed to 164 bob@sales.example.com. This shortcut has led to unfortunate 165 consequnces; in one famous case, in 1991 when the .CS domain was 166 added to the root, mail in computer science departments started to 167 fail as mail to bob@cs was now treated as mail to Czechoslovakia. 168 Hence, for reliable service, mail SHOULD NOT use addreses that 169 contain single label domains. 171 2.4. Use of SMTP Extensions 173 As SMTP has evolved over the years, several extensions have become 174 ubiquitous. As a result, the following extensions MUST be supported 175 by SMTP senders and receivers: 177 * 8-bit MIME [RFC6152] 179 * Enhanced Mail System Status Codes [RFC5248] 181 * Deliver Status Notifications [RFC3461] 183 Similarly, the following extensions SHOULD be supported by SMTP 184 senders and receivers: 186 * Command Pipelining [RFC2920] 187 * Internationalized Email [RFC6531] 189 3. Applicability of Message Format Provisions 191 This section describes adjustments to the Internet Message Format 192 that may be appropriate under various circumstances. 194 3.1. Use of Empty Quoted Strings 196 The quoted-string ABNF non-terminal is used in various places in 197 rfc5322bis grammar. While it allows for empty quoted string, such 198 construct is going to cause interoperability issues when used in 199 certain header fields. In particular, use of empty quoted strings is 200 NOT RECOMMENDED in "received-token" (a component of a Received header 201 field), "keywords" (a component of a Keywords header field) and 202 "local-part" (left hand side of email addresses). Use of empty 203 quoted strings is in particular problematic in the "local-part". For 204 example, all of the following email addresses are non interoperable: 206 "".bar@example.com 208 foo.""@example.net 210 ""@example.com 212 Use of empty quoted strings is fine in "display-name". 214 4. MIME and Its Implications 216 When the work leading to the original version of the MIME 217 specification was completed in 1992 [RFC1341], the intention was that 218 it be kept separate from the specification for basic mail headers in 219 RFC 822 [RFC0822]. That plan was carried forward into RFC 822's 220 successors, [RFC2822] and [RFC5322] and the successors of that 221 original MIME specification including [RFC2045]. The decision to do 222 so was different from the one made for SMTP, for which the core 223 specification was changed to allow for the extension mechanism 224 [RFC1425] which was then incorporated into RFC 5321 and its 225 predecessor [RFC2821]. 227 Various uses of MIME have become nearly ubiquitous in contemporary 228 email while others may have fallen into disuse or been repurposed 229 from the intent of their original design. 231 It may be appropriate to make some clear statements about the 232 applicability of MIME and its features. 234 5. Other Stuff 236 It is fairly clear that there will be things that do not fit into the 237 sections outlined above. As one example, if the IETF wants to say 238 something specific about signatures over headers or what (non-trace) 239 headers may reasonably be altered in transit, that may be more 240 appropriate to other sections than to any of the three suggested 241 above. 243 6. Acknowledgments 245 The Emailcore group arose out of discussions on the ietf-smtp group 246 over changes and additions that should be made to the core email 247 protocols. It was agreed upon that it was time to create a working 248 group that would fix many potential errors and opportunities for 249 misunderstandings within the RFCs. 251 7. IANA Considerations 253 This memo includes no requests to or actions for IANA. The IANA 254 registries associated with the protocol specifications it references 255 are specified in their respective documents. 257 8. Security Considerations 259 All drafts are required to have a security considerations section and 260 this one eventually will. 262 ... To be supplied ... 264 9. References 266 9.1. Normative References 268 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 269 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 270 . 272 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 273 Extensions (MIME) Part One: Format of Internet Message 274 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 275 . 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 9.2. Informative References 288 [I-D.ietf-emailcore-rfc5321bis] 289 Klensin, J. C., "Simple Mail Transfer Protocol", Work in 290 Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis- 291 08, 31 December 2021, . 294 [I-D.ietf-emailcore-rfc5322bis] 295 Resnick, P. W., "Internet Message Format", Work in 296 Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis- 297 02, 29 September 2021, . 300 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 301 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 302 August 1982, . 304 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 305 Mail Extensions): Mechanisms for Specifying and Describing 306 the Format of Internet Message Bodies", RFC 1341, 307 DOI 10.17487/RFC1341, June 1992, 308 . 310 [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 311 D. Crocker, "SMTP Service Extensions", February 1993, 312 . 314 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 315 RFC 2821, DOI 10.17487/RFC2821, April 2001, 316 . 318 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 319 DOI 10.17487/RFC2822, April 2001, 320 . 322 [RFC2920] Freed, N., "SMTP Service Extension for Command 323 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 324 September 2000, . 326 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 327 Extension for Delivery Status Notifications (DSNs)", 328 RFC 3461, DOI 10.17487/RFC3461, January 2003, 329 . 331 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 332 Mail System Status Codes", BCP 138, RFC 5248, 333 DOI 10.17487/RFC5248, June 2008, 334 . 336 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 337 DOI 10.17487/RFC5321, October 2008, 338 . 340 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 341 DOI 10.17487/RFC5322, October 2008, 342 . 344 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 345 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 346 RFC 6152, DOI 10.17487/RFC6152, March 2011, 347 . 349 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 350 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 351 . 353 [RFC7085] Levine, J. and P. Hoffman, "Top-Level Domains That Are 354 Already Dotless", RFC 7085, DOI 10.17487/RFC7085, December 355 2013, . 357 Appendix A. Change Log 359 RFC Editor: Please remove this appendix before publication. 361 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft- 362 ietf-emailcore-as-00 364 * Change of filename, metadata, and date to reflect transition to WG 365 document for new emailcore WG. No other substantive changes 367 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 369 * Added co-authors (list is in alphabetical order for the present). 371 * Updated references to 5321bis and 5322bis. 373 * Added note at top, "This version is provided as a document 374 management convenience to update the author list and make an un- 375 expired version available to the WG. There are no substantive 376 changes from the prior version", which should be removed for 377 version -02. 379 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 381 * Added new editors and also added some issues the emailcore group 382 will be dealing with. 384 * Added reference to RFC 6648. 386 A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to -03 388 * Moved discussion of address-literals (issue #1) and domain names 389 in EHLO (issue #19) under SMTP Provisions section 391 * Moved discussion of empty quoted-strings under Message Format 392 Provisions section 394 * Added text on use of addresses in TLDs (issue #50) 396 * Marked all authors as editors. 398 * Miscellaneous editorial changes. 400 A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to -04 402 * Added requirements for SMTP extensions (issue #40). 404 Authors' Addresses 406 John C Klensin (editor) 407 1770 Massachusetts Ave, Ste 322 408 Cambridge, MA 02140 409 United States of America 411 Phone: +1 617 245 1457 412 Email: john-ietf@jck.com 414 Kenneth Murchison (editor) 415 Fastmail US LLC 416 1429 Walnut Street - Suite 1201 417 Philadelphia, PA 19102 418 United States of America 420 Email: murch@fastmailteam.com 422 E Sam (editor) 424 Email: winshell64@gmail.com