Network Working Group M. Crispin
Request for Comments: 3501 University of Washington
Obsoletes: 2060 March 2003
Category: Standards Track
Network Working Group M. Crispin
Request for Comments: 3501 University of Washington
Obsoletes: 2060 March 2003
Category: Standards Track
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
INTERNET消息访问协议-版本4rev1
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.
Internet消息访问协议版本4rev1（IMAP4rev1）允许客户端访问和操作服务器上的电子邮件消息。IMAP4rev1允许以功能等同于本地文件夹的方式操纵邮箱（远程邮件文件夹）。IMAP4rev1还提供了脱机客户端与服务器重新同步的功能。
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1包括创建、删除和重命名邮箱、检查新邮件、永久删除邮件、设置和清除标志、RFC 2822和RFC 2045解析、搜索和选择性获取邮件属性、文本及其部分的操作。IMAP4rev1中的消息通过使用数字进行访问。这些数字是消息序列号或唯一标识符。
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1支持单台服务器。RFC 2244中讨论了访问配置信息以支持多个IMAP4rev1服务器的机制。
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.
IMAP4rev1未指定邮寄邮件的方式；此功能由邮件传输协议（如RFC 2821）处理。
Table of Contents
目录
IMAP4rev1 Protocol Specification ................................ 4
1. How to Read This Document ............................... 4
1.1. Organization of This Document ........................... 4
1.2. Conventions Used in This Document ....................... 4
1.3. Special Notes to Implementors ........................... 5
2. Protocol Overview ....................................... 6
2.1. Link Level .............................................. 6
2.2. Commands and Responses .................................. 6
2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
2.3. Message Attributes ...................................... 8
2.3.1. Message Numbers ......................................... 8
2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
2.3.1.2. Message Sequence Number Message Attribute ....... 10
2.3.2. Flags Message Attribute ................................. 11
2.3.3. Internal Date Message Attribute ......................... 12
2.3.4. [RFC-2822] Size Message Attribute ....................... 12
2.3.5. Envelope Structure Message Attribute .................... 12
2.3.6. Body Structure Message Attribute ........................ 12
2.4. Message Texts ........................................... 13
3. State and Flow Diagram .................................. 13
3.1. Not Authenticated State ................................. 13
3.2. Authenticated State ..................................... 13
3.3. Selected State .......................................... 13
3.4. Logout State ............................................ 14
4. Data Formats ............................................ 16
4.1. Atom .................................................... 16
4.2. Number .................................................. 16
4.3. String .................................................. 16
4.3.1. 8-bit and Binary Strings ................................ 17
4.4. Parenthesized List ...................................... 17
4.5. NIL ..................................................... 17
5. Operational Considerations .............................. 18
5.1. Mailbox Naming .......................................... 18
5.1.1. Mailbox Hierarchy Naming ................................ 19
5.1.2. Mailbox Namespace Naming Convention ..................... 19
5.1.3. Mailbox International Naming Convention ................. 19
5.2. Mailbox Size and Message Status Updates ................. 21
5.3. Response when no Command in Progress .................... 21
5.4. Autologout Timer ........................................ 22
5.5. Multiple Commands in Progress ........................... 22
6. Client Commands ........................................ 23
6.1. Client Commands - Any State ............................ 24
6.1.1. CAPABILITY Command ..................................... 24
6.1.2. NOOP Command ........................................... 25
6.1.3. LOGOUT Command ......................................... 26
IMAP4rev1 Protocol Specification ................................ 4
1. How to Read This Document ............................... 4
1.1. Organization of This Document ........................... 4
1.2. Conventions Used in This Document ....................... 4
1.3. Special Notes to Implementors ........................... 5
2. Protocol Overview ....................................... 6
2.1. Link Level .............................................. 6
2.2. Commands and Responses .................................. 6
2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
2.3. Message Attributes ...................................... 8
2.3.1. Message Numbers ......................................... 8
2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
2.3.1.2. Message Sequence Number Message Attribute ....... 10
2.3.2. Flags Message Attribute ................................. 11
2.3.3. Internal Date Message Attribute ......................... 12
2.3.4. [RFC-2822] Size Message Attribute ....................... 12
2.3.5. Envelope Structure Message Attribute .................... 12
2.3.6. Body Structure Message Attribute ........................ 12
2.4. Message Texts ........................................... 13
3. State and Flow Diagram .................................. 13
3.1. Not Authenticated State ................................. 13
3.2. Authenticated State ..................................... 13
3.3. Selected State .......................................... 13
3.4. Logout State ............................................ 14
4. Data Formats ............................................ 16
4.1. Atom .................................................... 16
4.2. Number .................................................. 16
4.3. String .................................................. 16
4.3.1. 8-bit and Binary Strings ................................ 17
4.4. Parenthesized List ...................................... 17
4.5. NIL ..................................................... 17
5. Operational Considerations .............................. 18
5.1. Mailbox Naming .......................................... 18
5.1.1. Mailbox Hierarchy Naming ................................ 19
5.1.2. Mailbox Namespace Naming Convention ..................... 19
5.1.3. Mailbox International Naming Convention ................. 19
5.2. Mailbox Size and Message Status Updates ................. 21
5.3. Response when no Command in Progress .................... 21
5.4. Autologout Timer ........................................ 22
5.5. Multiple Commands in Progress ........................... 22
6. Client Commands ........................................ 23
6.1. Client Commands - Any State ............................ 24
6.1.1. CAPABILITY Command ..................................... 24
6.1.2. NOOP Command ........................................... 25
6.1.3. LOGOUT Command ......................................... 26
6.2. Client Commands - Not Authenticated State .............. 26
6.2.1. STARTTLS Command ....................................... 27
6.2.2. AUTHENTICATE Command ................................... 28
6.2.3. LOGIN Command .......................................... 30
6.3. Client Commands - Authenticated State .................. 31
6.3.1. SELECT Command ......................................... 32
6.3.2. EXAMINE Command ........................................ 34
6.3.3. CREATE Command ......................................... 34
6.3.4. DELETE Command ......................................... 35
6.3.5. RENAME Command ......................................... 37
6.3.6. SUBSCRIBE Command ...................................... 39
6.3.7. UNSUBSCRIBE Command .................................... 39
6.3.8. LIST Command ........................................... 40
6.3.9. LSUB Command ........................................... 43
6.3.10. STATUS Command ......................................... 44
6.3.11. APPEND Command ......................................... 46
6.4. Client Commands - Selected State ....................... 47
6.4.1. CHECK Command .......................................... 47
6.4.2. CLOSE Command .......................................... 48
6.4.3. EXPUNGE Command ........................................ 49
6.4.4. SEARCH Command ......................................... 49
6.4.5. FETCH Command .......................................... 54
6.4.6. STORE Command .......................................... 58
6.4.7. COPY Command ........................................... 59
6.4.8. UID Command ............................................ 60
6.5. Client Commands - Experimental/Expansion ............... 62
6.5.1. X<atom> Command ........................................ 62
7. Server Responses ....................................... 62
7.1. Server Responses - Status Responses .................... 63
7.1.1. OK Response ............................................ 65
7.1.2. NO Response ............................................ 66
7.1.3. BAD Response ........................................... 66
7.1.4. PREAUTH Response ....................................... 67
7.1.5. BYE Response ........................................... 67
7.2. Server Responses - Server and Mailbox Status ........... 68
7.2.1. CAPABILITY Response .................................... 68
7.2.2. LIST Response .......................................... 69
7.2.3. LSUB Response .......................................... 70
7.2.4 STATUS Response ........................................ 70
7.2.5. SEARCH Response ........................................ 71
7.2.6. FLAGS Response ......................................... 71
7.3. Server Responses - Mailbox Size ........................ 71
7.3.1. EXISTS Response ........................................ 71
7.3.2. RECENT Response ........................................ 72
7.4. Server Responses - Message Status ...................... 72
7.4.1. EXPUNGE Response ....................................... 72
7.4.2. FETCH Response ......................................... 73
7.5. Server Responses - Command Continuation Request ........ 79
6.2. Client Commands - Not Authenticated State .............. 26
6.2.1. STARTTLS Command ....................................... 27
6.2.2. AUTHENTICATE Command ................................... 28
6.2.3. LOGIN Command .......................................... 30
6.3. Client Commands - Authenticated State .................. 31
6.3.1. SELECT Command ......................................... 32
6.3.2. EXAMINE Command ........................................ 34
6.3.3. CREATE Command ......................................... 34
6.3.4. DELETE Command ......................................... 35
6.3.5. RENAME Command ......................................... 37
6.3.6. SUBSCRIBE Command ...................................... 39
6.3.7. UNSUBSCRIBE Command .................................... 39
6.3.8. LIST Command ........................................... 40
6.3.9. LSUB Command ........................................... 43
6.3.10. STATUS Command ......................................... 44
6.3.11. APPEND Command ......................................... 46
6.4. Client Commands - Selected State ....................... 47
6.4.1. CHECK Command .......................................... 47
6.4.2. CLOSE Command .......................................... 48
6.4.3. EXPUNGE Command ........................................ 49
6.4.4. SEARCH Command ......................................... 49
6.4.5. FETCH Command .......................................... 54
6.4.6. STORE Command .......................................... 58
6.4.7. COPY Command ........................................... 59
6.4.8. UID Command ............................................ 60
6.5. Client Commands - Experimental/Expansion ............... 62
6.5.1. X<atom> Command ........................................ 62
7. Server Responses ....................................... 62
7.1. Server Responses - Status Responses .................... 63
7.1.1. OK Response ............................................ 65
7.1.2. NO Response ............................................ 66
7.1.3. BAD Response ........................................... 66
7.1.4. PREAUTH Response ....................................... 67
7.1.5. BYE Response ........................................... 67
7.2. Server Responses - Server and Mailbox Status ........... 68
7.2.1. CAPABILITY Response .................................... 68
7.2.2. LIST Response .......................................... 69
7.2.3. LSUB Response .......................................... 70
7.2.4 STATUS Response ........................................ 70
7.2.5. SEARCH Response ........................................ 71
7.2.6. FLAGS Response ......................................... 71
7.3. Server Responses - Mailbox Size ........................ 71
7.3.1. EXISTS Response ........................................ 71
7.3.2. RECENT Response ........................................ 72
7.4. Server Responses - Message Status ...................... 72
7.4.1. EXPUNGE Response ....................................... 72
7.4.2. FETCH Response ......................................... 73
7.5. Server Responses - Command Continuation Request ........ 79
8. Sample IMAP4rev1 connection ............................ 80
9. Formal Syntax .......................................... 81
10. Author's Note .......................................... 92
11. Security Considerations ................................ 92
11.1. STARTTLS Security Considerations ....................... 92
11.2. Other Security Considerations .......................... 93
12. IANA Considerations .................................... 94
Appendices ..................................................... 95
A. References ............................................. 95
B. Changes from RFC 2060 .................................. 97
C. Key Word Index ......................................... 103
Author's Address ............................................... 107
Full Copyright Statement ....................................... 108
8. Sample IMAP4rev1 connection ............................ 80
9. Formal Syntax .......................................... 81
10. Author's Note .......................................... 92
11. Security Considerations ................................ 92
11.1. STARTTLS Security Considerations ....................... 92
11.2. Other Security Considerations .......................... 93
12. IANA Considerations .................................... 94
Appendices ..................................................... 95
A. References ............................................. 95
B. Changes from RFC 2060 .................................. 97
C. Key Word Index ......................................... 103
Author's Address ............................................... 107
Full Copyright Statement ....................................... 108
IMAP4rev1 Protocol Specification
IMAP4rev1协议规范
This document is written from the point of view of the implementor of an IMAP4rev1 client or server. Beyond the protocol overview in section 2, it is not optimized for someone trying to understand the operation of the protocol. The material in sections 3 through 5 provides the general context and definitions with which IMAP4rev1 operates.
本文档是从IMAP4rev1客户机或服务器的实现者的角度编写的。除了第2节中的协议概述之外，对于试图理解协议操作的人来说，它不是优化的。第3节至第5节中的内容提供了IMAP4rev1操作的一般上下文和定义。
Sections 6, 7, and 9 describe the IMAP commands, responses, and syntax, respectively. The relationships among these are such that it is almost impossible to understand any of them separately. In particular, do not attempt to deduce command syntax from the command section alone; instead refer to the Formal Syntax section.
第6、7和9节分别描述了IMAP命令、响应和语法。它们之间的关系是这样的，以至于几乎不可能单独理解它们中的任何一个。特别是，不要试图仅从命令部分推断命令语法；请参阅正式语法部分。
"Conventions" are basic principles or procedures. Document conventions are noted in this section.
“公约”是基本原则或程序。本节说明了文件惯例。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“可”和“可选”应按照[关键词]中的说明进行解释。
The word "can" (not "may") is used to refer to a possible circumstance or situation, as opposed to an optional facility of the protocol.
“可以”（不是“可以”）一词是指可能的情况或情况，而不是《议定书》的任择设施。
"User" is used to refer to a human user, whereas "client" refers to the software being run by the user.
“用户”是指人工用户，而“客户端”是指用户正在运行的软件。
"Connection" refers to the entire sequence of client/server interaction from the initial establishment of the network connection until its termination.
“连接”是指从网络连接初始建立到终止的整个客户机/服务器交互顺序。
"Session" refers to the sequence of client/server interaction from the time that a mailbox is selected (SELECT or EXAMINE command) until the time that selection ends (SELECT or EXAMINE of another mailbox, CLOSE command, or connection termination).
“会话”是指从选择邮箱（选择或检查命令）到选择结束（选择或检查另一邮箱、关闭命令或连接终止）的客户端/服务器交互顺序。
Characters are 7-bit US-ASCII unless otherwise specified. Other character sets are indicated using a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. CHARSETs have important additional semantics in addition to defining character set; refer to these documents for more detail.
除非另有规定，否则字符为7位US-ASCII。其他字符集使用“字符集”表示，如[MIME-IMT]中所述，并在[CHARSET]中定义。除了定义字符集外，字符集还有重要的附加语义；有关更多详细信息，请参阅这些文档。
There are several protocol conventions in IMAP. These refer to aspects of the specification which are not strictly part of the IMAP protocol, but reflect generally-accepted practice. Implementations need to be aware of these conventions, and avoid conflicts whether or not they implement the convention. For example, "&" may not be used as a hierarchy delimiter since it conflicts with the Mailbox International Naming Convention, and other uses of "&" in mailbox names are impacted as well.
IMAP中有几个协议约定。这些是指规范的某些方面，这些方面并非严格属于IMAP协议的一部分，但反映了普遍接受的实践。实现需要了解这些约定，并避免冲突，无论它们是否实现了约定。例如，“&”不能用作层次定界符，因为它与邮箱国际命名约定冲突，邮箱名称中“&”的其他用法也会受到影响。
Implementors of the IMAP protocol are strongly encouraged to read the IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in conjunction with this document, to help understand the intricacies of this protocol and how best to build an interoperable product.
强烈鼓励IMAP协议的实施者结合本文件阅读IMAP实施建议文件[IMAP-implementation]，以帮助理解本协议的复杂性以及如何最好地构建可互操作的产品。
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with the IMAP4 protocol described in RFC 1730; the exception being in certain facilities added in RFC 1730 that proved problematic and were subsequently removed. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocols have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
IMAP4rev1设计为与[IMAP2]和未发布的IMAP2bis协议向上兼容。IMAP4rev1在很大程度上与RFC 1730中描述的IMAP4协议兼容；RFC 1730中添加的某些设施的例外情况证明存在问题，随后被删除。在IMAP4rev1的发展过程中，早期协议中的某些方面已经过时。[IMAP-OPERATE]中描述了IMAP4rev1实现与早期实现一起使用时可能遇到的过时命令、响应和数据格式。
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct)
[IMAP-COMPAT]中讨论了与早期协议最常见变体IMAP2bis的其他兼容性问题。全面讨论与稀有物种（和假定灭绝物种）的兼容性问题
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.
[IMAP2]的变体在[IMAP-HISTORICAL]中；这份文件主要具有历史意义。
IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items in IMAP incorporate "RFC822" in their name. With the exception of RFC822.SIZE, there are more modern replacements; for example, the modern version of RFC822.HEADER is BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a reference to the updated [RFC-2822] standard.
IMAP最初是为较旧的[RFC-822]标准开发的，因此，IMAP中的几个获取项在其名称中包含了“RFC822”。除了RFC822.2以外，还有更多的现代替代品；例如，RFC822.HEADER的现代版本是BODY.PEEK[HEADER]。在所有情况下，“RFC822”应解释为对更新的[RFC-2822]标准的引用。
The IMAP4rev1 protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, an IMAP4rev1 server listens on port 143.
IMAP4rev1协议采用可靠的数据流，如TCP提供的数据流。使用TCP时，IMAP4rev1服务器侦听端口143。
An IMAP4rev1 connection consists of the establishment of a client/server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.
IMAP4rev1连接包括建立客户机/服务器网络连接、来自服务器的初始问候语以及客户机/服务器交互。这些客户机/服务器交互包括客户机命令、服务器数据和服务器完成结果响应。
All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of an IMAP4rev1 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.
客户端和服务器传输的所有交互都是以行的形式，即以CRLF结尾的字符串。IMAP4rev1客户端或服务器的协议接收器正在读取一行，或者正在读取一个八位字节序列，该序列的已知计数后跟一行。
The client command begins an operation. Each client command is prefixed with an identifier (typically a short alphanumeric string, e.g., A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command.
client命令开始一个操作。每个客户端命令都以一个称为“标记”的标识符（通常是一个短字母数字字符串，例如A0001、A0002等）作为前缀。客户端为每个命令生成不同的标记。
Clients MUST follow the syntax outlined in this specification strictly. It is a syntax error to send a command with missing or extraneous spaces or arguments.
客户机必须严格遵循本规范中概述的语法。发送包含丢失或无关空格或参数的命令是一种语法错误。
There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In either case, the
有两种情况下，客户端的一行并不代表完整的命令。在一种情况下，命令参数被引用为八位字节计数（请参见数据格式下字符串中的文字说明）；在另一种情况下，命令参数需要服务器反馈（请参阅AUTHENTICATE命令）。在这两种情况下
server sends a command continuation request response if it is ready for the octets (if appropriate) and the remainder of the command. This response is prefixed with the token "+".
如果服务器已准备好接收八位字节（如果合适）和命令的其余部分，则会发送命令继续请求响应。此响应以标记“+”作为前缀。
Note: If instead, the server detected an error in the command, it sends a BAD completion response with a tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command.
注意：如果相反，服务器检测到命令中有错误，它会发送一个错误的完成响应，该响应带有与命令匹配的标记（如下所述），以拒绝该命令并阻止客户端发送更多的命令。
It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data. In either case, the command continuation request is still pending; the client takes the appropriate action for the response, and reads another response from the server. In all cases, the client MUST send a complete command (including receiving all command continuation request responses and command continuations for the command) before initiating a new command.
服务器也可以发送其他命令（如果多个命令正在执行）或未标记数据的完成响应。在这两种情况下，命令继续请求仍处于挂起状态；客户端对响应采取适当的操作，并从服务器读取另一个响应。在所有情况下，客户机必须在启动新命令之前发送完整的命令（包括接收命令的所有命令继续请求响应和命令继续）。
The protocol receiver of an IMAP4rev1 server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result response.
IMAP4rev1服务器的协议接收器从客户端读取命令行，解析命令及其参数，并传输服务器数据和服务器命令完成结果响应。
Data transmitted by the server to the client and status responses that do not indicate command completion are prefixed with the token "*", and are called untagged responses.
服务器向客户端传输的数据和不指示命令完成的状态响应以标记“*”作为前缀，称为未标记响应。
Server data MAY be sent as a result of a client command, or MAY be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally.
服务器数据可以作为客户端命令的结果发送，也可以由服务器单方面发送。由特定命令生成的服务器数据和单方面发送的服务器数据之间没有语法上的差异。
The server completion result response indicates the success or failure of the operation. It is tagged with the same tag as the client command which began the operation. Thus, if more than one command is in progress, the tag in a server completion response identifies the command to which the response applies. There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating a protocol error such as unrecognized command or command syntax error).
服务器完成结果响应指示操作的成功或失败。它使用与开始操作的客户端命令相同的标记进行标记。因此，如果正在执行多个命令，则服务器完成响应中的标记将标识响应所应用的命令。有三种可能的服务器完成响应：OK（表示成功）、NO（表示失败）或BAD（表示协议错误，例如无法识别的命令或命令语法错误）。
Servers SHOULD enforce the syntax outlined in this specification strictly. Any client command with a protocol syntax error, including (but not limited to) missing or extraneous spaces or arguments,
服务器应严格执行本规范中概述的语法。出现协议语法错误的任何客户端命令，包括（但不限于）缺少或无关的空格或参数，
SHOULD be rejected, and the client given a BAD server completion response.
应该被拒绝，并且客户端给出了错误的服务器完成响应。
The protocol receiver of an IMAP4rev1 client reads a response line from the server. It then takes action on the response based upon the first token of the response, which can be a tag, a "*", or a "+".
IMAP4rev1客户端的协议接收器从服务器读取响应行。然后，它根据响应的第一个标记对响应执行操作，该标记可以是标记、“*”或“+”。
A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded.
客户机必须随时准备接受任何服务器响应。这包括未请求的服务器数据。应该记录服务器数据，以便客户端可以引用其记录的副本，而不是向服务器发送请求数据的命令。对于某些服务器数据，必须记录这些数据。
This topic is discussed in greater detail in the Server Responses section.
服务器响应部分将更详细地讨论此主题。
In addition to message text, each message has several attributes associated with it. These attributes can be retrieved individually or in conjunction with other attributes or message texts.
除了消息文本之外，每条消息都有几个与其相关联的属性。这些属性可以单独检索，也可以与其他属性或消息文本一起检索。
Messages in IMAP4rev1 are accessed by one of two numbers; the unique identifier or the message sequence number.
IMAP4rev1中的消息由两个数字之一访问；唯一标识符或消息序列号。
A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. Unlike message sequence numbers, unique identifiers are not necessarily contiguous.
分配给每条邮件的32位值，当与唯一标识符有效性值（见下文）一起使用时，形成一个64位值，不能永远引用邮箱中的任何其他邮件或具有相同名称的任何后续邮箱。邮箱中以严格升序方式分配唯一标识符；在将每条邮件添加到邮箱时，会为其分配一个高于先前添加的邮件的UID。与消息序列号不同，唯一标识符不一定是连续的。
The unique identifier of a message MUST NOT change during the session, and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients); this is discussed further in [IMAP-DISC].
消息的唯一标识符不得在会话期间更改，也不得在会话之间更改。会话之间唯一标识符的任何更改都必须使用下面讨论的UIDVality机制进行检测。客户端需要持久的唯一标识符，以便从与服务器的上一个会话（例如，断开连接的或脱机访问的客户端）重新同步其状态；这将在[IMAP-DISC]中进一步讨论。
Associated with every mailbox are two values which aid in unique identifier handling: the next unique identifier value and the unique identifier validity value.
与每个邮箱关联的两个值有助于处理唯一标识符：下一个唯一标识符值和唯一标识符有效性值。
The next unique identifier value is the predicted value that will be assigned to a new message in the mailbox. Unless the unique identifier validity also changes (see below), the next unique identifier value MUST have the following two characteristics. First, the next unique identifier value MUST NOT change unless new messages are added to the mailbox; and second, the next unique identifier value MUST change whenever new messages are added to the mailbox, even if those new messages are subsequently expunged.
下一个唯一标识符值是将分配给邮箱中新邮件的预测值。除非唯一标识符有效性也发生变化（见下文），否则下一个唯一标识符值必须具有以下两个特征。首先，除非向邮箱添加新邮件，否则下一个唯一标识符值不得更改；其次，每当向邮箱添加新邮件时，下一个唯一标识符值必须更改，即使这些新邮件随后被删除。
Note: The next unique identifier value is intended to provide a means for a client to determine whether any messages have been delivered to the mailbox since the previous time it checked this value. It is not intended to provide any guarantee that any message will have this unique identifier. A client can only assume, at the time that it obtains the next unique identifier value, that messages arriving after that time will have a UID greater than or equal to that value.
注意：下一个唯一标识符值旨在为客户端提供一种方法，以确定自上次检查此值以来是否有任何邮件已发送到邮箱。它不打算提供任何保证，任何消息将具有此唯一标识符。客户机在获得下一个唯一标识符值时，只能假设在该时间之后到达的消息的UID将大于或等于该值。
The unique identifier validity value is sent in a UIDVALIDITY response code in an OK untagged response at mailbox selection time. If unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session.
唯一标识符有效性值在邮箱选择时以OK Untaged响应的UIDVALIDITY响应代码发送。如果先前会话中的唯一标识符无法在此会话中持久化，则唯一标识符有效性值必须大于先前会话中使用的值。
Note: Ideally, unique identifiers SHOULD persist at all times. Although this specification recognizes that failure to persist can be unavoidable in certain server environments, it STRONGLY ENCOURAGES message store implementation techniques that avoid this problem. For example:
注意：理想情况下，唯一标识符应始终保持不变。尽管本规范认识到在某些服务器环境中无法持久化是不可避免的，但它强烈鼓励使用消息存储实现技术来避免此问题。例如：
1) Unique identifiers MUST be strictly ascending in the mailbox at all times. If the physical message store is re-ordered by a non-IMAP agent, this requires that the unique identifiers in the mailbox be regenerated, since the former unique identifiers are no longer strictly ascending as a result of the re-ordering.
1) 邮箱中的唯一标识符必须始终严格递增。如果物理邮件存储由非IMAP代理重新排序，则需要重新生成邮箱中的唯一标识符，因为重新排序后，以前的唯一标识符不再严格升序。
2) If the message store has no mechanism to store unique identifiers, it must regenerate unique identifiers at each session, and each session must have a unique UIDVALIDITY value.
2) 如果消息存储没有存储唯一标识符的机制，则它必须在每个会话中重新生成唯一标识符，并且每个会话必须具有唯一的UIDVality值。
3) If the mailbox is deleted and a new mailbox with the same name is created at a later date, the server must either keep track of unique identifiers from the previous instance of the mailbox, or it must assign a new UIDVALIDITY value to the new instance of the mailbox. A good UIDVALIDITY value to use in this case is a 32-bit representation of the creation date/time of the mailbox. It is alright to use a constant such as 1, but only if it guaranteed that unique identifiers will never be reused, even in the case of a mailbox being deleted (or renamed) and a new mailbox by the same name created at some future time.
3) 如果删除邮箱并在以后创建具有相同名称的新邮箱，则服务器必须跟踪邮箱以前实例中的唯一标识符，或者必须为邮箱的新实例分配新的UIDVality值。在本例中使用的一个良好的UIDVality值是邮箱创建日期/时间的32位表示形式。使用常量（如1）是可以的，但前提是它保证了唯一标识符永远不会被重用，即使在删除（或重命名）邮箱以及在将来某个时间创建同名新邮箱的情况下也是如此。
4) The combination of mailbox name, UIDVALIDITY, and UID must refer to a single immutable message on that server forever. In particular, the internal date, [RFC-2822] size, envelope, body structure, and message texts (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...] fetch data items) must never change. This does not include message numbers, nor does it include attributes that can be set by a STORE command (e.g., FLAGS).
4) 邮箱名称、UIDVality和UID的组合必须永远引用该服务器上的单个不可变邮件。特别是，内部日期、[RFC-2822]大小、信封、正文结构和消息文本（RFC822、RFC822.HEADER、RFC822.TEXT和所有正文[…]获取数据项）不得更改。这不包括消息编号，也不包括可由STORE命令设置的属性（例如，标志）。
A relative position from 1 to the number of messages in the mailbox. This position MUST be ordered by ascending unique identifier. As each new message is added, it is assigned a message sequence number that is 1 higher than the number of messages in the mailbox before that new message was added.
从1到邮箱中邮件数的相对位置。此位置必须按升序唯一标识符排序。添加每封新邮件时，会为其分配一个邮件序列号，该序列号比添加新邮件之前邮箱中的邮件数高1。
Message sequence numbers can be reassigned during the session. For example, when a message is permanently removed (expunged) from the mailbox, the message sequence number for all subsequent messages is decremented. The number of messages in the mailbox is also decremented. Similarly, a new message can be assigned a message sequence number that was once held by some other message prior to an expunge.
可以在会话期间重新分配消息序列号。例如，当邮件从邮箱中永久删除（删除）时，所有后续邮件的邮件序列号都将递减。邮箱中的邮件数也会减少。类似地，可以为新消息分配一个消息序列号，该序列号在删除之前曾由其他消息持有。
In addition to accessing messages by relative position in the mailbox, message sequence numbers can be used in mathematical calculations. For example, if an untagged "11 EXISTS" is received, and previously an untagged "8 EXISTS" was received, three new messages have arrived with message sequence numbers of 9, 10, and 11. Another example, if message 287 in a 523 message mailbox has UID 12345, there are exactly 286 messages which have lesser UIDs and 236 messages which have greater UIDs.
除了通过邮箱中的相对位置访问邮件外，邮件序列号还可以用于数学计算。例如，如果接收到未标记的“11 EXISTS”，并且之前接收到未标记的“8 EXISTS”，则三条新消息已到达，消息序列号为9、10和11。另一个示例是，如果523邮件邮箱中的邮件287的UID为12345，则正好有286封邮件的UID较小，236封邮件的UID较大。
A list of zero or more named tokens associated with the message. A flag is set by its addition to this list, and is cleared by its removal. There are two types of flags in IMAP4rev1. A flag of either type can be permanent or session-only.
与消息关联的零个或多个命名令牌的列表。标志通过添加到此列表中来设置，并通过删除来清除。IMAP4rev1中有两种类型的标志。任何一种类型的标志都可以是永久性的，也可以是仅限会话的。
A system flag is a flag name that is pre-defined in this specification. All system flags begin with "\". Certain system flags (\Deleted and \Seen) have special semantics described elsewhere. The currently-defined system flags are:
系统标志是本规范中预定义的标志名称。所有系统标志都以“\”开头。某些系统标志（\Deleted and\Seen）具有其他地方描述的特殊语义。当前定义的系统标志为：
\Seen Message has been read
\所看到的消息已被读取
\Answered Message has been answered
\已回复的消息已被回复
\Flagged Message is "flagged" for urgent/special attention
\标记的消息被“标记”，以引起紧急/特别注意
\Deleted Message is "deleted" for removal by later EXPUNGE
\已删除的邮件将被“删除”，以便稍后删除
\Draft Message has not completed composition (marked as a draft).
\草稿邮件尚未完成合成（标记为草稿）。
\Recent Message is "recently" arrived in this mailbox. This session is the first session to have been notified about this message; if the session is read-write, subsequent sessions will not see \Recent set for this message. This flag can not be altered by the client.
\最近的邮件“最近”到达此邮箱。此会话是第一个收到此消息通知的会话；如果会话为读写会话，则后续会话将不会看到此消息的\Recent set。客户端无法更改此标志。
If it is not possible to determine whether or not this session is the first session to be notified about a message, then that message SHOULD be considered recent.
如果无法确定此会话是否是第一个收到消息通知的会话，则该消息应视为最近的消息。
If multiple connections have the same mailbox selected simultaneously, it is undefined which of these connections will see newly-arrived messages with \Recent set and which will see it without \Recent set.
如果多个连接同时选择了同一邮箱，则未定义这些连接中的哪些将看到具有\Recent set的新到达邮件，哪些将看到不具有\Recent set的新到达邮件。
A keyword is defined by the server implementation. Keywords do not begin with "\". Servers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information).
关键字由服务器实现定义。关键字不以“\”开头。服务器可能允许客户端在邮箱中定义新关键字（有关更多信息，请参阅PERMANENTFLAGS响应代码的说明）。
A flag can be permanent or session-only on a per-flag basis. Permanent flags are those which the client can add or remove from the message flags permanently; that is, concurrent and subsequent sessions will see any change in permanent flags. Changes to session flags are valid only in that session.
标志可以是永久性的，也可以是仅基于每个标志的会话。永久性标志是客户端可以从消息标志中永久添加或删除的标志；也就是说，并发会话和后续会话将看到永久标志的任何更改。对会话标志的更改仅在该会话中有效。
Note: The \Recent system flag is a special case of a session flag. \Recent can not be used as an argument in a STORE or APPEND command, and thus can not be changed at all.
注意：\最近的系统标志是会话标志的特例\“最近”不能用作存储或追加命令中的参数，因此根本不能更改。
The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined.
服务器上邮件的内部日期和时间。这不是[RFC-2822]标题中的日期和时间，而是反映消息接收时间的日期和时间。对于通过[SMTP]传递的邮件，这应该是[SMTP]定义的邮件最终传递的日期和时间。对于由IMAP4rev1 COPY命令传递的消息，这应该是源消息的内部日期和时间。对于由IMAP4rev1 APPEND命令传递的消息，这应该是APPEND命令说明中指定的日期和时间。所有其他情况都是实现定义的。
The number of octets in the message, as expressed in [RFC-2822] format.
消息中的八位字节数，以[RFC-2822]格式表示。
A parsed representation of the [RFC-2822] header of the message. Note that the IMAP Envelope structure is not the same as an [SMTP] envelope.
消息的[RFC-2822]头的解析表示形式。请注意，IMAP信封结构与[SMTP]信封不同。
A parsed representation of the [MIME-IMB] body structure information of the message.
消息的[MIME-IMB]正文结构信息的解析表示。
In addition to being able to fetch the full [RFC-2822] text of a message, IMAP4rev1 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] body part, or a [MIME-IMB] header.
除了能够获取消息的完整[RFC-2822]文本外，IMAP4rev1还允许获取部分完整消息文本。具体而言，可以获取[RFC-2822]消息头、[RFC-2822]消息正文、[MIME-IMB]正文部分或[MIME-IMB]标头。
Once the connection between client and server is established, an IMAP4rev1 connection is in one of four states. The initial state is identified in the server greeting. Most commands are only valid in certain states. It is a protocol error for the client to attempt a command while the connection is in an inappropriate state, and the server will respond with a BAD or NO (depending upon server implementation) command completion result.
一旦建立了客户端和服务器之间的连接，IMAP4rev1连接将处于四种状态之一。初始状态在服务器问候语中标识。大多数命令仅在某些状态下有效。当连接处于不适当的状态时，客户端尝试执行命令是一种协议错误，服务器将以错误或否（取决于服务器实现）命令完成结果进行响应。
In the not authenticated state, the client MUST supply authentication credentials before most commands will be permitted. This state is entered when a connection starts unless the connection has been pre-authenticated.
在未验证状态下，客户端必须提供验证凭据才能允许大多数命令。此状态在连接启动时输入，除非该连接已预验证。
In the authenticated state, the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted. This state is entered when a pre-authenticated connection starts, when acceptable authentication credentials have been provided, after an error in selecting a mailbox, or after a successful CLOSE command.
在“已验证”状态下，客户端已验证，必须先选择要访问的邮箱，然后才能允许使用影响邮件的命令。当预身份验证连接启动、提供了可接受的身份验证凭据、在选择邮箱时出错或在成功执行关闭命令后，将进入此状态。
In a selected state, a mailbox has been selected to access. This state is entered when a mailbox has been successfully selected.
在选定状态下，已选择要访问的邮箱。成功选择邮箱后，将进入此状态。
In the logout state, the connection is being terminated. This state can be entered as a result of a client request (via the LOGOUT command) or by unilateral action on the part of either the client or server.
在注销状态下，连接正在终止。此状态可以作为客户端请求（通过注销命令）的结果输入，也可以通过客户端或服务器的单方面操作输入。
If the client requests the logout state, the server MUST send an untagged BYE response and a tagged OK response to the LOGOUT command before the server closes the connection; and the client MUST read the tagged OK response to the LOGOUT command before the client closes the connection.
如果客户端请求注销状态，服务器必须在关闭连接之前向注销命令发送未标记的BYE响应和标记的OK响应；在客户端关闭连接之前，客户端必须读取对注销命令的带标记的OK响应。
A server MUST NOT unilaterally close the connection without sending an untagged BYE response that contains the reason for having done so. A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. If the server detects that the client has unilaterally closed the connection, the server MAY omit the untagged BYE response and simply close its connection.
服务器不能在不发送包含关闭原因的未标记BYE响应的情况下单方面关闭连接。客户端不应单方面关闭连接，而应发出注销命令。如果服务器检测到客户端单方面关闭了连接，服务器可能会忽略未标记的BYE响应，而只是关闭其连接。
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
(1) connection without pre-authentication (OK greeting) (2) pre-authenticated connection (PREAUTH greeting) (3) rejected connection (BYE greeting) (4) successful LOGIN or AUTHENTICATE command (5) successful SELECT or EXAMINE command (6) CLOSE command, or failed SELECT or EXAMINE command (7) LOGOUT command, server shutdown, or connection closed
(1) 没有预验证的连接（OK问候语）（2）预验证的连接（PREAUTH问候语）（3）拒绝的连接（BYE问候语）（4）成功登录或验证命令（5）成功选择或检查命令（6）关闭命令，或失败选择或检查命令（7）注销命令、服务器关闭或连接关闭
IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can be in one of several forms: atom, number, string, parenthesized list, or NIL. Note that a particular data item may take more than one form; for example, a data item defined as using "astring" syntax may be either an atom or a string.
IMAP4rev1使用文本命令和响应。IMAP4rev1中的数据可以是以下几种形式之一：原子、数字、字符串、括号列表或NIL。请注意，特定数据项可以采用多种形式；例如，定义为使用“astring”语法的数据项可以是原子或字符串。
An atom consists of one or more non-special characters.
原子由一个或多个非特殊字符组成。
A number consists of one or more digit characters, and represents a numeric value.
数字由一个或多个数字字符组成，表示一个数值。
A string is in one of two forms: either literal or quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used.
字符串有两种形式：文本或带引号的字符串。文字形式是字符串的一般形式。带引号的字符串形式是一种替代方法，它避免了以可能使用的字符限制为代价处理文本的开销。
A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command).
文字是由零个或多个八位字节（包括CR和LF）组成的序列，前缀以开括号（“{”）、八位字节数、闭括号（“}”）和CRLF的形式引用八位字节计数。对于从服务器传输到客户端的文本，CRLF后面紧跟着八位字节数据。对于从客户机传输到服务器的文本，客户机在发送八位字节数据（以及命令的其余部分）之前，必须等待接收命令继续请求（本文档后面将介绍）。
A quoted string is a sequence of zero or more 7-bit characters, excluding CR and LF, with double quote (<">) characters at each end.
带引号的字符串是由零个或多个7位字符组成的序列，不包括CR和LF，每端都有双引号（<“>）字符。
The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0).
空字符串表示为“”（双引号之间为零个字符的带引号字符串）或{0}后跟CRLF（八位字节计数为0的文本）。
Note: Even if the octet count is 0, a client transmitting a literal MUST wait to receive a command continuation request.
注意：即使八位字节计数为0，发送文本的客户端也必须等待接收命令继续请求。
8-bit textual and binary mail is supported through the use of a [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY transmit 8-bit or multi-octet characters in literals, but SHOULD do so only when the [CHARSET] is identified.
通过使用[MIME-IMB]内容传输编码，支持8位文本和二进制邮件。IMAP4rev1实现可以以文字形式传输8位或多个八位字符，但只有在识别[CHARSET]时才应该这样做。
Although a BINARY body encoding is defined, unencoded binary strings are not permitted. A "binary string" is any string with NUL characters. Implementations MUST encode binary data into a textual form, such as BASE64, before transmitting the data. A string with an excessive amount of CTL characters MAY also be considered to be binary.
虽然定义了二进制体编码，但不允许使用未编码的二进制字符串。“二进制字符串”是任何带有NUL字符的字符串。在传输数据之前，实现必须将二进制数据编码为文本形式，如BASE64。包含过多CTL字符的字符串也可能被视为二进制。
Data structures are represented as a "parenthesized list"; a sequence of data items, delimited by space, and bounded at each end by parentheses. A parenthesized list can contain other parenthesized lists, using multiple levels of parentheses to indicate nesting.
数据结构表示为“括号列表”；一组数据项，用空格分隔，两端用括号限定。带括号的列表可以包含其他带括号的列表，使用多级括号表示嵌套。
The empty list is represented as () -- a parenthesized list with no members.
空列表表示为（）——一个括号中没有成员的列表。
The special form "NIL" represents the non-existence of a particular data item that is represented as a string or parenthesized list, as distinct from the empty string "" or the empty parenthesized list ().
特殊形式“NIL”表示不存在表示为字符串或括号列表的特定数据项，与空字符串“”或空括号列表（）不同。
Note: NIL is never used for any data item which takes the form of an atom. For example, a mailbox name of "NIL" is a mailbox named NIL as opposed to a non-existent mailbox name. This is because mailbox uses "astring" syntax which is an atom or a string. Conversely, an addr-name of NIL is a non-existent personal name, because addr-name uses "nstring" syntax which is NIL or a string, but never an atom.
注意：NIL从不用于任何采用原子形式的数据项。例如，邮箱名“NIL”是一个名为NIL的邮箱，而不是一个不存在的邮箱名。这是因为邮箱使用“astring”语法，即atom或字符串。相反，地址名NIL是不存在的个人名称，因为地址名使用的“nstring”语法是NIL或字符串，但不是原子。
The following rules are listed here to ensure that all IMAP4rev1 implementations interoperate properly.
这里列出了以下规则，以确保所有IMAP4rev1实现都能正确互操作。
Mailbox names are 7-bit. Client implementations MUST NOT attempt to create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox names returned by LIST or LSUB as UTF-8. Server implementations SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for more information on how to represent non-ASCII mailbox names.
邮箱名称为7位。客户端实现不得尝试创建8位邮箱名称，并应将LIST或LSUB返回的任何8位邮箱名称解释为UTF-8。服务器实现应禁止创建8位邮箱名称，并且不应在列表或LSUB中返回8位邮箱名称。有关如何表示非ASCII邮箱名称的更多信息，请参见第5.1.3节。
Note: 8-bit mailbox names were undefined in earlier versions of this protocol. Some sites used a local 8-bit character set to represent non-ASCII mailbox names. Such usage is not interoperable, and is now formally deprecated.
注意：此协议的早期版本中未定义8位邮箱名称。一些站点使用本地8位字符集来表示非ASCII邮箱名称。这种用法是不可互操作的，现在正式不推荐使用。
The case-insensitive mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". The interpretation of all other names is implementation-dependent.
不区分大小写的邮箱名称INBOX是保留的特殊名称，表示“此服务器上此用户的主邮箱”。所有其他名称的解释取决于实现。
In particular, this specification takes no position on case sensitivity in non-INBOX mailbox names. Some server implementations are fully case-sensitive; others preserve case of a newly-created name but otherwise are case-insensitive; and yet others coerce names to a particular case. Client implementations MUST interact with any of these. If a server implementation interprets non-INBOX mailbox names as case-insensitive, it MUST treat names using the international naming convention specially as described in section 5.1.3.
特别是，本规范对非收件箱邮箱名称的大小写敏感度没有任何规定。一些服务器实现完全区分大小写；其他名称保留新创建名称的大小写，但不区分大小写；还有一些人将名字强加于某一特定案例。客户机实现必须与其中任何一个交互。如果服务器实现将非收件箱邮箱名称解释为不区分大小写，则必须按照第5.1.3节中的说明，使用国际命名约定处理名称。
There are certain client considerations when creating a new mailbox name:
创建新邮箱名称时，存在某些客户端注意事项：
1) Any character which is one of the atom-specials (see the Formal Syntax) will require that the mailbox name be represented as a quoted string or literal.
1) 任何作为atom特殊字符之一的字符（请参阅正式语法）都需要将邮箱名称表示为带引号的字符串或文字。
2) CTL and other non-graphic characters are difficult to represent in a user interface and are best avoided.
2) CTL和其他非图形字符很难在用户界面中表示，最好避免。
3) Although the list-wildcard characters ("%" and "*") are valid in a mailbox name, it is difficult to use such mailbox names with the LIST and LSUB commands due to the conflict with wildcard interpretation.
3) 虽然列表通配符（“%”和“*”）在邮箱名称中有效，但由于与通配符解释冲突，很难将此类邮箱名称与列表和LSUB命令一起使用。
4) Usually, a character (determined by the server implementation) is reserved to delimit levels of hierarchy.
4) 通常，保留一个字符（由服务器实现决定）来划分层次结构的级别。
5) Two characters, "#" and "&", have meanings by convention, and should be avoided except when used in that convention.
5) 两个字符“#”和“&”具有约定的含义，除非在该约定中使用，否则应避免使用。
If it is desired to export hierarchical mailbox names, mailbox names MUST be left-to-right hierarchical using a single character to separate levels of hierarchy. The same hierarchy separator character is used for all levels of hierarchy within a single name.
如果需要导出分层邮箱名称，则邮箱名称必须是从左到右分层的，使用单个字符分隔层次结构的级别。同一个层次分隔符字符用于单个名称中的所有层次。
By convention, the first hierarchical element of any mailbox name which begins with "#" identifies the "namespace" of the remainder of the name. This makes it possible to disambiguate between different types of mailbox stores, each of which have their own namespaces.
按照约定，任何邮箱名称中以“#”开头的第一个层次元素标识名称其余部分的“名称空间”。这使得在不同类型的邮箱存储之间消除歧义成为可能，每个邮箱存储都有自己的名称空间。
For example, implementations which offer access to USENET newsgroups MAY use the "#news" namespace to partition the USENET newsgroup namespace from that of other mailboxes. Thus, the comp.mail.misc newsgroup would have a mailbox name of "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to a different object (e.g., a user's private mailbox).
例如，提供对USENET新闻组访问的实现可以使用“#news”名称空间将USENET新闻组名称空间与其他邮箱名称空间进行分区。因此，comp.mail.misc新闻组的邮箱名称为“#news.comp.mail.misc”，而名称“comp.mail.misc”可以指不同的对象（例如，用户的私人邮箱）。
By convention, international mailbox names in IMAP4rev1 are specified using a modified version of the UTF-7 encoding described in [UTF-7]. Modified UTF-7 may also be usable in servers that implement an earlier version of this protocol.
按照惯例，IMAP4rev1中的国际邮箱名称是使用[UTF-7]中描述的UTF-7编码的修改版本指定的。修改后的UTF-7也可用于实现此协议早期版本的服务器。
In modified UTF-7, printable US-ASCII characters, except for "&", represent themselves; that is, characters with octet values 0x20-0x25 and 0x27-0x7e. The character "&" (0x26) is represented by the two-octet sequence "&-".
在修改后的UTF-7中，除“&”之外的可打印US-ASCII字符表示它们自己；即，具有八位字节值0x20-0x25和0x27-0x7e的字符。字符“&”（0x26）由两个八位字节序列“&-”表示。
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself.
所有其他字符（八位字节值0x00-0x1f和0x7f-0xff）在修改后的BASE64中表示，并对[UTF-7]进行了进一步修改，即使用“，”代替“/”。修改后的BASE64不得用于表示任何可以表示其自身的打印US-ASCII字符。
"&" is used to shift to modified BASE64 and "-" to shift back to US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means "&") are not permitted. However, all names start in US-ASCII, and MUST end in US-ASCII; that is, a name that ends with a non-ASCII ISO-10646 character MUST end with a "-").
“&”用于移到修改后的BASE64，“-”用于移回US-ASCII。从BASE64到US-ASCII没有隐式移位，在BASE64中不允许空移位（“-&”；请注意，“&-”在US-ASCII中表示“&”）。但是，所有名称都以US-ASCII开头，并且必须以US-ASCII结尾；也就是说，以非ASCII ISO-10646字符结尾的名称必须以“-”结尾。
The purpose of these modifications is to correct the following problems with UTF-7:
这些修改的目的是纠正UTF-7的以下问题：
1) UTF-7 uses the "+" character for shifting; this conflicts with the common use of "+" in mailbox names, in particular USENET newsgroup names.
1) UTF-7使用“+”字符进行移位；这与邮箱名称中常用的“+”相冲突，尤其是USENET新闻组名称。
2) UTF-7's encoding is BASE64 which uses the "/" character; this conflicts with the use of "/" as a popular hierarchy delimiter.
2) UTF-7的编码为BASE64，使用“/”字符；这与使用“/”作为常用的层次分隔符相冲突。
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with the use of "\" as a popular hierarchy delimiter.
3) UTF-7禁止未编码使用“\”；这与使用“\”作为流行的层次结构分隔符相冲突。
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with the use of "~" in some servers as a home directory indicator.
4) UTF-7禁止未编码使用“~”；这与某些服务器中使用“~”作为主目录指示符相冲突。
5) UTF-7 permits multiple alternate forms to represent the same string; in particular, printable US-ASCII characters can be represented in encoded form.
5) UTF-7允许多个替代形式表示同一字符串；特别是，可打印的US-ASCII字符可以以编码形式表示。
Although modified UTF-7 is a convention, it establishes certain requirements on server handling of any mailbox name with an embedded "&" character. In particular, server implementations MUST preserve the exact form of the modified BASE64 portion of a modified UTF-7 name and treat that text as case-sensitive, even if names are otherwise case-insensitive or case-folded.
尽管修改后的UTF-7是一种约定，但它对服务器处理任何带有嵌入“&”字符的邮箱名称确定了某些要求。特别是，服务器实现必须保留修改后的UTF-7名称中修改后的BASE64部分的确切形式，并将该文本视为区分大小写，即使名称不区分大小写或折叠。
Server implementations SHOULD verify that any mailbox name with an embedded "&" character, used as an argument to CREATE, is: in the correctly modified UTF-7 syntax, has no superfluous shifts, and has no encoding in modified BASE64 of any printing US-ASCII character which can represent itself. However, client implementations MUST NOT depend upon the server doing this, and SHOULD NOT attempt to create a mailbox name with an embedded "&" character unless it complies with the modified UTF-7 syntax.
服务器实现应验证任何带有嵌入“&”字符的邮箱名称（用作创建参数）是否为：在正确修改的UTF-7语法中，没有多余的移位，并且在修改的BASE64中没有任何可以表示自身的打印US-ASCII字符的编码。但是，客户端实现不能依赖于服务器来执行此操作，并且不应尝试创建带有嵌入“&”字符的邮箱名称，除非它符合修改后的UTF-7语法。
Server implementations which export a mail store that does not follow the modified UTF-7 convention MUST convert to modified UTF-7 any mailbox name that contains either non-ASCII characters or the "&" character.
导出不遵循修改的UTF-7约定的邮件存储的服务器实现必须将包含非ASCII字符或“&”字符的任何邮箱名称转换为修改的UTF-7。
For example, here is a mailbox name which mixes English,
Chinese, and Japanese text:
~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, here is a mailbox name which mixes English,
Chinese, and Japanese text:
~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name because it does not contain a shift to US-ASCII before the "!". The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is not permitted because it contains a superfluous shift. The correct form is "&U,BTF2XlZyyKng-".
例如，字符串“&Jjo！”不是有效的邮箱名称，因为它在“！”之前不包含转换为US-ASCII的移位。正确的形式是“&Jjo-！”。不允许使用字符串“&U，BTFw-&ZeVnLIqe-”，因为它包含多余的移位。正确的形式是“&U，BTF2XLZYKNG-”。
At any time, a server can send data that the client did not request. Sometimes, such behavior is REQUIRED. For example, agents other than the server MAY add messages to the mailbox (e.g., new message delivery), change the flags of the messages in the mailbox (e.g., simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly.
在任何时候，服务器都可以发送客户端未请求的数据。有时，这种行为是必需的。例如，服务器以外的代理可以向邮箱添加邮件（例如，新邮件传递），更改邮箱中邮件的标志（例如，多个代理同时访问同一邮箱），甚至从邮箱中删除邮件。如果在处理命令期间观察到邮箱大小更改，服务器必须自动发送邮箱大小更新。服务器应自动发送消息标志更新，而无需客户端明确请求此类更新。
Special rules exist for server notification of a client about the removal of messages to prevent synchronization errors; see the description of the EXPUNGE response for more detail. In particular, it is NOT permitted to send an EXISTS response that would reduce the number of messages in the mailbox; only the EXPUNGE response can do this.
对于服务器通知客户端删除消息以防止同步错误，存在特殊规则；有关更多详细信息，请参阅删除响应的描述。特别是，不允许发送会减少邮箱中邮件数量的EXISTS响应；只有删除响应才能执行此操作。
Regardless of what implementation decisions a client makes on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after the initial mailbox selection will return the size of the mailbox.
无论客户机在从服务器记住数据时做出什么实现决策，客户机实现都必须记录邮箱大小的更新。它不能假设初始邮箱选择后的任何命令都将返回邮箱的大小。
Server implementations are permitted to send an untagged response (except for EXPUNGE) while there is no command in progress. Server implementations that send such responses MUST deal with flow control considerations. Specifically, they MUST either (1) verify that the size of the data does not exceed the underlying transport's available window size, or (2) use non-blocking writes.
允许服务器实现在没有命令执行的情况下发送未标记的响应（EXPUNGE除外）。发送此类响应的服务器实现必须处理流控制注意事项。具体地说，他们必须（1）验证数据大小不超过基础传输的可用窗口大小，或者（2）使用非阻塞写入。
If a server has an inactivity autologout timer, the duration of that timer MUST be at least 30 minutes. The receipt of ANY command from the client during that interval SHOULD suffice to reset the autologout timer.
如果服务器具有非活动自动启动计时器，则该计时器的持续时间必须至少为30分钟。在该间隔期间从客户端接收到任何命令都应足以重置自动定时器。
The client MAY send another command without waiting for the completion result response of a command, subject to ambiguity rules (see below) and flow control constraints on the underlying data stream. Similarly, a server MAY begin processing another command before processing the current command to completion, subject to ambiguity rules. However, any command continuation request responses and command continuations MUST be negotiated before any subsequent command is initiated.
客户端可以在不等待命令的完成结果响应的情况下发送另一个命令，这取决于模糊规则（见下文）和底层数据流上的流控制约束。类似地，服务器可能会在处理当前命令之前开始处理另一个命令，直到完成，这取决于模糊规则。但是，在启动任何后续命令之前，必须协商任何命令继续请求响应和命令继续。
The exception is if an ambiguity would result because of a command that would affect the results of other commands. Clients MUST NOT send multiple commands without waiting if an ambiguity would result. If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client.
例外情况是，如果由于某个命令会影响其他命令的结果而导致歧义。如果会产生歧义，客户端必须在不等待的情况下发送多个命令。如果服务器检测到可能的歧义，它必须按照客户机给出的顺序执行命令以完成。
The most obvious example of ambiguity is when a command would affect the results of another command, e.g., a FETCH of a message's flags and a STORE of that same message's flags.
最明显的模棱两可的例子是当一个命令会影响另一个命令的结果时，例如，获取消息的标志和存储同一消息的标志。
A non-obvious ambiguity occurs with commands that permit an untagged EXPUNGE response (commands other than FETCH, STORE, and SEARCH), since an untagged EXPUNGE response can invalidate sequence numbers in a subsequent command. This is not a problem for FETCH, STORE, or SEARCH commands because servers are prohibited from sending EXPUNGE responses while any of those commands are in progress. Therefore, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for the completion result response before sending a command with message sequence numbers.
由于未标记的删除响应会使后续命令中的序列号无效，因此允许未标记的删除响应（除FETCH、STORE和SEARCH以外的命令）的命令会出现不明显的歧义。对于FETCH、STORE或SEARCH命令来说，这不是问题，因为在执行这些命令时，禁止服务器发送删除响应。因此，如果客户机发送除FETCH、STORE或SEARCH之外的任何命令，它必须等待完成结果响应，然后再发送带有消息序列号的命令。
Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. If the client sends a UID command, it must wait for a completion result response before sending a command with message sequence numbers.
注意：UID FETCH、UID STORE和UID SEARCH是与FETCH、STORE和SEARCH不同的命令。如果客户端发送UID命令，则必须等待完成结果响应，然后再发送带有消息序列号的命令。
For example, the following non-waiting command sequences are invalid:
例如，以下非等待命令序列无效：
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
The following are examples of valid non-waiting command sequences:
以下是有效的非等待命令序列示例：
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting command sequence, depending upon whether or not the second UID SEARCH contains message sequence numbers.
UID搜索+UID搜索作为非等待命令序列可能有效或无效，具体取决于第二个UID搜索是否包含消息序列号。
IMAP4rev1 commands are described in this section. Commands are organized by the state in which the command is permitted. Commands which are permitted in multiple states are listed in the minimum permitted state (for example, commands valid in authenticated and selected state are listed in the authenticated state commands).
本节介绍IMAP4rev1命令。命令按允许命令的状态组织。在多个状态下允许的命令列在最小允许状态中（例如，在已验证和选定状态下有效的命令列在已验证状态命令中）。
Command arguments, identified by "Arguments:" in the command descriptions below, are described by function, not by syntax. The precise syntax of command arguments is described in the Formal Syntax section.
在下面的命令描述中，由“arguments:”标识的命令参数是按函数描述的，而不是按语法描述的。命令参数的精确语法在“形式语法”一节中介绍。
Some commands cause specific server responses to be returned; these are identified by "Responses:" in the command descriptions below. See the response descriptions in the Responses section for information on these responses, and the Formal Syntax section for the precise syntax of these responses. It is possible for server data to be transmitted as a result of any command. Thus, commands that do not specifically require server data specify "no specific responses for this command" instead of "none".
某些命令导致返回特定的服务器响应；在下面的命令描述中，这些由“响应：”标识。有关这些响应的信息，请参阅响应部分中的响应描述，有关这些响应的精确语法，请参阅正式语法部分。任何命令都可以传输服务器数据。因此，不特别需要服务器数据的命令指定“此命令无特定响应”而不是“无”。
The "Result:" in the command description refers to the possible tagged status responses to a command, and any special interpretation of these status responses.
命令描述中的“结果：”是指对命令可能的标记状态响应，以及对这些状态响应的任何特殊解释。
The state of a connection is only changed by successful commands which are documented as changing state. A rejected command (BAD response) never changes the state of the connection or of the selected mailbox. A failed command (NO response) generally does not change the state of the connection or of the selected mailbox; the exception being the SELECT and EXAMINE commands.
连接的状态仅由记录为“更改状态”的成功命令更改。被拒绝的命令（错误响应）不会更改连接或所选邮箱的状态。失败的命令（无响应）通常不会更改连接或所选邮箱的状态；“选择”和“检查”命令除外。
The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
以下命令在任何状态下都有效：CAPABILITY、NOOP和LOGOUT。
Arguments: none
论点：无
Responses: REQUIRED untagged response: CAPABILITY
响应：必需的未标记响应：能力
Result: OK - capability completed BAD - command unknown or arguments invalid
结果：正常-功能完成错误-命令未知或参数无效
The CAPABILITY command requests a listing of capabilities that the server supports. The server MUST send a single untagged CAPABILITY response with "IMAP4rev1" as one of the listed capabilities before the (tagged) OK response.
CAPABILITY命令请求服务器支持的功能列表。在（标记的）OK响应之前，服务器必须发送单个未标记的功能响应，并将“IMAP4rev1”作为列出的功能之一。
A capability name which begins with "AUTH=" indicates that the server supports that particular authentication mechanism. All such names are, by definition, part of this specification. For example, the authorization capability for an experimental "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
以“AUTH=”开头的功能名称表示服务器支持该特定身份验证机制。根据定义，所有此类名称均为本规范的一部分。例如，实验性“blurdybloop”验证器的授权功能将是“AUTH=XBLURDYBLOOP”，而不是“XAUTH=blurdybloop”或“XAUTH=XBLURDYBLOOP”。
Other capability names refer to extensions, revisions, or amendments to this specification. See the documentation of the CAPABILITY response for additional information. No capabilities, beyond the base IMAP4rev1 set defined in this specification, are enabled without explicit client action to invoke the capability.
其他功能名称指本规范的扩展、修订或修正。有关更多信息，请参阅能力响应的文档。如果没有显式的客户端操作来调用该功能，则不会启用本规范中定义的基本IMAP4rev1集之外的任何功能。
Client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. See the Security Considerations section for important information.
客户机和服务器实现必须实现STARTTLS、LOGINDISABLED和AUTH=PLAIN（在[IMAP-TLS]中描述）功能。有关重要信息，请参阅安全注意事项部分。
See the section entitled "Client Commands - Experimental/Expansion" for information about the form of site or implementation-specific capabilities.
有关站点或实现特定功能的形式的信息，请参阅标题为“客户端命令-实验/扩展”的部分。
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
Arguments: none
论点：无
Responses: no specific responses for this command (but see below)
响应：此命令没有特定响应（请参见下文）
Result: OK - noop completed BAD - command unknown or arguments invalid
结果：确定-noop已完成错误-命令未知或参数无效
The NOOP command always succeeds. It does nothing.
NOOP命令总是成功的。它什么也不做。
Since any command can return a status update as untagged data, the NOOP command can be used as a periodic poll for new messages or message status updates during a period of inactivity (this is the preferred method to do this). The NOOP command can also be used to reset any inactivity autologout timer on the server.
由于任何命令都可以将状态更新作为未标记的数据返回，因此NOOP命令可以在非活动期间用作新消息或消息状态更新的定期轮询（这是执行此操作的首选方法）。NOOP命令还可用于重置服务器上的任何非活动自动启动计时器。
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
Arguments: none
论点：无
Responses: REQUIRED untagged response: BYE
回复：必需的未标记回复：再见
Result: OK - logout completed BAD - command unknown or arguments invalid
结果：确定-注销完成错误-命令未知或参数无效
The LOGOUT command informs the server that the client is done with the connection. The server MUST send a BYE untagged response before the (tagged) OK response, and then close the network connection.
LOGOUT命令通知服务器客户端已完成连接。服务器必须在（标记的）OK响应之前发送BYE untagged响应，然后关闭网络连接。
Example: C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)
Example: C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)
In the not authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enters the authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, privacy protection, and integrity checking; whereas the LOGIN command uses a traditional user name and plaintext password pair and has no means of establishing privacy protection or integrity checking.
在未验证状态下，AUTHENTICATE或LOGIN命令建立验证并进入验证状态。AUTHENTICATE命令为各种身份验证技术、隐私保护和完整性检查提供了通用机制；而LOGIN命令使用传统用户名和明文密码对，无法建立隐私保护或完整性检查。
The STARTTLS command is an alternate form of establishing session privacy protection and integrity checking, but does not establish authentication or enter the authenticated state.
STARTTLS命令是建立会话隐私保护和完整性检查的另一种形式，但不建立身份验证或进入身份验证状态。
Server implementations MAY allow access to certain mailboxes without establishing authentication. This can be done by means of the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older convention is a LOGIN command using the userid "anonymous"; in this case, a password is required although the server may choose to accept any password. The restrictions placed on anonymous users are implementation-dependent.
服务器实现可能允许在不建立身份验证的情况下访问某些邮箱。这可以通过[ANONYMOUS]中描述的匿名[SASL]验证器实现。旧的约定是使用用户标识“匿名”的登录命令；在这种情况下，尽管服务器可以选择接受任何密码，但仍需要密码。对匿名用户的限制取决于实现。
Once authenticated (including as anonymous), it is not possible to re-enter not authenticated state.
一旦验证（包括匿名），就不可能重新进入未验证状态。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the not authenticated state: STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations section for important information about these commands.
除了通用命令（CAPABILITY、NOOP和LOGOUT），以下命令在未验证状态下有效：STARTTLS、AUTHENTICATE和LOGIN。有关这些命令的重要信息，请参见安全注意事项部分。
Arguments: none
论点：无
Responses: no specific response for this command
响应：此命令没有特定响应
Result: OK - starttls completed, begin TLS negotiation BAD - command unknown or arguments invalid
结果：OK-starttls已完成，begin TLS协商错误-命令未知或参数无效
A [TLS] negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the [TLS] negotiation is complete.
[TLS]协商在服务器标记的OK响应结束时的CRLF之后立即开始。一旦客户机发出STARTTLS命令，在看到服务器响应且[TLS]协商完成之前，不得发出进一步的命令。
The server remains in the non-authenticated state, even if client credentials are supplied during the [TLS] negotiation. This does not preclude an authentication mechanism such as EXTERNAL (defined in [SASL]) from using client identity determined by the [TLS] negotiation.
即使在[TLS]协商期间提供了客户端凭据，服务器仍保持未经身份验证的状态。这并不妨碍外部（在[SASL]中定义）等身份验证机制使用由[TLS]协商确定的客户机标识。
Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS.
启动[TLS]后，客户端必须丢弃有关服务器功能的缓存信息，并应重新发出CAPABILITY命令。这对于防止中间人攻击是必要的，中间人攻击会在STARTTLS之前改变功能列表。服务器可能会在STARTTLS之后公布不同的功能。
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
Arguments: authentication mechanism name
参数：身份验证机制名称
Responses: continuation data can be requested
答复：可以请求继续数据
Result: OK - authenticate completed, now in authenticated state NO - authenticate failure: unsupported authentication mechanism, credentials rejected BAD - command unknown or arguments invalid, authentication exchange cancelled
结果：确定-身份验证已完成，现在处于身份验证状态否-身份验证失败：不支持的身份验证机制，拒绝的凭据错误-命令未知或参数无效，身份验证交换已取消
The AUTHENTICATE command indicates a [SASL] authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the client. It MAY also negotiate an OPTIONAL security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server SHOULD reject the AUTHENTICATE command by sending a tagged NO response.
AUTHENTICATE命令向服务器指示[SASL]身份验证机制。如果服务器支持请求的身份验证机制，它将执行身份验证协议交换，以对客户端进行身份验证和标识。它还可以协商后续协议交互的可选安全层。如果请求的身份验证机制不受支持，服务器应通过发送带标记的“无”响应来拒绝“身份验证”命令。
The AUTHENTICATE command does not support the optional "initial response" feature of [SASL]. Section 5.1 of [SASL] specifies how to handle an authentication mechanism which uses an initial response.
AUTHENTICATE命令不支持[SASL]的可选“初始响应”功能。[SASL]第5.1节规定了如何处理使用初始响应的身份验证机制。
The service name specified by this protocol's profile of [SASL] is "imap".
此协议的[SASL]配置文件指定的服务名称为“imap”。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a tagged BAD response.
身份验证协议交换由一系列特定于身份验证机制的服务器质询和客户端响应组成。服务器质询由命令继续请求响应组成，该响应带有“+”标记，后跟BASE64编码字符串。客户端响应由一行组成，该行由BASE64编码字符串组成。如果客户端希望取消身份验证交换，它将发出一行，其中包含一个“*”。如果服务器收到这样的响应，它必须通过发送标记的错误响应来拒绝AUTHENTICATE命令。
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 tagged OK response for the server.
如果通过[SASL]身份验证交换协商安全层，则该层将在完成客户端身份验证交换的CRLF和服务器标记的OK响应的CRLF之后立即生效。
While client and server implementations MUST implement the AUTHENTICATE command itself, it is not required to implement any authentication mechanisms other than the PLAIN mechanism described
虽然客户机和服务器实现必须实现AUTHENTICATE命令本身，但除了所描述的普通机制之外，不需要实现任何身份验证机制
in [IMAP-TLS]. Also, an authentication mechanism is not required to support any security layers.
在[IMAP-TLS]中。此外，不需要身份验证机制来支持任何安全层。
Note: a server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. Client and server implementations SHOULD implement additional [SASL] mechanisms that do not use plaintext passwords, such the GSSAPI mechanism described in [SASL] and/or the [DIGEST-MD5] mechanism.
注意：服务器实现必须实现不允许任何明文密码机制的配置，除非已协商STARTTLS命令或已提供保护会话免受密码窥探的其他机制。服务器站点不应使用任何允许明文密码机制的配置，而不应使用防止密码窥探的保护机制。客户端和服务器实现应实现不使用明文密码的其他[SASL]机制，如[SASL]中描述的GSSAPI机制和/或[DIGEST-MD5]机制。
Servers and clients can support multiple authentication mechanisms. The server SHOULD list its supported authentication mechanisms in the response to the CAPABILITY command so that the client knows which authentication mechanisms to use.
服务器和客户端可以支持多种身份验证机制。服务器应在对CAPABILITY命令的响应中列出其支持的身份验证机制，以便客户端知道要使用哪些身份验证机制。
A server MAY include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. This should only be done if a security layer was not negotiated by the AUTHENTICATE command, because the tagged OK response as part of an AUTHENTICATE command is not protected by encryption/integrity checking. [SASL] requires the client to re-issue a CAPABILITY command in this case.
服务器可以在成功的身份验证命令的标记OK响应中包括能力响应代码，以便自动发送能力。如果客户机能够识别这些自动功能，则无需发送单独的功能命令。仅当AUTHENTICATE命令未协商安全层时，才应执行此操作，因为作为AUTHENTICATE命令一部分的标记OK响应不受加密/完整性检查的保护。[SASL]在这种情况下要求客户端重新发出能力命令。
If an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command. It MAY also attempt to authenticate by using the LOGIN command (see section 6.2.3 for more detail). In other words, the client MAY request authentication types in decreasing order of preference, with the LOGIN command as a last resort.
如果AUTHENTICATE命令失败且没有响应，则客户端可以通过发出另一个AUTHENTICATE命令来尝试另一种身份验证机制。它还可以尝试使用LOGIN命令进行身份验证（有关更多详细信息，请参阅第6.2.3节）。换句话说，客户机可能会请求按优先顺序递减的身份验证类型，登录命令是最后的手段。
The authorization identity passed from the client to the server during the authentication exchange is interpreted by the server as the user name whose privileges the client is requesting.
在身份验证交换期间从客户端传递到服务器的授权标识由服务器解释为客户端请求其权限的用户名。
Example: S: * OK IMAP4rev1 Server
C: A001 AUTHENTICATE GSSAPI
S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful
Example: S: * OK IMAP4rev1 Server
C: A001 AUTHENTICATE GSSAPI
S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful
Note: The line breaks within server challenges and client responses are for editorial clarity and are not in real authenticators.
注意：服务器挑战和客户端响应中的换行符是为了编辑清晰，而不是在真实的验证器中。
Arguments: user name password
参数：用户名密码
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
The LOGIN command identifies the client to the server and carries the plaintext password authenticating this user.
LOGIN命令向服务器标识客户端，并携带验证该用户的明文密码。
A server MAY include a CAPABILITY response code in the tagged OK response to a successful LOGIN command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
服务器可以在对成功登录命令的标记OK响应中包含功能响应代码，以便自动发送功能。如果客户机能够识别这些自动功能，则无需发送单独的功能命令。
Example: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
示例：C:a001登录S:a001 OK登录已完成
Note: Use of the LOGIN command over an insecure network (such as the Internet) is a security risk, because anyone monitoring network traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT be used except as a last resort, and it is recommended that client implementations have a means to disable any automatic use of the LOGIN command.
注意：在不安全的网络（如互联网）上使用LOGIN命令存在安全风险，因为任何监控网络流量的人都可以获得明文密码。除非作为最后手段，否则不应使用LOGIN命令，建议客户端实现有一种方法来禁用LOGIN命令的任何自动使用。
Unless either the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided, a server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability and does NOT permit the LOGIN command. Server sites SHOULD NOT use any configuration which permits the LOGIN command without such a protection mechanism against password snooping. A client implementation MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised.
除非已协商STARTTLS命令或提供了保护会话免受密码窥探的其他机制，否则服务器实现必须实现一种配置，在该配置中，它播发LOGINDISABLED功能，并且不允许LOGIN命令。服务器站点不应使用任何允许登录命令的配置，而不应使用防止密码窥探的保护机制。如果公布LOGINDISABLED功能，则客户端实现不得发送登录命令。
In the authenticated state, commands that manipulate mailboxes as atomic entities are permitted. Of these commands, the SELECT and EXAMINE commands will select a mailbox for access and enter the selected state.
在已验证状态下，允许将邮箱作为原子实体进行操作的命令。在这些命令中，“选择”和“检查”命令将选择要访问的邮箱并进入选定状态。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the authenticated state: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND.
除了通用命令（CAPABILITY、NOOP和LOGOUT）之外，以下命令在经过身份验证的状态下也是有效的：选择、检查、创建、删除、重命名、订阅、取消订阅、列表、LSUB、状态和附加。
Arguments: mailbox name
参数：邮箱名称
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
响应：必需的未标记响应：标志、存在、最近必需的OK未标记响应：未看见、永久标志、UIDNEXT、UIDVality
Result: OK - select completed, now in selected state NO - select failure, now in authenticated state: no such mailbox, can't access mailbox BAD - command unknown or arguments invalid
结果：确定-选择已完成，现在处于选定状态否-选择失败，现在处于已验证状态：没有这样的邮箱，无法访问邮箱错误-命令未知或参数无效
The SELECT command selects a mailbox so that messages in the mailbox can be accessed. Before returning an OK to the client, the server MUST send the following untagged data to the client. Note that earlier versions of this protocol only required the FLAGS, EXISTS, and RECENT untagged data; consequently, client implementations SHOULD implement default behavior for missing data as discussed with the individual item.
SELECT命令选择邮箱，以便可以访问邮箱中的邮件。在向客户端返回OK之前，服务器必须向客户端发送以下未标记的数据。请注意，此协议的早期版本只需要标志、存在和最近未标记的数据；因此，客户机实现应该实现缺失数据的默认行为，如与单个项讨论的那样。
FLAGS Defined flags in the mailbox. See the description of the FLAGS response for more detail.
在邮箱中定义的标志。有关更多详细信息，请参见标志响应的描述。
<n> EXISTS The number of messages in the mailbox. See the description of the EXISTS response for more detail.
<n> 存在邮箱中的邮件数。有关更多详细信息，请参阅EXISTS响应的描述。
<n> RECENT The number of messages with the \Recent flag set. See the description of the RECENT response for more detail.
<n> 最近设置了\RECENT标志的邮件数。有关更多详细信息，请参见最近响应的描述。
OK [UNSEEN <n>] The message sequence number of the first unseen message in the mailbox. If this is missing, the client can not make any assumptions about the first unseen message in the mailbox, and needs to issue a SEARCH command if it wants to find it.
确定[未查看<n>]邮箱中第一封未查看邮件的邮件序列号。如果缺少此选项，则客户端无法对邮箱中第一条未看到的邮件进行任何假设，如果要查找该邮件，则需要发出搜索命令。
OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that the client can change permanently. If this is missing, the client should assume that all flags can be changed permanently.
OK[PERMANENTFLAGS（<list of flags>）]客户端可以永久更改的消息标志列表。如果缺少此项，则客户端应假定所有标志都可以永久更改。
OK [UIDNEXT <n>] The next unique identifier value. Refer to section 2.3.1.1 for more information. If this is missing, the client can not make any assumptions about the next unique identifier value.
确定[UIDNEXT<n>]下一个唯一标识符值。更多信息，请参阅第2.3.1.1节。如果缺少此项，则客户端无法对下一个唯一标识符值进行任何假设。
OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to section 2.3.1.1 for more information. If this is missing, the server does not support unique identifiers.
确定[UIDVALIDITY<n>]唯一标识符有效性值。更多信息，请参阅第2.3.1.1节。如果缺少此项，则服务器不支持唯一标识符。
Only one mailbox can be selected at a time in a connection; simultaneous access to multiple mailboxes requires multiple connections. The SELECT command automatically deselects any currently selected mailbox before attempting the new selection. Consequently, if a mailbox is selected and a SELECT command that fails is attempted, no mailbox is selected.
一个连接中一次只能选择一个邮箱；同时访问多个邮箱需要多个连接。在尝试新的选择之前，SELECT命令会自动取消选择任何当前选定的邮箱。因此，如果选择邮箱并尝试执行失败的SELECT命令，则不会选择任何邮箱。
If the client is permitted to modify the mailbox, the server SHOULD prefix the text of the tagged OK response with the "[READ-WRITE]" response code.
如果允许客户端修改邮箱，服务器应在标记好的OK响应的文本前面加上“[读写]”响应代码。
If the client is not permitted to modify the mailbox but is permitted read access, the mailbox is selected as read-only, and the server MUST prefix the text of the tagged OK response to SELECT with the "[READ-ONLY]" response code. Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Netnews messages marked in a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes.
如果不允许客户端修改邮箱，但允许对其进行读取访问，则会将邮箱选择为只读，并且服务器必须在要选择的已标记OK响应的文本前面加上“[只读]”响应代码。通过SELECT进行只读访问与EXAMINE命令的不同之处在于，某些只读邮箱可能允许基于每个用户（而不是全局）更改永久状态。在基于服务器的.newsrc文件中标记的Netnews邮件就是这样一种每个用户的永久状态，可以使用只读邮箱进行修改。
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
Arguments: mailbox name
参数：邮箱名称
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
响应：必需的未标记响应：标志、存在、最近必需的OK未标记响应：未看见、永久标志、UIDNEXT、UIDVality
Result: OK - examine completed, now in selected state NO - examine failure, now in authenticated state: no such mailbox, can't access mailbox BAD - command unknown or arguments invalid
结果：确定-检查已完成，现在处于选定状态否-检查失败，现在处于已验证状态：没有这样的邮箱，无法访问邮箱错误-命令未知或参数无效
The EXAMINE command is identical to SELECT and returns the same output; however, the selected mailbox is identified as read-only. No changes to the permanent state of the mailbox, including per-user state, are permitted; in particular, EXAMINE MUST NOT cause messages to lose the \Recent flag.
检查命令与选择命令相同，并返回相同的输出；但是，所选邮箱被标识为只读。不允许更改邮箱的永久状态，包括每个用户的状态；特别是，检查不能导致消息丢失\Recent标志。
The text of the tagged OK response to the EXAMINE command MUST begin with the "[READ-ONLY]" response code.
对EXAMINE命令的已标记OK响应的文本必须以“[只读]”响应代码开头。
Example: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
Example: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
Arguments: mailbox name
参数：邮箱名称
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
The CREATE command creates a mailbox with the given name. An OK response is returned only if a new mailbox with that name has been created. It is an error to attempt to create INBOX or a mailbox with a name that refers to an extant mailbox. Any error in creation will return a tagged NO response.
CREATE命令创建具有给定名称的邮箱。仅当已创建具有该名称的新邮箱时，才会返回OK响应。尝试使用引用现有邮箱的名称创建收件箱或邮箱时出错。创建过程中的任何错误都将返回标记为“无”的响应。
If the mailbox name is suffixed with the server's hierarchy separator character (as returned from the server by a LIST command), this is a declaration that the client intends to create mailbox names under this name in the hierarchy. Server implementations that do not require this declaration MUST ignore the declaration. In any case, the name created is without the trailing hierarchy delimiter.
如果邮箱名称以服务器的层次结构分隔符字符作为后缀（通过LIST命令从服务器返回），则这是一种声明，表明客户端打算在层次结构中的该名称下创建邮箱名称。不需要此声明的服务器实现必须忽略该声明。在任何情况下，创建的名称都不带尾部层次分隔符。
If the server's hierarchy separator character appears elsewhere in the name, the server SHOULD create any superior hierarchical names that are needed for the CREATE command to be successfully completed. In other words, an attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy separator character SHOULD create foo/ and foo/bar/ if they do not already exist.
如果服务器的层次分隔符字符出现在名称的其他位置，则服务器应创建成功完成create命令所需的任何上级层次名称。换句话说，在“/”是层次分隔符的服务器上尝试创建“foo/bar/zap”，如果它们不存在，则应创建foo/和foo/bar/。
If a new mailbox is created with the same name as a mailbox which was deleted, its unique identifiers MUST be greater than any unique identifiers used in the previous incarnation of the mailbox UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
如果使用与已删除邮箱相同的名称创建新邮箱，则其唯一标识符必须大于邮箱前一版本中使用的任何唯一标识符，除非新版本具有不同的唯一标识符有效性值。有关详细信息，请参见UID命令的说明。
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Note: The interpretation of this example depends on whether "/" was returned as the hierarchy separator from LIST. If "/" is the hierarchy separator, a new level of hierarchy named "owatagusiam" with a member called "blurdybloop" is created. Otherwise, two mailboxes at the same hierarchy level are created.
注意：此示例的解释取决于“/”是否作为列表的层次分隔符返回。如果“/”是层次结构分隔符，则将创建名为“owatagusiam”的新层次结构级别，其中包含名为“blurdybloop”的成员。否则，将在同一层次结构级别创建两个邮箱。
Arguments: mailbox name
参数：邮箱名称
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - delete completed
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
Result: OK - delete completed
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
The DELETE command permanently removes the mailbox with the given name. A tagged OK response is returned only if the mailbox has been deleted. It is an error to attempt to delete INBOX or a mailbox name that does not exist.
DELETE命令永久删除具有给定名称的邮箱。仅当邮箱已删除时，才会返回带标记的OK响应。尝试删除收件箱或不存在的邮箱名称是错误的。
The DELETE command MUST NOT remove inferior hierarchical names. For example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." is the hierarchy delimiter character), removing "foo" MUST NOT remove "foo.bar". It is an error to attempt to delete a name that has inferior hierarchical names and also has the \Noselect mailbox name attribute (see the description of the LIST response for more details).
DELETE命令不能删除下级层次结构名称。例如，如果邮箱“foo”具有次“foo.bar”（假设“.”是层次结构分隔符），则删除“foo”不能删除“foo.bar”。尝试删除具有较低层次结构名称且具有\n选择邮箱名称属性的名称是错误的（有关详细信息，请参阅列表响应的说明）。
It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute.
允许删除具有较低层次结构名称且不具有\n选择邮箱名称属性的名称。在这种情况下，将删除该邮箱中的所有邮件，并且该名称将获得\n选择邮箱名称属性。
The value of the highest-used unique identifier of the deleted mailbox MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
必须保留已删除邮箱的最高使用唯一标识符的值，以便使用相同名称创建的新邮箱不会重用前一个化身的标识符，除非新化身具有不同的唯一标识符有效性值。有关详细信息，请参见UID命令的说明。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
Arguments: existing mailbox name new mailbox name
参数：现有邮箱名称新邮箱名称
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - rename completed NO - rename failure: can't rename mailbox with that name, can't rename to mailbox with that name BAD - command unknown or arguments invalid
结果：确定-重命名已完成否-重命名失败：无法重命名具有该名称的邮箱，无法重命名为具有该名称的邮箱错误-命令未知或参数无效
The RENAME command changes the name of a mailbox. A tagged OK response is returned only if the mailbox has been renamed. It is an error to attempt to rename from a mailbox name that does not exist or to a mailbox name that already exists. Any error in renaming will return a tagged NO response.
重命名命令更改邮箱的名称。仅当邮箱已重命名时，才会返回带标记的OK响应。尝试将不存在的邮箱名称重命名为已存在的邮箱名称时出错。重命名中的任何错误都将返回标记为“无”的响应。
If the name has inferior hierarchical names, then the inferior hierarchical names MUST also be renamed. For example, a rename of "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy delimiter character) to "zap/bar".
如果名称具有较低层次的名称，则还必须重命名较低层次的名称。例如，将“foo”重命名为“zap”将把“foo/bar”（假设“/”是层次分隔符）重命名为“zap/bar”。
If the server's hierarchy separator character appears in the name, the server SHOULD create any superior hierarchical names that are needed for the RENAME command to complete successfully. In other words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a server in which "/" is the hierarchy separator character SHOULD create baz/ and baz/rag/ if they do not already exist.
如果名称中出现服务器的层次结构分隔符，则服务器应创建重命名命令成功完成所需的任何上级层次结构名称。换句话说，在“/”是层次分隔符的服务器上，如果试图将“foo/bar/zap”重命名为baz/rag/zowie，则应创建baz/和baz/rag/（如果它们不存在）。
The value of the highest-used unique identifier of the old mailbox name MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
必须保留旧邮箱名称的最高使用唯一标识符的值，以便使用相同名称创建的新邮箱不会重用前一个版本的标识符，除非新版本具有不同的唯一标识符有效性值。有关详细信息，请参见UID命令的说明。
Renaming INBOX is permitted, and has special behavior. It moves all messages in INBOX to a new mailbox with the given name, leaving INBOX empty. If the server implementation supports inferior hierarchical names of INBOX, these are unaffected by a rename of INBOX.
允许重命名收件箱，并且具有特殊行为。它会将收件箱中的所有邮件移动到具有给定名称的新邮箱，使收件箱为空。如果服务器实现支持收件箱的低级层次名称，则这些名称不受收件箱重命名的影响。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
Arguments: mailbox
参数：邮箱
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
The SUBSCRIBE command adds the specified mailbox name to the server's set of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns a tagged OK response only if the subscription is successful.
SUBSCRIBE命令将指定的邮箱名称添加到LSUB命令返回的服务器的“活动”或“订阅”邮箱集中。仅当订阅成功时，此命令才会返回带标记的OK响应。
A server MAY validate the mailbox argument to SUBSCRIBE to verify that it exists. However, it MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.
服务器可以验证要订阅的邮箱参数，以验证它是否存在。但是，它不能单方面从订阅列表中删除现有邮箱名称，即使该名称的邮箱已不存在。
Note: This requirement is because a server site can choose to routinely remove a mailbox with a well-known name (e.g., "system-alerts") after its contents expire, with the intention of recreating it when new contents are appropriate.
注意：此要求是因为服务器站点可以选择在其内容过期后定期删除具有已知名称（例如“系统警报”）的邮箱，以便在新内容合适时重新创建邮箱。
Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
Arguments: mailbox name
参数：邮箱名称
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
The UNSUBSCRIBE command removes the specified mailbox name from the server's set of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns a tagged OK response only if the unsubscription is successful.
UNSUBSCRIBE命令从LSUB命令返回的服务器“活动”或“订阅”邮箱集中删除指定的邮箱名称。仅当取消订阅成功时，此命令才会返回带标记的OK响应。
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
Arguments: reference name mailbox name with possible wildcards
参数：使用可能的通配符引用名称邮箱名称
Responses: untagged responses: LIST
响应：未标记的响应：列表
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LIST command returns a subset of names from the complete set of all names available to the client. Zero or more untagged LIST replies are returned, containing the name attributes, hierarchy delimiter, and name; see the description of the LIST reply for more detail.
LIST命令从客户端可用的所有名称的完整集合中返回名称的子集。返回零个或多个未标记的列表答复，其中包含名称属性、层次分隔符和名称；有关更多详细信息，请参见列表回复的说明。
The LIST command SHOULD return its data quickly, without undue delay. For example, it SHOULD NOT go to excess trouble to calculate the \Marked or \Unmarked status or perform other processing; if each name requires 1 second of processing, then a list of 1200 names would take 20 minutes!
LIST命令应快速返回其数据，无过度延迟。例如，计算\Marked或\Unmarked状态或执行其他处理不应过度麻烦；如果每个名称需要1秒的处理，那么1200个名称的列表将需要20分钟！
An empty ("" string) reference name argument indicates that the mailbox name is interpreted as by SELECT. The returned mailbox names MUST match the supplied mailbox name pattern. A non-empty reference name argument is the name of a mailbox or a level of mailbox hierarchy, and indicates the context in which the mailbox name is interpreted.
空（“”字符串）引用名称参数表示邮箱名称被SELECT解释为。返回的邮箱名称必须与提供的邮箱名称模式匹配。非空引用名称参数是邮箱或邮箱层次结构级别的名称，并指示解释邮箱名称的上下文。
An empty ("" string) mailbox name argument is a special request to return the hierarchy delimiter and the root name of the name given in the reference. The value returned as the root MAY be the empty string if the reference is non-rooted or is an empty string. In all cases, a hierarchy delimiter (or NIL if there is no hierarchy) is returned. This permits a client to get the hierarchy delimiter (or find out that the mailbox names are flat) even when no mailboxes by that name currently exist.
空（“”字符串）邮箱名称参数是一个特殊请求，用于返回层次分隔符和引用中给定名称的根名称。如果引用是非根引用或空字符串，则作为根返回的值可能是空字符串。在所有情况下，都会返回层次分隔符（如果没有层次，则返回NIL）。这允许客户端获取层次结构分隔符（或发现邮箱名称是扁平的），即使当前不存在以该名称命名的邮箱。
The reference and mailbox name arguments are interpreted into a canonical form that represents an unambiguous left-to-right hierarchy. The returned mailbox names will be in the interpreted form.
引用和邮箱名称参数被解释为代表从左到右明确层次结构的规范形式。返回的邮箱名称将采用解释格式。
Note: The interpretation of the reference argument is implementation-defined. It depends upon whether the server implementation has a concept of the "current working directory" and leading "break out characters", which override the current working directory.
注：引用参数的解释由实现定义。这取决于服务器实现是否具有“当前工作目录”和前导“中断字符”的概念，它们覆盖当前工作目录。
For example, on a server which exports a UNIX or NT filesystem, the reference argument contains the current working directory, and the mailbox name argument would contain the name as interpreted in the current working directory.
例如，在导出UNIX或NT文件系统的服务器上，reference参数包含当前工作目录，mailbox name参数将包含当前工作目录中解释的名称。
If a server implementation has no concept of break out characters, the canonical form is normally the reference name appended with the mailbox name. Note that if the server implements the namespace convention (section 5.1.2), "#" is a break out character and must be treated as such.
如果服务器实现没有中断字符的概念，则规范形式通常是附加邮箱名称的引用名称。请注意，如果服务器实现了名称空间约定（第5.1.2节），“#”是一个分隔符，必须按此处理。
If the reference argument is not a level of mailbox hierarchy (that is, it is a \NoInferiors name), and/or the reference argument does not end with the hierarchy delimiter, it is implementation-dependent how this is interpreted. For example, a reference of "foo/bar" and mailbox name of "rag/baz" could be interpreted as "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz". A client SHOULD NOT use such a reference argument except at the explicit request of the user. A hierarchical browser MUST NOT make any assumptions about server interpretation of the reference unless the reference is a level of mailbox hierarchy AND ends with the hierarchy delimiter.
如果引用参数不是邮箱层次结构的一个级别（即，它是一个\n索引层名称），和/或引用参数不是以层次结构分隔符结尾，则它取决于如何解释它。例如，引用“foo/bar”和邮箱名称“rag/baz”可以解释为“foo/bar/rag/baz”、“foo/barrag/baz”或“foo/rag/baz”。除非用户明确要求，否则客户端不应使用此类引用参数。层次结构浏览器不得对引用的服务器解释做出任何假设，除非引用是邮箱层次结构的一个级别，并以层次结构分隔符结尾。
Any part of the reference argument that is included in the interpreted form SHOULD prefix the interpreted form. It SHOULD also be in the same form as the reference name argument. This rule permits the client to determine if the returned mailbox name is in the context of the reference argument, or if something about the mailbox argument overrode the reference argument. Without this rule, the client would have to have knowledge of the server's naming semantics including what characters are "breakouts" that override a naming context.
解释表单中包含的引用参数的任何部分都应该在解释表单的前面加前缀。它还应该与reference name参数的形式相同。此规则允许客户端确定返回的邮箱名称是否在引用参数的上下文中，或者邮箱参数的某些内容是否覆盖了引用参数。如果没有这个规则，客户机必须了解服务器的命名语义，包括哪些字符是覆盖命名上下文的“突破口”。
For example, here are some examples of how references and mailbox names might be interpreted on a UNIX-based server:
例如，以下是一些在基于UNIX的服务器上如何解释引用和邮箱名称的示例：
Reference Mailbox Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
Reference Mailbox Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
The first three examples demonstrate interpretations in the context of the reference argument. Note that "~smith/Mail" SHOULD NOT be transformed into something like "/u2/users/smith/Mail", or it would be impossible for the client to determine that the interpretation was in the context of the reference.
前三个例子展示了参考论点背景下的解释。请注意，“~smith/Mail”不应转换为“/u2/users/smith/Mail”之类的内容，否则客户将无法确定解释是在引用的上下文中进行的。
The character "*" is a wildcard, and matches zero or more characters at this position. The character "%" is similar to "*", but it does not match a hierarchy delimiter. If the "%" wildcard is the last character of a mailbox name argument, matching levels of hierarchy are also returned. If these levels of hierarchy are not also selectable mailboxes, they are returned with the \Noselect mailbox name attribute (see the description of the LIST response for more details).
字符“*”是通配符，与此位置的零个或多个字符匹配。字符“%”类似于“*”，但与层次结构分隔符不匹配。如果“%”通配符是邮箱名称参数的最后一个字符，则还将返回层次结构的匹配级别。如果这些层次结构级别也不是可选的邮箱，则会返回\n选择邮箱名称属性（有关详细信息，请参阅列表响应的说明）。
Server implementations are permitted to "hide" otherwise accessible mailboxes from the wildcard characters, by preventing certain characters or names from matching a wildcard in certain situations. For example, a UNIX-based server might restrict the interpretation of "*" so that an initial "/" character does not match.
允许服务器实现通过防止某些字符或名称在某些情况下与通配符匹配，从而对通配符“隐藏”本来可以访问的邮箱。例如，基于UNIX的服务器可能会限制对“*”的解释，以便初始“/”字符不匹配。
The special name INBOX is included in the output from LIST, if INBOX is supported by this server for this user and if the uppercase string "INBOX" matches the interpreted reference and mailbox name arguments with wildcards as described above. The criteria for omitting INBOX is whether SELECT INBOX will return failure; it is not relevant whether the user's real INBOX resides on this or some other server.
如果此服务器支持此用户的收件箱，并且大写字符串“INBOX”与解释的引用和邮箱名称参数与通配符匹配（如上所述），则特殊名称INBOX将包含在输出自列表中。省略收件箱的标准是选择收件箱是否返回失败；用户的真实收件箱是否驻留在该服务器或其他服务器上并不相关。
Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
Arguments: reference name mailbox name with possible wildcards
参数：使用可能的通配符引用名称邮箱名称
Responses: untagged responses: LSUB
响应：未标记的响应：LSUB
Result: OK - lsub completed
NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid
Result: OK - lsub completed
NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LSUB command returns a subset of names from the set of names that the user has declared as being "active" or "subscribed". Zero or more untagged LSUB replies are returned. The arguments to LSUB are in the same form as those for LIST.
LSUB命令从用户声明为“活动”或“订阅”的名称集中返回名称子集。返回零个或多个未标记的LSUB回复。LSUB的参数格式与LIST的参数格式相同。
The returned untagged LSUB response MAY contain different mailbox flags from a LIST untagged response. If this should happen, the flags in the untagged LIST are considered more authoritative.
返回的未标记LSUB响应可能包含与列表未标记响应不同的邮箱标志。如果发生这种情况，则认为未标记列表中的标志更具权威性。
A special situation occurs when using LSUB with the % wildcard. Consider what happens if "foo/bar" (with a hierarchy delimiter of "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must return foo, not foo/bar, in the LSUB response, and it MUST be flagged with the \Noselect attribute.
使用带有%通配符的LSUB时会出现特殊情况。考虑如果“Fo/bar”（具有“/”的层次定界符）订阅，但“Fo”不是什么。LSUB的“%”通配符必须在LSUB响应中返回foo，而不是foo/bar，并且必须用\Noselect属性标记它。
The server MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.
服务器不得单方面从订阅列表中删除现有邮箱名称，即使该名称的邮箱已不存在。
Example: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
C: A003 LSUB "#news." "comp.%"
S: * LSUB (\NoSelect) "." #news.comp.mail
S: A003 OK LSUB completed
Example: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
C: A003 LSUB "#news." "comp.%"
S: * LSUB (\NoSelect) "." #news.comp.mail
S: A003 OK LSUB completed
Arguments: mailbox name status data item names
参数：邮箱名称状态数据项名称
Responses: untagged responses: STATUS
响应：未标记的响应：状态
Result: OK - status completed
NO - status failure: no status for that name
BAD - command unknown or arguments invalid
Result: OK - status completed
NO - status failure: no status for that name
BAD - command unknown or arguments invalid
The STATUS command requests the status of the indicated mailbox. It does not change the currently selected mailbox, nor does it affect the state of any messages in the queried mailbox (in particular, STATUS MUST NOT cause messages to lose the \Recent flag).
STATUS命令请求指示邮箱的状态。它不会更改当前选定的邮箱，也不会影响查询邮箱中任何邮件的状态（尤其是，状态不能导致邮件丢失\Recent标志）。
The STATUS command provides an alternative to opening a second IMAP4rev1 connection and doing an EXAMINE command on a mailbox to query that mailbox's status without deselecting the current mailbox in the first IMAP4rev1 connection.
STATUS命令提供了一种替代方法，可以打开第二个IMAP4rev1连接并对邮箱执行EXAMINE命令来查询该邮箱的状态，而无需在第一个IMAP4rev1连接中取消选择当前邮箱。
Unlike the LIST command, the STATUS command is not guaranteed to be fast in its response. Under certain circumstances, it can be quite slow. In some implementations, the server is obliged to open the mailbox read-only internally to obtain certain status information. Also unlike the LIST command, the STATUS command does not accept wildcards.
与LIST命令不同，STATUS命令不能保证响应速度快。在某些情况下，它可能相当缓慢。在某些实现中，服务器必须在内部以只读方式打开邮箱以获取某些状态信息。与LIST命令不同，STATUS命令不接受通配符。
Note: The STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox.
注意：STATUS命令用于访问除当前选定邮箱之外的邮箱的状态。由于STATUS命令可导致邮箱在内部打开，并且由于此信息可通过其他方式在所选邮箱上获得，因此不应在当前所选邮箱上使用STATUS命令。
The STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to sections 7, 7.3.1, and 7.3.2 for more information about the proper method for new message checking).
STATUS命令不得用作“检查所选邮箱中的新邮件”操作（有关检查新邮件的正确方法的更多信息，请参阅第7节、第7.3.1节和第7.3.2节）。
Because the STATUS command is not guaranteed to be fast in its results, clients SHOULD NOT expect to be able to issue many consecutive STATUS commands and obtain reasonable performance.
因为不能保证STATUS命令的结果是快速的，所以客户端不应该期望能够发出许多连续的STATUS命令并获得合理的性能。
The currently defined status data items that can be requested are:
可以请求的当前定义的状态数据项包括：
MESSAGES The number of messages in the mailbox.
MESSAGES邮箱中的邮件数。
RECENT The number of messages with the \Recent flag set.
最近设置了\RECENT标志的邮件数。
UIDNEXT The next unique identifier value of the mailbox. Refer to section 2.3.1.1 for more information.
UIDNEXT邮箱的下一个唯一标识符值。更多信息，请参阅第2.3.1.1节。
UIDVALIDITY The unique identifier validity value of the mailbox. Refer to section 2.3.1.1 for more information.
UIDVALIDITY邮箱的唯一标识符有效性值。更多信息，请参阅第2.3.1.1节。
UNSEEN The number of messages which do not have the \Seen flag set.
UNSEEN未设置\Seen标志的邮件数。
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
Arguments: mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
参数：邮箱名称可选标志括号列表可选日期/时间字符串消息文本
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text
BAD - command unknown or arguments invalid
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text
BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message to the end of the specified destination mailbox. This argument SHOULD be in the format of an [RFC-2822] message. 8-bit characters are permitted in the message. A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer encoding.
APPEND命令将文字参数作为新邮件追加到指定目标邮箱的末尾。此参数的格式应为[RFC-2822]消息。消息中允许使用8位字符。无法正确保留8位数据的服务器实现必须能够使用[MIME-IMB]内容传输编码将8位追加数据可逆地转换为7位。
Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed.
注意：可能存在例外情况，例如，草稿消息，其中需要追加的消息文字参数中省略了所需的[RFC-2822]头行。必须理解并仔细权衡这样做的全部影响。
If a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set to empty by default. In either case, the Recent flag is also set.
如果指定了带括号的标记列表，则应在生成的消息中设置标记；否则，结果消息的标志列表默认设置为空。在任何一种情况下，都会设置“最近”标志。
If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default.
如果指定了日期时间，则应在生成的消息中设置内部日期；否则，结果消息的内部日期默认设置为当前日期和时间。
If the append is unsuccessful for any reason, the mailbox MUST be restored to its state before the APPEND attempt; no partial appending is permitted.
如果由于任何原因导致追加失败，则必须将邮箱恢复到追加尝试之前的状态；不允许部分附加。
If the destination mailbox does not exist, a server MUST return an error, and MUST NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the APPEND if the CREATE is successful.
如果目标邮箱不存在，服务器必须返回错误，并且不能自动创建邮箱。除非确定无法创建目标邮箱，否则服务器必须发送响应代码“[TRYCREATE]”，作为标记的无响应文本的前缀。这会提示客户端，如果创建成功，它可以尝试创建命令并重试追加。
If the mailbox is currently selected, the normal new message actions SHOULD occur. Specifically, the server SHOULD notify the client immediately via an untagged EXISTS response. If the server does not do so, the client MAY issue a NOOP command (or failing that, a CHECK command) after one or more APPEND commands.
如果当前选择了邮箱，则应执行正常的新邮件操作。具体地说，服务器应该通过未标记的EXISTS响应立即通知客户机。如果服务器不这样做，客户机可能会在一个或多个APPEND命令之后发出NOOP命令（否则，发出CHECK命令）。
Example: C: A003 APPEND saved-messages (\Seen) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Example: C: A003 APPEND saved-messages (\Seen) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Note: The APPEND command is not used for message delivery, because it does not provide a mechanism to transfer [SMTP] envelope information.
注意：APPEND命令不用于邮件传递，因为它不提供传输[SMTP]信封信息的机制。
In the selected state, commands that manipulate messages in a mailbox are permitted.
在选定状态下，允许使用操作邮箱中邮件的命令。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), and the authenticated state commands (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND), the following commands are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
除了通用命令（CAPABILITY、NOOP和LOGOUT）和经过身份验证的状态命令（SELECT、inspect、CREATE、DELETE、RENAME、SUBSCRIBE、UNSUBSCRIBE、LIST、LSUB、STATUS和APPEND），以下命令在所选状态下有效：CHECK、CLOSE、EXPUNGE、SEARCH、FETCH、STORE、COPY和UID。
Arguments: none
论点：无
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - check completed BAD - command unknown or arguments invalid
结果：确定-检查已完成错误-命令未知或参数无效
The CHECK command requests a checkpoint of the currently selected mailbox. A checkpoint refers to any implementation-dependent housekeeping associated with the mailbox (e.g., resolving the server's in-memory state of the mailbox with the state on its
CHECK命令请求当前选定邮箱的检查点。检查点是指与邮箱关联的任何依赖于实现的内务管理（例如，使用邮箱上的状态解析邮箱的服务器内存中状态）
disk) that is not normally executed as part of each command. A checkpoint MAY take a non-instantaneous amount of real time to complete. If a server implementation has no such housekeeping considerations, CHECK is equivalent to NOOP.
磁盘），通常不作为每个命令的一部分执行。检查点可能需要非即时的实时时间才能完成。如果服务器实现没有这样的内务管理注意事项，那么CHECK相当于NOOP。
There is no guarantee that an EXISTS untagged response will happen as a result of CHECK. NOOP, not CHECK, SHOULD be used for new message polling.
无法保证检查的结果会出现EXISTS untagged响应。新消息轮询应使用NOOP而不是CHECK。
Example: C: FXXZ CHECK S: FXXZ OK CHECK Completed
示例：C:FXXZ检查S:FXXZ正常检查已完成
Arguments: none
论点：无
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - close completed, now in authenticated state BAD - command unknown or arguments invalid
结果：确定-关闭完成，现在处于身份验证状态错误-命令未知或参数无效
The CLOSE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox, and returns to the authenticated state from the selected state. No untagged EXPUNGE responses are sent.
CLOSE命令将从当前选定邮箱中永久删除所有设置了\Deleted标志的邮件，并从选定状态返回到已验证状态。未发送任何未标记的删除响应。
No messages are removed, and no error is given, if the mailbox is selected by an EXAMINE command or is otherwise selected read-only.
如果邮箱是通过“检查”命令选择的，或者是以只读方式选择的，则不会删除任何邮件，也不会出现任何错误。
Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT command MAY be issued without previously issuing a CLOSE command. The SELECT, EXAMINE, and LOGOUT commands implicitly close the currently selected mailbox without doing an expunge. However, when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because no untagged EXPUNGE responses (which the client would probably ignore) are sent.
即使选择了邮箱，也可以发出选择、检查或注销命令，而无需事先发出关闭命令。选择、检查和注销命令隐式关闭当前选定的邮箱，而不执行删除操作。但是，当许多消息被删除时，关闭注销或关闭选择序列比删除注销或删除选择序列快得多，因为没有发送未标记的删除响应（客户端可能会忽略）。
Example: C: A341 CLOSE S: A341 OK CLOSE completed
示例：C:A341关闭S:A341正常关闭完成
Arguments: none
论点：无
Responses: untagged responses: EXPUNGE
响应：未标记的响应：删除
Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid
结果：确定-删除已完成否-删除失败：无法删除（例如，权限被拒绝）错误-命令未知或参数无效
The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed.
EXPUNGE命令将永久删除当前选定邮箱中设置了\Deleted标志的所有邮件。在向客户端返回OK之前，将为每个被删除的消息发送一个未标记的EXPUNGE响应。
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag set. See the description of the EXPUNGE response for further explanation.
注意：在此示例中，消息3、4、7和11设置了\Deleted标志。有关详细说明，请参阅删除响应的说明。
Arguments: OPTIONAL [CHARSET] specification searching criteria (one or more)
参数：可选[CHARSET]规范搜索条件（一个或多个）
Responses: REQUIRED untagged response: SEARCH
响应：必需的未标记响应：搜索
Result: OK - search completed NO - search error: can't search that [CHARSET] or criteria BAD - command unknown or arguments invalid
结果：确定-搜索已完成否-搜索错误：无法搜索[CHARSET]或条件错误-命令未知或参数无效
The SEARCH command searches the mailbox for messages that match the given searching criteria. Searching criteria consist of one or more search keys. The untagged SEARCH response from the server contains a listing of message sequence numbers corresponding to those messages that match the searching criteria.
SEARCH命令在邮箱中搜索与给定搜索条件匹配的邮件。搜索条件由一个或多个搜索键组成。来自服务器的未标记搜索响应包含与匹配搜索条件的消息相对应的消息序列号列表。
When multiple keys are specified, the result is the intersection (AND function) of all the messages that match those keys. For example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all deleted messages from Smith that were placed in the mailbox since February 1, 1994. A search key can also be a parenthesized list of one or more search keys (e.g., for use with the OR and NOT keys).
指定多个键时，结果是与这些键匹配的所有消息的交集（和函数）。例如，自1994年2月1日起从“SMITH”中删除的标准是指自1994年2月1日起放入邮箱的所有从SMITH处删除的邮件。搜索键也可以是一个或多个搜索键的括号列表（例如，用于or和NOT键）。
Server implementations MAY exclude [MIME-IMB] body parts with terminal content media types other than TEXT and MESSAGE from consideration in SEARCH matching.
在搜索匹配中，服务器实现可能会将具有终端内容媒体类型（文本和消息除外）的[MIME-IMB]正文部分排除在考虑范围之外。
The OPTIONAL [CHARSET] specification consists of the word
"CHARSET" followed by a registered [CHARSET]. It indicates the
[CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
The OPTIONAL [CHARSET] specification consists of the word
"CHARSET" followed by a registered [CHARSET]. It indicates the
[CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
If the server does not support the specified [CHARSET], it MUST return a tagged NO response (not a BAD). This response SHOULD contain the BADCHARSET response code, which MAY list the [CHARSET]s supported by the server.
如果服务器不支持指定的[CHARSET]，它必须返回一个带标记的无响应（不是坏响应）。此响应应包含BADCHARSET响应代码，该代码可能列出服务器支持的[CHARSET]。
In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case-insensitive.
在所有使用字符串的搜索关键字中，如果字符串是字段的子字符串，则消息与关键字匹配。匹配不区分大小写。
The defined search keys are as follows. Refer to the Formal Syntax section for the precise syntactic definitions of the arguments.
定义的搜索键如下所示。有关参数的精确语法定义，请参阅正式语法部分。
<sequence set> Messages with message sequence numbers corresponding to the specified message sequence number set.
<sequence set>具有与指定消息序列号集对应的消息序列号的消息。
ALL All messages in the mailbox; the default initial key for ANDing.
邮箱中的所有邮件；安定的默认初始键。
ANSWERED Messages with the \Answered flag set.
设置了\应答标志的应答消息。
BCC <string> Messages that contain the specified string in the envelope structure's BCC field.
在信封结构的密件抄送字段中包含指定字符串的密件抄送<string>消息。
BEFORE <date> Messages whose internal date (disregarding time and timezone) is earlier than the specified date.
内部日期（不考虑时间和时区）早于指定日期的<date>消息之前。
BODY <string> Messages that contain the specified string in the body of the message.
BODY<string>消息体中包含指定字符串的消息。
CC <string> Messages that contain the specified string in the envelope structure's CC field.
CC<string>在信封结构的CC字段中包含指定字符串的消息。
DELETED Messages with the \Deleted flag set.
已删除设置了\DELETED标志的邮件。
DRAFT Messages with the \Draft flag set.
设置了\DRAFT标志的草稿邮件。
FLAGGED Messages with the \Flagged flag set.
设置了\FLAGGED标志的已标记邮件。
FROM <string> Messages that contain the specified string in the envelope structure's FROM field.
FROM<string>在信封结构的FROM字段中包含指定字符串的消息。
HEADER <field-name> <string> Messages that have a header with the specified field-name (as defined in [RFC-2822]) and that contains the specified string in the text of the header (what comes after the colon). If the string to search is zero-length, this matches all messages that have a header line with the specified field-name regardless of the contents.
HEADER<field name><string>具有具有指定字段名（如[RFC-2822]中所定义）且在标题文本中包含指定字符串（位于冒号之后）的标题的消息。如果要搜索的字符串长度为零，则无论内容如何，它都会匹配具有具有指定字段名的标题行的所有邮件。
KEYWORD <flag> Messages with the specified keyword flag set.
设置了指定关键字标志的关键字<flag>消息。
LARGER <n> Messages with an [RFC-2822] size larger than the specified number of octets.
[RFC-2822]大小大于指定八位字节数的较大<n>消息。
NEW Messages that have the \Recent flag set but not the \Seen flag. This is functionally equivalent to "(RECENT UNSEEN)".
设置了\Recent标志但未设置\Seen标志的新邮件。这在功能上等同于“（最近未看到的）”。
NOT <search-key> Messages that do not match the specified search key.
不<搜索键>与指定搜索键不匹配的消息。
OLD Messages that do not have the \Recent flag set. This is functionally equivalent to "NOT RECENT" (as opposed to "NOT NEW").
未设置\最近标记的旧邮件。这在功能上等同于“非最新”（而不是“非新”）。
ON <date> Messages whose internal date (disregarding time and timezone) is within the specified date.
在<date>消息上，其内部日期（不考虑时间和时区）在指定日期内。
OR <search-key1> <search-key2> Messages that match either search key.
或与任一搜索键匹配的<search-key1><search-key2>消息。
RECENT Messages that have the \Recent flag set.
设置了\RECENT标志的最近消息。
SEEN Messages that have the \Seen flag set.
已查看设置了\SEEN标志的邮件。
SENTBEFORE <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is earlier than the specified date.
SENTBEFORE<date>其[RFC-2822]日期：标头（忽略时间和时区）早于指定日期的消息。
SENTON <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is within the specified date.
SENTON<date>其[RFC-2822]日期：标头（不考虑时间和时区）在指定日期内的消息。
SENTSINCE <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is within or later than the specified date.
SENTSINCE<date>其[RFC-2822]日期：标头（不考虑时间和时区）在指定日期之内或之后的消息。
SINCE <date> Messages whose internal date (disregarding time and timezone) is within or later than the specified date.
自<日期>消息，其内部日期（不考虑时间和时区）在指定日期之内或之后。
SMALLER <n> Messages with an [RFC-2822] size smaller than the specified number of octets.
小于指定八位字节数的[RFC-2822]大小的<n>消息。
SUBJECT <string> Messages that contain the specified string in the envelope structure's SUBJECT field.
主题<string>在信封结构的主题字段中包含指定字符串的消息。
TEXT <string> Messages that contain the specified string in the header or body of the message.
TEXT<string>在消息头或消息体中包含指定字符串的消息。
TO <string> Messages that contain the specified string in the envelope structure's TO field.
在信封结构的“收件人”字段中包含指定字符串的收件人<string>消息。
UID <sequence set> Messages with unique identifiers corresponding to the specified unique identifier set. Sequence set ranges are permitted.
UID<sequence set>具有与指定唯一标识符集对应的唯一标识符的消息。允许序列集范围。
UNANSWERED Messages that do not have the \Answered flag set.
未设置\应答标志的未应答邮件。
UNDELETED Messages that do not have the \Deleted flag set.
未设置\Deleted标志的取消删除邮件。
UNDRAFT Messages that do not have the \Draft flag set.
取消起草未设置\Draft标志的邮件。
UNFLAGGED Messages that do not have the \Flagged flag set.
未设置\标记标志的未标记邮件。
UNKEYWORD <flag> Messages that do not have the specified keyword flag set.
未设置指定关键字标志的UNKEYWORD<flag>消息。
UNSEEN Messages that do not have the \Seen flag set.
未设置\Seen标志的未看到的邮件。
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
C: A283 SEARCH TEXT "string not in mailbox"
S: * SEARCH
S: A283 OK SEARCH completed
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
C: A283 SEARCH TEXT "string not in mailbox"
S: * SEARCH
S: A283 OK SEARCH completed
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
Note: Since this document is restricted to 7-bit ASCII text, it is not possible to show actual UTF-8 data. The "XXXXXX" is a placeholder for what would be 6 octets of 8-bit data in an actual transaction.
注：由于本文档仅限于7位ASCII文本，因此无法显示实际的UTF-8数据。“XXXXXX”是实际事务中8位数据的6个八位字节的占位符。
Arguments: sequence set message data item names or macro
参数：序列集消息数据项名称或宏
Responses: untagged responses: FETCH
响应：未标记的响应：获取
Result: OK - fetch completed
NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid
Result: OK - fetch completed
NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid
The FETCH command retrieves data associated with a message in the mailbox. The data items to be fetched can be either a single atom or a parenthesized list.
FETCH命令检索与邮箱中的邮件关联的数据。要获取的数据项可以是单个原子，也可以是带括号的列表。
Most data items, identified in the formal syntax under the msg-att-static rule, are static and MUST NOT change for any particular message. Other data items, identified in the formal syntax under the msg-att-dynamic rule, MAY change, either as a result of a STORE command or due to external events.
在msg att static规则下的正式语法中标识的大多数数据项都是静态的，不能针对任何特定消息进行更改。msg att动态规则下的正式语法中标识的其他数据项可能会因STORE命令或外部事件而更改。
For example, if a client receives an ENVELOPE for a message when it already knows the envelope, it can safely ignore the newly transmitted envelope.
例如，如果客户机在已经知道某个信封的情况下收到某个消息的信封，则可以安全地忽略新发送的信封。
There are three macros which specify commonly-used sets of data items, and can be used instead of data items. A macro must be used by itself, and not in conjunction with other macros or data items.
有三个宏指定常用的数据项集，可以用来代替数据项。宏必须单独使用，不能与其他宏或数据项结合使用。
ALL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
所有宏等效于：（标记INTERNALDATE RFC822.SIZE信封）
FAST Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
FAST宏等效于：（标志INTERNALDATE RFC822.SIZE）
FULL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
完整宏等效于：（标志INTERNALDATE RFC822.SIZE信封正文）
The currently defined data items that can be fetched are:
当前定义的可提取数据项包括：
BODY Non-extensible form of BODYSTRUCTURE.
车身结构的非可扩展形式。
BODY[<section>]<<partial>> The text of a particular body section. The section specification is a set of zero or more part specifiers delimited by periods. A part specifier is either a part number or one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. An empty section specification refers to the entire message, including the header.
正文[<section>]<<partial>>特定正文部分的文本。节规范是一组由句点分隔的零个或多个部分说明符。零件说明符可以是零件号，也可以是以下内容之一：HEADER、HEADER.FIELDS、HEADER.FIELDS.NOT、MIME和TEXT。空节规范指的是整个消息，包括消息头。
Every message has at least one part number. Non-[MIME-IMB] messages, and non-multipart [MIME-IMB] messages with no encapsulated message, only have a part 1.
每条消息至少有一个部件号。非[MIME-IMB]消息和没有封装消息的非多部分[MIME-IMB]消息只有第1部分。
Multipart messages are assigned consecutive part numbers, as they occur in the message. If a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part.
当多部分消息出现在消息中时，会为其分配连续的部分号。如果特定部件的类型为message或multipart，则其部件必须在嵌套的多部件部件中以句号后跟部件号表示。
A part of type MESSAGE/RFC822 also has nested part numbers, referring to parts of the MESSAGE part's body.
MESSAGE/RFC822类型的一部分也有嵌套的部件号，指的是消息部件主体的部分。
The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part specifiers can be the sole part specifier or can be prefixed by one or more numeric part specifiers, provided that the numeric part specifier refers to a part of type MESSAGE/RFC822. The MIME part specifier MUST be prefixed by one or more numeric part specifiers.
HEADER、HEADER.FIELDS、HEADER.FIELDS.NOT和文本部分说明符可以是唯一的部分说明符，也可以由一个或多个数字部分说明符作为前缀，前提是数字部分说明符引用MESSAGE/RFC822类型的部分。MIME部分说明符必须以一个或多个数字部分说明符作为前缀。
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part specifiers refer to the [RFC-2822] header of the message or of an encapsulated [MIME-IMT] MESSAGE/RFC822 message. HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of field-name (as defined in [RFC-2822]) names, and return a
HEADER、HEADER.FIELDS和HEADER.FIELDS.NOT部分说明符指的是消息或封装的[MIME-IMT]消息/RFC822消息的[RFC-2822]头。HEADER.FIELDS和HEADER.FIELDS.NOT后跟字段名列表（如[RFC-2822]中定义的）名称，并返回
subset of the header. The subset returned by HEADER.FIELDS contains only those header fields with a field-name that matches one of the names in the list; similarly, the subset returned by HEADER.FIELDS.NOT contains only the header fields with a non-matching field-name. The field-matching is case-insensitive but otherwise exact. Subsetting does not exclude the [RFC-2822] delimiting blank line between the header and the body; the blank line is included in all header fetches, except in the case of a message which has no body and no blank line.
标题的子集。HEADER.FIELDS返回的子集仅包含字段名与列表中的一个名称匹配的标题字段；类似地，HEADER.FIELDS.NOT返回的子集仅包含字段名不匹配的标题字段。字段匹配不区分大小写，但在其他方面是精确的。子集设置不排除标题和正文之间的[RFC-2822]定界空行；除了没有正文和空行的消息之外，所有行标题中都包含空白行。
The MIME part specifier refers to the [MIME-IMB] header for this part.
MIME部件说明符引用此部件的[MIME-IMB]头。
The TEXT part specifier refers to the text body of the message, omitting the [RFC-2822] header.
文本部分说明符引用消息的文本体，省略[RFC-2822]头。
Here is an example of a complex message with some of its part specifiers:
下面是一个包含部分说明符的复杂消息示例：
HEADER ([RFC-2822] header of the message) TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 1 TEXT/PLAIN 2 APPLICATION/OCTET-STREAM 3 MESSAGE/RFC822 3.HEADER ([RFC-2822] header of the message) 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 3.1 TEXT/PLAIN 3.2 APPLICATION/OCTET-STREAM 4 MULTIPART/MIXED 4.1 IMAGE/GIF 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) 4.2 MESSAGE/RFC822 4.2.HEADER ([RFC-2822] header of the message) 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 4.2.1 TEXT/PLAIN 4.2.2 MULTIPART/ALTERNATIVE 4.2.2.1 TEXT/PLAIN 4.2.2.2 TEXT/RICHTEXT
HEADER（[RFC-2822]消息头）TEXT（[RFC-2822]消息正文）MULTIPART/MIXED 1 TEXT/PLAIN 2 APPLICATION/OCTET-STREAM 3 message/RFC822 3.HEADER（[RFC-2822]消息头）3.TEXT（[RFC-2822]消息正文）MULTIPART/MIXED 3.1 TEXT/PLAIN 3.2 APPLICATION/OCTET-STREAM 4 MULTIPART/MIXED 4.1 IMAGE/GIF 4.1.MIME(图像的[MIME-IMB]头/GIF）4.2消息/RFC822 4.2.header（[RFC-2822]消息头）4.2.TEXT（[RFC-2822]消息正文）多部分/MIXED 4.2.1 TEXT/PLAIN 4.2.2多部分/ALTERNATIVE 4.2.2.1 TEXT/PLAIN 4.2.2.2 TEXT/RICHTEXT
It is possible to fetch a substring of the designated text. This is done by appending an open angle bracket ("<"), the octet position of the first desired octet, a period, the maximum number of octets desired, and a close angle bracket (">") to the part specifier. If the starting octet is beyond the end of the text, an empty string is returned.
可以获取指定文本的子字符串。这是通过在零件说明符后面附加一个开角括号（<”）、第一个所需八位字节的八位字节位置、一个句点、所需八位字节的最大数量以及一个闭角括号（“>”）来实现的。如果起始八位字节超出文本末尾，则返回空字符串。
Any partial fetch that attempts to read beyond the end of the text is truncated as appropriate. A partial fetch that starts at octet 0 is returned as a partial fetch, even if this truncation happened.
任何试图读取文本结尾以外内容的部分提取都会根据需要被截断。从八位元0开始的部分提取将作为部分提取返回，即使发生了此截断。
Note: This means that BODY[]<0.2048> of a 1500-octet message will return BODY[]<0> with a literal of size 1500, not BODY[].
注意：这意味着1500八位字节消息的BODY[]<0.2048>将返回文本大小为1500的BODY[]<0>，而不是BODY[]。
Note: A substring fetch of a HEADER.FIELDS or HEADER.FIELDS.NOT part specifier is calculated after subsetting the header.
注意：HEADER.FIELDS或HEADER.FIELDS.NOT部分说明符的子字符串获取是在对头进行子集设置后计算的。
The \Seen flag is implicitly set; if this causes the flags to change, they SHOULD be included as part of the FETCH responses.
\Seen标志被隐式设置；如果这导致标志更改，则应将其作为获取响应的一部分包含。
BODY.PEEK[<section>]<<partial>> An alternate form of BODY[<section>] that does not implicitly set the \Seen flag.
BODY.PEEK[<section>]<<partial>>BODY[<section>]的另一种形式，它不隐式设置\Seen标志。
BODYSTRUCTURE The [MIME-IMB] body structure of the message. This is computed by the server by parsing the [MIME-IMB] header fields in the [RFC-2822] header and [MIME-IMB] headers.
BODYSTRUCTURE消息的[MIME-IMB]正文结构。这由服务器通过解析[RFC-2822]头和[MIME-IMB]头中的[MIME-IMB]头字段来计算。
ENVELOPE The envelope structure of the message. This is computed by the server by parsing the [RFC-2822] header into the component parts, defaulting various fields as necessary.
信封消息的信封结构。这是由服务器通过将[RFC-2822]头解析为组件部分来计算的，并根据需要对各个字段进行默认设置。
FLAGS The flags that are set for this message.
标记为此消息设置的标记。
INTERNALDATE The internal date of the message.
INTERNALDATE消息的内部日期。
RFC822 Functionally equivalent to BODY[], differing in the syntax of the resulting untagged FETCH data (RFC822 is returned).
RFC822在功能上等同于BODY[]，在生成的未标记获取数据的语法上有所不同（返回RFC822）。
RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], differing in the syntax of the resulting untagged FETCH data (RFC822.HEADER is returned).
RFC822.HEADER在功能上等同于BODY.PEEK[HEADER]，在生成的未标记获取数据的语法上有所不同（返回RFC822.HEADER）。
RFC822.SIZE The [RFC-2822] size of the message.
RFC822.SIZE消息的[RFC-2822]大小。
RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in the syntax of the resulting untagged FETCH data (RFC822.TEXT is returned).
RFC822.TEXT在功能上等同于BODY[TEXT]，不同于生成的未标记获取数据的语法（返回RFC822.TEXT）。
UID The unique identifier for the message.
UID消息的唯一标识符。
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
Arguments: sequence set message data item name value for message data item
参数：序列设置消息数据项的消息数据项名称值
Responses: untagged responses: FETCH
响应：未标记的响应：获取
Result: OK - store completed
NO - store error: can't store that data
BAD - command unknown or arguments invalid
Result: OK - store completed
NO - store error: can't store that data
BAD - command unknown or arguments invalid
The STORE command alters data associated with a message in the mailbox. Normally, STORE will return the updated value of the data with an untagged FETCH response. A suffix of ".SILENT" in the data item name prevents the untagged FETCH, and the server SHOULD assume that the client has determined the updated value itself or does not care about the updated value.
STORE命令更改与邮箱中邮件关联的数据。通常，STORE将返回数据的更新值和未标记的FETCH响应。数据项名称中的后缀“.SILENT”会阻止未标记的获取，并且服务器应该假设客户端已经确定了更新的值本身，或者不关心更新的值。
Note: Regardless of whether or not the ".SILENT" suffix was used, the server SHOULD send an untagged FETCH response if a change to a message's flags from an external source is observed. The intent is that the status of the flags is determinate without a race condition.
注意：无论是否使用了“.SILENT”后缀，如果观察到外部源对消息标志的更改，服务器都应发送未标记的获取响应。其目的是在没有竞争条件的情况下确定标志的状态。
The currently defined data items that can be stored are:
当前定义的可存储数据项包括：
FLAGS <flag list> Replace the flags for the message (other than \Recent) with the argument. The new value of the flags is returned as if a FETCH of those flags was done.
FLAGS<flag list>用参数替换消息的标志（而不是\Recent）。返回标志的新值，就好像完成了这些标志的提取一样。
FLAGS.SILENT <flag list> Equivalent to FLAGS, but without returning a new value.
FLAGS.SILENT<flag list>相当于标志，但不返回新值。
+FLAGS <flag list> Add the argument to the flags for the message. The new value of the flags is returned as if a FETCH of those flags was done.
+FLAGS<flag list>将参数添加到消息的标志中。返回标志的新值，就好像完成了这些标志的提取一样。
+FLAGS.SILENT <flag list> Equivalent to +FLAGS, but without returning a new value.
+FLAGS.SILENT<flag list>相当于+标志，但不返回新值。
-FLAGS <flag list> Remove the argument from the flags for the message. The new value of the flags is returned as if a FETCH of those flags was done.
-FLAGS<flag list>从消息的标志中删除参数。返回标志的新值，就好像完成了这些标志的提取一样。
-FLAGS.SILENT <flag list> Equivalent to -FLAGS, but without returning a new value.
-FLAGS.SILENT<flag list>相当于-FLAGS，但不返回新值。
Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH (FLAGS (\Deleted \Seen))
S: * 3 FETCH (FLAGS (\Deleted))
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
S: A003 OK STORE completed
Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH (FLAGS (\Deleted \Seen))
S: * 3 FETCH (FLAGS (\Deleted))
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
S: A003 OK STORE completed
Arguments: sequence set mailbox name
参数：序列集邮箱名称
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - copy completed NO - copy error: can't copy those messages or to that name BAD - command unknown or arguments invalid
结果：OK-copy completed NO-copy错误：无法复制这些消息或复制到该名称错误-命令未知或参数无效
The COPY command copies the specified message(s) to the end of the specified destination mailbox. The flags and internal date of the message(s) SHOULD be preserved, and the Recent flag SHOULD be set, in the copy.
COPY命令将指定的邮件复制到指定目标邮箱的末尾。应在副本中保留消息的标志和内部日期，并设置最近的标志。
If the destination mailbox does not exist, a server SHOULD return an error. It SHOULD NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the COPY if the CREATE is successful.
如果目标邮箱不存在，服务器应返回错误。它不应自动创建邮箱。除非确定无法创建目标邮箱，否则服务器必须发送响应代码“[TRYCREATE]”，作为标记的无响应文本的前缀。这会提示客户端，如果创建成功，它可以尝试执行CREATE命令并重试复制。
If the COPY command is unsuccessful for any reason, server implementations MUST restore the destination mailbox to its state before the COPY attempt.
如果复制命令因任何原因失败，服务器实现必须将目标邮箱恢复到复制尝试之前的状态。
Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
Arguments: command name command arguments
参数：命令名命令参数
Responses: untagged responses: FETCH, SEARCH
响应：未标记的响应：获取、搜索
Result: OK - UID command completed NO - UID command error BAD - command unknown or arguments invalid
结果：确定-UID命令已完成否-UID命令错误-命令未知或参数无效
The UID command has two forms. In the first form, it takes as its arguments a COPY, FETCH, or STORE command with arguments appropriate for the associated command. However, the numbers in the sequence set argument are unique identifiers instead of message sequence numbers. Sequence set ranges are permitted, but there is no guarantee that unique identifiers will be contiguous.
UID命令有两种形式。在第一种形式中，它将一个COPY、FETCH或STORE命令作为其参数，该命令的参数适合于相关命令。但是，序列集参数中的数字是唯一标识符，而不是消息序列号。允许序列集范围，但不能保证唯一标识符是连续的。
A non-existent unique identifier is ignored without any error message generated. Thus, it is possible for a UID FETCH command to return an OK without any data or a UID COPY or UID STORE to return an OK without performing any operations.
将忽略不存在的唯一标识符，而不会生成任何错误消息。因此，UID FETCH命令可以返回OK而无需任何数据，或者UID副本或UID存储可以返回OK而无需执行任何操作。
In the second form, the UID command takes a SEARCH command with SEARCH command arguments. The interpretation of the arguments is the same as with SEARCH; however, the numbers returned in a SEARCH response for a UID SEARCH command are unique identifiers instead
在第二种形式中，UID命令接受带有搜索命令参数的搜索命令。对论点的解释与搜索相同；但是，UID搜索命令的搜索响应中返回的数字是唯一标识符
of message sequence numbers. For example, the command UID SEARCH 1:100 UID 443:557 returns the unique identifiers corresponding to the intersection of two sequence sets, the message sequence number range 1:100 and the UID range 443:557.
消息序列号。例如，命令uidsearch 1:100 UID 443:557返回与两个序列集（消息序列号范围1:100和UID范围443:557）的交集相对应的唯一标识符。
Note: in the above example, the UID range 443:557 appears. The same comment about a non-existent unique identifier being ignored without any error message also applies here. Hence, even if neither UID 443 or 557 exist, this range is valid and would include an existing UID 495.
注意：在上面的示例中，显示UID范围443:557。关于在没有任何错误消息的情况下忽略不存在的唯一标识符的相同注释也适用于此处。因此，即使UID 443或557都不存在，该范围仍然有效，并且将包括现有的UID 495。
Also note that a UID range of 559:* always includes the UID of the last message in the mailbox, even if 559 is higher than any assigned UID value. This is because the contents of a range are independent of the order of the range endpoints. Thus, any UID range with * as one of the endpoints indicates at least one message (the message with the highest numbered UID), unless the mailbox is empty.
还要注意，UID范围559:*始终包括邮箱中最后一封邮件的UID，即使559高于任何分配的UID值。这是因为范围的内容与范围端点的顺序无关。因此，任何以*作为端点之一的UID范围都表示至少一封邮件（UID编号最高的邮件），除非邮箱为空。
The number after the "*" in an untagged FETCH response is always a message sequence number, not a unique identifier, even for a UID command response. However, server implementations MUST implicitly include the UID message data item as part of any FETCH response caused by a UID command, regardless of whether a UID was specified as a message data item to the FETCH.
未标记的FETCH响应中“*”后面的数字始终是消息序列号，而不是唯一标识符，即使对于UID命令响应也是如此。但是，服务器实现必须隐式地包括UID消息数据项，作为UID命令引起的任何获取响应的一部分，而不管是否将UID指定为获取的消息数据项。
Note: The rule about including the UID message data item as part of a FETCH response primarily applies to the UID FETCH and UID STORE commands, including a UID FETCH command that does not include UID as a message data item. Although it is unlikely that the other UID commands will cause an untagged FETCH, this rule applies to these commands as well.
注意：关于将UID消息数据项作为获取响应的一部分的规则主要适用于UID FETCH和UID STORE命令，包括不将UID作为消息数据项的UID FETCH命令。虽然其他UID命令不太可能导致未标记的获取，但此规则也适用于这些命令。
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
Arguments: implementation defined
参数：定义了实现
Responses: implementation defined
答复：已定义实施
Result: OK - command completed NO - failure BAD - command unknown or arguments invalid
结果：确定-命令完成无-失败错误-命令未知或参数无效
Any command prefixed with an X is an experimental command. Commands which are not part of this specification, a standard or standards-track revision of this specification, or an IESG-approved experimental protocol, MUST use the X prefix.
任何以X为前缀的命令都是实验性命令。不属于本规范、本规范的一个或多个标准跟踪修订版或IESG批准的实验协议的命令必须使用X前缀。
Any added untagged responses issued by an experimental command MUST also be prefixed with an X. Server implementations MUST NOT send any such untagged responses, unless the client requested it by issuing the associated experimental command.
由实验命令发出的任何添加的未标记响应也必须以X作为前缀。服务器实现不得发送任何此类未标记响应，除非客户端通过发出相关的实验命令来请求。
Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay
Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay
Server responses are in three forms: status responses, server data, and command continuation request. The information contained in a server response, identified by "Contents:" in the response descriptions below, is described by function, not by syntax. The precise syntax of server responses is described in the Formal Syntax section.
服务器响应有三种形式：状态响应、服务器数据和命令继续请求。服务器响应中包含的信息（在下面的响应描述中由“Contents:”标识）是按函数描述的，而不是按语法描述的。服务器响应的精确语法在“正式语法”部分中进行了描述。
The client MUST be prepared to accept any response at all times.
客户必须随时准备接受任何回复。
Status responses can be tagged or untagged. Tagged status responses indicate the completion result (OK, NO, or BAD status) of a client command, and have a tag matching the command.
状态响应可以是标记的或未标记的。标记的状态响应指示客户端命令的完成结果（OK、NO或BAD状态），并具有与命令匹配的标记。
Some status responses, and all server data, are untagged. An untagged response is indicated by the token "*" instead of a tag. Untagged status responses indicate server greeting, or server status
某些状态响应和所有服务器数据未标记。未标记的响应由标记“*”而不是标记指示。未标记的状态响应表示服务器问候语或服务器状态
that does not indicate the completion of a command (for example, an impending system shutdown alert). For historical reasons, untagged server data responses are also called "unsolicited data", although strictly speaking, only unilateral server data is truly "unsolicited".
这并不表示命令已完成（例如，系统即将关闭警报）。由于历史原因，未标记的服务器数据响应也称为“未经请求的数据”，尽管严格来说，只有单边服务器数据才是真正的“未经请求的”。
Certain server data MUST be recorded by the client when it is received; this is noted in the description of that data. Such data conveys critical information which affects the interpretation of all subsequent commands and responses (e.g., updates reflecting the creation or destruction of messages).
某些服务器数据在接收时必须由客户端记录；这在该数据的描述中有所说明。此类数据传递的关键信息影响所有后续命令和响应的解释（例如，反映消息创建或销毁的更新）。
Other server data SHOULD be recorded for later reference; if the client does not need to record the data, or if recording the data has no obvious purpose (e.g., a SEARCH response when no SEARCH command is in progress), the data SHOULD be ignored.
应记录其他服务器数据，以备日后参考；如果客户端不需要记录数据，或者如果记录数据没有明显的目的（例如，当没有搜索命令进行时的搜索响应），则应忽略数据。
An example of unilateral untagged server data occurs when the IMAP connection is in the selected state. In the selected state, the server checks the mailbox for new messages as part of command execution. Normally, this is part of the execution of every command; hence, a NOOP command suffices to check for new messages. If new messages are found, the server sends untagged EXISTS and RECENT responses reflecting the new size of the mailbox. Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages.
IMAP连接处于选定状态时，会出现单边未标记服务器数据的示例。在选定状态下，作为命令执行的一部分，服务器将检查邮箱中的新邮件。通常，这是每个命令执行的一部分；因此，NOOP命令足以检查新消息。如果找到新邮件，服务器将发送未标记的EXISTS和反映邮箱新大小的最新响应。如果另一个代理更改任何消息标志的状态或删除任何消息，则提供对同一邮箱的多个同时访问的服务器实现还应发送适当的单边未标记获取和删除响应。
Command continuation request responses use the token "+" instead of a tag. These responses are sent by the server to indicate acceptance of an incomplete client command and readiness for the remainder of the command.
命令继续请求响应使用标记“+”而不是标记。这些响应由服务器发送，表示接受不完整的客户机命令，并准备好执行命令的其余部分。
Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD can be tagged or untagged. PREAUTH and BYE are always untagged.
状态响应为OK、NO、BAD、PREAUTH和BYE。好的，不，坏的可以被标记或不标记。PREAUTH和BYE总是未标记的。
Status responses MAY include an OPTIONAL "response code". A response code consists of data inside square brackets in the form of an atom, possibly followed by a space and arguments. The response code contains additional information or status codes for client software beyond the OK/NO/BAD condition, and are defined when there is a specific action that a client can take based upon the additional information.
状态响应可能包括可选的“响应代码”。响应代码由方括号内原子形式的数据组成，后面可能跟有空格和参数。响应代码包含OK/NO/BAD条件之外的客户机软件的附加信息或状态代码，并在客户机可以根据附加信息采取特定操作时定义。
The currently defined response codes are:
当前定义的响应代码为：
ALERT
警觉的
The human-readable text contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message.
人类可读文本包含一个特殊警报，必须以引起用户注意消息的方式呈现给用户。
BADCHARSET
坏蛋
Optionally followed by a parenthesized list of charsets. A SEARCH failed because the given charset is not supported by this implementation. If the optional list of charsets is given, this lists the charsets that are supported by this implementation.
（可选）后跟带括号的字符集列表。搜索失败，因为此实现不支持给定的字符集。如果给出了可选的字符集列表，则会列出此实现支持的字符集。
CAPABILITY
能力
Followed by a list of capabilities. This can appear in the initial OK or PREAUTH response to transmit an initial capabilities list. This makes it unnecessary for a client to send a separate CAPABILITY command if it recognizes this response.
然后是一个功能列表。这可以出现在初始OK或PREAUTH响应中，以传输初始能力列表。这使得如果客户机识别出此响应，则无需发送单独的能力命令。
PARSE
作语法分析
The human-readable text represents an error in parsing the [RFC-2822] header or [MIME-IMB] headers of a message in the mailbox.
人类可读文本表示解析邮箱中邮件的[RFC-2822]头或[MIME-IMB]头时出错。
PERMANENTFLAGS
永久旗帜
Followed by a parenthesized list of flags, indicates which of the known flags the client can change permanently. Any flags that are in the FLAGS untagged response, but not the PERMANENTFLAGS list, can not be set permanently. If the client attempts to STORE a flag that is not in the PERMANENTFLAGS list, the server will either ignore the change or store the state change for the remainder of the current session only. The PERMANENTFLAGS list can also include the special flag \*, which indicates that it is possible to create new keywords by attempting to store those flags in the mailbox.
后跟括号内的标志列表，指示客户端可以永久更改哪些已知标志。无法永久设置标志未标记响应中的任何标志，但PERMANENTFLAGS列表中的标志除外。如果客户端试图存储不在PERMANENTFLAGS列表中的标志，服务器将忽略更改或仅存储当前会话其余部分的状态更改。PERMANENTFLAGS列表还可以包括特殊标志\*，这表示可以通过尝试将这些标志存储在邮箱中来创建新的关键字。
READ-ONLY
只读
The mailbox is selected read-only, or its access while selected has changed from read-write to read-only.
邮箱被选择为只读，或者其选中时的访问权限已从读写更改为只读。
READ-WRITE
读写
The mailbox is selected read-write, or its access while selected has changed from read-only to read-write.
已以读写方式选择邮箱，或者其在选择时的访问权限已从只读更改为读写。
TRYCREATE
TRYCREATE
An APPEND or COPY attempt is failing because the target mailbox does not exist (as opposed to some other reason). This is a hint to the client that the operation can succeed if the mailbox is first created by the CREATE command.
追加或复制尝试失败，因为目标邮箱不存在（与其他原因相反）。这是对客户端的一个提示，提示如果首先使用CREATE命令创建邮箱，则操作可以成功。
UIDNEXT
UIDNEXT
Followed by a decimal number, indicates the next unique identifier value. Refer to section 2.3.1.1 for more information.
后跟一个十进制数，表示下一个唯一标识符值。更多信息，请参阅第2.3.1.1节。
UIDVALIDITY
UID有效性
Followed by a decimal number, indicates the unique identifier validity value. Refer to section 2.3.1.1 for more information.
后跟十进制数，表示唯一标识符有效值。更多信息，请参阅第2.3.1.1节。
UNSEEN
看不见
Followed by a decimal number, indicates the number of the first message without the \Seen flag set.
后跟一个十进制数字，表示未设置\Seen标志的第一条消息的编号。
Additional response codes defined by particular client or server implementations SHOULD be prefixed with an "X" until they are added to a revision of this protocol. Client implementations SHOULD ignore response codes that they do not recognize.
由特定客户端或服务器实现定义的其他响应代码应以“X”作为前缀，直到它们被添加到本协议的修订版中。客户端实现应该忽略它们无法识别的响应代码。
Contents: OPTIONAL response code human-readable text
内容：可选响应代码人类可读文本
The OK response indicates an information message from the server. When tagged, it indicates successful completion of the associated command. The human-readable text MAY be presented to the user as an information message. The untagged form indicates an
OK响应表示来自服务器的信息消息。标记后，表示关联命令已成功完成。人类可读文本可以作为信息消息呈现给用户。未标记的形式表示
information-only message; the nature of the information MAY be indicated by a response code.
只提供信息的信息；信息的性质可由响应代码表示。
The untagged form is also used as one of three possible greetings at connection startup. It indicates that the connection is not yet authenticated and that a LOGIN command is needed.
在连接启动时，untaged表单也可用作三种可能的问候语之一。它表示连接尚未通过身份验证，需要登录命令。
Example: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
Example: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
Contents: OPTIONAL response code human-readable text
内容：可选响应代码人类可读文本
The NO response indicates an operational error message from the server. When tagged, it indicates unsuccessful completion of the associated command. The untagged form indicates a warning; the command can still complete successfully. The human-readable text describes the condition.
无响应表示来自服务器的操作错误消息。标记后，表示相关命令未成功完成。未标记的表单表示警告；命令仍然可以成功完成。人类可读的文本描述了这种情况。
Example: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
Example: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
Contents: OPTIONAL response code human-readable text
内容：可选响应代码人类可读文本
The BAD response indicates an error message from the server. When tagged, it reports a protocol-level error in the client's command; the tag indicates the command that caused the error. The untagged form indicates a protocol-level error for which the associated command can not be determined; it can also indicate an internal server failure. The human-readable text describes the condition.
错误响应表示来自服务器的错误消息。标记后，它会报告客户端命令中的协议级错误；标记指示导致错误的命令。未标记形式表示协议级错误，无法确定相关命令；它还可以指示内部服务器故障。人类可读的文本描述了这种情况。
Example: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
Example: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
Contents: OPTIONAL response code human-readable text
内容：可选响应代码人类可读文本
The PREAUTH response is always untagged, and is one of three possible greetings at connection startup. It indicates that the connection has already been authenticated by external means; thus no LOGIN command is needed.
预授权响应总是未标记的，并且是连接启动时三种可能的问候语之一。表示连接已经通过外部方式进行了身份验证；因此，不需要登录命令。
Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
Contents: OPTIONAL response code human-readable text
内容：可选响应代码人类可读文本
The BYE response is always untagged, and indicates that the server is about to close the connection. The human-readable text MAY be displayed to the user in a status report by the client. The BYE response is sent under one of four conditions:
BYE响应始终未标记，表示服务器即将关闭连接。用户可读文本可以由客户端在状态报告中显示给用户。BYE响应在以下四种情况之一下发送：
1) as part of a normal logout sequence. The server will close the connection after sending the tagged OK response to the LOGOUT command.
1) 作为正常注销序列的一部分。服务器将在向注销命令发送带标记的OK响应后关闭连接。
2) as a panic shutdown announcement. The server closes the connection immediately.
2) 作为紧急关闭公告。服务器会立即关闭连接。
3) as an announcement of an inactivity autologout. The server closes the connection immediately.
3) 作为一个不活动的声明。服务器会立即关闭连接。
4) as one of three possible greetings at connection startup, indicating that the server is not willing to accept a connection from this client. The server closes the connection immediately.
4) 作为连接启动时三种可能的问候语之一，表示服务器不愿意接受来自此客户端的连接。服务器会立即关闭连接。
The difference between a BYE that occurs as part of a normal LOGOUT sequence (the first case) and a BYE that occurs because of a failure (the other three cases) is that the connection closes immediately in the failure case. In all cases the client SHOULD continue to read response data from the server until the connection is closed; this will ensure that any pending untagged or completion responses are read and processed.
作为正常注销序列的一部分出现的BYE（第一种情况）与由于故障而出现的BYE（其他三种情况）之间的区别在于，在故障情况下，连接会立即关闭。在所有情况下，客户端应继续从服务器读取响应数据，直到连接关闭；这将确保读取和处理任何挂起的未标记或完成响应。
Example: S: * BYE Autologout; idle for too long
Example: S: * BYE Autologout; idle for too long
These responses are always untagged. This is how server and mailbox status data are transmitted from the server to the client. Many of these responses typically result from a command with the same name.
这些响应总是未标记的。这是服务器和邮箱状态数据从服务器传输到客户端的方式。其中许多响应通常由同名命令产生。
Contents: capability listing
内容：能力清单
The CAPABILITY response occurs as a result of a CAPABILITY command. The capability listing contains a space-separated listing of capability names that the server supports. The capability listing MUST include the atom "IMAP4rev1".
能力响应是能力命令的结果。功能列表包含服务器支持的功能名称的空格分隔列表。功能列表必须包括原子“IMAP4rev1”。
In addition, client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. See the Security Considerations section for important information.
此外，客户机和服务器实现必须实现STARTTLS、LOGINDISABLED和AUTH=PLAIN（在[IMAP-TLS]中描述）功能。有关重要信息，请参阅安全注意事项部分。
A capability name which begins with "AUTH=" indicates that the server supports that particular authentication mechanism.
以“AUTH=”开头的功能名称表示服务器支持该特定身份验证机制。
The LOGINDISABLED capability indicates that the LOGIN command is disabled, and that the server will respond with a tagged NO response to any attempt to use the LOGIN command even if the user name and password are valid. An IMAP client MUST NOT issue the LOGIN command if the server advertises the LOGINDISABLED capability.
LOGINDISABLED功能表示LOGIN命令已禁用，并且服务器将以标记的NO response响应任何使用LOGIN命令的尝试，即使用户名和密码有效。如果服务器播发LOGINDISABLED功能，IMAP客户端不得发出LOGIN命令。
Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev1 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability.
其他功能名称表示服务器支持对IMAP4rev1协议的扩展、修订或修订。在客户端发出使用关联功能的命令之前，服务器响应必须符合此文档。
Capability names MUST either begin with "X" or be standard or standards-track IMAP4rev1 extensions, revisions, or amendments registered with IANA. A server MUST NOT offer unregistered or
功能名称必须以“X”开头，或者是标准名称，或者是IANA注册的IMAP4rev1扩展、修订或修订版的标准名称。服务器不能提供未注册或未注册的服务
non-standard capability names, unless such names are prefixed with an "X".
非标准功能名称，除非此类名称的前缀为“X”。
Client implementations SHOULD NOT require any capability name other than "IMAP4rev1", and MUST ignore any unknown capability names.
客户机实现不需要“IMAP4rev1”以外的任何功能名称，并且必须忽略任何未知的功能名称。
A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
服务器可以通过在初始预授权或OK响应中使用功能响应代码，并通过在标记的OK响应中发送更新的功能响应代码作为成功身份验证的一部分，自动发送功能。如果客户机能够识别这些自动功能，则无需发送单独的功能命令。
Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
Contents: name attributes hierarchy delimiter name
内容：名称属性层次结构分隔符名称
The LIST response occurs as a result of a LIST command. It returns a single name that matches the LIST specification. There can be multiple LIST responses for a single LIST command.
LIST响应是LIST命令的结果。它返回一个与列表规范匹配的名称。一个LIST命令可以有多个LIST响应。
Four name attributes are defined:
定义了四个名称属性：
\Noinferiors It is not possible for any child levels of hierarchy to exist under this name; no child levels exist now and none can be created in the future.
\n在此名称下不可能存在任何层次结构的子级；现在不存在子级别，将来也不能创建任何子级别。
\Noselect It is not possible to use this name as a selectable mailbox.
\Noselect无法将此名称用作可选邮箱。
\Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected.
\已标记邮箱已被服务器标记为“有趣”；邮箱可能包含自上次选择邮箱以来添加的邮件。
\Unmarked The mailbox does not contain any additional messages since the last time the mailbox was selected.
\未标记自上次选择邮箱以来，邮箱不包含任何其他邮件。
If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked.
如果服务器无法确定邮箱是否“有趣”，或者名称是\n选择名称，则服务器不应发送\Marked或\Unmarked。
The hierarchy delimiter is a character used to delimit levels of hierarchy in a mailbox name. A client can use it to create child mailboxes, and to search higher or lower levels of naming hierarchy. All children of a top-level hierarchy node MUST use the same separator character. A NIL hierarchy delimiter means that no hierarchy exists; the name is a "flat" name.
层次结构分隔符是用于分隔邮箱名称中层次结构级别的字符。客户端可以使用它创建子邮箱，并搜索更高或更低级别的命名层次结构。顶级层次结构节点的所有子节点必须使用相同的分隔符。NIL层次分隔符表示不存在层次；该名称是一个“平面”名称。
The name represents an unambiguous left-to-right hierarchy, and MUST be valid for use as a reference in LIST and LSUB commands. Unless \Noselect is indicated, the name MUST also be valid as an argument for commands, such as SELECT, that accept mailbox names.
该名称表示从左到右的明确层次结构，并且必须有效，才能用作LIST和LSUB命令中的引用。除非指示\n选择，否则该名称还必须作为接受邮箱名称的命令（如SELECT）的参数有效。
Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Contents: name attributes hierarchy delimiter name
内容：名称属性层次结构分隔符名称
The LSUB response occurs as a result of an LSUB command. It returns a single name that matches the LSUB specification. There can be multiple LSUB responses for a single LSUB command. The data is identical in format to the LIST response.
LSUB响应是LSUB命令的结果。它返回一个与LSUB规范匹配的名称。一个LSUB命令可以有多个LSUB响应。数据的格式与列表响应相同。
Example: S: * LSUB () "." #news.comp.mail.misc
Example: S: * LSUB () "." #news.comp.mail.misc
Contents: name status parenthesized list
目录：名称状态括号内的列表
The STATUS response occurs as a result of an STATUS command. It returns the mailbox name that matches the STATUS specification and the requested mailbox status information.
状态响应是STATUS命令的结果。它返回与状态规范和请求的邮箱状态信息匹配的邮箱名称。
Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
Contents: zero or more numbers
内容：零个或多个数字
The SEARCH response occurs as a result of a SEARCH or UID SEARCH command. The number(s) refer to those messages that match the search criteria. For SEARCH, these are message sequence numbers; for UID SEARCH, these are unique identifiers. Each number is delimited by a space.
搜索响应是搜索或UID搜索命令的结果。编号指的是与搜索条件匹配的邮件。对于搜索，这些是消息序列号；对于UID搜索，这些是唯一标识符。每个数字由空格分隔。
Example: S: * SEARCH 2 3 6
Example: S: * SEARCH 2 3 6
Contents: flag parenthesized list
目录：带括号的标记列表
The FLAGS response occurs as a result of a SELECT or EXAMINE command. The flag parenthesized list identifies the flags (at a minimum, the system-defined flags) that are applicable for this mailbox. Flags other than the system flags can also exist, depending on server implementation.
标志响应是选择或检查命令的结果。括号内的标志列表标识适用于此邮箱的标志（至少是系统定义的标志）。也可以存在系统标志以外的标志，具体取决于服务器实现。
The update from the FLAGS response MUST be recorded by the client.
客户端必须记录来自标志响应的更新。
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
These responses are always untagged. This is how changes in the size of the mailbox are transmitted from the server to the client. Immediately following the "*" token is a number that represents a message count.
这些响应总是未标记的。这就是邮箱大小的更改如何从服务器传输到客户端。紧跟在“*”标记后面的是一个表示消息计数的数字。
Contents: none
内容：无
The EXISTS response reports the number of messages in the mailbox. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).
EXISTS响应报告邮箱中的邮件数。此响应是SELECT或EXAMINE命令的结果，以及邮箱大小发生变化（例如，新邮件）时发生的。
The update from the EXISTS response MUST be recorded by the client.
客户端必须记录来自EXISTS响应的更新。
Example: S: * 23 EXISTS
Example: S: * 23 EXISTS
Contents: none
内容：无
The RECENT response reports the number of messages with the \Recent flag set. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).
最近的响应报告设置了\RECENT标志的消息数。此响应是SELECT或EXAMINE命令的结果，以及邮箱大小发生变化（例如，新邮件）时发生的。
Note: It is not guaranteed that the message sequence numbers of recent messages will be a contiguous range of the highest n messages in the mailbox (where n is the value reported by the RECENT response). Examples of situations in which this is not the case are: multiple clients having the same mailbox open (the first session to be notified will see it as recent, others will probably see it as non-recent), and when the mailbox is re-ordered by a non-IMAP agent.
注意：不能保证最近消息的消息序列号将是邮箱中最大n条消息的连续范围（其中n是最近响应报告的值）。情况并非如此的示例包括：打开同一邮箱的多个客户端（要通知的第一个会话会将其视为最近的，其他会话可能会将其视为非最近的），以及由非IMAP代理重新排序邮箱时。
The only reliable way to identify recent messages is to look at message flags to see which have the \Recent flag set, or to do a SEARCH RECENT.
识别最近的消息的唯一可靠方法是查看消息标志以查看哪个设置了\recent标志，或者执行最近的搜索。
The update from the RECENT response MUST be recorded by the client.
客户端必须记录最近响应的更新。
Example: S: * 5 RECENT
Example: S: * 5 RECENT
These responses are always untagged. This is how message data are transmitted from the server to the client, often as a result of a command with the same name. Immediately following the "*" token is a number that represents a message sequence number.
这些响应总是未标记的。这就是消息数据从服务器传输到客户机的方式，通常是由于具有相同名称的命令。紧跟在“*”标记后面的是一个表示消息序列号的数字。
Contents: none
内容：无
The EXPUNGE response reports that the specified message sequence number has been permanently removed from the mailbox. The message sequence number for each successive message in the mailbox is immediately decremented by 1, and this decrement is reflected in message sequence numbers in subsequent responses (including other untagged EXPUNGE responses).
“删除”响应报告指定的邮件序列号已从邮箱中永久删除。邮箱中每个连续邮件的邮件序列号立即递减1，并且此递减将反映在后续响应（包括其他未标记的删除响应）中的邮件序列号中。
The EXPUNGE response also decrements the number of messages in the mailbox; it is not necessary to send an EXISTS response with the new value.
“删除”响应也会减少邮箱中的邮件数；无需使用新值发送EXISTS响应。
As a result of the immediate decrement rule, message sequence numbers that appear in a set of successive EXPUNGE responses depend upon whether the messages are removed starting from lower numbers to higher numbers, or from higher numbers to lower numbers. For example, if the last 5 messages in a 9-message mailbox are expunged, a "lower to higher" server will send five untagged EXPUNGE responses for message sequence number 5, whereas a "higher to lower server" will send successive untagged EXPUNGE responses for message sequence numbers 9, 8, 7, 6, and 5.
根据立即递减规则，出现在一组连续删除响应中的消息序列号取决于消息是从较低的数字到较高的数字，还是从较高的数字到较低的数字删除。例如，如果删除9邮件邮箱中的最后5封邮件，“从低到高”服务器将为邮件序列号5发送五个未标记的删除响应，而“从高到低”服务器将为邮件序列号9、8、7、6和5发送连续的未标记删除响应。
An EXPUNGE response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. A command is not "in progress" until the complete command has been received; in particular, a command is not "in progress" during the negotiation of command continuation.
在未执行任何命令时，或在响应FETCH、STORE或SEARCH命令时，不得发送EXPUNGE响应。此规则对于防止客户端和服务器之间的消息序列号同步丢失是必需的。在收到完整的命令之前，命令不会“进行中”；特别是，在命令延续的协商过程中，命令没有“进行中”。
Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent during a UID command.
注意：UID FETCH、UID STORE和UID SEARCH是与FETCH、STORE和SEARCH不同的命令。在UID命令期间可能会发送删除响应。
The update from the EXPUNGE response MUST be recorded by the client.
客户端必须记录删除响应中的更新。
Example: S: * 44 EXPUNGE
Example: S: * 44 EXPUNGE
Contents: message data
内容：消息数据
The FETCH response returns data about a message to the client. The data are pairs of data item names and their values in parentheses. This response occurs as the result of a FETCH or STORE command, as well as by unilateral server decision (e.g., flag updates).
FETCH响应将有关消息的数据返回给客户端。数据是成对的数据项名称及其在括号中的值。此响应是FETCH或STORE命令的结果，以及单边服务器决策（例如，标志更新）的结果。
The current data items are:
当前数据项包括：
BODY A form of BODYSTRUCTURE without extension data.
BODY没有扩展数据的BODYSTRUCTURE的一种形式。
BODY[<section>]<<origin octet>> A string expressing the body contents of the specified section. The string SHOULD be interpreted by the client according to the content transfer encoding, body type, and subtype.
BODY[<section>]<<origin octet>>表示指定节的正文内容的字符串。客户端应根据内容传输编码、正文类型和子类型解释字符串。
If the origin octet is specified, this string is a substring of the entire body contents, starting at that origin octet. This means that BODY[]<0> MAY be truncated, but BODY[] is NEVER truncated.
如果指定了起始八位字节，则该字符串是整个正文内容的子字符串，从该起始八位字节开始。这意味着BODY[]<0>可能会被截断，但BODY[]永远不会被截断。
Note: The origin octet facility MUST NOT be used by a server in a FETCH response unless the client specifically requested it by means of a FETCH of a BODY[<section>]<<partial>> data item.
注意：服务器不得在获取响应中使用源八位字节功能，除非客户端通过获取正文[<section>]<<partial>>数据项专门请求它。
8-bit textual data is permitted if a [CHARSET] identifier is part of the body parameter parenthesized list for this section. Note that headers (part specifiers HEADER or MIME, or the header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit characters are not permitted in headers. Note also that the [RFC-2822] delimiting blank line between the header and the body is not affected by header line subsetting; the blank line is always included as part of header data, except in the case of a message which has no body and no blank line.
如果[CHARSET]标识符是本节主体参数括号列表的一部分，则允许使用8位文本数据。注意，头（部分说明符头或MIME，或消息/RFC822部分的头部分）必须为7位；标题中不允许使用8位字符。还要注意，标题和正文之间的[RFC-2822]定界空行不受标题行子集的影响；除了没有正文和空行的消息之外，空行总是作为头数据的一部分被包括在内。
Non-textual data such as binary data MUST be transfer encoded into a textual form, such as BASE64, prior to being sent to the client. To derive the original binary data, the client MUST decode the transfer encoded string.
非文本数据（如二进制数据）在发送到客户机之前必须传输编码为文本形式（如BASE64）。要派生原始二进制数据，客户端必须对传输编码字符串进行解码。
BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] body structure of a message. This is computed by the server by parsing the [MIME-IMB] header fields, defaulting various fields as necessary.
BODYSTRUCTURE括号内的列表，用于描述消息的[MIME-IMB]正文结构。这由服务器通过解析[MIME-IMB]头字段来计算，并根据需要对各种字段进行默认设置。
For example, a simple text message of 48 lines and 2279 octets can have a body structure of: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
例如，48行2279个八位字节的简单文本消息的正文结构为：（“文本”“普通”（“字符集”“US-ASCII”）NIL NIL“7BIT”2279 48）
Multiple parts are indicated by parenthesis nesting. Instead of a body type as the first element of the parenthesized list, there is a sequence of one or more nested body structures. The second element of the parenthesized list is the multipart subtype (mixed, digest, parallel, alternative, etc.).
多个零件由括号嵌套表示。括号列表的第一个元素不是主体类型，而是一个或多个嵌套主体结构的序列。括号内列表的第二个元素是多部分子类型（混合、摘要、并行、替代等）。
For example, a two part message consisting of a text and a BASE64-encoded text attachment can have a body structure of: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED")
例如，由文本和BASE64编码文本附件组成的两部分消息的正文结构可以是：（（“文本”“普通”（“字符集”“US-ASCII”）NIL NIL“7BIT”1152 23）（“文本”“普通”（“字符集”“US-ASCII”“名称”“cc.diff”）”<960723163407。20117h@cac.washington.edu>“编译器差异”“BASE64”4554 73“混合”）
Extension data follows the multipart subtype. Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order. The extension data of a multipart body part are in the following order:
扩展数据遵循多部分子类型。扩展数据永远不会随BODY fetch一起返回，但可以随BODYSTRUCTURE fetch一起返回。扩展数据（如果存在）必须按照定义的顺序。多部件主体零件的扩展数据按以下顺序排列：
body parameter parenthesized list A parenthesized list of attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where "bar" is the value of "foo", and "rag" is the value of "baz"] as defined in [MIME-IMB].
body parameter圆括号列表属性/值对的圆括号列表[例如，（“foo”“bar”“baz”“rag”），其中“bar”是“foo”的值，“rag”是[MIME-IMB]中定义的“baz”的值]。
body disposition A parenthesized list, consisting of a disposition type string, followed by a parenthesized list of disposition attribute/value pairs as defined in [DISPOSITION].
正文处置一个括号内的列表，由处置类型字符串组成，后跟[处置]中定义的处置属性/值对的括号内列表。
body language A string or parenthesized list giving the body language value as defined in [LANGUAGE-TAGS].
肢体语言给出[language-TAGS]中定义的肢体语言值的字符串或括号列表。
body location A string list giving the body content URI as defined in [LOCATION].
body location提供[location]中定义的正文内容URI的字符串列表。
Any following extension data are not yet defined in this version of the protocol. Such extension data can consist of zero or more NILs, strings, numbers, or potentially nested parenthesized lists of such data. Client implementations that do a BODYSTRUCTURE fetch MUST be prepared to accept such extension data. Server implementations MUST NOT send such extension data until it has been defined by a revision of this protocol.
此版本的协议中尚未定义以下任何扩展数据。此类扩展数据可以由零个或多个零、字符串、数字或此类数据的嵌套括号列表组成。执行BODYSTRUCTURE获取的客户端实现必须准备好接受此类扩展数据。服务器实现不得发送此类扩展数据，直到此协议的修订版对其进行了定义。
The basic fields of a non-multipart body part are in the following order:
非多部分主体零件的基本字段按以下顺序排列：
body type A string giving the content media type name as defined in [MIME-IMB].
正文类型给出[MIME-IMB]中定义的内容媒体类型名称的字符串。
body subtype A string giving the content subtype name as defined in [MIME-IMB].
body subtype提供[MIME-IMB]中定义的内容子类型名称的字符串。
body parameter parenthesized list A parenthesized list of attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where "bar" is the value of "foo" and "rag" is the value of "baz"] as defined in [MIME-IMB].
正文参数括号内列表一个括号内的属性/值对列表[例如，（“foo”“bar”“baz”“rag”），其中“bar”是“foo”的值，“rag”是“baz”的值]，如[MIME-IMB]中所定义。
body id A string giving the content id as defined in [MIME-IMB].
body id一个字符串，给出[MIME-IMB]中定义的内容id。
body description A string giving the content description as defined in [MIME-IMB].
正文描述给出[MIME-IMB]中定义的内容描述的字符串。
body encoding A string giving the content transfer encoding as defined in [MIME-IMB].
正文编码给出[MIME-IMB]中定义的内容传输编码的字符串。
body size A number giving the size of the body in octets. Note that this size is the size in its transfer encoding and not the resulting size after any decoding.
身体大小以八位字节表示身体大小的数字。请注意，此大小是其传输编码中的大小，而不是任何解码后的结果大小。
A body type of type MESSAGE and subtype RFC822 contains, immediately after the basic fields, the envelope structure, body structure, and size in text lines of the encapsulated message.
消息类型和子类型RFC822的正文类型紧跟在基本字段之后，包含封装消息的信封结构、正文结构和文本行大小。
A body type of type TEXT contains, immediately after the basic fields, the size of the body in text lines. Note that this size is the size in its content transfer encoding and not the resulting size after any decoding.
文本类型的主体类型在基本字段之后立即包含文本行中的主体大小。请注意，此大小是其内容传输编码中的大小，而不是任何解码后的结果大小。
Extension data follows the basic fields and the type-specific fields listed above. Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order.
扩展数据遵循上面列出的基本字段和特定于类型的字段。扩展数据永远不会随BODY fetch一起返回，但可以随BODYSTRUCTURE fetch一起返回。扩展数据（如果存在）必须按照定义的顺序。
The extension data of a non-multipart body part are in the following order:
非多部分主体零件的扩展数据的顺序如下：
body MD5 A string giving the body MD5 value as defined in [MD5].
body MD5一个字符串，给出[MD5]中定义的body MD5值。
body disposition A parenthesized list with the same content and function as the body disposition for a multipart body part.
body disposition一个括号内的列表，其内容和功能与多部分车身零件的车身配置相同。
body language A string or parenthesized list giving the body language value as defined in [LANGUAGE-TAGS].
肢体语言给出[language-TAGS]中定义的肢体语言值的字符串或括号列表。
body location A string list giving the body content URI as defined in [LOCATION].
body location提供[location]中定义的正文内容URI的字符串列表。
Any following extension data are not yet defined in this version of the protocol, and would be as described above under multipart extension data.
以下任何扩展数据尚未在本版本的协议中定义，将如上文“多部分扩展数据”中所述。
ENVELOPE A parenthesized list that describes the envelope structure of a message. This is computed by the server by parsing the [RFC-2822] header into the component parts, defaulting various fields as necessary.
信封一个括号内的列表，描述消息的信封结构。这是由服务器通过将[RFC-2822]头解析为组件部分来计算的，并根据需要对各个字段进行默认设置。
The fields of the envelope structure are in the following order: date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to, and message-id. The date, subject, in-reply-to, and message-id fields are strings. The from, sender, reply-to, to, cc, and bcc fields are parenthesized lists of address structures.
信封结构的字段按以下顺序排列：日期、主题、发件人、发件人、回复、收件人、抄送、密件抄送、回复中的收件人和邮件id。日期、主题、回复中的收件人和邮件id字段为字符串。“发件人”、“答复”、“收件人”、“抄送”和“密件抄送”字段是带括号的地址结构列表。
An address structure is a parenthesized list that describes an electronic mail address. The fields of an address structure are in the following order: personal name, [SMTP] at-domain-list (source route), mailbox name, and host name.
地址结构是一个括号内的列表，用于描述电子邮件地址。地址结构的字段按以下顺序排列：个人名称、[SMTP]位于域列表（源路由）、邮箱名称和主机名。
[RFC-2822] group syntax is indicated by a special form of address structure in which the host name field is NIL. If the mailbox name field is also NIL, this is an end of group marker (semi-colon in RFC 822 syntax). If the mailbox name field is non-NIL, this is a start of group marker, and the mailbox name field holds the group name phrase.
[RFC-2822]组语法由一种特殊形式的地址结构表示，其中主机名字段为NIL。如果邮箱名称字段也是NIL，则这是组结束标记（RFC 822语法中的分号）。如果邮箱名称字段为非NIL，则这是组标记的开始，邮箱名称字段包含组名称短语。
If the Date, Subject, In-Reply-To, and Message-ID header lines are absent in the [RFC-2822] header, the corresponding member of the envelope is NIL; if these header lines are present but empty the corresponding member of the envelope is the empty string.
如果[RFC-2822]标题中没有日期、主题、回复和消息ID标题行，则信封的相应成员为零；如果这些标题行存在但为空，则信封的相应成员为空字符串。
Note: some servers may return a NIL envelope member in the "present but empty" case. Clients SHOULD treat NIL and empty string as identical.
注意：在“存在但为空”的情况下，某些服务器可能会返回NIL信封成员。客户端应将NIL和空字符串视为相同的。
Note: [RFC-2822] requires that all messages have a valid Date header. Therefore, the date member in the envelope can not be NIL or the empty string.
注意：[RFC-2822]要求所有邮件都有有效的日期标头。因此，信封中的日期成员不能为NIL或空字符串。
Note: [RFC-2822] requires that the In-Reply-To and Message-ID headers, if present, have non-empty content. Therefore, the in-reply-to and message-id members in the envelope can not be the empty string.
注意：[RFC-2822]要求回复邮件和邮件ID标题（如果存在）包含非空内容。因此，信封中的in reply to和message id成员不能是空字符串。
If the From, To, cc, and bcc header lines are absent in the [RFC-2822] header, or are present but empty, the corresponding member of the envelope is NIL.
如果[RFC-2822]标头中没有From、To、cc和bcc标头行，或者存在但为空，则信封的相应成员为NIL。
If the Sender or Reply-To lines are absent in the [RFC-2822] header, or are present but empty, the server sets the corresponding member of the envelope to be the same value as the from member (the client is not expected to know to do this).
如果发送方或回复行在[RFC-2822]标头中不存在，或者存在但为空，则服务器会将信封的相应成员设置为与发件人成员相同的值（客户端不希望知道这样做）。
Note: [RFC-2822] requires that all messages have a valid From header. Therefore, the from, sender, and reply-to members in the envelope can not be NIL.
注意：[RFC-2822]要求所有邮件都具有有效的发件人标头。因此，信封中的发件人、发件人和回复成员不能为零。
FLAGS A parenthesized list of flags that are set for this message.
标志为此消息设置的带括号的标志列表。
INTERNALDATE A string representing the internal date of the message.
INTERNALDATE表示消息的内部日期的字符串。
RFC822 Equivalent to BODY[].
RFC822相当于主体[]。
RFC822.HEADER Equivalent to BODY[HEADER]. Note that this did not result in \Seen being set, because RFC822.HEADER response data occurs as a result of a FETCH of RFC822.HEADER. BODY[HEADER] response data occurs as a result of a FETCH of BODY[HEADER] (which sets \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
RFC822.1相当于正文[标题]的标题。请注意，这并没有导致设置\Seen，因为RFC822.HEADER响应数据是获取RFC822.HEADER的结果。BODY[HEADER]响应数据是在获取BODY[HEADER]（设置\SEED）或BODY.PEEK[HEADER]（未设置\SEED）时发生的。
RFC822.SIZE A number expressing the [RFC-2822] size of the message.
RFC822.SIZE表示消息[RFC-2822]大小的数字。
RFC822.TEXT Equivalent to BODY[TEXT].
RFC822.TEXT相当于BODY[TEXT]。
UID A number expressing the unique identifier of the message.
UID表示消息唯一标识符的数字。
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
The command continuation request response is indicated by a "+" token instead of a tag. This form of response indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text.
命令继续请求响应由“+”标记而不是标记指示。这种形式的响应表示服务器已准备好接受来自客户端的命令的继续。此响应的其余部分是一行文本。
This response is used in the AUTHENTICATE command to transmit server data to the client, and request additional client data. This response is also used if an argument to any command is a literal.
此响应在AUTHENTICATE命令中用于将服务器数据传输到客户端，并请求其他客户端数据。如果任何命令的参数是文本，也会使用此响应。
The client is not permitted to send the octets of the literal unless the server indicates that it is expected. This permits the server to process commands and reject errors on a line-by-line basis. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments, the literal octets are followed by a space and those arguments.
不允许客户端发送文本的八位字节，除非服务器表明需要。这允许服务器逐行处理命令和拒绝错误。命令的其余部分（包括终止命令的CRLF）位于文本的八位字节之后。如果有任何其他命令参数，则文字八位字节后面会有一个空格和这些参数。
Example: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
Example: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
The following is a transcript of an IMAP4rev1 connection. A long line in this sample is broken for editorial clarity.
以下是IMAP4rev1连接的副本。为了编辑清晰起见，此示例中的一条长线被打断。
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
In the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule which is listed earlier MUST take priority. For example, "\Seen" when parsed as a flag is the \Seen flag name and not a flag-extension, even though "\Seen" can be parsed as a flag-extension. Some, but not all, instances of this rule are noted below.
如果备用规则或可选规则中较后的规则与较早的规则重叠，则较早列出的规则必须优先。例如，解析为标志时，“\Seen”是\Seen标志名称，而不是标志扩展名，即使“\Seen”可以解析为标志扩展名。下面列出了该规则的一些（但不是全部）实例。
Note: [ABNF] rules MUST be followed strictly; in particular:
注：[ABNF]必须严格遵守规则；特别地：
(1) 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.
(1) 除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
(2) In all cases, SP refers to exactly one space. It is NOT permitted to substitute TAB, insert additional spaces, or otherwise treat SP as being equivalent to LWSP.
(2) 在所有情况下，SP仅指一个空间。不允许替换制表符、插入额外空格或以其他方式将SP视为等同于LWSP。
(3) The ASCII NUL character, %x00, MUST NOT be used at any time.
(3) 任何时候都不得使用ASCII NUL字符%x00。
address = "(" addr-name SP addr-adl SP addr-mailbox SP addr-host ")"
address=“（“地址名称SP地址adl SP地址邮箱SP地址主机”）”
addr-adl = nstring ; Holds route from [RFC-2822] route-addr if ; non-NIL
地址adl=nstring；保存来自[RFC-2822]路由地址的路由（如果有）；非零
addr-host = nstring ; NIL indicates [RFC-2822] group syntax. ; Otherwise, holds [RFC-2822] domain name
addr host=nstring；NIL表示[RFC-2822]组语法；否则，持有[RFC-2822]域名
addr-mailbox = nstring
; NIL indicates end of [RFC-2822] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822] group name.
; Otherwise, holds [RFC-2822] local-part
; after removing [RFC-2822] quoting
addr-mailbox = nstring
; NIL indicates end of [RFC-2822] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822] group name.
; Otherwise, holds [RFC-2822] local-part
; after removing [RFC-2822] quoting
addr-name = nstring ; If non-NIL, holds phrase from [RFC-2822] ; mailbox after removing [RFC-2822] quoting
地址名称=nstring；如果非NIL，则保留[RFC-2822]中的短语；删除[RFC-2822]报价后的邮箱
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal
append=“append”SP邮箱[SP标志列表][SP日期时间]SP文字
astring = 1*ASTRING-CHAR / string
astring = 1*ASTRING-CHAR / string
ASTRING-CHAR = ATOM-CHAR / resp-specials
ASTRING-CHAR = ATOM-CHAR / resp-specials
atom = 1*ATOM-CHAR
atom = 1*ATOM-CHAR
ATOM-CHAR = <any CHAR except atom-specials>
ATOM-CHAR = <any CHAR except atom-specials>
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
authenticate=“authenticate”SP身份验证类型*（CRLF base64）
auth-type = atom ; Defined by [SASL]
认证类型=原子；由[SASL]定义
base64 = *(4base64-char) [base64-terminal]
base64 = *(4base64-char) [base64-terminal]
base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive
base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
base64-terminal = (2base64-char "==") / (3base64-char "=")
body = "(" (body-type-1part / body-type-mpart) ")"
body = "(" (body-type-1part / body-type-mpart) ")"
body-extension = nstring / number /
"(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.
body-extension = nstring / number /
"(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
body-ext-1part=body-fld-md5[SP body fld dsp[SP body fld lang[SP body fld loc*（SP body extension）]；不能在不可扩展的情况下返回；“身体”取回
body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
阀体外部mpart=阀体fld参数[SP阀体fld dsp[SP阀体fld lang[SP阀体fld loc*（SP阀体扩展）]]；不能在不可扩展的情况下返回；“身体”取回
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP body-fld-enc SP body-fld-octets
主体字段=主体fld参数SP主体fld id SP主体fld desc SP主体fld enc SP主体fld八位字节
body-fld-desc = nstring
body-fld-desc = nstring
body-fld-dsp = "(" string SP body-fld-param ")" / nil
body-fld-dsp = "(" string SP body-fld-param ")" / nil
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") DQUOTE) / string
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") DQUOTE) / string
body-fld-id = nstring
body-fld-id = nstring
body-fld-lang = nstring / "(" string *(SP string) ")"
body-fld-lang = nstring / "(" string *(SP string) ")"
body-fld-loc = nstring
body-fld-loc = nstring
body-fld-lines = number
body-fld-lines = number
body-fld-md5 = nstring
body-fld-md5 = nstring
body-fld-octets = number
body-fld-octets = number
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]
body-type-basic = media-basic SP body-fields ; MESSAGE subtype MUST NOT be "RFC822"
主体类型基本=媒体基本SP主体字段；消息子类型不得为“RFC822”
body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart]
body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart]
body-type-msg = media-message SP body-fields SP envelope SP body SP body-fld-lines
body type msg=媒体消息SP body字段SP信封SP body SP body fld行
body-type-text = media-text SP body-fields SP body-fld-lines
正文类型文本=媒体文本SP正文字段SP正文fld行
capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be
; registered with IANA as standard or
; standards-track
capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be
; registered with IANA as standard or
; standards-track
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability.
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability.
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state
command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states
command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state
command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state
command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
uid / search
; Valid only when in Selected state
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
uid / search
; Valid only when in Selected state
continue-req = "+" SP (resp-text / base64) CRLF
continue-req = "+" SP (resp-text / base64) CRLF
copy = "COPY" SP sequence-set SP mailbox
copy=“copy”SP序列设置SP邮箱
create = "CREATE" SP mailbox ; Use of INBOX gives a NO error
create=“create”SP邮箱；使用收件箱不会产生错误
date = date-text / DQUOTE date-text DQUOTE
date = date-text / DQUOTE date-text DQUOTE
date-day = 1*2DIGIT
; Day of month
date-day = 1*2DIGIT
; Day of month
date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day
date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date-text = date-day "-" date-month "-" date-year
日期文本=日期日“-”日期月“-”日期年
date-year = 4DIGIT
date-year = 4DIGIT
date-time = DQUOTE date-day-fixed "-" date-month "-" date-year SP time SP zone DQUOTE
日期时间=DQUOTE固定日期日“-”日期月“-”日期年SP时区DQUOTE
delete = "DELETE" SP mailbox ; Use of INBOX gives a NO error
delete=“delete”SP邮箱；使用收件箱不会产生错误
digit-nz = %x31-39
; 1-9
digit-nz = %x31-39
; 1-9
envelope = "(" env-date SP env-subject SP env-from SP env-sender SP env-reply-to SP env-to SP env-cc SP env-bcc SP env-in-reply-to SP env-message-id ")"
envelope=“（“环境日期SP env subject SP env from SP env sender SP env reply to SP env to SP env cc SP env bcc SP env in reply to SP env message id”）”
env-bcc = "(" 1*address ")" / nil
env-bcc = "(" 1*address ")" / nil
env-cc = "(" 1*address ")" / nil
env-cc = "(" 1*address ")" / nil
env-date = nstring
env-date = nstring
env-from = "(" 1*address ")" / nil
env-from = "(" 1*address ")" / nil
env-in-reply-to = nstring
env-in-reply-to = nstring
env-message-id = nstring
env-message-id = nstring
env-reply-to = "(" 1*address ")" / nil
env-reply-to = "(" 1*address ")" / nil
env-sender = "(" 1*address ")" / nil
env-sender = "(" 1*address ")" / nil
env-subject = nstring
env-subject = nstring
env-to = "(" 1*address ")" / nil
env-to = "(" 1*address ")" / nil
examine = "EXAMINE" SP mailbox
检查=“检查”SP邮箱
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")")
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")")
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" section ["<" number "." nz-number ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"]
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" section ["<" number "." nz-number ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"]
flag = "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent"
flag = "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent"
flag-extension = "\" atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.
flag-extension = "\" atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.
flag-fetch = flag / "\Recent"
flag fetch=flag/“\Recent”
flag-keyword = atom
flag-keyword = atom
flag-list = "(" [flag *(SP flag)] ")"
flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*"
flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring
header-fld-name = astring
header-list = "(" header-fld-name *(SP header-fld-name) ")"
header-list = "(" header-fld-name *(SP header-fld-name) ")"
list = "LIST" SP mailbox SP list-mailbox
list=“list”SP邮箱SP列表邮箱
list-mailbox = 1*list-char / string
list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials
list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*"
list-wildcards = "%" / "*"
literal = "{" number "}" CRLF *CHAR8
; Number represents the number of CHAR8s
literal = "{" number "}" CRLF *CHAR8
; Number represents the number of CHAR8s
login = "LOGIN" SP userid SP password
login=“login”SP userid SP password
lsub = "LSUB" SP mailbox SP list-mailbox
lsub=“lsub”SP邮箱SP列表邮箱
mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.
mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT"
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT"
mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
邮箱列表=“（“[mbx列表标志]”）SP（DQUOTE QUOTE-CHAR DQUOTE/nil）SP邮箱
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)
mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response
mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
media-subtype
; Defined in [MIME-IMT]
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
media-subtype
; Defined in [MIME-IMT]
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE ; Defined in [MIME-IMT]
媒体消息=DQUOTE“消息”DQUOTE SP DQUOTE“RFC822”DQUOTE；在[MIME-IMT]中定义
media-subtype = string ; Defined in [MIME-IMT]
媒体子类型=字符串；在[MIME-IMT]中定义
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype ; Defined in [MIME-IMT]
媒体文本=DQUOTE“text”DQUOTE SP媒体子类型；在[MIME-IMT]中定义
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
消息数据=新西兰编号SP（“删除”/（“获取”SP消息附件））
msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
; MUST NOT change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
; MUST NOT change for a message
nil = "NIL"
nil = "NIL"
nstring = string / nil
nstring = string / nil
number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)
number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
password = astring
password = astring
quoted = DQUOTE *QUOTED-CHAR DQUOTE
quoted=DQUOTE*quoted-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials
quoted-specials = DQUOTE / "\"
报价特价=DQUOTE/“\”
rename = "RENAME" SP mailbox SP mailbox ; Use of INBOX as a destination gives a NO error
rename=“rename”SP邮箱SP邮箱；使用收件箱作为目的地不会出现错误
response = *(continue-req / response-data) response-done
response = *(continue-req / response-data) response-done
response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF
response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF
response-done = response-tagged / response-fatal
response-done = response-tagged / response-fatal
response-fatal = "*" SP resp-cond-bye CRLF ; Server closes connection immediately
response fatal=“*”SP resp cond bye CRLF；服务器立即关闭连接
response-tagged = tag SP resp-cond-state CRLF
response-tagged = tag SP resp-cond-state CRLF
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition
resp-cond-bye = "BYE" SP resp-text
resp cond bye=“bye”SP resp text
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition
resp-specials = "]"
resp specials=“]”
resp-text = ["[" resp-text-code "]" SP] text
resp-text = ["[" resp-text-code "]" SP] text
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) ; CHARSET argument to MUST be registered with IANA
search=“search”[SP“CHARSET”SP astring]1*（SP搜索键）；必须向IANA注册的字符集参数
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number /
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")"
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number /
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")"
section = "[" [section-spec] "]"
section=“[”[section spec]”
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT"
; top-level or MESSAGE/RFC822 part
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT"
; top-level or MESSAGE/RFC822 part
section-part = nz-number *("." nz-number) ; body part nesting
截面部分=新西兰编号*（“”新西兰编号）；身体部位嵌套
section-spec = section-msgtext / (section-part ["." section-text])
截面规格=截面msgtext/（截面部分[“”截面文字]）
section-text = section-msgtext / "MIME" ; text other than actual body part (headers, etc.)
节文本=节msgtext/“MIME”；实际正文部分以外的文本（标题等）
select = "SELECT" SP mailbox
select=“select”SP邮箱
seq-number = nz-number / "*"
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox's current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty.
seq-number = nz-number / "*"
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox's current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty.
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
sequence-set = (seq-number / seq-range) *("," sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; Example: a message sequence number set of
; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10.
sequence-set = (seq-number / seq-range) *("," sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; Example: a message sequence number set of
; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10.
status = "STATUS" SP mailbox SP "(" status-att *(SP status-att) ")"
status=“status”SP邮箱SP”（“status att*（SP status att）”）
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN"
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN"
status-att-list = status-att SP number *(SP status-att SP number)
状态附件列表=状态附件SP编号*（SP状态附件SP编号）
store = "STORE" SP sequence-set SP store-att-flags
store=“store”SP序列设置SP store att标志
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
(flag-list / (flag *(SP flag)))
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
(flag-list / (flag *(SP flag)))
string = quoted / literal
string = quoted / literal
subscribe = "SUBSCRIBE" SP mailbox
subscribe=“subscribe”SP邮箱
tag = 1*<any ASTRING-CHAR except "+">
tag = 1*<any ASTRING-CHAR except "+">
text = 1*TEXT-CHAR
text = 1*TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF>
TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds
uid = "UID" SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers
uid = "UID" SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers
uniqueid = nz-number ; Strictly ascending
唯一ID=新西兰编号；严格上升
unsubscribe = "UNSUBSCRIBE" SP mailbox
unsubscribe=“unsubscribe”SP邮箱
userid = astring
userid = astring
x-command = "X" atom <experimental command arguments>
x-command = "X" atom <experimental command arguments>
zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is "+0000".
zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is "+0000".
This document is a revision or rewrite of earlier documents, and supercedes the protocol specification in those documents: RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
本文件是对早期文件的修订或重写，取代了这些文件中的协议规范：RFC 2060、RFC 1730、未发布的IMAP2bis.TXT文件、RFC 1176和RFC 1064。
IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism.
IMAP4rev1协议事务（包括电子邮件数据）通过网络以明文形式发送，除非协商防止窥探。这可以通过使用STARTTLS、AUTHENTICATE命令中的协商隐私保护或某些其他保护机制来实现。
The specification of the STARTTLS command and LOGINDISABLED capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS] remains normative for the PLAIN [SASL] authenticator.
本文档中STARTTLS命令和LOGINDISABLED功能的规范取代了[IMAP-TLS]中的规范。[IMAP-TLS]仍然是普通[SASL]验证器的规范。
IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is important as it assures that any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
IMAP客户机和服务器实现必须使用\u RC4\u 128\u MD5[TLS]密码套件实现TLS\u RSA\u，并应使用\u 3DES\u EDE\u CBC\u SHA[TLS]密码套件实现TLS\u DHE\u DSS\u。这一点很重要，因为它可以确保任何两个兼容的实现都可以配置为互操作。所有其他密码套件都是可选的。请注意，这与[IMAP-TLS]第2.1节有所不同。
During the [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate that the server's identity is suspect. Matching is performed according to these rules:
在[TLS]协商期间，客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解，以防止中间人攻击。如果匹配失败，客户端应该请求明确的用户确认，或者终止连接并指出服务器的身份可疑。根据以下规则执行匹配：
The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
客户端必须使用用于打开连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
Matching is case-insensitive.
匹配不区分大小写。
A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
“*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
Both the client and server MUST check the result of the STARTTLS command and subsequent [TLS] negotiation to see whether acceptable authentication or privacy was achieved.
客户端和服务器都必须检查STARTTLS命令和后续[TLS]协商的结果，以查看是否实现了可接受的身份验证或隐私。
A server error message for an AUTHENTICATE command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid.
由于凭据无效而失败的AUTHENTICATE命令的服务器错误消息不应详细说明凭据无效的原因。
Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command with a [SASL] mechanism that does not use plaintext passwords, by first negotiating encryption via STARTTLS or some other protection mechanism.
使用LOGIN命令以清除方式发送密码。通过将AUTHENTICATE命令与不使用明文密码的[SASL]机制一起使用，首先通过STARTTLS或其他一些保护机制协商加密，可以避免这种情况。
A server implementation MUST implement a configuration that, at the time of authentication, requires: (1) The STARTTLS command has been negotiated. OR (2) Some other mechanism that protects the session from password snooping has been provided. OR (3) The following measures are in place: (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms (such as PLAIN) using plaintext passwords are NOT advertised in the CAPABILITY list. AND (b) The LOGIN command returns an error even if the password is correct. AND (c) The AUTHENTICATE command returns an error with all [SASL] mechanisms that use plaintext passwords, even if the password is correct.
服务器实现必须实现在身份验证时需要的配置：（1）STARTTLS命令已协商。或者（2）提供了保护会话免受密码窥探的其他机制。或者（3）采取了以下措施：（a）公布LOGINDISABLED功能，并且在功能列表中不公布使用明文密码的[SASL]机制（如纯密码）。（b）即使密码正确，LOGIN命令也会返回错误。（c）AUTHENTICATE命令返回所有使用明文密码的[SASL]机制的错误，即使密码正确。
A server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid.
失败登录命令的服务器错误消息不应指定用户名（而不是密码）无效。
A server SHOULD have mechanisms in place to limit or delay failed AUTHENTICATE/LOGIN attempts.
服务器应该有适当的机制来限制或延迟失败的身份验证/登录尝试。
Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands.
在讨论AUTHENTICATE和LOGIN命令的部分中讨论了其他安全注意事项。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4功能通过发布标准跟踪或IESG批准的实验RFC进行注册。注册处目前位于：
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED extensions previously defined in [IMAP-TLS], the registry will be updated accordingly.
由于本规范修改了[IMAP-TLS]中先前定义的STARTTLS和LOGINDISABLED扩展，注册表将相应更新。
Appendices
附录
A. Normative References
A.规范性参考文件
The following documents contain definitions or specifications that are necessary to understand this document properly: [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月。
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November 1997.
[匿名]Newman，C.，“匿名SASL机制”，RFC 22451997年11月。
[CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration Procedures", RFC 2978, October 2000.
[CHARSET]Freed，N.和J.Postel，“IANA字符集注册程序”，RFC 2978，2000年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[DISPOSITION] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[DISPOSITION]Troost，R.，Dorner，S.和K.Moore，“在互联网消息中传达演示信息：内容处置标题”，RFC 2183，1997年8月。
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[IMAP-TLS]纽曼，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[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月。
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGUAGE-TAGS]Alvestrand，H.，“识别语言的标签”，BCP 47，RFC 3066，2001年1月。
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[地点]Palme，J.，Hopmann，A.和N.Shelness，“聚合文档的MIME封装，如HTML（MHTML）”，RFC 2557，1999年3月。
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[MD5]Myers，J.和M.Rose，“Content-MD5标题字段”，RFC 18641995年10月。
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME-HDRS]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-IMB]Freed，N.和N.Borenstein，“MIME（多用途互联网邮件扩展）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996.
[MIME-IMT]Freed，N.和N.Borenstein，“MIME（多用途互联网邮件扩展）第二部分：媒体类型”，RFC 20461996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC-2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[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月。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997.
[UTF-7]Goldsmith，D.和M.Davis，“UTF-7：Unicode的邮件安全转换格式”，RFC 2152，1997年5月。
The following documents describe quality-of-implementation issues that should be carefully considered when implementing this protocol:
以下文件描述了实施本协议时应仔细考虑的实施质量问题：
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation Recommendations", RFC 2683, September 1999.
[IMAP-实施]Leiba，B.，“IMAP实施建议”，RFC 2683，1999年9月。
[IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[IMAP-MULTIACCESS]Gahrns，M.，“IMAP4多址邮箱实践”，RFC21801997年7月。
The following documents describe related protocols:
以下文件描述了相关协议：
[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.
[IMAP-DISC]Austein，R.，“断开连接的IMAP4客户端的同步操作”，正在进行中。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[IMAP-MODEL]Crispin，M.，“IMAP4中的分布式电子邮件模型”，RFC 1733，1994年12月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", STD 10, RFC 2821, April 2001.
[SMTP]Klensin，J.，“简单邮件传输协议”，STD 10，RFC 28212001年4月。
The following documents are historical or describe historical aspects of this protocol:
以下文件是本协议的历史文件或描述了本协议的历史方面：
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, December 1996.
[IMAP-COMPAT]Crispin，M.，“IMAP4与IMAP2bis的相容性”，RFC 2061，1996年12月。
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, December 1994.
[IMAP-HISTORICAL]Crispin，M.，“IMAP4与IMAP2和IMAP2bis的兼容性”，RFC 1732，1994年12月。
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, December 1996.
[IMAP-过时]Crispin，M.，“互联网消息访问协议-过时语法”，RFC 2062，1996年12月。
[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990.
[IMAP2]Crispin，M.，“交互式邮件访问协议-版本2”，RFC 1176，1990年8月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC-821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
B. Changes from RFC 2060
B.RFC 2060的变更
1) Clarify description of unique identifiers and their semantics.
1) 明确唯一标识符的描述及其语义。
2) Fix the SELECT description to clarify that UIDVALIDITY is required in the SELECT and EXAMINE responses.
2) 修正SELECT描述，以澄清SELECT和EXAMINE响应中需要UIDVality。
3) Added an example of a failing search.
3) 添加了一个搜索失败的示例。
4) Correct store-att-flags: "#flag" should be "1#flag".
4) 正确的存储att标志：“标志”应为“1标志”。
5) Made search and section rules clearer.
5) 使搜索和分区规则更加清晰。
6) Correct the STORE example.
6) 更正商店示例。
7) Correct "BASE645" misspelling.
7) 更正“BASE645”拼写错误。
8) Remove extraneous close parenthesis in example of two-part message with text and BASE64 attachment.
8) 在包含文本和BASE64附件的两部分邮件示例中，删除多余的右括号。
9) Remove obsolete "MAILBOX" response from mailbox-data.
9) 从邮箱数据中删除过时的“邮箱”响应。
10) A spurious "<" in the rule for mailbox-data was removed.
10） 删除了邮箱数据规则中的假“<”。
11) Add CRLF to continue-req.
11） 添加CRLF以继续请求。
12) Specifically exclude "]" from the atom in resp-text-code.
12） 在resp文本代码中明确地从atom中排除“]”。
13) Clarify that clients and servers should adhere strictly to the protocol syntax.
13） 阐明客户端和服务器应严格遵守协议语法。
14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
14） 强调5.2中存在的不能用于收缩邮箱。
15) Add NEWNAME to resp-text-code.
15） 将新名称添加到resp文本代码。
16) Clarify that the empty string, not NIL, is used as arguments to LIST.
16） 澄清将空字符串（而不是NIL）用作要列出的参数。
17) Clarify that NIL can be returned as a hierarchy delimiter for the empty string mailbox name argument if the mailbox namespace is flat.
17） 澄清如果邮箱命名空间为平面，则可以将NIL作为空字符串邮箱名称参数的层次分隔符返回。
18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting removed.
18） 澄清地址邮箱和地址名称已删除RFC-2822引用。
19) Update UTF-7 reference.
19） 更新UTF-7参考。
20) Fix example in 6.3.11.
20） 修复6.3.11中的示例。
21) Clarify that non-existent UIDs are ignored.
21）澄清忽略不存在的UID。
22) Update DISPOSITION reference.
22）更新处置参考。
23) Expand state diagram.
23）展开状态图。
24) Clarify that partial fetch responses are only returned in response to a partial fetch command.
24）澄清部分提取响应仅在响应部分提取命令时返回。
25) Add UIDNEXT response code. Correct UIDVALIDITY definition reference.
25）添加UIDNEXT响应代码。正确的UID有效性定义参考。
26) Further clarification of "can" vs. "MAY".
26）进一步澄清“可以”与“可以”。
27) Reference RFC-2119.
27）参考RFC-2119。
28) Clarify that superfluous shifts are not permitted in modified UTF-7.
28）澄清修改后的UTF-7中不允许出现多余的移位。
29) Clarify that there are no implicit shifts in modified UTF-7.
29）澄清修改后的UTF-7中没有隐含的变化。
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if it is given as a string.
30）澄清邮箱名称中的“收件箱”始终是收件箱，即使它是以字符串形式给出的。
31) Add missing open parenthesis in media-basic grammar rule.
31）在媒体基本语法规则中添加缺少的开括号。
32) Correct attribute syntax in mailbox-data.
32）邮箱数据中的属性语法正确。
33) Add UIDNEXT to EXAMINE responses.
33）添加UIDNEXT以检查响应。
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT responses in SELECT and EXAMINE. They are required now, but weren't in older versions.
34）澄清SELECT和EXAMINE中的不可见、永久标志、UIDVality和UIDNEXT响应。它们现在是必需的，但在旧版本中没有。
35) Update references with RFC numbers.
35）使用RFC编号更新参考。
36) Flush text-mime2.
36）刷新文本-mime2。
37) Clarify that modified UTF-7 names must be case-sensitive and that violating the convention should be avoided.
37）澄清修改后的UTF-7名称必须区分大小写，并应避免违反公约。
38) Correct UID FETCH example.
38）正确的UID获取示例。
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE responses.
39）澄清UID获取、UID存储和UID搜索与未标记的删除响应。
40) Clarify the use of the word "convention".
40）澄清“公约”一词的用法。
41) Clarify that a command is not "in progress" until it has been fully received (specifically, that a command is not "in progress" during command continuation negotiation).
41）澄清在完全收到命令之前，命令不是“进行中的”（具体而言，在命令继续协商期间，命令不是“进行中的”）。
42) Clarify envelope defaulting.
42）澄清信封默认设置。
43) Clarify that SP means one and only one space character.
43）澄清SP表示且仅表示一个空格字符。
44) Forbid silly states in LIST response.
44）禁止列表响应中的愚蠢状态。
45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID for a message is static.
45）澄清消息的信封、INTERNALDATE、RFC822*、正文*和UID是静态的。
46) Add BADCHARSET response code.
46）添加BADCHARSET响应代码。
47) Update formal syntax to [ABNF] conventions.
47）将正式语法更新为[ABNF]约定。
48) Clarify trailing hierarchy delimiter in CREATE semantics.
48）澄清创建语义中的尾部层次分隔符。
49) Clarify that the "blank line" is the [RFC-2822] delimiting blank line.
49）澄清“空行”是[RFC-2822]定界空行。
50) Clarify that RENAME should also create hierarchy as needed for the command to complete.
50）阐明重命名还应根据命令完成所需创建层次结构。
51) Fix body-ext-mpart to not require language if disposition present.
51）如果存在处置，则将车身外部部件固定为不需要语言。
52) Clarify the RFC822.HEADER response.
52）澄清RFC822.1标题响应。
53) Correct missing space after charset astring in search.
53）更正搜索中字符集搜索后缺少的空格。
54) Correct missing quote for BADCHARSET in resp-text-code.
54）更正resp文本代码中缺少的BADCHARSET引号。
55) Clarify that ALL, FAST, and FULL preclude any other data items appearing.
55）澄清所有、快速和完整的数据项均排除出现任何其他数据项。
56) Clarify semantics of reference argument in LIST.
56）澄清列表中引用参数的语义。
57) Clarify that a null string for SEARCH HEADER X-FOO means any message with a header line with a field-name of X-FOO regardless of the text of the header.
57）澄清搜索标题X-FOO的空字符串是指具有标题行且字段名为X-FOO的任何消息，而不考虑标题的文本。
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
58）专门保留8位邮箱名称，以备将来用作UTF-8。
59) It is not an error for the client to store a flag that is not in the PERMANENTFLAGS list; however, the server will either ignore the change or make the change in the session only.
59）客户端存储不在PERMANENTFLAGS列表中的标志不是错误；但是，服务器将忽略更改或仅在会话中进行更改。
60) Correct/clarify the text regarding superfluous shifts.
60）纠正/澄清有关多余移位的文本。
61) Correct typographic errors in the "Changes" section.
61）纠正“更改”部分的印刷错误。
62) Clarify that STATUS must not be used to check for new messages in the selected mailbox
62）澄清状态不得用于检查所选邮箱中的新邮件
63) Clarify LSUB behavior with "%" wildcard.
63）使用“%”通配符澄清LSUB行为。
64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
64）将授权更改为第7.5节中的身份验证。
65) Clarify description of multipart body type.
65）澄清多部分主体类型的说明。
66) Clarify that STORE FLAGS does not affect \Recent.
66）澄清存储标志不影响\Recent。
67) Change "west" to "east" in description of timezone.
67）将时区描述中的“西”改为“东”。
68) Clarify that commands which break command pipelining must wait for a completion result response.
68）澄清中断命令管道的命令必须等待完成结果响应。
69) Clarify that EXAMINE does not affect \Recent.
69）澄清检查不影响\最近。
70) Make description of MIME structure consistent.
70）使MIME结构的描述保持一致。
71) Clarify that date searches disregard the time and timezone of the INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means messages with an INTERNALDATE text which starts with "13-APR-2000", even if timezone differential from the local timezone is sufficient to move that INTERNALDATE into the previous or next day.
71）澄清日期搜索忽略INTERNALDATE或date:标题的时间和时区。换句话说，“2000年4月13日”是指内部日期文本以“2000年4月13日”开头的消息，即使与本地时区的时区差足以将该内部日期移到前一天或第二天。
72) Clarify that the header fetches don't add a blank line if one isn't in the [RFC-2822] message.
72）澄清如果[RFC-2822]消息中没有空行，则标头回迁不会添加空行。
73) Clarify (in discussion of UIDs) that messages are immutable.
73）澄清（在讨论UID时）消息是不可变的。
74) Add an example of CHARSET searching.
74）添加一个字符集搜索示例。
75) Clarify in SEARCH that keywords are a type of flag.
75）在搜索中澄清关键字是一种标志。
76) Clarify the mandatory nature of the SELECT data responses.
76）澄清所选数据响应的强制性。
77) Add optional CAPABILITY response code in the initial OK or PREAUTH.
77）在初始确认或预授权中添加可选能力响应代码。
78) Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN.
78）请注意，服务器可以发送一个未标记的功能命令作为身份验证和登录响应的一部分。
79) Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true.
79）删除关于不必在连接中多次发出能力命令的语句。这一说法不再正确。
80) Clarify that untagged EXPUNGE decrements the number of messages in the mailbox.
80）说明Untaged EXPUNGE会减少邮箱中的邮件数。
81) Fix definition of "body" (concatenation has tighter binding than alternation).
81）修正“body”的定义（连接比交替具有更紧密的绑定）。
82) Add a new "Special Notes to Implementors" section with reference to [IMAP-IMPLEMENTATION].
82）增加一个新的“实施者特别注意事项”部分，参考[IMAP-IMPLEMENTATION]。
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated.
83）澄清只有在未协商安全层的情况下，才能对认证命令进行未标记的功能响应。
84) Change the definition of atom to exclude "]". Update astring to include "]" for compatibility with the past. Remove resp-text-atom.
84）更改atom的定义以排除“]”。更新astring以包含“]”以与过去兼容。删除resp文本原子。
85) Remove NEWNAME. It can't work because mailbox names can be literals and can include "]". Functionality can be addressed via referrals.
85）删除新名称。它无法工作，因为邮箱名称可以是文字，并且可以包含“]”。功能可以通过转介解决。
86) Move modified UTF-7 rationale in order to have more logical paragraph flow.
86）移动修改后的UTF-7基本原理，以获得更具逻辑性的段落流。
87) Clarify UID uniqueness guarantees with the use of MUST.
87）使用MUST明确UID唯一性保证。
88) Note that clients should read response data until the connection is closed instead of immediately closing on a BYE.
88）请注意，客户端应在连接关闭之前读取响应数据，而不是在BYE上立即关闭。
89) Change RFC-822 references to RFC-2822.
89）将RFC-822参考更改为RFC-2822。
90) Clarify that RFC-2822 should be followed instead of RFC-822.
90）澄清应遵循RFC-2822而不是RFC-822。
91) Change recommendation of optional automatic capabilities in LOGIN and AUTHENTICATE to use the CAPABILITY response code in the tagged OK. This is more interoperable than an unsolicited untagged CAPABILITY response.
91）更改登录和身份验证中可选自动功能的建议，以使用标记OK中的功能响应代码。这比未经请求的未标记功能响应更具互操作性。
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add recommendations for other [SASL] mechanisms.
92）必须执行STARTTLS和AUTH=PLAIN；添加对其他[SASL]机制的建议。
93) Clarify that a "connection" (as opposed to "server" or "command") is in one of the four states.
93）澄清“连接”（与“服务器”或“命令”相对）处于四种状态之一。
94) Clarify that a failed or rejected command does not change state.
94）澄清失败或被拒绝的命令不会改变状态。
95) Split references between normative and informative.
95）将参考文献分为规范性参考文献和信息性参考文献。
96) Discuss authentication failure issues in security section.
96）在安全部分讨论身份验证失败问题。
97) Clarify that a data item is not necessarily of only one data type.
97）澄清数据项不一定只有一种数据类型。
98) Clarify that sequence ranges are independent of order.
98）澄清序列范围与顺序无关。
99) Change an example to clarify that superfluous shifts in Modified-UTF7 can not be fixed just by omitting the shift. The entire string must be recalculated.
99）更改一个示例，以澄清修改后的UTF7中的多余移位不能通过省略移位来修复。必须重新计算整个字符串。
100) Change Envelope Structure definition since [RFC-2822] uses "envelope" to refer to the [SMTP] envelope and not the envelope data that appears in the [RFC-2822] header.
100）更改信封结构定义，因为[RFC-2822]使用“信封”表示[SMTP]信封，而不是[RFC-2822]标头中显示的信封数据。
101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
101）展开RFC822.HEADER响应数据与BODY[HEADER]的对比。
102) Clarify Logout state semantics, change ASCII art.
102）澄清注销状态语义，更改ASCII艺术。
103) Security changes to comply with IESG requirements.
103）安全变更，以符合IESG要求。
104) Add definition for body URI.
104）添加主体URI的定义。
105) Break sequence range definition into three rules, with rewritten descriptions for each.
105）将序列范围定义分成三个规则，每个规则都有重写的描述。
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
106）从[IMAP-TLS]移动此处禁用的STARTTLS和LOGINDIABLE。
107) Add IANA Considerations section.
107）增加IANA注意事项部分。
108) Clarify valid client assumptions for new message UIDs vs. UIDNEXT.
108）澄清新消息UID与UIDNEXT的有效客户假设。
109) Clarify that changes to permanentflags affect concurrent sessions as well as subsequent sessions.
109）澄清对permanentflags的更改会影响并发会话以及后续会话。
110) Clarify that authenticated state can be entered by the CLOSE command.
110）说明可通过CLOSE命令输入认证状态。
111) Emphasize that SELECT and EXAMINE are the exceptions to the rule that a failing command does not change state.
111）强调SELECT和Inspect是失败命令不改变状态规则的例外。
112) Clarify that newly-appended messages have the Recent flag set.
112）澄清新附加的消息设置了“最近”标志。
113) Clarify that newly-copied messages SHOULD have the Recent flag set.
113）澄清新复制的邮件应设置最近标记。
114) Clarify that UID commands always return the UID in FETCH responses.
114）澄清UID命令总是在FETCH响应中返回UID。
C. Key Word Index
C.关键词索引
+FLAGS <flag list> (store command data item) ............... 59
+FLAGS.SILENT <flag list> (store command data item) ........ 59
-FLAGS <flag list> (store command data item) ............... 59
-FLAGS.SILENT <flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC <string> (search key) .................................. 51
BEFORE <date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY <string> (search key) ................................. 51
+FLAGS <flag list> (store command data item) ............... 59
+FLAGS.SILENT <flag list> (store command data item) ........ 59
-FLAGS <flag list> (store command data item) ............... 59
-FLAGS.SILENT <flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC <string> (search key) .................................. 51
BEFORE <date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY <string> (search key) ................................. 51
BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[<section>]<<origin octet>> (fetch result) ............. 74
BODY[<section>]<<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC <string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS <flag list> (store command data item) ................ 59
FLAGS.SILENT <flag list> (store command data item) ......... 59
FROM <string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER <field-name> <string> (search key) .................. 51
HEADER.FIELDS <header-list> (part specifier) ............... 55
HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD <flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER <n> (search key) .................................... 51
LIST (command) ............................................. 40
BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[<section>]<<origin octet>> (fetch result) ............. 74
BODY[<section>]<<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC <string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS <flag list> (store command data item) ................ 59
FLAGS.SILENT <flag list> (store command data item) ......... 59
FROM <string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER <field-name> <string> (search key) .................. 51
HEADER.FIELDS <header-list> (part specifier) ............... 55
HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD <flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER <n> (search key) .................................... 51
LIST (command) ............................................. 40
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT <search-key> (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON <date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR <search-key1> <search-key2> (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4
RFC822 (fetch item) ........................................ 57
RFC822 (fetch result) ...................................... 78
RFC822.HEADER (fetch item) ................................. 57
RFC822.HEADER (fetch result) ............................... 78
RFC822.SIZE (fetch item) ................................... 57
RFC822.SIZE (fetch result) ................................. 78
RFC822.TEXT (fetch item) ................................... 58
RFC822.TEXT (fetch result) ................................. 79
SEARCH (command) ........................................... 49
SEARCH (response) .......................................... 71
SEEN (search key) .......................................... 52
SELECT (command) ........................................... 31
SENTBEFORE <date> (search key) ............................. 52
SENTON <date> (search key) ................................. 52
SENTSINCE <date> (search key) .............................. 52
SHOULD (specification requirement term) .................... 4
SHOULD NOT (specification requirement term) ................ 4
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT <search-key> (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON <date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR <search-key1> <search-key2> (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4
RFC822 (fetch item) ........................................ 57
RFC822 (fetch result) ...................................... 78
RFC822.HEADER (fetch item) ................................. 57
RFC822.HEADER (fetch result) ............................... 78
RFC822.SIZE (fetch item) ................................... 57
RFC822.SIZE (fetch result) ................................. 78
RFC822.TEXT (fetch item) ................................... 58
RFC822.TEXT (fetch result) ................................. 79
SEARCH (command) ........................................... 49
SEARCH (response) .......................................... 71
SEEN (search key) .......................................... 52
SELECT (command) ........................................... 31
SENTBEFORE <date> (search key) ............................. 52
SENTON <date> (search key) ................................. 52
SENTSINCE <date> (search key) .............................. 52
SHOULD (specification requirement term) .................... 4
SHOULD NOT (specification requirement term) ................ 4
SINCE <date> (search key) .................................. 52
SMALLER <n> (search key) ................................... 52
STARTTLS (command) ......................................... 27
STATUS (command) ........................................... 44
STATUS (response) .......................................... 70
STORE (command) ............................................ 58
SUBJECT <string> (search key) .............................. 53
SUBSCRIBE (command) ........................................ 38
Session Flag (class of flag) ............................... 12
System Flag (type of flag) ................................. 11
TEXT (part specifier) ...................................... 56
TEXT <string> (search key) ................................. 53
TO <string> (search key) ................................... 53
TRYCREATE (response code) .................................. 65
UID (command) .............................................. 60
UID (fetch item) ........................................... 58
UID (fetch result) ......................................... 79
UID <sequence set> (search key) ............................ 53
UIDNEXT (response code) .................................... 65
UIDNEXT (status item) ...................................... 45
UIDVALIDITY (response code) ................................ 65
UIDVALIDITY (status item) .................................. 45
UNANSWERED (search key) .................................... 53
UNDELETED (search key) ..................................... 53
UNDRAFT (search key) ....................................... 53
UNFLAGGED (search key) ..................................... 53
UNKEYWORD <flag> (search key) .............................. 53
UNSEEN (response code) ..................................... 65
UNSEEN (search key) ........................................ 53
UNSEEN (status item) ....................................... 45
UNSUBSCRIBE (command) ...................................... 39
Unique Identifier (UID) (message attribute) ................ 8
X<atom> (command) .......................................... 62
[RFC-2822] Size (message attribute) ........................ 12
\Answered (system flag) .................................... 11
\Deleted (system flag) ..................................... 11
\Draft (system flag) ....................................... 11
\Flagged (system flag) ..................................... 11
\Marked (mailbox name attribute) ........................... 69
\Noinferiors (mailbox name attribute) ...................... 69
\Noselect (mailbox name attribute) ......................... 69
\Recent (system flag) ...................................... 11
\Seen (system flag) ........................................ 11
\Unmarked (mailbox name attribute) ......................... 69
SINCE <date> (search key) .................................. 52
SMALLER <n> (search key) ................................... 52
STARTTLS (command) ......................................... 27
STATUS (command) ........................................... 44
STATUS (response) .......................................... 70
STORE (command) ............................................ 58
SUBJECT <string> (search key) .............................. 53
SUBSCRIBE (command) ........................................ 38
Session Flag (class of flag) ............................... 12
System Flag (type of flag) ................................. 11
TEXT (part specifier) ...................................... 56
TEXT <string> (search key) ................................. 53
TO <string> (search key) ................................... 53
TRYCREATE (response code) .................................. 65
UID (command) .............................................. 60
UID (fetch item) ........................................... 58
UID (fetch result) ......................................... 79
UID <sequence set> (search key) ............................ 53
UIDNEXT (response code) .................................... 65
UIDNEXT (status item) ...................................... 45
UIDVALIDITY (response code) ................................ 65
UIDVALIDITY (status item) .................................. 45
UNANSWERED (search key) .................................... 53
UNDELETED (search key) ..................................... 53
UNDRAFT (search key) ....................................... 53
UNFLAGGED (search key) ..................................... 53
UNKEYWORD <flag> (search key) .............................. 53
UNSEEN (response code) ..................................... 65
UNSEEN (search key) ........................................ 53
UNSEEN (status item) ....................................... 45
UNSUBSCRIBE (command) ...................................... 39
Unique Identifier (UID) (message attribute) ................ 8
X<atom> (command) .......................................... 62
[RFC-2822] Size (message attribute) ........................ 12
\Answered (system flag) .................................... 11
\Deleted (system flag) ..................................... 11
\Draft (system flag) ....................................... 11
\Flagged (system flag) ..................................... 11
\Marked (mailbox name attribute) ........................... 69
\Noinferiors (mailbox name attribute) ...................... 69
\Noselect (mailbox name attribute) ......................... 69
\Recent (system flag) ...................................... 11
\Seen (system flag) ........................................ 11
\Unmarked (mailbox name attribute) ......................... 69
Author's Address
作者地址
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Mark R. Crispin网络与分布式计算华盛顿大学西雅图第十五大街4545号WA98105-427
Phone: (206) 543-5762
电话：（206）543-5762
EMail: MRC@CAC.Washington.EDU
EMail: MRC@CAC.Washington.EDU
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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. v 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.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。v本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。