idnits 2.17.1 draft-ietf-dmarc-eaiauth-02.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 directly say this. It does mention RFC7489 though, so this could be OK. -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to directly say this. It does mention RFC6376 though, so this could be OK. -- The draft header indicates that this document updates RFC7208, but the abstract doesn't seem to directly say this. It does mention RFC7208 though, so this could be OK. 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 (February 22, 2019) is 1889 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) February 22, 2019 5 Intended status: Standards Track 6 Expires: August 26, 2019 8 E-mail Authentication for Internationalized Mail 9 draft-ietf-dmarc-eaiauth-02 11 Abstract 13 SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain 14 owner to publish e-mail authentication and policy information in the 15 DNS. In internationalized e-mail, domain names can occur both as 16 U-labels and A-labels. The Authentication-Results header reports the 17 result of authentication checks made with SPF, DKIM, DMARC, and other 18 schemes. This specification updates the SPF, DKIM, and DMARC 19 specifications to clarify which form of internationalized domain 20 names to use in those specifications, and when creating 21 Authentication-Results headers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 26, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. General principles . . . . . . . . . . . . . . . . . . . . . 3 60 4. SPF and internationalized mail . . . . . . . . . . . . . . . 3 61 5. DKIM and internationalized mail . . . . . . . . . . . . . . . 4 62 6. DMARC and internationalized mail . . . . . . . . . . . . . . 4 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain 72 owner to publish e-mail authentication and policy information in the 73 DNS. SPF primarily publishes information about what host addresses 74 are authorized to send mail for a domain. DKIM places cryptographic 75 signatures on e-mail messages, with the validation keys published in 76 the DNS. DMARC publishes policy information related to the domain in 77 the From: header of e-mail messages. 79 In conventional e-mail, all domain names are ASCII in all contexts so 80 there is no question about the representation of the domain names. 81 All internationalized domain names are represented as A-labels 82 [RFC5890] in unencoded message bodies, in SMTP sessions, and in the 83 DNS. Internationalized mail [RFC6530] allows U-labels in SMTP 84 sessions [RFC6531] and in message headers [RFC6532]. 86 Every U-label is equivalent to an A-label, so in principle the choice 87 of label format should not cause any ambiguities. But in practice, 88 consistent use of label formats will make it more likely that mail 89 senders' and receivers' code interoperates. 91 Internationalized mail also allows UTF-8 characters in the local 92 parts of mailbox names, which were historically only ASCII. 94 2. Definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] and [RFC8174]. when they appear in all capitals, as 100 shown here. 102 The term IDN, for Internationalized Domain Name, refers to a domain 103 name containing either U-labels or A-labels. 105 Since DMARC is not currently a standards track protocol, this 106 specification offers advice rather than requirements for DMARC. 108 3. General principles 110 In headers in EAI mail messages, domain names that were restricted to 111 ASCII can now be U-labels, and mailbox local parts can be UTF-8. 112 Header names and other text intended primarily to be interpreted by 113 computers rather than read by people remains ASCII. 115 Strings stored in DNS records remain ASCII since there is no way to 116 tell whether a client retrieving a DNS record expects an EAI or an 117 ASCII result. When a domain name found in a mail header includes 118 U-labels, those labels are translated to A-labels before being looked 119 up in the DNS, as described in [RFC5891]. 121 4. SPF and internationalized mail 123 SPF [RFC7208] uses two identities from the SMTP session, the host 124 name in the EHLO command, and the domain in the address in the MAIL 125 FROM command. Since the EHLO command precedes the server response 126 that tells whether the server supports the SMTPUTF8 extension, an IDN 127 argument MUST be represented as an A-label. An IDN in MAIL FROM can 128 be either U-labels or A-labels. 130 All U-labels MUST be converted to A-labels before being used for an 131 SPF validation. This includes both the original DNS lookup, 132 described in Section 3 of [RFC7208] and the macro expansion of 133 domain-spec described in section 7. Section 4.3 of [RFC7208] states 134 that all IDNs in an SPF DNS record MUST be A-labels; this rule is 135 unchanged since any SPF record can be used to authorize either EAI or 136 conventional mail. 138 SPF macros %s and %l expand the local-part of the sender's mailbox. 139 If the local-part contains non-ASCII characters, terms that include 140 %s or %l do not match anything. (Note that unlike U-labels, there is 141 no way to rewrite non-ASCII local parts into ASCII.) 143 5. DKIM and internationalized mail 145 DKIM [RFC6376] specifies a message header that contains a 146 cryptographic message signature and a DNS record that contains the 147 validation key. 149 Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its 150 definition is modified in internationalized messages so that non- 151 ASCII UTF-8 characters need not be quoted. The ABNF for dkim-safe- 152 char in internationalized messages is replaced by the following: 154 dkim-safe-char = %x21-3A / %x3C / %x3E-7E / %x80-FF 155 ; '!' - ':', '<', '>' - '~', non-ASCII 157 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 158 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 159 relaxed only for headers in internationalized messages [RFC6532] so 160 IDNs SHOULD be represented as U-labels but MAY be A-labels. This 161 provides improved consistency with other headers. The set of 162 allowable characters in the local-part of an i= tag is extended as 163 described in [RFC6532]. When computing or verifying the hash in a 164 DKIM signature as described in section 3.7, the hash MUST use the 165 domain name in the format it occurs in the header. 167 Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. 168 Its first step converts all header field names from upper case to 169 lower case. Field names are restricted to printable ASCII (see 170 [RFC5322] section 3.6.8) so this case conversion remains the usual 171 ASCII conversion. 173 DKIM key records, described in section 3.6.1, do not contain domain 174 names, so there is no change to their specification. 176 6. DMARC and internationalized mail 178 DMARC [RFC7489] defines a policy language that domain owners can 179 specify for the domain of the address in a RFC5322.From header. 181 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 182 RFC5322.From address domain are to be handled. That section is 183 updated to say that all U-labels in the domain are converted to 184 A-labels before further processing. Sections 6.7 and 7.1 are 185 similarly updated to say that all U-labels in domains being handled 186 are converted to A-labels before further processing. 188 DMARC policy records, described in sections 6.3 and 7.1, can contain 189 e-mail addresses in the rua and ruf tags. Since a policy record can 190 be used for both internationalized and conventional mail, those 191 addresses still have to be conventional addresses, not 192 internationalized addresses. 194 7. IANA Considerations 196 This document makes no request of IANA. 198 8. Security Considerations 200 E-mail is subject to a vast range of threats and abuses. This 201 document attempts to slightly mitigate some of them but does not, as 202 far as the author knows, add any new ones. 204 9. Normative References 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, 208 DOI 10.17487/RFC2119, March 1997, 209 . 211 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 212 DOI 10.17487/RFC5322, October 2008, 213 . 215 [RFC5890] Klensin, J., "Internationalized Domain Names for 216 Applications (IDNA): Definitions and Document Framework", 217 RFC 5890, DOI 10.17487/RFC5890, August 2010, 218 . 220 [RFC5891] Klensin, J., "Internationalized Domain Names in 221 Applications (IDNA): Protocol", RFC 5891, 222 DOI 10.17487/RFC5891, August 2010, 223 . 225 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 226 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 227 RFC 6376, DOI 10.17487/RFC6376, September 2011, 228 . 230 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 231 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 232 February 2012, . 234 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 235 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 236 . 238 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 239 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 240 2012, . 242 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 243 Authorizing Use of Domains in Email, Version 1", RFC 7208, 244 DOI 10.17487/RFC7208, April 2014, 245 . 247 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 248 Message Authentication, Reporting, and Conformance 249 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 250 . 252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 254 May 2017, . 256 Appendix A. Change history 258 01 to 02 update references 260 00 to 01 Relaxed canon, Typos 262 00 First WG version 264 Author's Address 266 John Levine 267 Taughannock Networks 268 PO Box 727 269 Trumansburg, NY 14886 271 Phone: +1 831 480 2300 272 Email: standards@taugh.com 273 URI: http://jl.ly