RFC 6530《国际化电子邮件：综述与框架》中文译本

IETF · RFC 6530 · 标准跟踪（Standards Track）· 2012 年 2 月

摘要

要在全世界范围内充分使用电子邮件，就要求人们（在其他约束条件允许的前提下）能够把与自己姓名相近的写法——以其本族语言与文字正确书写——用作电子邮件地址中的邮箱名。本文档引入了一系列规范，这些规范定义了完整支持国际化电子邮件地址所需的机制与协议扩展。这些变更包括一项 SMTP 扩展，以及对邮件头字段语法的扩展，以容纳 UTF-8 数据。本文档集还讨论了部署完全国际化电子邮件时的关键假设与相关问题。本文档是 RFC 4952 的替代文档，反映了该文档发布以来所识别出的更多问题。

本文档废止（Obsoletes）RFC 4952、RFC 5504 与 RFC 5825。

1. 引言

为使用国际化电子邮件地址，必须同时对电子邮件地址的域名部分（domain part）与本地部分（local part）实施国际化。地址的域名部分已经实现了国际化 [RFC5890]，而本地部分尚未国际化。若无本文档所规定的扩展，邮箱名将被限制在 7 比特 ASCII 的一个子集之内 [RFC5321]。虽然 MIME [RFC2045] 使得非 ASCII 数据的传输成为可能，但它并未为国际化电子邮件地址提供机制。在 RFC 2047 [RFC2047] 中，MIME 为某些特定的报文头字段定义了一种编码机制以容纳非 ASCII 数据；然而，它并不允许使用包含非 ASCII 字符的电子邮件地址。若没有此处所定义的扩展或某种等效的机制，要在电子邮件地址的任何部分中纳入非 ASCII 字符，唯一的办法就是使用 RFC 2047 编码，把它们嵌入到 RFC 5322 [RFC5322] 所称的相关头字段的「显示名」（display name，在其他场合也称为 "name phrase" 或其他术语）之中。而编码进显示名中的信息在报文信封（envelope）里是不可见的，并且就许多用途而言，它根本就不属于地址的一部分。

本文档是 RFC 4952 [RFC4952] 的替代文档；它反映了自该文档发布以来所识别出的更多问题、共享术语以及若干体系结构上的变更，并废止该文档。由于第 12 节所讨论的变更，关于传输途中降级（in-transit downgrading）的实验性描述 [RFC5504] [RFC5825] 现已不再相关、也不再需要。我们请求 RFC 编辑将上述三份文档全部移入「历史」（Historic）状态。

本文档中代词 "he" 与 "she" 交替使用，用以指代性别不确定的人。

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

2. 本规范的作用

本文档给出了电子邮件国际化进入下一阶段所采用方法的综述与框架。这一新阶段不仅要求对地址与头字段实施国际化，还要求对与之关联的传输与投递模型加以国际化。本规范的前一版本 RFC 4952 [RFC4952] 也曾对一系列实验性协议 [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] 作过介绍。本修订版则为上述协议中一部分协议的「标准跟踪」后继文档提供综述与概念性说明。这些文档的细节及其相互关系见第 5 节，而从实验性协议及其实现中所获得的经验教训则在第 6 节中讨论。

综合来看，这些规范给出了实现与支持国际化电子邮件的具体途径。本文档本身描述了电子邮件国际化的各个要素如何相互契合，以及与报文传输、头格式和处理相关的各项主要规范之间的关系。

本文档以及构成上述集合的其他文档，均假定读者对基本的 Internet 电子邮件规范与术语 [RFC5321] [RFC5322]，以及 MIME [RFC2045] 和 8BITMIME [RFC6152] 有合理程度的熟悉。虽然并非实现本规范的严格前提，但同样假定读者对 IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] 的术语与功能有总体了解。

3. 问题陈述

「应用程序中的国际化域名」（IDNA）[RFC5890] 允许使用国际化域名，但其部署尚未触及大多数用户。原因之一在于：我们尚未拥有完全国际化的命名方案。域名只是众多需要国际化的名称与标识符之一。在许多场景下，除非这些标识符中有更多实现了国际化，否则仅有国际化域名的价值十分有限。

电子邮件地址正是「仅把域名国际化并不足够」的绝佳例证。正如大多数观察者从经验中所了解到的，相比那些看似毫无意义的字母或数字串，用户强烈偏好与姓名或姓名缩写相似的电子邮件地址。除非整个电子邮件地址都能使用熟悉的字符与格式，否则用户会觉得电子邮件在文化上不够友好。如果电子邮件地址中所使用的姓名与缩写能够以用户的母语与书写系统来表达，那么 Internet 就会被视为更自然——对于那些母语并非以罗马字母派生文字的子集书写的人来说尤其如此。

