RFC 6532 – 国际化电子邮件头
ELI5: 在这个 RFC 之前，如果你想在电子邮件标头中写像"Müller"这样的名字或日语主题行，你必须将其编码成难以理解的混乱，比如`=?UTF-8?B?...?=`。RFC 6532 说"直接使用 UTF-8"。From 行可以用纯文本显示`田太郎 `，主题可以使用任何语言，无需编码技巧。电子邮件在网络上看起来和在屏幕上一样。
为什么存在这个RFC
原始电子邮件格式（RFC 5322）将标题字段限制为美国ASCII字符。要在主题、发件人显示名称或地址注释等标题中包含非ASCII文本，发件人必须使用RFC 2047编码字——这是一个繁琐的方案，对文本进行Base64或Q编码，并将其包装在=?charset?encoding?...?=标记中。
这个系统有效，但产生的标题在原始形式下不可读，难以正确实现，并且适用范围有限。例如，RFC 2047编码字不能用于电子邮件地址的本地部分。
RFC 6532更新了RFC 5322，允许在电子邮件标题中直接使用UTF-8。结合RFC 6531（SMTP信封的SMTPUTF8），这实现了完全国际化的电子邮件，其中地址、显示名称、主题和其他标题都可以使用本地脚本，无需编码处理。
工作原理
- 消息通过SMTP与
SMTPUTF8扩展（RFC 6531）传输，表示消息使用国际化内容。 - 标题字段可在RFC 5322允许的任何文本位置包含原始UTF-8八位字节。
- 标题中的电子邮件地址（From、To、Cc、Reply-To）可在本地部分和域部分包含UTF-8字符。
- 消息标题块的
Content-Type隐式为message/global（在RFC 6532中定义），而不是传统的message/rfc822。 - 支持RFC 6532的接收邮件客户端以本地形式显示标题。不支持的客户端可能显示原始UTF-8字节或无法解析标题。
标题示例
传统RFC 2047编码标题与RFC 6532标题的对比：
# 旧方式：RFC 2047编码字（在线路上不可读）
From: =?UTF-8?B?w4ltaWxpZSBEdXBvbnQ=?= <emilie@example.fr>
Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?=
To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <taro@example.jp>
# 新方式：RFC 6532原始UTF-8（人类可读）
From: Émilie Dupont <émilie@exemple.fr>
Subject: 会议的确认
To: 田太郎 <田太郎@例.jp>
一条完整的国际化消息：
From: 田太郎 <田太郎@例.jp>
To: Émilie Dupont <émilie@exemple.fr>
Subject: 会议的确认
Date: Wed, 11 Mar 2026 19:00:00 +0900
Message-ID: <20260311.001@例.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
确认下周的会议。
关键技术细节
message/global与message/rfc822
RFC 6532引入了一个新的MIME类型：message/global。这在功能上与message/rfc822相同，但表示消息可能在标题中包含UTF-8。当消息通过SMTPUTF8传输时，附加消息和转发消息应使用message/global而非message/rfc822：
| MIME类型 | 标题编码 | 用途 |
|---|---|---|
message/rfc822 |
仅ASCII（非ASCII使用RFC 2047） | 传统电子邮件 |
message/global |
本地允许UTF-8 | 国际化电子邮件 |
允许UTF-8的位置
RFC 6532允许在RFC 5322允许文本的所有标题字段位置使用UTF-8：
-
显示名称：
From: 田太郎 <taro@example.jp> -
地址本地部分：
To: <田太郎@example.jp> -
域名：
Cc: <user@例.jp> -
非结构化字段：
Subject: 会议的确认 -
注释：
From: user@example.com（山田太郎）
DKIM签名考虑
DKIM签名覆盖特定标题。当这些标题包含原始UTF-8时，签名和验证过程必须正确处理字节。DKIMh=标签列出要签名的标题，规范化应用于原始UTF-8字节。发件人和验证人都必须处理相同的字节序列，签名才能匹配。
向后兼容性
RFC 6532消息与仅理解RFC 5322的邮件系统不向后兼容。接收message/global消息但不支持RFC 6532的服务器或客户端可能会：
- 显示原始UTF-8字节（大多数现代客户端处理合理）
- 无法解析包含非ASCII字符的地址标题
- 如果实现不处理UTF-8标题，则破坏DKIM验证
常见错误
-
在信封中不使用SMTPUTF8的情况下使用RFC 6532标题。如果SMTP会话未使用
SMTPUTF8参数，消息必须使用RFC 2047编码字处理非ASCII标题内容。RFC 6532标题仅在通过RFC 6531发送时有效。 - 在同一标题中混合RFC 2047和原始UTF-8。每条消息选择一种方法。如果通过SMTPUTF8发送，使用原始UTF-8。否则，全程使用RFC 2047。混合它们会造成解析歧义。
-
对国际化附件使用message/rfc822。转发或附加包含UTF-8标题的消息时，使用
message/global作为MIME类型，而非message/rfc822。 - 忽视Unicode规范化。相同的视觉字符在Unicode中可以有多个字节表示。对电子邮件地址和标题内容一致地使用NFC规范化，以防止匹配和验证失败。
- 假设所有邮件客户端都能正确呈现UTF-8。虽然现代客户端处理UTF-8良好，但某些较旧或嵌入式邮件客户端可能不支持。对于关键事务电子邮件，考虑您的受众是否包括旧系统上的用户。
- 通过在传输中修改UTF-8标题来破坏DKIM。某些邮件处理系统规范化或重新编码UTF-8文本。对DKIM签名标题的任何修改，即使改变Unicode规范化形式，也会使签名失效。
传递能力影响
- 为国际收件人更好显示。本地脚本的显示名称和主题看起来专业且可信。标题中的编码字乱码会让收件人困惑并引发怀疑。
- DKIM必须正确处理UTF-8。如果DKIM实现签署UTF-8标题，而验证人处理方式不同（不同规范化、不同编码），签名失败。这直接影响DMARC对齐和传递能力。
- 不断增长的提供商支持。Gmail、Outlook.com和其他主要提供商支持RFC 6532标题。具有干净UTF-8标题的消息由这些提供商正确显示。
- 国际化地址必需。没有RFC 6532标题就无法拥有国际化电子邮件地址。随着EAI采用增长，支持此RFC对于接触全球用户至关重要。
-
后备策略很重要。为最大传递能力，生成
message/global版本（用于支持SMTPUTF8的服务器）和降级RFC 2047版本（用于其他服务器）。您的发送基础设施应根据接收者功能进行选择。