非官方中文译本声明：本页为 IETF RFC 6531《SMTP Extension for Internationalized Email（国际化电子邮件的 SMTP 扩展）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6531。

RFC 6531：国际化 SMTP 扩展

标准跟踪（Standards Track）· J. Yao（姚健康）、W. Mao（毛伟）· CNNIC · 2012 年 2 月 · 取代 RFC 5336 · 类别：Standards Track · ISSN: 2070-1721

摘要

本文档规定了一种 SMTP 扩展，用于传输和投递带有国际化电子邮件地址或国际化报文头信息的电子邮件消息。

本备忘录的状态

本文档是互联网标准跟踪（Internet Standards Track）文档。

本文档是互联网工程任务组（IETF）的产物，代表了 IETF 社区的共识，已通过公开评审，并经互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息见 RFC 5741 第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc6531 获取。

Copyright (c) 2012 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含 Simplified BSD License 文本（如信托法律条款第 4.e 节所述），并按该许可证所描述的方式"不附担保"地提供。

目录

1. 引言

本文档定义了简单邮件传输协议 [RFC5321] 的一种扩展，使服务器能够通告其接受和处理国际化电子邮件地址（见第 1.1 节）以及国际化电子邮件报文头 [RFC6532] 的能力。

关于国际化电子邮件地址与电子邮件报文头扩展模型的扩展概述，见 RFC 6530 [RFC6530]，在本规范中称之为"框架文档"。要理解并实施本规范，必须透彻理解该文档以及基础互联网电子邮件规范 [RFC5321]、[RFC5322] 中的信息。

1.1. 术语

本文件中关键词 "MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"MAY（可以）"和 "OPTIONAL（可选）"应按 RFC 2119 [RFC2119] 中的描述进行解释。

"UTF-8 字符串"或"UTF-8 字符"用于指代采用 UTF-8 [RFC3629]（一种标准的 Unicode 编码形式）表示的 Unicode 字符，这些字符可能是也可能不是 ASCII 子集的成员。本规范中使用的所有其他专门术语均在框架文档或基础互联网电子邮件规范中定义。特别地，本文件中"ASCII 地址""国际化电子邮件地址""非 ASCII 地址""SMTPUTF8""国际化消息"以及"消息"等术语，均依据框架文档 [RFC6530] 中的定义使用。

本文件中提及的字符串（包括 ASCII 字符串）必须以 UTF-8 表示。

本规范使用增广 BNF（ABNF）规则 [RFC5234]。本文件中某些基本规则在第 3.3 节中被指明为（以相同名称）定义于 RFC 5234 [RFC5234]、RFC 5321 [RFC5321]、RFC 5890 [RFC5890] 或 RFC 6532 [RFC6532]。

1.2. 对其他规范所做的修改

本规范扩展了 RFC 5321 中定义的某些语法规则，并允许在信封和跟踪字段中使用国际化电子邮件地址，但它并未修改 RFC 5321。它允许 RFC 6532 [RFC6532] 中定义的数据格式，但并未修改 RFC 5322。它确实要求支持 SMTPUTF8 的 SMTP 服务器通告 8BITMIME 扩展 [RFC6152]，并要求支持 SMTPUTF8 的 SMTP 客户端配合 "BODY=8BITMIME" 使用它，但它并未以任何方式修改 8BITMIME 规范。

本规范取代了一种较早的、实验性的、解决同一问题的方法 [RFC5336]。RFC 6530 [RFC6530] 的第 6 节描述了 RFC 5336 [RFC5336] 与本规范之间在方法上的变化。任何试图将实现从实验性规范转换到本文档规范的人，都需要仔细审阅这些变化。

2. 运行概述

本文档规定了电子邮件国际化工作中的一个要素，具体而言，是定义了一种用于国际化电子邮件的 SMTP 扩展。该扩展以关键字 "SMTPUTF8" 标识。

国际化电子邮件报文头规范 [RFC6532] 提供了本扩展所启用的电子邮件报文头特性的细节。

3. 邮件传输层协议

3.1. 国际化扩展框架

