Internet Message Access Protocol (IMAP) - MOVE Extension
Schweppermannstr. 8D-81671 MuenchenGermany+49 89 4502 9758arnt@gulbrandsen.priv.noOracle800 Royal OaksMonroviaCA91016-6347USAned+ietf@mrochek.com
Applications
IMAP
This document defines an IMAP extension consisting of two new commands, MOVE
and UID MOVE, that are used to move messages from one mailbox to another.
This document defines an IMAP extension to facilitate
moving messages from one mailbox to another. This is accomplished by defining
a new MOVE command and extending the UID command to allow
UID MOVE.
A move function is not provided in the base IMAP specification, so clients have
instead had to use a combination of the COPY, STORE, and EXPUNGE commands to
perform this very common operation.
Implementors have long pointed out some shortcomings with this
approach. Because the moving of a message is not an atomic process,
interruptions can leave messages in intermediate states. Because
multiple clients can be accessing the mailboxes at the same time,
clients can see messages in intermediate states even without
interruptions. If the source mailbox contains other messages that are
flagged for deletion, the third step can have the side effect of
expunging more than just the set of moved messages. Additionally, servers with
certain types of back-end message stores might have efficient ways of
moving messages, which don't involve the actual copying of data. Such
efficiencies are often not available to the COPY/STORE/EXPUNGE
process.
The MOVE extension is present in any IMAP4 implementation that
returns "MOVE" as one of the supported capabilities to the
CAPABILITY command.
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 .
Formal syntax is specified using ABNF .
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server.
This extends the first form of the UID command (see ,
Section 6.4.8) to add the MOVE command defined above as a valid argument.
The MOVE command takes two arguments: a message set (sequence
numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each
message included in the set is moved, rather than copied, from
the selected (source) mailbox to the named (target) mailbox.
This means that a new message is created in the target mailbox
with a new UID, the original message is removed from the source
mailbox, and it appears to the client as a single action. This
has the same effect for each message as this sequence:
[UID] COPY
[UID] STORE +FLAGS.SILENT \DELETED
UID EXPUNGE
Although the effect of the MOVE is the same as the preceding steps,
the semantics are not identical: The intermediate states produced by
those steps do not occur, and the response codes are different. In
particular, though the COPY and EXPUNGE response codes will be returned,
response codes for a STORE MUST NOT be generated and the \DELETED
flag MUST NOT be set for any message.
Because a MOVE applies to a set of messages, it might fail partway
through the set. Regardless of whether the command is successful in
moving the entire set, each individual message SHOULD either be moved
or unaffected. The server MUST leave each message in a state where
it is in at least one of the source or target mailboxes (no message can
be lost or orphaned). The server SHOULD NOT leave any message in
both mailboxes (it would be bad for a partial failure to result in a bunch
of duplicate messages). This is true even if the server returns a tagged
NO response to the command.
Because of the similarity of MOVE to COPY, extensions that
affect COPY affect MOVE in the same way. Response codes such as
TRYCREATE (see , Section 6.4.7), as well as those
defined by extensions, are sent as appropriate. See
for more information about how MOVE interacts with other IMAP extensions.
An example:
Note that the server may send unrelated EXPUNGE responses as well, if
any happen to have been expunged at the same time; this is normal
IMAP operation.
Implementers will need to read to understand what UID
EXPUNGE does, though full implementation of is not
necessary.
Note that moving a message to the currently selected mailbox
(that is, where the source and target mailboxes are the same)
is allowed when copying the message to the currently selected mailbox is allowed.
The server may send EXPUNGE (or VANISHED) responses before the tagged
response, so the client cannot safely send more commands with message
sequence number arguments while the server is processing MOVE or UID MOVE.
Both MOVE and UID MOVE can be pipelined with other commands, but care
has to be taken. Both commands modify sequence numbers and also allow
unrelated EXPUNGE responses. The renumbering of other messages in the
source mailbox following any EXPUNGE response can be surprising and
makes it unsafe to pipeline any command that relies on message sequence
numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be pipelined
with a command that might cause message renumbering. See
, Section 5.5, for more information about ambiguities
as well as handling requirements for both clients and servers.
This section describes how MOVE interacts with some other IMAP extensions.
The QUOTA extension (defined by ) may interact with
MOVE on some servers, in the sense that a MOVE command may succeed where COPY
would cause a quota overrun.
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.
Servers supporting UIDPLUS SHOULD send COPYUID
in response to a UID MOVE command. For additional information see
Section 3 of .
Servers implementing UIDPLUS are also advised to
send the COPYUID response code in an untagged OK before sending EXPUNGE or
moved responses. (Sending COPYUID in the tagged OK, as described in the UIDPLUS
specification, means that clients first receive an EXPUNGE for a
message and afterwards COPYUID for the same message. It can be
unnecessarily difficult to process that sequence usefully.)
The QRESYNC extension states that the server SHOULD
send VANISHED
rather than EXPUNGE in response to the UID EXPUNGE command.
The same requirement applies to MOVE, and a QRESYNC-enabled client
needs to handle both VANISHED and EXPUNGE responses to a UID MOVE
command.
If the server is capable of storing modification sequences for the
selected mailbox, it MUST increment the per-mailbox mod-sequence if
at least one message was permanently moved due to the execution of
the MOVE/UID MOVE command. For each permanently removed message,
the server MUST remember the incremented mod-sequence and corresponding
UID. If at least one message was moved, the server MUST send the
updated per-mailbox modification sequence using the HIGHESTMODSEQ
response code (defined in ) in the tagged or untagged
OK response.
When one or more messages are moved to a target mailbox, if the server is
capable of storing modification sequences for the mailbox, the server MUST
generate and assign new modification sequence numbers to the moved messages
that are higher than the highest modification sequence of the messages
originally in the mailbox.
MOVE applies to IMAP events in Sieve
in the same way
as COPY does. Therefore, MOVE can cause a Sieve script to be
invoked with the imap.cause set to "COPY". Because MOVE does not
cause flags to be changed, a MOVE command will not result in a
script invocation with the imap.cause set to "FLAG".
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in .
defines the non-terminals "capability",
"command-select", "sequence-set", and "mailbox".
Except as noted otherwise, all alphabetic characters are case insensitive. The
use of upper or lower case characters to define token strings is for editorial
clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
MOVE does not introduce any new capabilities to IMAP, and this limits
the security impact. However, the transactional semantics of MOVE may
interact with specific implementations in ways that could have
unexpected consequences. For example, moving messages between mailboxes
under the quota root may require temporary suspension of quota checking.
An additional area of concern is interaction with antispam, antivirus,
and other security scanning and auditing mechanisms. Different mailboxes
may have different security policies that could interact with MOVE
in complex ways. Scanning with updated rules may also be required
when messages are moved even when the underlying policy has not changed.
MOVE does relieve a problem with the base specification, since client
authors currently have to devise and implement complicated algorithms to
handle partial failures of the STORE/COPY/EXPUNGE trio. Incomplete or
improper implementation of these algorithms can lead to mail loss.
The IANA has added MOVE to the "IMAP 4 Capabilities"
registry, <http://www.iana.org/assignments/imap4-capabilities>.
This document is dedicated to the memory of Mark Crispin, the inventor
of the IMAP protocol, author of the IMAP protocol specification , and contributor to many other email specifications in the IETF.
An extension like this has been proposed many times, by many people.
This document is based on several of those proposals, most recently that by
Witold Krecicki. Witold, Benoit Claise, Adrien W. de Croy, Stephen Farrell,
Bron Gondwana, Dan Karp, Christian Ketterer, Murray Kucherawy, Jan Kundrat,
Barry Leiba, Alexey Melnikov, Kathleen Moriarty, Zoltan Ordogh,
Pete Resnick, Timo Sirainen, Michael Slusarz, and others provided valuable comments.