1. 邮件国际化的层次模型

电子邮件的国际化并非单一技术特征，而是涉及五个不同协议层的系统性工程：字符编码层（邮件头和体的字符集声明）、传输层（SMTPUTF8 扩展和降级机制）、地址层（UTF-8 邮箱地址和 IDN 域名）、MIME 层（多语言消息体组合编码）以及客户端展示层（字体回退和编码检测）。RFC 4952（"Overview and Framework for Internationalized Email"）将这五层统称为 Email Address Internationalization (EAI) 框架，并定义了各层的互操作性要求 [1]。

对于部署面向中日韩（CJK）用户的邮件系统的运维团队，一个关键认识是：EAI 支持的优先级远高于 SMTPUTF8——即使用户使用纯 ASCII 邮箱地址，只要 Subject/From 显示名中包含 CJK 字符，邮件系统的 MIME 头编码和消息体编码就已是国际化部署的核心问题。

2. 多语言 MIME 头编码

2.1 RFC 2047 编码原理

RFC 2047 定义了在 RFC 5322 消息头中编码非 ASCII 文本的标准机制 [2]。其基本格式为 =?charset?encoding?encoded-text?=，其中 encoding 可以是 B（Base64）或 Q（Quoted-Printable）。对于 CJK 语言（UTF-8 编码的中日韩文），B 编码比 Q 编码空间效率更高，因为 CJK 字符在 UTF-8 中通常占用 3 字节，Q 编码对每个非 ASCII 字节使用 =XX 的 3 字符转义，与 B 编码的 4:3 Base64 膨胀率相比并无优势。

Subject: =?UTF-8?B?5L2g5aW977yM5LiW55WM?=
# 解码后："你好，世界"
# Subject 字段的 RFC 2047 编码步骤：
# 1. 将 "你好，世界" 转为 UTF-8 字节序列
# 2. 对字节序列执行 Base64 编码
# 3. 组装为 =?UTF-8?B?...base64...?=

RFC 2047 encoded-word 有长度限制——每行编码后的 encoded-word 不能超过 75 个字符。若原始文本较长（如包含多个收件人显示名的 To 字段），必须拆分为多个连续的 encoded-word，并在行间添加空格或 CRLF 空格（即 RFC 5322 的 folding white space）。拆分时需要注意不要跨字符边界截断 UTF-8 多字节序列，这是很多中文邮件在 Outlook 中显示乱码的常见原因。

2.2 RFC 2231 参数编码

RFC 2231 扩展了 MIME 头字段的参数值编码能力，主要适用于 Content-Disposition: attachment; filename= 和 Content-Type: name= 中的非 ASCII 文件名编码 [3]。RFC 2047 不能用于 MIME 参数值——这是一个经常被误解的技术限制。RFC 2231 的编码格式为：

Content-Disposition: attachment;
  filename*=UTF-8''%E4%B8%AD%E6%96%87%E6%96%87%E4%BB%B6.pdf

# 解码后 filename 为 "中文文件.pdf"
# 格式：charset'language'percent-encoded-text
# 其中百分号编码使用 RFC 3986 的 URI 百分号编码规则

RFC 2231 的性能开销在于它是"声明式"编码——接收方 MUA 必须解析参数值的字符集声明和百分号编码序列后才能还原文件名，比 RFC 2047 的 Base64 解码稍复杂。但 RFC 2231 的优势是向后兼容：不理解 RFC 2231 的客户端退化为采用未编码的部分或直接显示原始 ASCII 编码串。

2.3 RFC 6532 原生 UTF-8 头

RFC 6532 是 EAI 体系的核心组件，允许在邮件头中直接包含原生 UTF-8 文本，无需经过 RFC 2047 或 2231 编码 [4]。这在端到端 EAI 兼容的邮件流中显著降低了消息头的复杂度和解析开销。但需要强调的是：RFC 6532 仅在 SMTPUTF8-aware 的传输链中生效——一旦邮件经过不支持 SMTPUTF8 的 MTA 中继，发送 MTA 必须将原生 UTF-8 头降级编码为 RFC 2047 格式，这个过程在 RFC 6857 中有明确定义。

3. IDN 国际化域名配置

3.1 IDNA2008 标准体系

国际化域名（IDN）通过 Punycode 编码将非 ASCII 域名转换为 ACE（ASCII Compatible Encoding）标签。RFC 5890 定义了 IDNA2008 的术语框架，RFC 5891 定义了编码协议，RFC 5892 定义了 Unicode 字符的 IDN 适用性表，RFC 5893 专门处理包含中文字串的域名中的右左书写方向规则 [5][6][7]。

关键机制：

• U-label：用户可读的 Unicode 形式，如 昆仑邮件.cn
• A-label：ASCII 兼容的 Punycode 形式，以 xn-- 前缀标识，如 xn--2u0ap01i9t.cn
• 转换函数：ToASCII（U-label → A-label）和 ToUnicode（A-label → U-label），定义于 RFC 5891

3.2 邮件系统中 IDN 的处理流程

当 MTA 处理发往国际化域名的邮件时，需遵循以下协议流程：