定义了以下服务扩展：

  1. 该 SMTP 服务扩展的名称为"国际化电子邮件（Internationalized Email）"。
  2. 与此扩展关联的 EHLO 关键字值为 "SMTPUTF8"。
  3. 未为该 EHLO 关键字值定义任何参数值。为了容许将来（尽管难以预料）的扩展，EHLO 应答不得包含该关键字的任何参数。支持 SMTPUTF8 的 SMTP 客户端必须忽略该关键字若出现的任何参数；也就是说，支持 SMTPUTF8 的 SMTP 客户端必须表现得如同这些参数并未出现。如果某 SMTP 服务器在其 EHLO 应答中包含 SMTPUTF8，则它必须完全符合本规范的此版本。
  4. 向 MAIL 命令添加一个可选参数 SMTPUTF8。该参数不接受值。若在 MAIL 命令中设置此参数，则表明 SMTP 客户端是支持 SMTPUTF8 的。它的存在还断言：信封包含非 ASCII 地址、所发送的消息是国际化消息，或者所发送的消息需要 SMTPUTF8 支持。
  5. MAIL 命令行的最大长度增加了 10 个字符，以容纳可能添加的 SMTPUTF8 参数。
  6. 向 VERIFY（VRFY）和 EXPAND（EXPN）命令添加一个可选参数 SMTPUTF8。SMTPUTF8 参数不接受值。该参数表明 SMTP 客户端能够接受 VRFY 和 EXPN 命令应答中以 UTF-8 编码的 Unicode 字符。
  7. 本扩展未定义任何额外的 SMTP 动词。
  8. 提供此扩展的服务器必须提供支持并通告 8BITMIME 扩展 [RFC6152]。
  9. SMTP MAIL 与 RCPT 命令的反向路径（reverse-path）与正向路径（forward-path）被扩展为允许在邮箱名（地址）中使用以 UTF-8 编码的 Unicode 字符。
  10. 邮件消息正文按 RFC 6532 [RFC6532] 的规定进行扩展。
  11. SMTPUTF8 扩展在邮件提交端口 [RFC6409] 上有效。它也可以与本地邮件传输协议（LMTP）[RFC2033] 一起使用。当使用这些协议时，其用法应如适用地反映在跟踪字段的 WITH 关键字中 [RFC3848]。

3.2. SMTPUTF8 扩展

通告了 SMTPUTF8 扩展的 SMTP 服务器必须做好准备，在 RFC 5321 指定 可以出现的任何位置接受一个 UTF-8 字符串 [RFC3629]。尽管 中的字符允许包含非 ASCII 字符，但对 的实际解析以及所用分隔符与基础电子邮件规范 [RFC5321] 相比没有改变。任何要在 DNS 中查找的域名必须符合并作为应用程序国际化域名（IDNA）[RFC5890] 所规定的方式进行处理。在进行查找时，支持 SMTPUTF8 的 SMTP 客户端或服务器必须使用支持 Unicode 的 DNS 库，或者按照 RFC 5890 [RFC5890] 的规定将国际化域名转换为 A-label 形式（即包含一个或多个 A-label 但不含 U-label 的完全限定域名）。

在收到对 EHLO 命令的应答中包含 SMTPUTF8 扩展关键字的 SMTP 客户端，可以 UTF-8 形式的国际化字符串在 SMTP 命令中传输邮箱名。它可以发送 UTF-8 报文头 [RFC6532]（其中也可能包含 UTF-8 形式的邮箱名）。它可以在 SMTP 命令或消息报文头中以 A-label 或 U-label [RFC5890] 形式传输邮箱名的域部分。SMTPUTF8 扩展的存在不改变 RFC 5321 中描述的服务器中继行为。

如果 SMTP 服务器未提供 SMTPUTF8 SMTP 扩展，支持 SMTPUTF8 的 SMTP 客户端不得传输国际化电子邮件地址，也不得传输在其 MIME 结构 [RFC2045] 的任何层级包含国际化邮件报文头的邮件消息。（就本段而言，IDNA 定义 [RFC5890] 中规定的 A-label 形式的国际化域名不被视为"国际化"。）相反，如果支持 SMTPUTF8 的 SMTP 客户端（发送方）试图传输国际化消息，却遇到不支持该扩展的 SMTP 服务器，它采取的最佳行动取决于其他条件。特别地：

本规范适用于支持 SMTPUTF8 扩展的支持 SMTPUTF8 的 SMTP 客户端或服务器。对于所有其他情况，以及不需要 SMTPUTF8 扩展的地址和消息，支持 SMTPUTF8 的 SMTP 客户端和服务器不改变 RFC 5321 [RFC5321] 中规定的行为。