电子邮件地址的国际化，绝不仅仅是改变 SMTP 信封，或修改 "From:"、"To:"、"Cc:" 头字段，或允许升级后的邮件用户代理（MUA）解码某种特殊编码并以本地字符显示这么简单。要让人感到可用，地址就必须在其出现的所有场景中都被国际化并被一致地处理。这一要求具有深远影响：一堆补丁与变通办法的拼凑是不够的。即便它们够用，基于变通办法的路线也可能造成各种实现应用了不同的补丁与变通组合，进而使用户对「究竟什么才真正可用、真正受支持」产生困惑。相反，我们需要构建一个完全国际化的电子邮件环境，着眼于让共享同一语言与书写系统的人们之间能够高效沟通。这反过来意味着：需要变更邮件头环境，使那些适宜国际化的头字段能够使用 Unicode 字符的完整范围；需要一项 SMTP 扩展，以允许 UTF-8 [RFC3629] [RFC5198] 的邮件寻址以及上述扩展头字段的投递；需要支持投递通知与服务通知的国际化 [RFC3461] [RFC3464]；并且（最后）需要以支持 8BITMIME SMTP 扩展 [RFC6152] 为前提，使所有这些内容都能在邮件系统中传输，而不必去克服「头字段没有内容传输编码（content-transfer-encoding）」这一限制。

4. 术语

本文档假定读者对 RFC 5321 [RFC5321] 与 RFC 5322 [RFC5322] 所记载的核心电子邮件标准的协议与术语有合理程度的理解。

4.1. 邮件用户代理与邮件传输代理

本文档中的大量描述依赖于「邮件传输代理」（Mail Transfer Agent，"MTA"）与「邮件用户代理」（Mail User Agent，"MUA"）这两个抽象概念。然而，重要的是要理解：这些术语及其背后的概念，晚于 Internet 电子邮件体系结构的设计以及「线上协议」（protocols on the wire）原则在其中的应用。随着该电子邮件体系结构的演进，它与「线上」原则一起，阻止了对「MTA 与 MUA 在给定的源主机或目的主机上如何交互（乃至它们是否彼此分离）」形成任何强有力的标准化区分。

不过，本文档中所使用的术语「最终投递 MTA」（final delivery MTA）等同于 RFC 5321 中的「投递系统」（delivery system）或「最终投递系统」（final delivery system）。它是控制地址本地部分格式、并被允许检视与解释这些本地部分的那台 SMTP 服务器。它从网络接收报文，用于投递到邮箱或进行其他本地处理，其中包括任何会改变信封地址的转发或别名处理，而不是中继（relaying）。从网络的角度看，任何本地投递安排——例如保存到报文存储、移交给特定的报文投递程序或代理，以及取回报文的机制——都位于最终投递 MTA 的「后面」，因而不属于 SMTP 传输或投递过程的一部分。

4.2. 地址字符集

在本文档中，若某地址中的每一个字符都属于 ASCII 字符集 [ASCII]，则该地址为「全 ASCII」（all-ASCII）地址，或简称「ASCII 地址」；若其中任一字符不属于 ASCII 字符集，则该地址为「非 ASCII」（non-ASCII）地址，或称「i18n 地址」（i18n-address）。此类地址可以（MAY）在其他方面受到限制，但那些限制与此处的定义无关。当区分很重要时，「全 ASCII」这一术语也适用于其他协议要素，其反义词为「非 ASCII」或「国际化的」（internationalized）。

用来描述本文档及其配套文档所规定的电子邮件地址国际化的总称术语是 "SMTPUTF8"。例如，本规范所允许的一个地址被称为「SMTPUTF8（合规）地址」。

请注意，按照此处给出的定义，所有「全 ASCII」地址构成的集合与所有「非 ASCII」地址构成的集合是互斥的。当出现 SMTPUTF8 时所允许的全部地址的集合，是这两个集合的并集。

4.3. 用户类型

「ASCII 用户」是指：（i）只使用仅包含 ASCII 字符的电子邮件地址，并且（ii）无法生成包含非 ASCII 字符的收件人地址的用户。

「国际化电子邮件用户」是指拥有一个或多个非 ASCII 电子邮件地址，或者能够生成包含非 ASCII 字符的收件人地址的用户。此类用户也可能同时拥有 ASCII 地址；如果该用户拥有不止一个电子邮件账户及相应地址，或同一地址有不止一个别名，那么他或她具备某种方法来选择在外发邮件中使用哪个地址。请注意，按照这一定义，无法仅凭一个 ASCII 地址判断该地址的所有者是否为国际化电子邮件用户。（而一个非 ASCII 地址则意味着可以认为该地址的所有者是国际化电子邮件用户。）并不存在所谓「国际化电子邮件用户报文」这样的东西；该术语仅适用于用户及其代理与能力。特别地，使用非 ASCII 的（因而大概是国际化的）报文内容，本就是 MIME 规范 [RFC2045] 不可分割的组成部分，并不需要这些扩展（尽管它与这些扩展是兼容的）。

