Internet Message Access Protocol (IMAP) CATENATE Extension
RFC 4469

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                         P. Resnick
Request for Comments: 4469                         QUALCOMM Incorporated
Updates: 3501, 3502                                           April 2006
Category: Standards Track

       Internet Message Access Protocol (IMAP) CATENATE Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The CATENATE extension to the Internet Message Access Protocol (IMAP)
   extends the APPEND command to allow clients to create messages on the
   IMAP server that may contain a combination of new data along with
   parts of (or entire) messages already on the server.  Using this
   extension, the client can catenate parts of an already existing
   message onto a new message without having to first download the data
   and then upload it back to the server.

Resnick                     Standards Track                     [Page 1]
RFC 4469                IMAP CATENATE Extension               April 2006

1.  Introduction

   The CATENATE extension to the Internet Message Access Protocol (IMAP)
   [1] allows the client to create a message on the server that can
   include the text of messages (or parts of messages) that already
   exist on the server without having to FETCH them and APPEND them back
   to the server.  The CATENATE extension extends the APPEND command so
   that, instead of a single message literal, the command can take as
   arguments any combination of message literals (as described in IMAP
   [1]) and message URLs (as described in the IMAP URL Scheme [2]
   specification).  The server takes all the pieces and catenates them
   into the output message.  The CATENATE extension can also coexist
   with the MULTIAPPEND extension [3] to APPEND multiple messages in a
   single command.

   There are some obvious uses for the CATENATE extension.  The
   motivating use case was to provide a way for a resource-constrained
   client to compose a message for subsequent submission that contains
   data that already exists in that client's IMAP store.  Because the
   client does not have to download and re-upload potentially large
   message parts, bandwidth and processing limitations do not have as
   much impact.  In addition, since the client can create a message in
   its own IMAP store, the command also addresses the desire of the
   client to archive a copy of a sent message without having to upload
   the message twice.  (Mechanisms for sending the message are outside
   the scope of this document.)

   The extended APPEND command can also be used to copy parts of a
   message to another mailbox for archival purposes while getting rid of
   undesired parts.  In environments where server storage is limited, a
   client could get rid of large message parts by copying over only the
   necessary parts and then deleting the original message.  The
   mechanism could also be used to add data to a message (such as
   prepending message header fields) or to include other data by making
   a copy of the original and catenating the new data.

2.  The CATENATE Capability

   A server that supports this extension returns "CATENATE" as one of
   the responses to the CAPABILITY command.

Resnick                     Standards Track                     [Page 2]
RFC 4469                IMAP CATENATE Extension               April 2006

3.  The APPEND Command

   Arguments:  mailbox name
               (The following can be repeated in the presence of the
               MULTIAPPEND extension [3])
               OPTIONAL flag parenthesized list
               OPTIONAL date/time string
               a single message literal or one or more message parts to
               catenate, specified as:
                           message literal
                           or
                           message (or message part) URL

   Responses:  OPTIONAL NO responses: BADURL, TOOBIG

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

   The APPEND command concatenates all the message parts and appends
   them as a new message to the end of the specified mailbox.  The
   parenthesized flag list and date/time string set the flags and the
   internal date, respectively, as described in IMAP [1].  The
   subsequent command parameters specify the message parts that are
   appended sequentially to the output message.

   If the original form of APPEND is used, a message literal follows the