RFC 6532《国际化邮件头字段》中文导读

1. 问题与目标

互联网邮件最初只支持 7 位 ASCII。MIME 后来允许在正文分段中使用 8 位字符集，并定义了 encoded-word 构造，使某些头字段值可以承载其他字符集。但真正的国际化还需要更进一步：让 Unicode（含 ASCII 之外的字符）可以出现在邮件地址中，并让 From、To、Subject 等头字段能直接使用 Unicode，而不必依赖复杂的 encoded-word。

RFC 6532 就是这项扩展，它同时更新了 RFC 2045 第 6.4 节，解除了“不得对 message/ 的子类型施加非恒等内容传输编码”的限制。需要注意：采用本格式的邮件在 SMTP 上传输时需要 SMTPUTF8 扩展（RFC 6531）。

2. 语法扩展

扩展的方式非常简洁——在 RFC 5322 的 ABNF 上，把若干基础规则增补为可包含非 ASCII 的 UTF-8 序列：

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
dtext   =/  UTF8-non-ascii

这几行带来的直接后果是，以下构造现在都允许使用 UTF-8：

• 非结构化文本，如 Subject、Content-description 等头字段；
• 任何使用原子（atom）的构造，包括但不限于地址的本地部分与 Message-ID，也包括 Received 头字段中 for 子句里的地址；
• 引用字符串（quoted string）；
• 域名（domain）。

头字段名不在此列——字段名仍然只能由 ASCII 字符构成。

3. 规范化：用 NFC，不要用 NFKC

Unicode 存在多种等价表示，因此需要规定规范化形式。规范建议应当使用 NFC 规范化形式；不应当使用 NFKC，因为 NFKC 可能丢失在某些特殊情况下正确拼写姓名所需的信息。

原文对此给出的理由很直白：国际化最常被引用的目标之一，就是让人们能正确拼写自己的名字；由于许多邮箱本地部分反映的正是个人姓名，这条原则同样适用于邮箱地址。

4. 行长限制与 Message-ID

RFC 5322 第 2.1.1 节把行长限制为 998 个字符，并建议控制在 78 个字符以内。本规范把前者改为 998 个字节——在 ASCII 下字节与字符等同，但在 UTF-8 下并非如此；而 78 的建议值仍以字符计，因为它针对的是显示宽度而非行长本身。

对 Message-ID，规范提示实现者可以选择把生成结果限制在 ASCII 范围内。这样做有实际好处：在邮件列表线索中，当部分发送者使用国际化地址、部分不使用时，构造 In-Reply-To 与 References 头字段会更简单可靠。

5. MIME 编码限制的放宽与 message/global

RFC 2045 原本禁止对 message/ 的任何子类型施加内容传输编码。本规范放宽了这一规则：允许新定义的 MIME 类型许可内容传输编码，并允许对 message/global 使用内容传输编码。

放宽的原因是降级路径：message/global 通常在 8 位干净的通道上传输、各分段使用恒等编码；但当一封含 message/global 的邮件按 RFC 6152 从 8 位降级到 7 位时，就不得不施加某种编码。若邮件在 7 位环境与本扩展环境之间往返多次，还可能出现多层嵌套编码。规范认为这种情况实践中罕见，且允许嵌套编码的复杂度低于其他处理方式。

关于 encoded-word：MIME 的 encoded-word 机制只能在本扩展允许位置的一个子集中放置非 ASCII 文本，而且因为允许任意字符集而显著更复杂。因此在生成采用本扩展的邮件头字段时，不应当使用 encoded-word；代理在引用其他邮件的内容时，可以把 encoded-word 用法转换为直接使用 UTF-8。

6. 部署提醒

国际化邮件是一个需要全链路支持的特性：发送方 MTA 必须通告并使用 SMTPUTF8，接收方必须能存储与展示 UTF-8 头字段，中间的过滤、归档与合规系统也要能正确解析。链路上任一环节不支持，都可能导致退信或乱码。

从安全角度看，允许 Unicode 出现在地址与显示名中，也带来了同形异义字（confusable）冒充的风险——外观相近的不同码点可用于伪造知名域名或人名，这需要在展示层与检测层单独处理。

参考：https://www.rfc-editor.org/rfc/rfc6532.txt