4.4. 报文

「报文」（message）是指由一位用户（发送者）使用某个特定的电子邮件地址，发往一个或多个其他收件人电子邮件地址（常常径直称为「用户」或「收件用户」）的邮件。

4.5. 邮件列表

「邮件列表」（mailing list）是这样一种机制：通过把报文发送到某一个收件人地址，即可将其分发给多个收件人。位于该单一地址处的某个代理（通常不是人）随后促使该报文被重新分发给目标收件人。该代理会把重新分发后报文的信封返回地址设置为不同于原始单收件人报文的另一个地址。使用不同的信封返回地址（反向路径，reverse-path）会使差错报文（以及其他自动生成的报文）被送往一个专门的差错处理地址。

关于管理可能包含非 ASCII 地址的邮件列表的特别规定，在一份专门针对该主题的文档 [RFC5983] 及其预期的后继文档 [RFC5983bis-MailingList] 中讨论。

4.6. 常规报文与国际化报文

• 常规报文（conventional message）是指未使用本规范集合中的 SMTP 扩展文档 [RFC6531] 或 UTF8header 文档 [RFC6532] 所定义的任何扩展，并且严格符合 RFC 5322 [RFC5322] 的报文。
• 国际化报文（internationalized message）是指使用了本规范集合所定义的一项或多项扩展的报文，因而它不再符合电子邮件报文或其传输的传统规范。

4.7. 不可投递报文、通知与投递回执

正如 RFC 5321 所规定，因某种原因无法投递的报文应导致向发送者发出通知。这可以通过两种方式之一发生。其一通常称为「拒收」（Rejection），发生在 SMTP 服务器返回表示致命错误的应答码（"5yz" 码）或持续返回临时失败错误（"4yz" 码）之时。另一种方式则是在 SMTP 处理过程中先接受该报文，随后再生成一封发给发送者的报文，通常称为「未投递通知」（Non-delivery Notification，NDN）。当前实践往往更偏向拒收而非 NDN，因为这能降低 NDN 的生成被当作垃圾邮件手段加以利用的可能性。若某个中间 MTA 接受了一封随后被下一跳服务器拒收的报文，则后一种情形（即 NDN）就不可避免。

发送者也可以（MAY）显式请求报文回执 [RFC3461]，而这对于这些国际化扩展所引出的问题与 NDN 相同。

5. 方法概述与文档规划

本规范集合同时变更了 SMTP 与电子邮件报文头的字符编码，以允许直接表示非 ASCII 字符。这项工作的每一个重要组成部分都由一份单独的文档来描述。该文档集（其成员如下所述）还包含若干信息性（Informational）文档，其目的是为这些协议提供实现建议与指导。

除本文档之外，以下文档共同构成本规范，并为其提供建议与上下文。

• SMTP 扩展。SMTP 扩展文档 [RFC6531] 为国际化地址提供了一项 SMTP 扩展（如 RFC 5321 所规定的那样）。
• 以 UTF-8 表示的电子邮件报文头。电子邮件报文头文档 [RFC6532] 实质上更新了 RFC 5322，使得在使用上述 SMTP 扩展时，电子邮件报文头中的某些信息可以直接由以 UTF-8 编码的 Unicode 字符来表达。该文档（可能还需一份或多份补充文档）还需要处理与 MIME 的交互，包括 SMTPUTF8 与 MIME 内部头及内容类型之间的关系。
• 对投递状态与通知处理的扩展，以适应国际化地址 [RFC6533]。
• 即将发布的文档将规定对 IMAP 协议 [RFC3501] 的扩展以支持国际化报文头 [RFC5738bis-IMAP]，对 POP 协议的平行扩展 [RFC5721] [RFC5721bis-POP3]，以及两者的一些共同性质 [POPIMAP-downgrade]。

6. 实验结果回顾

本协议集合与先于它的实验性协议集合 [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] 之间的关键差异在于：早先那一组提供了一种报文的传输途中降级机制（在 RFC 5504 中有详细描述）。该机制允许——并且实质上要求——每一个非 ASCII 地址都伴随一个全 ASCII 的等价地址。这反过来又引发了与「无法被认证的地址配对」相关的安全顾虑。它还带来了多年来 Internet 邮件寻址方面的第一次不兼容变更，令人担心一旦新的地址形式「泄漏」到既有的旧式电子邮件实现中会引发互操作性问题。在考察了这些规范的早期实验性前身的实践经验之后，制定这些规范的工作组曾得出结论：如果传输途中降级在运营上确实可行，其优势将足以显著到可以压倒上述顾虑。

