Internet Engineering Task Force (IETF) A. Gulbrandsen
Request for Comments: 6851
Category: Standards Track N. Freed, Ed.
ISSN: 2070-1721 Oracle
Internet Message Access Protocol (IMAP) - MOVE Extension
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gulbrandsen & Freed Standards Track [Page 1]RFC 6851 IMAP - MOVE Extension January 20131. Introduction
This document defines an IMAP [RFC3501] 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
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
The MOVE extension is present in any IMAP implementation that returns
"MOVE" as one of the supported capabilities to the CAPABILITY
2. Conventions Used in This Document
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 [RFC2119].
Formal syntax is specified using ABNF [RFC5234].
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server.
Gulbrandsen & Freed Standards Track [Page 2]RFC 6851 IMAP - MOVE Extension January 20133. MOVE and UID MOVE3.1. MOVE Command
Arguments: sequence set
Responses: no specific responses for this command
Result: OK - move completed
NO - move error: can't move those messages or to that name
BAD - command unknown or arguments invalid
3.2. UID MOVE Command
This extends the first form of the UID command (see [RFC3501],
Section 6.4.8) to add the MOVE command defined above as a valid
3.3. Semantics of MOVE and UID MOVE
The MOVE command takes two arguments: a message set (sequence numbers
for MOVE, UIDs for UID MOVE) and a named mailbox. Each message