Internet Message Access Protocol (IMAP) - MOVE Extension
Extracted elements (22)
MOVE is defined to have the same observable effect as COPY + STORE \Deleted + UID EXPUNGE but without producing the intermediate states those steps would generate. This preserves the semantics of related extensions (e.g., TRYCREATE response codes still apply) while eliminating the window for partial-failure inconsistencies.
MOVE was introduced because the existing COPY/STORE/EXPUNGE sequence for moving messages is non-atomic: interruptions or concurrent clients can observe intermediate states, and expunging can affect more messages than intended if other messages are already flagged \Deleted. Servers with efficient backend stores also cannot exploit those efficiencies through the three-step process.
For QRESYNC-enabled servers, MOVE must follow the same VANISHED-instead-of-EXPUNGE requirement as UID EXPUNGE; a QRESYNC-enabled client must handle both VANISHED and EXPUNGE responses to a UID MOVE command.
MOVE applies to IMAP events in Sieve (RFC 6785) the same way COPY does: a MOVE can cause a Sieve script to be invoked with imap.cause set to "COPY". Because MOVE does not change flags, a MOVE will never trigger a Sieve invocation with imap.cause set to "FLAG".
Servers supporting UIDPLUS (RFC 4315) SHOULD send the COPYUID response code in response to a UID MOVE command, and are advised to send it in an untagged OK before sending EXPUNGE or moved responses so that clients receive COPYUID before the corresponding EXPUNGE.
The ACL rights required for MOVE and UID MOVE are the union of the ACL rights required for UID STORE, UID COPY, and UID EXPUNGE as defined by RFC 4314.
The QUOTA extension (RFC 2087) may interact with MOVE such that a MOVE command succeeds where a COPY would cause a quota overrun, because the server can account for the fact that the source message will be removed.
Although MOVE has the same effect as [UID] COPY + [UID] STORE +FLAGS.SILENT \Deleted + UID EXPUNGE, response codes for a STORE MUST NOT be generated and the \Deleted flag MUST NOT be set for any message during a MOVE operation.
Each individual message in a MOVE set SHOULD either be moved or left unaffected; partial moves that leave a message in an ambiguous state are not acceptable.
If a MOVE fails partway through a message set, the server MUST leave each affected message in a state where it is in at least one of the source or target mailboxes — no message may be lost or orphaned — even if the server returns a tagged NO response.
If the server stores modification sequences for the selected mailbox and at least one message was permanently moved, the server MUST increment the per-mailbox mod-sequence, remember the incremented mod-sequence and corresponding UID for each moved message, and send the updated HIGHESTMODSEQ response code in the tagged or untagged OK response.
The capability token for this extension is "MOVE"; the MOVE extension is present in any IMAP implementation that returns "MOVE" among its supported capabilities.
The server may send EXPUNGE (or VANISHED) responses before the tagged response to MOVE, so the client MUST NOT safely send more commands with message sequence number arguments while the server is processing MOVE or UID MOVE.
The server SHOULD NOT leave any message in both the source and target mailboxes after a partial MOVE failure, to avoid creating duplicate messages.
When messages are moved to a target mailbox, if the server stores modification sequences for that mailbox, it MUST generate and assign new modification sequence numbers to the moved messages that are higher than the highest modification sequence of any message originally in that mailbox.
The MOVE command takes a sequence set (message sequence numbers) and a mailbox name as arguments. It moves each message in the set from the currently selected source mailbox to the named target mailbox, creating a new message with a new UID in the target and removing the original from the source, appearing to the client as a single atomic action.
UID MOVE extends the UID command form to accept MOVE as a valid argument, using UIDs rather than sequence numbers to identify the messages to be moved.
IANA has added "MOVE" to the IMAP 4 Capabilities registry at http://www.iana.org/assignments/imap4-capabilities.
MOVE may interact with antispam, antivirus, and other security scanning and auditing mechanisms in complex ways, since different mailboxes may have different security policies. Rescanning with updated rules may be required even when the underlying policy has not changed.
MOVE reduces the risk of mail loss that arises from incomplete or improper client implementation of the COPY/STORE/EXPUNGE partial-failure recovery algorithms that were previously required to simulate an atomic move.
MOVE's transactional semantics may interact with quota implementations in unexpected ways, such as requiring temporary suspension of quota checking when moving messages between mailboxes under the same quota root.
ABNF for MOVE: capability =/ "MOVE"; command-select =/ move; move = "MOVE" SP sequence-set SP mailbox; uid = "UID" SP (copy / fetch / search / store / move). All alphabetic characters in command strings are case-insensitive.