| Internet-Draft | Core Email A/S | May 2022 |
| Klensin, et al. | Expires 24 November 2022 | [Page] |
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.¶
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 24 November 2022.¶
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 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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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:¶
Similarly, the following extensions SHOULD be supported by SMTP senders and receivers:¶
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].¶
This section describes adjustments to the Internet Message Format that may be appropriate under various circumstances.¶
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:¶
"".bar@example.com¶
foo.""@example.net¶
""@example.com¶
Use of empty quoted strings is fine in "display-name".¶
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.¶
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.¶
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.¶
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!¶
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.¶
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.¶
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.¶
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.¶
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 of SMTP, they are out of scope for this document.¶
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.¶
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.¶
All drafts are required to have a security considerations section and this one eventually will.¶
... To be supplied ...¶
RFC Editor: Please remove this appendix before publication.¶