draft-ietf-dmarc-eaiauth-06.txt   rfc8616.txt 
Network Working Group J. Levine Internet Engineering Task Force (IETF) J. Levine
Internet-Draft Taughannock Networks Request for Comments: 8616 Taughannock Networks
Updates: 6376, 7208, 7489 (if approved) April 11, 2019 Updates: 6376, 7208, 7489 June 2019
Intended status: Standards Track Category: Standards Track
Expires: October 13, 2019 ISSN: 2070-1721
E-mail Authentication for Internationalized Mail Email Authentication for Internationalized Mail
draft-ietf-dmarc-eaiauth-06
Abstract Abstract
SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail
owner to publish e-mail authentication and policy information in the (DKIM) (RFC 6376), and Domain-based Message Authentication,
DNS. In internationalized e-mail, domain names can occur both as Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner
U-labels and A-labels. This specification updates the SPF, DKIM, and to publish email authentication and policy information in the DNS.
DMARC specifications to clarify which form of internationalized In internationalized email, domain names can occur both as U-labels
domain names to use in those specifications. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 13, 2019. 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General principles . . . . . . . . . . . . . . . . . . . . . 3 3. General Principles . . . . . . . . . . . . . . . . . . . . . 3
4. SPF and internationalized mail . . . . . . . . . . . . . . . 3 4. SPF and Internationalized Mail . . . . . . . . . . . . . . . 3
5. DKIM and internationalized mail . . . . . . . . . . . . . . . 4 5. DKIM and Internationalized Mail . . . . . . . . . . . . . . . 3
6. DMARC and internationalized mail . . . . . . . . . . . . . . 5 6. DMARC and Internationalized Mail . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain
owner to publish e-mail authentication and policy information in the owner to publish email authentication and policy information in the
DNS. SPF primarily publishes information about what host addresses DNS. SPF primarily publishes information about what host addresses
are authorized to send mail for a domain. DKIM places cryptographic are authorized to send mail for a domain. DKIM places cryptographic
signatures on e-mail messages, with the validation keys published in signatures on email messages, with the validation keys published in
the DNS. DMARC publishes policy information related to the domain in the DNS. DMARC publishes policy information related to the domain in
the From: header field of e-mail messages. the From: header field of email messages.
In conventional e-mail, all domain names are ASCII in all contexts so In conventional email, all domain names are ASCII in all contexts, so
there is no question about the representation of the domain names. there is no question about the representation of the domain names.
All internationalized domain names are represented as A-labels All internationalized domain names are represented as A-labels
[RFC5890] in message header fields, in SMTP sessions, and in the DNS. [RFC5890] in message header fields, SMTP sessions, and the DNS.
Internationalized mail [RFC6530], (generally called EAI for E-mail Internationalized mail [RFC6530] (generally called "EAI" for Email
Address Internationalization), allows U-labels in SMTP sessions Address Internationalization) allows U-labels in SMTP sessions
[RFC6531] and in message header fields [RFC6532]. [RFC6531] and message header fields [RFC6532].
Every U-label is equivalent to an A-label, so in principle the choice Every U-label is equivalent to an A-label, so in principle, the
of label format will not cause ambiguities. But in practice, choice of label format will not cause ambiguities. But in practice,
consistent use of label formats will make it more likely that mail consistent use of label formats will make it more likely that code
senders' and receivers' code interoperates. for mail senders and receivers interoperates.
Internationalized mail also allows UTF-8 encoded Unicode characters Internationalized mail also allows UTF-8-encoded Unicode characters
in the local parts of mailbox names, which were historically only in the local parts of mailbox names, which were historically only
ASCII. ASCII.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The term IDN, for Internationalized Domain Name, refers to a domain The term "IDN", for Internationalized Domain Name, refers to a domain
name containing either U-labels or A-labels. name containing either U-labels or A-labels.
Since DMARC is not currently a standards track protocol, this Since DMARC is not currently a Standards Track protocol, this
specification offers advice rather than requirements for DMARC. specification offers advice rather than requirements for DMARC.
3. General principles 3. General Principles
In headers in EAI mail messages, domain names that were restricted to 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 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 field names and other text intended primarily to be interpreted by
computers rather than read by people remains ASCII. computers rather than read by people remains ASCII.
Strings stored in DNS records remain ASCII since there is no way to Strings stored in DNS records remain ASCII since there is no way to
tell whether a client retrieving a DNS record expects an EAI or an tell whether a client retrieving a DNS record expects an EAI or an
ASCII result. When a domain name found in a mail header field ASCII result. When a domain name found in a mail header field
includes U-labels, those labels are translated to A-labels before includes U-labels, those labels are translated to A-labels before
being looked up in the DNS, as described in [RFC5891]. being looked up in the DNS, as described in [RFC5891].
4. SPF and internationalized mail 4. SPF and Internationalized Mail
SPF [RFC7208] uses two identities from the SMTP session, the host 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 name in the EHLO command and the domain in the address in the MAIL
FROM command. Since the EHLO command precedes the server response FROM command. Since the EHLO command precedes the server response
that tells whether the server supports the SMTPUTF8 extension, an IDN 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 host name MUST be represented as A-labels. An IDN in MAIL FROM can
be either U-labels or A-labels. be either U-labels or A-labels.
All U-labels MUST be converted to A-labels before being used for an All U-labels MUST be converted to A-labels before being used for an
SPF validation. This includes both the original DNS lookup, SPF validation. This includes both the labels in the name used for
described in Section 3 of [RFC7208] and the macro expansion of the original DNS lookup, described in Section 3 of [RFC7208], and
domain-spec described in section 7. Section 4.3 of [RFC7208] states those used in the macro expansion of domain-spec, described in
that all IDNs in an SPF DNS record MUST be A-labels; this rule is Section 7. Section 4.3 of [RFC7208] states that all IDNs in an SPF
unchanged since any SPF record can be used to authorize either EAI or DNS record MUST be A-labels; this rule is unchanged since any SPF
conventional mail. record can be used to authorize either EAI or conventional mail.
SPF macros %{s} and %{l} expand the local-part of the sender's SPF macros %{s} and %{l} expand the local part of the sender's
mailbox. If the local-part contains non-ASCII characters, terms that mailbox. If the local part contains non-ASCII characters, terms that
include %{s} or %{l} do not match anything, because non-ASCII local include %{s} or %{l} do not match anything, because non-ASCII local
parts cannot be used as the DNS labels the macros are intended to parts cannot be used as the DNS labels the macros are intended to
match. Since these macros are rarely used, this is unlikely to be an match. Since these macros are rarely used, this is unlikely to be an
issue in practice. issue in practice.
5. DKIM and internationalized mail 5. DKIM and Internationalized Mail
DKIM [RFC6376] specifies a mail header field that contains a DKIM [RFC6376] specifies a mail header field that contains a
cryptographic message signature and a DNS record that contains the cryptographic message signature and a DNS record that contains the
validation key. validation key.
Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its
definition is modified in messages with internationalized header definition is modified in messages with internationalized header
fields so that non-ASCII UTF-8 characters need not be quoted. The fields so that non-ASCII UTF-8 characters need not be quoted. The
ABNF for dkim-safe-char in those messages is replaced by the ABNF [RFC5234] for dkim-safe-char in those messages is replaced by
following, adding non-ASCII UTF-8 characters from [RFC3629]: the following, adding non-ASCII UTF-8 characters from [RFC3629]:
dkim-safe-char = %x21-3A / %x3C / %x3E-7E / dkim-safe-char = %x21-3A / %x3C / %x3E-7E /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
; '!' - ':', '<', '>' - '~', non-ASCII ; '!' - ':', '<', '>' - '~', non-ASCII
UTF8-2 = <Defined in Section 4 of RFC 3629> UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629> UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629> UTF8-4 = <Defined in Section 4 of RFC 3629>
Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags
of a DKIM-Signature header field MUST be encoded as A-labels. This of a DKIM-Signature header field MUST be encoded as A-labels. This
rule is relaxed only for internationalized messages header fields rule is relaxed only for internationalized message header fields
[RFC6532] so IDNs SHOULD be represented as U-labels. This provides [RFC6532], so IDNs SHOULD be represented as U-labels. This provides
improved consistency with other header fields. (A-labels remain improved consistency with other header fields. (A-labels remain
valid to allow a transition from older software.) The set of valid to allow a transition from older software.) The set of
allowable characters in the local-part of an i= tag is extended in allowable characters in the local part of an i= tag is extended in
the same fashion as local parts of e-mail addresses as described in the same fashion as local parts of email addresses as described in
section 3.2 of [RFC6532]. When computing or verifying the hash in a Section 3.2 of [RFC6532]. When computing or verifying the hash in a
DKIM signature as described in section 3.7, the hash MUST use the DKIM signature as described in Section 3.7 of [RFC6376], the hash
domain name in the format it occurs in the header field. MUST use the domain name in the format it occurs in the header field.
Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. Section 3.4.2 of [RFC6376] describes relaxed header canonicalization.
Its first step converts all header field names from upper case to Its first step converts all header field names from uppercase to
lower case. Field names are restricted to printable ASCII (see lowercase. Field names are restricted to printable ASCII (see
[RFC5322] section 3.6.8) so this case conversion remains ASCII case [RFC5322], Section 3.6.8), so this case conversion remains ASCII case
conversion. conversion.
DKIM key records, described in section 3.6.1, do not contain domain DKIM key records, described in Section 3.6.1 of [RFC6376], do not
names, so there is no change to their specification. contain domain names, so there is no change to their specification.
6. DMARC and internationalized mail 6. DMARC and Internationalized Mail
DMARC [RFC7489] defines a policy language that domain owners can DMARC [RFC7489] defines a policy language that domain owners can
specify for the domain of the address in a RFC5322.From header field. specify for the domain of the address in an RFC5322.From header
field.
Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the Section 6.6.1 of [RFC7489] specifies, somewhat imprecisely, how IDNs
RFC5322.From address domain are to be handled. That section is in the RFC5322.From address domain are to be handled. That section
updated to say that all U-labels in the domain are converted to is updated to say that all U-labels in the domain are converted to
A-labels before further processing. Section 7.1 is similarly updated A-labels before further processing. Section 7.1 of [RFC7489] is
to say that all U-labels in domains being handled are converted to similarly updated to say that all U-labels in domains being handled
A-labels before further processing. are converted to A-labels before further processing.
DMARC policy records, described in sections 6.3 and 7.1, can contain DMARC policy records, described in Sections 6.3 and 7.1 of [RFC7489],
e-mail addresses in the rua and ruf tags. Since a policy record can can contain email addresses in the "rua" and "ruf" tags. Since a
be used for both internationalized and conventional mail, those policy record can be used for both internationalized and conventional
addresses still have to be conventional addresses, not mail, those addresses still have to be conventional addresses, not
internationalized addresses. internationalized addresses.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document has no IANA actions.
8. Security Considerations 8. Security Considerations
E-mail is subject to a vast range of threats and abuses. This Email is subject to a vast range of threats and abuses. This
document attempts to slightly mitigate some of them but does not, as 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, far as the author knows, add any new ones. The updates to SPF, DKIM,
and DMARC are intended to allow the respective specifications work as and DMARC are intended to allow the respective specifications to work
reliably on internationalized mail as they do on ASCII mail, so that as reliably on internationalized mail as they do on ASCII mail, so
applications that use them, such as some kinds of spam and phish that applications that use them, such as some kinds of mail filters
filtering, can work more reliably on internationalized mail. that catch spam and phish, can work more reliably on
internationalized mail.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
skipping to change at page 6, line 46 skipping to change at page 6, line 41
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Change history
05 to 06 more editorial nits
04 to 05 editorial nits
03 to 04 remove dangling A-R reference, add more i18nish and
security goodness
02 to 03 minor edits per Alexey
01 to 02 update references
00 to 01 Relaxed canon, Typos
00 First WG version
Author's Address Author's Address
John Levine John Levine
Taughannock Networks Taughannock Networks
PO Box 727 PO Box 727
Trumansburg, NY 14886 Trumansburg, NY 14886
United States of America
Email: standards@taugh.com Email: standards@taugh.com
URI: http://jl.ly URI: http://jl.ly
 End of changes. 40 change blocks. 
110 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/