事实证明并非如此——初期的各个实现之间出现了互操作性问题。在着手开展导致本规范集合的工作之前，工作组得出结论：早先那一模型的各项要求与长期影响相互交织，过于复杂而难以令人满意，工作应当在不采用它的前提下继续推进。

对协议本身的另一项重要变更是：如果需要使用该扩展，现在要求由 SMTP 客户端声明 SMTPUTF8 关键词；而在实验版本中，只需要服务器声明允许使用扩展的信封和/或内容即可。

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 变体），那么用户不可避免地——哪怕只是偶尔——会看到这些编码而非「原生」字符，并会因此感到不适或惊讶。同样地，如果邮件传输与报文主体使用了不同的编码，那么用户也特别容易感到意外，哪怕这只是那条由来已久的「东西总会泄漏」（things leak）原则所导致的后果。无论从中期还是长期看，避免这些不适来源的唯一可行办法，就是让传输中所用的编码尽可能与报文头和报文主体中所用的编码保持一致。

当电子邮件的本地部分被国际化时，应当（SHOULD）同时安排报文头采用完全国际化的形式。该形式应当（SHOULD）使用 UTF-8 而非 ASCII 作为头字段内容的基础字符集（诸如头字段名本身这类协议要素保持不变，仍完全采用 ASCII）。出于过渡目的以及与既有旧式系统的兼容性，这可以通过扩展传统的 MIME 头部非 ASCII 字符编码模型 [RFC2045] [RFC2231] 来实现；但即便如此，只要有可能，这些做法也应当基于 UTF-8 而非其他编码 [RFC6055]。然而，目标是完全国际化的报文头（如 [RFC6532] 中所讨论的那样），而不是一段被拉长且痛苦的过渡期。

7.3. 面向 DSN 的 SMTP 服务扩展

现行的投递状态通知（DSN）规范 [RFC3461]（其状态为草案标准）在协议的机器可读部分仅限于使用 ASCII 文本。《国际化投递与处置通知》[RFC6533] 为国际化电子邮件地址新增了一种地址类型，从而使得含非 ASCII 字符的原始收件人地址即使在降级之后也能被正确保留。如果一台 SMTP 服务器同时通告 SMTPUTF8 扩展与 DSN 扩展，那么该服务器必须（MUST）实现国际化 DSN，包括支持 RFC 3461 [RFC3461] 所规定的 ORCPT 参数。

8. SMTP 事务之前与之后的降级

这些扩展所面临的一个重要问题是：如何处理支持非 ASCII 地址的系统与预期使用 ASCII 的既有旧式系统之间的交互。当然，仅支持 ASCII 的系统向能够处理国际化形式的系统发信是不存在问题的，因为 ASCII 形式恰好是其真子集。但是，当支持这些扩展的系统发送邮件时，它们可以（MAY）为发件人、收件人或双方使用非 ASCII 地址，并且还可能提供地址之外的其他非 ASCII 头部信息。如果第一跳系统（即由提交服务器以 SMTP 客户端身份访问的那台 SMTP 服务器）不支持该扩展，则报文的始发系统应当（SHOULD）准备好：要么发送常规的信封与报文头，要么把该报文退回给始发用户，以便该报文可由人工降级为传统形式——可能会在报文头中使用编码字（encoded words）[RFC2047]。当然，此类转换意味着始发用户或始发系统必须为所有发件人与收件人都备有仅含 ASCII 的地址。至于发现或识别此类地址的机制，则不在这些规范的范围之内；同样不在范围之内的还有关于始发系统设计的各项决定，例如所需的各种转换究竟由用户、由始发 MUA 还是由提交服务器来完成。

当第一跳系统支持这些扩展，而 SMTP 传输链中后续的某台服务器却不支持时，情况就要复杂一些。需要注意的是，对于前向指向地址（forward-pointing addresses）而言，这种情况在大多数场合下都是配置错误的结果：特别是当一台最终投递 MTA 承载着非 ASCII 地址时，如果它接受这些扩展，就不应（SHOULD NOT）配置不支持这些扩展的较低优先级 MX 主机。而当所传输的唯一非 ASCII 地址是后向指向地址（backward-pointing，例如出现在 SMTP MAIL 命令中）时，收件方的配置一般起不到什么作用。另一方面，为发件人准备的备用全 ASCII 地址，恰恰是最有可能被提交环境或发件人本人权威地知晓的。因此，如果某个要求使用这些扩展的中间 SMTP 中继随后发现链中的下一个系统并不支持它们，那么除了拒收或退回该报文之外，它几乎别无选择。

如上所述，降级为纯 ASCII 形式可能发生在初始报文提交之前或提交期间；它也可能发生在投递到最终投递 MTA 之后，以适配那些与投递 MTA 能力不同的报文存储、IMAP 或 POP 服务器或客户端。这些情形将在下面各小节中讨论。

8.1. 报文提交之前或提交期间的降级

