RFC 6409：邮件提交（Message Submission）

R. Gellens（QUALCOMM Incorporated）、J. Klensin · STD 72 · 取代 RFC 4409 · 2011 年 11 月 · 类别：Standards Track（标准跟踪）· ISSN: 2070-1721

摘要

本备忘录将邮件提交（message submission）与邮件中转（message relay）分离，使两项服务各自能够依据其自身的规则（出于安全、策略等目的）运作，并规定了提交服务器应当采取的行动。

邮件中转不受影响，继续使用基于 25 端口的 SMTP。

在遵循本文档时，邮件提交使用本文规定的协议，通常经由 587 端口。

这种功能分离带来了若干好处，包括能够施加特定的安全或策略要求。

本备忘录的状态

本文是一份互联网标准跟踪（Standards Track）文档。

本文是互联网工程任务组（IETF）的成果，代表了 IETF 社区的共识，已通过公众评审，并经互联网工程指导组（IESG）批准发布。有关互联网标准的更多信息见 RFC 5741 第 2 节。

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

版权声明

Copyright (c) 2011 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含简化 BSD 许可证（Simplified BSD License）文本，如《信托法律规定》第 4.e 节所述，并按该许可证的规定「不附任何担保」提供。

目录

• 1. 引言
• 2. 文档信息
  • 2.1. 本备忘录所用术语定义
  • 2.2. 本备忘录所用约定
• 3. 邮件提交
  • 3.1. 提交标识
  • 3.2. 消息拒收与退信
  • 3.3. 已授权的提交
• 4. 强制动作
  • 4.1. 通用提交拒收码
  • 4.2. 确保所有域均为完全限定
  • 4.3. 要求认证
• 5. 推荐动作
  • 5.1. 强制地址语法
  • 5.2. 记录错误
  • 5.3. 应用更短的超时
• 6. 可选动作
  • 6.1. 强制提交权限
  • 6.2. 强制许可
  • 6.3. 检查消息数据
  • 6.4. 对 Postmaster 地址的支持
  • 6.5. 调整字符编码
• 7. 与 SMTP 扩展的交互
• 8. 消息修改
  • 8.1. 添加 'Sender'
  • 8.2. 添加 'Date'
  • 8.3. 添加 'Message-ID'
  • 8.4. 传输编码
  • 8.5. 对消息签名
  • 8.6. 对消息加密
  • 8.7. 解析别名
  • 8.8. 头字段重写
• 9. 安全考量
• 10. IANA 考量
• 11. 致谢
• 12. 参考文献
  • 12.1. 规范性参考文献
  • 12.2. 资料性参考文献
• 附录 A. 相对于 RFC 4409 的主要变更
• 作者地址

1. 引言

SMTP [SMTP-MTA] 最初被定义为一种消息传输（transfer）协议，即一种在需要时进行路由、并投递完整（finished）消息的手段。

邮件传输代理（MTA）不应更改消息文本，除非按照 [SMTP-MTA] 的要求添加 'Received'（接收）、'Return-Path'（返回路径）等头字段。然而，如今 SMTP 也被广泛用作一种消息提交（submission）协议，即消息用户代理（MUA）将新消息引入 MTA 路由网络的手段。接受来自 MUA 的消息提交的过程称为「邮件提交代理」（MSA）。

为允许不受约束的通信，SMTP 在消息中转过程中通常不进行认证。随着安全需求的变化，以及对提交服务器为其发出的消息流量承担责任这一期望的上升，对初始提交的认证与授权已变得愈发重要。

例如，由于大量机器感染了蠕虫、病毒或其他会产生海量垃圾邮件的恶意软件，许多站点现在禁止通过标准 SMTP 端口（25 端口）的外发流量，将所有邮件提交都汇聚到提交服务器。

除认证与授权问题之外，被提交的邮件在某些情况下是已完成（完整）的邮件，而在另一些情况下则在一个或多个方面未完成（不完整）。未完成的邮件可能需要补全，以确保其符合报文格式规范 [MESSAGE-FORMAT] 及相关要求。例如，邮件可能缺少恰当的 'Date'（日期）头字段，且域名可能不是完全限定的。在某些情况下，MUA 可能无法生成已完成的邮件（例如，它可能不知道自身的时区）。即使提交的邮件是完整的，本地站点策略也可能要求以某种方式检查或修改邮件文本，例如隐藏本地名称或地址空间。此类补全或修改若由下游 MTA——即首跳提交 MTA 之后的 MTA——执行，已被证明会造成损害，并且通常被认为超出了标准化 MTA 功能的范畴。

