idnits 2.17.1 draft-ietf-dmarc-eaiauth-03.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 27, 2019) is 1884 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 27, 2019 5 Intended status: Standards Track 6 Expires: August 31, 2019 8 E-mail Authentication for Internationalized Mail 9 draft-ietf-dmarc-eaiauth-03 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 31, 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 . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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 139 mailbox. If the local-part contains non-ASCII characters, terms that 140 include %{s} or %{l} do not match anything. (Note that unlike 141 U-labels in domains, there is no way to rewrite non-ASCII local parts 142 into ASCII.) 144 5. DKIM and internationalized mail 146 DKIM [RFC6376] specifies a message header that contains a 147 cryptographic message signature and a DNS record that contains the 148 validation key. 150 Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its 151 definition is modified in internationalized messages so that non- 152 ASCII UTF-8 characters need not be quoted. The ABNF for dkim-safe- 153 char in internationalized messages is replaced by the following, 154 adding non-ASCII UTF-8 characters from [RFC3629]: 156 dkim-safe-char = %x21-3A / %x3C / %x3E-7E / 157 UTF8-2 / UTF8-3 / UTF8-4 158 ; '!' - ':', '<', '>' - '~', non-ASCII 160 UTF8-2 = 162 UTF8-3 = 164 UTF8-4 = 166 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 167 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 168 relaxed only for headers in internationalized messages [RFC6532] so 169 IDNs SHOULD be represented as U-labels but MAY be A-labels. This 170 provides improved consistency with other headers. The set of 171 allowable characters in the local-part of an i= tag is extended as 172 described in [RFC6532]. When computing or verifying the hash in a 173 DKIM signature as described in section 3.7, the hash MUST use the 174 domain name in the format it occurs in the header. 176 Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. 177 Its first step converts all header field names from upper case to 178 lower case. Field names are restricted to printable ASCII (see 179 [RFC5322] section 3.6.8) so this case conversion remains the usual 180 ASCII conversion. 182 DKIM key records, described in section 3.6.1, do not contain domain 183 names, so there is no change to their specification. 185 6. DMARC and internationalized mail 187 DMARC [RFC7489] defines a policy language that domain owners can 188 specify for the domain of the address in a RFC5322.From header. 190 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 191 RFC5322.From address domain are to be handled. That section is 192 updated to say that all U-labels in the domain are converted to 193 A-labels before further processing. Sections 6.7 and 7.1 are 194 similarly updated to say that all U-labels in domains being handled 195 are converted to A-labels before further processing. 197 DMARC policy records, described in sections 6.3 and 7.1, can contain 198 e-mail addresses in the rua and ruf tags. Since a policy record can 199 be used for both internationalized and conventional mail, those 200 addresses still have to be conventional addresses, not 201 internationalized addresses. 203 7. IANA Considerations 205 This document makes no request of IANA. 207 8. Security Considerations 209 E-mail is subject to a vast range of threats and abuses. This 210 document attempts to slightly mitigate some of them but does not, as 211 far as the author knows, add any new ones. 213 9. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, 217 DOI 10.17487/RFC2119, March 1997, 218 . 220 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 221 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 222 2003, . 224 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 225 DOI 10.17487/RFC5322, October 2008, 226 . 228 [RFC5890] Klensin, J., "Internationalized Domain Names for 229 Applications (IDNA): Definitions and Document Framework", 230 RFC 5890, DOI 10.17487/RFC5890, August 2010, 231 . 233 [RFC5891] Klensin, J., "Internationalized Domain Names in 234 Applications (IDNA): Protocol", RFC 5891, 235 DOI 10.17487/RFC5891, August 2010, 236 . 238 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 239 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 240 RFC 6376, DOI 10.17487/RFC6376, September 2011, 241 . 243 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 244 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 245 February 2012, . 247 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 248 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 249 . 251 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 252 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 253 2012, . 255 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 256 Authorizing Use of Domains in Email, Version 1", RFC 7208, 257 DOI 10.17487/RFC7208, April 2014, 258 . 260 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 261 Message Authentication, Reporting, and Conformance 262 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 263 . 265 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 266 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 267 May 2017, . 269 Appendix A. Change history 271 02 to 03 minor edits per Alexey 273 01 to 02 update references 275 00 to 01 Relaxed canon, Typos 277 00 First WG version 279 Author's Address 281 John Levine 282 Taughannock Networks 283 PO Box 727 284 Trumansburg, NY 14886 286 Phone: +1 831 480 2300 287 Email: standards@taugh.com 288 URI: http://jl.ly