Network Working Group J. Myers
Request for Comments: 2554 Netscape Communications
Category: Standards Track March 1999
Network Working Group J. Myers
Request for Comments: 2554 Netscape Communications
Category: Standards Track March 1999
SMTP Service Extension for Authentication
用于身份验证的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 defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL].
本文档定义了SMTP服务扩展[ESMTP]，SMTP客户端可通过该扩展向服务器指示身份验证机制，执行身份验证协议交换，并可选择协商后续协议交互的安全层。此扩展是简单身份验证和安全层[SASL]的概要文件。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[关键词]。
(1) the name of the SMTP service extension is "Authentication"
(1) SMTP服务扩展名为“身份验证”
(2) the EHLO keyword value associated with this extension is "AUTH"
(2) 与此扩展关联的EHLO关键字值为“AUTH”
(3) The AUTH EHLO keyword contains as a parameter a space separated list of the names of supported SASL mechanisms.
(3) AUTH EHLO关键字包含一个参数，该参数以空格分隔，列出了受支持的SASL机制的名称。
(4) a new SMTP verb "AUTH" is defined
(4) 定义了一个新的SMTP谓词“AUTH”
(5) an optional parameter using the keyword "AUTH" is added to the MAIL FROM command, and extends the maximum line length of the MAIL FROM command by 500 characters.
(5) 将使用关键字“AUTH”的可选参数添加到MAIL FROM命令中，并将MAIL FROM命令的最大行长度延长500个字符。
(6) this extension is appropriate for the submission protocol [SUBMIT].
(6) 此扩展适用于提交协议[SUBMIT]。
AUTH mechanism [initial-response]
验证机制[初始响应]
Arguments: a string identifying a SASL authentication mechanism. an optional base64-encoded response
参数：标识SASL身份验证机制的字符串。可选的base64编码响应
Restrictions: After an AUTH command has successfully completed, no more AUTH commands may be issued in the same session. After a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply.
限制：成功完成AUTH命令后，同一会话中不能再发出AUTH命令。在成功的AUTH命令完成后，服务器必须以503回复拒绝任何进一步的AUTH命令。
The AUTH command is not permitted during a mail transaction.
在邮件事务期间不允许使用AUTH命令。
Discussion: The AUTH command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTH command with a 504 reply.
讨论：AUTH命令指示服务器的身份验证机制。如果服务器支持请求的身份验证机制，它将执行身份验证协议交换以验证和标识用户。可选地，它还为后续协议交互协商安全层。如果请求的身份验证机制不受支持，服务器将以504回复拒绝AUTH命令。
The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge, otherwise known as a ready response, is a 334 reply with the text part containing a BASE64 encoded string. The client answer consists of a line containing a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line with a single "*". If the server receives such an answer, it MUST reject the AUTH command by sending a 501 reply.
身份验证协议交换由一系列特定于身份验证机制的服务器质询和客户端应答组成。服务器质询，也称为就绪响应，是一个334回复，其文本部分包含BASE64编码字符串。客户端应答由一行组成，其中包含BASE64编码的字符串。如果客户端希望取消身份验证交换，它将发出一行，其中包含一个“*”。如果服务器收到这样的应答，它必须通过发送501应答来拒绝AUTH命令。
The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial-response argument as if it were sent in response to the empty challenge. Unlike a zero-length client answer to a 334 reply, a zero-length initial response is sent as a single equals sign ("="). If the client uses an initial-response argument to the AUTH command with a mechanism that sends data in the initial challenge, the server rejects the AUTH command with a 535 reply.
AUTH命令的可选初始响应参数用于在使用定义为在初始质询中不发送数据的身份验证机制时保存往返。当initialresponse参数与这种机制一起使用时，初始空质询不会发送给客户端，服务器使用initialresponse参数中的数据，就好像它是响应空质询而发送的一样。与334应答的零长度客户端应答不同，零长度初始响应以单个等号（“=”）发送。如果客户端对AUTH命令使用初始响应参数，并且该参数具有在初始质询中发送数据的机制，则服务器将以535回复拒绝AUTH命令。
If the server cannot BASE64 decode the argument, it rejects the AUTH command with a 501 reply. If the server rejects the authentication data, it SHOULD reject the AUTH command with a 535 reply unless a more specific error code, such as one listed in section 6, is appropriate. Should the client successfully complete the authentication exchange, the SMTP server issues a 235 reply.
如果服务器无法对参数进行BASE64解码，则会以501回复拒绝AUTH命令。如果服务器拒绝验证数据，则应拒绝带有535回复的AUTH命令，除非出现更具体的错误代码，如第6节中列出的错误代码。如果客户端成功完成身份验证交换，SMTP服务器将发出235回复。
The service name specified by this protocol's profile of SASL is "smtp".
此协议的SASL配置文件指定的服务名称为“smtp”。
If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the success reply for the server. Upon a security layer's taking effect, 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 SASL 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 SASL negotiation itself (with the exception that a client MAY compare the list of advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack). The client SHOULD send an EHLO command as the first command after a successful SASL negotiation which results in the enabling of a security layer.
如果通过SASL身份验证交换协商安全层，则该层将在完成客户端身份验证交换的CRLF和服务器成功回复的CRLF之后立即生效。安全层生效后，SMTP协议将重置为初始状态（服务器发出220服务就绪问候语后SMTP中的状态）。服务器必须放弃从客户机获得的任何知识，例如EHLO命令的参数，这些知识不是从SASL协商本身获得的。客户端必须放弃从服务器获得的任何知识，例如SMTP服务扩展列表，这些知识不是从SASL协商本身获得的（客户端可以在身份验证之前和之后比较公布的SASL机制列表，以便检测活动的向下协商攻击除外）。成功的SASL协商导致启用安全层后，客户端应发送EHLO命令作为第一个命令。
The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any security layers. If an AUTH command fails, the client may try another authentication mechanism by issuing another AUTH command.
服务器不需要支持任何特定的身份验证机制，也不需要身份验证机制来支持任何安全层。如果AUTH命令失败，客户端可以通过发出另一个AUTH命令来尝试另一种身份验证机制。
If an AUTH command fails, the server MUST behave the same as if the client had not issued the AUTH command.
如果AUTH命令失败，服务器的行为必须与客户端未发出AUTH命令的行为相同。
The BASE64 string may in general be arbitrarily long. Clients and servers MUST be able to support challenges and responses that are as long as are generated by the authentication mechanisms they support, independent of any line length limitations the client or server may have in other parts of its protocol implementation.
BASE64字符串通常可以任意长。客户机和服务器必须能够支持由其支持的身份验证机制生成的挑战和响应，而不受客户机或服务器在其协议实现的其他部分中可能存在的任何线路长度限制。
Examples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
Examples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
AUTH=addr-spec
AUTH=addr规范
Arguments: An addr-spec containing the identity which submitted the message to the delivery system, or the two character sequence "<>" indicating such an identity is unknown or insufficiently authenticated. To comply with the restrictions imposed on ESMTP parameters, the addr-spec is encoded inside an xtext. The syntax of an xtext is described in section 5 of [ESMTP-DSN].
参数：包含将消息提交给传递系统的标识的addr规范，或表示该标识未知或未经充分验证的两个字符序列“<>”。为了遵守对ESMTP参数施加的限制，addr规范在xtext中进行编码。xtext的语法在[ESMTP-DSN]的第5节中描述。
Discussion: The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a trusted environment to communicate the authentication of individual messages.
讨论：MAIL FROM命令的可选AUTH参数允许可信环境中的协作代理传递单个消息的身份验证。
If the server trusts the authenticated identity of the client to assert that the message was originally submitted by the supplied addr-spec, then the server SHOULD supply the same addr-spec in an AUTH parameter when relaying the message to any server which supports the AUTH extension.
如果服务器信任客户端的经过身份验证的标识来断言消息最初是由提供的addr spec提交的，则在将消息中继到支持AUTH扩展的任何服务器时，服务器应在AUTH参数中提供相同的addr spec。
A MAIL FROM parameter of AUTH=<> indicates that the original submitter of the message is not known. The server MUST NOT treat the message as having been originally submitted by the client.
参数AUTH=<>的MAIL-FROM表示消息的原始提交者未知。服务器不得将消息视为最初由客户端提交。
If the AUTH parameter to the MAIL FROM is not supplied, the client has authenticated, and the server believes the message is an original submission by the client, the server MAY supply the client's identity in the addr-spec in an AUTH parameter when relaying the message to any server which supports the AUTH extension.
如果未提供邮件发件人的AUTH参数，则客户端已通过身份验证，并且服务器认为该邮件是客户端提交的原始邮件，则在将邮件中继到支持AUTH扩展的任何服务器时，服务器可以在addr规范中的AUTH参数中提供客户端的身份。
If the server does not sufficiently trust the authenticated identity of the client, or if the client is not authenticated, then the server MUST behave as if the AUTH=<> parameter was supplied. The server MAY, however, write the value of the AUTH parameter to a log file.
如果服务器不充分信任客户机的身份验证，或者客户机未经过身份验证，则服务器的行为必须与提供了AUTH=<>参数一样。但是，服务器可以将AUTH参数的值写入日志文件。
If an AUTH=<> parameter was supplied, either explicitly or due to the requirement in the previous paragraph, then the server MUST supply the AUTH=<> parameter when relaying the message to any server which it has authenticated to using the AUTH extension.
如果提供了AUTH=<>参数，无论是显式提供的还是由于上一段中的要求提供的，则服务器在将消息中继到其已使用AUTH扩展进行身份验证的任何服务器时，必须提供AUTH=<>参数。
A server MAY treat expansion of a mailing list as a new submission, setting the AUTH parameter to the mailing list address or mailing list administration address when relaying the message to list subscribers.
服务器可以将邮件列表的扩展视为新提交，在将邮件转发给列表订户时，将AUTH参数设置为邮件列表地址或邮件列表管理地址。
It is conforming for an implementation to be hard-coded to treat all clients as being insufficiently trusted. In that case, the implementation does nothing more than parse and discard syntactically valid AUTH parameters to the MAIL FROM command and supply AUTH=<> parameters to any servers to which it authenticates using the AUTH extension.
将实现硬编码为将所有客户机视为不充分信任是符合要求的。在这种情况下，该实现只需解析并丢弃语法上有效的AUTH参数，并将AUTH=<>参数提供给它使用AUTH扩展对其进行身份验证的任何服务器。
Examples:
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK
Examples:
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK
The following error codes may be used to indicate various conditions as described.
以下错误代码可用于指示所述的各种情况。
432 A password transition is needed
432需要密码转换
This response to the AUTH command indicates that the user needs to transition to the selected authentication mechanism. This typically done by authenticating once using the PLAIN authentication mechanism.
对AUTH命令的响应表明用户需要转换到所选的身份验证机制。这通常通过使用普通身份验证机制进行一次身份验证来完成。
534 Authentication mechanism is too weak
534身份验证机制太弱
This response to the AUTH command indicates that the selected authentication mechanism is weaker than server policy permits for that user.
对AUTH命令的此响应表示所选身份验证机制弱于该用户的服务器策略允许。
538 Encryption required for requested authentication mechanism
538请求的身份验证机制需要加密
This response to the AUTH command indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.
对AUTH命令的此响应表明，只有在加密基础SMTP连接时，才能使用选定的身份验证机制。
454 Temporary authentication failure
454临时身份验证失败
This response to the AUTH command indicates that the authentication failed due to a temporary server failure.
对AUTH命令的此响应表示由于临时服务器故障，身份验证失败。
530 Authentication required
530需要身份验证
This response may be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT. It indicates that server policy requires authentication in order to perform the requested action.
此响应可以由AUTH、EHLO、HELO、NOOP、RSET或QUIT以外的任何命令返回。它表示服务器策略需要身份验证才能执行请求的操作。
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广巴科斯诺尔形式（BNF）表示法。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
UPALPHA = %x41-5A ;; Uppercase: A-Z
UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
LOALPHA = %x61-7A ;; Lowercase: a-z
ALPHA = UPALPHA / LOALPHA ;; case insensitive
ALPHA = UPALPHA / LOALPHA ;; case insensitive
DIGIT = %x30-39 ;; Digits 0-9
DIGIT = %x30-39 ;; Digits 0-9
HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
hexchar = "+" HEXDIGIT HEXDIGIT
hexchar=“+”HEXDIGIT HEXDIGIT
xchar = %x21-2A / %x2C-3C / %x3E-7E
;; US-ASCII except for "+", "=", SPACE and CTL
xchar = %x21-2A / %x2C-3C / %x3E-7E
;; US-ASCII except for "+", "=", SPACE and CTL
xtext = *(xchar / hexchar)
xtext = *(xchar / hexchar)
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
auth_type = 1*20AUTH_CHAR
auth_type = 1*20AUTH_CHAR
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64]) CRLF
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64]) CRLF
auth_param = "AUTH=" xtext
;; The decoded form of the xtext MUST be either
;; an addr-spec or the two characters "<>"
auth_param = "AUTH=" xtext
;; The decoded form of the xtext MUST be either
;; an addr-spec or the two characters "<>"
base64 = base64_terminal / ( 1*(4base64_CHAR) [base64_terminal] )
base64=base64\u终端/（1*（4base64\u字符）[base64\u终端]）
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_terminal = (2base64_char "==") / (3base64_char "=")
continue_req = "334" SPACE [base64] CRLF
继续_req=“334”空格[base64]CRLF
CR = %x0C ;; ASCII CR, carriage return
CR = %x0C ;; ASCII CR, carriage return
CRLF = CR LF
CRLF = CR LF
CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
LF = %x0A ;; ASCII LF, line feed
LF = %x0A ;; ASCII LF, line feed
SPACE = %x20 ;; ASCII SP, space
SPACE = %x20 ;; ASCII SP, space
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[CRAM-MD5]Klensin，J.，Catoe，R.和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，RFC 18691995年11月。
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[ESMTP-DSN]Moore，K，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]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月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提交]Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating server, it needs to be configured to never send mail to that server when the connection is not mutually authenticated and encrypted. Otherwise, an attacker could steal the client's mail by hijacking the SMTP connection and either pretending the server does not support the Authentication extension or causing all AUTH commands to fail.
如果客户机使用此扩展获取通过不安全网络到协作服务器的加密隧道，则需要将其配置为在连接未经过相互身份验证和加密时从不向该服务器发送邮件。否则，攻击者可以通过劫持SMTP连接并假装服务器不支持身份验证扩展或导致所有AUTH命令失败来窃取客户端的邮件。
Before the SASL negotiation 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 SASL negotiation upon completion of a SASL negotiation which results in a security layer.
在SASL协商开始之前，任何协议交互都会在clear中执行，并且可能会被活动攻击者修改。因此，客户机和服务器必须在SASL协商完成后丢弃在SASL协商开始之前获得的任何知识，这将导致安全层。
This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt to the submission port [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing an relayed message without an envelope authentication to pick up the authentication of the relay client.
此机制不保护TCP端口，因此主动攻击者可能会将中继连接尝试重定向到提交端口[SUBMIT]。AUTH=<>参数可防止此类攻击导致未经信封身份验证的中继消息获取中继客户端的身份验证。
A message submission client may require the user to authenticate whenever a suitable SASL mechanism is advertised. Therefore, it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when use of that mechanism grants the client no benefits over anonymous submission.
消息提交客户端可能要求用户在发布适当的SASL机制时进行身份验证。因此，当使用SASL机制对客户端没有匿名提交的好处时，提交服务器[SUBMIT]可能不希望公布该机制。
This extension is not intended to replace or be used instead of end-to-end message signature and encryption systems such as S/MIME or PGP. This extension addresses a different problem than end-to-end systems; it has the following key differences:
此扩展不打算取代或替代端到端消息签名和加密系统，如S/MIME或PGP。此扩展解决了与端到端系统不同的问题；它有以下主要区别：
(1) it is generally useful only within a trusted enclave
(1) 它通常只在受信任的飞地内有用
(2) it protects the entire envelope of a message, not just the message's body.
(2) 它保护消息的整个信封，而不仅仅是消息的正文。
(3) it authenticates the message submission, not authorship of the message content
(3) 它验证消息提交，而不是消息内容的作者身份
(4) it can give the sender some assurance the message was delivered to the next hop in the case where the sender mutually authenticates with the next hop and negotiates an appropriate security layer.
(4) 在发送方与下一个跃点相互认证并协商适当的安全层的情况下，它可以给发送方一些消息传递到下一个跃点的保证。
Additional security considerations are mentioned in the SASL specification [SASL].
SASL规范[SASL]中提到了其他安全注意事项。
John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043
约翰·加德纳·迈尔斯网景通信公司501东米德菲尔德路邮递站MV-029加利福尼亚州山景城94043
EMail: jgmyers@netscape.com
EMail: jgmyers@netscape.com
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。