1 ../imapserver/server.go:142
2
3
4
5
6
7Network Working Group A. Melnikov
8Request for Comments: 4731 Isode Ltd
9Category: Standards Track D. Cridland
10 Inventure Systems Ltd
11 November 2006
12
13
14 IMAP4 Extension to SEARCH Command for Controlling
15 What Kind of Information Is Returned
16
17Status of This Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25Copyright Notice
26
27 Copyright (C) The IETF Trust (2006).
28
29Abstract
30
31 This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands 9051:3716 4466:354 3501:2723 ../imapserver/search.go:20
32 with several result options, which can control what kind of
33 information is returned. The following result options are defined:
34 minimal value, maximal value, all found messages, and number of found
35 messages.
36
37Table of Contents
38
39 1. Introduction ....................................................2
40 2. Conventions Used in This Document ...............................2
41 3. IMAP Protocol Changes ...........................................2
42 3.1. New SEARCH/UID SEARCH Result Options .......................2
43 3.2. Interaction with CONDSTORE extension .......................4
44 4. Formal Syntax ...................................................5
45 5. Security Considerations .........................................6
46 6. IANA Considerations .............................................6
47 7. Normative References ............................................6
48 8. Acknowledgments .................................................6
49
50
51
52
53
54
55
56
57
58Melnikov & Cridland Standards Track [Page 1]
59
60RFC 4731 IMAP4 Extension to SEARCH November 2006
61
62
631. Introduction
64
65 [IMAPABNF] extended SEARCH and UID SEARCH commands with result
66 specifiers (also known as result options), which can control what
67 kind of information is returned.
68
69 A server advertising the ESEARCH capability supports the following
70 result options: minimal value, maximal value, all found messages,
71 and number of found messages. These result options allow clients to
72 get SEARCH results in more convenient forms, while also saving
73 bandwidth required to transport the results, for example, by finding
74 the first unseen message or returning the number of unseen or deleted
75 messages. Also, when a single MIN or a single MAX result option is
76 specified, servers can optimize execution of SEARCHes.
77
782. Conventions Used in This Document
79
80 In examples, "C:" and "S:" indicate lines sent by the client and
81 server, respectively.
82
83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
85 document are to be interpreted as described in RFC 2119 [KEYWORDS].
86
873. IMAP Protocol Changes
88
893.1. New SEARCH/UID SEARCH Result Options
90
91 The SEARCH/UID SEARCH commands are extended to allow for the
92 following result options:
93
94 MIN
95 Return the lowest message number/UID that satisfies the SEARCH
96 criteria.
97
98 If the SEARCH results in no matches, the server MUST NOT 9051:3758 ../imapserver/search.go:246
99 include the MIN result option in the ESEARCH response; however,
100 it still MUST send the ESEARCH response.
101
102 MAX
103 Return the highest message number/UID that satisfies the SEARCH
104 criteria.
105
106 If the SEARCH results in no matches, the server MUST NOT
107 include the MAX result option in the ESEARCH response; however,
108 it still MUST send the ESEARCH response.
109
110
111
112
113
114Melnikov & Cridland Standards Track [Page 2]
115
116RFC 4731 IMAP4 Extension to SEARCH November 2006
117
118
119 ALL
120 Return all message numbers/UIDs that satisfy the SEARCH
121 criteria. Unlike regular (unextended) SEARCH, the messages are
122 always returned using the sequence-set syntax. A sequence-set
123 representation may be more compact and can be used as is in a
124 subsequent command that accepts sequence-set. Note, the client
125 MUST NOT assume that messages/UIDs will be listed in any
126 particular order.
127
128 If the SEARCH results in no matches, the server MUST NOT
129 include the ALL result option in the ESEARCH response; however,
130 it still MUST send the ESEARCH response.
131
132 COUNT
133 Return number of the messages that satisfy the SEARCH criteria.
134 This result option MUST always be included in the ESEARCH
135 response.
136
137 If one or more result options described above are specified, the
138 extended SEARCH command MUST return a single ESEARCH response
139 [IMAPABNF], instead of the SEARCH response.
140
141 An extended UID SEARCH command MUST cause an ESEARCH response with
142 the UID indicator present.
143
144 Note that future extensions to this document can allow servers to
145 return multiple ESEARCH responses for a single extended SEARCH
146 command. These extensions will have to describe how results from
147 multiple ESEARCH responses are to be amalgamated.
148
149 If the list of result options is empty, that requests the server to 9051:3737 ../imapserver/search.go:52
150 return an ESEARCH response instead of the SEARCH response. This is
151 equivalent to "(ALL)".
152
153 Example: C: A282 SEARCH RETURN (MIN COUNT) FLAGGED 9051:3986 3501:2975 ../imapserver/search.go:21
154 SINCE 1-Feb-1994 NOT FROM "Smith"
155 S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
156 S: A282 OK SEARCH completed
157
158 Example: C: A283 SEARCH RETURN () FLAGGED
159 SINCE 1-Feb-1994 NOT FROM "Smith"
160 S: * ESEARCH (TAG "A283") ALL 2,10:11
161 S: A283 OK SEARCH completed
162
163 The following example demonstrates finding the first unseen message
164 as returned in the UNSEEN response code on a successful SELECT
165 command:
166
167
168
169
170Melnikov & Cridland Standards Track [Page 3]
171
172RFC 4731 IMAP4 Extension to SEARCH November 2006
173
174
175 Example: C: A284 SEARCH RETURN (MIN) UNSEEN
176 S: * ESEARCH (TAG "A284") MIN 4
177 S: A284 OK SEARCH completed
178
179 The following example demonstrates that if the ESEARCH UID indicator
180 is present, all data in the ESEARCH response is referring to UIDs;
181 for example, the MIN result specifier will be followed by a UID.
182
183 Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
184 S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
185 S: A285 OK SEARCH completed
186
187 The following example demonstrates returning the number of deleted
188 messages:
189
190 Example: C: A286 SEARCH RETURN (COUNT) DELETED
191 S: * ESEARCH (TAG "A286") COUNT 15
192 S: A286 OK SEARCH completed
193
1943.2. Interaction with CONDSTORE extension
195
196 When the server supports both the ESEARCH and the CONDSTORE
197 [CONDSTORE] extension, and the client requests one or more result
198 option described in section 3.1 together with the MODSEQ search
199 criterion in the same SEARCH/UID SEARCH command, then the server MUST
200 return the ESEARCH response containing the MODSEQ result option
201 (described in the following paragraph) instead of the extended SEARCH
202 response described in section 3.5 of [CONDSTORE].
203
204 If the SEARCH/UID SEARCH command contained a single MIN or MAX result
205 option, the MODSEQ result option contains the mod-sequence for the
206 found message. If the SEARCH/UID SEARCH command contained both MIN
207 and MAX result options and no ALL/COUNT option, the MODSEQ result
208 option contains the highest mod-sequence for the two returned
209 messages. Otherwise the MODSEQ result option contains the highest
210 mod-sequence for all messages being returned.
211
212 Example: The following example demonstrates how Example 15 from
213 [CONDSTORE] would look in the presence of one or more result option:
214
215 C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
216 all 620162338
217 S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
218 S: a1 OK Search complete
219
220 C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft"
221 all 620162338
222 S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
223
224
225
226Melnikov & Cridland Standards Track [Page 4]
227
228RFC 4731 IMAP4 Extension to SEARCH November 2006
229
230
231 S: a2 OK Search complete
232
233 C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft"
234 all 620162338
235 S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
236 S: a3 OK Search complete
237
238 C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft"
239 all 620162338
240 S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
241 S: a4 OK Search complete
242
2434. Formal Syntax
244
245 The following syntax specification uses the Augmented Backus-Naur
246 Form (ABNF) notation as specified in [ABNF].
247
248 Non-terminals referenced but not defined below are as defined by
249 [IMAP4], [CONDSTORE], or [IMAPABNF].
250
251 Except as noted otherwise, all alphabetic characters are case-
252 insensitive. The use of upper or lowercase characters to define
253 token strings is for editorial clarity only. Implementations MUST
254 accept these strings in a case-insensitive fashion.
255
256 capability =/ "ESEARCH"
257
258 search-return-data = "MIN" SP nz-number /
259 "MAX" SP nz-number /
260 "ALL" SP sequence-set /
261 "COUNT" SP number
262 ;; conforms to the generic
263 ;; search-return-data syntax defined
264 ;; in [IMAPABNF]
265
266 search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT"
267 ;; conforms to generic search-return-opt
268 ;; syntax defined in [IMAPABNF]
269
270 When the CONDSTORE [CONDSTORE] IMAP extension is also supported,
271 the ABNF is updated as follows:
272
273 search-return-data =/ "MODSEQ" SP mod-sequence-value 7162:1211 ../imapclient/parse.go:1190 ../imapserver/search.go:260
274 ;; mod-sequence-value is defined
275 ;; in [CONDSTORE]
276
277
278
279
280
281
282Melnikov & Cridland Standards Track [Page 5]
283
284RFC 4731 IMAP4 Extension to SEARCH November 2006
285
286
2875. Security Considerations
288
289 In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU
290 and/or IO intensive, and are seen by some as a potential attack point
291 for denial of service attacks, so some sites/implementations even
292 disable them entirely. This is quite unfortunate, as SEARCH command
293 is one of the best examples demonstrating IMAP advantage over POP3.
294
295 The ALL and COUNT return options don't change how SEARCH is working
296 internally; they only change how information about found messages is
297 returned. MIN and MAX SEARCH result options described in this
298 document can lighten the load on IMAP servers that choose to optimize
299 SEARCHes containing only one or both of them.
300
301 It is believed that this extension doesn't raise any additional
302 security concerns not already discussed in [IMAP4].
303
3046. IANA Considerations
305
306 IMAP4 capabilities are registered by publishing a standards track RFC
307 or an IESG-approved experimental RFC. The registry is currently
308 located at <http://www.iana.org/assignments/imap4-capabilities>.
309
310 This document defines the ESEARCH IMAP capability, which IANA added
311 to the registry.
312
3137. Normative References
314
315 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
316 Requirement Levels", BCP 14, RFC 2119, March 1997.
317
318 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
319 4rev1", RFC 3501, March 2003.
320
321 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for
322 Syntax Specifications: ABNF", RFC 4234, October 2005.
323
324 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
325 ABNF", RFC 4466, April 2006..
326
327 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
328 STORE", RFC 4551, June 2006.
329
3308. Acknowledgments
331
332 Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin,
333 and Pete Maclean for comments and corrections.
334
335
336
337
338Melnikov & Cridland Standards Track [Page 6]
339
340RFC 4731 IMAP4 Extension to SEARCH November 2006
341
342
343Authors' Addresses
344
345 Alexey Melnikov
346 Isode Limited
347 5 Castle Business Village
348 36 Station Road
349 Hampton, Middlesex, TW12 2BX
350 UK
351
352 EMail: Alexey.Melnikov@isode.com
353
354
355 Dave A. Cridland
356 Inventure Systems Limited
357
358 EMail: dave.cridland@inventuresystems.co.uk
359 URL: http://invsys.co.uk/dave/
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Melnikov & Cridland Standards Track [Page 7]
395
396RFC 4731 IMAP4 Extension to SEARCH November 2006
397
398
399Full Copyright Statement
400
401 Copyright (C) The IETF Trust (2006).
402
403 This document is subject to the rights, licenses and restrictions
404 contained in BCP 78, and except as set forth therein, the authors
405 retain all their rights.
406
407 This document and the information contained herein are provided on an
408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
410 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
411 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
412 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
413 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
414 PURPOSE.
415
416Intellectual Property
417
418 The IETF takes no position regarding the validity or scope of any
419 Intellectual Property Rights or other rights that might be claimed to
420 pertain to the implementation or use of the technology described in
421 this document or the extent to which any license under such rights
422 might or might not be available; nor does it represent that it has
423 made any independent effort to identify any such rights. Information
424 on the procedures with respect to rights in RFC documents can be
425 found in BCP 78 and BCP 79.
426
427 Copies of IPR disclosures made to the IETF Secretariat and any
428 assurances of licenses to be made available, or the result of an
429 attempt made to obtain a general license or permission for the use of
430 such proprietary rights by implementers or users of this
431 specification can be obtained from the IETF on-line IPR repository at
432 http://www.ietf.org/ipr.
433
434 The IETF invites any interested party to bring to its attention any
435 copyrights, patents or patent applications, or other proprietary
436 rights that may cover technology that may be required to implement
437 this standard. Please address the information to the IETF at
438 ietf-ipr@ietf.org.
439
440Acknowledgement
441
442 Funding for the RFC Editor function is currently provided by the
443 Internet Society.
444
445
446
447
448
449
450Melnikov & Cridland Standards Track [Page 8]
451
452