将消息区分为提交与中转，使开发者和网络管理员能够更轻松地做到以下几点：

• 实施安全策略，防范未经授权的邮件中转或未经请求的大量邮件（群发邮件）的注入。
• 实施经认证的提交，包括旅行者等已授权用户的异地提交。
• 分离相关的软件代码差异，从而简化各自的代码库，并允许为转发与提交使用不同的程序。
• 检测站点邮件客户端的配置问题。
• 为添加增强的提交服务奠定基础。

本备忘录描述了一种低成本、确定性的手段，用于识别消息为提交，并规定了提交服务器应当采取的行动。

2. 文档信息

2.1. 本备忘录所用术语定义

本文档使用的许多概念和术语在 [SMTP-MTA] 中定义；此处假定读者已熟悉这些文档。

完全限定（Fully Qualified）：包含或由可通过域名服务（DNS）在全球范围内解析的域构成，即不是本地别名或部分规格。

邮件提交代理（Message Submission Agent，MSA）：符合本规范的进程。MSA 作为提交服务器接受来自 MUA 的消息，并要么将其投递，要么作为 SMTP 客户端将其转发给某个 MTA。

邮件传输代理（Message Transfer Agent，MTA）：符合 [SMTP-MTA] 的进程。MTA 作为 SMTP 服务器接受来自 MSA 或另一 MTA 的消息，并要么将其投递，要么作为 SMTP 客户端将其转发给另一 MTA。

消息用户代理（Message User Agent，MUA）：（通常代表用户并带有用户界面）负责撰写和提交新消息，以及处理已投递消息的进程。

对于已投递的消息，接收方 MUA 可以按照本地约定获取并处理消息，或者，在通常称为分离式 MUA（split-MUA）模型的方案中，使用邮局协议 [POP3] 或 IMAP [IMAP4] 访问已投递的消息，而使用本文定义的协议（或 SMTP）来提交消息。

2.2. 本备忘录所用约定

示例中使用 'example.net' 域。

本文中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"SHOULD"（应该）、"SHOULD NOT"（不应该）以及 "MAY"（可以）应按照 [KEYWORDS] 中的定义进行解释。

3. 邮件提交

3.1. 提交标识

587 端口被保留用于本文规定的电子邮件消息提交。在该端口上接收到的消息被定义为提交。所使用的协议是 ESMTP [SMTP-MTA]，并附带本文规定的额外限制或许可。

尽管大多数邮件客户端和服务器都可配置为使用 587 端口而非 25 端口，但在某些情况下这样做并不可行或不方便。站点可以（MAY）选择将 25 端口用于消息提交，方法是把某些主机指定为 MSA，而将其他主机指定为 MTA。

3.2. 消息拒收与退信

MTA 和 MSA 可以（MAY）实施部分依赖于消息是提交还是中转的消息拒收规则。

例如，某些站点可能将其 MTA 配置为拒收所有引用了非本地用户的消息的 RCPT 命令，并将其 MSA 配置为拒收所有并非来自已授权用户的消息提交，其中授权可基于已认证的身份，或者提交端点位于受保护的 IP 环境之内。

注意：拒收一条消息，胜过冒险发出一条已被损坏的消息。对于可由 MUA 纠正的问题（例如无效的 'From' 字段），这一点尤为正确。

如果 MSA 无法根据一个有效的 MAIL FROM、一个有效的源 IP 地址，或基于已认证身份，来确定提交用户的返回路径，那么 MSA 应该（SHOULD）立即拒收该消息。可通过向 MAIL 命令返回 550 代码来立即拒收消息。

注意，空返回路径（即 MAIL FROM:<>）是允许的，其本身不得（MUST NOT）成为拒收消息的理由。（MUA 出于多种原因需要生成空返回路径的消息，包括投递状态通知。）

除非 MSA 无法确定所提交消息的有效返回路径，否则本规范中指示 MSA 发出拒收码的内容，可以通过接受该消息并随后生成一封退信（bounce）消息来遵从。（也就是说，如果 MSA 因任何原因（除无法确定返回路径外）要拒收消息，它可以选择立即拒收，也可以接受消息之后再寄出退信。）

