7377
PROPOSED STANDARD
IMAP4 Multimailbox SEARCH Extension
Authors: B. Leiba, A. Melnikov
Date: October 2014
Area: app
Working Group: appsawg
Stream: IETF
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.
RFC 7377
PROPOSED STANDARD
Errata Exist
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 7377 Huawei Technologies
Obsoletes: <a href="./rfc6237">6237</a> A. Melnikov
Updates: <a href="./rfc4466">4466</a> Isode Limited
Category: Standards Track October 2014
ISSN: 2070-1721
<span class="h1">IMAP4 Multimailbox SEARCH Extension</span>
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 <a href="./rfc4466">RFC 4466</a> and obsoletes <a href="./rfc6237">RFC 6237</a>.
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc7377">http://www.rfc-editor.org/info/rfc7377</a>.
<span class="grey">Leiba & Melnikov Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. New ESEARCH Command . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. The ESEARCH Response . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Source Options: Specifying Mailboxes to Search . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Strictness in Search Matches . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. Server-Side Limitations on Search Volume . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Changes since <a href="./rfc6237">RFC 6237</a> . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgments . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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.
<span class="grey">Leiba & Melnikov Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
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:
o A single command limits the number of round trips needed to search
a set of mailboxes.
o A single command eliminates the need to wait for one search to
complete before starting the next.
o A single command allows the server to optimize the search if it
can.
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 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 [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>].
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 <a href="#section-7">Section 7</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
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.
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. New ESEARCH Command</span>
Arguments: OPTIONAL source options
OPTIONAL result options
OPTIONAL charset specification (see [<a href="./rfc2978" title=""IANA Charset Registration Procedures"">RFC2978</a>])
searching criteria (one or more)
Responses: REQUIRED untagged response: ESEARCH
<span class="grey">Leiba & Melnikov Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
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 <a href="./rfc4466#section-2.6.1">Section 2.6.1 of [RFC4466]</a>
(initially described in <a href="./rfc3501#section-6.4.4">Section 6.4.4 of [RFC3501]</a> and extended by
[<a href="./rfc4731" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">RFC4731</a>]).
The ESEARCH command further extends searching by allowing for
optional source and result options. This document does not define
any new result options (see <a href="./rfc4731#section-3.1">Section 3.1 of [RFC4731]</a>). A server that
supports this extension includes "MULTISEARCH" in its IMAP capability
string.
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:
C: tag1 UID ESEARCH FROM "frobozz" 1:100
... followed later by this:
C: tag1 UID ESEARCH FROM "frobozz" 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.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. The ESEARCH Response</span>
In response to an ESEARCH command, the server MUST return ESEARCH
responses [<a href="./rfc4731" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">RFC4731</a>] (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.
<span class="grey">Leiba & Melnikov Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
Presence of a source option in the absence of a result option implies
the "ALL" result option (see <a href="./rfc4731#section-3.1">Section 3.1 of [RFC4731]</a>). Note that
this is not the same as the result from the SEARCH command described
in the IMAP base protocol [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>].
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.
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
<a href="./rfc4731#section-3.1">Section 3.1 of [RFC4731]</a>), 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.
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.
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 [<a href="./rfc5182" title=""IMAP Extension for Referencing the Last SEARCH Result"">RFC5182</a>] 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.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Source Options: Specifying Mailboxes to Search</span>
The source options, if present, MUST contain a mailbox specifier as
defined in the IMAP NOTIFY extension <a href="./rfc5465#section-6">[RFC5465], Section 6</a> (using the
"filter-mailboxes" ABNF item), with the following differences:
1. The "selected-delayed" specifier is not valid here.
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
<span class="grey">Leiba & Melnikov Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
deep hierarchy. The "subtree-one" specifier results in a search
of the specified mailbox and all selectable child mailboxes, one
hierarchy level down.
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.
If the source options are not present, the value "selected" is
assumed -- that is, only the currently selected mailbox is searched.
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.
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.
If the server supports the SEARCHRES [<a href="./rfc5182" title=""IMAP Extension for Referencing the Last SEARCH Result"">RFC5182</a>] 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.
If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT
extension [<a href="./rfc5267" title=""Contexts for IMAP4"">RFC5267</a>], then the following additional rules apply:
o The CONTEXT return option (<a href="./rfc5267#section-4.2">Section 4.2 of [RFC5267]</a>) can be used
with an ESEARCH command.
o If the UPDATE return option is used (<a href="./rfc5267#section-4.3">Section 4.3 of [RFC5267]</a>), 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.
<span class="grey">Leiba & Melnikov Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
o The PARTIAL search return option (<a href="./rfc5267#section-4.4">Section 4.4 of [RFC5267]</a>) can be
used and applies to each mailbox searched by the ESEARCH command.
If the server supports the Access Control List (ACL) [<a href="./rfc4314" title=""IMAP4 Access Control List (ACL) Extension"">RFC4314</a>]
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.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Strictness in Search Matches</span>
The base IMAP SEARCH command (<a href="./rfc3501#section-6.4.4">Section 6.4.4. of [RFC3501]</a>) 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 [<a href="./rfc6203" title=""IMAP4 Extension for Fuzzy Search"">RFC6203</a>], and that extension
is compatible with this one and can be combined with it.
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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Server-Side Limitations on Search Volume</span>
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 [<a href="./rfc5530" title=""IMAP Response Codes"">RFC5530</a>] 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Examples</span>
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).
<span class="grey">Leiba & Melnikov Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
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
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Formal Syntax</span>
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]. Terms not defined here are
taken from [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>], [<a href="./rfc5465" title=""The IMAP NOTIFY Extension"">RFC5465</a>], or [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>].
command-auth =/ esearch
; Update definition from IMAP base [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>].
; Add new "esearch" command.
command-select =/ esearch
; Update definition from IMAP base [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>].
; Add new "esearch" command.
filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox)
; Update definition from IMAP Notify [<a href="./rfc5465" title=""The IMAP NOTIFY Extension"">RFC5465</a>].
; Add new "subtree-one" selector.
filter-mailboxes-selected = "selected"
; Update definition from IMAP Notify [<a href="./rfc5465" title=""The IMAP NOTIFY Extension"">RFC5465</a>].
; We forbid the use of "selected-delayed".
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.
scope-option-name = tagged-ext-label
; No options defined here. Syntax for future extensions.
<span class="grey">Leiba & Melnikov Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
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.
esearch = "ESEARCH" [SP esearch-source-opts]
[SP search-return-opts] SP search-program
search-correlator = SP "(" one-correlator *(SP one-correlator) ")"
; Updates definition in IMAP4 ABNF [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>].
esearch-source-opts = "IN" SP "(" source-mbox [SP
"(" scope-options ")"] ")"
source-mbox = filter-mailboxes *(SP filter-mailboxes)
; "filter-mailboxes" is defined in IMAP Notify [<a href="./rfc5465" title=""The IMAP NOTIFY Extension"">RFC5465</a>].
; See updated definition of filter-mailboxes-other, above.
; See updated definition of filter-mailboxes-selected, above.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
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 <a href="#section-2.4">Section 2.4</a>).
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.
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 <a href="#section-2.2">Section 2.2</a>). 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.
<span class="grey">Leiba & Melnikov Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
If "subtree" is specified, the server MUST defend against loops in
the hierarchy (see the paragraph about this in <a href="#section-2.2">Section 2.2</a>).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
The "Internet Message Access Protocol (IMAP) Capabilities Registry"
is currently located at
<<a href="http://www.iana.org/assignments/imap-capabilities">http://www.iana.org/assignments/imap-capabilities</a>>.
IANA has changed the reference for the IMAP capability "MULTISEARCH"
to point to this document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Changes since <a href="./rfc6237">RFC 6237</a></span>
o Change to Standards Track.
o Added paragraph about duplicate mailboxes.
o Added <a href="#section-2.3">Section 2.3</a> about Fuzzy Search.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2978">RFC2978</a>] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", <a href="https://www.rfc-editor.org/bcp/bcp19">BCP 19</a>, <a href="./rfc2978">RFC 2978</a>, October 2000,
<<a href="https://www.rfc-editor.org/info/rfc2978">http://www.rfc-editor.org/info/rfc2978</a>>.
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003,
<<a href="https://www.rfc-editor.org/info/rfc3501">http://www.rfc-editor.org/info/rfc3501</a>>.
[<a id="ref-RFC4314">RFC4314</a>] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
<a href="./rfc4314">RFC 4314</a>, December 2005,
<<a href="https://www.rfc-editor.org/info/rfc4314">http://www.rfc-editor.org/info/rfc4314</a>>.
[<a id="ref-RFC4466">RFC4466</a>] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", <a href="./rfc4466">RFC 4466</a>, April 2006,
<<a href="https://www.rfc-editor.org/info/rfc4466">http://www.rfc-editor.org/info/rfc4466</a>>.
[<a id="ref-RFC4731">RFC4731</a>] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", <a href="./rfc4731">RFC 4731</a>, November 2006,
<<a href="https://www.rfc-editor.org/info/rfc4731">http://www.rfc-editor.org/info/rfc4731</a>>.
<span class="grey">Leiba & Melnikov Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc7377">RFC 7377</a> IMAP4 Multimailbox SEARCH Extension October 2014</span>
[<a id="ref-RFC5182">RFC5182</a>] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", <a href="./rfc5182">RFC 5182</a>, March 2008,
<<a href="https://www.rfc-editor.org/info/rfc5182">http://www.rfc-editor.org/info/rfc5182</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC5267">RFC5267</a>] Cridland, D. and C. King, "Contexts for IMAP4", <a href="./rfc5267">RFC 5267</a>,
July 2008, <<a href="https://www.rfc-editor.org/info/rfc5267">http://www.rfc-editor.org/info/rfc5267</a>>.
[<a id="ref-RFC5465">RFC5465</a>] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", <a href="./rfc5465">RFC 5465</a>, February 2009,
<<a href="https://www.rfc-editor.org/info/rfc5465">http://www.rfc-editor.org/info/rfc5465</a>>.
[<a id="ref-RFC5530">RFC5530</a>] Gulbrandsen, A., "IMAP Response Codes", <a href="./rfc5530">RFC 5530</a>, May
2009, <<a href="https://www.rfc-editor.org/info/rfc5530">http://www.rfc-editor.org/info/rfc5530</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC6203">RFC6203</a>] Sirainen, T., "IMAP4 Extension for Fuzzy Search", <a href="./rfc6203">RFC</a>
<a href="./rfc6203">6203</a>, March 2011,
<<a href="https://www.rfc-editor.org/info/rfc6203">http://www.rfc-editor.org/info/rfc6203</a>>.
Acknowledgments
The authors gratefully acknowledge feedback provided by Timo
Sirainen, Peter Coates, Arnt Gulbrandsen, and Chris Newman.
Authors' Addresses
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
EMail: [email protected]
URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a>
Alexey Melnikov
Isode Limited
14 Castle Mews
Hampton, Middlesex TW12 2NP
United Kingdom
EMail: [email protected]
URI: <a href="http://www.melnikov.ca/">http://www.melnikov.ca/</a>
Leiba & Melnikov Standards Track [Page 11]
Annotations
Select text to annotate