Network Working Group R. Gellens
Request for Comments: 2449 Qualcomm
Updates: 1939 C. Newman
Category: Standards Track Innosoft
L. Lundblade
Qualcomm
November 1998
Network Working Group R. Gellens
Request for Comments: 2449 Qualcomm
Updates: 1939 C. Newman
Category: Standards Track Innosoft
L. Lundblade
Qualcomm
November 1998
POP3 Extension Mechanism
POP3扩展机制
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
IESG Note
IESG注释
This extension to the POP3 protocol is to be used by a server to express policy descisions taken by the server administrator. It is not an endorsement of implementations of further POP3 extensions generally. It is the general view that the POP3 protocol should stay simple, and for the simple purpose of downloading email from a mail server. If more complicated operations are needed, the IMAP protocol [RFC 2060] should be used. The first paragraph of section 7 should be read very carefully.
服务器将使用POP3协议的此扩展来表示服务器管理员采取的策略描述。一般来说，这不是对进一步POP3扩展实现的认可。一般认为，POP3协议应该保持简单，并用于从邮件服务器下载电子邮件的简单目的。如果需要更复杂的操作，则应使用IMAP协议[RFC 2060]。应仔细阅读第7节的第一段。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 3
3. General Command and Response Grammar . . . . . . . . . . . . 3
4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 3
3. General Command and Response Grammar . . . . . . . . . . . . 3
4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
The Post Office Protocol version 3 [POP3] is very widely used. However, while it includes some optional commands (and some useful protocol extensions have been published), it lacks a mechanism for advertising support for these extensions or for behavior variations.
邮局协议版本3[POP3]使用非常广泛。然而，尽管它包含一些可选命令（并且已经发布了一些有用的协议扩展），但它缺乏一种机制来宣传对这些扩展或行为变化的支持。
Currently these optional features and extensions can only be detected by probing, if at all. This is at best inefficient, and possibly worse. As a result, some clients have manual configuration options for POP3 server capabilities.
目前，这些可选功能和扩展只能通过探测（如果有的话）来检测。这充其量是低效的，甚至可能更糟。因此，一些客户端具有POP3服务器功能的手动配置选项。
Because one of the most important characteristics of POP3 is its simplicity, it is desirable that extensions be few in number (see section 7). However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In addition, a means for discovering server behavior is needed.
因为POP3最重要的特性之一是它的简单性，所以希望扩展的数量少一些（参见第7节）。但是，一些扩展是必要的（例如提供改进的安全性[POP-AUTH]），而其他扩展在某些情况下是非常可取的。此外，还需要一种发现服务器行为的方法。
This memo updates RFC 1939 [POP3] to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. Included is an initial set of currently deployed capabilities which vary between server implementations, and several new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION). This document also extends POP3 error messages so that machine parsable codes can be provided to the client. An initial set of response codes is included. In addition, an [ABNF] specification of POP3 commands and responses is defined.
本备忘录更新了RFC1939[POP3]，以定义一种机制来宣布对可选命令、扩展和无条件服务器行为的支持。其中包括一组当前部署的功能，这些功能在服务器实现之间有所不同，还有一些新功能（SASL、RESP-CODE、登录延迟、管道、过期和实现）。本文档还扩展了POP3错误消息，以便可以向客户端提供机器可解析代码。包括一组初始响应代码。此外，还定义了POP3命令和响应的[ABNF]规范。
Public comments should be sent to the IETF POP3 Extensions mailing list, <ietf-pop3ext@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
公众意见应发送至IETF POP3扩展邮件列表，<IETF-pop3ext@imc.org>. 要订阅，请发送包含订阅<ietf-pop3ext的消息-request@imc.org>.
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The general form of POP3 commands and responses is described using [ABNF]:
POP3命令和响应的一般形式使用[ABNF]描述：
POP3 commands:
POP3命令：
command = keyword *(SP param) CRLF ;255 octets maximum
keyword = 3*4VCHAR
param = 1*VCHAR
command = keyword *(SP param) CRLF ;255 octets maximum
keyword = 3*4VCHAR
param = 1*VCHAR
POP3 responses:
POP3响应：
response = greeting / single-line / capa-resp / multi-line
capa-resp = single-line *capability "." CRLF
capa-tag = 1*cchar
capability = capa-tag *(SP param) CRLF ;512 octets maximum
cchar = %x21-2D / %x2F-7F
;printable ASCII, excluding "."
dot-stuffed = *CHAR CRLF ;must be dot-stuffed
gchar = %x21-3B / %x3D-7F
;printable ASCII, excluding "<"
greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
;512 octets maximum
multi-line = single-line *dot-stuffed "." CRLF
rchar = %x21-2E / %x30-5C / %x5E-7F
;printable ASCII, excluding "/" and "]"
resp-code = "[" resp-level *("/" resp-level) "]"
resp-level = 1*rchar
schar = %x21-5A / %x5C-7F
;printable ASCII, excluding "["
single-line = status [SP text] CRLF ;512 octets maximum
status = "+OK" / "-ERR"
text = *schar / resp-code *CHAR
timestamp = "<" *VCHAR ">"
;MUST conform to RFC-822 msg-id
response = greeting / single-line / capa-resp / multi-line
capa-resp = single-line *capability "." CRLF
capa-tag = 1*cchar
capability = capa-tag *(SP param) CRLF ;512 octets maximum
cchar = %x21-2D / %x2F-7F
;printable ASCII, excluding "."
dot-stuffed = *CHAR CRLF ;must be dot-stuffed
gchar = %x21-3B / %x3D-7F
;printable ASCII, excluding "<"
greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
;512 octets maximum
multi-line = single-line *dot-stuffed "." CRLF
rchar = %x21-2E / %x30-5C / %x5E-7F
;printable ASCII, excluding "/" and "]"
resp-code = "[" resp-level *("/" resp-level) "]"
resp-level = 1*rchar
schar = %x21-5A / %x5C-7F
;printable ASCII, excluding "["
single-line = status [SP text] CRLF ;512 octets maximum
status = "+OK" / "-ERR"
text = *schar / resp-code *CHAR
timestamp = "<" *VCHAR ">"
;MUST conform to RFC-822 msg-id
This specification increases the length restrictions on commands and parameters imposed by RFC 1939.
本规范增加了RFC1939对命令和参数的长度限制。
The maximum length of a command is increased from 47 characters (4 character command, single space, 40 character argument, CRLF) to 255 octets, including the terminating CRLF.
命令的最大长度从47个字符（4个字符的命令，单空格，40个字符的参数，CRLF）增加到255个八位字节，包括终止的CRLF。
Servers which support the CAPA command MUST support commands up to 255 octets. Servers MUST also support the largest maximum command length specified by any supported capability.
支持CAPA命令的服务器必须支持多达255个八位字节的命令。服务器还必须支持任何支持的功能指定的最大命令长度。
The maximum length of the first line of a command response (including the initial greeting) is unchanged at 512 octets (including the terminating CRLF).
命令响应（包括初始问候语）第一行的最大长度不变，为512个八位字节（包括终止的CRLF）。
The POP3 CAPA command returns a list of capabilities supported by the POP3 server. It is available in both the AUTHORIZATION and TRANSACTION states.
POP3 CAPA命令返回POP3服务器支持的功能列表。它在授权和事务状态下都可用。
A capability description MUST document in which states the capability is announced, and in which states the commands are valid.
能力描述必须记录宣布能力的状态以及命令有效的状态。
Capabilities available in the AUTHORIZATION state MUST be announced in both states.
授权状态下可用的功能必须在这两个状态下公布。
If a capability is announced in both states, but the argument might differ after authentication, this possibility MUST be stated in the capability description.
如果在两种状态下都宣布了一种功能，但在身份验证后参数可能不同，则必须在功能描述中说明这种可能性。
(These requirements allow a client to issue only one CAPA command if it does not use any TRANSACTION-only capabilities, or any capabilities whose values may differ after authentication.)
（如果客户机不使用任何仅事务功能或任何在身份验证后其值可能不同的功能，则这些要求允许客户机仅发出一个CAPA命令。）
If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating, to check for active down-negotiation attacks.
如果身份验证步骤协商完整性保护层，则客户端应在身份验证后重新发出CAPA命令，以检查是否存在主动向下协商攻击。
Each capability may enable additional protocol commands, additional parameters and responses for existing commands, or describe an aspect of server behavior. These details are specified in the description of the capability.
每个功能都可以为现有命令启用附加协议命令、附加参数和响应，或者描述服务器行为的一个方面。这些详细信息在功能描述中指定。
Section 3 describes the CAPA response using [ABNF]. When a capability response describes an optional command, the <capa-tag> SHOULD be identical to the command keyword. CAPA response tags are case-insensitive.
第3节使用[ABNF]描述CAPA响应。当能力响应描述可选命令时，<capa tag>应与命令关键字相同。CAPA响应标记不区分大小写。
CAPA
卡帕
Arguments: none
论点：无
Restrictions: none
限制：无
Discussion: An -ERR response indicates the capability command is not implemented and the client will have to probe for capabilities as before.
讨论：-ERR响应表示未实现capability命令，客户端必须像以前一样探测功能。
An +OK response is followed by a list of capabilities, one per line. Each capability name MAY be followed by a single space and a space-separated list of parameters. Each capability line is limited to 512 octets (including the CRLF). The capability list is terminated by a line containing a termination octet (".") and a CRLF pair.
+OK响应之后是一个功能列表，每行一个。每个功能名称后面可以跟一个空格和一个以空格分隔的参数列表。每个能力线限制为512个八位字节（包括CRLF）。能力列表由包含终止八位字节（“.”）和CRLF对的行终止。
Possible Responses: +OK -ERR
可能的响应：+OK-错误
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
This section defines an initial set of POP3 capabilities. These include the optional POP3 commands, already published POP3 extensions, and behavior variations between POP3 servers which can impact clients.
本节定义了POP3功能的初始集合。其中包括可选的POP3命令、已发布的POP3扩展以及POP3服务器之间可能影响客户端的行为变化。
Note that there is no APOP capability, even though APOP is an optional command in [POP3]. Clients discover server support of APOP by the presence in the greeting banner of an initial challenge enclosed in angle brackets ("<>"). Therefore, an APOP capability would introduce two ways for a server to announce the same thing.
请注意，即使APOP是[POP3]中的可选命令，也没有APOP功能。客户机发现服务器对APOP的支持是通过在角括号（“<>”）中包含的初始质询的问候横幅中出现。因此，APOP功能将为服务器引入两种方法来宣布相同的事情。
CAPA tag: TOP
CAPA标签：顶部
Arguments: none
论点：无
Added commands: TOP
添加命令：TOP
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: TRANSACTION
在以下状态下有效的命令：事务
Specification reference: [POP3]
规范参考：[POP3]
Discussion: The TOP capability indicates the optional TOP command is available.
讨论：TOP功能表示可选的TOP命令可用。
CAPA tag: USER
CAPA标签：用户
Arguments: none
论点：无
Added commands: USER PASS
添加命令：用户通行证
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: AUTHENTICATION
在以下状态下有效的命令：身份验证
Specification reference: [POP3]
规范参考：[POP3]
Discussion: The USER capability indicates that the USER and PASS commands are supported, although they may not be available to all users.
讨论：用户功能表明支持用户和PASS命令，尽管它们可能不适用于所有用户。
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: AUTHENTICATION
在以下状态下有效的命令：身份验证
Specification reference: [POP-AUTH, SASL]
规范参考：[POP-AUTH，SASL]
Discussion: The POP3 AUTH command [POP-AUTH] permits the use of [SASL] authentication mechanisms with POP3. The SASL capability indicates that the AUTH command is available and that it supports an optional base64 encoded second argument for an initial client response as described in the SASL specification. The argument to the SASL capability is a space separated list of SASL mechanisms which are supported.
讨论：POP3 AUTH命令[POP-AUTH]允许对POP3使用[SASL]身份验证机制。SASL功能表明AUTH命令可用，并且它支持可选的base64编码的第二个参数，用于初始客户端响应，如SASL规范中所述。SASL功能的参数是一个以空间分隔的列表，其中列出了受支持的SASL机制。
CAPA tag: RESP-CODES
CAPA标签：RESP-CODES
Arguments: none
论点：无
Added commands: none
添加命令：无
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: n/a
在以下状态下有效的命令：不适用
Specification reference: this document
规范参考：本文件
Discussion: The RESP-CODES capability indicates that any response text issued by this server which begins with an open square bracket ("[") is an extended response code (see section 8).
讨论：RESP-CODES功能表示此服务器发出的任何以开放方括号（“[”）开头的响应文本都是扩展响应代码（请参阅第8节）。
CAPA tag: LOGIN-DELAY
CAPA标签：登录延迟
Arguments: minimum seconds between logins; optionally followed by USER in AUTHENTICATION state.
参数：登录之间的最小秒数；可选地，后跟处于身份验证状态的用户。
Added commands: none
添加命令：无
Standard commands affected: USER PASS APOP AUTH
受影响的标准命令：用户传递APOP AUTH
Announced states / possible differences: both / yes
宣布的州/可能的差异：两者/是
Commands valid in states: n/a
在以下状态下有效的命令：不适用
Specification reference: this document
规范参考：本文件
Discussion: POP3 clients often login frequently to check for new mail. Unfortunately, the process of creating a connection, authenticating the user, and opening the user's maildrop can be very resource intensive on the server. A number of deployed POP3 servers try to reduce server load by requiring a delay between logins. The LOGIN-DELAY capability includes an integer argument which indicates the number of seconds after an "+OK" response to a PASS, APOP, or AUTH command before another authentication will be accepted. Clients which permit the user to configure a mail check interval SHOULD use this capability to determine the minimum permissible interval. Servers which advertise LOGIN-DELAY SHOULD enforce it.
讨论：POP3客户端经常登录以检查新邮件。不幸的是，在服务器上创建连接、验证用户和打开用户邮件的过程可能会占用大量资源。许多已部署的POP3服务器试图通过要求登录之间的延迟来减少服务器负载。LOGIN-DELAY功能包括一个整数参数，该参数指示在接受另一个身份验证之前，对PASS、APOP或AUTH命令做出“+OK”响应后的秒数。允许用户配置邮件检查间隔的客户端应使用此功能确定最小允许间隔。播发登录延迟的服务器应强制执行登录延迟。
If the minimum login delay period could differ per user (that is, the LOGIN-DELAY argument might change after authentication), the server MUST announce in AUTHENTICATION state the largest value which could be set for any user. This might be the largest value currently in use for any user (so only one value per server), or even the largest value which the server permits to be set for any user. The server SHOULD append the token "USER" to the LOGIN-DELAY parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication. The server SHOULD announce the more accurate value in TRANSACTION state. (The "USER" token allows the client to decide if a second CAPA command is needed or not.)
如果每个用户的最小登录延迟时间可能不同（即，登录延迟参数在身份验证后可能会更改），则服务器必须在身份验证状态下宣布可为任何用户设置的最大值。这可能是任何用户当前使用的最大值（因此每个服务器只有一个值），甚至是服务器允许为任何用户设置的最大值。服务器应该在身份验证状态下将令牌“USER”附加到LOGIN-DELAY参数，以通知客户端身份验证后可以使用更准确的值。服务器应该在事务状态中宣布更准确的值。（用户令牌允许客户端决定是否需要第二个CAPA命令。）
Servers enforce LOGIN-DELAY by rejecting an authentication command with or without the LOGIN-DELAY error response. See section 8.1.1 for more information.
服务器通过拒绝具有或不具有登录延迟错误响应的身份验证命令来强制执行登录延迟。详见第8.1.1节。
CAPA tag: PIPELINING
CAPA标签：流水线
Arguments: none
论点：无
Added commands: none
添加命令：无
Standard commands affected: all
受影响的标准命令：全部
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: n/a
在以下状态下有效的命令：不适用
Specification reference: this document
规范参考：本文件
Discussion: The PIPELINING capability indicates the server is capable of accepting multiple commands at a time; the client does not have to wait for the response to a command before issuing a subsequent command. If a server supports PIPELINING, it MUST process each command in turn. If a client uses PIPELINING, it MUST keep track of which commands it has outstanding, and match server responses to commands in order. If either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer.
讨论：流水线功能表明服务器能够一次接受多个命令；客户端不必在发出后续命令之前等待对命令的响应。如果服务器支持流水线，它必须依次处理每个命令。如果客户机使用管道，它必须跟踪它有哪些未完成的命令，并按顺序匹配服务器对命令的响应。如果客户端或服务器使用阻塞写入，则它不得超过底层传输层的窗口大小。
Some POP3 clients have an option to indicate the server supports "Overlapped POP3 commands." This capability removes the need to configure this at the client.
一些POP3客户端有一个选项来指示服务器支持“重叠的POP3命令”。此功能消除了在客户端配置此命令的需要。
This is roughly synonymous with the ESMTP PIPELINING extension [PIPELINING], however, since SMTP [SMTP] tends to have short commands and responses, the benefit is in grouping multiple commands and sending them as a unit. While there are cases of this in POP (for example, USER and PASS could be batched, multiple RETR and/or DELE commands could be sent as a group), because POP has short commands and sometimes lengthy responses, there is also an advantage is sending new commands while still receiving the response to an earlier command (for example, sending RETR and/or DELE commands while processing a UIDL reply).
这大致等同于ESMTP管道扩展[Pipeline]，但是，由于SMTP[SMTP]往往具有较短的命令和响应，其好处在于将多个命令分组并作为一个单元发送。虽然在POP中存在这种情况（例如，用户和PASS可以成批处理，多个RETR和/或DELE命令可以作为一个组发送），但由于POP的命令较短，有时响应较长，因此还有一个优势，即在发送新命令的同时仍然接收对早期命令的响应（例如，在处理UIDL应答时发送RETR和/或DELE命令）。
CAPA tag: EXPIRE
CAPA标签：过期
Arguments: server-guaranteed minimum retention days, or NEVER; optionally followed by USER in AUTHENTICATION state
参数：服务器保证的最低保留天数，或从不；可选后跟处于身份验证状态的用户
Added commands: none
添加命令：无
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both / yes
宣布的州/可能的差异：两者/是
Commands valid in states: n/a
在以下状态下有效的命令：不适用
Specification reference: this document
规范参考：本文件
Discussion: While POP3 allows clients to leave messages on the server, RFC 1939 [POP3] warns about the problems that may arise from this, and allows servers to delete messages based on site policy.
讨论：虽然POP3允许客户端在服务器上留下消息，但RFC 1939[POP3]警告可能由此产生的问题，并允许服务器根据站点策略删除消息。
The EXPIRE capability avoids the problems mentioned in RFC 1939, by allowing the server to inform the client as to the policy in effect. The argument to the EXPIRE capability indicates the minimum server retention period, in days, for messages on the server.
EXPIRE功能通过允许服务器向客户机通知有效的策略，避免了RFC1939中提到的问题。EXPIRE功能的参数表示服务器上邮件的最短服务器保留期（以天为单位）。
EXPIRE 0 indicates the client is not permitted to leave mail on the server; when the session enters the UPDATE state the server MAY assume an implicit DELE for each message which was downloaded with RETR.
EXPIRE 0表示不允许客户端将邮件留在服务器上；当会话进入更新状态时，服务器可能会对使用RETR下载的每条消息采用隐式DELE。
EXPIRE NEVER asserts that the server does not delete messages.
EXPIRE NEVER断言服务器不会删除邮件。
The concept of a "retention period" is intentionally vague. Servers may start counting days to expiration when a message is added to a maildrop, when a client becomes aware of the existence of a message through the LIST or UIDL commands, when a message has been acted upon in some way (for example, TOP or RETR), or at some other event. The EXPIRE capability cannot provide a precise indication as to exactly when any specific message will expire. The capability is intended to make it easier for clients to behave in ways which conform to site policy and user wishes. For example, a client might display a warning for attempts to configure a "leave mail on server" period which is greater than or equal to some percentage of the value announced by the server.
“保留期”的概念故意含糊不清。当消息被添加到邮件投递时，当客户端通过LIST或UIDL命令意识到消息的存在时，当消息以某种方式（例如TOP或RETR）被处理时，或者在某些其他事件时，服务器可能开始计算过期天数。EXPIRE功能无法精确指示任何特定消息何时过期。该功能旨在使客户端更容易以符合站点策略和用户意愿的方式行事。例如，客户机可能会显示一条警告，表示试图配置“将邮件留在服务器上”的时间段大于或等于服务器宣布的值的某个百分比。
If a site uses any automatic deletion policy, it SHOULD use the EXPIRE capability to announce this.
如果站点使用任何自动删除策略，它应该使用EXPIRE功能来宣布这一点。
The EXPIRE capability, with a parameter other than 0 or NEVER, is intended to let the client know that the server does permit mail to be left on the server, and to present a value which is the smallest which might be in force.
EXPIRE功能的参数不是0或NEVER，其目的是让客户机知道服务器允许邮件留在服务器上，并提供可能生效的最小值。
Sites which permit users to retain messages indefinitely SHOULD announce this with the EXPIRE NEVER response.
允许用户无限期保留消息的站点应该用EXPIRE NEVER响应来宣布这一点。
If the expiration policy differs per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in AUTHENTICATION state the smallest value which could be set for any user. This might be the smallest value currently in use for any user (so only one value per server), or even the smallest value which the server permits to be set for any user. The server SHOULD append the token "USER" to the EXPIRE parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication. The server SHOULD announce the more accurate value in TRANSACTION state. (The "USER" token allows the client to decide if a second CAPA command is needed or not.)
如果每个用户的过期策略不同（即，在身份验证后EXPIRE参数可能会更改），则服务器必须在身份验证状态下宣布可以为任何用户设置的最小值。这可能是任何用户当前使用的最小值（因此每个服务器只有一个值），甚至是服务器允许为任何用户设置的最小值。服务器应将令牌“USER”附加到身份验证状态下的EXPIRE参数，以通知客户端身份验证后有更准确的值可用。服务器应该在事务状态中宣布更准确的值。（用户令牌允许客户端决定是否需要第二个CAPA命令。）
A site may have a message expiration policy which treats messages differently depending on which user actions have been performed, or based on other factors. For example, a site might delete unseen messages after 60 days, and completely- or partially-seen messages after 15 days.
站点可能有一个消息过期策略，该策略根据执行的用户操作或其他因素对消息进行不同的处理。例如，一个站点可能在60天后删除未看到的邮件，在15天后删除全部或部分看到的邮件。
The announced EXPIRE value is the smallest retention period which is or might be used by any category or condition of the current site policy, for any user (in AUTHENTICATION state) or the specific user (in TRANSACTION state). That is, EXPIRE informs the client of the minimum number of days messages may remain on the server under any circumstances.
宣布的过期值是当前站点策略的任何类别或条件对任何用户（处于身份验证状态）或特定用户（处于事务状态）使用的或可能使用的最小保留期。也就是说，EXPIRE通知客户端消息在任何情况下都可以保留在服务器上的最短天数。
Examples: EXPIRE 5 USER EXPIRE 30 EXPIRE NEVER EXPIRE 0
示例：过期5用户过期30过期永不过期0
The first example indicates the server might delete messages after five days, but the period differs per user, and so a more accurate value can be obtained by issuing a second CAPA command in TRANSACTION state. The second example indicates the server could delete messages after 30 days. In the third example, the server announces it does not delete messages. The fourth example specifies that the site does not permit messages to be left on the server.
第一个示例表明服务器可能会在五天后删除消息，但每个用户的时间段不同，因此可以通过在事务状态下发出第二个CAPA命令来获得更准确的值。第二个示例表明服务器可以在30天后删除邮件。在第三个示例中，服务器宣布它不删除消息。第四个示例指定站点不允许将消息留在服务器上。
CAPA tag: UIDL
CAPA标签：UIDL
Arguments: none
论点：无
Added commands: UIDL
添加命令：UIDL
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both / no
宣布的州/可能的差异：两者/否
Commands valid in states: TRANSACTION
在以下状态下有效的命令：事务
Specification reference: [POP3]
规范参考：[POP3]
Discussion: The UIDL capability indicates that the optional UIDL command is supported.
讨论：UIDL功能表明支持可选的UIDL命令。
CAPA tag: IMPLEMENTATION
CAPA标签：实现
Arguments: string giving server implementation information
参数：提供服务器实现信息的字符串
Added commands: none
添加命令：无
Standard commands affected: none
受影响的标准命令：无
Announced states / possible differences: both (optionally TRANSACTION only) / no
公布状态/可能的差异：两者（可选仅限交易）/否
Commands valid in states: n/a
在以下状态下有效的命令：不适用
Specification reference: this document
规范参考：本文件
Discussion: It is often useful to identify an implementation of a particular server (for example, when logging). This is commonly done in the welcome banner, but one must guess if a string is an implementation ID or not.
讨论：识别特定服务器的实现（例如，在日志记录时）通常很有用。这通常在欢迎横幅中完成，但必须猜测字符串是否是实现ID。
The argument to the IMPLEMENTATION capability consists of one or more tokens which identify the server. (Note that since CAPA response tag arguments are space-separated, it may be convenient for the IMPLEMENTATION capability argument to not contain spaces, so that it is a single token.)
实现功能的参数由一个或多个标识服务器的令牌组成。（请注意，由于CAPA响应标记参数是空格分隔的，因此实现能力参数不包含空格可能比较方便，因此它是单个标记。）
Normally, servers announce IMPLEMENTATION in both states. However, a server MAY chose to do so only in TRANSACTION state.
通常，服务器会在这两种状态下宣布实现。但是，服务器可以选择仅在事务状态下执行此操作。
A server MAY include the implementation identification both in the welcome banner and in the IMPLEMENTATION capability.
服务器可以在欢迎横幅和实现能力中包括实现标识。
Clients MUST NOT modify their behavior based on the server implementation. Instead the server and client should agree on a private extension.
客户端不得根据服务器实现修改其行为。相反，服务器和客户端应该就私有扩展达成一致。
Future extensions to POP3 are in general discouraged, as POP3's usefulness lies in its simplicity. POP3 is intended as a download-and-delete protocol; mail access capabilities are available in IMAP [IMAP4]. Extensions which provide support for additional mailboxes, allow uploading of messages to the server, or which deviate from POP's download-and-delete model are strongly discouraged and unlikely to be permitted on the IETF standards track.
一般不鼓励将来对POP3进行扩展，因为POP3的实用性在于它的简单性。POP3旨在作为下载和删除协议；IMAP[IMAP4]中提供了邮件访问功能。强烈反对支持额外邮箱、允许向服务器上传消息或偏离POP下载和删除模式的扩展，IETF标准不太可能允许这些扩展。
Clients MUST NOT require the presence of any extension for basic functionality, with the exception of the authentication commands (APOP, AUTH [section 6.3] and USER/PASS).
除认证命令（APOP、AUTH[第6.3节]和USER/PASS）外，客户端不得要求存在任何基本功能的扩展。
Section 9 specifies how additional capabilities are defined.
第9节规定了如何定义附加功能。
Unextended POP3 is only capable of indicating success or failure to most commands. Unfortunately, clients often need to know more information about the cause of a failure in order to gracefully recover. This is especially important in response to a failed login
未扩展的POP3只能指示大多数命令的成功或失败。不幸的是，客户端通常需要了解有关故障原因的更多信息，以便正常恢复。这对于响应失败的登录尤其重要
(there are widely-deployed clients which attempt to decode the error text of a PASS command result, to try and distinguish between "unable to get maildrop lock" and "bad login").
（有广泛部署的客户端试图解码PASS命令结果的错误文本，以尝试区分“无法获取邮件投递锁”和“错误登录”）。
This specification amends the POP3 standard to permit an optional response code, enclosed in square brackets, at the beginning of the human readable text portion of an "+OK" or "-ERR" response. Clients supporting this extension MAY remove any information enclosed in square brackets prior to displaying human readable text to the user. Immediately following the open square bracket "[" character is a response code which is interpreted in a case-insensitive fashion by the client.
本规范修订了POP3标准，允许在“+OK”或“-ERR”响应的人类可读文本部分的开头使用方括号中的可选响应代码。支持此扩展的客户端可以在向用户显示人类可读文本之前删除方括号中包含的任何信息。紧跟在方括号“[”后面的是响应代码，客户端以不区分大小写的方式解释该代码。
The response code is hierarchical, with a "/" separating levels of detail about the error. Clients MUST ignore unknown hierarchical detail about the response code. This is important, as it could be necessary to provide further detail for response codes in the future.
响应代码是分层的，用“/”分隔有关错误的详细级别。客户端必须忽略有关响应代码的未知层次结构详细信息。这一点很重要，因为将来可能需要为响应代码提供更多细节。
Section 3 describes response codes using [ABNF].
第3节描述了使用[ABNF]的响应代码。
If a server supports extended response codes, it indicates this by including the RESP-CODES capability in the CAPA response.
如果服务器支持扩展响应代码，则通过在CAPA响应中包含RESP-codes功能来表明这一点。
Examples:
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?
Examples:
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?
This specification defines two POP3 response codes which can be used to determine the reason for a failed login. Section 9 specifies how additional response codes are defined.
本规范定义了两个POP3响应代码，可用于确定登录失败的原因。第9节规定了如何定义其他响应代码。
This occurs on an -ERR response to an AUTH, USER (see note), PASS or APOP command and indicates that the user has logged in recently and will not be allowed to login again until the login delay period has expired.
这发生在对AUTH、USER（请参见注释）、PASS或APOP命令的-ERR响应上，表示该用户最近已登录，并且在登录延迟期到期之前将不允许再次登录。
NOTE: Returning the LOGIN-DELAY response code to the USER command avoids the work of authenticating the user but reveals to the client that the specified user exists. Unless the server is operating in an environment where user names are not secret (for example, many popular email clients advertise the POP server and user name in an outgoing mail header), or where server access is restricted, or the server can verify that the connection is to the same user, it is
注意：将LOGIN-DELAY响应代码返回给USER命令可以避免验证用户的工作，但会向客户端显示指定的用户存在。除非服务器在用户名不保密的环境中运行（例如，许多流行的电子邮件客户端在传出邮件头中公布POP服务器和用户名），或者服务器访问受到限制，或者服务器可以验证连接是否与同一用户，否则它是保密的
strongly recommended that the server not issue this response code to the USER command. The server still saves the cost of opening the maildrop, which in some environments is the most expensive step.
强烈建议服务器不要向用户命令发出此响应代码。服务器仍然可以节省打开邮件投递的成本，这在某些环境中是最昂贵的步骤。
This occurs on an -ERR response to an AUTH, APOP, or PASS command. It indicates the authentication was successful, but the user's maildrop is currently in use (probably by another POP3 client).
这发生在对AUTH、APOP或PASS命令的-ERR响应上。它表示身份验证已成功，但用户的maildrop当前正在使用中（可能由另一个POP3客户端使用）。
This document requests that IANA maintain two new registries: POP3 capabilities and POP3 response codes.
本文件要求IANA维护两个新的注册表：POP3功能和POP3响应代码。
New POP3 capabilities MUST be defined in a standards track or IESG approved experimental RFC, and MUST NOT begin with the letter "X".
新POP3功能必须在标准轨道或IESG批准的实验RFC中定义，且不得以字母“X”开头。
New POP3 capabilities MUST include the following information: CAPA tag Arguments Added commands Standard commands affected Announced states / possible differences Commands valid in states Specification reference Discussion
新的POP3功能必须包括以下信息：CAPA标记参数添加命令标准命令受影响的公布状态/可能的差异命令有效状态规范参考讨论
In addition, new limits for POP3 command and response lengths may need to be included.
此外，可能需要包括POP3命令和响应长度的新限制。
New POP3 response codes MUST be defined in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. (This is the "Specification Required" policy described in [IANA]).
新的POP3响应代码必须在RFC或其他永久性且随时可用的参考文件中定义，且必须足够详细，以便独立实现之间的互操作性成为可能。（这是[IANA]中描述的“规范要求”政策）。
New POP3 response code specifications MUST include the following information: the complete response code, for which responses (+OK or -ERR) and commands it is valid, and a definition of its meaning and expected client behavior.
新的POP3响应代码规范必须包括以下信息：完整的响应代码，响应（+OK或-ERR）和命令对其有效，以及对其含义和预期客户端行为的定义。
A capability list can reveal information about the server's authentication mechanisms which can be used to determine if certain attacks will be successful. However, allowing clients to automatically detect availability of stronger mechanisms and alter their configurations to use them can improve overall security at a site.
功能列表可以显示有关服务器身份验证机制的信息，这些信息可用于确定某些攻击是否会成功。然而，允许客户端自动检测更强机制的可用性并更改其配置以使用它们可以提高站点的整体安全性。
Section 8.1 discusses the security issues related to use of the LOGIN-DELAY response code with the USER command.
第8.1节讨论了与用户命令使用登录延迟响应代码相关的安全问题。
This document has been revised in part based on comments and discussions which took place on and off the IETF POP3 Extensions mailing list. The help of those who took the time to review this memo and make suggestions is appreciated, especially that of Alexey Melnikov, Harald Alvestrand, and Mike Gahrns.
本文件已根据IETF POP3扩展邮件列表内外的评论和讨论进行了部分修订。感谢那些花时间审阅这份备忘录并提出建议的人的帮助，特别是Alexey Melnikov、Harald Alvestrand和Mike Gahrns的帮助。
[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月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IMAP4] Crispin, M., "Internet Message Access Protocol -- Version 4rev1", RFC 2060, December 1996.
[IMAP4]Crispin，M.，“互联网消息访问协议——版本4rev1”，RFC20601996年12月。
[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月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[PIPELINING]Freed，N.，“用于命令管道的SMTP服务扩展”，RFC 21971997年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议——第3版”，STD 53，RFC 1939，1996年5月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]迈尔斯，J.，“POP3认证命令”，RFC 17341994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]Postel，J.，“简单邮件传输协议”，STD 10，RFC 8211982年8月。
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 USA
Randall Gellens高通公司卢斯克大道6455号。美国加利福尼亚州圣地亚哥92121-2779
Phone: +1 619 651 5115
Fax: +1 619 845 7268
EMail: randy@qualcomm.com
Phone: +1 619 651 5115
Fax: +1 619 845 7268
EMail: randy@qualcomm.com
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Chris Newman Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
EMail: chris.newman@innosoft.com
EMail: chris.newman@innosoft.com
Laurence Lundblade QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, Ca, 92121-2779 USA
劳伦斯·伦德布雷德高通公司卢斯克大道6455号。美国加利福尼亚州圣地亚哥92121-2779
Phone: +1 619 658 3584
Fax: +1 619 845 7268
EMail: lgl@qualcomm.com
Phone: +1 619 658 3584
Fax: +1 619 845 7268
EMail: lgl@qualcomm.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。