Network Working Group P. Hoffman
Request for Comments: 3207 Internet Mail Consortium
Obsoletes: 2487 February 2002
Category: Standards Track
Network Working Group P. Hoffman
Request for Comments: 3207 Internet Mail Consortium
Obsoletes: 2487 February 2002
Category: Standards Track
SMTP Service Extension for Secure SMTP over Transport Layer Security
用于传输层安全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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (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服务器和客户端使用TLS（传输层安全）在Internet上提供经过身份验证的私人通信。这使SMTP代理能够保护其部分或全部通信免受窃听者和攻击者的攻击。
SMTP [RFC2821] 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[RFC2821]服务器和客户端通常通过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上的许多其他常见协议添加安全性。
This document obsoletes RFC 2487.
本文件淘汰了RFC 2487。
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]中所述进行解释。
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 is currently able to negotiate the 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不可用
If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.
如果客户端收到454响应，则客户端必须决定是否继续SMTP会话。这样的决定是基于当地的政策。例如，如果TLS用于客户机身份验证，客户机可能会尝试继续会话，以防服务器允许它，即使没有身份验证。但是，如果正在协商TLS以进行加密，则获得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 [RFC2034], the status code to be returned SHOULD be 5.7.0.
除了NOOP、EHLO、STARTTLS或QUIT之外的所有命令。如果客户端和服务器正在使用ENHANCEDSTATUSCODES ESMTP扩展[RFC2034]，则返回的状态代码应为5.7.0。
After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection.
在收到对STARTTLS命令的220响应后，客户端必须在发出任何其他SMTP命令之前启动TLS协商。如果在发出STARTTLS命令后，客户端发现某些故障阻止它实际启动TLS握手，那么它应该中止连接。
If the SMTP client is using pipelining as defined in RFC 2920, the STARTTLS command must be the last command in a group.
如果SMTP客户端使用RFC 2920中定义的管道，则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 verifiable 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
为响应TLS握手后收到的EHLO命令而返回的SMTP服务扩展列表可能与TLS握手前返回的列表不同。例如，SMTP服务器
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.
可能不希望公布对特定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 STARTTLS extension in response to an EHLO command received after a TLS handshake has completed.
客户端和服务器都必须知道是否存在活动的TLS会话。如果TLS会话已处于活动状态，则客户端不得尝试启动TLS会话。在TLS握手完成后，服务器不得返回STARTTLS扩展以响应接收到的EHLO命令。
STARTTLS is a valid ESMTP extension when used on the Submission port, as defined in [RFC2476]. In fact, since the submission port is by definition not a publicly referenced SMTP server, the STARTTLS extension can be particularly useful by providing security and authentication for this service.
STARTTLS在提交端口上使用时是有效的ESMTP扩展，如[RFC2476]中所定义。事实上，由于提交端口根据定义不是公开引用的SMTP服务器，因此STARTTLS扩展可以通过为此服务提供安全性和身份验证而特别有用。
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.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
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
应该注意的是，SMTP不是端到端机制。因此，如果SMTP客户端/服务器对决定添加TLS隐私，则它们不会保护从原始邮件用户代理到收件人的传输。此外，由于单个邮件的传递可能在两个以上的SMTP服务器之间进行，因此将TLS隐私添加到一对SMTP服务器上
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服务器可以对SMTP客户端进行身份验证，并不意味着来自SMTP客户端的邮件在客户端接收时已由SMTP客户端进行身份验证。
Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and 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-dependent, and is beyond the scope of this document.
SMTP客户端和服务器都必须检查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 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. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client's request to start TLS and the server's response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.
通过删除服务器上的“250 STARTTLS”响应，可以发起中间人攻击。这将导致客户端不尝试启动TLS会话。另一种中间人攻击是允许服务器宣布其STARTTLS功能，但改变客户端启动TLS的请求和服务器的响应。为了抵御此类攻击，必须将客户端和服务器配置为在成功传输消息之前，要求成功地为选定主机协商适当的密码套件。还应提供可能时使用TLS的附加选项。实现可以提供记录TLS用于与给定对等方通信的能力，并在以后的会话中未使用TLS时生成警告。
If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, retry TLS at a later time, or give up and return the mail to the sender. If a failure or error occurs, the client can assume that the server may be able to negotiate TLS in the future, and should try negotiate TLS in a later session, until some locally-chosen timeout occurs, at which point, the client should return the mail to the sender. However, if the client and server were only using TLS for authentication, the client may want to proceed with the SMTP session, in case some of the operations the client wanted to perform are accepted by the server even if the client is unauthenticated.
如果TLS协商失败或客户机收到454响应，客户机必须决定下一步做什么。有三种主要选择：继续SMTP会话的其余部分，稍后重试TLS，或者放弃并将邮件返回给发件人。如果出现故障或错误，客户机可以假定服务器将来可能能够协商TLS，并应在以后的会话中尝试协商TLS，直到发生某些本地选择的超时，此时，客户机应将邮件返回给发件人。但是，如果客户端和服务器仅使用TLS进行身份验证，则客户端可能希望继续SMTP会话，以防服务器接受客户端希望执行的某些操作，即使客户端未经身份验证。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker.
在TLS握手开始之前，任何协议交互都会在clear中执行，并且可能会被活动攻击者修改。
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握手完成后，客户端和服务器必须丢弃在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命令结合使用，以提供授权标识。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 20341996年10月。
[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月。
[RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476]Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[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月。
Appendix
附录
This document is a revision of RFC 2487, which is a Proposed Standard. The changes from that document are:
本文件是RFC 2487的修订版，RFC 2487是一项拟议标准。该文件的变化如下：
- Section 5 and 7: More discussion of the man-in-the-middle attacks - Section 5: Additional discussion of when a server should and should not advertise the STARTTLS extension - Section 5: Changed the requirements on SMTP clients after receiving a 220 response. - Section 5.1: Clarified description of verifying certificates. - Section 5.3: Added the section on "STARTTLS on the Submission Port" - Section 6: Bug fix in the example to indicate that the client needs to issue a new EHLO command, as already is described in section 5.2. - Section 7: Clarification of the paragraph on acceptable degree of privacy. Significant change to the discussion of how to avoid a man-in-the-middle attack. - Section A: Update reference from RFC 821 to RFC 2821.
- 第5节和第7节：关于中间人攻击的更多讨论-第5节：关于服务器何时应该和不应该公布STARTTLS扩展的更多讨论-第5节：在收到220响应后更改了SMTP客户端的要求。-第5.1节：澄清了验证证书的说明。-第5.3节：添加了“提交端口上的STARTTLS”一节-第6节：示例中的错误修复，以表明客户端需要发出新的EHLO命令，如第5.2节所述。-第7节：澄清关于可接受隐私程度的段落。关于如何避免中间人攻击的讨论发生了重大变化A部分：将参考从RFC 821更新为RFC 2821。
Author's Address
作者地址
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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。