idnits 2.17.1 draft-ietf-dmarc-eaiauth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7489, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7208, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 19, 2018) is 1926 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7489 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Updates: 6376, 7208, 7489 (if approved) December 19, 2018 5 Intended status: Standards Track 6 Expires: June 22, 2019 8 E-mail Authentication for Internationalized Mail 9 draft-ietf-dmarc-eaiauth-00 11 Abstract 13 SPF, DKIM, and DMARC enable a domain owner to publish e-mail 14 authentication and policy information in the DNS. In 15 internationalized e-mail, domain names can occur both as U-labels and 16 A-labels. The Authentication-Results header reports the result of 17 authentication checks made with SPF, DKIM, DMARC, and other schemes. 18 This specification clarifies when to use which form of domain names 19 when using SPF, DKIM, and DMARC and when creating Authentication- 20 Results headers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 22, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. General principles . . . . . . . . . . . . . . . . . . . . . 3 59 4. SPF and internationalized mail . . . . . . . . . . . . . . . 3 60 5. DKIM and internationalized mail . . . . . . . . . . . . . . . 4 61 6. DMARC and internationalized mail . . . . . . . . . . . . . . 4 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 SPF, DKIM, and DMARC enable a domain owner to publish e-mail 71 authentication and policy information in the DNS. SPF primarily 72 publishes information about what host addresses are authorized to 73 send mail for a domain. DKIM places cryptographic signatures on 74 e-mail messages, with the validation keys published in the DNS. 75 DMARC publishes policy information related to the domain in the From: 76 header of e-mail messages. 78 In conventional e-mail, all domain names are ASCII in all contexts so 79 there is no question about the representation of the domain names. 80 All internationalized domain names are represented as A-labels 81 [RFC5890] in unencoded message bodies, in SMTP sessions, and in the 82 DNS. Internationalized mail [RFC6530] allows U-labels in SMTP 83 sessions [RFC6531] and in message headers [RFC6532]. 85 Every U-label is equivalent to an A-label, so in principle the choice 86 of label format should not cause any ambiguities. But in practice, 87 consistent use of label formats will make it more likely that mail 88 senders' and receivers' code interoperates. 90 Internationalized mail also allows UTF-8 characters in the local 91 parts of mailbox names, which were historically only ASCII. 93 2. Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when 97 written in upper case in in this document are to be interpreted as 98 described in [RFC2119] and [RFC8174]. 100 The term IDN, for Internationalized Domain Name, refers to a doman 101 name containing either U-labels or A-labels. 103 Since DMARC is not currently a standards track protocol, this 104 specification offers advice rather than requirements for DMARC. 106 3. General principles 108 In headers in EAI mail messages, domain names that were restricted to 109 ASCII can now be U-labels, and mailbox local parts can be UTF-8. 110 Header names and other text intended primarily to be interpreted by 111 computers rather than read by people remains ASCII. 113 Strings stored in DNS records remain ASCII since there is no way to 114 tell whether a client retrieving a DNS record expects an EAI or an 115 ASCII result. When a domain name found in a mail header includes 116 U-labels, those labels are translated to A-labels before being looked 117 up in the DNS, as described in [RFC5891]. 119 4. SPF and internationalized mail 121 SPF [RFC7208] uses two identities from the SMTP session, the host 122 name in the EHLO command, and the domain in the address in the MAIL 123 FROM command. Since the EHLO command precedes the server response 124 that tells whether the server supports the SMTPUTF8 extension, an IDN 125 argument MUST be represented as an A-label. An IDN in MAIL FROM can 126 be either U-labels or an A-labels. 128 All U-labels MUST be converted to A-labels before being used for an 129 SPF validation. This includes both the original DNS lookup, 130 described in Section 3 of [RFC7208] and the macro expansion of 131 domain-spec described in section 7. Section 4.3 of [RFC7208] states 132 that all IDNs in an SPF DNS record MUST be A-labels; this rule is 133 unchanged since any SPF record can be used to authorize either EAI or 134 conventional mail. 136 SPF macros %s and %l expand the local-part of the sender's mailbox. 137 If the local-part contains non-ASCII characters, terms that include 138 %s or %l do not match anything. (Note that unlike U-labels, there is 139 no way to rewrite non-ASCII local parts into ASCII.) 141 5. DKIM and internationalized mail 143 DKIM [RFC6376] specifies a message header that contains a 144 cryptographic message signature and a DNS record that contains the 145 validation key. 147 Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its 148 definition is modified in internationalized messages so that non- 149 ASCII UTF-8 characters need not be quoted. The ABNF for dkim-safe- 150 char in internationalized messages is replaced by the following: 152 dkim-safe-char = %x21-3A / %x3C / %x3E-7E / %x80-FF 153 ; '!' - ':', '<', '>' - '~', non-ASCII 155 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 156 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 157 relaxed only for headers in internationalized messages [RFC6532] so 158 IDNs SHOULD be represented as U-labels but MAY be A-labels. This 159 provides improved consistency with other headers. The set of 160 allowable characters in the local-part of an i= tag is extended as 161 described in [RFC6532]. When computing or verifying the hash in a 162 DKIM signature as described in section 3.7, the hash MUST use the 163 domain name in the format it occurs in the header. 165 DKIM key records, described in section 3.6.1, do not contain domain 166 names, so there is no change to their specification. 168 6. DMARC and internationalized mail 170 DMARC [RFC7489] defines a policy language that domain owners can 171 specify for the domain of the address in a RFC5322.From header. 173 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 174 RFC5322.From address domain are to be handled. That section is 175 updated to say that all U-labels in the domain are converted to 176 A-labels before further processing. Sections 6.7 and 7.1 are 177 similarly updated to say that all U-labels in domains being handled 178 are converted to A-labels before further processing. 180 DMARC policy records, described in sections 6.3 and 7.1, can contain 181 e-mail addresses in the rua and ruf tags. Since a policy record can 182 be used for both internationalized and conventional mail, those 183 addresses still have to be conventional addresses, not 184 internationalized addresses. 186 7. IANA Considerations 188 This document makes no request of IANA. 190 8. Security Considerations 192 E-mail is subject to a vast range of threats and abuses. This 193 document attempts to slightly mitigate some of them but does not, as 194 far as the author knows, add any new ones. 196 9. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC5890] Klensin, J., "Internationalized Domain Names for 204 Applications (IDNA): Definitions and Document Framework", 205 RFC 5890, DOI 10.17487/RFC5890, August 2010, 206 . 208 [RFC5891] Klensin, J., "Internationalized Domain Names in 209 Applications (IDNA): Protocol", RFC 5891, 210 DOI 10.17487/RFC5891, August 2010, 211 . 213 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 214 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 215 RFC 6376, DOI 10.17487/RFC6376, September 2011, 216 . 218 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 219 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 220 February 2012, . 222 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 223 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 224 . 226 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 227 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 228 2012, . 230 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 231 Authorizing Use of Domains in Email, Version 1", RFC 7208, 232 DOI 10.17487/RFC7208, April 2014, 233 . 235 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 236 Message Authentication, Reporting, and Conformance 237 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 238 . 240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 242 May 2017, . 244 Appendix A. Change history 246 00 First WG version 248 Author's Address 250 John Levine 251 Taughannock Networks 252 PO Box 727 253 Trumansburg, NY 14886 255 Phone: +1 831 480 2300 256 Email: standards@taugh.com 257 URI: http://jl.ly