Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 7377 Huawei Technologies
Obsoletes: 6237 A. Melnikov
Updates: 4466 Isode Limited
Category: Standards Track October 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 7377 Huawei Technologies
Obsoletes: 6237 A. Melnikov
Updates: 4466 Isode Limited
Category: Standards Track October 2014
ISSN: 2070-1721
IMAP4 Multimailbox SEARCH Extension
IMAP4多邮箱搜索扩展
Abstract
摘要
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.
IMAP4规范仅允许搜索所选邮箱。用户通常希望搜索多个邮箱，而希望支持此功能的客户端必须发出一系列SELECT和search命令，等待每个命令完成后再转到下一个。此扩展允许客户端使用一个命令搜索多个邮箱，从而限制了多次往返造成的延迟，并且不需要中断当前选定的邮箱。此扩展还使用ESEARCH响应中的邮箱、UIDVality和标记字段，允许客户机选择时通过管道进行搜索。本文件更新了RFC 4466，淘汰了RFC 6237。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7377.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7377.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. New ESEARCH Command . . . . . . . . . . . . . . . . . . . . . 3
2.1. The ESEARCH Response . . . . . . . . . . . . . . . . . . . 4
2.2. Source Options: Specifying Mailboxes to Search . . . . . . 5
2.3. Strictness in Search Matches . . . . . . . . . . . . . . . 7
2.4. Server-Side Limitations on Search Volume . . . . . . . . . 7
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Changes since RFC 6237 . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. New ESEARCH Command . . . . . . . . . . . . . . . . . . . . . 3
2.1. The ESEARCH Response . . . . . . . . . . . . . . . . . . . 4
2.2. Source Options: Specifying Mailboxes to Search . . . . . . 5
2.3. Strictness in Search Matches . . . . . . . . . . . . . . . 7
2.4. Server-Side Limitations on Search Volume . . . . . . . . . 7
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Changes since RFC 6237 . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. The commands can't be pipelined, because the server might run them in parallel and the untagged SEARCH responses could not then be distinguished from each other.
IMAP4规范仅允许搜索所选邮箱。用户通常希望搜索多个邮箱，而希望支持此功能的客户端必须发出一系列SELECT和search命令，等待每个命令完成后再转到下一个。这些命令无法通过管道传输，因为服务器可能会并行运行它们，并且无法将未标记的搜索响应彼此区分开来。
This extension allows a client to search multiple mailboxes with one command and includes MAILBOX and TAG fields in the ESEARCH response, yielding the following advantages:
此扩展允许客户端使用一个命令搜索多个邮箱，并在ESEARCH响应中包含邮箱和标记字段，具有以下优点：
o A single command limits the number of round trips needed to search a set of mailboxes.
o 单个命令可限制搜索一组邮箱所需的往返次数。
o A single command eliminates the need to wait for one search to complete before starting the next.
o 只需一个命令，无需等待一次搜索完成后再开始下一次搜索。
o A single command allows the server to optimize the search if it can.
o 只要一个命令，服务器就可以优化搜索。
o A command that is not dependent upon the selected mailbox eliminates the need to disrupt the selection state or to open another IMAP connection.
o 不依赖于所选邮箱的命令无需中断选择状态或打开另一个IMAP连接。
o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466].
o 响应中的邮箱、UIDVality和标记字段允许客户端区分哪些响应与哪个搜索（以及哪个邮箱）匹配。客户端可以安全地通过管道传输这些搜索命令，而不会出现混淆的危险。添加邮箱和UIDVALIDITY字段将更新[RFC4466]中定义的搜索相关器项。
This extension was previously published in an Experimental RFC. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. A brief summary of changes is in Section 7.
该扩展先前发表在一篇实验性RFC上。现在有了实施经验，对协议有了信心，因此本文档将扩展放在标准轨道上，并根据实施经验进行了一些小的更新。第7节简要概述了这些变化。
In examples, "C:" indicates lines sent by a client that is connected to a server, and "S:" indicates lines sent by the server to the client.
在示例中，“C:”表示连接到服务器的客户端发送的线路，“S:”表示服务器发送到客户端的线路。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Arguments: OPTIONAL source options OPTIONAL result options OPTIONAL charset specification (see [RFC2978]) searching criteria (one or more)
参数：可选源选项可选结果选项可选字符集规范（请参见[RFC2978]）搜索条件（一个或多个）
Responses: REQUIRED untagged response: ESEARCH
响应：必需的未标记响应：ESEARCH
Result: OK -- search completed
NO -- error: cannot search that charset or criteria
BAD -- command unknown or arguments invalid
Result: OK -- search completed
NO -- error: cannot search that charset or criteria
BAD -- command unknown or arguments invalid
This section defines a new ESEARCH command, which works similarly to the UID SEARCH command described in Section 2.6.1 of [RFC4466] (initially described in Section 6.4.4 of [RFC3501] and extended by [RFC4731]).
本节定义了一个新的ESEARCH命令，其工作原理类似于[RFC4466]第2.6.1节中描述的UID搜索命令（最初在[RFC3501]第6.4.4节中描述，并由[RFC4731]扩展）。
The ESEARCH command further extends searching by allowing for optional source and result options. This document does not define any new result options (see Section 3.1 of [RFC4731]). A server that supports this extension includes "MULTISEARCH" in its IMAP capability string.
ESEARCH命令通过允许可选的源和结果选项进一步扩展搜索。本文件未定义任何新的结果选项（见[RFC4731]第3.1节）。支持此扩展的服务器在其IMAP功能字符串中包含“MULTISEARCH”。
Because there has been confusion about this, it is worth pointing out that with ESEARCH, as with any SEARCH or UID SEARCH command, it MUST NOT be considered an error if the search terms include a range of message numbers that extends (or, in fact, starts) beyond the end of the mailbox. For example, a client might want to establish a rolling window through the search results this way:
由于对这一点存在混淆，因此值得指出的是，对于ESEARCH，与任何搜索或UID搜索命令一样，如果搜索词包含延伸（或实际上开始）到邮箱末尾以外的消息编号范围，则不得将其视为错误。例如，客户机可能希望通过以下方式通过搜索结果建立滚动窗口：
C: tag1 UID ESEARCH FROM "frobozz" 1:100
C:tag1 UID从“泡沫”中搜索1:100
... followed later by this:
... 随后是：
C: tag1 UID ESEARCH FROM "frobozz" 101:200
C:tag1 UID E从“泡沫”101:200开始搜索
... and so on.
... 等等
This tells the server to match only the first hundred messages in the mailbox the first time, the second hundred the second time, etc. In fact, it might likely allow the server to optimize the search significantly. In the above example, whether the mailbox contains 50, 150, or 250 messages, neither of the search commands shown will result in an error. It is up to the client to know when to stop moving its search window.
这会告诉服务器第一次只匹配邮箱中的前一百封邮件，第二次匹配第二百封邮件，等等。事实上，这可能会让服务器显著优化搜索。在上面的示例中，无论邮箱包含50、150或250封邮件，显示的搜索命令都不会导致错误。由客户端决定何时停止移动其搜索窗口。
In response to an ESEARCH command, the server MUST return ESEARCH responses [RFC4731] (that is, not SEARCH responses). Because message numbers are not useful for mailboxes that are not selected, the responses MUST contain information about UIDs, not message numbers. This is true even if the source options specify that only the selected mailbox be searched.
为了响应ESEARCH命令，服务器必须返回ESEARCH响应[RFC4731]（即，不是搜索响应）。由于邮件编号对于未选中的邮箱不有用，因此响应必须包含有关UID的信息，而不是邮件编号。即使源选项指定只搜索选定的邮箱，这也是正确的。
Presence of a source option in the absence of a result option implies the "ALL" result option (see Section 3.1 of [RFC4731]). Note that this is not the same as the result from the SEARCH command described in the IMAP base protocol [RFC3501].
在没有结果选项的情况下存在源选项意味着“全部”结果选项（见[RFC4731]第3.1节）。请注意，这与IMAP基本协议[RFC3501]中描述的搜索命令的结果不同。
Source options describe which mailboxes must be searched for messages. An ESEARCH command with source options does not affect which mailbox, if any, is currently selected, regardless of which mailboxes are searched.
源选项描述必须在哪些邮箱中搜索邮件。带有源选项的ESEARCH命令不会影响当前选择的邮箱（如果有的话），无论搜索哪个邮箱。
For each mailbox satisfying the source options, a single ESEARCH response MUST be returned if any messages in that mailbox match the search criteria. An ESEARCH response MUST NOT be returned for mailboxes that contain no matching messages. This is true even when result options such as MIN, MAX, and COUNT are specified (see Section 3.1 of [RFC4731]), and the values returned (lowest UID matched, highest UID matched, and number of messages matched, respectively) apply to the mailbox reported in that ESEARCH response.
对于满足源选项的每个邮箱，如果该邮箱中的任何邮件符合搜索条件，则必须返回单个ESEARCH响应。对于不包含匹配邮件的邮箱，不得返回ESEARCH响应。即使指定了最小值、最大值和计数等结果选项（请参见[RFC4731]的第3.1节），并且返回的值（分别为匹配的最低UID、最高UID和匹配的邮件数）适用于该ESEARCH响应中报告的邮箱，这也是正确的。
Note that it is possible for an ESEARCH command to return no untagged responses (no ESEARCH responses at all) in the case that there are no matches to the search in any of the mailboxes that satisfy the source options. Clients can detect this situation by finding the tagged OK response without having received any matching untagged ESEARCH responses.
请注意，如果满足源选项的任何邮箱中没有与搜索匹配的内容，则ESEARCH命令可能不会返回任何未标记的响应（根本没有ESEARCH响应）。客户端可以通过查找带标记的OK响应来检测这种情况，而无需接收任何匹配的未标记ESEARCH响应。
Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY correlators. Correlators allow clients to issue several ESEARCH commands at once (pipelined). If the SEARCHRES [RFC5182] extension is used in an ESEARCH command, that ESEARCH command MUST be executed by the server after all previous SEARCH/ESEARCH commands have completed and before any subsequent SEARCH/ESEARCH commands are executed. The server MAY perform consecutive ESEARCH commands in parallel as long as none of them use the SEARCHRES extension.
每个ESEARCH响应必须包含邮箱、标记和UIDVality相关器。相关器允许客户端一次发出多个ESEARCH命令（流水线）。如果在ESEARCH命令中使用SEARCHRES[RFC5182]扩展名，则服务器必须在所有先前的搜索/ESEARCH命令完成后和执行任何后续搜索/ESEARCH命令之前执行该ESEARCH命令。只要没有使用SEARCHRES扩展，服务器就可以并行执行连续的ESEARCH命令。
The source options, if present, MUST contain a mailbox specifier as defined in the IMAP NOTIFY extension [RFC5465], Section 6 (using the "filter-mailboxes" ABNF item), with the following differences:
源选项（如果存在）必须包含IMAP NOTIFY extension[RFC5465]第6节（使用“筛选器邮箱”ABNF项）中定义的邮箱说明符，但有以下区别：
1. The "selected-delayed" specifier is not valid here.
1. “所选延迟”说明符在此处无效。
2. A "subtree-one" specifier is added. The "subtree" specifier results in a search of the specified mailbox and all selectable mailboxes that are subordinate to it, through an indefinitely
2. 添加了“子树1”说明符。“子树”说明符通过一个
deep hierarchy. The "subtree-one" specifier results in a search of the specified mailbox and all selectable child mailboxes, one hierarchy level down.
深层层次。“subtree one”说明符搜索指定邮箱和所有可选子邮箱，向下搜索一个层次结构级别。
If "subtree" is specified, the server MUST defend against loops in the hierarchy (for example, those caused by recursive file-system links within the message store). The server SHOULD do this by keeping track of the mailboxes that have been searched and by terminating the hierarchy traversal when a repeat is found. If it cannot do that, it MAY do it by limiting the hierarchy depth.
如果指定了“subtree”，服务器必须防御层次结构中的循环（例如，由消息存储中的递归文件系统链接引起的循环）。服务器应该通过跟踪已搜索的邮箱以及在发现重复时终止层次结构遍历来完成此操作。如果它不能做到这一点，它可以通过限制层次深度来做到这一点。
If the source options are not present, the value "selected" is assumed -- that is, only the currently selected mailbox is searched.
如果源选项不存在，则假定值为“selected”——即只搜索当前选定的邮箱。
The "personal" source option is a particularly convenient way to search all of the current user's mailboxes. Note that there is no way to use wildcard characters to search all mailboxes; the "mailboxes" source option does not do wildcard expansion.
“个人”源选项是搜索当前用户所有邮箱的一种特别方便的方法。请注意，无法使用通配符搜索所有邮箱；“邮箱”源选项不进行通配符扩展。
If the source options include (or default to) "selected", the IMAP session MUST be in "selected" state. If the source options specify other mailboxes and NOT "selected", then the IMAP session MUST be in either "selected" or "authenticated" state. If the session is not in a correct state, the ESEARCH command MUST return a "BAD" result.
如果源选项包括（或默认为“已选择”），则IMAP会话必须处于“已选择”状态。如果源选项指定了其他邮箱而未“选中”，则IMAP会话必须处于“选中”或“已验证”状态。如果会话未处于正确状态，则ESEARCH命令必须返回“坏”结果。
The client SHOULD NOT provide source options that resolve to including the same mailbox more than once. A server can, of course, remove the duplicates before processing, but the server MAY return "BAD" to an ESEARCH command with duplicate source mailboxes.
客户端不应提供解析为多次包含同一邮箱的源选项。当然，服务器可以在处理之前删除重复项，但服务器可能会将“BAD”返回给具有重复源邮箱的ESEARCH命令。
If the server supports the SEARCHRES [RFC5182] extension, then the "SAVE" result option is valid only if "selected" is specified or defaulted to as the sole mailbox to be searched. If any source option other than "selected" is specified, the ESEARCH command MUST return a "BAD" result.
如果服务器支持SEARCHRES[RFC5182]扩展，“保存”结果选项只有在指定或默认为“已选择”作为要搜索的唯一邮箱时才有效。如果指定了“selected”以外的任何源选项，则ESEARCH命令必须返回“BAD”结果。
If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT extension [RFC5267], then the following additional rules apply:
如果服务器支持CONTEXT=SEARCH和/或CONTEXT=SORT扩展[RFC5267]，则以下附加规则适用：
o The CONTEXT return option (Section 4.2 of [RFC5267]) can be used with an ESEARCH command.
o 上下文返回选项（RFC5267的第4.2节）可与ESEARCH命令一起使用。
o If the UPDATE return option is used (Section 4.3 of [RFC5267]), it MUST apply only to the currently selected mailbox. If UPDATE is used and there is no mailbox currently selected, the ESEARCH command MUST return a "BAD" result.
o 如果使用更新返回选项（RFC5267的第4.3节），则该选项必须仅适用于当前选定的邮箱。如果使用更新且当前未选择邮箱，则ESEARCH命令必须返回“坏”结果。
o The PARTIAL search return option (Section 4.4 of [RFC5267]) can be used and applies to each mailbox searched by the ESEARCH command.
o 部分搜索返回选项（RFC5267的第4.4节）可用于并应用于通过ESEARCH命令搜索的每个邮箱。
If the server supports the Access Control List (ACL) [RFC4314] extension, then the logged-in user is required to have the "r" right for each mailbox she wants to search. In addition, any mailboxes that are not explicitly named (accessed through "personal" or "subtree", for example) are required to have the "l" right. Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing. In particular, ESEARCH responses MUST NOT be returned for those mailboxes.
如果服务器支持访问控制列表（ACL）[RFC4314]扩展，则登录用户需要对其要搜索的每个邮箱拥有“r”权限。此外，任何未明确命名（例如通过“个人”或“子树”访问）的邮箱都需要具有“l”权限。ESEARCH命令处理必须忽略与源选项匹配且登录用户没有足够权限的邮箱。特别是，不得为这些邮箱返回ESEARCH响应。
The base IMAP SEARCH command (Section 6.4.4. of [RFC3501]) requires strict substring matching in text searches. Many servers, however, use search engines that match strings in different ways, for example, matching "swim" to both "swam" and "swum" or only doing full word matching (where "swim" will not match "swimming"). This is covered by the "Fuzzy Search" extension to IMAP [RFC6203], and that extension is compatible with this one and can be combined with it.
基本IMAP搜索命令（RFC3501的第6.4.4节）要求在文本搜索中进行严格的子字符串匹配。然而，许多服务器使用搜索引擎以不同的方式匹配字符串，例如，将“swim”与“swam”和“swum”匹配，或者只进行全词匹配（其中“swim”与“swiming”不匹配）。IMAP[RFC6203]的“模糊搜索”扩展涵盖了这一点，该扩展与此扩展兼容，并且可以与之结合。
Whether or not Fuzzy Search is implemented or used, this extension explicitly allows flexible searching with respect to TEXT and BODY searches. Servers MAY use fuzzy text matching in multimailbox searches.
无论是否实现或使用模糊搜索，此扩展都明确允许灵活搜索文本和正文搜索。服务器可以在多邮箱搜索中使用模糊文本匹配。
To avoid having a search use more than a reasonable share of server resources, servers MAY apply limits that go beyond loop protection, such as limits on the number of mailboxes that may be searched at once and/or limits on the number or total size of messages searched. A server can apply those limits up front, responding with "NO [LIMIT]" if a limit is exceeded (see [RFC5530] for information about response codes). Alternatively, a server can process the search and terminate it when a limit is exceeded, responding with "OK [LIMIT]" and returning partial results. Note that searches that return partial results can cause complexity for client implementations and confusion to users.
为避免搜索使用的服务器资源超过合理份额，服务器可能会应用超出循环保护范围的限制，例如对一次可搜索的邮箱数量的限制和/或对搜索的邮件数量或总大小的限制。服务器可以预先应用这些限制，如果超过限制，则响应“NO[LIMIT]”（有关响应代码的信息，请参阅[RFC5530]）。或者，服务器可以处理搜索并在超过限制时终止搜索，响应“OK[limit]”并返回部分结果。请注意，返回部分结果的搜索可能会导致客户端实现的复杂性和用户的困惑。
In the following example, note that two ESEARCH commands are pipelined and that the server is running them in parallel, interleaving a response to the second search amid the responses to the first (watch the tags).
在下面的示例中，请注意两个ESEARCH命令是流水线的，服务器并行运行它们，将对第二个搜索的响应与对第一个搜索的响应交错（注意标记）。
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2")
subject "chad"
S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
4001,4003,4005,4007,4009
S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
3001:3004,3788
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
UID ALL 3002,4004
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID
ALL 921691
S: tag1 OK done
S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
1111111) UID ALL 50003,50006,50009,50012
S: tag2 OK done
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2")
subject "chad"
S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
4001,4003,4005,4007,4009
S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
3001:3004,3788
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
UID ALL 3002,4004
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID
ALL 921691
S: tag1 OK done
S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
1111111) UID ALL 50003,50006,50009,50012
S: tag2 OK done
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC3501], [RFC5465], or [RFC4466].
以下语法规范使用了[RFC5234]中所述的增广Backus-Naur形式（ABNF）。此处未定义的术语取自[RFC3501]、[RFC5465]或[RFC4466]。
command-auth =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.
命令auth=/esearch；从IMAP库[RFC3501]更新定义；添加新的“esearch”命令。
command-select =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.
命令select=/esearch；从IMAP库[RFC3501]更新定义；添加新的“esearch”命令。
filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox) ; Update definition from IMAP Notify [RFC5465]. ; Add new "subtree-one" selector.
筛选邮箱其他=/（“子树一”SP一个或多个邮箱）；从IMAP Notify[RFC5465]更新定义；添加新的“子树一号”选择器。
filter-mailboxes-selected = "selected" ; Update definition from IMAP Notify [RFC5465]. ; We forbid the use of "selected-delayed".
筛选选定邮箱=“已选定”；从IMAP Notify[RFC5465]更新定义；我们禁止使用“选择延迟”。
one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
("UIDVALIDITY" SP nz-number)
; Each correlator MUST appear exactly once.
one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
("UIDVALIDITY" SP nz-number)
; Each correlator MUST appear exactly once.
scope-option = scope-option-name [SP scope-option-value] ; No options defined here. Syntax for future extensions.
范围选项=范围选项名称[SP范围选项值]；此处未定义任何选项。未来扩展的语法。
scope-option-name = tagged-ext-label ; No options defined here. Syntax for future extensions.
范围选项名称=标记的外部标签；此处未定义任何选项。未来扩展的语法。
scope-option-value = tagged-ext-val ; No options defined here. Syntax for future extensions.
范围选项值=标记的外部值；此处未定义任何选项。未来扩展的语法。
scope-options = scope-option *(SP scope-option) ; A given option may only appear once. ; No options defined here. Syntax for future extensions.
范围选项=范围选项*（SP范围选项）；给定选项只能出现一次；此处未定义任何选项。未来扩展的语法。
esearch = "ESEARCH" [SP esearch-source-opts] [SP search-return-opts] SP search-program
esearch=“esearch”[SP esearch source opts][SP search return opts]SP search程序
search-correlator = SP "(" one-correlator *(SP one-correlator) ")" ; Updates definition in IMAP4 ABNF [RFC4466].
搜索相关器=SP“（“一个相关器*（SP一个相关器）”）”；更新IMAP4 ABNF[RFC4466]中的定义。
esearch-source-opts = "IN" SP "(" source-mbox [SP "(" scope-options ")"] ")"
esearch source opts=“在“SP”（“源mbox[SP”（“范围选项”）”]）”
source-mbox = filter-mailboxes *(SP filter-mailboxes)
; "filter-mailboxes" is defined in IMAP Notify [RFC5465].
; See updated definition of filter-mailboxes-other, above.
; See updated definition of filter-mailboxes-selected, above.
source-mbox = filter-mailboxes *(SP filter-mailboxes)
; "filter-mailboxes" is defined in IMAP Notify [RFC5465].
; See updated definition of filter-mailboxes-other, above.
; See updated definition of filter-mailboxes-selected, above.
This new IMAP ESEARCH command allows a single command to search many mailboxes at once. On the one hand, a client could do that by sending many IMAP SEARCH commands. On the other hand, this makes it easier for a client to overwork a server by sending a single command that results in an expensive search of tens of thousands of mailboxes. Server implementations need to be aware of that and provide mechanisms that prevent a client from adversely affecting other users. Limitations on the number of mailboxes that may be searched in one command and/or on the server resources that will be devoted to responding to a single client, are reasonable limitations for an implementation to impose (see also Section 2.4).
这个新的IMAP ESEARCH命令允许单个命令一次搜索多个邮箱。一方面，客户端可以通过发送许多IMAP搜索命令来实现这一点。另一方面，这使得客户端更容易通过发送单个命令对服务器进行过度工作，从而导致对数以万计的邮箱进行昂贵的搜索。服务器实现需要意识到这一点，并提供防止客户端对其他用户产生不利影响的机制。对一个命令中可以搜索的邮箱数量和/或对用于响应单个客户端的服务器资源的限制是实施的合理限制（另请参见第2.4节）。
Implementations MUST, of course, apply access controls appropriately, limiting a user's access to ESEARCH in the same way its access is limited for any other IMAP commands. This extension has no data-access risks beyond what may exist in the unextended IMAP implementation.
当然，实现必须适当地应用访问控制，限制用户对ESEARCH的访问，就像限制用户对任何其他IMAP命令的访问一样。此扩展没有超出未扩展IMAP实现中可能存在的数据访问风险。
Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing (see the paragraph about this in Section 2.2). In particular, any attempt to distinguish insufficient access from non-existent mailboxes may expose information about the mailbox hierarchy that isn't otherwise available to the client.
ESEARCH命令处理必须忽略与登录用户缺乏足够权限的源选项相匹配的邮箱（请参阅第2.2节中的相关段落）。特别是，任何区分访问不足和不存在邮箱的尝试都可能会暴露有关邮箱层次结构的信息，而这些信息对于客户端来说是不可用的。
If "subtree" is specified, the server MUST defend against loops in the hierarchy (see the paragraph about this in Section 2.2).
如果指定了“subtree”，服务器必须防御层次结构中的循环（请参阅第2.2节中关于此的段落）。
The "Internet Message Access Protocol (IMAP) Capabilities Registry" is currently located at <http://www.iana.org/assignments/imap-capabilities>.
“Internet消息访问协议（IMAP）功能注册表”当前位于<http://www.iana.org/assignments/imap-capabilities>.
IANA has changed the reference for the IMAP capability "MULTISEARCH" to point to this document.
IANA已将IMAP功能“多搜索”的参考更改为指向本文档。
o Change to Standards Track.
o 转向标准轨道。
o Added paragraph about duplicate mailboxes.
o 添加了关于重复邮箱的段落。
o Added Section 2.3 about Fuzzy Search.
o 增加了关于模糊搜索的第2.3节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月<http://www.rfc-editor.org/info/rfc2978>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005, <http://www.rfc-editor.org/info/rfc4314>.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，2005年12月<http://www.rfc-editor.org/info/rfc4314>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006, <http://www.rfc-editor.org/info/rfc4466>.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC4466，2006年4月<http://www.rfc-editor.org/info/rfc4466>.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006, <http://www.rfc-editor.org/info/rfc4731>.
[RFC4731]Melnikov，A.和D.Cridland，“用于控制返回何种信息的搜索命令的IMAP4扩展”，RFC 47312006年11月<http://www.rfc-editor.org/info/rfc4731>.
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, March 2008, <http://www.rfc-editor.org/info/rfc5182>.
[RFC5182]Melnikov，A.，“引用最后搜索结果的IMAP扩展”，RFC 51822008年3月<http://www.rfc-editor.org/info/rfc5182>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008, <http://www.rfc-editor.org/info/rfc5267>.
[RFC5267]Cridland，D.和C.King，“IMAP4的上下文”，RFC 52672008年7月<http://www.rfc-editor.org/info/rfc5267>.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009, <http://www.rfc-editor.org/info/rfc5465>.
[RFC5465]Gulbrandsen，A.，King，C.，和A.Melnikov，“IMAP通知扩展”，RFC 54652009年2月<http://www.rfc-editor.org/info/rfc5465>.
[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530, May 2009, <http://www.rfc-editor.org/info/rfc5530>.
[RFC5530]Gulbrandsen，A.，“IMAP响应代码”，RFC5530，2009年5月<http://www.rfc-editor.org/info/rfc5530>.
[RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC 6203, March 2011, <http://www.rfc-editor.org/info/rfc6203>.
[RFC6203]Sirainen，T.，“模糊搜索的IMAP4扩展”，RFC62032011年3月<http://www.rfc-editor.org/info/rfc6203>.
Acknowledgments
致谢
The authors gratefully acknowledge feedback provided by Timo Sirainen, Peter Coates, Arnt Gulbrandsen, and Chris Newman.
作者感谢Timo Sirainen、Peter Coates、Arnt Gulbrandsen和Chris Newman提供的反馈。
Authors' Addresses
作者地址
Barry Leiba Huawei Technologies
巴里·雷巴华为技术有限公司
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Alexey Melnikov Isode Limited 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Limited 14 Castle Mews Hampton，英国米德尔塞克斯TW12 2NP
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/