1. MUA 从用户输入的 user@昆仑邮件.cn 中提取域名部分 昆仑邮件.cn
2. 将域名应用 ToASCII 转换，得到 xn--2u0ap01i9t.cn
3. 执行 MX 查询：xn--2u0ap01i9t.cn IN MX（DNS 系统中 IDN 域名的 MX 记录必须以 Punycode 形式存储）
4. 若 MTA 支持 SMTPUTF8，在 EHLO 中声明 SMTPUTF8 后可以使用原生 UTF-8 邮箱地址；若不支持，则信封（MAIL FROM/RCPT TO）使用 Punycode 域名
5. 支持 EAI 的 IMAP 服务器在 SEARCH/FETCH 返回时，允许使用原生 UTF-8 地址

Postfix 中的 IDN 支持依赖 libidn 库：

# Postfix main.cf - IDN 相关配置
# IDNA2008 作为默认 IDN 版本
smtputf8_enable = yes
# 启用前检查 libidn2 版本
ldconfig -p | grep libidn2

# IDN 域名的 MX 查询（Punycode 转换由 Postfix SMTP 客户端自动完成）
transport_maps = hash:/etc/postfix/transport
# transport 内容使用 U-label 而非 A-label：
# user@昆仑邮件.cn      smtp:[xn--2u0ap01i9t.cn]:25

4. 中日韩文邮件编码演进与对比

4.1 CJK 编码历史

中日韩三种语言的邮件编码经历了各自独立发展的三个阶段：

4.1 CJK 编码历史

时期	中文	日文	韩文	问题
1990s 早期	GB2312、HZ	ISO-2022-JP、Shift_JIS	EUC-KR、ISO-2022-KR	无法互发多语言邮件；MIME 编码膨胀率高
1990s 末-2000s	GBK、GB18030	EUC-JP、ISO-2022-JP with JIS X 0213	CP949 (UHC)、EUC-KR with KSC 5601	编码检测失败频繁；一个邮件可能包含多种编码导致乱码
2010s 至今	UTF-8 为主	UTF-8 为主	UTF-8 为主	UTF-8 统一编码解决了互操作问题

虽然 UTF-8 已成为现代邮件系统的默认编码，但处理遗留邮件归档时仍需理解历史编码格式。Dovecot 的 mail_attachment_dir 功能在归档存储中保留原始编码的邮件体，以便需要时进行编码转换。

4.2 Content-Type 编码声明策略

对于发送给国际收件人的多语言邮件，推荐的 Content-Type 声明策略：

# 方案 A（推荐）：使用 UTF-8 作为邮件体编码
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

# 方案 B（兼容遗留客户端）：使用 ISO-2022-JP 与 UTF-8 多部分组合
Content-Type: multipart/alternative;
  boundary="=_multipart_boundary"
--=_multipart_boundary
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
... (UTF-8 编码的邮件体)
--=_multipart_boundary
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
... (ISO-2022-JP 编码的日文备用体)
--=_multipart_boundary--

方案 A 适用于 EAI 兼容的客户端（Thunderbird、Roundcube）；方案 B 通过 multipart/alternative 为不支持 UTF-8 的遗留客户端提供备用编码版本。

5. Postfix SMTPUTF8 降级策略与兼容性

RFC 6857 定义了 EAI 邮件在传输链中遭遇非 SMTPUTF8 MTA 时的降级操作规范。核心原则是"信息损失最小化"——尽可能保留邮件的可读性和语义完整性，同时添加 Downgraded-* 消息头以标记降级操作。Postfix 中的降级流程由 smtputf8_autodetect_classes 参数控制，其值可以是 sendmail（本地投递）、smtp（远程投递）或两者的组合。

# 降级配置策略
# 仅对远程投递启用自动降级（推荐）
smtputf8_autodetect_classes = smtp

# 降级时保留原始消息头作为 Downgraded-From 记录
# 需要自定义 header_checks 规则
header_checks = pcre:/etc/postfix/header_checks

# /etc/postfix/header_checks 内容：
/^(Subject|From|To):/ INFO Downgraded-From:$&

6. 国际化部署实施清单

• 确认 Postfix 版本 ≥ 3.0 且编译时启用了 EAI 支持（postconf mail_version && postconf smtputf8_enable）
• 安装 libidn2 库并确认 IDN 表现为 IDNA2008 标准（vs 旧的 IDNA2003）
• 在 Dovecot 中启用 imap_capability = +UTF8=ACCEPT 并安装 ICU 库
• 测试 CJK 编码使用 swaks 工具模拟多语言邮件发送：

# 使用 swaks 发送 UTF-8 编码的国际化邮件
swaks --to 张三@昆仑邮件.cn \
  --from test@ztpop.net \
  --header "Subject: =?UTF-8?B?5Lit5paH5rWL6K+V?=" \
  --body "这是一封UTF-8编码的中文测试邮件" \
  --charset "UTF-8"

# 验证邮件投递情况和头部编码
swaks --to user@example.com \
  --attach-type text/plain \
  --attach-body /dev/stdin <<< "简体中文 / 日本語 / 한국어"