Internet-Draft Core Email A/S August 2021
Klensin, et al. Expires 7 February 2022 [Page]
Intended Status:
Standards Track
J.C. Klensin, Ed.
K. Murchison, Ed.
E. Sam, Ed.

Applicability Statement for IETF Core Email Protocols


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

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 7 February 2022.

Table of Contents

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 [I-D.ietf-emailcore-rfc5321bis]) and Internet Message Format [RFC5322] (being revised as [I-D.ietf-emailcore-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 [RFC2026],

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 specifications, 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 [RFC2119] and [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.

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 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.

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 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:




Use of empty quoted strings is fine in "display-name".

4. 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, [RFC2822] and [RFC5322] and the successors of that original MIME specification including [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.

It may be appropriate to make some clear statements about the applicability of MIME and its features.

5. 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.

6. 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.

7. 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.

8. Security Considerations

All drafts are required to have a security considerations section and this one eventually will.

... To be supplied ...

9. References

9.1. Normative References

Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, , <>.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

9.2. Informative References

Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-03, , <>.
Resnick, P. W., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-01, , <>.
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, , <>.
Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", , <>.
Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, DOI 10.17487/RFC2821, , <>.
Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, , <>.
Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, , <>.
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <>.
Levine, J. and P. Hoffman, "Top-Level Domains That Are Already Dotless", RFC 7085, DOI 10.17487/RFC7085, , <>.

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
  • 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.

Authors' Addresses

John C Klensin (editor)
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
United States of America
Kenneth Murchison (editor)
Fastmail US LLC
1429 Walnut Street - Suite 1201
Philadelphia, PA 19102
United States of America
E Sam (editor)