Network Working Group C. Hutzler
Request for Comments: 5068
BCP: 134 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
P. Resnick
QUALCOMM Incorporated
E. Allman
Sendmail, Inc.
T. Finch
University of Cambridge Computing Service
November 2007
Network Working Group C. Hutzler
Request for Comments: 5068
BCP: 134 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
P. Resnick
QUALCOMM Incorporated
E. Allman
Sendmail, Inc.
T. Finch
University of Cambridge Computing Service
November 2007
Email Submission Operations: Access and Accountability Requirements
电子邮件提交操作：访问和责任要求
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
电子邮件已经成为一种流行的分发服务，用于各种社会上不可接受的、大众效应的目的。最明显的包括垃圾邮件和蠕虫。本说明建议在企业和互联网服务提供商等独立运营商之间使用电子邮件提交和传输服务的约定。其目标是改善控制滥用互联网邮件服务的责任线。为此，本文件为电子邮件提交和传输服务的独立运营商之间的建设性运营政策提供了建议。
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document.
电子邮件认证技术的目的是在互联网络之间提供保证和可追溯性。在许多电子邮件服务中，保证链中最薄弱的环节是首次提交邮件。本文件为电子邮件发送的第一步，即向传输网络提交（或发布）电子邮件，提供了建设性操作政策的建议。转发和交付包含提交后发生的政策，不在本文件范围内。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 4
3.1. Best Practices for Submission Operation . . . . . . . . . 5
3.2. Transitioning to Submission Port . . . . . . . . . . . . . 6
4. External Submission . . . . . . . . . . . . . . . . . . . . . 6
4.1. Best Practices for Support of External Submissions . . . . 7
5. Message Submission Authentication/Authorization
Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 4
3.1. Best Practices for Submission Operation . . . . . . . . . 5
3.2. Transitioning to Submission Port . . . . . . . . . . . . . 6
4. External Submission . . . . . . . . . . . . . . . . . . . . . 6
4.1. Best Practices for Support of External Submissions . . . . 7
5. Message Submission Authentication/Authorization
Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
The very characteristics that make email such a convenient communications medium -- its near ubiquity, rapid delivery, low cost, and support for exchanges without prior arrangement -- have made it a fertile ground for the distribution of unwanted or malicious content. Spam, fraud, and worms have become a serious problem, threatening the viability of email and costing end users and providers millions of dollars in damages and lost productivity. In recent years, independent operators including enterprises and ISPs have turned to a number of different technologies and procedures, in an attempt to combat these problems. The results have been mixed, at best.
电子邮件作为一种便捷的通信媒介的特点——它几乎无处不在，传递速度快，成本低，并且支持在没有事先安排的情况下进行交流——使其成为传播不需要的或恶意内容的肥沃土壤。垃圾邮件、欺诈和蠕虫已经成为一个严重的问题，威胁到电子邮件的生存能力，并使最终用户和提供商损失数百万美元的损失和生产力的损失。近年来，包括企业和ISP在内的独立运营商已采用了许多不同的技术和程序，试图解决这些问题。结果好坏参半，充其量也不尽相同。
En route to its final destination, email will often travel between multiple independent providers of email transmission services. These services will generally have no prior arrangement with one another and may employ different rules on the transmission. It is therefore difficult both to debug problems that occur in mail transmission and to assign accountability if undesired or malicious mail is injected into the Internet mail infrastructure.
在到达最终目的地的途中，电子邮件通常会在多个独立的电子邮件传输服务提供商之间传输。这些服务通常彼此之间没有事先安排，并且可能对传输采用不同的规则。因此，如果不希望的或恶意的邮件被注入到Internet邮件基础结构中，则很难调试邮件传输中出现的问题，也很难分配责任。
Many email authentication technologies exist. They provide some accountability and traceability between disparate networks. This document aims to build upon the availability of these technologies by exploring best practices for authenticating and authorizing the first step of an email's delivery, from a Mail User Agent (MUA) to a Mail Submission Agent (MSA), known as submission. Without strong practices on email submission, the use of authentication technologies elsewhere in the service provides limited benefit.
存在许多电子邮件身份验证技术。它们在不同的网络之间提供了一些责任和可追溯性。本文档旨在通过探索从邮件用户代理（MUA）到邮件提交代理（MSA）（称为提交）的电子邮件发送的第一步认证和授权的最佳实践，以这些技术的可用性为基础。在电子邮件提交方面没有强有力的实践，在服务的其他地方使用身份验证技术带来的好处有限。
This document specifies operational policies to be used for the first step of email sending, the submission -- or posting from an MUA to an MSA as defined below -- of email into the transmission service. These policies will permit continued, smooth operation of Internet email, with controls added to improve accountability. Relaying and delivering employ policies that occur after submission and are outside the scope of this document. The policies listed here are appropriate for operators of all sizes of networks and may be implemented by operators independently, without regard for whether the other side of an email exchange has implemented them.
本文件规定了用于电子邮件发送第一步的操作策略，即将电子邮件提交（或从MUA发送至MSA，定义见下文）至传输服务。这些政策将允许互联网电子邮件的持续、顺利运行，并增加控制措施以提高问责制。转发和交付提交后发生且不在本文件范围内的雇佣政策。此处列出的策略适用于各种规模的网络运营商，运营商可以独立实施，而不考虑电子邮件交换的另一方是否实施了这些策略。
It is important to note that the adoption of these policies alone will not solve the problems of spam and other undesirable email. However, these policies provide a useful step in clarifying lines of accountability and interoperability between operators. This helps raise the bar against abusers and provides a foundation for additional tools to preserve the utility of the Internet email infrastructure.
需要注意的是，仅采用这些政策并不能解决垃圾邮件和其他不受欢迎的电子邮件问题。然而，这些政策为澄清运营商之间的责任和互操作性提供了有用的一步。这有助于提高反对滥用者的门槛，并为额外的工具来保护互联网电子邮件基础设施的实用性提供基础。
NOTE: This document does not delve into other anti-spam operational issues such as standards for rejection of email. The authors note that this could be a valuable effort to undertake and encourage its pursuit.
注意：本文档未深入探讨其他反垃圾邮件操作问题，例如拒绝电子邮件的标准。作者指出，这可能是一项有价值的努力，以承担和鼓励其追求。
The Internet email architecture distinguishes four message-handling components:
Internet电子邮件体系结构区分了四个邮件处理组件：
o Mail User Agents (MUAs)
o 邮件用户代理（MUA）
o Mail Submission Agents (MSAs)
o 邮件提交代理（MSA）
o Mail Transfer Agents (MTAs)
o 邮件传输代理（MTA）
o Mail Delivery Agents (MDAs)
o 邮件传递代理（MDA）
At the origination end, an MUA works on behalf of end users to create a message and perform initial "submission" into the transmission infrastructure, via an MSA. An MSA accepts the message submission, performs any necessary preprocessing on the message, and relays the message to an MTA for transmission. MTAs 'relay' messages to other MTAs, in a sequence reaching a destination MDA that, in turn, 'delivers' the email to the recipient's inbox. The inbox is part of the recipient-side MUA that works on behalf of the end user to process received mail.
在发起端，MUA代表最终用户创建消息，并通过MSA向传输基础设施执行初始“提交”。MSA接受邮件提交，对邮件执行任何必要的预处理，并将邮件转发给MTA进行传输。MTA将邮件“中继”到其他MTA，并按顺序到达目标MDA，然后将电子邮件“传递”到收件人的收件箱。收件箱是接收方MUA的一部分，代表最终用户处理收到的邮件。
These architectural components are often compressed, such as having the same software do MSA, MTA and MDA functions. However the requirements for each of these components of the architecture are becoming more extensive, so that their software and even physical platform separation is increasingly common.
这些体系结构组件通常是压缩的，例如具有相同的软件执行MSA、MTA和MDA功能。然而，对体系结构的每一个组件的需求都变得越来越广泛，因此它们的软件甚至物理平台分离越来越普遍。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Originally the MSA, MTA, and MDA architectural components were considered to be a single unit. This was reflected in the practice of having MSA, MTA, and MDA transfers all be performed with SMTP [RFC2821] [RFC0821], over TCP port 25. Internet mail permits email to be exchanged without prior arrangement and without sender authentication. That is, the confirmed identity of the originator of the message is not necessarily known by the relaying MTAs or the MDA.
最初，MSA、MTA和MDA体系结构组件被视为一个单元。这反映在让MSA、MTA和MDA传输都通过TCP端口25通过SMTP[RFC2821][RFC0821]执行的实践中。互联网邮件允许在没有事先安排和发件人身份验证的情况下交换电子邮件。也就是说，中继MTA或MDA不一定知道消息发起人的已确认身份。
It is important to distinguish MUA-to-MSA email submission, versus MTA relaying, versus the final MTA-to-MDA transition. Submission typically does entail a pre-established relationship between the user of the client and operator of the server; equally, the MDA is performing final delivery and can determine that it has an existing relationship with the recipient. That is, MSAs and MDAs can take advantage of having prior relationships with users in order to constrain their transfer activities.
区分MUA到MSA的电子邮件提交、MTA中继和最终MTA到MDA的转换非常重要。提交通常需要客户机用户和服务器操作员之间预先建立的关系；同样，MDA正在执行最终交付，并且可以确定它与接收者之间存在关系。也就是说，MSA和MDA可以利用与用户的先前关系来约束他们的传输活动。
Specifically, an MSA can choose to reject all postings from MUAs for which it has no existing relationship. Similarly, an MDA can choose to reject all mail to recipients for which it has no arrangement to perform delivery. Indeed, both of these policies are already in common practice.
具体而言，MSA可以选择拒绝MUA中与其没有现有关系的所有帖子。类似地，MDA可以选择拒绝发送给收件人的所有邮件，因为它没有安排对这些邮件执行传递。事实上，这两项政策都已成为普遍做法。
Submission Port Availability:
提交端口可用性：
If external submissions are supported -- that is, from outside a site's administrative domain -- then the domain's MSAs MUST support the SUBMISSION port 587 [RFC4409]. Operators MAY standardize on the SUBMISSION port for both external AND LOCAL users; this can significantly simplify submission operations.
如果支持外部提交（即从站点的管理域外部提交），则域的MSA必须支持提交端口587[RFC4409]。运营商可以为外部和本地用户标准化提交端口；这可以大大简化提交操作。
Submission Port Use:
提交端口使用：
MUAs SHOULD use the SUBMISSION port for message submission.
MUA应使用提交端口提交消息。
Submission Authentication:
提交验证：
MSAs MUST perform authentication on the identity asserted during all mail transactions on the SUBMISSION port, even for a message having a RCPT TO address that would not cause the message to be relayed outside of the local administrative domain.
MSA必须对提交端口上的所有邮件事务期间声明的身份执行身份验证，即使对于具有RCPT TO地址的邮件，也不会导致邮件在本地管理域之外中继。
Submission Authorization:
提交授权：
An operator of an MSA MUST ensure that the authenticated identity is authorized to submit email, based on an existing relationship between the submitting entity and the operator. This requirement applies to all mail submission mechanisms (MUA to MSA).
MSA的运营商必须确保基于提交实体和运营商之间的现有关系，授权认证身份提交电子邮件。此要求适用于所有邮件提交机制（MUA至MSA）。
Submission Accountability after Submission:
提交后的提交责任：
For a reasonable period of time after submission, the message SHOULD be traceable by the MSA operator to the authenticated identity of the user who sent the message. Such tracing MAY be
在提交后的一段合理时间内，MSA操作员应可追踪到发送消息的用户的身份验证。这种追踪可能是错误的
based on transactional identifiers stored in the headers (received lines, etc.) or other fields in the message, on audit data stored elsewhere, or on any other mechanism that supports sufficient post-submission accountability. The specific length of time, after message submission, that traceability is supported is not specified here. However, issues regarding transit often occur as much as one week after submission.
基于存储在消息头（接收行等）或其他字段中的事务标识符、存储在其他位置的审核数据或支持充分提交后责任的任何其他机制。在消息提交后，支持可追溯性的具体时间长度在此未指定。然而，有关过境的问题往往在提交后一周内发生。
Note that [RFC3848] defines a means of recording submission-time information in Received header fields. This information can help receive-side analysis software establish a sending MSA's accountability and then make decisions about processing the message.
请注意，[RFC3848]定义了在接收到的报头字段中记录提交时间信息的方法。该信息有助于接收端分析软件建立发送MSA的责任，然后做出处理消息的决定。
In order to promote transition of initial message submission from port 25 to port 587, MSAs MUST listen on port 587 by default and SHOULD have the ability to listen on other ports. MSAs MUST require authentication on port 587 and SHOULD require authentication on any other port used for submission. MSAs MAY also listen on other ports. Regardless of the ports on which messages are accepted, MSAs MUST NOT permit relaying of unauthenticated messages to other domains. That is, they must not be open relays.
为了促进初始消息提交从端口25到端口587的转换，MSA默认情况下必须侦听端口587，并且应该能够侦听其他端口。MSA必须要求在端口587上进行身份验证，并且应要求在用于提交的任何其他端口上进行身份验证。MSA也可以侦听其他端口。无论接受消息的端口是什么，MSA都不得允许将未经验证的消息中继到其他域。也就是说，它们不能是开路继电器。
As a default, MUAs SHOULD attempt to find the best possible submission port from a list of alternatives. The SUBMISSION port 587 SHOULD be placed first in the list. Since most MUAs available today do not permit falling back to alternate ports, sites SHOULD pre-configure or encourage their users to connect on the SUBMISSION port 587, assuming that site supports that port.
默认情况下，MUA应尝试从备选方案列表中找到最佳的提交端口。提交端口587应放在列表的第一位。由于目前可用的大多数MUA不允许退回到备用端口，因此站点应预先配置或鼓励其用户连接到提交端口587，前提是站点支持该端口。
An MUA might need to submit mail across the Internet, rather than to a local MSA, in order to obtain particular services from its home site. Examples include active privacy protection against third-party content monitoring, timely processing, and being subject to the most appropriate authentication and accountability protocols. Further, the privacy requirement might reasonably include protection against monitoring by the operator of the MUA's access network. This requirement creates a challenge for the provider operating the IP network through which the MUA gains access. It makes that provider an involuntary recruit to the task of solving mass-effect email problems: When the MUA participates in a problem that affects large numbers of Internet users, the provider is expected to effect remedies and is often expected to prevent such occurrences.
MUA可能需要通过互联网而不是向本地MSA提交邮件，以便从其主页获得特定服务。示例包括针对第三方内容监控的主动隐私保护、及时处理以及遵守最合适的身份验证和问责协议。此外，隐私要求可能合理地包括防止MUA接入网络的运营商监控。这一要求给运营IP网络的提供商带来了挑战，MUA通过该网络获得访问权。它使该提供商成为解决大规模效应电子邮件问题的非自愿招募者：当MUA参与影响大量互联网用户的问题时，提供商应采取补救措施，并且通常应防止此类事件的发生。
A proactive technique used by some providers is to block all use of port 25 SMTP for mail that is being sent outbound, or to automatically redirect this traffic through a local SMTP proxy, except for hosts that are explicitly authorized. This can be problematic for some users, notably legitimate mobile users attempting to use their "home" MSA, even though those users might already employ legitimate, port 25-based authentication.
某些提供商使用的一种主动预防性技术是阻止所有使用端口25 SMTP发送出站的邮件，或通过本地SMTP代理自动重定向此通信量，明确授权的主机除外。这对某些用户来说可能是个问题，尤其是试图使用其“家庭”MSA的合法移动用户，即使这些用户可能已经使用了基于端口25的合法身份验证。
This document offers no recommendation concerning the blocking of SMTP port 25 or similar practices for controlling abuse of the standard anonymous mail transfer port. Rather, it pursues the mutually constructive benefit of using the official SUBMISSION port 587 [RFC4409].
本文件不提供有关阻止SMTP端口25或类似做法以控制滥用标准匿名邮件传输端口的建议。相反，它追求使用官方提交端口587[RFC4409]的相互建设性利益。
NOTE: Many established practices for controlling abuse of port 25, for mail that is being sent outbound, currently do exist. These include the proxy of SMTP traffic to local hosts for screening, combined with various forms of rate limits. The authors suggest that a separate document on this topic would benefit the email operations community.
注意：目前确实存在许多控制滥用端口25的既定做法，用于将邮件发送到外部。其中包括将SMTP通信代理到本地主机进行筛选，并结合各种形式的速率限制。作者建议，关于此主题的单独文档将有利于电子邮件操作社区。
Open Submission Port:
打开提交端口：
Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587 [RFC4409].
访问提供商不得阻止用户使用提交端口587[RFC4409]访问外部互联网。
Traffic Identification -- External Posting (MSA) Versus Relaying (MX):
流量标识——外部发布（MSA）与中继（MX）：
When receiving email from outside their local operational environment, email service providers MUST distinguish between unauthenticated email addressed to local domains (MX traffic) versus submission-related authenticated email that can be addressed anywhere (MSA traffic). This allows the MTA to restrict relaying operations, and thereby prevent "open" relays. Note that there are situations where this may not apply, such as secondary MXs and related implementations internal to an operator's network and within their control.
当从本地运营环境外部接收电子邮件时，电子邮件服务提供商必须区分发往本地域的未经验证的电子邮件（MX流量）和可以发往任何地方的提交相关的经验证电子邮件（MSA流量）。这允许MTA限制中继操作，从而防止“打开”中继。请注意，在某些情况下，这可能不适用，例如辅助MX和运营商网络内部及其控制范围内的相关实现。
Figure 1 depicts a local user (MUA.l) submitting a message to an MSA (MSA). It also shows a remote user (MUA.r), such as might be in a coffee shop offering "hotspot" wireless access, submitting a message to their "home" MSA via an authenticated port 587 transaction. The figure shows the alternative of using port 587 or port 25 within the MSA's network. This document makes no recommendations about the use
图1描述了一个本地用户（MUA.l）向MSA（MSA）提交消息。它还显示了远程用户（MUA.r），例如可能在提供“热点”无线访问的咖啡馆中，通过经过身份验证的端口587事务向其“家庭”MSA提交消息。该图显示了在MSA网络内使用端口587或端口25的备选方案。本文件未对使用提出任何建议
of port 25 for submission. The diagram merely seeks to note that it is in common use and to acknowledge that port 25 can be used with sufficient accountability within an organization's network.
提交第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
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
图1：通过互联网使用587端口的示例
There are many competent technologies and standards for authenticating message submissions. Two component mechanisms that have been standardized include SMTP AUTH [RFC4954] and TLS [RFC3207]. Depending upon the environment, different mechanisms can be more or less effective and convenient. Mechanisms might also have to be used in combination with each other to make a secure system. Organizations SHOULD choose the most secure approaches that are practical.
有许多称职的技术和标准用于验证消息提交。标准化的两个组件机制包括SMTP认证[RFC4954]和TLS[RFC3207]。根据环境的不同，不同的机制可能或多或少有效和方便。机制可能还必须相互结合使用，以形成一个安全的系统。组织应该选择最安全、最实用的方法。
This document does not provide recommendations on specific security implementations. It simply provides a warning that transmitting user credentials in clear text over insecure networks SHOULD be avoided in all scenarios as this could allow attackers to listen for this traffic and steal account data. In these cases, it is strongly suggested that an appropriate security technology MUST be used.
本文档不提供有关特定安全实现的建议。它只是提供了一个警告，即在所有情况下都应避免在不安全的网络上以明文形式传输用户凭据，因为这可能使攻击者监听此流量并窃取帐户数据。在这些情况下，强烈建议必须使用适当的安全技术。
Email transfer between independent administrations can be the source of large volumes of unwanted email and email containing malicious content designed to attack the recipient's system. This document addresses the requirements and procedures to permit such exchanges while reducing the likelihood that malicious mail will be transmitted.
独立管理机构之间的电子邮件传输可能是大量不需要的电子邮件和包含恶意内容的电子邮件的来源，这些内容旨在攻击收件人的系统。本文件阐述了允许此类交换的要求和程序，同时降低了恶意邮件传输的可能性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2005.
[RFC3848]Newman，C.，“ESMTP和LMTP传输类型登记”，RFC 3848，2005年7月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
These recommendations were first formulated during informal discussions among members of Anti-Spam Technical Alliance (ASTA) and some participants from the Internet Research Task Force's Anti-Spam Research Group (ASRG).
这些建议最初是在反垃圾邮件技术联盟（ASTA）成员和互联网研究工作队反垃圾邮件研究小组（ASRG）的一些参与者之间的非正式讨论中制定的。
Later reviews and suggestions were provided by: 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.
后来的评论和建议由以下人员提供：M.奥尔曼、L.H.埃斯特朗、N.博伦斯坦、S.博尔茨迈耶、K.琼、R.克莱顿、B.科尔、W.德内斯、V.杜科夫尼、E.埃德斯坦、F.埃勒曼、M.艾维、J.D.福尔克、N.弗里德、J.格鲁贝、A.赫茨伯格、J.克莱辛、J.莱文、S.穆内萨米、K.摩尔、R.纳尔逊、C.纽曼、C.奥马利、S.拉曼尼亚、，罗格利、圣索弗、施利特、谢恩、沙利文。
Authors' Addresses
作者地址
Carl Hutzler 2512 Freetown Drive Reston, VA 20191
卡尔·哈茨勒，弗吉尼亚州雷斯顿弗里敦大道2512号，邮编20191
Phone: 703-915-6862
EMail: cdhutzler@aol.com
URI: http://carlhutzler.com/blog/
Phone: 703-915-6862
EMail: cdhutzler@aol.com
URI: http://carlhutzler.com/blog/
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Peter Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA
Peter Resnick高通公司美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121-1714
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Eric Allman Sendmail, Inc. 6745 Christie Ave., Suite 350 Emeryville, CA USA
Eric Allman Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6745号350室
Phone: +1 510 594 5501
EMail: eric+ietf-smtp@sendmail.org
Phone: +1 510 594 5501
EMail: eric+ietf-smtp@sendmail.org
Tony Finch University of Cambridge Computing Service New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND
托尼芬奇剑桥大学计算服务新博物馆遗址彭布罗克街剑桥CB2 3QH英格兰
Phone: +44 797 040 1426
EMail: dot@dotat.at
URI: http://dotat.at/
Phone: +44 797 040 1426
EMail: dot@dotat.at
URI: http://dotat.at/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.