非官方中文译本声明：本页为 IETF RFC 5068《Email Submission Operations: Access and Accountability Requirements》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc5068。

RFC 5068《邮件提交运营：接入与问责要求》中文译本

IETF · RFC 5068 · 最佳当前实践（BCP 134）· 2007 年 11 月

Status of This Memo（本备忘录状态）

本文档为互联网社区规定了互联网最佳实践（Best Current Practices），并请求讨论与改进建议。本备忘录的分发不受限制。

Abstract（摘要）

电子邮件已成为各类社会所不接受、具有大规模效应之用途的流行分发服务。其中最明显者包括垃圾邮件（spam）与蠕虫。本备忘录就独立运营者（诸如企业与互联网服务提供商）之间的邮件提交与传输服务运营约定提出建议，其目标是改善问责链，以管控对互联网邮件服务的滥用。为此，本文档为邮件提交与传输服务的独立运营者之间提供建设性的运营策略建议。

邮件认证技术旨在为互联网络之间提供保障与可追溯性。在众多邮件服务中，保障链中最薄弱的环节乃是消息的初始提交。本文档针对邮件发送的第一步——将邮件提交（或投寄）进入传输网络——提出建设性的运营策略建议。中继与投递所涉及的策略发生在提交之后，不在本文档范围之列。

1. 引言（Introduction）

正是令电子邮件如此便捷的那些特性——其近乎无处不在、快速投递、低成本，以及支持无需事先约定的交换——使其成为分发不受欢迎或恶意内容的沃土。垃圾邮件、欺诈与蠕虫已成为严重问题，威胁着电子邮件的存续能力，并令最终用户与服务提供商蒙受数百万美元的损失与生产力下降。近年来，包括企业与 ISP 在内的独立运营者已转向多种不同的技术与流程，试图对抗这些问题。其成效即便往好处说，也是喜忧参半。

在抵达最终目的地途中，邮件常常在多个独立的邮件传输服务运营者之间穿行。这些服务彼此通常并无事先约定，并可能在传输上采用不同规则。因此，无论是对邮件传输中出现的问题进行调试，还是在不良或恶意邮件被注入互联网邮件基础设施时追究责任，都十分困难。

现有的邮件认证技术为数众多。它们为异构网络之间提供了某种问责与可追溯性。本文档旨在利用这些技术的可得性，探讨从邮件用户代理（MUA, Mail User Agent）到邮件提交代理（MSA, Mail Submission Agent）这第一步——即"提交（submission）"——的认证与授权最佳实践。若邮件提交环节缺乏有力实践，认证技术在服务其余各处所发挥作用便极为有限。

本文档规定了用于邮件发送第一步的运营策略，即提交——或按下文定义从 MUA 向 MSA 投寄——邮件进入传输服务。这些策略在提升问责的前提下，保障互联网邮件的持续平稳运行。中继与投递所采用的是提交之后发生的策略，不在本文档范围之内。此处所列策略适用于各种规模的网络运营者，且可由运营者独立实施，无需顾及邮件交换的另一方是否已予实施。

需要着重指出：仅凭采纳这些策略本身，并不能解决垃圾邮件及其他不良邮件的问题。然而，这些策略在厘清运营者之间的问责界限与互操作性方面，提供了有益的一步。这有助于提高滥用者的门槛，并为额外工具的引入奠定基础，以维护互联网邮件基础设施的效用。

注：本文档不深入探讨其他反垃圾邮件运营议题，例如邮件拒收的标准。作者指出，开展此项工作或许颇有价值，并鼓励对其进行推进。

2. 术语（Terminology）

互联网邮件架构区分了四种消息处理组件：

在源端，MUA 代表最终用户创建消息，并通过 MSA 执行初始的"提交"进入传输基础设施。MSA 接受消息提交，对消息执行任何必要的预处理，并将消息中继给某个 MTA 以进行传输。MTA 将消息"中继"给其他 MTA，经过一系列传递抵达目的地的 MDA，而 MDA 再"投递"邮件至收件人的收件箱。收件箱属于收件方 MUA 的一部分，后者代表最终用户处理所收到的邮件。

这些架构组件常常被压缩在一起，例如由同一套软件承担 MSA、MTA 与 MDA 的功能。然而，对这些架构组件各自的要求正变得日益广泛，以至于其软件乃至物理平台上的分离也愈发常见。

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

3. 提交、中继与投递（Submission, Relaying, Delivery）

