Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 8616 Taughannock Networks
Updates: 6376, 7208, 7489 June 2019
Category: Standards Track
ISSN: 2070-1721
Email Authentication for Internationalized Mail
Levine Standards Track [Page 1]
RFC 8616 EAI Authentication June 2019
Table of Contents
1. Introduction
SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain owner to publish email authentication and policy information in the DNS. SPF primarily publishes information about what host addresses are authorized to send mail for a domain. DKIM places cryptographic signatures on email messages, with the validation keys published in the DNS. DMARC publishes policy information related to the domain in the From: header field of email messages.
2. Definitions
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. The term "IDN", for Internationalized Domain Name, refers to a domain name containing either U-labels or A-labels.
Levine Standards Track [Page 2]
RFC 8616 EAI Authentication June 2019
Since DMARC is not currently a Standards Track protocol, this specification offers advice rather than requirements for DMARC.
3. General Principles
In headers in EAI mail messages, domain names that were restricted to ASCII can be U-labels, and mailbox local parts can be UTF-8. Header field names and other text intended primarily to be interpreted by computers rather than read by people remains ASCII.
4. SPF and Internationalized Mail
SPF [RFC7208] uses two identities from the SMTP session: the host name in the EHLO command and the domain in the address in the MAIL FROM command. Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension, an IDN host name MUST be represented as A-labels. An IDN in MAIL FROM can be either U-labels or A-labels.
5. DKIM and Internationalized Mail
DKIM [RFC6376] specifies a mail header field that contains a cryptographic message signature and a DNS record that contains the validation key. Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its definition is modified in messages with internationalized header fields so that non-ASCII UTF-8 characters need not be quoted. The ABNF [RFC5234] for dkim-safe-char in those messages is replaced by the following, adding non-ASCII UTF-8 characters from [RFC3629]:
Levine Standards Track [Page 3]
RFC 8616 EAI Authentication June 2019
dkim-safe-char = %x21-3A / %x3C / %x3E-7E /
6. DMARC and Internationalized Mail
DMARC [RFC7489] defines a policy language that domain owners can specify for the domain of the address in an RFC5322.From header field.
Levine Standards Track [Page 4]
RFC 8616 EAI Authentication June 2019
DMARC policy records, described in Sections 6.3 and 7.1 of [RFC7489], can contain email addresses in the "rua" and "ruf" tags. Since a policy record can be used for both internationalized and conventional mail, those addresses still have to be conventional addresses, not internationalized addresses.
7. IANA Considerations
This document has no IANA actions.
8. Security Considerations
Email is subject to a vast range of threats and abuses. This document attempts to slightly mitigate some of them but does not, as far as the author knows, add any new ones. The updates to SPF, DKIM, and DMARC are intended to allow the respective specifications to work as reliably on internationalized mail as they do on ASCII mail, so that applications that use them, such as some kinds of mail filters that catch spam and phish, can work more reliably on internationalized mail.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levine Standards Track [Page 5]
RFC 8616 EAI Authentication June 2019
[RFC5891] Klensin, J., "Internationalized Domain Names in