注意：在消息提交的正常情形下，首选立即拒收消息，因为这能向用户和 MUA 提供直接反馈。为了正确处理延迟的退信，客户端 MUA 需要维护一个已提交消息的队列，并将退信与它们相匹配。请注意，许多当代 MUA 并不具备这种能力。

3.3. 已授权的提交

人们已使用多种方法，以确保只有已授权的用户才能够提交消息。这些方法包括经认证的 SMTP、IP 地址限制、安全的 IP 及其他隧道，以及事先的 POP 认证。

经认证的 SMTP [SMTP-AUTH] 已得到广泛部署。它使 MSA 能够为消息提交确定一个授权身份，该身份不依赖于其他协议。

IP 地址限制的实现非常广泛，但它们不允许旅行者及类似情形，并且除非 MUA 与 MSA 之间的所有传输路径都是可信的，否则很容易被伪造。

安全的 IP [IPSEC] 以及其他加密且经认证的隧道技术也可以使用，并且提供额外好处，即防范窃听与流量分析。

要求在消息提交会话开始前的一段时间内（例如 20 分钟）进行 POP [POP3] 认证（来自同一 IP 地址）的做法也曾被采用，但这确实对客户端和服务器都施加了限制，从而可能引发困难。具体而言，客户端必须在 SMTP 提交会话之前进行 POP 认证，而并非所有客户端都具备并配置了这一能力。此外，MSA 必须与 POP 服务器协调，这可能很困难。还存在一个时间窗，在此窗口内未授权用户能够提交消息并表现为先前已授权的用户。由于它依赖于 MUA 的 IP 地址，该技术基本上与仅基于已知 IP 地址的验证一样容易受到 IP 地址伪造的影响（见上文）。

4. 强制动作

MSA 必须（MUST）执行以下所有动作：

4.1. 通用提交拒收码

除非被更精确的响应码所涵盖，否则应使用响应码 554 来拒收包含不当内容的 MAIL、RCPT 或 DATA 命令。

4.2. 确保所有域均为完全限定

MSA 必须（MUST）确保 SMTP 信封中的所有域都是完全限定的。

如果 MSA 以任何方式检查或修改消息文本（除非按照 [SMTP-MTA] 添加追溯头字段），它必须（MUST）确保地址头字段中的所有域都是完全限定的。

应使用响应码 554 来拒收包含不当域引用的 MAIL、RCPT 或 DATA 命令。

一种常见的本地约定是接受单级域（例如 'sales'），然后通过添加域名的其余部分（例如扩展为 'sales.example.net'）来补全引用。允许单级域的本地约定应该（SHOULD）拒收——而非补全——不完整的多级域（例如 'squeaky.sales'），因为这种补全尤其危险。

4.3. 要求认证

默认情况下，如果会话尚未使用 [SMTP-AUTH] 进行认证，MSA 必须（MUST）对 MAIL 命令发出错误响应，除非它已经独立地建立了认证或授权（例如位于受保护的子网之内）。

第 3.3 节讨论了认证机制。

为此目的使用响应码 530 [SMTP-AUTH]。

5. 推荐动作

MSA 应该（SHOULD）执行以下所有动作：

5.1. 强制地址语法

MSA 应该（SHOULD）拒收发件人或收件人 SMTP 信封地址语法非法的消息。

如果 MSA 以任何方式检查或修改消息文本（除非添加追溯头字段），它应该（SHOULD）拒收地址头字段中地址语法非法的消息。

应使用响应码 501 来拒收包含可检测到的不当地址的 MAIL 或 RCPT 命令。

当地址是在提交消息正文之后才被解析时，如果消息头中包含无效地址，则在数据结束（end-of-data）之后使用响应码 554（配合 [SMTP-CODES] 中合适的增强状态码）。

5.2. 记录错误

MSA 应该（SHOULD）记录消息错误，尤其是客户端软件明显的错误配置。

在检测到本地邮件客户端问题时通知管理员可能非常有帮助。这是区分提交与中转的又一好处：系统管理员可能关心本地配置问题，而不关心其他站点的客户端问题。

请注意，对此类记录施加限制以防止某些形式的拒绝服务（DoS）攻击是很重要的。

5.3. 应用更短的超时

