Message ORGanization Working Group B. Leiba
Internet-Draft Huawei Technologies
Updates: 4466 (if approved) A. Melnikov
Intended status: Standards Track Isode Limited
Expires: December 20, 2010 June 18, 2010
IMAP4 Multimailbox SEARCH Extension
draft-ietf-morg-multimailbox-search-03
Abstract
The IMAP4 specification allows the searching only of 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 round-trips and waiting for various
searches to complete, and not requiring disruption of the currently
selected mailbox. This also uses MAILBOX and TAG fields in ESEARCH
responses, allowing a client to pipeline the searches if it chooses.
Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
morg@ietf.org.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2010.
Copyright Notice
Leiba & Melnikov Expires December 20, 2010 [Page 1]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Extensions to UID SEARCH command . . . . . . . . . . . . . . 3
2.1. The ESEARCH response . . . . . . . . . . . . . . . . . . . . 4
2.2. Source options -- specifying mailboxes to search . . . . . . 5
3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Leiba & Melnikov Expires December 20, 2010 [Page 2]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
1. Introduction
The IMAP4 specification allows the searching only of 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.
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 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.
1.1. Conventions used in this document
In examples, "C:" indicates lines sent by a client that is connected
to a server. "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 RFC 2119 [RFC2119].
2. Extensions to UID SEARCH command
Leiba & Melnikov Expires December 20, 2010 [Page 3]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
Arguments: OPTIONAL source options
OPTIONAL result options
OPTIONAL charset specification (see [RFC2978])
searching criteria (one or more)
Responses: REQUIRED untagged response: ESEARCH
Result: OK - search completed
NO - error: cannot search that charset or criteria
BAD - command unknown or arguments invalid
This section further updates definition of 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]).
The UID SEARCH command is extended to allow 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 [[fix-for-pub-1: "X-DRAFT-I03-MMBX" (changes for
publication)]] in its IMAP capability string.
2.1. The ESEARCH response
Unless specified otherwise by a description of a result option, in
the presence of a search source option the server MUST return ESEARCH
responses [RFC4731] instead of the corresponding SEARCH responses.
Because message numbers are not useful for mailboxes that are not
selected, the responses need information about UIDs, not message
numbers. Therefore, this extension only applies to UID SEARCH, and
trying to specify source options on plain SEARCH results in a tagged
BAD response. This is true even if the source options specify that
only the selected mailbox be searched.
Presence of a source option in 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.
Source options describe which mailboxes must be searched for
messages. A UID SEARCH 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 section
Leiba & Melnikov Expires December 20, 2010 [Page 4]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
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.
Note that it is now possible for a UID SEARCH command to return *no*
untagged responses (no SEARCH nor ESEARCH responses), 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 UID SEARCH
commands at once (pipelined). The server MAY perform pipelined
searches in parallel; or it MAY instead serialize them.
2.2. Source options -- specifying mailboxes to search
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 changes:
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
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
terminating the hierarchy traversal when a repeat is found. If it
can not 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
Leiba & Melnikov Expires December 20, 2010 [Page 5]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
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 UID SEARCH command returns a "BAD" result.
If the server supports the 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 a
multimailbox search. In particular, ESEARCH responses MUST NOT be
returned for those mailboxes.
3. Open Issues
[[Issues: This is a section of To-Do items and considerations before
this draft is done. This section will be worked through, emptied,
and removed before we send this on.]]
Interaction with IMAP Contexts [RFC5267] needs to be defined.
Suggestion: UPDATE option of IMAP Notify [RFC5465] might have to be
prohibited when both Context and this extension are used. [Barry:
But why? Isn't this then the equivalent of doing many SEARCH
commands with the UPDATE option?]
There's a suggestion to add an EXCLUDE clause (with a nested search
criteria). For example, one might want to search "personal" but
exclude "mailboxes (Trash Spam)".
Cyrus suggests you can use metadata to tag mailboxes that you do or
don't want to search, and use search criteria to exclude them (good
for mailboxes that you NEVER want searched (as Trash and Spam,
above)).
4. Examples
C: tag1 UID SEARCH IN ((mailboxes "folder1" subtree "folder2"))
unseen
C: tag2 UID SEARCH 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 6789023554)
UID ALL 195001:195004,169788
S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
Leiba & Melnikov Expires December 20, 2010 [Page 6]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
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
5. Formal Syntax
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].
filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox)
; Update definition from IMAP Notify [RFC5465]
; Add new "subtree-one" selector.
filter-mailboxes-selected = "selected"
; Update definition from IMAP Notify [RFC5465]
; 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.
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.
search = "SEARCH" [SP search-source-opts] [SP search-return-opts]
SP search-program
; Updates definition in IMAP4 ABNF [RFC4466]
search-correlator = SP "(" one-correlator *(SP one-correlator) ")"
; Updates definition in IMAP4 ABNF [RFC4466]
Leiba & Melnikov Expires December 20, 2010 [Page 7]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
search-source-opts = "IN" SP "(" source-mbox [SP
"(" scope-options ")"] ")"
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.
6. Security Considerations
This extension to the IMAP UID SEARCH 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.
Implementations MUST, of course, apply access controls appropriately,
limiting a user's access to UID SEARCH in the same way its access is
limited for any other IMAP commands. This extension has no data-
access risks beyond what may be there in the unextended IMAP
implementation.
7. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located
here:
http://www.iana.org/assignments/imap4-capabilities
This document defines the IMAP capability [[fix-for-pub-2: X-DRAFT-
I03-MMBX (changes for publication)]], and IANA is asked to add it to
the registry.
8. Acknowledgements
The authors gratefully acknowledge feedback provided by Timo
Leiba & Melnikov Expires December 20, 2010 [Page 8]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
Sirainen, Peter Coates and Arnt Gulbrandsen.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, November 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
July 2008.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, February 2009.
Authors' Addresses
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Leiba & Melnikov Expires December 20, 2010 [Page 9]
Internet-Draft IMAP4 Multimailbox SEARCH Extension June 2010
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Leiba & Melnikov Expires December 20, 2010 [Page 10]