跳到主要内容

RFC 6531 - SMTP 扩展以支持国际化电子邮件地址

  • 状态: Proposed Standard
  • 发布日期: February 2012
  • Stream: IETF
  • 废弃了: RFC5336
  • 勘误: 无勘误

文档信息​

  • RFC Number: 6531
  • Title: SMTP Extension for Internationalized Email
  • Authors: J. Yao, W. Mao
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 5336
  • ISSN: 2070-1721

摘要​

本文档规定了一个 SMTP 扩展, 用于传输和投递包含国际化电子邮件地址或头部信息的电子邮件消息.

本文档状态​

本文档是一份 Internet 标准轨道 (Standards Track) 文档.

本文档是互联网工程任务组 (Internet Engineering Task Force, IETF) 的产物. 它代表了 IETF 社区的共识. 它已经过公开评审, 并已由互联网工程指导组 (Internet Engineering Steering Group, IESG) 批准发布. 有关 Internet 标准的更多信息, 请参见 RFC 5741 的第 2 节.

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

版权声明​

版权所有 (c) 2012 IETF Trust 以及被标识为文档作者的个人. 保留所有权利.

本文档受 BCP 78 以及在本文档发布之日有效的 IETF Trust 关于 IETF 文档的法律条款 (Legal Provisions Relating to IETF Documents) (http://trustee.ietf.org/license-info) 的约束. 请仔细审阅这些文档, 因为它们描述了您对本文档所享有的权利和受到的限制. 从本文档中提取的代码组件必须包含 Trust 法律条款第 4.e 节所述的简化 BSD 许可证 (Simplified BSD License) 文本, 并且按照简化 BSD 许可证的规定在不提供任何担保的情况下提供.

本文档可能包含 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献中的材料. 控制此类材料中部分内容版权的个人可能未授予 IETF Trust 允许在 IETF 标准流程之外修改此类材料的权利. 在未从控制此类材料版权的个人处获得充分许可的情况下, 本文档不得在 IETF 标准流程之外进行修改, 也不得在 IETF 标准流程之外创建其衍生作品; 但为将其格式化以作为 RFC 发布, 或为将其翻译为英语以外的其他语言而进行的处理除外.

目录​

  1. 引言
  2. 操作概述
  3. 邮件传输层协议
  4. IANA 考虑
  5. 安全考虑
  6. 致谢
  7. 参考文献

1. 引言​

本文档定义了一个简单邮件传输协议 (Simple Mail Transfer Protocol, SMTP) [RFC5321] 扩展, 使服务器能够通告其接受并处理国际化电子邮件地址 (见第 1.1 节) 和国际化电子邮件头部 [RFC6532] 的能力.

关于国际化电子邮件地址和电子邮件头部的扩展模型的一个更详尽的概述出现在 RFC 6530 [RFC6530] 中, 在本规范中将其称为 "框架文档" (the framework document). 要理解并实现本规范, 必须透彻理解该文档以及 Internet 电子邮件基础规范 [RFC5321] [RFC5322] 中的信息.

1.1. 术语​

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 [RFC2119] 中的描述进行解释.

术语 "UTF-8 字符串" 或 "UTF-8 字符" 用于指代 Unicode 字符, 这些字符可能是也可能不是 ASCII 子集的成员, 它们以 UTF-8 [RFC3629] (一种标准的 Unicode 编码形式) 表示. 本规范中使用的所有其他专门术语都在框架文档或 Internet 电子邮件基础规范中定义. 特别地, 本文档中使用的术语 "ASCII 地址" (ASCII address)、"国际化电子邮件地址" (internationalized email address)、"非 ASCII 地址" (non-ASCII address)、"SMTPUTF8"、"国际化消息" (internationalized message) 和 "消息" (message) 均按照框架文档 [RFC6530] 中的定义使用.

本文档中提及的字符串, 包括 ASCII 字符串, 都必须 (MUST) 以 UTF-8 表示.

本规范使用扩充巴科斯范式 (Augmented BNF, ABNF) 规则 [RFC5234]. 本文档中的一些基本规则在第 3.3 节中被标识为已在 RFC 5234 [RFC5234]、RFC 5321 [RFC5321]、RFC 5890 [RFC5890] 或 RFC 6532 [RFC6532] 中定义 (使用相同的名称).

1.2. 对其他规范的变更​

本规范扩展了 RFC 5321 中定义的一些语法规则, 并允许在信封 (envelope) 和跟踪字段 (trace field) 中使用国际化电子邮件地址, 但它不修改 RFC 5321. 它允许使用 RFC 6532 [RFC6532] 中定义的数据格式, 但不修改 RFC 5322. 它确实要求支持 SMTPUTF8 的 SMTP 服务器 (SMTPUTF8-aware SMTP server) 通告 8BITMIME 扩展 [RFC6152], 并且支持 SMTPUTF8 的 SMTP 客户端 (SMTPUTF8-aware SMTP client) 使用 "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 应答中禁止 (MUST NOT) 包含该关键字的任何参数. 支持 SMTPUTF8 的 SMTP 客户端必须 (MUST) 忽略该关键字出现的任何参数; 也就是说, 支持 SMTPUTF8 的 SMTP 客户端必须表现得如同这些参数没有出现一样. 如果一个 SMTP 服务器在其 EHLO 应答中包含 SMTPUTF8, 则它必须完全遵从本规范的这一版本.

  4. 向 MAIL 命令添加了一个可选 (OPTIONAL) 参数 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. 提供本扩展的服务器必须 (MUST) 支持并通告 8BITMIME 扩展 [RFC6152].

  9. SMTP 的 MAIL 和 RCPT 命令的 reverse-path 和 forward-path 被扩展为允许在邮箱名称 (地址) 中使用以 UTF-8 编码的 Unicode 字符.

  10. 邮件消息正文按照 RFC 6532 [RFC6532] 的规定进行扩展.

  11. SMTPUTF8 扩展在提交端口 (submission port) [RFC6409] 上是有效的. 它也可以与本地邮件传输协议 (Local Mail Transfer Protocol, LMTP) [RFC2033] 一起使用. 当使用这些协议时, 其使用情况应当 (should) 适当地反映在跟踪字段的 WITH 关键字中 [RFC3848].

3.2. SMTPUTF8 扩展​

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

在响应 EHLO 命令而接收到 SMTPUTF8 扩展关键字后, SMTP 客户端可以 (MAY) 在 SMTP 命令中以 UTF-8 形式的国际化字符串传输邮箱名称. 它可以发送 UTF-8 头部 [RFC6532] (其中也可以包含以 UTF-8 表示的邮箱名称). 它可以在 SMTP 命令或消息头部中以 A-label 或 U-label [RFC5890] 的形式传输邮箱名称的域部分. SMTPUTF8 扩展的存在不会改变 RFC 5321 中描述的服务器中继行为.

如果 SMTP 服务器未提供 SMTPUTF8 SMTP 扩展, 则支持 SMTPUTF8 的 SMTP 客户端禁止 (MUST NOT) 传输国际化电子邮件地址, 并且禁止 (MUST NOT) 在其 MIME 结构 [RFC2045] 的任何层次内传输包含 RFC 6532 [RFC6532] 所述的国际化邮件头部的邮件消息. (对于本段而言, 按照 IDNA 定义 [RFC5890] 的以 A-label 形式表示的国际化域名不被视为 "国际化的".) 相反, 如果一个支持 SMTPUTF8 的 SMTP 客户端 (发送方) 尝试传输一条国际化消息, 但遇到一个不支持该扩展的 SMTP 服务器, 那么它应采取的最佳行动取决于其他条件. 特别地:

  • 如果它是消息提交代理 (Message Submission Agent, MSA) [RFC6409] [RFC5598], 它可以 (MAY) 以自己的方式处理这种情形, 利用 RFC 6409 允许的在更改地址或以其他方式修补和转换消息方面的广泛自由裁量权. 只要最终得到的消息符合 RFC 5321 的要求 (即不带 SMTPUTF8 扩展), 这种转换的细节就不在本文档的讨论范围之内.

  • 如果它不是 MSA, 或者它是 MSA 但没有选择将该消息转换为不需要 SMTPUTF8 扩展的消息, 那么它应当 (SHOULD) 拒绝该消息. 与往常一样, 这既可以通过在 SMTP 事务期间生成适当的应答来完成, 也可以通过接受该消息然后生成并发送一份未投递通知 (non-delivery notification) 来完成. 如果选择后者, 该通知过程必须 (MUST) 符合 RFC 5321、RFC 3464 [RFC3464] 和 RFC 6533 [RFC6533] 的要求.

  • 按照 RFC 5321 第 2.2.3 节的规定, 拥有额外信息和/或了解特殊情况知识的 SMTP 客户端可以 (MAY) 选择将该消息重新排队并稍后重试, 和/或按照该节的规定尝试另一个备用 MX 主机.

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

如果支持 SMTPUTF8 的 SMTP 服务器通告投递状态通知 (Delivery Status Notification, DSN) [RFC3461] 扩展, 则它必须 (MUST) 实现 RFC 6533 [RFC6533].

3.3. 扩展的邮箱地址语法​

RFC 5321 第 4.1.2 节完全以 ASCII 字符的形式定义了 <Mailbox> 的语法. 本文档扩展了 <Mailbox>, 以增加对非 ASCII 字符的支持.

本规范所做的主要变更包括:

  • 从 RFC 5321 导入 <Mailbox> ABNF 规则并加以更新, 以支持国际化电子邮件地址. 其他相关规则从 RFC 5321、RFC 5234、RFC 5890 和 RFC 6532 导入, 或在本文档中进行扩展.

  • <sub-domain> 的定义被扩展为同时允许 RFC 5321 的定义和符合 IDNA 定义 [RFC5890] 的 DNS 标签中的 UTF-8 字符串.

  • <atext> 的定义被扩展为同时允许 RFC 5321 的定义和 UTF-8 字符串. 该字符串禁止 (MUST NOT) 包含任何 ASCII 图形字符或控制字符.

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

  • <Mailbox>
  • <Local-part>
  • <Dot-string>
  • <Quoted-string>
  • <QcontentSMTP>
  • <Domain>
  • <Atom>

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

  • <UTF8-non-ascii>

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

  • <DQUOTE>

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

  • <U-label>

以下规则按照如下方式在 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 客户端必须 (MUST) 在 MAIL 命令中提供 SMTPUTF8 参数. 如果提供了该参数, 它禁止 (MUST NOT) 接受值. 如果支持 SMTPUTF8 的 SMTP 客户端确知信封和正在发送的消息都不需要任何 SMTPUTF8 扩展能力, 那么它不应 (SHOULD NOT) 在 MAIL 命令中提供 SMTPUTF8 参数.

由于无法保证下一跳的 SMTP 服务器会支持 SMTPUTF8 扩展, 因此使用 SMTPUTF8 扩展总是带有传输失败的风险. 事实上, 在 SMTPUTF8 扩展部署的早期阶段, 这种风险会相当高. 因此, 对于仅含 ASCII 的消息而言, 在近期内不使用本扩展发送具有明显的优势. 将 ASCII [ASCII] 字符 (0x7f 及以下) 视作 UTF-8 形式的长期优势在于, 它允许纯 Unicode 的环境.

3.5. 非 ASCII 地址与应答码​

支持 SMTPUTF8 的 SMTP 客户端禁止 (MUST NOT) 向不支持 SMTPUTF8 的 SMTP 服务器发送国际化消息. 如果 SMTP 服务器不支持该选项, 那么支持 SMTPUTF8 的 SMTP 客户端可以按照本规范第 3.2 节的规定在三种做法中进行选择.

本节中使用的三位数字应答码 (reply-code) 基于其在 RFC 5321 中定义的含义.

当消息因为 RCPT 命令要求 ASCII 地址而被拒绝时, 返回应答码 553, 含义为 "mailbox name not allowed" (邮箱名称不被允许). 当消息因为 MAIL 命令要求 ASCII 地址而被拒绝时, 返回应答码 550, 含义为 "mailbox unavailable" (邮箱不可用). 当支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态码 (enhanced mail system status codes) [RFC3463] 时, 使用应答码 "X.6.7" [RFC5248] (见第 4 节), 含义为 "Non-ASCII addresses not permitted for that sender/recipient" (该发件人/收件人不允许使用非 ASCII 地址).

当消息因其他原因被拒绝时, 服务器遵循 RFC 5321 这一电子邮件基础规范的模型; 本扩展不改变这些情形或应答消息.

如果一条消息在 DATA 命令的最后的 "." 之后被拒绝, 原因是一个或多个接收者无法接受和处理带有国际化电子邮件头部的消息, 则使用应答码 "554", 含义为 "Transaction failed" (事务失败). 如果支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态码 [RFC3463], 则使用应答码 "X.6.9" [RFC5248] (见第 4 节) 来指示这种情况, 含义为 "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected" (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-bit 数据具有足够的处理能力, 但它并不要求 MIME 消息中存在 RFC 2045 所规定的非 ASCII 正文部分. SMTPUTF8 扩展可以 (MAY) 按如下方式使用 (假设就正文内容而言是恰当的):

  • 与 BODY=8BITMIME 参数 [RFC6152] 一起使用, 或者

  • 与 BODY=BINARYMIME 参数一起使用, 前提是该 SMTP 服务器通告了 BINARYMIME [RFC3030].

3.7. 其他 ESMTP 变更与澄清​

邮件传输过程中所携带的信息, 除了 MAIL 和 RCPT 命令及其扩展的替代形式之外, 还涉及在各种上下文中的地址 ("邮箱") 和域名. 一般规则是: 当 RFC 5321 规定了一个邮箱时, 本 SMTP 扩展要求对整个字符串使用 UTF-8 形式. 当 RFC 5321 规定了一个域名时, 如果支持 SMTPUTF8 扩展, 则国际化域名应当 (SHOULD) 采用 U-label 形式; 否则, 它应当采用 A-label 形式.

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

3.7.1. 初始 SMTP 交换​

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

3.7.2. 邮件交换器​

如果使用多个 DNS MX 记录为一个域指定多个服务器 (如 RFC 5321 [RFC5321] 第 5 节所述), 则强烈建议这些服务器要么全部、要么全不应当 (SHOULD) 支持 SMTPUTF8 扩展. 否则, 在发生临时或永久性故障时可能会出现意外的拒绝, 用户可能将其视为严重的可靠性问题.

3.7.3. 跟踪信息​

跟踪信息 <Return-path-line>、<Time-stamp-line> 及其相关规则定义于 RFC 5321 [RFC5321] 第 4.4 节. 本文档更新了 <Mailbox> 和 <Domain> 以支持非 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 参数传输的消息添加跟踪字段时, 该服务器应当 (SHOULD) 在新跟踪字段中对国际化域名使用 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 客户端必须 (MUST) 能够接受并处理它们. 如果给定的 MAIL 命令不包含 SMTPUTF8 参数, 则支持 SMTPUTF8 的 SMTP 服务器禁止 (MUST NOT) 返回包含非 ASCII 邮箱的 251 或 551 应答. 相反, 它必须 (MUST) 将这样的应答转换为不包含非 ASCII 地址的 250 或 550 应答.

3.7.4.2. VRFY 和 EXPN 命令与 SMTPUTF8 参数​

如果 SMTPUTF8 参数与 VRFY 和 EXPN 命令一起传输, 则它表明 SMTP 客户端能够在对这些命令的应答中接受 UTF-8 字符串. SMTPUTF8 参数与 VRFY 和 EXPN 命令一起使用时, 应当 (SHOULD) 只在 SMTP 客户端看到带有 SMTPUTF8 关键字的 EHLO 应答之后进行. 这使得支持 SMTPUTF8 的 SMTP 服务器能够在应答中出现的邮箱名称和全名中使用 UTF-8 字符串, 而无需担心 SMTP 客户端可能会被它们搞混. 符合本规范的 SMTP 客户端必须 (MUST) 接受并正确处理包含 UTF-8 字符串的 VRFY 和 EXPN 命令应答. 然而, 如果 SMTP 客户端没有通过在 VRFY 和 EXPN 命令中传输该参数来明确允许这样的应答, 那么支持 SMTPUTF8 的 SMTP 服务器禁止 (MUST NOT) 在应答中使用 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 服务器必须 (MUST) 使用应答码 252 或 550. RFC 5321 [RFC5321] 中定义的应答码 252 意为 "Cannot VRFY user, but will accept the message and attempt the delivery" (无法验证用户, 但将接受该消息并尝试投递). RFC 5321 [RFC5321] 中同样定义的应答码 550 意为 "Requested action not taken: mailbox unavailable" (未执行所请求的操作: 邮箱不可用). 当支持 SMTPUTF8 的 SMTP 服务器支持增强邮件系统状态码 [RFC3463] 时, 使用如下所述的增强应答码. 将 SMTPUTF8 参数与 VRFY 或 EXPN 命令一起使用, 仅为该命令启用 UTF-8 应答.

如果返回了正常的成功应答 (即 250), 该应答可以 (MAY) 包含用户的全名, 并且必须 (MUST) 包含用户的邮箱. 它必须 (MUST) 采用以下两种形式之一:

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 节), 意为 "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client" (需要包含 UTF-8 字符串的应答来显示邮箱名称, 但 SMTP 客户端不允许这种形式的应答).

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

尽管按照本节规定的规则, 在应答中表示电子邮件地址需要用到 UTF-8 字符串, 但本扩展不允许将 UTF-8 字符串用于任何其他目的. 支持 SMTPUTF8 的 SMTP 服务器禁止 (MUST NOT) 在应答中包含非 ASCII 字符, 本节中明确允许的有限情形除外.

4. IANA 考虑​

4.1. SMTP 服务扩展注册表​

IANA 已经按照如下数据, 向 "Mail Parameters" 注册表的 "SMTP Service Extension" 注册表添加了一个新值 "SMTPUTF8":

KeywordsDescriptionReference
SMTPUTF8Internationalized email address[RFC6531]

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

本文档中的代码定义按照本文档第 3.5 节和第 3.7.4.2 节的指引, 并基于 RFC 5248 [RFC5248], 取代了 RFC 5336 中规定的定义. IANA 已经使用如下数据更新了 "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry":

Code: X.6.7 Sample Text: Non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.9 Sample Text: UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.

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

IANA 已经在 "Mail Transmission Types" 注册表下的 "WITH protocol types" 子注册表中修改或添加了如下条目.

WITH protocol typesDescriptionReference
UTF8SMTPESMTP with SMTPUTF8[RFC6531]
UTF8SMTPAESMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8SMTPSESMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8SMTPSAESMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]
UTF8LMTPLMTP with SMTPUTF8[RFC6531]
UTF8LMTPALMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8LMTPSLMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8LMTPSALMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]