RFC 5321 [SMTP-MTA] 第 4.5.3.2 节规定的超时，旨在应对公共互联网上可能遇到的多种情形。与本规范相对应的客户端与服务器之间的关系通常要紧密和可控得多。提交客户端在某些方面（尤其是对超时的容忍度）的表现不同于中转客户端。在实践中，消息提交客户端往往具有较短的超时（对任意命令的回复可能只需 2–5 分钟）。提交服务器应该（SHOULD）在少于 2 分钟的时间内对任何命令（即便是 DATA）作出响应。

当提交服务器与提交客户端之间存在紧密的管理和/或网络关系时——例如，网页邮件（webmail）界面调用一个紧密绑定的提交服务器——双方约定使用更短的超时可能是合适的。

6. 可选动作

MSA 可以（MAY）执行以下任何动作：

6.1. 强制提交权限

如果 MAIL FROM 中的地址似乎提交权限不足，或者（若会话已认证）未被所用认证所授权，MSA 可以（MAY）对 MAIL 命令发出错误响应。

为此目的使用配合 [SMTP-CODES] 的适当增强状态码（例如 5.7.1）的响应码 550。

6.2. 强制许可

如果与授予用户的许可不一致（若会话已认证），MSA 可以（MAY）对 RCPT 命令发出错误响应。

为此目的使用配合 [SMTP-CODES] 的适当增强状态码（例如 5.7.1）的响应码 550。

6.3. 检查消息数据

如果所提交的消息语法无效、似乎与授予用户的许可（若已知）不一致，或以某种方式违反站点策略，MSA 可以（MAY）对 DATA 命令发出错误响应，或在数据结束后发送失败结果。

对于数据中的语法问题使用响应码 554。如果命令本身语法无效，则使用响应码 501。基于提交用户进行拒收时，使用配合 [SMTP-CODES] 的适当增强状态码（例如 5.7.1）的响应码 550。如果消息违反站点策略，则使用配合适当增强状态码（例如 5.7.0）的响应码 550。

6.4. 对 Postmaster 地址的支持

若在当地条件下合适，并且为促进符合 [SMTP-MTA] 对 "postmaster" 的要求，MSA 可以（MAY）允许针对发往一个或多个域中 "postmaster"（或其某一替代拼写形式，见 [SMTP-MTA]）的邮件，采用比其他地址所强制要求更弱程度的认证。

除其他好处外，这提供了一个最后的兜底地址，已授权用户可用来报告那些原本会阻止其提交邮件的问题。

6.5. 调整字符编码

在其他协议和规范所施加的限制范围内，MSA 可以（MAY）在字符集或字符串编码之间进行转换，以提高消息的实用性、投递可能性，或对其他规范或建议的符合度。此类转换在必要时可以包含：使用带外可得的信息，将无法符合 RFC 5321 的编码的地址替换为符合 RFC 5321 的地址。

7. 与 SMTP 扩展的交互

下表列出了其文档未明确说明是否适用于本协议的「标准跟踪」（Standards Track）与「实验性」（Experimental）SMTP 扩展。表中列出了 EHLO 关键字、名称、关于该扩展在提交端口上使用的指示，以及参考文献。

关键字（Keyword）	名称（Name）	提交（Submission）	参考文献
PIPELINING	Pipelining	SHOULD	[PIPELINING]
ENHANCEDSTATUSCODES	Enhanced Status Codes	SHOULD	[CODES-EXTENSION]
…	Extended Codes	SHOULD	[SMTP-CODES]
ETRN	Extended Turn	MUST NOT	[ETRN]
DSN	Delivery Status Notification	SHOULD	[DSN]
SIZE	Message size	MAY	[SIZE]
…	521 reply code	MUST NOT	[REPLY-521]
CHECKPOINT	Checkpoint/Restart	MAY	[CHECKPOINT]
BINARYMIME	Binary MIME	MAY	[CHUNKING]
CHUNKING	Chunking	MAY	[CHUNKING]
8BITMIME	Use 8-bit data	SHOULD	[RFC6152]
AUTH	Authentication	MUST	[SMTP-AUTH]
STARTTLS	Start TLS	MAY	[START-TLS]
NO-SOLICITING	Notification of no soliciting	MAY	[RFC3865]
MTRK	Message Tracking	MAY	[MSG-TRACK]
ATRN	On-Demand Relay	MUST NOT	[RFC2645]
DELIVERBY	Deliver By	MAY	[RFC2852]
CONPERM	Content Conversion Permission	MAY	[RFC4141]
CONNEG	Content Conversion Negotiation	MAY	[RFC4141]