IETF 历来避免规定 MUA 的精确行为，以便在相关用户界面上留出最大的灵活性。SMTP 标准 [RFC5321] 第 6.4 节给予 MUA 与提交服务器很大的自由度，只要用户所提供内容在注入公共 Internet 之后其结果符合「线上」标准即可。秉承这一传统，第 8 节余下部分的讨论均作为一般性指导给出，而非规范性要求。

需要使用这些扩展的报文有时会被传送到不支持这些扩展的系统；最常见的情形很可能是「仅 ASCII 的前向指向地址」与「一个非 ASCII 的后向指向地址」组合出现。在此处所述的扩展在 Internet 电子邮件环境中获得普遍实现之前，那些偏好使用非 ASCII 地址（或在头字段中使用原始 UTF-8 字符）的发件人，即便其预期收件人使用并期待全 ASCII 地址，也需要对可能出现的各种错误情形格外小心。在那些例行丢弃或忽略未投递报文（或提交服务器所给出的其他提示）的环境中，风险尤其大。

或许显而易见的是，为国际化地址寻找一个相对应的 ASCII 地址，最方便的时机是在始发 MUA 或与之紧密关联的系统上。这既可以发生在报文被发送之前，也可以发生在报文的国际化形式被拒收之后。同样，这也是把报文从国际化形式转换为常规 ASCII 形式、或在必要时向发件人生成一封未投递报文的最方便时机。在那个时点上，用户可以有全套的选择：修改后向指向地址、通过带外途径联系预期收件人以获取备用地址、查阅相应的目录服务、安排把地址与报文内容一并翻译为另一种语言，等等。虽然人们很自然地会认为报文降级的最优形态是一个完全自动化的过程，但我们不应低估一位至少具备中等智力、且希望与另一位同样的用户进行沟通的使用者所具备的能力。

在这一背景下，人们不难设想对报文提交服务器（如 RFC 6409 [RFC6409] 所述）作出修改，使其能够执行降级操作，甚至可能执行升级操作。此类操作将允许接收带有本文所讨论的一项或多项国际化扩展的报文，并根据需要对外发报文加以调整，以适应提交服务器所面对的投递环境或下一跳环境。

8.2. 最终 SMTP 投递之后的降级或其他处理

当一封电子邮件报文被最终投递 MTA 接收后，它通常会以某种形式被存储起来。随后，它要么被直接读取该存储形式的软件取回，要么被客户端软件通过 POP 或 IMAP 等某种邮件取回机制取回。

第 7.1 节所述的 SMTP 扩展只在传输环节提供保护。它无法阻止那些尚未升级到能够理解国际化地址与 UTF-8 报文头的 MUA 及邮件取回机制去访问已存储的国际化邮件。

由于最终投递 MTA（更确切地说，是与之对应的邮件存储代理）无法安全地假定访问邮件存储的各类代理总是有能力处理此处所提出的扩展，因此它可以（MAY）对国际化邮件进行降级，或者专门标识使用了这些扩展的报文，或者两者兼行。如果采取了其中一项或两项行动，则最终投递 MTA 应当（SHOULD）包含一种机制，用于无信息损失地保留或恢复原始的国际化形式。保留这些信息对于支持具备 SMTPUTF8 感知能力的代理进行访问是必要的。

9. 传输途中的降级

SMTP 基础规范（RFC 5321 [RFC5321] 第 2.3.11 节）指出：「由于中间主机试图通过修改本地部分来优化传输而造成的问题由来已久，本地部分必须（MUST）仅由地址域名部分所指定的主机来解释并赋予语义。」这并不是一项新要求；早在 2001 年 [RFC2821] 乃至 1989 年 [RFC1123] 的规范中就出现过等效的表述。

遵守这一规则意味着：一种会对电子邮件地址本地部分进行变换的降级机制，不能在传输途中被使用。它只能在端点上被应用，具体而言是由 MUA 或提交服务器，或者由最终投递 MTA 来应用。

这条规则的原因之一，与那些把邮件路由信息嵌入到地址字段本地部分之中的既有旧式邮件系统有关。变换电子邮件地址会破坏此类路由信息。举例来说，除最终投递服务器之外，任何服务器都无从知晓 user%foo@example.com 的本地部分究竟是一条路由（即「user」经由「foo」抵达），还是仅仅是一个本地地址。

10. 用户界面与配置问题

地址与报文头的国际化，尤其是当它与 Unicode 所固有的字符编码变体相结合时，可能会使「审慎选择地址」以及「审慎配置服务器与 DNS 记录」变得比在传统 Internet 电子邮件中更加重要。随着使用这些协议的经验不断积累，很可能有必要再制定一份或多份文档，为配置与界面提供指导。预计还将制定一份讨论 MUA 相关问题（特别是关于降级）的文档。下面各小节讨论另外一些问题。

