Email Authentication for Internationalized Mail
RFC 8616
| Document | Type | RFC - Proposed Standard (June 2019; No errata) | |
|---|---|---|---|
| Author | John Levine | ||
| Last updated | 2019-06-30 | ||
| Replaces | draft-levine-appsarea-eaiauth | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Kurt Andersen | ||
| Shepherd write-up | Show (last changed 2019-02-26) | ||
| IESG | IESG state | RFC 8616 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions | ||
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
Abstract
Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail
(DKIM) (RFC 6376), and Domain-based Message Authentication,
Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner
to publish email authentication and policy information in the DNS.
In internationalized email, domain names can occur both as U-labels
and A-labels. This specification updates the SPF, DKIM, and DMARC
specifications to clarify which form of internationalized domain
names to use in those specifications.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8616.
Copyright Notice
Copyright (c) 2019 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.
Levine Standards Track [Page 1]
RFC 8616 EAI Authentication June 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Principles . . . . . . . . . . . . . . . . . . . . . 3
4. SPF and Internationalized Mail . . . . . . . . . . . . . . . 3
5. DKIM and Internationalized Mail . . . . . . . . . . . . . . . 3
6. DMARC and Internationalized Mail . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
In conventional email, all domain names are ASCII in all contexts, so
there is no question about the representation of the domain names.
All internationalized domain names are represented as A-labels
[RFC5890] in message header fields, SMTP sessions, and the DNS.
Internationalized mail [RFC6530] (generally called "EAI" for Email
Address Internationalization) allows U-labels in SMTP sessions
[RFC6531] and message header fields [RFC6532].
Every U-label is equivalent to an A-label, so in principle, the
choice of label format will not cause ambiguities. But in practice,
consistent use of label formats will make it more likely that code
for mail senders and receivers interoperates.
Internationalized mail also allows UTF-8-encoded Unicode characters
in the local parts of mailbox names, which were historically only
ASCII.
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.
Levine Standards Track [Page 2]
RFC 8616 EAI Authentication June 2019
The term "IDN", for Internationalized Domain Name, refers to a domain
name containing either U-labels or A-labels.
Show full document text