表 1

未来的 SMTP 扩展应该（SHOULD）明确说明其是否在提交端口上有效。

某些 SMTP 扩展对消息提交尤为有用：

增强状态码（Enhanced Status Codes）[SMTP-CODES] 应该（SHOULD）按照 [CODES-EXTENSION] 得到支持和使用。这允许 MSA 以比本备忘录所列响应码更详细的方式，向客户端通知特定的配置或其他问题。由于某些拒收与站点的安全策略有关，应注意不要向未认证的发送方暴露超出所需程度的细节。

[PIPELINING] 应该（SHOULD）由 MSA 支持。

[SMTP-AUTH] 使 MSA 能够验证提交用户的权限并确定其身份，并且必须（MUST）由 MSA 支持。

在撰写本文档时，[START-TLS] 是允许 MUA 与 MSA 保护消息提交完整性与隐私的最广泛使用机制。

本备忘录中对 DATA 命令的任何引用，同样适用于 DATA 的任何替代命令，例如配合 [CHUNKING] 使用的 BDAT 命令。

8. 消息修改

站点可以（MAY）修改提交，以确保符合标准和站点策略。本节描述了一些通常被认为有用的此类修改。

注意：作为对实施消息修改的本地决策的指导，首要规则是将此类动作限于针对具有明确解决方案的特定问题的补救措施。对于地址元素而言尤其如此。例如，不加区分地向缺少域的地址或元素后附加域，通常会导致更多损坏的地址。在能够安全添加域之前，必须验证一个未限定的地址确实是该域中有效的本地部分。

由 MSA 转发或投递的任何消息必须（MUST）符合 [SMTP-MTA] 与 [MESSAGE-FORMAT] 的要求，或符合由 MSA 支持且被下一跳服务器所接受的扩展所允许的要求。

消息修改会影响既有消息签名的有效性，例如域名密钥识别邮件（DKIM）[DKIM]、Pretty Good Privacy（PGP）[RFC4880] 或安全 MIME（S/MIME）[RFC5751] 的签名，并可能使签名失效。这反过来又会影响后续接收方（例如那些依据有效签名的存在与否进行处理的过滤引擎）对消息的处理。

8.1. 添加 'Sender'

如果已知发件人身份且该身份未在 'From' 字段中给出，MSA 可以（MAY）添加或替换 'Sender' 字段。

MSA 必须（MUST）确保它放置在 'Sender' 字段中的任何地址确实是一个有效的邮件地址。

8.2. 添加 'Date'

如果提交的消息缺少 'Date' 字段，或者该字段不符合 [MESSAGE-FORMAT] 语法，MSA 可以（MAY）向提交的消息添加 'Date' 字段，或予以更正。

8.3. 添加 'Message-ID'

如果消息缺少 'Message-ID' 字段，或其语法无效（按 [MESSAGE-FORMAT] 定义），MSA 应该（SHOULD）添加或替换 'Message-ID' 字段。请注意，许多客户端仍然不生成 'Message-ID' 字段。

8.4. 传输编码

如有需要且对 MIME 类型无害，MSA 可以（MAY）按照 MIME 约定对消息施加传输编码。

8.5. 对消息签名

MSA 可以（MAY）对消息（以数字方式）签名，或以其他方式添加认证信息。

8.6. 对消息加密

MSA 可以（MAY）为传输而对消息加密，以反映组织策略。

注意：为了使 MSA 添加签名和/或加密具有实际用处，通常意味着 MUA 与 MSA 之间的连接本身必须以某种其他方式加以保护，例如运行在安全环境之内、在传输层保护提交连接，或使用提供会话完整性的 [SMTP-AUTH] 机制。

8.7. 解析别名

在本地策略约束下，MSA 可以（MAY）解析并重写域名的别名（例如规范名称（CNAME）记录），可在 SMTP 信封中和/或头的地址字段中进行。

注意：SMTP [SMTP-MTA] 禁止在地址与会话开始宣告中使用域名别名。与其他 SMTP 要求一样，RFC 5321 实际上禁止 MSA 将此类消息转发到公共互联网。尽管如此，无条件地解析别名可能是有害的。例如，如果 www.example.net 和 ftp.example.net 都是 mail.example.net 的别名，重写它们可能会丢失有用信息。

