Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 8616 Taughannock Networks
Updates: 6376, 7208, 7489 June 2019
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 8616 Taughannock Networks
Updates: 6376, 7208, 7489 June 2019
Category: Standards Track
ISSN: 2070-1721
Email Authentication for Internationalized Mail
国际化邮件的电子邮件身份验证
Abstract
摘要
Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels 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.
发件人策略框架（SPF）（RFC 7208）、域密钥标识邮件（DKIM）（RFC 6376）和基于域的消息身份验证、报告和一致性（DMARC）（RFC 7489）使域所有者能够在DNS中发布电子邮件身份验证和策略信息。在国际化电子邮件中，域名既可以作为U标签出现，也可以作为A标签出现。本规范更新了SPF、DKIM和DMARC规范，以澄清在这些规范中使用哪种形式的国际化域名。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8616.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Principles . . . . . . . . . . . . . . . . . . . . . 3
4. SPF and Internationalized Mail . . . . . . . . . . . . . . . 3
5. DKIM and Internationalized Mail . . . . . . . . . . . . . . . 3
6. DMARC and Internationalized Mail . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Principles . . . . . . . . . . . . . . . . . . . . . 3
4. SPF and Internationalized Mail . . . . . . . . . . . . . . . 3
5. DKIM and Internationalized Mail . . . . . . . . . . . . . . . 3
6. DMARC and Internationalized Mail . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain owner to publish email authentication and policy information in the DNS. SPF primarily publishes information about what host addresses are authorized to send mail for a domain. DKIM places cryptographic signatures on email messages, with the validation keys published in the DNS. DMARC publishes policy information related to the domain in the From: header field of email messages.
SPF[RFC7208]、DKIM[RFC6376]和DMARC[RFC7489]使域所有者能够在DNS中发布电子邮件身份验证和策略信息。SPF主要发布关于授权哪些主机地址为域发送邮件的信息。DKIM在电子邮件上放置加密签名，验证密钥在DNS中发布。DMARC在电子邮件的发件人：标题字段中发布与域相关的策略信息。
In conventional email, all domain names are ASCII in all contexts, so there is no question about the representation of the domain names. All internationalized domain names are represented as A-labels [RFC5890] in message header fields, SMTP sessions, and the DNS.
在传统的电子邮件中，所有的域名在所有上下文中都是ASCII码，因此域名的表示形式毫无疑问。所有国际化域名在消息头字段、SMTP会话和DNS中都表示为A标签[RFC5890]。
Internationalized mail [RFC6530] (generally called "EAI" for Email Address Internationalization) allows U-labels in SMTP sessions [RFC6531] and message header fields [RFC6532].
国际化邮件[RFC6530]（电子邮件地址国际化通常称为“EAI”）允许SMTP会话[RFC6531]和邮件头字段[RFC6532]中使用U标签。
Every U-label is equivalent to an A-label, so in principle, the choice of label format will not cause ambiguities. But in practice, consistent use of label formats will make it more likely that code for mail senders and receivers interoperates.
每个U型标签都相当于A型标签，因此原则上，标签格式的选择不会造成歧义。但在实践中，标签格式的一致使用将使邮件发送者和接收者的代码更有可能进行互操作。
Internationalized mail also allows UTF-8-encoded Unicode characters in the local parts of mailbox names, which were historically only ASCII.
国际化邮件还允许在邮箱名称的本地部分使用UTF-8编码的Unicode字符，这在历史上只有ASCII字符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The term "IDN", for Internationalized Domain Name, refers to a domain name containing either U-labels or A-labels.
术语“IDN”表示国际化域名，指包含U标签或a标签的域名。
Since DMARC is not currently a Standards Track protocol, this specification offers advice rather than requirements for DMARC.
由于DMARC目前不是一个标准跟踪协议，因此本规范提供了DMARC的建议而不是要求。
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 field names and other text intended primarily to be interpreted by computers rather than read by people remains ASCII.
在EAI邮件消息的标题中，限制为ASCII的域名可以是U标签，邮箱本地部分可以是UTF-8。标题字段名和其他主要由计算机解释而不是由人读取的文本仍然是ASCII。
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 ASCII result. When a domain name found in a mail header field includes U-labels, those labels are translated to A-labels before being looked up in the DNS, as described in [RFC5891].
DNS记录中存储的字符串保持ASCII，因为无法判断检索DNS记录的客户端是否需要EAI或ASCII结果。当在邮件头字段中找到的域名包含U标签时，在DNS中查找之前，这些标签将被转换为a标签，如[RFC5891]中所述。
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 FROM command. Since the EHLO command precedes the server response 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 be either U-labels or A-labels.
SPF[RFC7208]使用SMTP会话中的两个标识：EHLO命令中的主机名和MAIL from命令中的地址中的域。由于EHLO命令位于服务器响应之前，该响应告知服务器是否支持SMTPUTF8扩展，因此IDN主机名必须表示为A标签。来自的邮件中的IDN可以是U标签或A标签。
All U-labels MUST be converted to A-labels before being used for an SPF validation. This includes both the labels in the name used for the original DNS lookup, described in Section 3 of [RFC7208], and those used in the macro expansion of 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 unchanged since any SPF record can be used to authorize either EAI or conventional mail.
在用于SPF验证之前，必须将所有U型标签转换为A型标签。这包括[RFC7208]第3节中描述的用于原始DNS查找的名称中的标签，以及第7节中描述的域规范宏扩展中使用的标签。[RFC7208]第4.3节规定，SPF DNS记录中的所有IDN必须是A标签；此规则不变，因为任何SPF记录都可以用于授权EAI或常规邮件。
SPF macros %{s} and %{l} expand the local part of the sender's mailbox. If the local part contains non-ASCII characters, terms that 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 match. Since these macros are rarely used, this is unlikely to be an issue in practice.
SPF宏%{s}和%{l}扩展发件人邮箱的本地部分。如果本地部分包含非ASCII字符，则包含%{s}或%{l}的术语不匹配任何内容，因为非ASCII本地部分不能用作宏要匹配的DNS标签。由于很少使用这些宏，因此在实践中这不太可能成为问题。
DKIM [RFC6376] specifies a mail header field that contains a cryptographic message signature and a DNS record that contains the validation key.
DKIM[RFC6376]指定包含加密消息签名的邮件头字段和包含验证密钥的DNS记录。
Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its definition is modified in messages with internationalized header fields so that non-ASCII UTF-8 characters need not be quoted. The ABNF [RFC5234] for dkim-safe-char in those messages is replaced by the following, adding non-ASCII UTF-8 characters from [RFC3629]:
[RFC6376]第2.11节定义了dkim报价可打印。它的定义在带有国际化标头字段的消息中修改，因此无需引用非ASCII UTF-8字符。这些消息中dkim safe char的ABNF[RFC5234]替换为以下内容，从[RFC3629]中添加非ASCII UTF-8字符：
dkim-safe-char = %x21-3A / %x3C / %x3E-7E /
UTF8-2 / UTF8-3 / UTF8-4
; '!' - ':', '<', '>' - '~', non-ASCII
dkim-safe-char = %x21-3A / %x3C / %x3E-7E /
UTF8-2 / UTF8-3 / UTF8-4
; '!' - ':', '<', '>' - '~', 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 of a DKIM-Signature header field MUST be encoded as A-labels. This rule is relaxed only for internationalized message header fields [RFC6532], so IDNs SHOULD be represented as U-labels. This provides improved consistency with other header fields. (A-labels remain valid to allow a transition from older software.) The set of allowable characters in the local part of an i= tag is extended 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 DKIM signature as described in Section 3.7 of [RFC6376], the hash MUST use the domain name in the format it occurs in the header field.
[RFC6376]第3.5节规定，DKIM签名头字段的d=、i=、s=标记中的IDN必须编码为a标签。此规则仅适用于国际化消息头字段[RFC6532]，因此IDN应表示为U标签。这提高了与其他标题字段的一致性。（A标签仍然有效，以允许从旧软件转换。）i=标记的本地部分中允许的字符集以与[RFC6532]第3.2节中所述的电子邮件地址本地部分相同的方式扩展。如[RFC6376]第3.7节所述，在计算或验证DKIM签名中的哈希时，哈希必须使用域名，其格式与头字段中出现的格式相同。
Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. Its first step converts all header field names from uppercase to lowercase. Field names are restricted to printable ASCII (see [RFC5322], Section 3.6.8), so this case conversion remains ASCII case conversion.
[RFC6376]的第3.4.2节描述了宽松的标头规范化。它的第一步是将所有头字段名从大写转换为小写。字段名限制为可打印的ASCII（见[RFC5322]，第3.6.8节），因此这种大小写转换仍然是ASCII大小写转换。
DKIM key records, described in Section 3.6.1 of [RFC6376], do not contain domain names, so there is no change to their specification.
[RFC6376]第3.6.1节中描述的DKIM密钥记录不包含域名，因此其规范没有变化。
DMARC [RFC7489] defines a policy language that domain owners can specify for the domain of the address in an RFC5322.From header field.
DMARC[RFC7489]定义了一种策略语言，域所有者可以在RFC5322.From标头字段中为地址的域指定该语言。
Section 6.6.1 of [RFC7489] specifies, somewhat imprecisely, how IDNs in the RFC5322.From address domain are to be handled. That section is updated to say that all U-labels in the domain are converted to A-labels before further processing. Section 7.1 of [RFC7489] is
[RFC7489]的第6.6.1节规定了如何处理RFC5322.From地址域中的IDN，但有些不精确。该部分已更新，说明域中的所有U型标签在进一步处理之前都将转换为A型标签。[RFC7489]第7.1节为
similarly updated to say that all U-labels in domains being handled are converted to A-labels before further processing.
类似地，更新后表示，在进一步处理之前，正在处理的域中的所有U标签都将转换为A标签。
DMARC policy records, described in Sections 6.3 and 7.1 of [RFC7489], can contain email addresses in the "rua" and "ruf" tags. Since a policy record can be used for both internationalized and conventional mail, those addresses still have to be conventional addresses, not internationalized addresses.
[RFC7489]第6.3节和第7.1节中描述的DMARC策略记录可以在“rua”和“ruf”标签中包含电子邮件地址。由于策略记录可用于国际邮件和常规邮件，因此这些地址仍然必须是常规地址，而不是国际地址。
This document has no IANA actions.
本文档没有IANA操作。
Email is subject to a vast range of threats and abuses. This 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, and DMARC are intended to allow the respective specifications to work as reliably on internationalized mail as they do on ASCII mail, so that applications that use them, such as some kinds of mail filters that catch spam and phish, can work more reliably on internationalized mail.
电子邮件受到广泛的威胁和滥用。本文件试图稍微缓解其中一些问题，但据作者所知，并未添加任何新问题。对SPF、DKIM和DMARC的更新旨在允许各自的规范在国际化邮件上像在ASCII邮件上一样可靠地工作，以便使用它们的应用程序（如捕获垃圾邮件和钓鱼的某些邮件过滤器）能够在国际化邮件上更可靠地工作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<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>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 6530，DOI 10.17487/RFC6530，2012年2月<https://www.rfc-editor.org/info/rfc6530>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, <https://www.rfc-editor.org/info/rfc6531>.
[RFC6531]Yao，J.和W.Mao，“国际化电子邮件的SMTP扩展”，RFC 6531，DOI 10.17487/RFC653112012年2月<https://www.rfc-editor.org/info/rfc6531>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件头”，RFC 6532，DOI 10.17487/RFC6532，2012年2月<https://www.rfc-editor.org/info/rfc6532>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
Author's Address
作者地址
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States of America
John Levine Taughannock Networks美国纽约州杜鲁曼斯堡727号邮政信箱14886
Email: standards@taugh.com
URI: http://jl.ly
Email: standards@taugh.com
URI: http://jl.ly