idnits 2.17.00 (12 Aug 2021) /tmp/idnits41073/draft-ietf-emailcore-as-02.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 11, 2021) is 313 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) -- 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) -- Duplicate reference: RFC5321, mentioned in 'RFC5321', was also mentioned in 'ID.RFC5321bis'. -- Duplicate reference: RFC5322, mentioned in 'RFC5322', was also mentioned in 'ID.RFC5322bis'. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMAILCORE J. Klensin, Ed. 3 Internet-Draft 4 Intended status: Standards Track K. Murchison 5 Expires: January 12, 2022 Fastmail 6 E. Sam 7 July 11, 2021 9 Applicability Statement for IETF Core Email Protocols 10 draft-ietf-emailcore-as-02 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 Note on draft-ietf-emailcore-as-01 25 This version is provided as a document management convenience to 26 update the author list and make an un-expired version available to 27 the WG. There are no substantive changes from the prior version. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 12, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 65 3. Applicability of Message Format Provisions . . . . . . . . . 3 66 4. Use of IP addresses/domain names in EHLO . . . . . . . . . . 4 67 5. Extension Keywords Starting in X- . . . . . . . . . . . . . . 4 68 6. IP address literals in EHLO . . . . . . . . . . . . . . . . . 4 69 7. Use of empty quote strings in email messages . . . . . . . . 5 70 8. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5 71 9. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 13.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 79 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) 80 to draft-ietf-emailcore-as-00 . . . . . . . . . . . . 8 81 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to 82 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to 84 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 In its current form, this draft is a placeholder and beginning of an 90 outline for the Applicability Statement that has been discussed as a 91 complement for proposed revisions of the base protocol specifications 92 for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis]) 93 and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis 95 [ID.RFC5322bis]). Among other things, it is expected to capture 96 topics that a potential WG concludes are important but that should 97 not become part of those core documents. 99 As discussed in RFC 2026 [RFC2026], 101 "An Applicability Statement specifies how, and under what 102 circumstances, one or more TSs may be applied to support a 103 particular Internet capability." 105 That form of a standards track document is appropriate because one of 106 the roles of such a document is to explain the relationship among 107 technical specification, describe how they are used together, and 108 make statements about what is "required, recommended, or elective". 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119] and 113 RFC 8174 [RFC8174]. 115 2. Applicability of Some SMTP Provisions 117 Over the years since RFC 5321 was published in October 2008, usage of 118 SMTP has evolved, machines and network speeds have increased, and the 119 frequency with which SMTP senders and receivers have to be prepared 120 to deal with systems that are disconnected from the Internet for long 121 periods or that require many hops to reach has decreased. During the 122 same period, the IETF has become much more sensitive to privacy and 123 security issues and the need to be more resistant or robust against 124 spam and other attacks. In addition SMTP (and Message Format) 125 extensions have been introduced that are expected to evolve the 126 Internet's mail system to better accommodate environments in which 127 Basic Latin Script is not the norm. 129 This section describes adjustments that may be appropriate for SMTP 130 under various circumstances and discusses the applicability of other 131 protocols that represent newer work or that are intended to deal with 132 relatively newer issues. 134 [[CREF1: ... Actual content to be supplied after WG consideration. 135 ]] 137 3. Applicability of Message Format Provisions 139 Placeholder: 140 I am not sure what, if anything, goes here. If nothing does, we drop 141 the section. 143 [[CREF2: ... Actual content to be supplied after WG consideration.]] 145 4. Use of IP addresses/domain names in EHLO 147 There has been a suggestion to update RFC 5321 [RFC5321] to clarify 148 that servers may verify the domain name in the EHLO command to see if 149 it matches up with the IP address of the client. The reasoning 150 behind this was that many mail servers were already verifying the 151 domain name provided with the EHLO command for anti spam purposes, 152 and that mail servers that don't have a matching domain name/IP 153 address are more likely to have their mail rejected. 155 People for this change say that this is the "de facto" practice and 156 that it should be formally specified since basically all mail servers 157 are verifying the EHLO domain name anyway. 159 People against this argue that the domain names supplied with the 160 EHLO command won't always have a matching IP because they are 161 internal domain names or a custom domain convention. 163 The consensus was that this should be specified within RFC 5231 due 164 to the fact it is already taking place to prevent spam. 166 5. Extension Keywords Starting in X- 168 Since the release of the SMTP RFC, opinons on "X" extensions have 169 changed over the years. These opinions can best be represented by 170 RFC 6648 [RFC6648]. In short, people are beginning to "shy away" 171 from the usage of "X" extensions. 173 The proposed changes would involve the removal of the "X" extension 174 provisions in Section 2.2.2 of the SMTP RFC, and also called for the 175 removal of how to deal with "X" extensinos in the IANA considerations 176 and private-use commands. 178 While the exact solution is being talked about, the general consensus 179 is that its a good idea for this part of the RFC to be removed or 180 reformed. 182 6. IP address literals in EHLO 184 One of the proposed ideas on the mailing list was to clarify if IP 185 addresses are allowed to be used as a EHLO parameter. While the 186 original specification allowed for the use of IP addresses instead of 187 a domain name, it didn't say if the mail server was required to 188 accept IP addresses 189 The people that suggest that the specification should not require IP 190 addresses to be accepted say that anti-spam systems already reject 191 emails with IP addresses in EHLO commands, just like how they reject 192 domain names that don't match up with a valid IP. 194 However, some say there are some valid use cases for EHLO commands to 195 have IP literals, for example in private networks. 197 The general opinion is that the specification should have a section 198 explaining why IP addresses are not recommended as an EHLO parameter, 199 but should not ban IP literals outright. 201 7. Use of empty quote strings in email messages 203 quoted-string ABNF non terminal is used in various places in 204 rfc5322bis grammar. While it allows for empty quoted string, such 205 construct is going to cause interoperability issues when used in 206 certain header fields. In particular, use of empty quoted strings is 207 NOT RECOMMENDED in "received-token" (a component of a Received header 208 field), "keywords" (a component of a Keywords header field) and 209 "local-part" (left hand side of email addresses). Use of empty 210 quoted strings is in particular problematic in the "local-part". For 211 example, all of the following email addresses are non interoperable: 213 "".bar@example.com 215 foo.""@example.net 217 ""@example.com 219 Use of empty quoted strings is fine in "display-name". 221 8. MIME and Its Implications 223 When the work leading to the original version of the MIME 224 specification was completed in 1992 [RFC1341], the intention was that 225 it be kept separate from the specification for basic mail headers in 226 RFC 822 [RFC0822]. That plan was carried forward into RFC 822's 227 successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322] and the 228 successors of that original MIME specification including RFC 2045 229 [RFC2045]. The decision to do so was different from the one made for 230 SMTP, for which the core specification was changed to allow for the 231 extension mechanism [RFC1425] which was then incorporated into RFC 232 5321 and its predecessor [RFC2821]. 234 Various uses of MIME have become nearly ubiquitous in contemporary 235 email while others may have fallen into disuse or been repurposed 236 from the intent of their original design. 238 It may be appropriate to make some clear statements about the 239 applicability of MIME and its features. 241 9. Other Stuff 243 It is fairly clear that there will be things that do not fit into the 244 sections outlined above. As one example, if the IETF wants to say 245 something specific about signatures over headers or what (non-trace) 246 headers may reasonably be altered in transit, that may be more 247 appropriate to other sections than to any of the three suggested 248 above. 250 10. Acknowledgments 252 The Emailcore group arose out of discussions on the ietf-smtp group 253 over changes and additions that should be made to the core email 254 protocols. It was agreed upon that it was time to create a working 255 group that would fix many potential errors and opportunities for 256 misunderstandings within the RFCs 258 11. IANA Considerations 260 This memo includes no requests to or actions for IANA. The IANA 261 registries associated with the protocol specifications it references 262 are specified in their respective documents. 264 12. Security Considerations 266 All drafts are required to have a security considerations section and 267 this one eventually will. 269 ... To be supplied ... 271 13. References 273 13.1. Normative References 275 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 276 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 277 . 279 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 280 Extensions (MIME) Part One: Format of Internet Message 281 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 282 . 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 13.2. Informative References 295 [ID.RFC5321bis] 296 Klensin, J., "Simple Mail Transfer Protocol", Feburary 297 2021, . 300 [ID.RFC5322bis] 301 Resnick, P., "Internet Message Format", March 2021, 302 . 305 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 306 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 307 August 1982, . 309 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 310 Mail Extensions): Mechanisms for Specifying and Describing 311 the Format of Internet Message Bodies", RFC 1341, 312 DOI 10.17487/RFC1341, June 1992, 313 . 315 [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 316 D. Crocker, "SMTP Service Extensions", February 1993, 317 . 319 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 320 RFC 2821, DOI 10.17487/RFC2821, April 2001, 321 . 323 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 324 DOI 10.17487/RFC2822, April 2001, 325 . 327 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 328 DOI 10.17487/RFC5321, October 2008, 329 . 331 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 332 DOI 10.17487/RFC5322, October 2008, 333 . 335 [RFC6648] Saint-Andre, P., Nottingham, N., Ed., and D. Crocker, 336 "Deprecating the "X-" Prefix and Similar Constructs in 337 Application Protocols", June 2012, 338 . 340 Appendix A. Change Log 342 RFC Editor: Please remove this appendix before publication. 344 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft- 345 ietf-emailcore-as-00 347 o Change of filename, metadata, and date to reflect transition to WG 348 document for new emailcore WG. No other substantive changes 350 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 352 o Added co-authors (list is in alphabetical order for the present). 354 o Updated references to 5321bis and 5322bis. 356 o Added note at top, "This version is provided as a document 357 management convenience to update the author list and make an un- 358 expired version available to the WG. There are no substantive 359 changes from the prior version", which should be removed for 360 version -02. 362 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 364 o Added new editors and also added some issues the emailcore group 365 will be dealing with. 367 o Added reference to RFC 6648. 369 Authors' Addresses 371 John C Klensin (editor) 372 1770 Massachusetts Ave, Ste 322 373 Cambridge, MA 02140 374 USA 376 Phone: +1 617 245 1457 377 Email: john-ietf@jck.com 378 Kenneth Murchison 379 Fastmail US LLC 380 1429 Walnut Street - Suite 1201 381 Philadelphia, PA 19102 382 USA 384 Email: murch@fastmailteam.com 386 E Sam 388 Email: winshell64@gmail.com