Network Working Group A. Melnikov
Request for Comments: 4466 Isode Ltd.
Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
Category: Standards Track April 2006
Network Working Group A. Melnikov
Request for Comments: 4466 Isode Ltd.
Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
Category: Standards Track April 2006
Collected Extensions to IMAP4 ABNF
IMAP4 ABNF的已收集扩展
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.
多年来，来自IMAPEXT和LEMONADE工作组的许多文档，以及许多单独的文档，都为RFC3501中描述的许多基本IMAP命令添加了语法扩展。为便于参考，本文件将大部分ABNF变更收集在一个地方。
This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.
本文档还建议了一组标准模式，用于向RFC 3501中定义的几个现有IMAP命令添加选项和扩展。这些模式提供了现有扩展和未来扩展之间的兼容性。
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.
本文档更新了RFCs 2088、2342、3501、3502和3516中的ABNF。它还包括RFC 3501勘误表的一部分。本文档未指定对所列RFC的任何语义更改。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Purpose of This Document ...................................2
1.2. Conventions Used in This Document ..........................3
2. IMAP ABNF Extensions ............................................3
2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
2.2. Extended CREATE Command ....................................4
2.3. Extended RENAME Command ....................................5
2.4. Extensions to FETCH and UID FETCH Commands .................6
2.5. Extensions to STORE and UID STORE Commands .................6
2.6. Extensions to SEARCH Command ...............................7
2.6.1. Extended SEARCH Command .............................7
2.6.2. ESEARCH untagged response ...........................8
2.7. Extensions to APPEND Command ...............................8
3. Formal Syntax ...................................................9
4. Security Considerations ........................................14
5. Normative References ...........................................15
6. Acknowledgements ...............................................15
1. Introduction ....................................................2
1.1. Purpose of This Document ...................................2
1.2. Conventions Used in This Document ..........................3
2. IMAP ABNF Extensions ............................................3
2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
2.2. Extended CREATE Command ....................................4
2.3. Extended RENAME Command ....................................5
2.4. Extensions to FETCH and UID FETCH Commands .................6
2.5. Extensions to STORE and UID STORE Commands .................6
2.6. Extensions to SEARCH Command ...............................7
2.6.1. Extended SEARCH Command .............................7
2.6.2. ESEARCH untagged response ...........................8
2.7. Extensions to APPEND Command ...............................8
3. Formal Syntax ...................................................9
4. Security Considerations ........................................14
5. Normative References ...........................................15
6. Acknowledgements ...............................................15
This document serves several purposes:
本文件有以下几个目的：
1. rationalize and generalize ABNF for some existing IMAP extensions; 2. collect the ABNF in one place in order to minimize cross references between documents; 3. define building blocks for future extensions so that they can be used together in a compatible way.
1. 对一些现有IMAP扩展的ABNF进行合理化和推广；2.将ABNF收集在一个地方，以尽量减少文件之间的交叉引用；3.为将来的扩展定义构建块，以便它们能够以兼容的方式一起使用。
It is expected that a future revision of this document will be incorporated into a revision of RFC 3501.
预计本文件的未来修订版将并入RFC 3501的修订版中。
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.
本文档更新了RFCs 2088、2342、3501、3502和3516中的ABNF。它还包括RFC 3501勘误表的一部分。本文档未指定对所列RFC的任何语义更改。
The ABNF in section 6 of RFC 2342 got rewritten to conform to the ABNF syntax as defined in RFC 4234 and to reference new non-terminals from RFC 3501. It was also restructured to allow for better readability. There were no changes "on the wire".
RFC 2342第6节中的ABNF被重写，以符合RFC 4234中定义的ABNF语法，并引用RFC 3501中的新非终端。它还进行了重组，以提高可读性。“电线上”没有变化。
Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent manner. Extensions to all the commands but APPEND have the same
第2节以一致的方式扩展了SELECT、EXAMINE、CREATE、RENAME、FETCH/UID FETCH、STORE/UID STORE、SEARCH和APPEND命令的ABNF。除了APPEND之外，所有命令的扩展都具有相同的
structure. Extensibility for the APPEND command was done slightly differently in order to preserve backward compatibility with existing extensions.
结构APPEND命令的可扩展性的实现略有不同，以保持与现有扩展的向后兼容性。
Section 2 also defines a new ESEARCH response, whose purpose is to define a better version of the SEARCH response defined in RFC 3501.
第2节还定义了一个新的ESEARCH响应，其目的是定义RFC 3501中定义的搜索响应的更好版本。
Section 3 defines the collected ABNF that replaces pieces of ABNF in the aforementioned RFCs. The collected ABNF got generalized to allow for easier future extensibility.
第3节定义了收集的ABNF，该ABNF替换了上述RFC中的ABNF片段。收集到的ABNF得到了通用化，以便于将来的扩展。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[关键词]。
This section is not normative. It provides some background on the intended use of different extensions and it gives some guidance about how future extensions should extend the described commands.
本节不规范。它提供了关于不同扩展的预期用途的一些背景知识，并就未来扩展如何扩展所描述的命令提供了一些指导。
This document adds the ability to include one or more parameters with the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2 of [IMAP4]) commands, to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension.
本文档增加了在IMAP SELECT（IMAP4第6.3.1节）或EXAMINE（IMAP4第6.3.2节）命令中包含一个或多个参数的功能，以打开或关闭某些标准行为，或添加特定扩展所需的新可选行为。
There are two possible modes of operation:
有两种可能的操作模式：
o A global state change where a single use of the optional parameter will affect the session state from that time on, irrespective of subsequent SELECT/EXAMINE commands.
o 一种全局状态更改，在此更改中，无论后续的SELECT/EXAMINE命令如何，只要使用一次可选参数，就会影响会话状态。
o A per-mailbox state change that will affect the session only for the duration of the new selected state. A subsequent SELECT/EXAMINE without the optional parameter will cancel its effect for the newly selected mailbox.
o 每个邮箱的状态更改，仅在新选定状态期间影响会话。不带可选参数的后续选择/检查将取消其对新选定邮箱的影响。
Optional parameters to the SELECT or EXAMINE commands are added as a parenthesized list of attribute/value pairs, and appear after the mailbox name in the standard SELECT or EXAMINE command. The order of individual parameters is arbitrary. A parameter value is optional
选择或检查命令的可选参数添加为带括号的属性/值对列表，并显示在标准选择或检查命令中邮箱名称之后。单个参数的顺序是任意的。参数值是可选的
and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
并且可以由原子、字符串或列表按特定顺序组成。如果参数值存在，则它始终显示在括号（*）中。服务器支持的扩展未定义的任何参数都必须以错误响应拒绝。
Example:
例子：
C: a SELECT INBOX (ANNOTATE)
S: ...
S: a OK SELECT complete
C: a SELECT INBOX (ANNOTATE)
S: ...
S: a OK SELECT complete
In the above example, a single parameter is used with the SELECT command.
在上面的示例中，SELECT命令使用单个参数。
Example:
例子：
C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
CONDSTORE)
S: ...
S: a OK EXAMINE complete
C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
CONDSTORE)
S: ...
S: a OK EXAMINE complete
In the above example, three parameters are used with the EXAMINE command. The second parameter consists of two items: an atom "RESPONSES" followed by a quoted string.
在上面的示例中，三个参数与EXAMINE命令一起使用。第二个参数由两项组成：一个原子“RESPONSES”，后跟一个带引号的字符串。
Example:
例子：
C: a SELECT INBOX (BLURDYBLOOP)
S: a BAD Unknown parameter in SELECT command
C: a SELECT INBOX (BLURDYBLOOP)
S: a BAD Unknown parameter in SELECT command
In the above example, a parameter not supported by the server is used. This results in the BAD response from the server.
在上面的示例中，使用了服务器不支持的参数。这会导致服务器的错误响应。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*）-如果参数具有强制值，该值始终可以表示为数字或序列集，则参数值不需要封闭（）。有关更多详细信息，请参见ABNF。
Arguments: mailbox name OPTIONAL list of CREATE parameters
参数：邮箱名称创建参数的可选列表
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - create completed
NO - create failure: cannot create mailbox with
that name
BAD - argument(s) invalid
Result: OK - create completed
NO - create failure: cannot create mailbox with
that name
BAD - argument(s) invalid
This document adds the ability to include one or more parameters with the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension. No CREATE parameters are defined in this document.
本文档添加了在IMAP CREATE命令中包含一个或多个参数的功能（请参见[IMAP4]第6.3.3节），以打开或关闭某些标准行为，或添加特定扩展所需的新可选行为。此文档中未定义任何创建参数。
Optional parameters to the CREATE command are added as a parenthesized list of attribute/value pairs after the mailbox name. The order of individual parameters is arbitrary. A parameter value is optional and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
“创建”命令的可选参数将作为属性/值对的括号列表添加到邮箱名称之后。单个参数的顺序是任意的。参数值是可选的，可以由原子、字符串或按特定顺序排列的列表组成。如果参数值存在，则它始终显示在括号（*）中。服务器支持的扩展未定义的任何参数都必须以错误响应拒绝。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*）-如果参数具有强制值，该值始终可以表示为数字或序列集，则参数值不需要封闭（）。有关更多详细信息，请参见ABNF。
Arguments: existing mailbox name new mailbox name OPTIONAL list of RENAME parameters
参数：现有邮箱名称新邮箱名称重命名参数的可选列表
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - rename completed NO - rename failure: cannot rename mailbox with that name, cannot rename to mailbox with that name, etc. BAD - argument(s) invalid
结果：确定-重命名完成否-重命名失败：无法使用该名称重命名邮箱，无法重命名为使用该名称的邮箱，等等。错误-参数无效
This document adds the ability to include one or more parameters with the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or off certain standard behaviors, or to add new optional behaviors required for a particular extension. No RENAME parameters are defined in this document.
本文档增加了使用IMAP RENAME命令（参见[IMAP4]第6.3.5节）包含一个或多个参数的功能，以打开或关闭某些标准行为，或添加特定扩展所需的新可选行为。此文档中未定义重命名参数。
Optional parameters to the RENAME command are added as a parenthesized list of attribute/value pairs after the new mailbox name. The order of individual parameters is arbitrary. A parameter value is optional and may consist of atoms, strings, or lists in a specific order. If the parameter value is present, it always appears in parentheses (*). Any parameter not defined by extensions that the server supports must be rejected with a BAD response.
重命名命令的可选参数将作为新邮箱名称后的属性/值对的括号列表添加。单个参数的顺序是任意的。参数值是可选的，可以由原子、字符串或按特定顺序排列的列表组成。如果参数值存在，则它始终显示在括号（*）中。服务器支持的扩展未定义的任何参数都必须以错误响应拒绝。
(*) - if a parameter has a mandatory value, which can always be represented as a number or a sequence-set, the parameter value does not need the enclosing (). See ABNF for more details.
（*）-如果参数具有强制值，该值始终可以表示为数字或序列集，则参数值不需要封闭（）。有关更多详细信息，请参见ABNF。
Arguments: sequence set message data item names or macro OPTIONAL fetch modifiers
参数：序列集消息数据项名称或宏可选获取修饰符
Responses: untagged responses: FETCH
响应：未标记的响应：获取
Result: OK - fetch completed
NO - fetch error: cannot fetch that data
BAD - command unknown or arguments invalid
Result: OK - fetch completed
NO - fetch error: cannot fetch that data
BAD - command unknown or arguments invalid
This document extends the syntax of the FETCH and UID FETCH commands (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers. No fetch modifiers are defined in this document.
本文档扩展了FETCH和UID FETCH命令的语法（参见[IMAP4]第6.4.5节），以包括可选的FETCH修饰符。此文档中未定义提取修饰符。
The order of individual modifiers is arbitrary. Each modifier is an attribute/value pair. A modifier value is optional and may consist of atoms and/or strings and/or lists in a specific order. If the modifier value is present, it always appears in parentheses (*). Any modifiers not defined by extensions that the server supports must be rejected with a BAD response.
单个修改器的顺序是任意的。每个修改器都是一个属性/值对。修饰符值是可选的，可以由原子和/或字符串和/或列表按特定顺序组成。如果修改器值存在，则它始终显示在括号（*）中。服务器支持的扩展未定义的任何修饰符都必须以错误响应被拒绝。
(*) - if a modifier has a mandatory value, which can always be represented as a number or a sequence-set, the modifier value does not need the enclosing (). See ABNF for more details.
（*）-如果修饰符具有强制值，该值始终可以表示为数字或序列集，则修饰符值不需要封闭（）。有关更多详细信息，请参见ABNF。
Arguments: message set OPTIONAL store modifiers message data item name value for message data item
参数：消息集可选存储修饰符消息数据项的消息数据项名称值
Responses: untagged responses: FETCH
响应：未标记的响应：获取
Result: OK - store completed
NO - store error: cannot store that data
BAD - command unknown or arguments invalid
Result: OK - store completed
NO - store error: cannot store that data
BAD - command unknown or arguments invalid
This document extends the syntax of the STORE and UID STORE commands (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers. No store modifiers are defined in this document.
本文档扩展了STORE和UID STORE命令的语法（参见[IMAP4]第6.4.6节），以包括可选的STORE修饰符。本文档中未定义存储修改器。
The order of individual modifiers is arbitrary. Each modifier is an attribute/value pair. A modifier value is optional and may consist of atoms and/or strings and/or lists in a specific order. If the modifier value is present, it always appears in parentheses (*). Any modifiers not defined by extensions that the server supports must be rejected with a BAD response.
单个修改器的顺序是任意的。每个修改器都是一个属性/值对。修饰符值是可选的，可以由原子和/或字符串和/或列表按特定顺序组成。如果修改器值存在，则它始终显示在括号（*）中。服务器支持的扩展未定义的任何修饰符都必须以错误响应被拒绝。
(*) - if a modifier has a mandatory value, which can always be represented as a number or a sequence-set, the modifier value does not need the enclosing (). See ABNF for more details.
（*）-如果修饰符具有强制值，该值始终可以表示为数字或序列集，则修饰符值不需要封闭（）。有关更多详细信息，请参见ABNF。
Arguments: OPTIONAL result specifier OPTIONAL [CHARSET] specification searching criteria (one or more)
参数：可选结果说明符可选[CHARSET]规范搜索条件（一个或多个）
Responses: REQUIRED untagged response: SEARCH (*)
Responses: REQUIRED untagged response: SEARCH (*)
Result: OK - search completed NO - search error: cannot search that [CHARSET] or criteria BAD - command unknown or arguments invalid
结果：确定-搜索已完成否-搜索错误：无法搜索[CHARSET]或条件错误-命令未知或参数无效
This section updates definition of the SEARCH command described in section 6.4.4 of [IMAP4].
本节更新了[IMAP4]第6.4.4节中描述的搜索命令的定义。
The SEARCH command is extended to allow for result options. This document does not define any result options.
搜索命令已扩展，以允许使用结果选项。本文档未定义任何结果选项。
The order of individual options is arbitrary. Individual options may contain parameters enclosed in parentheses (**). If an option has parameters, they consist of atoms and/or strings and/or lists in a specific order. Any options not defined by extensions that the server supports must be rejected with a BAD response.
各个选项的顺序是任意的。单个选项可能包含括在括号（**）中的参数。如果选项有参数，则它们由原子和/或字符串和/或按特定顺序排列的列表组成。服务器支持的扩展未定义的任何选项都必须以错误响应拒绝。
(*) - An extension to the SEARCH command may require another untagged response, or no untagged response to be returned. Section 2.6.2 defines a new ESEARCH untagged response that replaces the SEARCH untagged response. Note that for a given extended SEARCH command the SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only one of them should be returned.
（*）-搜索命令的扩展可能需要另一个未标记的响应，或者不返回未标记的响应。第2.6.2节定义了一个新的ESEARCH未标记响应，它取代了搜索未标记响应。请注意，对于给定的扩展搜索命令，搜索和ESEARCH响应应该是互斥的，即只返回其中一个响应。
(**) - if an option has a mandatory parameter, which can always be represented as a number or a sequence-set, the option parameter does not need the enclosing (). See ABNF for more details.
（**）-如果一个选项有一个强制参数，该参数始终可以表示为一个数字或序列集，则该选项参数不需要封闭（）。有关更多详细信息，请参见ABNF。
Contents: one or more search-return-data pairs
内容：一个或多个搜索返回数据对
The ESEARCH response SHOULD be sent as a result of an extended SEARCH or UID SEARCH command specified in section 2.6.1.
ESEARCH响应应作为第2.6.1节中指定的扩展搜索或UID搜索命令的结果发送。
The ESEARCH response starts with an optional search correlator. If it is missing, then the response was not caused by a particular IMAP command, whereas if it is present, it contains the tag of the command that caused the response to be returned.
ESEARCH响应以可选的搜索相关器开始。如果缺少，则响应不是由特定IMAP命令引起的，而如果存在，则包含导致返回响应的命令的标记。
The search correlator is followed by an optional UID indicator. If this indicator is present, all data in the ESEARCH response refers to UIDs, otherwise all returned data refers to message numbers.
搜索相关器后面跟着一个可选的UID指示器。如果此指示器存在，则ESEARCH响应中的所有数据都指向UID，否则所有返回的数据都指向消息编号。
The rest of the ESEARCH response contains one or more search data pairs. Each pair starts with unique return item name, followed by a space and the corresponding data. Search data pairs may be returned in any order. Unless specified otherwise by an extension, any return item name SHOULD appear only once in an ESEARCH response.
ESEARCH响应的其余部分包含一个或多个搜索数据对。每一对都以唯一的返回项名称开始，后跟一个空格和相应的数据。搜索数据对可以按任何顺序返回。除非扩展名另有规定，否则任何返回项名称在ESEARCH响应中只应出现一次。
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
Example: S: * ESEARCH COUNT 5 ALL 1:17,21
The IMAP BINARY extension [BINARY] extends the APPEND command to allow a client to append data containing NULs by using the <literal8> syntax. The ABNF was rewritten to allow for easier extensibility by IMAP extensions. This document hasn't specified any semantical changes to the [BINARY] extension.
IMAP二进制扩展名[BINARY]扩展了APPEND命令，允许客户端使用<literal8>语法追加包含NUL的数据。ABNF被重写，以便通过IMAP扩展更易于扩展。此文档未指定对[BINARY]扩展名的任何语义更改。
In addition, the non-terminal "literal8" defined in [BINARY] got extended to allow for non-synchronizing literals if both [BINARY] and [LITERAL+] extensions are supported by the server.
此外，如果服务器支持[BINARY]和[LITERAL+]扩展，则扩展了[BINARY]中定义的非终端“literal8”，以允许非同步文字。
The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND command to allow a client to append multiple messages atomically. This document defines a common syntax for the APPEND command that takes into consideration syntactic extensions defined by both [BINARY] and [MULTIAPPEND] extensions.
IMAP MULTIAPPEND extension[MULTIAPPEND]扩展了APPEND命令，允许客户端以原子方式追加多条消息。本文档定义了APPEND命令的通用语法，该语法考虑了[BINARY]和[MULTIAPPEND]扩展定义的语法扩展。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
Non-terminals referenced but not defined below are as defined by [IMAP4].
以下引用但未定义的非端子由[IMAP4]定义。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
append = "APPEND" SP mailbox 1*append-message
;; only a single append-message may appear
;; if MULTIAPPEND [MULTIAPPEND] capability
;; is not present
append = "APPEND" SP mailbox 1*append-message
;; only a single append-message may appear
;; if MULTIAPPEND [MULTIAPPEND] capability
;; is not present
append-message = append-opts SP append-data
append-message = append-opts SP append-data
append-ext = append-ext-name SP append-ext-value ;; This non-terminal define extensions to ;; to message metadata.
追加外部=追加外部名称SP追加外部值；；此非终端定义对；；的扩展；；创建消息元数据。
append-ext-name = tagged-ext-label
append-ext-name = tagged-ext-label
append-ext-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
追加外部值=标记的外部值；；此非终端显示建议的语法；；用于将来的扩展。
append-data = literal / literal8 / append-data-ext
append-data = literal / literal8 / append-data-ext
append-data-ext = tagged-ext
;; This non-terminal shows recommended syntax
;; for future extensions,
;; i.e., a mandatory label followed
;; by parameters.
append-data-ext = tagged-ext
;; This non-terminal shows recommended syntax
;; for future extensions,
;; i.e., a mandatory label followed
;; by parameters.
append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
;; message metadata
append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
;; message metadata
charset = atom / quoted ;; Exact syntax is defined in [CHARSET].
字符集=原子/引号；；确切语法在[CHARSET]中定义。
create = "CREATE" SP mailbox [create-params] ;; Use of INBOX gives a NO error.
create=“create”SP邮箱[创建参数]；；使用“收件箱”时不会出现错误。
create-params = SP "(" create-param *( SP create-param) ")"
create-params = SP "(" create-param *( SP create-param) ")"
create-param-name = tagged-ext-label
create-param-name = tagged-ext-label
create-param = create-param-name [SP create-param-value]
创建参数=创建参数名称[SP创建参数值]
create-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
创建参数值=标记的外部值；；此非终端显示建议的语法；；用于将来的扩展。
esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
*(SP search-return-data)
;; Note that SEARCH and ESEARCH responses
;; SHOULD be mutually exclusive,
;; i.e., only one of the response types
;; should be
;; returned as a result of a command.
esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
*(SP search-return-data)
;; Note that SEARCH and ESEARCH responses
;; SHOULD be mutually exclusive,
;; i.e., only one of the response types
;; should be
;; returned as a result of a command.
examine = "EXAMINE" SP mailbox [select-params]
;; modifies the original IMAP EXAMINE command
;; to accept optional parameters
examine = "EXAMINE" SP mailbox [select-params]
;; modifies the original IMAP EXAMINE command
;; to accept optional parameters
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
"FAST" / fetch-att /
"(" fetch-att *(SP fetch-att) ")")
[fetch-modifiers]
;; modifies the original IMAP4 FETCH command to
;; accept optional modifiers
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
"FAST" / fetch-att /
"(" fetch-att *(SP fetch-att) ")")
[fetch-modifiers]
;; modifies the original IMAP4 FETCH command to
;; accept optional modifiers
fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
获取修饰符=获取修饰符名称[SP fetch modif params]
fetch-modif-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
fetch modif params=标记的ext val；；此非终端显示建议的语法；；用于将来的扩展。
fetch-modifier-name = tagged-ext-label
fetch-modifier-name = tagged-ext-label
literal8 = "~{" number ["+"] "}" CRLF *OCTET
;; A string that might contain NULs.
;; <number> represents the number of OCTETs
;; in the response string.
;; The "+" is only allowed when both LITERAL+ and
;; BINARY extensions are supported by the server.
literal8 = "~{" number ["+"] "}" CRLF *OCTET
;; A string that might contain NULs.
;; <number> represents the number of OCTETs
;; in the response string.
;; The "+" is only allowed when both LITERAL+ and
;; BINARY extensions are supported by the server.
mailbox-data =/ Namespace-Response / esearch-response
邮箱数据=/Namespace响应/esearch响应
Namespace = nil / "(" 1*Namespace-Descr ")"
Namespace = nil / "(" 1*Namespace-Descr ")"
Namespace-Command = "NAMESPACE"
Namespace-Command = "NAMESPACE"
Namespace-Descr = "(" string SP (DQUOTE QUOTED-CHAR DQUOTE / nil) *(Namespace-Response-Extension) ")"
Namespace Descr=“（“字符串SP（DQUOTE-quote-CHAR-DQUOTE/nil）*（名称空间响应扩展）”）
Namespace-Response-Extension = SP string SP "(" string *(SP string) ")"
命名空间响应扩展名=SP string SP“（“string*（SP string）”）
Namespace-Response = "NAMESPACE" SP Namespace
SP Namespace SP Namespace
;; This response is currently only allowed
;; if the IMAP server supports [NAMESPACE].
;; The first Namespace is the Personal Namespace(s)
;; The second Namespace is the Other Users' Namespace(s)
;; The third Namespace is the Shared Namespace(s)
Namespace-Response = "NAMESPACE" SP Namespace
SP Namespace SP Namespace
;; This response is currently only allowed
;; if the IMAP server supports [NAMESPACE].
;; The first Namespace is the Personal Namespace(s)
;; The second Namespace is the Other Users' Namespace(s)
;; The third Namespace is the Shared Namespace(s)
rename = "RENAME" SP mailbox SP mailbox
[rename-params]
;; Use of INBOX as a destination gives
;; a NO error, unless rename-params
;; is not empty.
rename = "RENAME" SP mailbox SP mailbox
[rename-params]
;; Use of INBOX as a destination gives
;; a NO error, unless rename-params
;; is not empty.
rename-params = SP "(" rename-param *( SP rename-param) ")"
rename-params = SP "(" rename-param *( SP rename-param) ")"
rename-param = rename-param-name [SP rename-param-value]
重命名参数=重命名参数名称[SP重命名参数值]
rename-param-name = tagged-ext-label
rename-param-name = tagged-ext-label
rename-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
重命名参数值=标记的外部值；；此非终端显示建议的语法；；用于将来的扩展。
response-data = "*" SP response-payload CRLF
响应数据=“*”SP响应有效负载CRLF
response-payload= resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data
response-payload= resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data
search = "SEARCH" [search-return-opts] SP search-program
search=“search”[search return opts]SP搜索程序
search-correlator = SP "(" "TAG" SP tag-string ")"
搜索相关器=SP“（“标记”SP标记字符串“）
search-program = ["CHARSET" SP charset SP]
search-key *(SP search-key)
;; CHARSET argument to SEARCH MUST be
;; registered with IANA.
search-program = ["CHARSET" SP charset SP]
search-key *(SP search-key)
;; CHARSET argument to SEARCH MUST be
;; registered with IANA.
search-return-data = search-modifier-name SP search-return-value
;; Note that not every SEARCH return option
;; is required to have the corresponding
;; ESEARCH return data.
search-return-data = search-modifier-name SP search-return-value
;; Note that not every SEARCH return option
;; is required to have the corresponding
;; ESEARCH return data.
search-return-opts = SP "RETURN" SP "(" [search-return-opt *(SP search-return-opt)] ")"
搜索返回选项=SP“return”SP“（“[search return opt*（SP search return opt）]”）
search-return-opt = search-modifier-name [SP search-mod-params]
搜索返回opt=搜索修改器名称[SP search mod params]
search-return-value = tagged-ext-val
;; Data for the returned search option.
;; A single "nz-number"/"number" value
;; can be returned as an atom (i.e., without
;; quoting). A sequence-set can be returned
;; as an atom as well.
search-return-value = tagged-ext-val
;; Data for the returned search option.
;; A single "nz-number"/"number" value
;; can be returned as an atom (i.e., without
;; quoting). A sequence-set can be returned
;; as an atom as well.
search-modifier-name = tagged-ext-label
search-modifier-name = tagged-ext-label
search-mod-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
search mod params=标记的ext val；；此非终端显示建议的语法；；用于将来的扩展。
select = "SELECT" SP mailbox [select-params]
;; modifies the original IMAP SELECT command to
;; accept optional parameters
select = "SELECT" SP mailbox [select-params]
;; modifies the original IMAP SELECT command to
;; accept optional parameters
select-params = SP "(" select-param *(SP select-param) ")"
select-params = SP "(" select-param *(SP select-param) ")"
select-param = select-param-name [SP select-param-value] ;; a parameter to SELECT may contain one or ;; more atoms and/or strings and/or lists.
选择参数=选择参数名称[SP选择参数值]；；要选择的参数可以包含一个或多个；；更多原子和/或字符串和/或列表。
select-param-name= tagged-ext-label
选择参数名称=标记的外部标签
select-param-value= tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
选择参数值=标记的外部值；；此非终端显示建议的语法；；用于将来的扩展。
status-att-list = status-att-val *(SP status-att-val) ;; Redefines status-att-list from RFC 3501.
状态att list=状态att val*（SP状态att val）；；从RFC 3501重新定义状态att列表。
;; status-att-val is defined in RFC 3501 errata
;; 状态att val在RFC 3501勘误表中定义
status-att-val = ("MESSAGES" SP number) /
("RECENT" SP number) /
("UIDNEXT" SP nz-number) /
("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number)
;; Extensions to the STATUS responses
;; should extend this production.
;; Extensions should use the generic
;; syntax defined by tagged-ext.
status-att-val = ("MESSAGES" SP number) /
("RECENT" SP number) /
("UIDNEXT" SP nz-number) /
("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number)
;; Extensions to the STATUS responses
;; should extend this production.
;; Extensions should use the generic
;; syntax defined by tagged-ext.
store = "STORE" SP sequence-set [store-modifiers] SP store-att-flags ;; extend [IMAP4] STORE command syntax ;; to allow for optional store-modifiers
store=“store”SP序列集[store MODIFERS]SP store att标志；；扩展[IMAP4]存储命令语法；；允许使用可选的存储修改器
store-modifiers = SP "(" store-modifier *(SP store-modifier) ")"
存储修饰符=SP“（“存储修饰符*（SP存储修饰符）”）
store-modifier = store-modifier-name [SP store-modif-params]
存储修改器=存储修改器名称[SP store modif params]
store-modif-params = tagged-ext-val ;; This non-terminal shows recommended syntax ;; for future extensions.
store modif params=标记的ext val；；此非终端显示建议的语法；；用于将来的扩展。
store-modifier-name = tagged-ext-label
store-modifier-name = tagged-ext-label
tag-string = string
;; tag of the command that caused
;; the ESEARCH response, sent as
;; a string.
tag-string = string
;; tag of the command that caused
;; the ESEARCH response, sent as
;; a string.
tagged-ext = tagged-ext-label SP tagged-ext-val
;; recommended overarching syntax for
;; extensions
tagged-ext = tagged-ext-label SP tagged-ext-val
;; recommended overarching syntax for
;; extensions
tagged-ext-label = tagged-label-fchar *tagged-label-char ;; Is a valid RFC 3501 "atom".
tagged ext label=tagged label fchar*tagged label char；；是有效的RFC 3501“atom”。
tagged-label-fchar = ALPHA / "-" / "_" / "."
tagged-label-fchar = ALPHA / "-" / "_" / "."
tagged-label-char = tagged-label-fchar / DIGIT / ":"
tagged-label-char = tagged-label-fchar / DIGIT / ":"
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
;; Extensions that follow this general
;; syntax should use nstring instead of
;; astring when appropriate in the context
;; of the extension.
;; Note that a message set or a "number"
;; can always be represented as an "atom".
;; An URL should be represented as
;; a "quoted" string.
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
;; Extensions that follow this general
;; syntax should use nstring instead of
;; astring when appropriate in the context
;; of the extension.
;; Note that a message set or a "number"
;; can always be represented as an "atom".
;; An URL should be represented as
;; a "quoted" string.
tagged-ext-simple = sequence-set / number
tagged-ext-simple = sequence-set / number
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
tagged ext val=tagged ext simple/“（“[tagged ext comp]”）
This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. The updated documents must be consulted for security considerations for the extensions that they define.
本文档更新了RFCs 2088、2342、3501、3502和3516中的ABNF。必须参考更新后的文档，以了解其定义的扩展的安全考虑。
As a protocol gets more complex, parser bugs become more common including buffer overflow, denial of service, and other common security coding errors. To the extent that this document makes the parser more complex, it makes this situation worse. To the extent that this document makes the parser more consistent and thus simpler, the situation is improved. The impact will depend on how many deployed IMAP extensions are consistent with this document. Implementers are encouraged to take care of these issues when extending existing implementations. Future IMAP extensions should strive for consistency and simplicity to the greatest extent possible.
随着协议变得越来越复杂，解析器错误变得越来越常见，包括缓冲区溢出、拒绝服务和其他常见的安全编码错误。由于该文档使解析器变得更复杂，因此情况更糟。由于本文档使解析器更加一致，从而更加简单，因此情况有所改善。影响将取决于有多少已部署的IMAP扩展与本文档一致。我们鼓励实现者在扩展现有实现时注意这些问题。未来的IMAP扩展应该尽可能地追求一致性和简单性。
Extensions to IMAP commands that are permitted in NOT AUTHENTICATED state are more sensitive to these security issues due to the larger possible attacker community prior to authentication, and the fact that some IMAP servers run with elevated privileges in that state. This document does not extend any commands permitted in NOT AUTHENTICATED state. Future IMAP extensions to commands permitted in NOT AUTHENTICATED state should favor simplicity over consistency or extensibility.
在未验证状态下允许的IMAP命令扩展对这些安全问题更为敏感，因为在验证之前，可能存在更大的攻击者群体，并且某些IMAP服务器在该状态下以提升的权限运行。本文档不扩展未验证状态下允许的任何命令。对于未经身份验证状态下允许的命令，未来的IMAP扩展应该支持简单性而不是一致性或可扩展性。
[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月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[CHARSET]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]Crispin，M.，“互联网消息访问协议（IMAP）-多附加扩展”，RFC 35022003年3月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[名称空间]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC 23421998年5月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL+]Myers，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[二进制]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，2003年4月。
This documents is based on ideas proposed by Pete Resnick, Mark Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon Nerenberg.
本文件基于皮特·雷斯尼克、马克·克里斯宾、肯·默奇森、菲利普·根瑟、兰德尔·盖伦斯和林登·内伦伯格提出的想法。
However, all errors and omissions must be attributed to the authors of the document.
但是，所有错误和遗漏必须归咎于文件作者。
Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman, Elwyn Davies, and Barry Leiba for comments and corrections.
感谢Philip Guenther、Dave Cridland、Mark Crispin、Chris Newman、Elwyn Davies和Barry Leiba的评论和更正。
literal8 syntax was taken from RFC 3516.
literal8语法取自RFC3516。
Authors' Addresses
作者地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton，Middlesex，TW12 2BX英国
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Cyrus Daboo
塞勒斯·达布
EMail: cyrus@daboo.name
EMail: cyrus@daboo.name
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。