8.8. 头字段重写

MSA 可以（MAY）根据本地策略，重写 SMTP 信封中的本地部分和/或域，并可选地重写头地址字段中的本地部分和/或域。例如，站点可能倾向于将 'JRU' 重写为 'J.Random.User' 以隐藏登录名，和/或将 'squeaky.sales.example.net' 重写为 'zyx.example.net' 以隐藏机器名称并便于用户迁移。

然而，只应更改那些与特定本地 MSA 配置设置相匹配的地址、本地部分或域。若 MSA 应用与数据无关的改写规则（例如总是删除域名的第一部分），将非常危险。因此，举例来说，若完整域名匹配 '*.foo.example.net'，则一条剥离该域最左部分的规则是可以接受的。

MSA 不得（MUST NOT）以违反 [SMTP-MTA] 关于修改本地部分的约束的方式，重写一个前向（目的地）地址。若 MSA 拥有足够信息以成功且准确地应用替换，则配合第 6.5 节动作进行的寻址与编码更改不违反本原则。

9. 安全考量

将消息的提交与中转分离，使站点能够为这两类服务实施不同的策略，包括要求对其中之一或两者使用额外的安全机制。它可以用在技术和行政管理上都更简单的方式做到这一点。这增加了策略被正确应用的可能性。

分离也有助于追踪和防范未经请求的大量电子邮件。

例如，站点可以将其邮件服务器配置为：MSA 在接收消息前要求认证，而 MTA 拒收所有针对非本地用户的 RCPT 命令。这可以是站点整体邮件安全策略中的一个重要要素。

如果站点未能要求任何形式的消息提交授权（相关讨论见第 3.3 节），它就是在允许对其资源和名称的开放使用；未经请求的大量电子邮件可以利用其设施被注入。

第 3 节包含对某些认证方法问题的进一步讨论。

第 5.2 节包含一条警示：无限制的记录可能助长某些形式的拒绝服务攻击。

10. IANA 考量

表 1 中的条目已被更正（NO-SOLICITING 的参考文献）并扩充（ATRN、DELIVERBY、CONPERM 和 CONNEG）。「SMTP 服务扩展」（SMTP Service Extensions）注册表已更新，以反映更改后的和新增加的条目。注册表中未出现在上表中的条目是正确的，不应更改。

「SMTP 服务扩展」注册表中针对 RFC 4409 的条目已更新为引用本文档。原本针对 Submit（RFC 2476）的引用（本应更早被更正）也已更新为指向本文档。

「服务名称与传输协议端口号注册表」（Service Name and Transport Protocol Port Number Registry）中针对 587 端口的条目已更新为指向本文档。

11. 致谢

本规范当前版本的准备与制定，受到了 IETF YAM 与 EAI 工作组讨论的推动。Dave Crocker、Subramanian Moonesamy、Barry Leiba、John Levine 等人提供了出现在本文档或其前期版本中的文字。

Nathaniel Borenstein 和 Barry Leiba 对 RFC 4409（即 RFC 2476 的更新）的制定起到了关键作用。

原始备忘录（RFC 2476）的制定，部分基于在 IETF-Submit 邮件列表上及列表外发生的评论与讨论。感谢那些抽出时间审阅该文档并提出建议的人，尤其是 Dave Crocker、Ned Freed、Keith Moore、John Myers 和 Chris Newman。

特别感谢 Harald Alvestrand，是他启动了这一工作。

12. 参考文献

12.1. 规范性参考文献

[KEYWORDS]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels"（用于 RFC 中指示要求等级的关键词）, BCP 14, RFC 2119, 1997 年 3 月。

[SMTP-AUTH]

Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication"（用于认证的 SMTP 服务扩展）, RFC 4954, 2007 年 7 月。

[SMTP-MTA]

Klensin, J., "Simple Mail Transfer Protocol"（简单邮件传输协议）, RFC 5321, 2008 年 10 月。

12.2. 资料性参考文献

[CHECKPOINT]

Crocker, D. and N. Freed, "SMTP Service Extension for Checkpoint/Restart"（SMTP 检查点/重启服务扩展）, RFC 1845, 1995 年 9 月。