10.1. 邮箱名的选择与 Unicode 规范化

长期以来的情况是：如果人们确实希望邮箱能够被广泛的发件人所访问，那么电子邮件语法所允许的某些邮箱名选择在实践中并不明智。最常被援引的例子涉及大小写敏感性，以及对邮箱本地部分中嵌入字符所作的巧妙引号处理。这些刻意为之的不寻常构造是协议所允许的，服务器也应支持它们。尽管在特殊情形下它们可能带来价值，但除非意图是营造某种「以隐晦求安全」（security by obscurity）的效果，否则利用它们几乎总是不良实践。

在没有这些扩展的情况下，SMTP 客户端与服务器只能使用 RFC 5321 所允许的那些地址。这些地址的本地部分可以（MAY）由 RFC 5321 所禁止的控制字符之外的任何 ASCII 字符构成，尽管其中一些字符必须（MUST）按该文档的规定加引号。在国际化的语境中，值得注意的是：某些系统上长期以来存在一种做法，即在带引号的字符串中使用叠打（overstruck）ASCII 字符（一个字符、一个退格、再一个字符）来近似表示非 ASCII 字符。这种国际化形式为 RFC 821 [RFC0821] 所允许，但被 RFC 5321 所禁止，因为它需要用到退格字符（一个被禁止的 C0 控制字符）。由于 RFC 5321（及其前身 RFC 2821）禁止在 ASCII 邮箱名中使用该字符，而它在非 ASCII 字符串中（出于规范化与归一化的原因）问题更大，因此退格字符不得（MUST NOT）出现在 SMTPUTF8 邮箱名中。

对于本地部分、域名部分或两者之中包含非 ASCII 字符的邮箱名这一特定情形，必须（MUST）特别关注 Unicode 规范化 [Unicode-UAX15]，部分原因在于 Unicode 字符串可能被独立于邮件协议之外的其他过程加以规范化（这与传统地址中加引号与去引号可能发生的情况完全类似）。因此，谨向那些为邮箱选取名称的人提出以下原则作为建议：

• 一般而言，明智的做法是支持规范化形式的地址，至少采用规范化形式 NFC。除非在某些情形下 NFKC 会把目的邮件服务器的责任方希望保持可区分的字符映射到一起，否则支持符合 NFKC 的形式将为典型用户带来更可预期的行为。
• 通常明智的做法还包括支持同一本地部分字符串的其他形式，方式可以是设置别名，也可以是对抵达投递服务器的字符串进行规范化：不应指望发送方一定会以规范化形式发送这些字符串。
• 换一种更具体的说法，协议关于本地部分字符串的规则实质上规定：
  • 未规范化的字符串是有效的，但这种做法糟糕到足以使其在全球范围内无法可靠工作。服务器不应指望客户端发送规范化形式，但应意识到：客户端机器上不受 MUA 控制的某些处理过程，可能会导致无论用户本意如何都发送出规范化后的字符串。
  • C0（以及可以推定的 C1）控制字符（参见《Unicode 标准》[Unicode]）是被禁止的：前者由 RFC 5321 禁止，后者则由从中显然可推出的扩展加以禁止 [RFC5198]。
  • 其他各类标点符号、空格等等属于有风险的做法。它们或许能够工作，并且 SMTP 接收方代码也被要求在处理它们时不产生严重错误（即使含此类字符串的地址并不被该服务器接受用于投递），但在所选取的邮箱名中制造对它们的依赖通常是不良实践，并可能导致互操作性问题。

11. 其他问题

本节指出了一些在本规范集合中未被涵盖、或未被全面涵盖的问题，但在部署电子邮件地址与报文头国际化的过程中，这些问题需要持续加以审视。

11.1. 对 URI 与 IRI 的影响

当这项工作完成并标准化之后，mailto: 方案 [RFC6068] 以及「国际化资源标识符」（IRI）规范 [RFC3987] 中对它的讨论，可能需要作出修改。

11.2. 将电子邮件地址用作标识符

在当代 Internet 的使用中，有若干场合把电子邮件地址用作个人的标识符，包括在支持某些电子商务站点的 Web 服务器上作为标识符，以及在某些 X.509 证书 [RFC5280] 之中。这些文档并未处理那些用途，但可以合理地预期：当国际化地址首次被用于这些场景时，会遇到一些困难——其中许多场景甚至连当今已被允许的全部地址范围都无法处理。

11.3. 编码字、签名报文与降级

