EAI 国际化电子邮件 — RFC 6530-6533：SMTPUTF8、UTF-8 邮箱地址与 IDN 域名
一、邮件只能使用 ASCII 的历史包袱
自 RFC 821（1982 年）起，SMTP 协议规定邮件地址和头部字段只能使用 US-ASCII 字符集。这意味着：邮箱地址不能包含中文、日文、阿拉伯文或带变音符的拉丁字母；邮件主题和发件人显示名虽然可以通过 MIME 编码（RFC 2047）传递非 ASCII 文本，但底层地址始终是 ASCII。
这对全球 70% 以上的非英语母语用户造成了实质性的可用性障碍。用户不得不记忆并分发纯 ASCII 地址（如
zhangsan@example.com
），而非其母语地址（如
张三@例子.中国
）。
IETF 于 2012 年发布了 EAI（Email Address Internationalization）框架——RFC 6530、6531、6532、6533 四份标准——从协议层面对 SMTP、邮件头部格式和 DSN 送达通知进行了 UTF-8 扩展。这是自 RFC 2821 以来 SMTP 协议最具野心的变革。
二、EAI 标准体系分解
| RFC | 标题 | 核心内容 |
|---|---|---|
| RFC 6530 | Overview and Framework | EAI 整体框架、术语定义、设计原则与向后兼容策略 |
| RFC 6531 | SMTP Extension for Internationalized Email | SMTPUTF8 扩展关键字、国际化邮箱地址的 SMTP 传输 |
| RFC 6532 | Internationalized Email Headers | 邮件头部字段的 UTF-8 编码：From、To、Subject 等原生支持非 ASCII |
| RFC 6533 | Internationalized Delivery Status and Disposition Notifications | DSN/MDN 的国际字符集支持 |
| RFC 6855 | IMAP Support for UTF-8 | IMAP UTF8=ACCEPT 能力，在邮箱名/文件夹名中使用 UTF-8 |
| RFC 6856 | POP3 Support for UTF-8 | POP3 协议的 UTF8 用户/密码支持 |
| RFC 6857 | Post-Delivery Message Downgrading for I18n Email | 将 UTF-8 邮件向下转换为纯 ASCII 格式（降级） |
| RFC 6858 | Simplified POP/IMAP Downgrading | POP/IMAP 场景下的邮件降级 |
RFC 6530 第 1 节定义了两个关键术语：
- 国际邮件消息（Internationalized Email Message） ：包含至少一个 UTF-8 头部字段或 UTF-8 正文的邮件
- SMTPUTF8 感知 MTA ：在 EHLO 响应中声明 SMTPUTF8 关键字，并能处理 UTF-8 地址的 MTA
EAI 的设计遵循 渐进式部署 理念：不强制全球邮件基础设施同步升级。支持 EAI 的节点通过 SMTPUTF8 声明能力；不支持的老旧 MTA 接受 ASCII-only 邮件，EAI 邮件通过降级网关转换。
三、SMTPUTF8：SMTP 协议扩展
RFC 6531 第 2.1 节定义的 SMTPUTF8 是对 ESMTP 的扩展。启用方式如下：
# SMTP 会话示例
S: 220 mx1.example.com ESMTP Postfix
C: EHLO sender.example.org
S: 250-mx1.example.com
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-SMTPUTF8 ← 声明支持 UTF-8 地址
S: 250 STARTTLS
C: MAIL FROM:<张三@例子.中国> SMTPUTF8 ← 使用 UTF-8 地址
S: 250 2.1.0 Ok
C: RCPT TO:<李四@测试.公司>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with .
C: From: =?UTF-8?B?5byg5LiJ?= <张三@例子.中国>
C: To: 李四 <李四@测试.公司>
C: Subject: =?UTF-8?B?5rWL6K+V?= ← MIME 编码仍保留
...
RFC 6531 第 3.3 节规定，当 MAIL FROM 包含非 ASCII 字符时，必须同时传递 SMTPUTF8 参数。这是一个协议级别的安全阀——如果接收 MTA 不支持 SMTPUTF8，它会拒绝该 MAIL FROM 命令，发送方 MTA 就可以选择降级或退信。
3.1 IDN 域名与 EAI 的协作
EAI 地址中的域部分使用的是 U-label（Unicode 域名） 而非 A-label（Punycode）。RFC 5890-5895（IDNA2008）定义了 Unicode 域名的规范化规则。
DNS 层面仍然使用 Punycode（A-label）：
# 用户看到的地址
张三@例子.中国
# DNS 查询时使用 Punycode
例子.中国 → xn--fsq270a.xn--fiqs8s
# MX 记录查询：
dig xn--fsq270a.xn--fiqs8s MX
RFC 6531 第 4 节要求 SMTPUTF8 MTA 在内部使用 U-label，但在 DNS 查询时自动转换为 A-label。这个转换对上层透明。
四、Postfix SMTPUTF8 配置
Postfix 从 3.0 版本开始完整支持 SMTPUTF8。以下为典型配置：
# /etc/postfix/main.cf
# 启用 SMTPUTF8 支持
smtputf8_enable = yes
# 允许 UTF-8 邮箱地址
strict_8bitmime = no
strict_8bitmime_body = no
# SMTPUTF8 自动降级配置
smtputf8_autodetect_classes = all
send_cyrus_sasl_authzid = no
# 对于不支持 SMTPUTF8 的外发目的地
# 配置降级网关（可选）
smtp_delivery_status_filter = pcre:/etc/postfix/dsn_filter
Dovecot 侧的 IMAP UTF-8 配置（RFC 6855）：
# /etc/dovecot/conf.d/20-imap.conf
imap_capability = +UTF8=ACCEPT
# 允许 UTF-8 文件夹名
mail_utf8_extensions = yes
昆仑邮件系统自 昆仑 3.0 起完整支持 SMTPUTF8，覆盖收发、归档和 Webmail 全链路，满足政府机构和跨国企业的国际化邮件需求。
五、降级策略：当 SMTPUTF8 不可用时
EAI 框架最大的挑战不是 EAI-to-EAI 通信（双方都支持 SMTPUTF8 时一切顺畅），而是 EAI-to-ASCII 通信。RFC 6857（Post-Delivery Message Downgrading）和 RFC 6858（POP/IMAP Downgrading）提供了一套标准化的降级方案。
5.1 降级的三个层面
| 层面 | 原始形式 | 降级后 |
|---|---|---|
| 邮箱地址 |
张三@例子.中国
|
zhangsan@xn--fsq270a.xn--fiqs8s
（ASCII 别名映射）
|
| 头部显示名 |
From: 张三 <...>
|
From: =?UTF-8?B?5byg5LiJ?= <...>
（MIME 编码）
|
| 邮件正文 | UTF-8 原样 | Content-Type: text/plain; charset=UTF-8 不变 |
RFC 6857 第 3 节规定降级网关的行为：
- 将 UTF-8 头部字段（非 ASCII 字节）全部 MIME 编码
- 将 EAI 邮箱地址替换为预设的 ASCII 别名（alternate address）
-
在降级后的邮件中插入
Downgraded-From:头部，保留原始 UTF-8 地址供 EAI 客户端还原
5.2 ASCII 别名映射策略
降级机制的关键在于 ASCII 别名表。常见策略：
# /etc/postfix/eai_aliases
张三@例子.中国 zhangsan@example.com
李四@测试.公司 lisi@example.com
support@帮助.中国 support@example.com
别名表需要管理员维护，确保：(a) 别名全局唯一，(b) 降级地址能正常收发，(c) 降级地址的反向映射（ASCII-to-UTF8）在 EAI 接收方可还原。
5.3 与 SPF/DKIM/DMARC 的交互
降级过程涉及 MIME 重组，会破坏原始 DKIM 签名。RFC 6376 第 5.3 节指出任何 MIME 结构变更都导致 DKIM 验证失败。因此降级网关 必须在签名之前完成降级处理 ，或由降级网关自行重新签名。
DMARC 的对齐（Alignment）基于 5322.From 域。降级后 From 头部被 MIME 编码但不影响域部分——对齐仍然保留。
六、总结
EAI 将邮件从 ASCII 牢笼中解放出来。RFC 6530-6533 体系与 RFC 6855-6858 的 IMAP/POP 扩展，构建了从 SMTP 传输、邮件存储到客户端访问的完整 UTF-8 支持链。
当前（2026 年）的 EAI 部署现状：Postfix 3.0+、Exim 4.86+、Google Gmail、Microsoft Exchange Online 均已支持 SMTPUTF8 收发。但仍有大量老旧 MTA（尤其是企业内部邮件网关）不支持，降级网关在过渡期内不可或缺。
对于新部署邮件系统的组织，建议：(a) 默认启用 SMTPUTF8，(b) 提前规划 ASCII 别名映射，(c) 在 DMARC 报告中监控 EAI 降级对 DKIM 通过率的影响，(d) 优先使用 Postfix 3.9+ 的内置 smtputf8_enable 支持，减少自定义降级脚本的维护成本。
参考文献：
[1] IETF RFC 6530 — Overview and Framework for Internationalized Email, February 2012
[2] IETF RFC 6531 — SMTP Extension for Internationalized Email, February 2012
[3] IETF RFC 6532 — Internationalized Email Headers, February 2012
[4] IETF RFC 6533 — Internationalized Delivery Status and Disposition Notifications, February 2012
[5] IETF RFC 6855 — IMAP Support for UTF-8, March 2013
[6] IETF RFC 6856 — Post Office Protocol Version 3 (POP3) Support for UTF-8, March 2013
[7] IETF RFC 6857 — Post-Delivery Message Downgrading for Internationalized Email Messages, March 2013
[8] IETF RFC 6858 — Simplified POP/IMAP Downgrading for Internationalized Email, March 2013
[9] IETF RFC 5890-5895 — Internationalized Domain Names for Applications (IDNA2008), August 2010
[10] GB/T 30282-2013 — 信息安全技术 反垃圾邮件产品技术要求和测试评价方法