7Internet Engineering Task Force (IETF) S. Brandt
8Request for Comments: 8508 Verizon
9Category: Standards Track January 2019
13 IMAP REPLACE Extension
17 This document defines an IMAP extension that can be used to replace
18 an existing message in a message store with a new message. Message
19 replacement is a common operation for clients that automatically save
20 drafts or notes as a user composes them.
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 7841.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc8508.
38 Copyright (c) 2019 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 (https://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.
58Brandt Standards Track [Page 1]
60RFC 8508 IMAP REPLACE Extension January 2019
65 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3
68 3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3
69 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3
70 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4
71 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5
72 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6
73 4. Interaction with Other Extensions . . . . . . . . . . . . . . 6
74 4.1. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
75 4.2. CATENATE . . . . . . . . . . . . . . . . . . . . . . . . 6
76 4.3. UIDPLUS . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 4.4. IMAP Events in Sieve . . . . . . . . . . . . . . . . . . 8
78 4.5. CONDSTORE/QRESYNC . . . . . . . . . . . . . . . . . . . . 8
79 4.6. OBJECTID . . . . . . . . . . . . . . . . . . . . . . . . 8
80 4.7. MULTIAPPEND . . . . . . . . . . . . . . . . . . . . . . . 8
81 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
85 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
86 8.2. Informative References . . . . . . . . . . . . . . . . . 10
87 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
92 This document defines an IMAP ([RFC3501]) extension to facilitate the
93 replacement of an existing message with a new one. This is
94 accomplished by defining a new REPLACE command and extending the
95 Unique Identifier (UID) command to allow UID REPLACE.
97 Since there is no replace function in the base IMAP specification,
98 clients have instead had to use a combination of three separate
99 commands issued in serial fashion; APPEND, STORE, and EXPUNGE.
100 Pipelining of these three commands is not recommended since failure
101 of any individual command should prevent subsequent commands from
102 being executed lest the original message version be lost.
104 Because of the non-atomic nature of the existing sequence,
105 interruptions can leave messages in intermediate states that can be
106 seen and acted upon by other clients. Such interruptions can also
107 strand older revisions of messages, thereby forcing the user to
108 manually clean up multiple revisions of the same message in order to
109 avoid wasteful quota consumption. Additionally, the existing
110 sequence can fail on APPEND due to an over-quota condition even
114Brandt Standards Track [Page 2]
116RFC 8508 IMAP REPLACE Extension January 2019
119 though the subsequent STORE/EXPUNGE would free up enough space for
120 the newly revised message. And finally, server efficiencies may be
121 possible with a single logical message replacement operation as
122 compared to the existing APPEND/STORE/EXPUNGE sequence.
124 In its simplest form, the REPLACE command is a single-command
125 encapsulation of APPEND, STORE +flags \DELETED, and UID EXPUNGE for a
126 message, except that it avoids any of the quota implications or
127 intermediate states associated with the three-command sequence.
128 Server developers are encouraged to implement REPLACE as an atomic
129 operation to simplify error handling, minimize operational concerns,
130 and reduce potential security problems. For systems where this is
131 not possible, communication with the requesting client must ensure no
132 confusion of message store state. A server MUST NOT generate a
133 response code for the STORE +flags \DELETED portion of the sequence.
134 Additionally, servers supporting the REPLACE command MUST NOT infer
135 any inheritance of content, flags, or annotations from the message
1382. Conventions Used in This Document
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
142 "OPTIONAL" in this document are to be interpreted as described in
143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
144 capitals, as shown here.
146 Formal syntax is defined by [RFC5234].
148 Example lines prefaced by "C:" are sent by the client, and ones
149 prefaced by "S:" are sent by the server.
1513. REPLACE and UID REPLACE
1533.1. Advertising Support for REPLACE
155 Servers that implement the REPLACE extension will return "REPLACE" as
156 one of the supported capabilities in the CAPABILITY command response.
160 Arguments: message sequence number
162 OPTIONAL flag parenthesized list
163 OPTIONAL date/time string
166 Responses: no specific responses for this command
170Brandt Standards Track [Page 3]
172RFC 8508 IMAP REPLACE Extension January 2019
175 Result: OK - replace completed
176 NO - replace error; can't remove specified message
177 or can't add new message content
178 BAD - command unknown or arguments invalid
181 C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
182 S: + Ready for literal data
183 C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
184 C: From: Fritz Schmidt <fritz.ze@example.org>
185 C: Subject: happy new year !!
186 C: To: miss.mitzy@example.org
187 C: Message-Id: <B238822388-0100000@example.org>
189 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
191 C: Just saw the best fireworks show. Wish you were here.
193 S: * OK [APPENDUID 1 2000] Replacement Message ready
196 S: A003 OK Replace completed
1983.3. UID REPLACE Command
200 This extends the first form of the UID command (see Section 6.4.8 of
201 [RFC3501]) to add the REPLACE command defined above as a valid
202 argument. This form of REPLACE uses a UID rather than a sequence
203 number as its first parameter.
206 C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
207 S: + Ready for literal data
208 C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
209 C: From: Fritz Schmidt <fritz.ze@example.org>
210 C: Subject: happy new year !!
211 C: To: miss.mitzy@example.org
212 C: Message-Id: <B238822389-0100000@example.org>
214 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
216 C: Just saw the best fireworks show. Wish you were here.
217 C: Hopefully next year you can join us.
219 S: * OK [APPENDUID 1 2001] Replacement Message ready
222 S: A004 OK Replace completed
226Brandt Standards Track [Page 4]
228RFC 8508 IMAP REPLACE Extension January 2019
2313.4. Semantics of REPLACE and UID REPLACE
233 The REPLACE and UID REPLACE commands take five arguments: a message
234 identifier, a named mailbox, an optional parenthesized flag list, an
235 optional message date/time string, and a message literal. The
236 message literal will be appended to the named mailbox, and the
237 message specified by the message identifier will be removed from the
238 selected mailbox. These operations will appear to the client as a
239 single action. This has the same effect as the following sequence:
242 2. [UID] STORE +FLAGS.SILENT \DELETED
245 In the cited sequence, the quota implications of APPEND are evaluated
246 within the context of the pending EXPUNGE so that only the net quota
247 consumption is considered. Additionally, the EXPUNGE portion of the
248 sequence only applies to the specified message, not all messages
249 flagged as "\Deleted".
251 Although the effect of REPLACE is identical to the steps above, the
252 semantics are not identical; similar to MOVE [RFC6851], the
253 intermediate states do not occur and the response codes are
254 different. In particular, the response codes for APPEND and EXPUNGE
255 will be returned while those for the STORE operation MUST NOT be
258 When an error occurs while processing REPLACE or UID REPLACE, the
259 server MUST NOT leave the selected mailbox in an inconsistent state;
260 any untagged EXPUNGE response MUST NOT be sent until all actions are
261 successfully completed.
263 While it may be common for the named mailbox argument to match the
264 selected mailbox for the common use case of replacing a draft, the
265 REPLACE extension intentionally does not require the two to be the
266 same. As an example, it's possible to use the REPLACE command to
267 replace a message in the \Drafts special-use mailbox (see Section 2
268 of [RFC6154]) with a message in the \Sent special-use mailbox
269 following message submission.
271 Because of the similarity of REPLACE to APPEND, extensions that
272 affect APPEND affect REPLACE in the same way. Response codes such as
273 TRYCREATE (see Section 6.3.11 of [RFC3501]), along with those defined
274 by extensions, are sent as appropriate. See Section 4 for more
275 information about how REPLACE interacts with other IMAP extensions.
282Brandt Standards Track [Page 5]
284RFC 8508 IMAP REPLACE Extension January 2019
2873.5. IMAP State Diagram Impacts
289 Unlike the APPEND command, which is valid in the authenticated state,
290 the REPLACE and UID REPLACE commands MUST only be valid in the
291 selected state. This difference from APPEND is necessary since
292 REPLACE operates on message sequence numbers. Additionally, the
293 REPLACE extension intentionally follows the convention for UID
294 commands found in Section 6.4.8 of [RFC3501] in that the UID variant
295 of the command does not support use from the authenticated state.
2974. Interaction with Other Extensions
299 This section describes how REPLACE interacts with some other IMAP
304 The Access Control List (ACL) rights [RFC4314] required for UID
305 REPLACE are the union of the ACL rights required for UID STORE and
306 UID EXPUNGE in the current mailbox, and APPEND in the target mailbox.
310 Servers supporting both REPLACE and CATENATE [RFC4469] MUST support
311 the additional append-data and resp-text-code elements defined in
312 Section 5 ("Formal Syntax") of [RFC4469] in conjunction with the
313 REPLACE command. When combined with CATENATE, REPLACE can become
314 quite an efficient way of message manipulation.
338Brandt Standards Track [Page 6]
340RFC 8508 IMAP REPLACE Extension January 2019
345 User composes message and attaches photo
346 ----------------------------------------
347 C: A010 APPEND Drafts (\Seen \Draft) {1201534}
348 S: + Ready for literal data
349 C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
350 C: From: Fritz Schmidt <fritz.ze@example.org>
351 C: Message-ID: <B238822388-0100003@example.org>
353 C: Content-Type: multipart/mixed;
354 C: boundary="------------030305060306060609050804"
356 C: --------------030305060306060609050804
357 C: Content-Type: text/plain; charset=utf-8; format=flowed
358 C: Content-Transfer-Encoding: 7bit
360 C: Here is picture from the fireworks
365 C: --------------030305060306060609050804
366 C: Content-Type: image/jpeg;
367 C: name="Fireworks.jpg"
368 C: Content-Transfer-Encoding: base64
369 C: Content-Disposition: attachment;
370 C: filename="Fireworks.jpg"
372 <large base64 encoded part goes here>
374 C: --------------030305060306060609050804--
375 S: A010 OK [APPENDUID 1 3002] APPEND complete
377 User completes message with To: and Subject: fields
378 ---------------------------------------------------
379 C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
380 S: + Ready for literal data
381 C: To: Mitzy <miss.mitzy@example.org>
382 C: Subject: My view of the fireworks
383 C: URL "/Drafts/;UID=3002")
384 S: * OK [APPENDUID 1 3003] Replacement Message ready
387 S: A011 OK REPLACE completed
394Brandt Standards Track [Page 7]
396RFC 8508 IMAP REPLACE Extension January 2019
401 Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send
402 APPENDUID in response to a UID REPLACE command. For additional
403 information, see Section 3 of [RFC4315]. Servers implementing
404 REPLACE and UIDPLUS are also advised to send the APPENDUID response
405 code in an untagged OK before sending the EXPUNGE or replaced
406 responses. (Sending APPENDUID in the tagged OK as described in the
407 UIDPLUS specification means that the client first receives EXPUNGE
408 for a message and afterwards APPENDUID for the new message. It can
409 be unnecessarily difficult to process that sequence usefully.)
4114.4. IMAP Events in Sieve
413 REPLACE applies to IMAP events in Sieve [RFC6785] in the same way
414 that APPEND does. Therefore, REPLACE can cause a Sieve script to be
415 invoked with the imap.cause set to "APPEND". Because the
416 intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by
417 REPLACE, no action will be taken that results in an imap.cause of
4204.5. CONDSTORE/QRESYNC
422 Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162]
423 MUST treat the message being replaced as if it were being removed
424 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of [RFC7162]
425 are particularly relevant for this condition.
429 Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return
430 different EMAILIDs for both the replaced and replacing messages. The
431 only exception to this is the case outlined in Section 5.1 ("EMAILID
432 Identifier for Identical Messages") of [RFC8474] when the server
433 detects that both messages' immutable content is identical.
437 The REPLACE extension has no interaction with MULTIAPPEND [RFC3502].
438 This document explicitly does not outline a method for replacing
439 multiple messages concurrently.
450Brandt Standards Track [Page 8]
452RFC 8508 IMAP REPLACE Extension January 2019
457 The following syntax specification uses the Augmented Backus-Naur
458 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
459 the non-terminals "capability","command-select", "mailbox",
460 "seq-number", and "uid". [RFC4466] defines the non-terminal
463 Except as noted otherwise, all alphabetic characters are case
464 insensitive. The use of uppercase or lowercase characters to define
465 token strings is for editorial clarity only. Implementations MUST
466 accept these strings in a case-insensitive fashion.
468 capability =/ "REPLACE"
470 command-select =/ replace
471 replace = "REPLACE" SP seq-number SP mailbox append-message
472 uid =/ "UID" SP replace
4746. Security Considerations
476 This document is believed to add no security problems beyond those
477 that may already exist with the base IMAP specification. The REPLACE
478 command may actually prevent some potential security problems because
479 it avoids intermediate message states that could possibly be
480 exploited by an attacker.
4827. IANA Considerations
484 The IANA has added REPLACE to the "IMAP Capabilities" registry at
485 <https://www.iana.org/assignments/imap-capabilities>.
4898.1. Normative References
491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
492 Requirement Levels", BCP 14, RFC 2119,
493 DOI 10.17487/RFC2119, March 1997,
494 <https://www.rfc-editor.org/info/rfc2119>.
496 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
497 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
498 <https://www.rfc-editor.org/info/rfc3501>.
500 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
501 RFC 4314, DOI 10.17487/RFC4314, December 2005,
502 <https://www.rfc-editor.org/info/rfc4314>.
506Brandt Standards Track [Page 9]
508RFC 8508 IMAP REPLACE Extension January 2019
511 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
512 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
513 December 2005, <https://www.rfc-editor.org/info/rfc4315>.
515 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
516 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
517 <https://www.rfc-editor.org/info/rfc4466>.
519 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
520 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April
521 2006, <https://www.rfc-editor.org/info/rfc4469>.
523 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
524 Specifications: ABNF", STD 68, RFC 5234,
525 DOI 10.17487/RFC5234, January 2008,
526 <https://www.rfc-editor.org/info/rfc5234>.
528 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol
529 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
530 November 2012, <https://www.rfc-editor.org/info/rfc6785>.
532 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
533 Changes Resynchronization (CONDSTORE) and Quick Mailbox
534 Resynchronization (QRESYNC)", RFC 7162,
535 DOI 10.17487/RFC7162, May 2014,
536 <https://www.rfc-editor.org/info/rfc7162>.
538 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
539 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
540 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
542 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
543 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
544 2018, <https://www.rfc-editor.org/info/rfc8474>.
5468.2. Informative References
548 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
549 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
550 March 2003, <https://www.rfc-editor.org/info/rfc3502>.
552 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
553 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
554 March 2011, <https://www.rfc-editor.org/info/rfc6154>.
562Brandt Standards Track [Page 10]
564RFC 8508 IMAP REPLACE Extension January 2019
567 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
568 Access Protocol (IMAP) - MOVE Extension", RFC 6851,
569 DOI 10.17487/RFC6851, January 2013,
570 <https://www.rfc-editor.org/info/rfc6851>.
574 The author would like to thank the participants of IMAPEXT with
575 particular thanks to Arnt Gulbrandsen, Alexey Melnikov, Chris Newman,
576 and Bron Gondwana for their specific contributions.
582 22001 Loudoun County Parkway
584 United States of America
586 Email: stujenerin@aol.com
618Brandt Standards Track [Page 11]