如果支持 SMTPUTF8 的 SMTP 服务器通告了投递状态通知（DSN）[RFC3461] 扩展，则它必须实现 RFC 6533 [RFC6533]。

3.3. 扩展的邮箱地址语法

RFC 5321 第 4.1.2 节完全以 ASCII 字符定义了 的语法。本文档对 进行了扩展，以增加对非 ASCII 字符的支持。

本规范所做的关键变更包括：

以下从 RFC 5321 第 4.1.2 节导入的 ABNF 规则被本文档直接或者间接更新：

以下 ABNF 规则将从 RFC 6532 第 3.1 节直接导入：

以下 ABNF 规则将从 RFC 5234 附录 B.1 直接导入：

以下 ABNF 规则将从 RFC 5890 第 2.3.2.1 节直接导入：

以下规则在 ABNF [RFC5234] 中按如下方式扩展：

   sub-domain   =/  U-label
    ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

   atext   =/  UTF8-non-ascii
    ; extend the implicit definition of atext in
    ; RFC 5321, Section 4.1.2, which ultimately points to
    ; the actual definition in RFC 5322, Section 3.2.3

   qtextSMTP  =/ UTF8-non-ascii
    ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

   esmtp-value  =/ UTF8-non-ascii
    ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. MAIL 命令参数用法

如果所发送的信封或消息需要 SMTPUTF8 扩展的能力，支持 SMTPUTF8 的 SMTP 客户端必须随 MAIL 命令提供 SMTPUTF8 参数。如果提供了此参数，它不得接受值。如果支持 SMTPUTF8 的 SMTP 客户端知道所发送的信封和消息都不需要 SMTPUTF8 扩展的任何能力，则它不应随 MAIL 命令提供 SMTPUTF8 参数。

由于无法保证下一跳 SMTP 服务器会支持 SMTPUTF8 扩展，使用 SMTPUTF8 扩展始终带有传输失败的风险。事实上，在 SMTPUTF8 扩展部署的早期阶段，这一风险会相当高。因此，对于纯 ASCII 消息而言，不使用此扩展进行发送具有明显的近期优势。将 ASCII [ASCII] 字符（0x7f 及以下）以 UTF-8 形式表达的长期优势在于，它允许纯 Unicode 环境。

3.5. 非 ASCII 地址与应答码

支持 SMTPUTF8 的 SMTP 客户端不得向不支持 SMTPUTF8 的 SMTP 服务器发送国际化消息。如果 SMTP 服务器不支持此选项，则支持 SMTPUTF8 的 SMTP 客户端根据本规范第 3.2 节有三种选择。

本节所用的三位数字应答码基于其在 RFC 5321 中定义的含义。

当消息因 RCPT 命令需要一个 ASCII 地址而被拒绝时，返回应答码 553，含义为"邮箱名不允许（mailbox name not allowed）"。当消息因 MAIL 命令需要一个 ASCII 地址而被拒绝时，返回应答码 550，含义为"邮箱不可用（mailbox unavailable）"。当支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态代码 [RFC3463] 时，使用应答码 "X.6.7" [RFC5248]（见第 4 节），含义为"该发送方/接收方不允许使用非 ASCII 地址"。

当消息因其他原因被拒绝时，服务器遵循 RFC 5321 中基础电子邮件规范的模式；本扩展不改变那些情况或应答消息。

如果在 DATA 命令最后的 "." 之后，由于一个或多个收件人无法接受并处理带有国际化电子邮件报文头的消息而导致消息被拒绝，则使用应答码 "554"，含义为"事务失败（Transaction failed）"。如果支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态代码 [RFC3463]，则使用应答码 "X.6.9" [RFC5248]（见第 4 节）来指示此状况，含义为"UTF-8 报文头消息无法传输到一个或多个收件人，因此必须拒绝该消息"。

鼓励支持 SMTPUTF8 的 SMTP 服务器在 RCPT 命令之后（而非等到 DATA 命令之后才）检测收件人无法接受国际化消息并生成错误。

3.6. 正文部分与 SMTP 扩展

MAIL 命令参数 SMTPUTF8 断言某消息是国际化消息，或者所发送的消息需要 SMTPUTF8 支持。仍然存在这样的可能：通过带有 SMTPUTF8 参数的 MAIL 命令发送的消息并非国际化消息。需要准确知晓某消息是否国际化的支持 SMTPUTF8 的 SMTP 客户端或服务器，需要解析消息中所有的报文头字段以及 MIME 报文头字段 [RFC2045]。

