EMAILCORE J. Klensin, Ed. Internet-Draft Intended status: Standards Track K. Murchison Expires: January 12, 2022 Fastmail E. Sam July 11, 2021 Applicability Statement for IETF Core Email Protocols draft-ietf-emailcore-as-02 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. Note on draft-ietf-emailcore-as-01 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. 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 January 12, 2022. Klensin, et al. Expires January 12, 2022 [Page 1] Internet-Draft Core Email A/S July 2021 Copyright Notice Copyright (c) 2021 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 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 3. Applicability of Message Format Provisions . . . . . . . . . 3 4. Use of IP addresses/domain names in EHLO . . . . . . . . . . 4 5. Extension Keywords Starting in X- . . . . . . . . . . . . . . 4 6. IP address literals in EHLO . . . . . . . . . . . . . . . . . 4 7. Use of empty quote strings in email messages . . . . . . . . 5 8. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5 9. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. Security Considerations . . . . . . . . . . . . . . . . . . . 6 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 13.1. Normative References . . . . . . . . . . . . . . . . . . 6 13.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft-ietf-emailcore-as-00 . . . . . . . . . . . . 8 A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In its current form, this draft is a placeholder and beginning of an outline for the Applicability Statement that has been discussed as a complement for proposed revisions of the base protocol specifications for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis]) and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis Klensin, et al. Expires January 12, 2022 [Page 2] Internet-Draft Core Email A/S July 2021 [ID.RFC5322bis]). Among other things, it is expected to capture topics that a potential WG concludes are important but that should not become part of those core documents. As discussed in RFC 2026 [RFC2026], "An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability." That form of a standards track document is appropriate because one of the roles of such a document is to explain the relationship among technical specification, describe how they are used together, and make statements about what is "required, recommended, or elective". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and RFC 8174 [RFC8174]. 2. Applicability of Some SMTP Provisions Over the years since RFC 5321 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. 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. [[CREF1: ... Actual content to be supplied after WG consideration. ]] 3. Applicability of Message Format Provisions Placeholder: I am not sure what, if anything, goes here. If nothing does, we drop the section. Klensin, et al. Expires January 12, 2022 [Page 3] Internet-Draft Core Email A/S July 2021 [[CREF2: ... Actual content to be supplied after WG consideration.]] 4. Use of IP addresses/domain names in EHLO There has been a suggestion to update RFC 5321 [RFC5321] to clarify that servers may verify the domain name in the EHLO command to see if it matches up with the IP address of the client. The reasoning behind this was that many mail servers were already verifying the domain name provided with the EHLO command for anti spam purposes, and that mail servers that don't have a matching domain name/IP address are more likely to have their mail rejected. People for this change say that this is the "de facto" practice and that it should be formally specified since basically all mail servers are verifying the EHLO domain name anyway. People against this argue that the domain names supplied with the EHLO command won't always have a matching IP because they are internal domain names or a custom domain convention. The consensus was that this should be specified within RFC 5231 due to the fact it is already taking place to prevent spam. 5. Extension Keywords Starting in X- Since the release of the SMTP RFC, opinons on "X" extensions have changed over the years. These opinions can best be represented by RFC 6648 [RFC6648]. In short, people are beginning to "shy away" from the usage of "X" extensions. The proposed changes would involve the removal of the "X" extension provisions in Section 2.2.2 of the SMTP RFC, and also called for the removal of how to deal with "X" extensinos in the IANA considerations and private-use commands. While the exact solution is being talked about, the general consensus is that its a good idea for this part of the RFC to be removed or reformed. 6. IP address literals in EHLO One of the proposed ideas on the mailing list was to clarify if IP addresses are allowed to be used as a EHLO parameter. While the original specification allowed for the use of IP addresses instead of a domain name, it didn't say if the mail server was required to accept IP addresses Klensin, et al. Expires January 12, 2022 [Page 4] Internet-Draft Core Email A/S July 2021 The people that suggest that the specification should not require IP addresses to be accepted say that anti-spam systems already reject emails with IP addresses in EHLO commands, just like how they reject domain names that don't match up with a valid IP. However, some say there are some valid use cases for EHLO commands to have IP literals, for example in private networks. The general opinion is that the specification should have a section explaining why IP addresses are not recommended as an EHLO parameter, but should not ban IP literals outright. 7. Use of empty quote strings in email messages quoted-string ABNF non terminal is used in various places in 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". 8. MIME and Its Implications When the work leading to the original version of the MIME specification was completed in 1992 [RFC1341], the intention was that it be kept separate from the specification for basic mail headers in RFC 822 [RFC0822]. That plan was carried forward into RFC 822's successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322] and the successors of that original MIME specification including RFC 2045 [RFC2045]. The decision to do so was different from the one made for SMTP, for which the core specification was changed to allow for the extension mechanism [RFC1425] which was then incorporated into RFC 5321 and its predecessor [RFC2821]. Various uses of MIME have become nearly ubiquitous in contemporary email while others may have fallen into disuse or been repurposed from the intent of their original design. Klensin, et al. Expires January 12, 2022 [Page 5] Internet-Draft Core Email A/S July 2021 It may be appropriate to make some clear statements about the applicability of MIME and its features. 9. Other Stuff It is fairly clear that there will be things that do not fit into the sections outlined above. As one example, if the IETF wants to say something specific about signatures over headers or what (non-trace) headers may reasonably be altered in transit, that may be more appropriate to other sections than to any of the three suggested above. 10. 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 11. 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. 12. Security Considerations All drafts are required to have a security considerations section and this one eventually will. ... To be supplied ... 13. References 13.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, . Klensin, et al. Expires January 12, 2022 [Page 6] Internet-Draft Core Email A/S July 2021 [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, . 13.2. Informative References [ID.RFC5321bis] Klensin, J., "Simple Mail Transfer Protocol", Feburary 2021, . [ID.RFC5322bis] Resnick, P., "Internet Message Format", March 2021, . [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, August 1982, . [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, DOI 10.17487/RFC1341, June 1992, . [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", February 1993, . [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, DOI 10.17487/RFC2821, April 2001, . [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . Klensin, et al. Expires January 12, 2022 [Page 7] Internet-Draft Core Email A/S July 2021 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6648] Saint-Andre, P., Nottingham, N., Ed., and D. Crocker, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", June 2012, . 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 o 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 o Added co-authors (list is in alphabetical order for the present). o Updated references to 5321bis and 5322bis. o 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 o Added new editors and also added some issues the emailcore group will be dealing with. o Added reference to RFC 6648. Authors' Addresses John C Klensin (editor) 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin, et al. Expires January 12, 2022 [Page 8] Internet-Draft Core Email A/S July 2021 Kenneth Murchison Fastmail US LLC 1429 Walnut Street - Suite 1201 Philadelphia, PA 19102 USA Email: murch@fastmailteam.com E Sam Email: winshell64@gmail.com Klensin, et al. Expires January 12, 2022 [Page 9]