电子邮件格式的一个突出特性是它的持久性：人们期望 MUA 不仅能处理数秒前投递的报文，也能处理数十年前发出的报文。因此，MUA 以及诸如 Sieve [RFC5228] 所规定的邮件过滤软件，将需要继续接受并解码那些使用「编码字」机制 [RFC2047] 以容纳某些头字段中非 ASCII 字符的头字段。虽然针对 POP3 [RFC1939] 与 IMAP [RFC3501] 都已定义了扩展，其中包含由 POP3 [RFC5721bis-POP3] 或 IMAP [RFC5738bis-IMAP] 服务器对携带编码形式非 ASCII 信息的报文进行自动升级（包括 RFC 2047 解码），但仍存在一些报文结构与 MIME 内容类型，对它们无法这样做，或者这样做会带来不可接受的副作用。

例如，使用 S/MIME [RFC5751] 或 Pretty Good Privacy（PGP）[RFC3156] 等方式进行了密码学签名的报文部分，如果从 RFC 2047 形式升级为普通 UTF-8 字符，就会破坏签名。类似地，被加密的报文部分在解密之后可能包含使用 RFC 2047 编码的头字段；若无法访问密钥，此类报文就无法被「完全」升级。

如果报文先被签名，随后又被降级（例如第 8.1 节所讨论的情形），之后又有人试图把它们升级回原始形式并验证签名，也可能出现类似问题。即使是降级再升级的算法所可能造成的极其细微的变化，只要影响到主头部或 MIME 主体部分的头部，就足以使签名失效。当存在签名时，降级即便要做，也必须极其审慎地进行。

11.4. 本地部分的其他用途

本地部分有时被用来构造域名标签。例如，地址 user@domain.example 中的本地部分 "user" 可以被转换为主机名 user.domain.example，其 Web 空间位于 <http://user.domain.example>，并配有形如 any.thing.goes@user.domain.example 的通配（catch-all）地址。

此类方案显然会受到诸多限制，其中就包括 SMTP 关于域名的规则；对于其他形式的本地部分，若不施加进一步的限制，这些方案将无法工作。这些局限是否与本规范集合相关，是一个开放问题。它也可能只不过是「投递 MTA 在决定接受哪些邮箱名以及如何解释它们方面被赋予了相当大灵活性」的又一个实例罢了。

11.5. 非标准封装格式

某些应用使用类似 application/mbox 格式 [RFC4155] 的格式，而不使用 RFC 2046 第 5.1.5 节 [RFC2046] 所定义的 message/digest 形式，来把多封报文作为单一单元传输。只要此类应用假定所有已存储的报文都采用 RFC 2046 第 5.2.1 节 [RFC2046] 所述的 message/rfc822 格式并带有 ASCII 报文头，它们就尚未为本系列文档所规定的扩展做好准备，因而可能需要采取特别措施来正确地检测并处理它们。

12. 相对于实验性协议与框架的关键变更

国际化电子邮件地址与报文头的最初框架由 RFC 4952 以及随后的一组实验性协议文档所描述。这些文档之间的关系在第 3 节中有所描述。实验性规范与这一套较新规范之间的关键体系结构差异在于：早先的规范支持传输途中降级。那些机制包括：定义了用于在传递非 ASCII 地址的同时传递备用全 ASCII 地址的语法与功能，以及用于指示报文降级状态的特殊头部。在实验表明这些特性比早先所设想的更为复杂、也更不必要之后，它们被取消了。这些问题在第 6 节与第 9 节中有更详细的描述。

13. 安全考虑

对电子邮件地址中所允许的字符与编码形式的任何扩充，都会带来一定的风险。业界已就所谓的「IDN 欺骗」（IDN-spoofing）或「IDN 同形异义攻击」（IDN homograph attacks）展开过讨论。这类攻击使攻击者（或「钓鱼者」）能够伪造企业或其他实体的域名或 URL。同类攻击在国际化电子邮件地址的本地部分上同样可能发生。应当注意的是，所提出的「把所有显示元素强制转为规范化小写形式」这一修复办法，对 URL 中的域名有效，但对电子邮件本地部分无效，因为后者是大小写敏感的。

由于电子邮件地址常常是从名片和纸质便条上转录而来，因此它们容易受到易混淆字符（confusable characters）所引发问题的影响（参见 [RFC4690]）。如果与邮箱相关联的域是明确无歧义的，并且该域支持的邮箱数量相对较少、其命名遵循本地系统约定，那么这些问题会有所减轻；而在用户可以自由选择自己地址的超大型邮件系统中，这些问题则会加剧。

电子邮件地址与报文头的国际化，绝不应使 Internet 的安全性低于不采用这些必需扩展时的水平。总体而言，本规范集合所记载的各项要求与机制并未引入任何新的安全问题。

它们确实要求对与易混淆字符相关的问题进行审视——该主题正在别处被深入探讨（例如可参见 RFC 4690 [RFC4690]）——并且可能还要求审视与 UTF-8 规范化相关的一些问题（在 RFC 3629 [RFC3629] 中有讨论）以及其他各种变换。规范化以及与变换和标准形式相关的其他问题，同样属于别处所述工作的主题 [RFC5198] [RFC5893] [RFC6055]。