最初，MSA、MTA 与 MDA 这三种架构组件被视为单一单元。这一点反映在如下实践中：MSA、MTA 与 MDA 的传输全部通过 TCP 25 端口以 SMTP [RFC2821] [RFC0821] 完成。互联网邮件允许在无需事先约定、且无需发件人认证的情况下交换邮件。也就是说，中继的 MTA 或 MDA 未必知晓消息发起者的已确认身份。

区分以下三者至关重要：MUA 到 MSA 的邮件提交、MTA 中继、以及最终的 MTA 到 MDA 的过渡。提交通常确实涉及客户端用户与服务器运营者之间的预先确立关系；同样，MDA 执行最终投递，能够确定其与收件人之间存在既有关系。也就是说，MSA 与 MDA 可借助与用户的事先关系，对其传输活动加以约束。

具体而言，MSA 可以选择拒收来自其无既有关系之 MUA 的所有投寄。类似地，MDA 可以选择拒收发往其无投递安排之收件人的所有邮件。事实上，这两项策略均早已是普遍做法。

3.1 提交运营的最佳实践（Best Practices for Submission Operation）

提交端口可用性（Submission Port Availability）：

若支持外部提交——即来自某站点管理域之外——则该域的 MSA MUST（必须）支持 SUBMISSION 端口 587 [RFC4409]。运营者 MAY（可以）针对外部用户与本地用户统一采用 SUBMISSION 端口；此举可显著简化提交运营。

提交端口使用（Submission Port Use）：

MUA SHOULD（应该）使用 SUBMISSION 端口进行消息提交。

提交认证（Submission Authentication）：

MSA MUST（必须）对 SUBMISSION 端口上所有邮件事务中所声明的身份执行认证，即便该消息的 RCPT TO 地址不会导致消息被中继至本地管理域之外。

提交授权（Submission Authorization）：

MSA 的运营者 MUST（必须）确保经认证的身份已获授权提交邮件，其依据为提交实体与运营者之间的既有关系。此项要求适用于所有邮件提交机制（MUA 到 MSA）。

提交后的提交问责（Submission Accountability after Submission）：

在提交后的合理时间段内，MSA 运营者 SHOULD（应该）能够将消息追溯到发送该消息之用户的已认证身份。此类追溯 MAY（可以）基于存储在信头（received 行等）或消息其他字段中的事务标识符、基于存储在其他位置的审计数据，或基于任何能够支撑充分提交后问责的其他机制。此处并未规定消息提交之后需支撑可追溯性的具体时长。然而，与传输相关的问题常常在提交后长达一周时才出现。

需注意，[RFC3848] 定义了在 Received 信头字段中记录提交时信息的方法。该信息可帮助接收端分析软件确立发送 MSA 的问责，进而对消息的处理做出决策。

3.2 向提交端口过渡（Transitioning to Submission Port）

为推动初始消息提交从 25 端口向 587 端口过渡，MSA MUST（必须）默认监听 587 端口，并 SHOULD（应该）具备监听其他端口的能力。MSA MUST（必须）在 587 端口上要求认证，并 SHOULD（应该）在任何其他用于提交的端口上要求认证。MSA MAY（可以）也监听其他端口。无论接受消息的端口为何，MSA MUST NOT（不得）允许将未认证消息中继至其他域。也就是说，它们不得成为开放中继（open relays）。

作为默认行为，MUA SHOULD（应该）尝试从备选端口列表中找出最佳可能的提交端口。SUBMISSION 端口 587 SHOULD（应该）置于该列表首位。由于当下大多数 MUA 不允许回退到备用端口，站点 SHOULD（应该）预先配置，或鼓励其用户连接 SUBMISSION 端口 587（假设该站点支持该端口）。

4. 外部提交（External Submission）

MUA 可能需要跨互联网提交邮件，而非提交给本地 MSA，以便从其归属站点获取特定服务。例子包括：主动防范第三方内容监视的隐私保护、及时处理，以及适用最为恰当的认证与问责协议。此外，隐私要求或许还合理地包含防范 MUA 接入网络运营者的监视。这一要求给通过其网络使 MUA 得以接入的提供商带来了挑战。它使得该提供商被迫卷入解决大规模效应邮件问题的任务之中：当 MUA 卷入影响大量互联网用户的问题时，该提供商被期望施以补救，并常被期望预防此类事件的发生。

某些提供商采用的主动技术是：阻断所有出站邮件对 25 端口 SMTP 的使用，或自动将此流量通过本地 SMTP 代理重定向，被明确授权的主机除外。这对某些用户而言可能带来问题，尤其是试图使用其"归属" MSA 的合法移动用户，即便这些用户或许已经采用了合法的、基于 25 端口的认证。

