RFC 3502

RFC 3502: Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension 💌

okay so this one is by Mark R. Crispin from the University of Washington 🎓, and it's a Standards Track doc from March 2003. It's published through the Network Working Group as RFC 3502. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🌸 For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💖

Copyright Notice ©️

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒

Abstract 🦋

This doc describes the multiappending extension to the Internet Message Access Protocol (IMAP), which is defined in RFC 3501. The whole point is substantial performance improvements for IMAP clients that upload multiple messages at a time to a mailbox on the server. It's giving speed 🏎️💨

A server that supports this extension tells everyone with a capability name of "MULTIAPPEND" 🫶

Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. These are the rules-words, so pay attention to them 👀

Introduction 🧚

okay so MULTIAPPEND lets you upload multiple messages with a single command ✨ When you pair it with [LITERAL+], the entire upload happens in a single command/response round trip. Literally one trip, no cap 🔥

A MULTIAPPEND APPEND operation is atomic 🔒 That means it's all or nothing: either every message gets appended, or no messages do. No in-between messiness 💅

Now, in the base IMAP spec, every message needs its own command 😩 And there's no way to "unappend" messages if something goes wrong halfway. On top of that, some mail stores need an expensive "open/lock + sync/unlock/close" operation as part of appending. Doing that for every single message? Iconic behavior, but not in a good way 💀

If a server supports both LITERAL+ and pipelining but not MULTIAPPEND, you can kinda grab some of the perks by doing a pipelined "batch" append 🍓 BUT it's not going to hit as hard as MULTIAPPEND, and here's why:

1. Multiple APPEND commands, even as part of a pipelined batch, are non-atomic by definition. There's no way to revert the mailbox to the state it was in before the batch if something errors out 😭
2. The server might not be able to coalesce pipelined APPEND operations so it avoids the "open/lock + sync/unlock/close" overhead. Even if it could, that coalescing would be timing dependent and therefore potentially unreliable 🙈 With traditional UNIX mailbox files, a lock is assumed to be held only for a single atomic operation, and many applications ignore any lock that's older than 5 minutes. Not it 💀
3. If an error occurs, then depending on what kind of error it is, extra messages can still get appended after the error 👻 Picture this: the user wants to append 5 messages, but a disk quota error hits the third one because of its size. The fourth and fifth messages were already sent down the pipeline, so the mailbox ends up with the first, second, fourth, and fifth messages of the batch appended. Chaotic, bestie 😭

6.3.11. APPEND Command 📬

Here's the APPEND command's spec, with the MULTIAPPEND twist 🎀

Arguments:  mailbox name
            one or more messages to upload, specified as:
               OPTIONAL flag parenthesized list
               OPTIONAL date/time string
               message literal

Data:       no specific responses for this command

Result:     OK - append completed
            NO - append error: can't append to that mailbox, error
                 in flags or date/time or message text,
                 append cancelled
            BAD - command unknown or arguments invalid

The APPEND command adds the literal arguments as new messages at the end of the destination mailbox 🌈 The argument SHOULD be in the format of an [RFC-2822] message. 8-bit characters are allowed in the message 🙌 A server that can't preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer encoding. Non-negotiable, bestie 💅

Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed. 🙈

If you specify a flag parenthesized list, the flags SHOULD be set on the resulting message. Otherwise, the flag list of the resulting message is set empty by default 🦋

If you specify a date-time, the internal date SHOULD be set on the resulting message. Otherwise, the internal date is set to the current date and time by default ⏰

A zero-length message literal argument is an error, and it MUST return a NO. This is the way to cancel the append, so it's kinda a feature 🚫✨

If the append is unsuccessful for any reason (including being cancelled), the mailbox MUST be restored to its state before the APPEND attempt. No partial appending is permitted 🔒 The server MAY return an error before processing all the message arguments 🫠

If the destination mailbox doesn't exist, a server MUST return an error and MUST NOT automatically create the mailbox 🚫 Unless it's certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives the client a hint that it can attempt a CREATE command and retry the APPEND if the CREATE succeeds 🧚

If the mailbox is currently selected, the normal new message actions SHOULD occur. Specifically, the server SHOULD notify the client immediately via an untagged EXISTS response. If the server doesn't do that, the client MAY issue a NOOP command (or, failing that, a CHECK command) after one or more APPEND commands 🔔

Example:

C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:  (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C:  {35403}
S: A005 NO APPEND failed: Disk quota exceeded

Note: The APPEND command is not used for message delivery, because it does not provide a mechanism to transfer [SMTP] envelope information. 📨

---

Full Copyright Statement ✨

Okay bestie, legal stuff time, but it's actually cute 🎀 Copyright (C) The Internet Society (2003). All Rights Reserved. 💖

You're totally allowed to copy and share this document, and to translate it. You can also make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those however you want, in whole or in part, with no restrictions at all 🦋. The one big condition is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 📜

Now the plot twist 😭 The original document itself can't be changed in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are only three exceptions. First, you can do it when it's needed to develop Internet standards, but then you have to follow the copyright procedures defined in the Internet Standards process. Second, you can do it when it's required to translate it into languages other than English. 🌍

These permissions are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, periodt 💅✨

Also, this document and everything in it is provided "AS IS" 🙈 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. So, no guarantees, but the vibes are immaculate 🌸

---

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 👑