一些专门与国际化地址和报文头相关的问题，在本集合的其他文档中有更详细的讨论。不过特别需要注意的是：任何「降级」机制，或对降级后地址的使用，都不应不恰当地假定国际化地址与 ASCII 地址之间存在经过认证的绑定关系。这一潜在问题可以在一定程度上得到缓解，办法是切实落实这样的预期：绝大部分乃至全部此类变换，都将在最终投递之前由那些可推定处于发送用户管理控制之下的系统来执行（而不是在传输途中由不受发送用户管理控制的实体来执行）。

新的 UTF-8 头部与报文格式还可能引发或加剧另一个已知问题。如果该模型造就了「无效」或「畸形」报文的新形式，那么一种新的邮件攻击就随之产生：出于健壮性的考虑，部分乃至大多数代理会接受此类报文，并把它们当作格式良好的报文来解释。如果某个过滤器对此类报文的解释不同于收件人所使用的 MUA，那就有可能构造出这样一封报文：按过滤器的解释它看起来是可接受的，但按该 MUA 赋予它的解释则本应被拒绝。针对既有报文与编码层的此类攻击已经发生过，例如无效的 MIME 语法、无效的 HTML 标记，以及特定图像类型的无效编码。

此外，电子邮件地址还被用于发送邮件之外的许多场景，例如在各种情形下用作标识符（参见第 11.2 节）。上述每一种场景都需要逐一评估，以确定使用非 ASCII 形式是否恰当，以及它们会引出哪些具体问题。

这项工作显然会影响任何依赖数字签名或类似完整性保护手段来保护电子邮件报文头的系统或机制（另请参见第 11.3 节中的讨论）。PGP 与 S/MIME 的许多常规用法不受影响，因为它们被用于对主体部分而非报文头进行签名。另一方面，「域名密钥识别邮件」（DKIM）[RFC5863] 方面正在开展的工作最终需要考虑本项工作，反之亦然：虽然本规范并未处理或解决 DKIM 及其他头部签名机制所引出的问题，但如果这两套协议要共存，这些问题最终必须被协调并解决。另外，就电子邮件地址出现在公钥基础设施（PKI）证书 [RFC5280] 中的程度而言，针对此类证书的标准将需要升级以处理这些国际化地址。这些升级还需要处理针对地址本身的「形近仿冒」（look-alikes）欺骗问题。

14. 致谢

本文档是对 RFC 4952 的更新，并派生自该文档。若没有该文档中所致谢的各项工作与贡献，本文档将无从谈起。自 RFC 4952 发布以来，IETF EAI 工作组内外的各种讨论——尤其是关于国际化电子邮件文档集合中其他文档的实验版本的讨论——以及针对 RFC 4952 本身的勘误，都使本文档获益良多。

特别感谢 Ernie Dainow 对本版本所作的细致审阅与建议文本，并感谢数位 IESG 成员的认真审阅与具体建议。

15. 参考文献

15.1. 规范性参考文献

• [ASCII] American National Standards Institute（原为 United States of America Standards Institute），《USA Code for Information Interchange》，ANSI X3.4-1968，1968 年。（ANSI X3.4-1968 已被略有修改的新版本所取代，但 1968 年版本对 Internet 而言仍具决定性意义。）
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
• [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., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 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.
• [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.
• [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
• [RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.

15.2. 资料性参考文献

• [POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", 进行中的工作（Work in Progress），2011 年 10 月。
• [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
• [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
• [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
• [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
• [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
• [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
• [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
• [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
• [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
• [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
• [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
• [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
• [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
• [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
• [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.
• [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
• [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
• [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
• [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
• [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
• [RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.
• [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
• [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
• [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
• [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.
• [RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", 进行中的工作（Work in Progress），2011 年 11 月。
• [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.
• [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", 进行中的工作（Work in Progress），2011 年 12 月。
• [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
• [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.
• [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
• [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
• [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
• [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
• [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
• [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.
• [RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", 进行中的工作（Work in Progress），2011 年 12 月。
• [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
• [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
• [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
• [Unicode] The Unicode Consortium，《The Unicode Standard, Version 6.0.0》（Mountain View, CA: The Unicode Consortium, 2011，ISBN 978-1-936213-01-6），<http://www.unicode.org/versions/Unicode6.0.0/>。
• [Unicode-UAX15] The Unicode Consortium，《Unicode Standard Annex #15: Unicode Normalization Forms》，2010 年 9 月，<http://www.unicode.org/reports/tr15/>。

作者地址（Authors' Addresses）

John C KLENSIN
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA

Phone: +1 617 491 5735
EMail: john-ietf@jck.com

YangWoo KO
112-202 Malgeunachim APT. Nae-dong
Seo-gu, Daejeon 302-981
Republic of Korea

EMail: yangwooko@gmail.com