draft-ietf-dmarc-eaiauth-00.txt   draft-ietf-dmarc-eaiauth-01.txt 
Network Working Group J. Levine Network Working Group J. Levine
Internet-Draft Taughannock Networks Internet-Draft Taughannock Networks
Updates: 6376, 7208, 7489 (if approved) December 19, 2018 Updates: 6376, 7208, 7489 (if approved) February 8, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: June 22, 2019 Expires: August 12, 2019
E-mail Authentication for Internationalized Mail E-mail Authentication for Internationalized Mail
draft-ietf-dmarc-eaiauth-00 draft-ietf-dmarc-eaiauth-01
Abstract Abstract
SPF, DKIM, and DMARC enable a domain owner to publish e-mail SPF, DKIM, and DMARC enable a domain owner to publish e-mail
authentication and policy information in the DNS. In authentication and policy information in the DNS. In
internationalized e-mail, domain names can occur both as U-labels and internationalized e-mail, domain names can occur both as U-labels and
A-labels. The Authentication-Results header reports the result of A-labels. The Authentication-Results header reports the result of
authentication checks made with SPF, DKIM, DMARC, and other schemes. authentication checks made with SPF, DKIM, DMARC, and other schemes.
This specification clarifies when to use which form of domain names This specification clarifies when to use which form of domain names
when using SPF, DKIM, and DMARC and when creating Authentication- when using SPF, DKIM, and DMARC and when creating Authentication-
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2019. This Internet-Draft will expire on August 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
Internationalized mail also allows UTF-8 characters in the local Internationalized mail also allows UTF-8 characters in the local
parts of mailbox names, which were historically only ASCII. parts of mailbox names, which were historically only 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", "MAY", and "OPTIONAL" when "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when
written in upper case in in this document are to be interpreted as written in upper case in in this document are to be interpreted as
described in [RFC2119] and [RFC8174]. described in [RFC2119] and [RFC8174].
The term IDN, for Internationalized Domain Name, refers to a doman 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 now be U-labels, and mailbox local parts can be UTF-8. ASCII can now be U-labels, and mailbox local parts can be UTF-8.
Header names and other text intended primarily to be interpreted by Header names and other text intended primarily to be interpreted by
skipping to change at page 3, line 38 skipping to change at page 3, line 38
U-labels, those labels are translated to A-labels before being looked U-labels, those labels are translated to A-labels before being looked
up in the DNS, as described in [RFC5891]. 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
argument MUST be represented as an A-label. An IDN in MAIL FROM can argument MUST be represented as an A-label. An IDN in MAIL FROM can
be either U-labels or an 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 original DNS lookup,
described in Section 3 of [RFC7208] and the macro expansion of described in Section 3 of [RFC7208] and the macro expansion of
domain-spec described in section 7. Section 4.3 of [RFC7208] states domain-spec described in section 7. Section 4.3 of [RFC7208] states
that all IDNs in an SPF DNS record MUST be A-labels; this rule is that all IDNs in an SPF DNS record MUST be A-labels; this rule is
unchanged since any SPF record can be used to authorize either EAI or unchanged since any SPF record can be used to authorize either EAI or
conventional mail. conventional mail.
SPF macros %s and %l expand the local-part of the sender's mailbox. SPF macros %s and %l expand the local-part of the sender's mailbox.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 MUST be encoded as A-labels. This rule is of a DKIM-Signature header MUST be encoded as A-labels. This rule is
relaxed only for headers in internationalized messages [RFC6532] so relaxed only for headers in internationalized messages [RFC6532] so
IDNs SHOULD be represented as U-labels but MAY be A-labels. This IDNs SHOULD be represented as U-labels but MAY be A-labels. This
provides improved consistency with other headers. The set of provides improved consistency with other headers. The set of
allowable characters in the local-part of an i= tag is extended as allowable characters in the local-part of an i= tag is extended as
described in [RFC6532]. When computing or verifying the hash in a described in [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, the hash MUST use the
domain name in the format it occurs in the header. domain name in the format it occurs in the header.
Section 3.4.2 of [RFC6376] describes relaxed header canonicalization.
Its first step converts all header field names from upper case to
lower case. Field names are restricted to printable ASCII (see
[RFC5322] section 3.6.8) so this case conversion remains the usual
ASCII conversion.
DKIM key records, described in section 3.6.1, do not contain domain DKIM key records, described in section 3.6.1, do not contain domain
names, so there is no change to their specification. 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. specify for the domain of the address in a RFC5322.From header.
Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
RFC5322.From address domain are to be handled. That section is RFC5322.From address domain are to be handled. That section is
skipping to change at page 5, line 22 skipping to change at page 5, line 24
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. far as the author knows, add any new ones.
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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<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
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>. <https://www.rfc-editor.org/info/rfc5891>.
skipping to change at page 6, line 16 skipping to change at page 6, line 25
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 Appendix A. Change history
00 to 01 Relaxed canon, Typos
00 First WG version 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
Phone: +1 831 480 2300 Phone: +1 831 480 2300
 End of changes. 10 change blocks. 
7 lines changed or deleted 19 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/