idnits 2.17.1 draft-ietf-emailcore-as-05.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 (23 May 2022) is 701 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-27) exists of draft-ietf-emailcore-rfc5321bis-10 == Outdated reference: A later version (-11) exists of draft-ietf-emailcore-rfc5322bis-03 -- 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 (~~), 4 warnings (==), 7 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: 24 November 2022 Fastmail 6 E. Sam, Ed. 7 23 May 2022 9 Applicability Statement for IETF Core Email Protocols 10 draft-ietf-emailcore-as-05 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 24 November 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 58 2.1. Handling of the Domain Argument to the EHLO Command . . . 4 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 . . . . . . . . . . . . . . . . . . 6 65 5. Confidentiality and Authentication with SMTP . . . . . . . . 6 66 5.1. Optional Confidentiality . . . . . . . . . . . . . . . . 7 67 5.2. Required Confidentiality, with Receiving Server 68 Authentication . . . . . . . . . . . . . . . . . . . . . 7 69 5.3. Message-Level Authentication . . . . . . . . . . . . . . 8 70 5.4. SMTP Authentication . . . . . . . . . . . . . . . . . . . 8 71 5.5. Message-Level Confidentiality . . . . . . . . . . . . . . 8 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 79 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to 80 draft-ietf-emailcore-as-00 . . . . . . . . . . . . . . . 12 81 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to 82 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to 84 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to 86 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to 88 -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 A.6. Changes from draft-ietf-emailcore-as-04 (2022-05-21) to 90 -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 In its current form, this draft is a placeholder and beginning of an 96 outline for the Applicability Statement that has been discussed as a 97 complement for proposed revisions of the base protocol specifications 98 for SMTP [RFC5321] (being revised as [I-D.ietf-emailcore-rfc5321bis]) 99 and Internet Message Format [RFC5322] (being revised as 100 [I-D.ietf-emailcore-rfc5322bis]). Among other things, it is expected 101 to capture topics that a potential WG concludes are important but 102 that should not become part of those core documents. 104 As discussed in [RFC2026], 106 "An Applicability Statement specifies how, and under what 107 circumstances, one or more TSs may be applied to support a 108 particular Internet capability." 110 That form of a standards track document is appropriate because one of 111 the roles of such a document is to explain the relationship among 112 technical specifications, describe how they are used together, and 113 make statements about what is "required, recommended, or elective". 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119] and 118 [RFC8174]. 120 2. Applicability of Some SMTP Provisions 122 Over the years since RFC 5321 was published in October 2008, usage of 123 SMTP has evolved, machines and network speeds have increased, and the 124 frequency with which SMTP senders and receivers have to be prepared 125 to deal with systems that are disconnected from the Internet for long 126 periods or that require many hops to reach has decreased. During the 127 same period, the IETF has become much more sensitive to privacy and 128 security issues and the need to be more resistant or robust against 129 spam and other attacks. In addition SMTP (and Message Format) 130 extensions have been introduced that are expected to evolve the 131 Internet's mail system to better accommodate environments in which 132 Basic Latin Script is not the norm. 134 This section describes adjustments that may be appropriate for SMTP 135 under various circumstances and discusses the applicability of other 136 protocols that represent newer work or that are intended to deal with 137 relatively newer issues. 139 2.1. Handling of the Domain Argument to the EHLO Command 141 If the Domain argument to the EHLO command does not have an address 142 record in the DNS that matches the IP address of the client, the SMTP 143 server may refuse any mail from the client as part of established 144 anti-abuse practice. Operational experience has demonstrated that 145 the lack of a matching address record for the the domain name 146 argument is at best an indication of a poorly-configured MTA, and at 147 worst that of an abusive host. 149 2.2. Use of Address Literals 151 The address-literal ABNF non-terminal is used in various places in 152 [I-D.ietf-emailcore-rfc5321bis] grammar however, for SMTP connections 153 over the public internet, an address-literal as the argument to EHLO 154 command or the Domain part of the Mailbox argument to the MAIL FROM 155 command is quite likely to result in the message being rejected as a 156 matter of policy at many sites, since they are deemed to be signs of 157 at best a misconfigured server, and at worst either a compromised 158 host or a server that's intentionally configured to hide its 159 identity. 161 2.3. Use of Addresses in Top-Level Domains 163 While addresses in top-level domains (TLDs) are syntactically valid, 164 mail to these addresses has never worked reliably. A handful of 165 country code TLDs have top level MX records but they have never been 166 widely used nor well supported. In 2013 [RFC7085] found 18 TLDs with 167 MX records, which dropped to 17 in 2021 despite many new TLDs having 168 been added. 170 Mail sent to addresses with single label domains has typically 171 expected the address to be an abbreviation to be completed by a 172 search list, so mail to bob@sales would be completed to 173 bob@sales.example.com. This shortcut has led to unfortunate 174 consequnces; in one famous case, in 1991 when the .CS domain was 175 added to the root, mail in computer science departments started to 176 fail as mail to bob@cs was now treated as mail to Czechoslovakia. 177 Hence, for reliable service, mail SHOULD NOT use addreses that 178 contain single label domains. 180 2.4. Use of SMTP Extensions 182 As SMTP has evolved over the years, several extensions have become 183 ubiquitous. As a result, the following extensions MUST be supported 184 by SMTP senders and receivers: 186 * 8-bit MIME [RFC6152] 187 * Deliver Status Notifications [RFC3461] 189 Similarly, the following extensions SHOULD be supported by SMTP 190 senders and receivers: 192 * Command Pipelining [RFC2920] 194 * Internationalized Email [RFC6531] 196 Furthermore, while Enhanced Mail System Status Codes ([RFC3463], 197 [RFC5248]) are widely supported, they are not ubiquitous. 198 Nevertheless, they have been found to be useful to SMTP senders in 199 determining the exact reason for a transmission failure in a machine- 200 readable, language-independent manner, thus allowing them to present 201 more detailed and language-specific error messages to users. Given 202 the usefulness of these enhanced codes, SMTP receivers are 203 RECOMMENDED to implement the SMTP Service Extension for Returning 204 Enhanced Error Codes [RFC2034] utilizing the codes registered in 205 [RFC5248]. 207 3. Applicability of Message Format Provisions 209 This section describes adjustments to the Internet Message Format 210 that may be appropriate under various circumstances. 212 3.1. Use of Empty Quoted Strings 214 The quoted-string ABNF non-terminal is used in various places in 215 rfc5322bis grammar. While it allows for empty quoted string, such 216 construct is going to cause interoperability issues when used in 217 certain header fields. In particular, use of empty quoted strings is 218 NOT RECOMMENDED in "received-token" (a component of a Received header 219 field), "keywords" (a component of a Keywords header field) and 220 "local-part" (left hand side of email addresses). Use of empty 221 quoted strings is in particular problematic in the "local-part". For 222 example, all of the following email addresses are non interoperable: 224 "".bar@example.com 226 foo.""@example.net 228 ""@example.com 230 Use of empty quoted strings is fine in "display-name". 232 4. MIME and Its Implications 234 When the work leading to the original version of the MIME 235 specification was completed in 1992 [RFC1341], the intention was that 236 it be kept separate from the specification for basic mail headers in 237 RFC 822 [RFC0822]. That plan was carried forward into RFC 822's 238 successors, [RFC2822] and [RFC5322] and the successors of that 239 original MIME specification including [RFC2045]. The decision to do 240 so was different from the one made for SMTP, for which the core 241 specification was changed to allow for the extension mechanism 242 [RFC1425] which was then incorporated into RFC 5321 and its 243 predecessor [RFC2821]. 245 Various uses of MIME have become nearly ubiquitous in contemporary 246 email while others may have fallen into disuse or been repurposed 247 from the intent of their original design. 249 It may be appropriate to make some clear statements about the 250 applicability of MIME and its features. 252 5. Confidentiality and Authentication with SMTP 254 SMTP is specified without embedded mechanisms for authentication or 255 confidentiality; its traffic is therefore "in the clear". Years of 256 operational experience have shown that such transmission exposes the 257 message to easy compromise, including wiretapping and spoofing. To 258 mitigate these risks, operation of SMTP has evolved over the years so 259 that it is used with the benefit of Transport Layer Security (TLS) 260 [RFC8446] to provide both confidentiality and authentication in the 261 transmission of messages. This section discusses those topics and 262 their most common uses. 264 It is important that the reader understand what is meant by the terms 265 "Authentication" and "Confidentiality", and for that we will borrow 266 directly from RFC8446. 268 * Authentication is the process of establishing the identity of one 269 or more of the endpoints of a communication channel. TLS only 270 requires authentication of the server side of the communication 271 channel; authentication of the client side is optional. 273 * The term "confidentiality" describes a state where the data (i.e., 274 the message) is transmitted in a way that it is only visible to 275 the endpoints of a communication channel. 277 It is not uncommon for implementers to use the term "encryption" to 278 mean "confidentiality", but this is not quite correct. Rather, 279 encryption using TLS is the current method by which confidentiality 280 is achieved with SMTP, but that does not mean that future methods 281 might not be developed. 283 Note: With typical email use of TLS, authentication only is performed 284 for the target receiving server and is not done for the sending 285 client. That is, it serves to validate that the connection has been 286 made to the intended server, but does not validate who initiated it. 288 5.1. Optional Confidentiality 290 The most common implementation of message confidentiality is what's 291 known as "opportunistic TLS", which is frequently referred to as 292 "opportunistic encryption". With this method, a receiving server 293 announces in its greeting that it is capable of supporting TLS 294 encryption through the presence of the "STARTTLS" keyword. The 295 sending client then attempts to negotiate an encrypted connection, 296 and if successful, transmits the message in encrypted form; if 297 negotiation fails, the client falls back to sending the message in 298 clear text. 300 Opportunistic TLS is confidentiality without authentication, because 301 no effort is made to authenticate the receiving server, and it is 302 optional confidentiality due to the ability to fall back to 303 transmission in the clear if a secure connection cannot be 304 established. That said, most modern implementations of SMTP support 305 this method, especially at the largest mailbox providers, and so the 306 vast majority of email traffic is encrypted during its time 307 transiting from the client to the server. 309 Note: While TLS provides protection while the message is in transit, 310 there is no guarantee that the message will be stored in encrypted 311 fashion at its destination. In fact, storage in plain text should be 312 expected! 314 5.2. Required Confidentiality, with Receiving Server Authentication 316 Two protocols exist that move message confidentiality from optional 317 to required (with conditions as noted below) - MTA-STS [RFC8461] and 318 DANE for SMTP [RFC7672]. While they differ in their implementation 319 details, receiving servers relying on either protocol are stating 320 that they only accept mail if the transmission can be encrypted with 321 TLS, and a failure to negotiate a secure connection MUST result in 322 the sending client refusing to transmit the message. Support for 323 both protocols is increasing, but is not yet mandatory. 325 These two protocols differ from Opportunistic TLS in that they 326 require receiving server authentication and there is no fallback to 327 sending in the clear if negotiation of an encrypted connection fails. 329 Note: Both protocols mentioned in this section rely not only on the 330 receiving server but also the sending client supporting the protocol 331 intended to be used. If the sending client does not implement or 332 understand the protocol requested by the receiving server, the 333 sending client will use Opportunistic TLS or clear-text to transmit 334 the message. 336 5.3. Message-Level Authentication 338 Protocols exist to allow for authentication of different identities 339 associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. 340 A third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow 341 for validation of the domain in the visible From header, and a 342 fourth, ARC [RFC8617], provides a way for each hop to record results 343 of authentication checks performed at that hop. 345 All of these are outside the scope of this document, as they are 346 outside the scope of SMTP. They deal with validating the authorized 347 usage of one or more domains in an email message, and not with 348 establishing the identity of the receiving server. 350 5.4. SMTP Authentication 352 SMTP Authentication [RFC4954], which is often abbreviated as SMTP 353 AUTH, is an extension to SMTP. While its name might suggest that it 354 would be within scope for this section of the Applicability 355 Statement, nothing could be further from the truth. 357 SMTP AUTH defines a method for a client to identify itself to a 358 Message Submission Agent (MSA) when presenting a message for 359 transmission, usually using port 587 rather than the traditional port 360 25. The most common implementation of SMTP AUTH is for a person to 361 present a username and password to their mailbox provider's outbound 362 SMTP server when configuring their MUA for sending mail. 364 5.5. Message-Level Confidentiality 366 Protocols such as S/MIME [RFC8551] and OpenPGP [RFC4880] exist to 367 allow for message confidentiality outside of the operation of SMTP. 368 That is to say, using these protocols results in encryption of the 369 message prior to its being submitted to the SMTP communications 370 channel, and decryption of the message is the responsibility of the 371 message recipient. There are numerous implementations of these 372 protocols, too many to list here. As they operate fully independent 373 of SMTP, they are out of scope for this document. 375 6. Acknowledgments 377 The Emailcore group arose out of discussions on the ietf-smtp group 378 over changes and additions that should be made to the core email 379 protocols. It was agreed upon that it was time to create a working 380 group that would fix many potential errors and opportunities for 381 misunderstandings within the RFCs. 383 7. IANA Considerations 385 This memo includes no requests to or actions for IANA. The IANA 386 registries associated with the protocol specifications it references 387 are specified in their respective documents. 389 8. Security Considerations 391 All drafts are required to have a security considerations section and 392 this one eventually will. 394 ... To be supplied ... 396 9. References 398 9.1. Normative References 400 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 401 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 402 . 404 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 405 Extensions (MIME) Part One: Format of Internet Message 406 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 407 . 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 415 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 416 May 2017, . 418 9.2. Informative References 420 [I-D.ietf-emailcore-rfc5321bis] 421 Klensin, J. C., "Simple Mail Transfer Protocol", Work in 422 Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis- 423 10, 7 March 2022, . 426 [I-D.ietf-emailcore-rfc5322bis] 427 Resnick, P. W., "Internet Message Format", Work in 428 Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis- 429 03, 4 April 2022, . 432 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 433 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 434 August 1982, . 436 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 437 Mail Extensions): Mechanisms for Specifying and Describing 438 the Format of Internet Message Bodies", RFC 1341, 439 DOI 10.17487/RFC1341, June 1992, 440 . 442 [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 443 D. Crocker, "SMTP Service Extensions", February 1993, 444 . 446 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 447 Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 448 1996, . 450 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 451 RFC 2821, DOI 10.17487/RFC2821, April 2001, 452 . 454 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 455 DOI 10.17487/RFC2822, April 2001, 456 . 458 [RFC2920] Freed, N., "SMTP Service Extension for Command 459 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 460 September 2000, . 462 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 463 Extension for Delivery Status Notifications (DSNs)", 464 RFC 3461, DOI 10.17487/RFC3461, January 2003, 465 . 467 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 468 RFC 3463, DOI 10.17487/RFC3463, January 2003, 469 . 471 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 472 Thayer, "OpenPGP Message Format", RFC 4880, 473 DOI 10.17487/RFC4880, November 2007, 474 . 476 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 477 Extension for Authentication", RFC 4954, 478 DOI 10.17487/RFC4954, July 2007, 479 . 481 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 482 Mail System Status Codes", BCP 138, RFC 5248, 483 DOI 10.17487/RFC5248, June 2008, 484 . 486 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 487 DOI 10.17487/RFC5321, October 2008, 488 . 490 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 491 DOI 10.17487/RFC5322, October 2008, 492 . 494 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 495 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 496 RFC 6152, DOI 10.17487/RFC6152, March 2011, 497 . 499 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 500 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 501 RFC 6376, DOI 10.17487/RFC6376, September 2011, 502 . 504 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 505 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 506 . 508 [RFC7085] Levine, J. and P. Hoffman, "Top-Level Domains That Are 509 Already Dotless", RFC 7085, DOI 10.17487/RFC7085, December 510 2013, . 512 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 513 Authorizing Use of Domains in Email, Version 1", RFC 7208, 514 DOI 10.17487/RFC7208, April 2014, 515 . 517 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 518 Message Authentication, Reporting, and Conformance 519 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 520 . 522 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 523 Opportunistic DNS-Based Authentication of Named Entities 524 (DANE) Transport Layer Security (TLS)", RFC 7672, 525 DOI 10.17487/RFC7672, October 2015, 526 . 528 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 529 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 530 . 532 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., 533 and J. Jones, "SMTP MTA Strict Transport Security (MTA- 534 STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, 535 . 537 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 538 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 539 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 540 April 2019, . 542 [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. 543 Kucherawy, Ed., "The Authenticated Received Chain (ARC) 544 Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, 545 . 547 Appendix A. Change Log 549 RFC Editor: Please remove this appendix before publication. 551 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft- 552 ietf-emailcore-as-00 554 * Change of filename, metadata, and date to reflect transition to WG 555 document for new emailcore WG. No other substantive changes 557 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 559 * Added co-authors (list is in alphabetical order for the present). 561 * Updated references to 5321bis and 5322bis. 563 * Added note at top, "This version is provided as a document 564 management convenience to update the author list and make an un- 565 expired version available to the WG. There are no substantive 566 changes from the prior version", which should be removed for 567 version -02. 569 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 571 * Added new editors and also added some issues the emailcore group 572 will be dealing with. 574 * Added reference to RFC 6648. 576 A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to -03 578 * Moved discussion of address-literals (issue #1) and domain names 579 in EHLO (issue #19) under SMTP Provisions section 581 * Moved discussion of empty quoted-strings under Message Format 582 Provisions section 584 * Added text on use of addresses in TLDs (issue #50) 586 * Marked all authors as editors. 588 * Miscellaneous editorial changes. 590 A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to -04 592 * Added requirements for SMTP extensions (issue #40). 594 A.6. Changes from draft-ietf-emailcore-as-04 (2022-05-21) to -05 596 * Added text addressing use ofx enhanced status codes. 598 * Added text addressing confidentiality and authentication (issue 599 #54). 601 Authors' Addresses 602 John C Klensin (editor) 603 1770 Massachusetts Ave, Ste 322 604 Cambridge, MA 02140 605 United States of America 606 Phone: +1 617 245 1457 607 Email: john-ietf@jck.com 609 Kenneth Murchison (editor) 610 Fastmail US LLC 611 1429 Walnut Street - Suite 1201 612 Philadelphia, PA 19102 613 United States of America 614 Email: murch@fastmailteam.com 616 E Sam (editor) 617 Email: winshell64@gmail.com