然而，本规范不要求支持 SMTPUTF8 的 SMTP 客户端或服务器检查消息。

尽管本规范要求支持 SMTPUTF8 的 SMTP 服务器支持 8BITMIME 扩展 [RFC6152]，以确保服务器具备充分的 8 位数据处理能力，但它并不要求 RFC 2045 所规定的 MIME 消息中存在非 ASCII 正文部分。SMTPUTF8 扩展可按如下方式使用（假设就正文内容而言是适当的）：

3.7. 其他 ESMTP 变更与澄清

邮件传输过程中承载的信息，除了 MAIL 和 RCPT 命令及其扩展替代形式外，还涉及不同上下文中的地址（"邮箱"）和域名。一般规则是：当 RFC 5321 指定一个邮箱时，此 SMTP 扩展要求对整个字符串使用 UTF-8 形式；当 RFC 5321 指定一个域名时，如果该国际化域名支持 SMTPUTF8 扩展，则应采用 U-label 形式，否则应采用 A-label 形式。

以下小节列出并讨论了所有相关情形。

3.7.1. 初始 SMTP 交换

当打开一个 SMTP 连接时，SMTP 服务器发送一个由 220 应答码和某些信息组成的"问候（greeting）"应答。随后 SMTP 客户端发送 EHLO 命令。由于 SMTP 客户端在收到对 EHLO 的应答之前无法知道 SMTP 服务器是否支持 SMTPUTF8，支持 SMTPUTF8 的 SMTP 客户端在 EHLO 命令中必须只发送 ASCII（LDH 标签或 A-label [RFC5890]）域名。如果支持 SMTPUTF8 的 SMTP 服务器在 EHLO 应答中提供域名，则它们必须采用 LDH 标签或 A-label 的形式。

3.7.2. 邮件交换器

如果使用多条 DNS MX 记录为一个域指定多个服务器（如 RFC 5321 [RFC5321] 第 5 节所述），强烈建议它们要么全部、要么都不支持 SMTPUTF8 扩展。否则，在临时性或永久性故障期间可能发生意外的拒绝，用户可能会将其视为严重的可靠性问题。

3.7.3. 跟踪信息

跟踪信息 、 及其相关规则在 RFC 5321 [RFC5321] 第 4.4 节中定义。本文档更新了 和 以支持非 ASCII 字符。当使用 SMTPUTF8 扩展时，Return-path-line 的 'Reverse-path' 子句可以包含使用 U-label 形式的国际化域名。同样，Time-stamp-line 的 'Stamp' 子句可以包含使用 U-label 形式的国际化域名。

如果包含跟踪字段的消息是由支持 SMTPUTF8 的 SMTP 客户端或中继服务器发送，但 MAIL 命令中未包含 SMTPUTF8 参数，则无论 SMTP 服务器的能力如何，跟踪字段值必须符合 RFC 5321。

当支持 SMTPUTF8 的 SMTP 服务器向已传输或将要传输、且在 MAIL 命令中包含了 SMTPUTF8 参数的消息添加跟踪字段时，该服务器应在新的跟踪字段中对国际化域名使用 U-label 形式。

使用此扩展时，'WITH' 子句的协议值是本文档"IANA 考量"一节中规定的 SMTPUTF8 值之一。

3.7.4. UTF-8 字符串在应答中

3.7.4.1. MAIL 命令

如果某个 SMTP 客户端遵循本规范并发送了任何包含 SMTPUTF8 参数的 MAIL 命令，则允许支持 SMTPUTF8 的 SMTP 服务器在关联于 251 和 551 应答码的电子邮件地址中使用 UTF-8 字符，并且 SMTP 客户端必须能够接受并处理它们。如果某条给定的 MAIL 命令不包含 SMTPUTF8 参数，则支持 SMTPUTF8 的 SMTP 服务器不得返回包含非 ASCII 邮箱的 251 或 551 应答。相反，它必须将这些应答转换为不含非 ASCII 地址的 250 或 550 应答。

3.7.4.2. VRFY 与 EXPN 命令以及 SMTPUTF8 参数

