Internet Engineering Task Force (IETF) S. Brandt Request for Comments: 8508 Verizon Category: Standards Track January 2019 ISSN: 2070-1721
IMAP REPLACE Extension
Abstract
This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.
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 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8508.
Copyright Notice
Copyright (c) 2019 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 (https://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.
This document defines an IMAP ([RFC3501]) extension to facilitate the replacement of an existing message with a new one. This is accomplished by defining a new REPLACE command and extending the Unique Identifier (UID) command to allow UID REPLACE.
Since there is no replace function in the base IMAP specification, clients have instead had to use a combination of three separate commands issued in serial fashion; APPEND, STORE, and EXPUNGE. Pipelining of these three commands is not recommended since failure of any individual command should prevent subsequent commands from being executed lest the original message version be lost.
Because of the non-atomic nature of the existing sequence, interruptions can leave messages in intermediate states that can be seen and acted upon by other clients. Such interruptions can also strand older revisions of messages, thereby forcing the user to manually clean up multiple revisions of the same message in order to avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even
Brandt Standards Track [Page 2]
RFC 8508 IMAP REPLACE Extension January 2019
though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence.
In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED, and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the three-command sequence. Server developers are encouraged to implement REPLACE as an atomic operation to simplify error handling, minimize operational concerns, and reduce potential security problems. For systems where this is not possible, communication with the requesting client must ensure no confusion of message store state. A server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
Responses: no specific responses for this command
Brandt Standards Track [Page 3]
RFC 8508 IMAP REPLACE Extension January 2019
Result: OK - replace completed NO - replace error; can't remove specified message or can't add new message content BAD - command unknown or arguments invalid
Example: C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) C: From: Fritz Schmidt <fritz.ze@example.org> C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: <B238822388-0100000@example.org> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: S: * OK [APPENDUID 1 2000] Replacement Message ready S: * 5 EXISTS S: * 4 EXPUNGE S: A003 OK Replace completed
This extends the first form of the UID command (see Section 6.4.8 of [RFC3501]) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than a sequence number as its first parameter.
Example: C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) C: From: Fritz Schmidt <fritz.ze@example.org> C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: <B238822389-0100000@example.org> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: Hopefully next year you can join us. C: S: * OK [APPENDUID 1 2001] Replacement Message ready S: * 5 EXISTS S: * 4 EXPUNGE S: A004 OK Replace completed
The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the message specified by the message identifier will be removed from the selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence:
1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE
In the cited sequence, the quota implications of APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as "\Deleted".
Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the intermediate states do not occur and the response codes are different. In particular, the response codes for APPEND and EXPUNGE will be returned while those for the STORE operation MUST NOT be generated.
When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed.
While it may be common for the named mailbox argument to match the selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to replace a message in the \Drafts special-use mailbox (see Section 2 of [RFC6154]) with a message in the \Sent special-use mailbox following message submission.
Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such as TRYCREATE (see Section 6.3.11 of [RFC3501]), along with those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions.
Unlike the APPEND command, which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Additionally, the REPLACE extension intentionally follows the convention for UID commands found in Section 6.4.8 of [RFC3501] in that the UID variant of the command does not support use from the authenticated state.
The Access Control List (ACL) rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current mailbox, and APPEND in the target mailbox.
Servers supporting both REPLACE and CATENATE [RFC4469] MUST support the additional append-data and resp-text-code elements defined in Section 5 ("Formal Syntax") of [RFC4469] in conjunction with the REPLACE command. When combined with CATENATE, REPLACE can become quite an efficient way of message manipulation.
Brandt Standards Track [Page 6]
RFC 8508 IMAP REPLACE Extension January 2019
Example:
User composes message and attaches photo ---------------------------------------- C: A010 APPEND Drafts (\Seen \Draft) {1201534} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) C: From: Fritz Schmidt <fritz.ze@example.org> C: Message-ID: <B238822388-0100003@example.org> C: MIME-Version: 1.0 C: Content-Type: multipart/mixed; C: boundary="------------030305060306060609050804" C: C: --------------030305060306060609050804 C: Content-Type: text/plain; charset=utf-8; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Here is picture from the fireworks C: C: Yours... C: Fritz C: C: --------------030305060306060609050804 C: Content-Type: image/jpeg; C: name="Fireworks.jpg" C: Content-Transfer-Encoding: base64 C: Content-Disposition: attachment; C: filename="Fireworks.jpg" C: <large base64 encoded part goes here> C: C: --------------030305060306060609050804-- S: A010 OK [APPENDUID 1 3002] APPEND complete
User completes message with To: and Subject: fields --------------------------------------------------- C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} S: + Ready for literal data C: To: Mitzy <miss.mitzy@example.org> C: Subject: My view of the fireworks C: URL "/Drafts/;UID=3002") S: * OK [APPENDUID 1 3003] Replacement Message ready S: * 5 EXISTS S: * 4 EXPUNGE S: A011 OK REPLACE completed
Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information, see Section 3 of [RFC4315]. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. (Sending APPENDUID in the tagged OK as described in the UIDPLUS specification means that the client first receives EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.)
REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by REPLACE, no action will be taken that results in an imap.cause of FLAG.
Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of [RFC7162] are particularly relevant for this condition.
Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return different EMAILIDs for both the replaced and replacing messages. The only exception to this is the case outlined in Section 5.1 ("EMAILID Identifier for Identical Messages") of [RFC8474] when the server detects that both messages' immutable content is identical.
The REPLACE extension has no interaction with MULTIAPPEND [RFC3502]. This document explicitly does not outline a method for replacing multiple messages concurrently.
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability","command-select", "mailbox", "seq-number", and "uid". [RFC4466] defines the non-terminal "append-message".
Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
This document is believed to add no security problems beyond those that may already exist with the base IMAP specification. The REPLACE command may actually prevent some potential security problems because it avoids intermediate message states that could possibly be exploited by an attacker.
The author would like to thank the participants of IMAPEXT with particular thanks to Arnt Gulbrandsen, Alexey Melnikov, Chris Newman, and Bron Gondwana for their specific contributions.
Author's Address
Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 United States of America