EMAILCORE J.C. Klensin, Ed. Internet-Draft Intended status: Standards Track K. Murchison, Ed. Expires: 11 May 2023 Fastmail E. Sam, Ed. 7 November 2022 Applicability Statement for IETF Core Email Protocols draft-ietf-emailcore-as-07 Abstract Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. 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 11 May 2023. Copyright Notice Copyright (c) 2022 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 Klensin, et al. Expires 11 May 2023 [Page 1] Internet-Draft Core Email A/S November 2022 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 2.1. Handling of the Domain Argument to the EHLO Command . . . 4 2.2. Use of Address Literals . . . . . . . . . . . . . . . . . 4 2.3. Use of Addresses in Top-Level Domains . . . . . . . . . . 4 2.4. Use of the FOR clause in Received header fields . . . . . 5 2.5. Use of SMTP Extensions . . . . . . . . . . . . . . . . . 5 3. Applicability of Message Format Provisions . . . . . . . . . 6 3.1. Use of Empty Quoted Strings . . . . . . . . . . . . . . . 6 3.2. Use of Time Zones in Date and Received Header Fields . . 6 3.3. Line Length Limits . . . . . . . . . . . . . . . . . . . 6 4. Use of Email Addresses . . . . . . . . . . . . . . . . . . . 6 4.1. Case-Sensitivity, Delimiters, and Mailbox Equivalency . . 6 4.2. Use and Validation in HTML and Other Contexts . . . . . . 7 5. Use of Multipurpose Internet Mail Extensions (MIME) . . . . . 8 6. Confidentiality and Authentication with SMTP . . . . . . . . 8 6.1. Optional Confidentiality . . . . . . . . . . . . . . . . 9 6.2. Required Confidentiality, with Receiving Server Authentication . . . . . . . . . . . . . . . . . . . . . 9 6.3. Message-Level Authentication . . . . . . . . . . . . . . 10 6.4. SMTP Authentication . . . . . . . . . . . . . . . . . . . 10 6.5. Message-Level Confidentiality . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft-ietf-emailcore-as-00 . . . . . . . . . . . . . . . 14 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Klensin, et al. Expires 11 May 2023 [Page 2] Internet-Draft Core Email A/S November 2022 A.6. Changes from draft-ietf-emailcore-as-04 (2022-05-21) to -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.7. Changes from draft-ietf-emailcore-as-05 (2022-10-24) to -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.8. Changes from draft-ietf-emailcore-as-06 (2021-11-07) to -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document is an Applicability Statement [RFC2026], Section 3.2 that provides guidance in the use of the Internet's core email specifications, the Simple Mail Transfer Protocol (SMTP) [I-D.ietf-emailcore-rfc5321bis] and the Internet Message Format (IMF) [I-D.ietf-emailcore-rfc5322bis], and some extensions that have been built on them. In order to promote interoperability amongst senders, receivers, and intermediaries, it includes discussions and recommendations about selected features of SMTP, IMF, and certain extensions to them that are required, recommended, or to be avoided except in special cases. Furthermore, this document discusses some common mechanisms for confidentiality and authentication in electronic mail. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Applicability of Some SMTP Provisions Over the years since [RFC5321] was published in October 2008, usage of SMTP has evolved, machines and network speeds have increased, and the frequency with which SMTP senders and receivers have to be prepared to deal with systems that are disconnected from the Internet for long periods or that require many hops to reach has decreased. During the same period, the IETF has become much more sensitive to privacy and security issues and the need to be more resistant or robust against spam and other attacks. In addition SMTP (and Message Format) extensions have been introduced that are expected to evolve the Internet's mail system to better accommodate environments in which Basic Latin Script is not the norm. Klensin, et al. Expires 11 May 2023 [Page 3] Internet-Draft Core Email A/S November 2022 This section describes adjustments that may be appropriate for SMTP under various circumstances and discusses the applicability of other protocols that represent newer work or that are intended to deal with relatively newer issues. 2.1. Handling of the Domain Argument to the EHLO Command If the Domain argument to the EHLO command does not have an address record in the DNS that matches the IP address of the client, the SMTP server may refuse any mail from the client as part of established anti-abuse practice. Operational experience has demonstrated that the lack of a matching address record for the the domain name argument is at best an indication of a poorly-configured MTA, and at worst that of an abusive host. 2.2. Use of Address Literals The address-literal ABNF non-terminal is used in various places in [I-D.ietf-emailcore-rfc5321bis] grammar however, for SMTP connections over the public internet, an address-literal as the argument to EHLO command or the Domain part of the Mailbox argument to the MAIL FROM command is quite likely to result in the message being rejected as a matter of policy at many sites, since they are deemed to be signs of at best a misconfigured server, and at worst either a compromised host or a server that's intentionally configured to hide its identity. 2.3. Use of Addresses in Top-Level Domains While addresses in top-level domains (TLDs) are syntactically valid, mail to these addresses has never worked reliably. A handful of country code TLDs have top level MX records but they have never been widely used nor well supported. In 2013 [RFC7085] found 18 TLDs with MX records, which dropped to 17 in 2021 despite many new TLDs having been added. Mail sent to addresses with single label domains has typically expected the address to be an abbreviation to be completed by a search list, so mail to bob@sales would be completed to bob@sales.example.com. This shortcut has led to unfortunate consequnces; in one famous case, in 1991 when the .CS domain was added to the root, mail in computer science departments started to fail as mail to bob@cs was now treated as mail to Czechoslovakia. Hence, for reliable service, mail SHOULD NOT use addreses that contain single label domains. Klensin, et al. Expires 11 May 2023 [Page 4] Internet-Draft Core Email A/S November 2022 2.4. Use of the FOR clause in Received header fields Email addresses are commonly classified as Personally Identifiable Information (PII). Improper application of the FOR clause in Received header fields can result in disclosure of PII. As such, the FOR clause MUST NOT be generated if the message copy is associated with multiple recipients from mutliple SMTP RCPT commands. Otherwise, the value of the FOR clause MUST contain the RCPT address that caused the message to be routed to the recipient of the given copy of the message. Note however, that if a mail system generates a FOR clause when there is only a single recipient, and doesn't generate one when there are multiple recipients, the absence of the field is an indication that there is another recipient, which may allow someone to infer that a "blind" copy is involved. 2.5. Use of SMTP Extensions As SMTP has evolved over the years, several extensions have become ubiquitous. As a result, the following extensions MUST be supported by SMTP senders and receivers: * 8-bit MIME [RFC6152] * Deliver Status Notifications [RFC3461] Similarly, the following extensions SHOULD be supported by SMTP senders and receivers: * Command Pipelining [RFC2920] * Internationalized Email [RFC6531] Furthermore, while Enhanced Mail System Status Codes ([RFC3463], [RFC5248]) are widely supported, they are not ubiquitous. Nevertheless, they have been found to be useful to SMTP senders in determining the exact reason for a transmission failure in a machine- readable, language-independent manner, thus allowing them to present more detailed and language-specific error messages to users. Given the usefulness of these enhanced codes, SMTP receivers are RECOMMENDED to implement the SMTP Service Extension for Returning Enhanced Error Codes [RFC2034] utilizing the codes registered in [RFC5248]. Klensin, et al. Expires 11 May 2023 [Page 5] Internet-Draft Core Email A/S November 2022 3. Applicability of Message Format Provisions This section describes adjustments to the Internet Message Format that may be appropriate under various circumstances. 3.1. Use of Empty Quoted Strings The quoted-string ABNF non-terminal is used in various places in [I-D.ietf-emailcore-rfc5322bis] grammar. While it allows for empty quoted string, such construct is going to cause interoperability issues when used in certain header fields. In particular, use of empty quoted strings is NOT RECOMMENDED in "received-token" (a component of a Received header field), "keywords" (a component of a Keywords header field) and "local-part" (left hand side of email addresses). Use of empty quoted strings is in particular problematic in the "local-part". For example, all of the following email addresses are non interoperable: "".bar@example.com foo.""@example.net ""@example.com Use of empty quoted strings is fine in "display-name". 3.2. Use of Time Zones in Date and Received Header Fields Recommendations on the use of "-0000" as a time zone offset, etc (Issue #55)... 3.3. Line Length Limits Clarify 78 octet limit versus 998 line length limit (Issue #38)... 4. Use of Email Addresses 4.1. Case-Sensitivity, Delimiters, and Mailbox Equivalency SMTP specifies that the local-part of an email address is case- sensitive (see Section 2.4 of [I-D.ietf-emailcore-rfc5321bis]): Klensin, et al. Expires 11 May 2023 [Page 6] Internet-Draft Core Email A/S November 2022 The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. While case-sensitivity is specified as an absolute requirement, it is important to stress that most implementations do not make case distinctions in local parts (most treat "smith", "Smith", and "SMITH" as the same), and most implementations do preserve the case that is received (from SMTP or HTTP, from address books, or from user input). Maximum interoperability will be achieved by keeping local-parts unchanged (and especially making no attempt to change their case in any way) and by assuming that local-parts that differ only in their case probably refer to the same mailbox. This is particularly important for software that validates user-input fields, where case changes are tempting, but must be avoided. It is also important to note, as we encounter non-ASCII local-parts over time, that case changes are both character-set dependent and language dependent, and attempts to change case without having the full context necessary are likely to be wrong often enough to matter. Additionally, final delivery systems vary in how they interpret the use of delimiters such as '+' and '.' in local-parts. Some systems make distinctions between local-parts such as "smith" and "smith+foo", or "jane.doe" and "janedoe", while others treat them as referring to the same mailboxes respectively. Since only the final delivery system can properly interpret the local-part of an address, originating and transit/relay mail systems are discouraged from making any assumptions as to address equivalency or from making any changes to local-parts containing such delimiters. 4.2. Use and Validation in HTML and Other Contexts Email addresses are frequently used as input in HyperText Markup Language (HTML) forms but the allowed grammar of these email addresses is more restrictive than the grammar for a 'Mailbox' in Section 4.1.2 of [I-D.ietf-emailcore-rfc5321bis] (the lack of quoted strings and limited characters allowed in domains). Implementations that intend to accept email addresses in HTML forms are encouraged to consult the valid email address grammar in Section 4.10.5.1.5 of [HTML]. Additionally, the following general guidance is provided: Klensin, et al. Expires 11 May 2023 [Page 7] Internet-Draft Core Email A/S November 2022 * Few mail systems allow leading, trailing, or consecutive unquoted dots ('.') in the local-part of email addresses even though the HTML grammar referenced above currently allows them. Consequently, implementations are discouraged from accepting such addresses. * Some mail systems allow a trailing dot ('.') in the domain part of email addresses (as allowed by Domain Names [RFC1035]), but this is not interoperable with all systems. Consequently, implementations are encouraged to strip trailing dots from the domain part of email addresses. 5. Use of Multipurpose Internet Mail Extensions (MIME) Although the Multipurpose Internet Mail Extensions (MIME) [RFC2045] specification and its predecessors have remained separate from the Internet Message Format (IMF) [I-D.ietf-emailcore-rfc5322bis] specification and its predecessors, MIME features such as non-textual message bodies, multi-part message bodies, and the use of character sets other than US-ASCII in message bodies and header fields have become nearly ubiquitous in contemporary email. As a result, IMF generators and parsers are expected to support MIME. 6. Confidentiality and Authentication with SMTP SMTP is specified without embedded mechanisms for authentication or confidentiality; its traffic is therefore "in the clear". Years of operational experience have shown that such transmission exposes the message to easy compromise, including wiretapping and spoofing. To mitigate these risks, operation of SMTP has evolved over the years so that it is used with the benefit of Transport Layer Security (TLS) [RFC8446] to provide both confidentiality and authentication in the transmission of messages. This section discusses those topics and their most common uses. It is important that the reader understand what is meant by the terms "Authentication" and "Confidentiality", and for that we will borrow directly from RFC8446. * Authentication is the process of establishing the identity of one or more of the endpoints of a communication channel. TLS only requires authentication of the server side of the communication channel; authentication of the client side is optional. * The term "confidentiality" describes a state where the data (i.e., the message) is transmitted in a way that it is only visible to the endpoints of a communication channel. Klensin, et al. Expires 11 May 2023 [Page 8] Internet-Draft Core Email A/S November 2022 It is not uncommon for implementers to use the term "encryption" to mean "confidentiality", but this is not quite correct. Rather, encryption using TLS is the current method by which confidentiality is achieved with SMTP, but that does not mean that future methods might not be developed. Note: With typical email use of TLS, authentication only is performed for the target receiving server and is not done for the sending client. That is, it serves to validate that the connection has been made to the intended server, but does not validate who initiated it. 6.1. Optional Confidentiality The most common implementation of message confidentiality is what's known as "opportunistic TLS", which is frequently referred to as "opportunistic encryption". With this method, a receiving server announces in its greeting that it is capable of supporting TLS encryption through the presence of the "STARTTLS" keyword. The sending client then attempts to negotiate an encrypted connection, and if successful, transmits the message in encrypted form; if negotiation fails, the client falls back to sending the message in clear text. Opportunistic TLS is confidentiality without authentication, because no effort is made to authenticate the receiving server, and it is optional confidentiality due to the ability to fall back to transmission in the clear if a secure connection cannot be established. That said, most modern implementations of SMTP support this method, especially at the largest mailbox providers, and so the vast majority of email traffic is encrypted during its time transiting from the client to the server. Note: While TLS provides protection while the message is in transit, there is no guarantee that the message will be stored in encrypted fashion at its destination. In fact, storage in plain text should be expected! 6.2. Required Confidentiality, with Receiving Server Authentication Two protocols exist that move message confidentiality from optional to required (with conditions as noted below) - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their implementation details, receiving servers relying on either protocol are stating that they only accept mail if the transmission can be encrypted with TLS, and a failure to negotiate a secure connection MUST result in the sending client refusing to transmit the message. Support for both protocols is increasing, but is not yet mandatory. Klensin, et al. Expires 11 May 2023 [Page 9] Internet-Draft Core Email A/S November 2022 These two protocols differ from Opportunistic TLS in that they require receiving server authentication and there is no fallback to sending in the clear if negotiation of an encrypted connection fails. Note: Both protocols mentioned in this section rely not only on the receiving server but also the sending client supporting the protocol intended to be used. If the sending client does not implement or understand the protocol requested by the receiving server, the sending client will use Opportunistic TLS or clear-text to transmit the message. 6.3. Message-Level Authentication Protocols exist to allow for authentication of different identities associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow for validation of the domain in the visible From header, and a fourth, ARC [RFC8617], provides a way for each hop to record results of authentication checks performed at that hop. All of these are outside the scope of this document, as they are outside the scope of SMTP. They deal with validating the authorized usage of one or more domains in an email message, and not with establishing the identity of the receiving server. 6.4. SMTP Authentication SMTP Authentication [RFC4954], which is often abbreviated as SMTP AUTH, is an extension to SMTP. While its name might suggest that it would be within scope for this section of the Applicability Statement, nothing could be further from the truth. SMTP AUTH defines a method for a client to identify itself to a Message Submission Agent (MSA) when presenting a message for transmission, usually using port 587 rather than the traditional port 25. The most common implementation of SMTP AUTH is for a person to present a username and password to their mailbox provider's outbound SMTP server when configuring their MUA for sending mail. 6.5. Message-Level Confidentiality Protocols such as S/MIME [RFC8551] and OpenPGP [RFC4880] exist to allow for message confidentiality outside of the operation of SMTP. That is to say, using these protocols results in encryption of the message prior to its being submitted to the SMTP communications channel, and decryption of the message is the responsibility of the message recipient. There are numerous implementations of these protocols, too many to list here. As they operate fully independent Klensin, et al. Expires 11 May 2023 [Page 10] Internet-Draft Core Email A/S November 2022 of SMTP, they are out of scope for this document. 7. Acknowledgments The Emailcore group arose out of discussions on the ietf-smtp group over changes and additions that should be made to the core email protocols. It was agreed upon that it was time to create a working group that would fix many potential errors and opportunities for misunderstandings within the RFCs. Special thanks to the following for providing significant portions of text for this document: Todd Herr, Barry Leiba, John Levine, Alexey Melnikov. 8. IANA Considerations This memo includes no requests to or actions for IANA. The IANA registries associated with the protocol specifications it references are specified in their respective documents. 9. Security Considerations Security and privacy considerations are discussed throughout this document as they pertain to the referenced specifications. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References Klensin, et al. Expires 11 May 2023 [Page 11] Internet-Draft Core Email A/S November 2022 [HTML] Web Hypertext Application Technology Working Group, "HTML Living Standard", 4 October 2022, . [I-D.ietf-emailcore-rfc5321bis] Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis- 15, 6 November 2022, . [I-D.ietf-emailcore-rfc5322bis] Resnick, P., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-04, 4 October 2022, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, . [RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, . Klensin, et al. Expires 11 May 2023 [Page 12] Internet-Draft Core Email A/S November 2022 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, DOI 10.17487/RFC5248, June 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, . [RFC7085] Levine, J. and P. Hoffman, "Top-Level Domains That Are Already Dotless", RFC 7085, DOI 10.17487/RFC7085, December 2013, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Klensin, et al. Expires 11 May 2023 [Page 13] Internet-Draft Core Email A/S November 2022 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA- STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, . Appendix A. Change Log RFC Editor: Please remove this appendix before publication. A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft- ietf-emailcore-as-00 * Change of filename, metadata, and date to reflect transition to WG document for new emailcore WG. No other substantive changes A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 * Added co-authors (list is in alphabetical order for the present). * Updated references to 5321bis and 5322bis. * Added note at top, "This version is provided as a document management convenience to update the author list and make an un- expired version available to the WG. There are no substantive changes from the prior version", which should be removed for version -02. A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 * Added new editors and also added some issues the emailcore group will be dealing with. * Added reference to RFC 6648. A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to -03 * Moved discussion of address-literals (issue #1) and domain names in EHLO (issue #19) under SMTP Provisions section Klensin, et al. Expires 11 May 2023 [Page 14] Internet-Draft Core Email A/S November 2022 * Moved discussion of empty quoted-strings under Message Format Provisions section * Added text on use of addresses in TLDs (issue #50) * Marked all authors as editors. * Miscellaneous editorial changes. A.5. Changes from draft-ietf-emailcore-as-03 (2022-01-31) to -04 * Added requirements for SMTP extensions (issue #40). A.6. Changes from draft-ietf-emailcore-as-04 (2022-05-21) to -05 * Added text addressing use ofx enhanced status codes. * Added text addressing confidentiality and authentication (issue #54). A.7. Changes from draft-ietf-emailcore-as-05 (2022-10-24) to -06 * Converted source to xml2rfc v3. * Replaced placeholder Introduction with new text. * Updated keywords boilerplate. * Added text on interoperability of email addresses in general and use in HTML forms (issue #51). * Added text stating that implementations are expected to support MIME (issue #65). * Added placeholders for issues #38 and #55. * Add list of contributors in Acknowledgments. * Added minimal Security Considerations section. A.8. Changes from draft-ietf-emailcore-as-06 (2021-11-07) to -07 * Added text addressing use of FOR clause in Received hdeader fields (issue #55). * Miscellaneous editorial changes. Klensin, et al. Expires 11 May 2023 [Page 15] Internet-Draft Core Email A/S November 2022 Authors' Addresses John C Klensin (editor) 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America Phone: +1 617 245 1457 Email: john-ietf@jck.com Kenneth Murchison (editor) Fastmail US LLC 1429 Walnut Street - Suite 1201 Philadelphia, PA 19102 United States of America Email: murch@fastmailteam.com E Sam (editor) Email: winshell64@gmail.com Klensin, et al. Expires 11 May 2023 [Page 16]