5. 安全考虑​

框架文档 [RFC6530] 中扩展的安全考虑讨论在这里同样适用.

更多的安全考虑在下面讨论:

除了在电子邮件全局系统内部 (在 SMTP 信封和消息头部中) 的使用之外, 国际化电子邮件地址还会出现在其他一些场景中, 特别是:

  • 用于监控电子邮件系统的 SMTP 事务日志系统和其他日志;

  • 安全团队用于管理安全事件的故障工单系统, 当涉及到电子邮件地址时;

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

另一个需要考虑的安全方面, 与安全团队成员在追踪事件时能否从日志中快速理解、阅读和识别电子邮件地址的能力有关. 应当 (SHALL) 实现能够自动并快速地提供国际化电子邮件地址的来源或归属信息的机制, 供那些难以阅读非 ASCII 信息的日志阅读者使用.

SMTP 命令 VRFY 和 EXPN 有时会用在没有消息需要传输的 SMTP 事务中 (由在识别出潜在垃圾邮件时采取自动操作的工具使用). RFC 5321 的第 3.5 节和第 7.3 节对这类使用和可能的行为给出了详细的描述. 国际化地址的实现也可能影响这些工具的日志和操作.

6. 致谢​

本文档基于电子邮件地址国际化 (Email Address Internationalization, 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. 规范性参考文献​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

  • [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.

  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

7.2. 资料性参考文献​

  • [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

  • [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

作者地址

Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58813007 EMail: [email protected]

Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58812230 EMail: [email protected]

相关资源​

  • 官方文本: https://www.rfc-editor.org/rfc/rfc6531.txt
  • 官方页面: https://datatracker.ietf.org/doc/html/rfc6531