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 字符, 本节中明确允许的有限情形除外.