Network Working Group P. Hoffman
Request for Comments: 2487 Internet Mail Consortium
Category: Standards Track January 1999
Network Working Group P. Hoffman
Request for Comments: 2487 Internet Mail Consortium
Category: Standards Track January 1999
SMTP Service Extension for Secure SMTP over TLS
用于TLS上安全SMTP的SMTP服务扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.
本文档介绍SMTP服务的扩展，该扩展允许SMTP服务器和客户端使用传输层安全性在Internet上提供经过身份验证的私有通信。这使SMTP代理能够保护其部分或全部通信免受窃听者和攻击者的攻击。
SMTP [RFC-821] servers and clients normally communicate in the clear over the Internet. In many cases, this communication goes through one or more router that is not controlled or trusted by either entity. Such an untrusted router might allow a third party to monitor or alter the communications between the server and client.
SMTP[RFC-821]服务器和客户端通常通过Internet以明文形式进行通信。在许多情况下，这种通信通过一个或多个不受任何实体控制或信任的路由器进行。这种不受信任的路由器可能允许第三方监视或更改服务器和客户端之间的通信。
Further, there is often a desire for two SMTP agents to be able to authenticate each others' identities. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know.
此外，通常需要两个SMTP代理能够验证彼此的身份。例如，安全SMTP服务器可能只允许来自它知道的其他SMTP代理的通信，或者对于从它知道的代理接收的邮件，它的行为可能与从它不知道的代理接收的邮件不同。
TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing TCP communications with privacy and authentication. TLS is in wide use with the HTTP protocol, and is also being used for adding security to many other common protocols that run over TCP.
TLS[TLS]，通常称为SSL，是一种通过隐私和身份验证增强TCP通信的流行机制。TLS在HTTP协议中得到广泛使用，并且还用于为运行在TCP上的许多其他常见协议添加安全性。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
The STARTTLS extension to SMTP is laid out as follows:
SMTP的STARTTLS扩展如下所示：
(1) the name of the SMTP service defined here is STARTTLS;
(1) 此处定义的SMTP服务的名称为STARTTLS；
(2) the EHLO keyword value associated with the extension is STARTTLS;
(2) 与扩展关联的EHLO关键字值为STARTTLS；
(3) the STARTTLS keyword has no parameters;
(3) STARTTLS关键字没有参数；
(4) a new SMTP verb, "STARTTLS", is defined;
(4) 定义了一个新的SMTP动词“STARTTLS”；
(5) no additional parameters are added to any SMTP command.
(5) 没有向任何SMTP命令添加其他参数。
The STARTTLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS. It takes no parameters.
STARTTLS关键字用于通知SMTP客户端SMTP服务器允许使用TLS。它不需要参数。
The format for the STARTTLS command is:
STARTTLS命令的格式为：
STARTTLS
STARTTLS
with no parameters.
没有参数。
After the client gives the STARTTLS command, the server responds with one of the following reply codes:
客户机发出STARTTLS命令后，服务器用以下回复代码之一进行响应：
220 Ready to start TLS 501 Syntax error (no parameters allowed) 454 TLS not available due to temporary reason
220准备启动TLS 501语法错误（不允许参数）454由于临时原因TLS不可用
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.
公开引用的SMTP服务器不得要求使用STARTTLS扩展才能在本地传递邮件。此规则防止STARTTLS扩展破坏Internet SMTP基础结构的互操作性。公开引用的SMTP服务器是一个SMTP服务器，它运行在Internet邮件地址右侧域名的MX记录（或MX记录不存在时的记录）中列出的Internet主机的端口25上。
Any SMTP server may refuse to accept messages for relay based on authentication supplied during the TLS negotiation. An SMTP server that is not publicly referenced may refuse to accept any messages for relay or local delivery based on authentication supplied during the TLS negotiation.
根据TLS协商期间提供的身份验证，任何SMTP服务器都可能拒绝接受用于中继的邮件。未公开引用的SMTP服务器可能会根据TLS协商期间提供的身份验证拒绝接受任何用于中继或本地传递的邮件。
A SMTP server that is not publicly referenced may choose to require that the client perform a TLS negotiation before accepting any commands. In this case, the server SHOULD return the reply code:
未公开引用的SMTP服务器可以选择要求客户端在接受任何命令之前执行TLS协商。在这种情况下，服务器应返回回复代码：
530 Must issue a STARTTLS command first
530必须首先发出STARTTLS命令
to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034], the status code to be returned SHOULD be 5.7.0.
除了NOOP、EHLO、STARTTLS或QUIT之外的所有命令。如果客户端和服务器正在使用ENHANCEDSTATUSCODES ESMTP扩展[RFC-2034]，则返回的状态代码应为5.7.0。
After receiving a 220 response to a STARTTLS command, the client SHOULD start the TLS negotiation before giving any other SMTP commands.
在收到对STARTTLS命令的220响应后，客户端应在发出任何其他SMTP命令之前启动TLS协商。
If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS command must be the last command in a group.
如果SMTP客户端使用RFC 1854中定义的管道，则STARTTLS命令必须是组中的最后一个命令。
After the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved. The SMTP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy because most SMTP services are performed with no authentication and no privacy, but some SMTP clients or servers may want to continue only if a particular level of authentication and/or privacy was achieved.
TLS握手完成后，双方必须立即根据获得的身份验证和隐私决定是否继续。即使TLS协商在没有身份验证和/或隐私的情况下结束，SMTP客户端和服务器也可能决定继续，因为大多数SMTP服务都是在没有身份验证和隐私的情况下执行的，但某些SMTP客户端或服务器可能只希望在达到特定身份验证和/或隐私级别时继续。
If the SMTP client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD issue an SMTP QUIT command immediately after the TLS negotiation is complete. If the SMTP server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code (with a possible text string such as "Command refused due to lack of security").
如果SMTP客户端确定身份验证或隐私级别不够高，无法继续，则应在TLS协商完成后立即发出SMTP QUIT命令。如果SMTP服务器确定身份验证或隐私级别不够高，无法继续，则应使用554回复代码（可能的文本字符串，如“由于缺乏安全性而拒绝命令”）回复来自客户端的每个SMTP命令（退出命令除外）。
The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are:
在TLS谈判中，是否相信另一方的真实性是一个当地问题。然而，这些决定的一些一般规则是：
- A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. - A publicly-referenced SMTP server would probably want to accept any certificate from an SMTP client, and would possibly want to put distinguishing information about the certificate in the Received header of messages that were relayed or submitted from the client.
- SMTP客户端可能只想验证其服务器证书具有域名的SMTP服务器，该域名是客户端认为它正在连接的域名。-公开引用的SMTP服务器可能希望接受来自SMTP客户端的任何证书，并且可能希望在从客户端中继或提交的消息的接收头中放置有关证书的区别信息。
Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation.
TLS握手完成后，SMTP协议重置为初始状态（服务器发出220服务就绪问候语后SMTP中的状态）。服务器必须放弃从客户机获得的任何知识，例如EHLO命令的参数，这些知识不是从TLS协商本身获得的。客户端必须放弃从服务器获得的任何知识，例如SMTP服务扩展列表，这些知识不是从TLS协商本身获得的。成功的TLS协商后，客户端应发送EHLO命令作为第一个命令。
The list of SMTP service extensions returned in response to an EHLO command received after the TLS handshake MAY be different than the list returned before the TLS handshake. For example, an SMTP server might not want to advertise support for a particular SASL mechanism [SASL] unless a client has sent an appropriate client certificate during a TLS handshake.
为响应TLS握手后收到的EHLO命令而返回的SMTP服务扩展列表可能与TLS握手前返回的列表不同。例如，SMTP服务器可能不希望公布对特定SASL机制[SASL]的支持，除非客户端在TLS握手期间发送了适当的客户端证书。
Both the client and the server MUST know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active. A server MUST NOT return the TLS extension in response to an EHLO command received after a TLS handshake has completed.
客户端和服务器都必须知道是否存在活动的TLS会话。如果TLS会话已处于活动状态，则客户端不得尝试启动TLS会话。在TLS握手完成后，服务器不得返回TLS扩展以响应接收到的EHLO命令。
The following dialog illustrates how a client and server can start a TLS session:
以下对话框说明了客户端和服务器如何启动TLS会话：
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: <continues by sending an SMTP command> . . .
C&S:<协商TLS会话>C&S:<检查协商结果>C:<通过发送SMTP命令继续>。
It should be noted that SMTP is not an end-to-end mechanism. Thus, if an SMTP client/server pair decide to add TLS privacy, they are not securing the transport from the originating mail user agent to the recipient. Further, because delivery of a single piece of mail may go between more than two SMTP servers, adding TLS privacy to one pair of servers does not mean that the entire SMTP chain has been made private. Further, just because an SMTP server can authenticate an SMTP client, it does not mean that the mail from the SMTP client was authenticated by the SMTP client when the client received it.
应该注意的是，SMTP不是端到端机制。因此，如果SMTP客户端/服务器对决定添加TLS隐私，则它们不会保护从原始邮件用户代理到收件人的传输。此外，由于单个邮件的传递可能在两个以上的SMTP服务器之间进行，因此将TLS隐私添加到一对服务器并不意味着整个SMTP链都是私有的。此外，仅仅因为SMTP服务器可以对SMTP客户端进行身份验证，并不意味着来自SMTP客户端的邮件在客户端接收时已由SMTP客户端进行身份验证。
Both the STMP client and server must check the result of the TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependant, and is beyond the scope of this document.
STMP客户端和服务器都必须检查TLS协商的结果，以查看是否实现了可接受的身份验证或隐私。忽略此步骤将使使用TLS进行安全保护完全无效。关于是否实现了可接受的身份验证或隐私的决定是在本地做出的，取决于实现，并且超出了本文档的范围。
The SMTP client and server should note carefully the result of the TLS negotiation. If the negotiation results in no privacy, or if it results in privacy using algorithms or key lengths that are deemed not strong enough, or if the authentication is not good enough for either party, the client may choose to end the SMTP session with an immediate QUIT command, or the server may choose to not accept any more SMTP commands.
SMTP客户端和服务器应仔细注意TLS协商的结果。如果协商导致没有隐私，或者使用被认为不够强的算法或密钥长度导致隐私，或者如果认证对任何一方都不够好，则客户端可以选择使用立即退出命令结束SMTP会话，或者服务器可以选择不再接受任何SMTP命令。
A server announcing in an EHLO response that it uses a particular TLS protocol should not pose any security issues, since any use of TLS will be at least as secure as no use of TLS.
在EHLO响应中宣布使用特定TLS协议的服务器不应造成任何安全问题，因为使用TLS至少与不使用TLS一样安全。
A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the client not to try to start a TLS session. An SMTP client can protect against this attack by recording the fact that a particular SMTP server offers TLS during one session and generating an alarm if it does not appear in the EHLO response for a later session. The lack of TLS during a session SHOULD NOT result in the bouncing of email, although it could result in delayed processing.
通过删除服务器上的“250 STARTTLS”响应，可以发起中间人攻击。这将导致客户端不尝试启动TLS会话。SMTP客户端可以通过记录特定SMTP服务器在一个会话期间提供TLS的事实，并在以后会话的EHLO响应中未出现警报的情况下生成警报来防止此攻击。会话期间缺少TLS不应导致电子邮件跳转，尽管这可能会导致处理延迟。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the TLS handshake upon completion of the TLS handshake.
在TLS握手开始之前，任何协议交互都会在clear中执行，并且可能会被活动攻击者修改。因此，在TLS握手完成后，客户端和服务器必须丢弃在TLS握手开始之前获得的任何知识。
The STARTTLS extension is not suitable for authenticating the author of an email message unless every hop in the delivery chain, including the submission to the first SMTP server, is authenticated. Another proposal [SMTP-AUTH] can be used to authenticate delivery and MIME security multiparts [MIME-SEC] can be used to authenticate the author of an email message. In addition, the [SMTP-AUTH] proposal offers simpler and more flexible options to authenticate an SMTP client and the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the STARTTLS command to provide an authorization identity.
STARTTLS扩展不适合验证电子邮件的作者，除非传递链中的每个跃点（包括提交到第一个SMTP服务器的跃点）都经过验证。另一个方案[SMTP-AUTH]可用于验证传递，MIME安全多部分[MIME-SEC]可用于验证电子邮件的作者。此外，[SMTP-AUTH]方案提供了更简单、更灵活的选项来验证SMTP客户端，SASL外部机制[SASL]可与STARTTLS命令结合使用，以提供授权标识。
A. References
A.参考资料
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982.
[RFC-821]Postel，J.，“简单邮件传输协议”，RFC 821，1982年8月。
[RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-1869]Klensin，J.，Freed，N，Rose，M，Stefferud，E.和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC-2034]弗里德，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SMTP-AUTH] "SMTP Service Extension for Authentication", Work in Progress.
[SMTP-AUTH]“用于身份验证的SMTP服务扩展”，正在进行中。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
B. Author's Address
B.作者地址
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
保罗霍夫曼互联网邮件联盟127塞格雷广场圣克鲁斯，加利福尼亚州95060
Phone: (831) 426-9827 EMail: phoffman@imc.org
电话：（831）426-9827电子邮件：phoffman@imc.org
C. Full Copyright Statement
C.完整的版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。