非官方中文译本声明：本页为 IETF RFC 8616《Email Authentication for Internationalized Mail》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8616。

RFC 8616《国际化邮件的认证处理》中文译本

IETF · RFC 8616 · 标准跟踪（Standards Track）· 2019 年 6 月

1. 引言（Introduction）

发件人策略框架（SPF，见 RFC 7208）、域名密钥识别邮件（DKIM，见 RFC 6376）以及基于域名的消息认证、报告与一致性（DMARC，见 RFC 7489），使域名所有者能够在 DNS 中发布电子邮件认证与策略信息。SPF 主要发布关于「哪些主机地址被授权代表某域名发送邮件」的信息。DKIM 在电子邮件消息上附加密码学签名，验证所用的密钥发布于 DNS 中。DMARC 发布与电子邮件消息 From: 信头字段中域名相关的策略信息。

在常规电子邮件中，所有域名在各个上下文里都是 ASCII，因此不存在域名表示形式的问题。所有国际化域名都以 A-label（A 标签）[RFC5890] 的形式出现在消息信头字段、SMTP 会话以及 DNS 中。

国际化邮件（internationalized mail）[RFC6530]（通常简称为「EAI」，即 Email Address Internationalization，邮件地址国际化）允许在 SMTP 会话 [RFC6531] 与消息信头字段 [RFC6532] 中使用 U-label（U 标签）。

每一个 U-label 都等价于一个 A-label，因此从原理上讲，标签格式的选择不会造成歧义。但在实践中，一致地使用标签格式将更有可能使邮件发送方与接收方的代码实现互操作。

国际化邮件还允许邮箱名（mailbox name）的本地部分（local part）使用 UTF-8 编码的 Unicode 字符，而历史上本地部分只能是 ASCII。

2. 定义（Definitions）

本文件中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应该）、"SHOULD NOT"（不应该）、"RECOMMENDED"（推荐）、"NOT RECOMMENDED"（不推荐）、"MAY"（可以）和 "OPTIONAL"（可选），当且仅当它们以全大写形式出现时，才按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如下文所示。

术语「IDN」指国际化域名（Internationalized Domain Name，IDN），即包含 U-label 或 A-label 中任一种的域名。

由于 DMARC 目前尚不是标准跟踪（Standards Track）协议，本规范对 DMARC 提供的是建议（advice）而非强制要求（requirements）。

3. 通用原则（General Principles）

在 EAI 邮件消息的信头中，原本被限定为 ASCII 的域名可以是 U-label，邮箱本地部分可以是 UTF-8。而信头字段名（field names）以及其他主要由计算机而非由人阅读的文本，仍然保持 ASCII。

存储在 DNS 记录中的字符串仍然保持 ASCII，因为无法判断检索某条 DNS 记录的客户端期望的是 EAI 结果还是 ASCII 结果。当在邮件信头字段中发现的域名包含 U-label 时，这些标签在查 DNS 之前需先转换为 A-label，如 [RFC5891] 所述。

4. SPF 与国际化邮件（SPF and Internationalized Mail）

SPF [RFC7208] 使用来自 SMTP 会话的两个身份：EHLO 命令中的主机名（host name），以及 MAIL FROM 命令中地址里的域名。由于 EHLO 命令先于服务器返回「是否支持 SMTPUTF8 扩展」的响应，因此 IDN 主机名必须（MUST）以 A-label 表示。MAIL FROM 中的 IDN 可以是 U-label 或 A-label。

所有 U-label必须（MUST）在用于 SPF 验证之前转换为 A-label。这不仅包括用于原始 DNS 查找的名称中的标签（见 [RFC7208] 第 3 节），也包括 domain-spec 宏展开（macro expansion）中所用的标签（见 [RFC7208] 第 7 节）。[RFC7208] 第 4.3 节规定，SPF DNS 记录中的所有 IDN必须（MUST）为 A-label；此规则保持不变，因为任意 SPF 记录都可用于授权 EAI 邮件或常规邮件。

SPF 宏 %{s} 与 %{l} 展开发送者邮箱的本地部分。如果本地部分包含非 ASCII 字符，那么包含 %{s} 或 %{l} 的术语（terms）将无法匹配任何内容，因为非 ASCII 的本地部分无法用作这些宏旨在匹配的 DNS 标签。由于这些宏很少被使用，这在实际中不太可能成为问题。

5. DKIM 与国际化邮件（DKIM and Internationalized Mail）

DKIM [RFC6376] 规定了一种邮件信头字段，其中包含密码学消息签名，以及一种 DNS 记录，其中包含验证密钥。

[RFC6376] 第 2.11 节定义了 dkim-quoted-printable。其定义在带有国际化信头字段的消息中被修改，使得非 ASCII 的 UTF-8 字符无需加引号（quoted）。在这些消息中，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

   UTF8-2                = <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>

[RFC6376] 第 3.5 节规定，DKIM-Signature 信头字段中 d=、i= 与 s= 标签里的 IDN必须（MUST）编码为 A-label。该规则仅在国际化消息信头字段 [RFC6532] 中被放宽，因此 IDN应该（SHOULD）表示为 U-label。这提供了与其他信头字段更好的一致性。（A-label 仍然有效，以便从较旧软件进行过渡。）i= 标签本地部分中允许出现的字符集合，按 [RFC6532] 第 3.2 节所描述的电子邮件地址本地部分的方式进行了同等扩展。在计算或验证 DKIM 签名中的哈希（hash）时（见 [RFC6376] 第 3.7 节），哈希必须（MUST）使用域名在信头字段中出现的格式。

[RFC6376] 第 3.4.2 节描述了宽松信头规范化（relaxed header canonicalization）。其第一步将所有信头字段名从大写转换为小写。字段名被限定为可打印 ASCII（见 [RFC5322] 第 3.6.8 节），因此此大小写转换仍为 ASCII 大小写转换。

[RFC6376] 第 3.6.1 节描述的 DKIM 密钥记录（key records）不包含域名，因此其规范无需更改。

6. DMARC 与国际化邮件（DMARC and Internationalized Mail）

DMARC [RFC7489] 定义了一种策略语言，域名所有者可针对 RFC5322.From 信头字段中地址的域名指定该语言。

[RFC7489] 第 6.6.1 节对 RFC5322.From 地址域名中的 IDN 如何被处理做了（多少有些不精确的）规定。该节被更新为：域名中的所有 U-label 在进一步处理之前均转换为 A-label。[RFC7489] 第 7.1 节也作了类似更新，即所处理域名中的所有 U-label 在进一步处理之前均转换为 A-label。

[RFC7489] 第 6.3 节与第 7.1 节描述的 DMARC 策略记录（policy records）可以在 "rua" 与 "ruf" 标签中包含电子邮件地址。由于一条策略记录可同时用于国际化邮件与常规邮件，这些地址仍然必须是常规地址，而非国际化地址。

7. IANA 考虑事项（IANA Considerations）

本文档没有任何 IANA 操作（IANA actions）。

8. 安全考虑事项（Security Considerations）

电子邮件面临范围极广的威胁与滥用。本文档试图略微缓解其中的一部分，但据作者所知，并未引入任何新的威胁。对 SPF、DKIM 与 DMARC 的更新，意在使各相关规范在国际化邮件上的工作可靠性，与在 ASCII 邮件上一样，从而使依赖它们的应用（例如某些用于捕获垃圾邮件与钓鱼邮件的邮件过滤器）能在国际化邮件上更可靠地工作。

9. 规范性引用文献（Normative References）

作者地址（Author's Address）

John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
United States of America

Email: standards@taugh.com
URI: http://jl.ly