如果随 VRFY 和 EXPN 命令传输了 SMTPUTF8 参数，则表明 SMTP 客户端能够接受这些命令应答中的 UTF-8 字符串。随 VRFY 和 EXPN 命令使用此参数，应仅在 SMTP 客户端看到包含 SMTPUTF8 关键字的 EHLO 应答之后进行。这使得支持 SMTPUTF8 的 SMTP 服务器能够在应答中出现的邮箱名和全名里使用 UTF-8 字符串，而不必担心 SMTP 客户端会被它们弄糊涂。符合本规范的 SMTP 客户端必须接受并正确处理包含 UTF-8 字符串的 VRFY 和 EXPN 命令应答。然而，如果 SMTP 客户端未通过随 VRFY 和 EXPN 命令传输此参数来明确允许此类应答，则支持 SMTPUTF8 的 SMTP 服务器不得在应答中使用 UTF-8 字符串。

大多数应答不需要在返回的文本中包含邮箱名，因此其中不需要 UTF-8 字符串。一些应答，特别是成功执行 VRFY 和 EXPN 命令所产生的应答，确实包含邮箱。

VERIFY（VRFY）与 EXPAND（EXPN）命令语法变更为：

   vrfy = "VRFY" SP String
     [ SP "SMTPUTF8" ] CRLF
    ; String may include Non-ASCII characters

   expn = "EXPN" SP String
     [ SP "SMTPUTF8" ] CRLF
    ; String may include Non-ASCII characters

SMTPUTF8 参数不接受值。如果对 VRFY 或 EXPN 命令的应答需要 UTF-8 字符串，但 SMTP 客户端未使用 SMTPUTF8 参数，则支持 SMTPUTF8 的 SMTP 服务器必须使用应答码 252 或 550。RFC 5321 [RFC5321] 定义的应答码 252 含义为"无法 VRFY 用户，但将接受消息并尝试投递"。同样在 RFC 5321 [RFC5321] 中定义的应答码 550 含义为"未采取请求的动作：邮箱不可用"。当支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态代码 [RFC3463] 时，使用如下指定的增强应答码。在 VRFY 或 EXPN 命令中使用 SMTPUTF8 参数仅为该命令启用 UTF-8 应答。

如果返回了正常的成功应答（即 250），则该应答可以包含用户的全名，且必须包含用户的邮箱。它必须采用以下两种形式之一：

   User Name <Mailbox>
    ; Mailbox is defined in Section 3.3 of this document.
    ; User Name can contain non-ASCII characters.

   Mailbox
    ; Mailbox is defined in Section 3.3 of this document.

如果 SMTP 应答需要 UTF-8 字符串，但应答中不允许使用 UTF-8 字符串，且支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态代码 [RFC3463]，则增强应答码为 "X.6.8" [RFC5248]（见第 4 节），含义为"需要包含 UTF-8 字符串的应答来显示邮箱名，但 SMTP 客户端不允许该形式的应答"。

如果 SMTP 客户端不支持 SMTPUTF8 扩展，却收到应答中的 UTF-8 字符串，它可能无法向用户正确报告该应答，并且某些客户端可能会错误处理该应答。仅在以上所述情形下，才允许在应答中使用国际化消息。

尽管根据本节的规则，需要在应答中表示电子邮件地址时需要使用 UTF-8 字符串，但此扩展不允许将 UTF-8 字符串用于任何其他目的。支持 SMTPUTF8 的 SMTP 服务器不得在本节明确允许的有限情形之外，在应答中包含非 ASCII 字符。

4. IANA 考量

4.1. SMTP 服务扩展注册表

IANA 已根据以下数据，向"邮件参数（Mail Parameters）"注册表中的"SMTP 服务扩展（SMTP Service Extension）"注册表添加了一个新值 "SMTPUTF8"：

关键字描述参考文献
SMTPUTF8国际化电子邮件地址[RFC6531]

4.2. SMTP 增强状态代码注册表

本文档中的代码定义取代了 RFC 5336 中规定的那些，遵循本规范第 3.5 节和第 3.7.4.2 节的指引，并基于 RFC 5248 [RFC5248]。IANA 已使用以下数据更新"简单邮件传输协议（SMTP）增强状态代码注册表（Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry）"：