[CHUNKING]

Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages"（用于传输大型与二进制 MIME 消息的 SMTP 服务扩展）, RFC 3030, 2000 年 12 月。

[CODES-EXTENSION]

Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes"（用于返回增强错误码的 SMTP 服务扩展）, RFC 2034, 1996 年 10 月。

[DKIM]

Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures"（域名密钥识别邮件（DKIM）签名）, RFC 6376, 2011 年 9 月。

[DSN]

Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)"（用于投递状态通知的 SMTP 服务扩展）, RFC 3461, 2003 年 1 月。

[ETRN]

De Winter, J., "SMTP Service Extension for Remote Message Queue Starting"（用于远程消息队列启动的 SMTP 服务扩展）, RFC 1985, 1996 年 8 月。

[IMAP4]

Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"（互联网消息访问协议 - 版本 4rev1）, RFC 3501, 2003 年 3 月。

[IPSEC]

Kent, S. and K. Seo, "Security Architecture for the Internet Protocol"（互联网协议的安全架构）, RFC 4301, 2005 年 12 月。

[MESSAGE-FORMAT]

Resnick, P., Ed., "Internet Message Format"（互联网报文格式）, RFC 5322, 2008 年 10 月。

[MSG-TRACK]

Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking"（用于消息追踪的 SMTP 服务扩展）, RFC 3885, 2004 年 9 月。

[PIPELINING]

Freed, N., "SMTP Service Extension for Command Pipelining"（用于命令流水线的 SMTP 服务扩展）, STD 60, RFC 2920, 2000 年 9 月。

[POP3]

Myers, J. and M. Rose, "Post Office Protocol - Version 3"（邮局协议 - 版本 3）, STD 53, RFC 1939, 1996 年 5 月。

[REPLY-521]

Durand, A. and F. Dupont, "SMTP 521 Reply Code"（SMTP 521 回复码）, RFC 1846, 1995 年 9 月。

[RFC2645]

Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses"（具备动态 IP 地址的按需邮件中继（ODMR）SMTP）, RFC 2645, 1999 年 8 月。

[RFC2852]

Newman, D., "Deliver By SMTP Service Extension"（按投递时限 SMTP 服务扩展）, RFC 2852, 2000 年 6 月。

[RFC3865]

Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension"（无招揽 SMTP 服务扩展）, RFC 3865, 2004 年 9 月。

[RFC4141]

Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion"（用于内容转换的 SMTP 与 MIME 扩展）, RFC 4141, 2005 年 11 月。

[RFC4880]

Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format"（OpenPGP 报文格式）, RFC 4880, 2007 年 11 月。

[RFC5751]

Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification"（安全/多用途互联网邮件扩展（S/MIME）3.2 版报文规范）, RFC 5751, 2010 年 1 月。

[RFC6152]

Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport"（用于 8 位 MIME 传输的 SMTP 服务扩展）, STD 71, RFC 6152, 2011 年 3 月。

[SIZE]

Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration"（用于声明消息大小的 SMTP 服务扩展）, STD 10, RFC 1870, 1995 年 11 月。

[SMTP-CODES]

Vaudreuil, G., "Enhanced Mail System Status Codes"（增强邮件系统状态码）, RFC 3463, 2003 年 1 月。

[START-TLS]

Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security"（基于传输层安全的安全 SMTP 服务扩展）, RFC 3207, 2002 年 2 月。

附录 A. 相对于 RFC 4409 的主要变更

本文档所规定的协议与 RFC 4409 并无实质性差异。不过，本规范包含了若干澄清与更新，以反映 RFC 4409 发布之后其他文档的变化与修订。以下具体变更可能会引起部分读者的兴趣。

• 更新了若干参考文献，以反映各规范较新的版本。作为其中一部分，将 RFC 4954 重新归类为规范性参考文献（SMTP AUTH 对于 RFC 4409 以及本规范均为 MUST）。
• 更新了第 7 节的文字，以反映注册表的存在及部分填充，并包含表 1 用于更正一个条目和增加其他条目。更多信息见第 10 节。
• 新增了文字（第 5.3 节），以澄清提交服务器应当快速响应。
• 新增了文字，以明确允许字符编码的更改。
• 新增了文字，以表明对经签名消息的修改可能引发问题，应当谨慎考虑。

作者地址

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-2779
USA
EMail: rg+ietf@qualcomm.com

John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com