1 ../imapserver/server.go:144
2
3
4
5
6
7Internet Engineering Task Force (IETF) A. Gulbrandsen
8Request for Comments: 6851
9Category: Standards Track N. Freed, Ed.
10ISSN: 2070-1721 Oracle
11 January 2013
12
13
14 Internet Message Access Protocol (IMAP) - MOVE Extension
15
16Abstract
17
18 This document defines an IMAP extension consisting of two new
19 commands, MOVE and UID MOVE, that are used to move messages from one
20 mailbox to another.
21
22Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc6851.
35
36Copyright Notice
37
38 Copyright (c) 2013 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
40
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
50
51
52
53
54
55
56
57
58Gulbrandsen & Freed Standards Track [Page 1]
59
60RFC 6851 IMAP - MOVE Extension January 2013
61
62
631. Introduction
64
65 This document defines an IMAP [RFC3501] extension to facilitate
66 moving messages from one mailbox to another. This is accomplished by
67 defining a new MOVE command and extending the UID command to allow
68 UID MOVE.
69
70 A move function is not provided in the base IMAP specification, so
71 clients have instead had to use a combination of the COPY, STORE, and
72 EXPUNGE commands to perform this very common operation.
73
74 Implementors have long pointed out some shortcomings with this
75 approach. Because the moving of a message is not an atomic process,
76 interruptions can leave messages in intermediate states. Because
77 multiple clients can be accessing the mailboxes at the same time,
78 clients can see messages in intermediate states even without
79 interruptions. If the source mailbox contains other messages that
80 are flagged for deletion, the third step can have the side effect of
81 expunging more than just the set of moved messages. Additionally,
82 servers with certain types of back-end message stores might have
83 efficient ways of moving messages, which don't involve the actual
84 copying of data. Such efficiencies are often not available to the
85 COPY/STORE/EXPUNGE process.
86
87 The MOVE extension is present in any IMAP implementation that returns
88 "MOVE" as one of the supported capabilities to the CAPABILITY
89 command.
90
912. Conventions Used in This Document
92
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
95 document are to be interpreted as described in [RFC2119].
96
97 Formal syntax is specified using ABNF [RFC5234].
98
99 Example lines prefaced by "C:" are sent by the client and ones
100 prefaced by "S:" by the server.
101
102
103
104
105
106
107
108
109
110
111
112
113
114Gulbrandsen & Freed Standards Track [Page 2]
115
116RFC 6851 IMAP - MOVE Extension January 2013
117
118
1193. MOVE and UID MOVE 9051:4650 6851:265 ../imapserver/server.go:3482
120
1213.1. MOVE Command
122
123 Arguments: sequence set
124 mailbox name
125
126 Responses: no specific responses for this command
127
128 Result: OK - move completed
129
130 NO - move error: can't move those messages or to that name
131
132 BAD - command unknown or arguments invalid
133
1343.2. UID MOVE Command
135
136 This extends the first form of the UID command (see [RFC3501],
137 Section 6.4.8) to add the MOVE command defined above as a valid
138 argument.
139
1403.3. Semantics of MOVE and UID MOVE
141
142 The MOVE command takes two arguments: a message set (sequence numbers
143 for MOVE, UIDs for UID MOVE) and a named mailbox. Each message
144 included in the set is moved, rather than copied, from the selected
145 (source) mailbox to the named (target) mailbox.
146
147 This means that a new message is created in the target mailbox with a
148 new UID, the original message is removed from the source mailbox, and
149 it appears to the client as a single action. This has the same
150 effect for each message as this sequence:
151
152 1. [UID] COPY
153
154 2. [UID] STORE +FLAGS.SILENT \DELETED
155
156 3. UID EXPUNGE
157
158 Although the effect of the MOVE is the same as the preceding steps,
159 the semantics are not identical: The intermediate states produced by
160 those steps do not occur, and the response codes are different. In
161 particular, though the COPY and EXPUNGE response codes will be
162 returned, response codes for a STORE MUST NOT be generated and the
163 \DELETED flag MUST NOT be set for any message.
164
165
166
167
168
169
170Gulbrandsen & Freed Standards Track [Page 3]
171
172RFC 6851 IMAP - MOVE Extension January 2013
173
174
175 Because a MOVE applies to a set of messages, it might fail partway
176 through the set. Regardless of whether the command is successful in
177 moving the entire set, each individual message SHOULD either be moved
178 or unaffected. The server MUST leave each message in a state where
179 it is in at least one of the source or target mailboxes (no message
180 can be lost or orphaned). The server SHOULD NOT leave any message in
181 both mailboxes (it would be bad for a partial failure to result in a
182 bunch of duplicate messages). This is true even if the server
183 returns a tagged NO response to the command.
184
185 Because of the similarity of MOVE to COPY, extensions that affect
186 COPY affect MOVE in the same way. Response codes such as TRYCREATE
187 (see [RFC3501], Section 6.4.7), as well as those defined by
188 extensions, are sent as appropriate. See Section 4 for more
189 information about how MOVE interacts with other IMAP extensions.
190
191 An example:
192
193 C: a UID MOVE 42:69 foo
194 S: * OK [COPYUID 432432 42:69 1202:1229]
195 S: * 22 EXPUNGE
196 S: (more expunges)
197 S: a OK Done
198
199 Note that the server may send unrelated EXPUNGE responses as well, if
200 any happen to have been expunged at the same time; this is normal
201 IMAP operation.
202
203 Implementers will need to read [RFC4315] to understand what UID
204 EXPUNGE does, though full implementation of [RFC4315] is not
205 necessary.
206
207 Note that moving a message to the currently selected mailbox (that
208 is, where the source and target mailboxes are the same) is allowed
209 when copying the message to the currently selected mailbox is
210 allowed.
211
212 The server may send EXPUNGE (or VANISHED) responses before the tagged
213 response, so the client cannot safely send more commands with message
214 sequence number arguments while the server is processing MOVE or UID
215 MOVE.
216
217 Both MOVE and UID MOVE can be pipelined with other commands, but care
218 has to be taken. Both commands modify sequence numbers and also
219 allow unrelated EXPUNGE responses. The renumbering of other messages
220 in the source mailbox following any EXPUNGE response can be
221 surprising and makes it unsafe to pipeline any command that relies on
222 message sequence numbers after a MOVE or UID MOVE. Similarly, MOVE
223
224
225
226Gulbrandsen & Freed Standards Track [Page 4]
227
228RFC 6851 IMAP - MOVE Extension January 2013
229
230
231 cannot be pipelined with a command that might cause message
232 renumbering. See [RFC3501], Section 5.5, for more information about
233 ambiguities as well as handling requirements for both clients and
234 servers.
235
2364. Interaction with Other Extensions
237
238 This section describes how MOVE interacts with some other IMAP
239 extensions.
240
2414.1. RFC 2087, QUOTA
242
243 The QUOTA extension (defined by [RFC2087]) may interact with MOVE on
244 some servers, in the sense that a MOVE command may succeed where COPY
245 would cause a quota overrun.
246
2474.2. RFC 4314, Access Control List (ACL)
248
249 The ACL rights [RFC4314] required for MOVE and UID MOVE are the union
250 of the ACL rights required for UID STORE, UID COPY, and UID EXPUNGE.
251
2524.3. RFC 4315, UIDPLUS
253
254 Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response 9051:4708 ../imapserver/server.go:3613
255 to a UID MOVE command. For additional information see Section 3 of
256 [RFC4315].
257
258 Servers implementing UIDPLUS are also advised to send the COPYUID
259 response code in an untagged OK before sending EXPUNGE or moved
260 responses. (Sending COPYUID in the tagged OK, as described in the
261 UIDPLUS specification, means that clients first receive an EXPUNGE
262 for a message and afterwards COPYUID for the same message. It can be
263 unnecessarily difficult to process that sequence usefully.)
264
2654.4. RFC 5162, QRESYNC 9051:4650 6851:119 ../imapserver/server.go:3482
266
267 The QRESYNC extension [RFC5162] states that the server SHOULD send
268 VANISHED rather than EXPUNGE in response to the UID EXPUNGE command.
269 The same requirement applies to MOVE, and a QRESYNC-enabled client
270 needs to handle both VANISHED and EXPUNGE responses to a UID MOVE
271 command.
272
273 If the server is capable of storing modification sequences for the
274 selected mailbox, it MUST increment the per-mailbox mod-sequence if
275 at least one message was permanently moved due to the execution of
276 the MOVE/UID MOVE command. For each permanently removed message, the
277 server MUST remember the incremented mod-sequence and corresponding
278 UID. If at least one message was moved, the server MUST send the
279
280
281
282Gulbrandsen & Freed Standards Track [Page 5]
283
284RFC 6851 IMAP - MOVE Extension January 2013
285
286
287 updated per-mailbox modification sequence using the HIGHESTMODSEQ
288 response code (defined in [RFC4551]) in the tagged or untagged OK
289 response.
290
291 When one or more messages are moved to a target mailbox, if the
292 server is capable of storing modification sequences for the mailbox,
293 the server MUST generate and assign new modification sequence numbers
294 to the moved messages that are higher than the highest modification
295 sequence of the messages originally in the mailbox.
296
2974.5. IMAP Events in Sieve
298
299 MOVE applies to IMAP events in Sieve [RFC6785] in the same way as
300 COPY does. Therefore, MOVE can cause a Sieve script to be invoked
301 with the imap.cause set to "COPY". Because MOVE does not cause flags
302 to be changed, a MOVE command will not result in a script invocation
303 with the imap.cause set to "FLAG".
304
3055. Formal Syntax
306
307 The following syntax specification uses the Augmented Backus-Naur
308 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
309 the non-terminals "capability", "command-select", "sequence-set", and
310 "mailbox".
311
312 Except as noted otherwise, all alphabetic characters are case
313 insensitive. The use of upper or lower case characters to define
314 token strings is for editorial clarity only. Implementations MUST
315 accept these strings in a case-insensitive fashion.
316
317 capability =/ "MOVE"
318
319 command-select =/ move
320 move = "MOVE" SP sequence-set SP mailbox ../imapserver/server.go:3484
321 uid = "UID" SP (copy / fetch / search / store / move)
322
3236. Security Considerations
324
325 MOVE does not introduce any new capabilities to IMAP, and this limits
326 the security impact. However, the transactional semantics of MOVE
327 may interact with specific implementations in ways that could have
328 unexpected consequences. For example, moving messages between
329 mailboxes under the quota root may require temporary suspension of
330 quota checking.
331
332 An additional area of concern is interaction with antispam,
333 antivirus, and other security scanning and auditing mechanisms.
334 Different mailboxes may have different security policies that could
335
336
337
338Gulbrandsen & Freed Standards Track [Page 6]
339
340RFC 6851 IMAP - MOVE Extension January 2013
341
342
343 interact with MOVE in complex ways. Scanning with updated rules may
344 also be required when messages are moved even when the underlying
345 policy has not changed.
346
347 MOVE does relieve a problem with the base specification, since client
348 authors currently have to devise and implement complicated algorithms
349 to handle partial failures of the STORE/COPY/EXPUNGE trio.
350 Incomplete or improper implementation of these algorithms can lead to
351 mail loss.
352
3537. IANA Considerations
354
355 The IANA has added MOVE to the "IMAP 4 Capabilities" registry,
356 <http://www.iana.org/assignments/imap4-capabilities>.
357
3588. Acknowledgments
359
360 This document is dedicated to the memory of Mark Crispin, the
361 inventor of the IMAP protocol, author of the IMAP protocol
362 specification [RFC3501], and contributor to many other email
363 specifications in the IETF.
364
365 An extension like this has been proposed many times, by many people.
366 This document is based on several of those proposals, most recently
367 that by Witold Krecicki. Witold, Benoit Claise, Adrien W. de Croy,
368 Stephen Farrell, Bron Gondwana, Dan Karp, Christian Ketterer, Murray
369 Kucherawy, Jan Kundrat, Barry Leiba, Alexey Melnikov, Kathleen
370 Moriarty, Zoltan Ordogh, Pete Resnick, Timo Sirainen, Michael
371 Slusarz, and others provided valuable comments.
372
3739. References
374
3759.1. Normative References
376
377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
378 Requirement Levels", BCP 14, RFC 2119, March 1997.
379
380 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
381 4rev1", RFC 3501, March 2003.
382
383 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
384 RFC 4314, December 2005.
385
386 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
387 UIDPLUS extension", RFC 4315, December 2005.
388
389
390
391
392
393
394Gulbrandsen & Freed Standards Track [Page 7]
395
396RFC 6851 IMAP - MOVE Extension January 2013
397
398
399 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
400 STORE Operation or Quick Flag Changes Resynchronization",
401 RFC 4551, June 2006.
402
403 [RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4
404 Extensions for Quick Mailbox Resynchronization", RFC 5162,
405 March 2008.
406
407 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
408 Specifications: ABNF", STD 68, RFC 5234, January 2008.
409
4109.2. Informative References
411
412 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
413 January 1997.
414
415 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol
416 (IMAP) Events in Sieve", RFC 6785, November 2012.
417
418Authors' Addresses
419
420 Arnt Gulbrandsen
421 Schweppermannstr. 8
422 D-81671 Muenchen
423 Germany
424
425 Fax: +49 89 4502 9758
426 EMail: arnt@gulbrandsen.priv.no
427
428
429 Ned Freed (editor)
430 Oracle
431 800 Royal Oaks
432 Monrovia, CA 91016-6347
433 USA
434
435 EMail: ned+ietf@mrochek.com
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Gulbrandsen & Freed Standards Track [Page 8]
451
452