跳到主要内容

7. 协议扩展与变更概述

7.1 国际化电子邮件地址的 SMTP 扩展​

一项名为 "SMTPUTF8" 的 SMTP 扩展规定如下:

  • 允许电子邮件地址的本地部分和域名使用 UTF-8 字符串.

  • 允许在电子邮件消息首部中有选择地使用 UTF-8 字符串, 见第 7.2 节.

  • 要求服务器通告 8BITMIME 扩展 [RFC6152], 并要求客户端支持 8 位传输, 从而无需特殊的内容传输编码即可传送首部信息.

若干通用原则影响了这项工作背后的开发决策:

  1. 电子邮件地址会进入可能执行字符集转换或其他编码变更的子系统, 例如用户界面. 如果地址的本地部分包含 ASCII 字符表之外的字符, 则不鼓励对域部分使用 ASCII 兼容编码(ACE) [RFC3492] [RFC5890], 以促进整个地址中的字符得到一致处理.

  2. SMTP 中继 MUST 采取以下一种做法:

    • 显式识别该格式, 并通过 ESMTP 选项同意这样做.
    • 拒绝消息, 或在必要时返回未投递通知消息, 让发件人能够另作安排.

  3. 如果由于下一跳系统无法接受该扩展而不能转发消息, 则该消息 MUST 被拒绝, 或者当前系统 MUST 生成并发送未投递消息.

  4. 为了实现互操作, 通过 Internet 传输的邮件地址和消息首部禁止使用 UTF-8 以外的字符集. 如果不引入极大复杂性, 就没有实际可行的方法通过类似扩展正确标识多个字符集.

要符合这里规定的电子邮件传输和投递标准组, 实现必须实现 SMTP 扩展规范和 UTF-8 首部规范. 如果系统实现 IMAP 或 POP, 则分别 MUST 符合国际化 IMAP [RFC5738bis-IMAP] 或 POP [RFC5721bis-POP3] 规范.

7.2 以 UTF-8 编码传输电子邮件首部字段​

在 MUA 或用户所见内容中, 电子邮件地址或域名会出现在许多位置. 例如传统的 "From:", "To:" 和 "Cc:" 首部字段, 通常包含域名的 "Message-ID:" 和 "In-Reply-To:" 首部字段(但它们可能属于特殊情况), 以及消息正文. 必须从国际化角度检查其中每个位置. 用户期望看到以本地字符表示的邮箱名和域名, 而且期望它们始终保持一致. 如果使用协议特定的 ACE 变体等不直观编码, 用户就难免会偶尔看到这些编码而不是 "本族" 字符, 并因此感到不适或惊讶. 同样, 如果邮件传输和消息正文采用不同编码, 根据由来已久的 "事物总会泄漏" 原则, 用户尤其容易遇到意外. 无论从中期还是长期看, 避免这些问题的唯一实际方法, 都是让传输使用的编码尽可能接近消息首部和消息正文使用的编码.

电子邮件本地部分国际化时, SHOULD 同时作出安排, 使消息首部采用完全国际化形式. 这种形式 SHOULD 使用 UTF-8 而不是 ASCII 作为首部字段内容的基础字符集. 首部字段名称本身等协议元素不作变更, 仍完全采用 ASCII. 为了过渡并兼容旧式系统, 可以扩展传统 MIME 的非 ASCII 首部字符编码模型 [RFC2045] [RFC2231], 但即使采用这种方式, 也应尽可能以 UTF-8 而不是其他编码为基础 [RFC6055]. 不过, 目标是 [RFC6532] 所讨论的完全国际化消息首部, 而不是延长并增加痛苦的过渡过程.

7.3 用于 DSN 的 SMTP 服务扩展​

现有的投递状态通知 (DSNs) 规范 [RFC3461] 是草案标准, 其协议中机器可读的部分仅限于 ASCII 文本. "国际化投递与处置通知" [RFC6533] 为国际化电子邮件地址增加了新的地址类型, 以便在降级之后仍能正确保留含有非 ASCII 字符的原始收件人地址. 如果 SMTP 服务器同时通告 SMTPUTF8 和 DSN 扩展, 则该服务器 MUST 实现国际化 DSN, 包括对 RFC 3461 [RFC3461] 规定的 ORCPT 参数的支持.