Network Working Group R. Siemborski
Request for Comments: 5034 Google, Inc.
Obsoletes: 1734 A. Menon-Sen
Updates: 2449 Oryx Mail Systems GmbH
Category: Standards Track July 2007
Network Working Group R. Siemborski
Request for Comments: 5034 Google, Inc.
Obsoletes: 1734 A. Menon-Sen
Updates: 2449 Oryx Mail Systems GmbH
Category: Standards Track July 2007
The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
邮局协议（POP3）简单身份验证和安全层（SASL）身份验证机制
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.
本文档定义了邮局协议（POP3）的简单身份验证和安全层（SASL）的概要文件。此扩展允许POP3客户端向服务器指示身份验证机制，执行身份验证协议交换，并在此会话期间可选地协商安全层以进行后续协议交互。
This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449.
本文档旨在将与POP3 AUTH相关的信息整合到单个文档中。为此，本文件废弃并取代了RFC 1734，并更新了RFC 2449第6.3节中包含的信息。
The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered several problems in its specification. The first is that it was very similar to a SASL framework defined by [RFC4422], but pre-dated the initial SASL specification. It was therefore missing some key components, such as a way to list the available authentication mechanisms.
POP3（参见[RFC1939]）AUTH命令（参见[RFC1734]）在其规范中遇到了几个问题。首先，它与[RFC4422]定义的SASL框架非常相似，但早于最初的SASL规范。因此，它缺少一些关键组件，例如列出可用身份验证机制的方法。
Later, [RFC2449] attempted to remedy this situation by adding the CAPA command and allowing an initial client response with the AUTH command, but problems remained in the clarity of the specification of how the initial client response was to be handled.
后来，[RFC2449]试图通过添加CAPA命令并允许使用AUTH命令进行初始客户机响应来纠正这种情况，但在如何处理初始客户机响应的规范的清晰性方面仍然存在问题。
Together, this means creating a full POP3 AUTH implementation requires an understanding of material in at least five different documents (and [RFC3206] provides additional response codes that are useful during authentication).
总之，这意味着创建完整的POP3身份验证实现需要了解至少五个不同文档中的材料（并且[RFC3206]提供了在身份验证期间有用的其他响应代码）。
This document attempts to combine the information in [RFC1734] and [RFC2449] to simplify this situation. Additionally, it aims to clarify and update the older specifications where appropriate.
本文档试图结合[RFC1734]和[RFC2449]中的信息来简化这种情况。此外，其目的是在适当的情况下澄清和更新旧规范。
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]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
Formal syntax is defined by [RFC4234].
形式语法由[RFC4234]定义。
This section supersedes the definition of the SASL Capability in section 6.3 of [RFC2449].
本节取代[RFC2449]第6.3节中SASL能力的定义。
CAPA tag: SASL
CAPA标签：SASL
Arguments: Supported SASL Mechanisms
参数：支持的SASL机制
Added commands: AUTH
添加命令：AUTH
Standard commands affected: None
受影响的标准命令：无
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: AUTHORIZATION
在以下状态下有效的命令：授权
Specification reference: This document and [RFC4422]
规范参考：本文件和[RFC4422]
Discussion: The SASL capability permits the use of the AUTH command (as defined in Section 4 of this document) to begin a SASL negotiation (as defined in [RFC4422]). The argument to the SASL capability is a space-separated list of SASL mechanisms that are supported.
讨论：SASL功能允许使用AUTH命令（定义见本文件第4节）开始SASL协商（定义见[RFC4422]）。SASL功能的参数是受支持的SASL机制的空间分隔列表。
If a server either does not support the CAPA command or does not advertise the SASL capability, clients SHOULD NOT attempt the AUTH command. If a client does attempt the AUTH command in such a situation, it MUST NOT supply the client initial response parameter (for backwards compatibility with [RFC1734]).
如果服务器不支持CAPA命令或不公布SASL功能，则客户端不应尝试使用AUTH命令。如果客户机确实在这种情况下尝试使用AUTH命令，则它不得提供客户机初始响应参数（用于向后兼容[RFC1734]）。
Note that the list of available mechanisms MAY change after a successful STLS command (see [RFC2595]). However, as required by [RFC2449], implementations MUST continue to include the SASL capability even after a successful AUTH command has been completed (even though no further AUTH commands may be issued).
请注意，STLS命令成功后，可用机制的列表可能会更改（请参见[RFC2595]）。但是，根据[RFC2449]的要求，即使在成功完成了AUTH命令之后（即使可能不会发出进一步的AUTH命令），实现也必须继续包括SASL功能。
Example
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
Example
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
AUTH mechanism [initial-response]
验证机制[初始响应]
Arguments:
论据：
mechanism: A string identifying a SASL authentication mechanism.
机制：标识SASL身份验证机制的字符串。
initial-response: An optional initial client response, as defined in Section 3 of [RFC4422]. If present, this response MUST be encoded as Base64 (specified in Section 4 of [RFC4648]), or consist only of the single character "=", which represents an empty initial response.
初始响应：可选的初始客户端响应，如[RFC4422]第3节所定义。如果存在，该响应必须编码为Base64（在[RFC4648]的第4节中指定），或者仅由表示空初始响应的单个字符“=”组成。
Restrictions:
限制：
After an AUTH command has been 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 an -ERR reply.
成功完成AUTH命令后，同一会话中不能再发出AUTH命令。在成功的AUTH命令完成后，服务器必须以-ERR回复拒绝任何进一步的AUTH命令。
The AUTH command may only be given during the AUTHORIZATION state.
AUTH命令只能在授权状态下发出。
Discussion:
讨论：
The AUTH command initiates a SASL authentication exchange between the client and the server. The client identifies the SASL mechanism to use with the first parameter of the AUTH command. If the server supports the requested authentication mechanism, it performs the SASL exchange to authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions during this session. If the requested authentication mechanism is not supported, the server rejects the AUTH command with an -ERR reply.
AUTH命令启动客户端和服务器之间的SASL身份验证交换。客户端识别要与AUTH命令的第一个参数一起使用的SASL机制。如果服务器支持请求的身份验证机制，它将执行SASL交换以对用户进行身份验证。可选地，它还为会话期间的后续协议交互协商安全层。如果请求的身份验证机制不受支持，则服务器将以-ERR回复拒绝AUTH命令。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the chosen SASL mechanism.
身份验证协议交换由一系列特定于所选SASL机制的服务器挑战和客户端响应组成。
A server challenge is sent as a line consisting of a "+" character, followed by a single space and a string encoded using Base64, as specified in Section 4 of [RFC4648]. This line MUST NOT contain any text other than the BASE64-encoded challenge.
按照[RFC4648]第4节的规定，服务器质询将作为一行发送，该行由“+”字符组成，后跟一个空格和一个使用Base64编码的字符串。此行不能包含BASE64编码质询以外的任何文本。
A client response consists of a line containing a string encoded as Base64. If the client wishes to cancel the authentication exchange, it issues a line with a single "*". If the server receives such a response, it MUST reject the AUTH command by sending an -ERR reply.
客户端响应由一行组成，其中包含编码为Base64的字符串。如果客户端希望取消身份验证交换，它将发出一行，其中包含一个“*”。如果服务器收到这样的响应，它必须通过发送-ERR回复来拒绝AUTH命令。
The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires
AUTH命令的可选初始响应参数用于在使用支持初始客户端响应的身份验证机制时保存往返。如果省略了初始响应参数，并且所选机制需要
an initial client response, the server MUST proceed by issuing an empty challenge, as defined in Section 3 of [RFC4422]. In POP3, an empty server challenge is defined as a line with only a "+", followed by a single space. It MUST NOT contain any other data.
初始客户端响应时，服务器必须发出一个空质询，如[RFC4422]第3节所定义。在POP3中，空服务器质询被定义为只有一个“+”后跟一个空格的行。它不能包含任何其他数据。
For the purposes of the initial client response, the 255-octet limit on the length of a single command, defined in Section 4 of [RFC2449], still applies. If specifying an initial response would cause the AUTH command to exceed this length, the client MUST NOT use the initial-response parameter (and must proceed instead by sending its initial response after an empty challenge from the server, as in Section 3 of [RFC4422]).
就初始客户端响应而言，[RFC2449]第4节中定义的单个命令长度的255个八位字节限制仍然适用。如果指定初始响应将导致AUTH命令超过此长度，则客户端不得使用初始响应参数（并且必须在服务器发出空质询后发送初始响应，如[RFC4422]第3节所述）。
If the client needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="). This indicates that the response is present, but contains no data.
如果客户端需要发送长度为零的初始响应，则它必须以单个等号（“=”）的形式发送响应。这表示响应存在，但不包含任何数据。
If the client uses an initial-response argument to the AUTH command with a SASL mechanism that does not support an initial client send, the server MUST reject the AUTH command with an -ERR reply.
如果客户端对AUTH命令使用不支持初始客户端发送的SASL机制的initial response参数，则服务器必须使用-ERR reply拒绝AUTH命令。
If the server cannot Base64 decode a client response, it MUST reject the AUTH command with an -ERR reply. If the client cannot Base64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response. In particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the Base64 alphabet, and MUST reject any sequence of Base64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
如果服务器无法对客户端响应进行Base64解码，则必须使用-ERR应答拒绝AUTH命令。如果客户端无法Base64解码服务器的任何挑战，则必须使用“*”响应取消身份验证。特别是，服务器和客户端必须拒绝（而不是忽略）Base64字母表不明确允许的任何字符，并且必须拒绝任何包含填充字符（'='）的Base64字符序列，而不是字符串末尾（例如，不允许“=AAA”和“AAA=BBB”）。
Excepting the initial client response, these BASE64 strings may be of arbitrary length, depending on the authentication mechanism in use. Clients and servers MUST be able to handle the largest encoded challenges and responses generated by the authentication mechanisms they support. This requirement is independent of any line-length limitations the client or server may have in other parts of its protocol implementation.
除了初始客户端响应之外，这些BASE64字符串可能具有任意长度，具体取决于使用的身份验证机制。客户端和服务器必须能够处理由其支持的身份验证机制生成的最大编码挑战和响应。此要求独立于客户端或服务器在其协议实现的其他部分可能具有的任何线路长度限制。
If the server is unable to authenticate the client, it MUST reject the AUTH command with an -ERR reply. Should the client successfully complete the exchange, the server issues a +OK reply. Additionally, upon success, the POP3 session enters the TRANSACTION state.
如果服务器无法对客户端进行身份验证，则必须使用-ERR回复拒绝AUTH命令。如果客户端成功完成交换，服务器将发出+OK回复。此外，一旦成功，POP3会话将进入事务状态。
The authorization identity generated by the SASL exchange is a simple username, and SHOULD use the SASLprep profile (see [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to prepare these names for matching. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
SASL交换生成的授权标识是一个简单的用户名，应该使用StringPrep算法（参见[RFC3454]）的SASLprep配置文件（参见[RFC4013]）来准备这些名称以进行匹配。如果授权标识的准备失败或导致空字符串（除非它作为空字符串传输），则服务器必须使身份验证失败。
If a security layer is negotiated during the SASL exchange, it takes effect for the client on the octet immediately following the CRLF that concludes the last response generated by the client. For the server, it takes effect immediately following the CRLF of its success reply.
如果在SASL交换期间协商了安全层，则它将在CRLF结束客户端生成的最后一个响应后立即对客户端的八位字节生效。对于服务器，它在成功回复的CRLF之后立即生效。
When a security layer takes effect, the server MUST discard any knowledge previously obtained from the client, which was not obtained from the SASL negotiation itself. Likewise, the client MUST discard any knowledge obtained from the server, such as the list of available POP3 service extensions.
当安全层生效时，服务器必须放弃以前从客户端获得的任何知识，这些知识不是从SASL协商本身获得的。同样，客户机必须放弃从服务器获得的任何知识，例如可用POP3服务扩展的列表。
When both Transport Layer Security (TLS) (see [RFC4346]) and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding when sending data. (According to [RFC2595], STLS can only be issued before AUTH in any case.)
当传输层安全（TLS）（请参见[RFC4346]）和SASL安全层都有效时，发送数据时，必须在SASL编码之后应用TLS编码。（根据[RFC2595]，STL在任何情况下都只能在授权前发布。）
Note that POP3 does not allow for additional data to be sent with a message indicating a successful outcome (see Section 3.6 of [RFC4422]).
请注意，POP3不允许发送附加数据，同时发送指示成功结果的消息（参见[RFC4422]第3.6节）。
The service name specified by this protocol's profile of SASL is "pop".
此协议的SASL配置文件指定的服务名称为“pop”。
If an AUTH command fails, the client may try another authentication mechanism or present different credentials by issuing another AUTH command (or by using one of the other POP3 authentication mechanisms). Likewise, the server MUST behave as if the client had not issued the AUTH command.
如果AUTH命令失败，客户端可以尝试其他身份验证机制，或通过发出另一个AUTH命令（或使用其他POP3身份验证机制之一）来提供不同的凭据。同样，服务器的行为必须与客户端未发出AUTH命令的行为相同。
To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595].
为了确保互操作性，此扩展的客户端和服务器实现必须实现在TLS[RFC2595]上运行的普通SASL机制[RFC4616]。
A server implementation MUST implement a configuration in which it does NOT advertise or permit any plaintext password mechanisms, unless the STLS command has been used to negotiate a TLS session (see [RFC2595]). As described by RFC 4616, this configuration SHOULD be the default configuration. Before using a plaintext password mechanism over a TLS session, client
服务器实现必须实现一种配置，在该配置中，它不公布或允许任何明文密码机制，除非使用STLS命令协商TLS会话（请参见[RFC2595]）。如RFC 4616所述，此配置应为默认配置。在TLS会话上使用明文密码机制之前，客户端
implementations MUST verify the TLS server certificate as required by RFC 2595, Section 2.4. Client and server implementations SHOULD implement additional SASL mechanisms that do not send plaintext passwords, such as the GSSAPI [RFC4752] mechanism.
实施必须按照RFC 2595第2.4节的要求验证TLS服务器证书。客户端和服务器实现应实现不发送明文密码的附加SASL机制，如GSSAPI[RFC4752]机制。
The following syntax specification uses the Augmented Backus-Naur Form notation as specified in [RFC4234]. The rules CRLF, ALPHA, and DIGIT are imported from [RFC4234]. The sasl-mech rule is from [RFC4422].
以下语法规范使用了[RFC4234]中指定的扩展的Backus-Naur形式表示法。规则CRLF、ALPHA和DIGIT从[RFC4234]导入。sasl机械规则来自[RFC4422]。
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.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
auth-command = "AUTH" SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF
auth command=“auth”SP sasl mech[SP initial response]*（CRLF[base64]）[CRLF cancel response]CRLF
initial-response = base64 / "="
initial-response = base64 / "="
cancel-response = "*"
取消响应=“*”
base64 = base64-terminal / ( 1*(4base64-CHAR) [base64-terminal] )
base64=base64终端/（1*（4base64字符）[base64终端]）
base64-char = ALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64-char = ALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
base64-terminal = (2base64-char "==") / (3base64-char "=")
continue-req = "+" SP [base64] CRLF
continue req=“+”SP[base64]CRLF
Additionally, the ABNF specified in [RFC2449] is updated as follows:
此外，[RFC2449]中规定的ABNF更新如下：
response =/ continue-req
响应=/continue请求
Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) under TLS and making use of the initial client response:
下面是一个客户机尝试在TLS下进行普通身份验证（请参见[RFC4616]）并利用初始客户机响应的示例：
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: STLS
S: +OK Begin TLS negotiation now
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: STLS
S: +OK Begin TLS negotiation now
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
Here is another client that is attempting AUTH PLAIN under a TLS layer, this time without the initial response. Parts of the negotiation before the TLS layer was established have been omitted:
下面是另一个客户端，它正在尝试在TLS层下进行普通身份验证，这次没有初始响应。TLS层建立之前的部分协商已被省略：
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN
(note that there is a space following the '+' on the
following line)
S: +
C: dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN
(note that there is a space following the '+' on the
following line)
S: +
C: dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
Here is an example using a mechanism in which the exchange begins with a server challenge (the long lines are broken for editorial clarity only):
下面是一个使用一种机制的示例，在该机制中，exchange以服务器质询开始（为了编辑清晰起见，长线被打断）：
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
C:
S: +OK Maildrop locked and ready
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
C:
S: +OK Maildrop locked and ready
Security issues are discussed throughout this document.
本文档中讨论了安全问题。
The IANA has updated its site to refer to this RFC instead of [RFC1734] in http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 extension registry), and also in http://www.iana.org/assignments/gssapi-service-names (the GSSAPI/SASL service name registry).
IANA已更新其站点，以引用此RFC，而不是中的[RFC1734]http://www.iana.org/assignments/pop3-extension-mechanism （POP3扩展注册表），以及http://www.iana.org/assignments/gssapi-service-names （GSSAPI/SASL服务名称注册表）。
The authors would like to acknowledge the contributions of John Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other contributors to RFC 1734 and RFC 2554, on which this document draws heavily.
作者要感谢John Myers、Randall Gellens、Chris Newman、Laurence Lundblade以及RFC 1734和RFC 2554的其他贡献者的贡献，本文件在这些贡献中起了重要作用。
The authors would also like to thank Ken Murchison, Randall Gellens, Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, Frank Ellermann, and Philip Guenther for their reviews of this document.
作者还要感谢Ken Murchison、Randall Gellens、Alexey Melnikov、Mark Crispin、Arnt Gulbrandsen、Lisa Dusseault、Frank Ellermann和Philip Guenther对本文件的评论。
10. Changes From RFC 1734, RFC 2449.
10. 与RFC 1734、RFC 2449的变更。
1. Updated references to newer versions of various specifications, particularly RFC 4422.
1. 更新了各种规范的更新版本参考，尤其是RFC 4422。
2. The SASL-based semantics defined in RFC 2449 are now normative for the AUTH extension.
2. RFC2449中定义的基于SASL的语义现在是AUTH扩展的规范。
3. The proper behaviour and handling of initial client responses is defined, with examples and references to SASL.
3. 定义了初始客户响应的正确行为和处理，并提供了示例和SASL参考。
4. New minimum requirement of support for TLS+PLAIN.
4. TLS+平面支架的新最低要求。
5. The SASLprep profile SHOULD be used to prepare authorization identities.
5. SASLprep配置文件应用于准备授权标识。
6. Clarify that the TLS encoding should be applied after any encoding applied by SASL security layers.
6. 阐明TLS编码应在SASL安全层应用任何编码后应用。
7. Note that the mechanism list can change after STLS.
7. 请注意，STL之后，机制列表可能会更改。
8. Explicitly mention that "=" means a zero-length initial response.
8. 明确指出“=”表示零长度初始响应。
9. Note that POP3 doesn't allow additional data to be sent with +OK.
9. 请注意，POP3不允许使用+OK发送附加数据。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[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月。
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[RFC2449]Gellens，R.，Newman，C.，和L.Lundblade，“POP3扩展机制”，RFC 2449，1998年11月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616]Zeilenga，K.，Ed.“简单认证和安全层（SASL）机制”，RFC4616，2006年8月。
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734]迈尔斯，J.，“POP3认证命令”，RFC17341994年12月。
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC3206]Gellens，R.，“系统和认证POP响应代码”，RFC3206，2002年2月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752]Melnikov，A.，Ed.，“Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制”，RFC 47522006年11月。
Authors' Addresses
作者地址
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043
Robert Siemborski Google，Inc.加利福尼亚州安比塞特公园山景大道1600号，邮编94043
Phone: +1 650 623 6925
EMail: robsiemb@google.com
Phone: +1 650 623 6925
EMail: robsiemb@google.com
Abhijit Menon-Sen Oryx Mail Systems GmbH
Abhijit Menon Sen Oryx邮件系统有限公司
EMail: ams@oryx.com
EMail: ams@oryx.com
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。