1. Introduction (简介)

1.1. Transport of Electronic Mail (电子邮件传输)

简单邮件传输协议 (Simple Mail Transfer Protocol, SMTP) 的目标是可靠且高效地传输邮件。

SMTP独立于特定的传输子系统，仅需要一个可靠的有序数据流通道。虽然本文档专门讨论基于TCP的传输，但也可以使用其他传输方式。RFC 821 [1] 的附录描述了其中一些方式。

SMTP的一个重要特性是能够跨多个网络传输邮件，通常称为"SMTP邮件中继"(SMTP mail relaying, 参见第3.6节)。网络可以由公共互联网上相互可通过TCP访问的主机、防火墙隔离的TCP/IP内网上相互可通过TCP访问的主机、或使用非TCP传输层协议的某些其他LAN或WAN环境中的主机组成。使用SMTP，进程可以将邮件传输到同一网络上的另一个进程，或者通过两个网络都可以访问的中继或网关进程传输到其他网络。

通过这种方式，邮件消息可以在从发件人到最终收件人的路径上经过多个中间中继或网关主机。域名系统 (Domain Name System) 的邮件交换器 (Mail eXchanger) 机制 (RFC 1035 [2], RFC 974 [12], 以及本文档的第5节) 用于确定正在传输的消息的适当下一跳目标。

1.2. History and Context for This Document (本文档的历史与背景)

本文档是互联网电子邮件传输基本协议的规范。它整合、更新并阐明了以下文档，但不添加新功能或更改现有功能:

• RFC 821 [1] 的原始SMTP (Simple Mail Transfer Protocol) 规范,

• RFC 1035 [2] 和RFC 974 [12] 中关于邮件传输的域名系统要求和影响,

• RFC 1123 [3] 中的澄清和适用性声明, 以及

• 从RFC 1869 [13] 中SMTP扩展机制提取的材料。

• 对RFC 2821 [14] 的编辑性和澄清性修改，使该规范达到标准草案 (Draft Standard) 级别。

本文档废止了RFC 821, RFC 974, RFC 1869和RFC 2821，并更新了RFC 1123 (取代RFC 1123中的邮件传输材料)。然而，RFC 821指定了一些在1990年代中期之前在互联网上没有显著使用的功能，以及(在附录中)一些额外的传输模型。为了清晰和简洁，这些部分在此处被省略; 需要它们的读者应参考RFC 821。

本文档还包含了一些需要扩充的RFC 1123中的额外材料。这些材料已通过多种方式识别，主要是通过跟踪各种列表和新闻组上的讨论，以及在部署SMTP扩展时出现的不寻常解读或解释问题。在本规范超越整合并实际上与早期文档不同的地方，它在技术上和文本上都取代了它们。

虽然SMTP被设计为邮件传输和投递协议，但本规范还包含了对其作为"邮件提交" (mail submission) 协议使用的重要信息，如邮局协议 (Post Office Protocol, POP) (RFC 937 [15], RFC 1939 [16]) 和IMAP (RFC 3501 [17]) 所推荐的那样。一般来说，RFC 4409 [18] 中指定的独立邮件提交协议现在优先于直接使用SMTP; 关于该主题的更多讨论出现在该文档中。

第2.3节提供了本文档特定术语的定义。除非需要历史术语来清晰说明，本文档使用当前的"客户端" (client) 和"服务器" (server) 术语来分别标识发送和接收SMTP进程。

配套文档RFC 5322 [4] 讨论了消息头部分 (header sections) 和正文 (bodies)，并指定了它们的格式和结构。

1.3. Document Conventions (文档约定)

本文档中的关键词"MUST" (必须), "MUST NOT" (禁止), "REQUIRED" (必需), "SHALL" (应), "SHALL NOT" (不应), "SHOULD" (应该), "SHOULD NOT" (不应该), "RECOMMENDED" (推荐), "MAY" (可以), 和"OPTIONAL" (可选) 应按照RFC 2119 [5] 中的描述进行解释。由于这些术语中的每一个都是有意且精心选择以改善电子邮件的互操作性的，因此这些术语的每次使用都应被视为一致性要求。

由于本文档有很长的历史，并且为了避免各种错误的风险以及混淆指向本文档的读者和文档，大多数示例及其包含的域名都保留自RFC 2821。提醒读者，这些是说明性示例，实际上不应在代码或配置文件中使用。