代码示例文本关联基础状态码说明定义于提交者变更控制者
X.6.7 该发送方/接收方不允许使用非 ASCII 地址 550, 553 表示收到了一个使用非 ASCII 地址的 MAIL 或 RCPT 命令。 RFC 6531（标准跟踪） Jiankang YAO ima@ietf.org
X.6.8 需要 UTF-8 字符串应答，但 SMTP 客户端不允许 252, 550, 553 表示需要包含 UTF-8 字符串的应答来显示邮箱名，但 SMTP 客户端不允许该形式的应答。 RFC 6531（标准跟踪） Jiankang YAO ima@ietf.org
X.6.9 UTF-8 报文头消息无法传输到一个或多个收件人，因此必须拒绝该消息 550 表示在 DATA 命令最后的 "." 之后事务失败。 RFC 6531（标准跟踪） Jiankang YAO ima@ietf.org
X.6.10 这是 X.6.8 的重复，因此已弃用。

4.3. 邮件传输类型注册表下的 WITH 协议类型子注册表

IANA 已修改或添加了"邮件传输类型（Mail Transmission Types）"注册表下"WITH 协议类型（WITH protocol types）"子注册表中的以下条目：

WITH 协议类型描述参考文献
UTF8SMTP带 SMTPUTF8 的 ESMTP[RFC6531]
UTF8SMTPA带 SMTPUTF8 与 AUTH 的 ESMTP[RFC4954] [RFC6531]
UTF8SMTPS带 SMTPUTF8 与 STARTTLS 的 ESMTP[RFC3207] [RFC6531]
UTF8SMTPSA带 SMTPUTF8、STARTTLS 与 AUTH 的 ESMTP[RFC3207] [RFC4954] [RFC6531]
UTF8LMTP带 SMTPUTF8 的 LMTP[RFC6531]
UTF8LMTPA带 SMTPUTF8 与 AUTH 的 LMTP[RFC4954] [RFC6531]
UTF8LMTPS带 SMTPUTF8 与 STARTTLS 的 LMTP[RFC3207] [RFC6531]
UTF8LMTPSA带 SMTPUTF8、STARTTLS 与 AUTH 的 LMTP[RFC3207] [RFC4954] [RFC6531]

5. 安全考量

框架文档 [RFC6530] 中扩展的安全考量讨论在此同样适用。

下方讨论了更多安全考量：

除了在电子邮件全局系统（SMTP 信封与消息报文头）内部使用之外，国际化电子邮件地址还会出现在其他情形中，特别是：

为了避免可能导致数据丢失的问题，这很可能需要扩展这些系统以支持完整的 UTF-8，或者需要提供将非 ASCII 字符串映射到 ASCII 的适当机制。

另一个需要考虑的安全方面，关系到安全团队成员在追踪事件时，能否从日志中快速理解、读取并识别电子邮件地址。必须为难以阅读非 ASCII 信息的日志阅读者实现能够自动、快速地提供国际化电子邮件地址来源或归属的机制。

SMTP 命令 VRFY 和 EXPN 有时用于没有消息需要传输的 SMTP 事务中（被用于在识别出潜在垃圾邮件时采取自动化行动的工具所使用）。RFC 5321 第 3.5 节和第 7.3 节给出了关于用法与可能行为的详细描述。国际化地址的实现也可能影响这些工具的日志与行动。

6. 致谢

本文档基于电子邮件地址国际化（EAI）工作组讨论的结果修订了 RFC 5336 [RFC5336]。许多 EAI 工作组成员进行了测试与实现，推动本文档进入标准跟踪。来自 Xiaodong LEE、Nai-Wen HSU、Yangwoo KO、Yoshiro YONEYA 以及 JET 其他成员的重要意见与建议已被纳入本规范。来自工作组和设计团队许多成员的额外重要意见与建议，往往还有具体文字，也作出了贡献。这些贡献包括来自 John C. Klensin、Charles Lindsey、Dave Crocker、Harald Tveit Alvestrand、Marcos Sanz、Chris Newman、Martin Duerst、Edmon Chung、Tony Finch、Kari Hurtta、Randall Gellens、Frank Ellermann、Alexey Melnikov、Pete Resnick、S. Moonesamy、Soobok Lee、Shawn Steele、Alfred Hoenes、Miguel Garcia、Magnus Westerlund、Joseph Yee 和 Lars Eggert 的材料。当然，这些个人均不必然对本文件所体现的思想组合负责。

非常感谢 Dave Crocker 提出的意见以及对 ABNF 精炼的帮助。

7. 参考文献

7.1. 规范性参考文献

7.2. 资料性参考文献

作者地址

Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
China
电话：+86 10 58813007
电子邮箱：yaojk@cnnic.cn

Wei MAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
China
电话：+86 10 58812230
电子邮箱：maowei_ietf@cnnic.cn