7Internet Engineering Task Force (IETF) A. Gulbrandsen
8Request for Comments: 6851
9Category: Standards Track N. Freed, Ed.
14 Internet Message Access Protocol (IMAP) - MOVE Extension
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
24 This is an Internet Standards Track document.
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.
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.
38 Copyright (c) 2013 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
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.
58Gulbrandsen & Freed Standards Track [Page 1]
60RFC 6851 IMAP - MOVE Extension January 2013
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
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.
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.
87 The MOVE extension is present in any IMAP implementation that returns
88 "MOVE" as one of the supported capabilities to the CAPABILITY
912. Conventions Used in This Document
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].
97 Formal syntax is specified using ABNF [RFC5234].
99 Example lines prefaced by "C:" are sent by the client and ones
100 prefaced by "S:" by the server.
114Gulbrandsen & Freed Standards Track [Page 2]
116RFC 6851 IMAP - MOVE Extension January 2013
123 Arguments: sequence set
126 Responses: no specific responses for this command
128 Result: OK - move completed
130 NO - move error: can't move those messages or to that name
132 BAD - command unknown or arguments invalid
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
1403.3. Semantics of MOVE and UID MOVE
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.
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:
154 2. [UID] STORE +FLAGS.SILENT \DELETED
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.
170Gulbrandsen & Freed Standards Track [Page 3]
172RFC 6851 IMAP - MOVE Extension January 2013
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.
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.
193 C: a UID MOVE 42:69 foo
194 S: * OK [COPYUID 432432 42:69 1202:1229]
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
203 Implementers will need to read [RFC4315] to understand what UID
204 EXPUNGE does, though full implementation of [RFC4315] is not
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
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
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
226Gulbrandsen & Freed Standards Track [Page 4]
228RFC 6851 IMAP - MOVE Extension January 2013
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
2364. Interaction with Other Extensions
238 This section describes how MOVE interacts with some other IMAP
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.
2474.2. RFC 4314, Access Control List (ACL)
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.
2524.3. RFC 4315, UIDPLUS
255 to a UID MOVE command. For additional information see Section 3 of
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.)
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
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
282Gulbrandsen & Freed Standards Track [Page 5]
284RFC 6851 IMAP - MOVE Extension January 2013
287 updated per-mailbox modification sequence using the HIGHESTMODSEQ
288 response code (defined in [RFC4551]) in the tagged or untagged OK
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.
2974.5. IMAP Events in Sieve
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".
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
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.
319 command-select =/ move
321 uid = "UID" SP (copy / fetch / search / store / move)
3236. Security Considerations
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
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
338Gulbrandsen & Freed Standards Track [Page 6]
340RFC 6851 IMAP - MOVE Extension January 2013
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.
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
3537. IANA Considerations
355 The IANA has added MOVE to the "IMAP 4 Capabilities" registry,
356 <http://www.iana.org/assignments/imap4-capabilities>.
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.
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.
3759.1. Normative References
377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
378 Requirement Levels", BCP 14, RFC 2119, March 1997.
380 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
381 4rev1", RFC 3501, March 2003.
383 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
384 RFC 4314, December 2005.
386 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
387 UIDPLUS extension", RFC 4315, December 2005.
394Gulbrandsen & Freed Standards Track [Page 7]
396RFC 6851 IMAP - MOVE Extension January 2013
399 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
400 STORE Operation or Quick Flag Changes Resynchronization",
403 [RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4
404 Extensions for Quick Mailbox Resynchronization", RFC 5162,
407 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
408 Specifications: ABNF", STD 68, RFC 5234, January 2008.
4109.2. Informative References
412 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
415 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol
416 (IMAP) Events in Sieve", RFC 6785, November 2012.
425 Fax: +49 89 4502 9758
426 EMail: arnt@gulbrandsen.priv.no
432 Monrovia, CA 91016-6347
435 EMail: ned+ietf@mrochek.com
450Gulbrandsen & Freed Standards Track [Page 8]