摘要

  • SMTPUTF8 把 SMTP 信封里的邮箱名和邮件头值扩展到 UTF-8，但每台服务器必须先声明能力；声明 SMTPUTF8 的服务器还必须支持并声明 8BITMIME。
  • 域名可以依照 IDNA 转为 A-label，非 ASCII 本地部分却没有通用等价物。路径中断时，诚实选择是提交边界上的授权转换、另选路径、重试或失败，而不是捏造邮箱。

看得见的姓名还不是投递地址

MIME 早已能让收件人看到自己文字体系里的姓名与主题，但显示名只是 ASCII 地址周围的说明。RFC 6530 明确指出，这些显示信息对 SMTP 信封不可见，通常也不是地址的一部分。

IDNA 解决了 @ 右侧的国际化域名。传统 SMTP 左侧的本地部分仍限于 ASCII，并由最终投递系统解释。Unicode 域名可以转换成 DNS 可查询的 A-label；本地部分却没有标准音译或编码能保证指向同一邮箱。随意替换，可能无人接收，也可能送给另一个人。

完整地址的国际化因此不是字体升级，而是路径能力问题。只有能保留该名字的路线，才有资格把它当作目的地。

标准轨架构放弃了诱人的中途降级

RFC 6530 取代 RFC 4952，并记录实验性的途中降级方案已经不再需要，应转为 Historic。中间中继没有足够权限替国际化邮箱创造 ASCII 身份，这是架构转向的核心。

2012 年 2 月发布的标准轨文档分配了不同责任：RFC 6531 定义 SMTP 扩展；RFC 6532 允许适当的邮件头值直接使用 UTF-8；RFC 6533 让投递与处置通知保留国际化原始收件人。

这不是一张全局翻译表，而是一套让信封、邮件头和失败证据都指向同一地址的协同环境。

一个 EHLO 关键字承担完整承诺

服务器以 SMTPUTF8 宣布能力。IANA SMTP 服务扩展注册表 将其登记为国际化电子邮件地址支持，不带 EHLO 参数。

没有参数不等于模糊。RFC 6531 要求宣布该关键字的服务器完全符合本版规范，并同时支持、宣布 8BITMIME。8BITMIME 负责正文中的高位字节保管；SMTPUTF8 扩展信封地址与承载身份的邮件头。后者依赖八位洁净环境，却没有取代前者。

客户端可在 MAIL FROM 上添加无值的 SMTPUTF8 参数，表示信封含非 ASCII 地址、消息属于国际化格式，或某部分需要该扩展。@、引号与其他 SMTP 分隔规则仍在，扩展的是允许字符的范围。

路径成为可达性的组成条件

收到能力声明后，客户端才可发送国际化邮箱名与 RFC 6532 邮件头。没有声明时，两者都不得发送，即使国际化邮件头藏在嵌套 MIME 结构中也不行。

同一个邮箱因而可能经一个 MX 可达、经另一个 MX 暂时不可达。尝试备用 MX 或稍后重试，是寻找能忠实运输该名字的路径，并不是地址本身发生了变化。

邮件提交代理拥有较大的处置空间，因为作者仍处于这个边界。若系统掌握由账户方明确配置的 ASCII 别名，可以生成普通 RFC 5321 邮件。RFC 6531 没有规定这种转换，也没有授权途中中继自行音译。

没有合法转换或可用路线时，系统应拒绝、生成合规退信、重新排队或尝试适当的备用主机。失败保留了“这条路带不了这个名字”和“邮箱不存在”的差别。

UTF-8 进入字段值，字段名仍是 ASCII

RFC 6532 允许 Subject、地址本地部分、引号字符串、域名与部分 Message-ID 结构直接包含 UTF-8；邮件头字段名本身仍限 ASCII。

行长也暴露字符与字节的不同。硬上限变为 998 个八位字节，因为一个 UTF-8 字符可能占多个字节；面向显示的 78 字符建议仍按字符计算。一个保护运输容量，另一个保护可读性。

Unicode 规范化同样不能替中继创造身份等价。RFC 6532 建议 NFC，并在可能丢失拼写差异时反对 NFKC。最终投递系统仍掌握本地部分的解释权。

失败通知必须保留真正失败的名字

若退信无法说明哪个国际化收件人失败，这套地址就无法运维。RFC 6533 因此定义 UTF-8 地址类型和适用于 ORCPT、DSN 的表示，其中包括可在七位环境中保存证据的编码形式。

这叫保存，不叫降级。把原始收件人编码进通知，是为了保住失败对象的证据，并没有创造一个能够接收原邮件的 ASCII 邮箱。宣布 SMTPUTF8 与 DSN 的服务器必须实现 RFC 6533，避免失败报告丢失关联对象。

运输能力不是邮箱产权

SMTPUTF8 证明服务器能解析并搬运一类字符串。它不证明邮箱存在、某人拥有该邮箱、两个视觉相似名字等价、域名可信或最终软件会安全显示所有字符。

持久的治理边界正是拒绝把兼容能力膨胀成身份权力。域名持有人管理 DNS，最终投递系统管理本地命名空间，源端可以配置可归责别名，中继只能原样运输或明确失败。任何一方都不能为了保持流程顺畅而发明替身。

来源与证据边界

架构来自 RFC 6530，SMTP 行为来自 RFC 6531，邮件头语法来自 RFC 6532，通知证据来自 RFC 6533，当前关键字记录来自 IANA SMTP 注册表。这些来源不能证明当代服务商支持率、全球可投递性、邮箱所有权或 Unicode 欺骗事故率。