本文档不就阻断 SMTP 25 端口或类似管控标准匿名邮件传输端口滥用的做法提出建议。相反，它追求使用官方 SUBMISSION 端口 587 [RFC4409] 所带来的相互建设性益处。

注：当前已存在许多管控出站邮件之 25 端口滥用的既有做法。其中包括将 SMTP 流量代理至本地主机进行筛查，并结合各种形式的速率限制。作者建议，就此主题另行起草一份独立文档将有益于邮件运营社区。

4.1 支持外部提交的最佳实践（Best Practices for Support of External Submissions）

开放提交端口（Open Submission Port）：

接入提供商 MUST NOT（不得）阻断用户使用 SUBMISSION 端口 587 [RFC4409] 访问外部互联网。

流量识别——外部投寄（MSA）与中继（MX）之分：

当从本地运营环境之外接收邮件时，邮件服务提供商 MUST（必须）区分两类流量：发往本地域的未认证邮件（MX 流量），与可发往任何地址的、与提交相关的已认证邮件（MSA 流量）。这使得 MTA 能够限制中继操作，从而防止"开放"中继。需注意，存在某些可能不适用此要求的情况，例如运营者网络内部、处于其控制之下的次级 MX 及相关实现。

图 1 描绘了一个本地用户（MUA.l）向 MSA 提交消息。它还展示了一个远程用户（MUA.r，例如可能位于提供"热点"无线接入的咖啡馆）经由已认证的 587 端口事务向其"归属" MSA 提交消息。该图显示了在 MSA 网络内使用 587 端口或 25 端口的两种选择。本文档不对使用 25 端口进行提交提出建议。该图仅旨在指出 25 端口被广泛使用，并承认在组织网络内部，25 端口可在充分问责下使用。

                 HOME  NETWORK                       DESTINATION
      +-------+
      | MUA.l |
      +---+---+
   port   |  port     port                          port
   587/25 V   25       25          --------          25
       +-----+  +-----+  ******   /        \   ******  +-----+  +-----+
       | MSA |->| MTA |->* AP *->|          |->* AP *->| MTA |->| MDA |
       +--^--+  +-----+  ******  | INTERNET |  ******  +-----+  +-----+
          |                      |          |
          +-------<--------------|----+     |
                                  \   |    /
                                   ---^----
                                      |
                                    ******
        AP = Access Provider        * AP *
                                    ******
                                      | port 587
                                  +---+----+
                                  |  MUA.r |
                                  +--------+
                                  HOTSPOT

             Figure 1: Example of Port 587 Usage via Internet

5. 消息提交认证/授权技术（Message Submission Authentication/Authorization Technologies）

现有许多胜任的、用于认证消息提交的技术与标准。两项已被标准化的组成机制包括 SMTP AUTH [RFC4954] 与 TLS [RFC3207]。视环境不同，不同机制的有效性与便捷性或有高低。机制也可能须彼此结合使用，方能构成安全系统。组织 SHOULD（应该）选择切实可行范围内最为安全的方案。

本文档不就具体的安全实现提出建议。它仅给出一项警示：在所有场景下都应避免在不安全的网络上以明文传输用户凭证，因为这可能使攻击者得以监听此类流量并窃取账户数据。在此类情形下，强烈建议 MUST（必须）使用适当的安全技术。

6. 安全考量（Security Considerations）

独立管理域之间的邮件传输，可能成为大量不受欢迎邮件、以及含有旨在攻击收件人系统之恶意内容的邮件之源。本文档阐明了在降低恶意邮件被传输之可能性的同时，允许此类交换的要求与流程。

7. 参考文献（References）

7.1 规范性参考文献（Normative References）

7.2 资料性参考文献（Informative References）

附录 A. 致谢（Appendix A. Acknowledgments）

这些建议最初形成于反垃圾邮件技术联盟（ASTA, Anti-Spam Technical Alliance）部分成员与互联网研究任务组反垃圾邮件研究组（ASRG, Anti-Spam Research Group）部分参与者之间的非正式讨论。

后续的评审与建议由以下人士提供：M. Allman, L.H. Aestrand, N. Borenstein, S. Bortzmeyer, K. Chon, R. Clayton, B. Cole, W. Dnes, V. Duchovni, E. Edelstein, F. Ellermann, M. Elvey, J.D. Falk, N. Freed, J. Glube, A. Herzberg, J. Klensin, J. Levine, S. Moonesamy, K. Moore, R. Nelson, C. Newman, C. O'Malley, S. Ramasubramanian, R. Rognlie, J. St. Sauver, W. Schlitt, B. Shein, B. Sullivan。

作者地址（Authors' Addresses）