Internet Message Access Protocol (IMAP) CATENATE Extension
updated by
- rfc-5550 — The Internet Email to Support Diverse Service Environments (Lemonade) Profile
updates
Extracted elements (20)
The primary motivation for CATENATE is to allow resource-constrained clients (e.g., mobile devices) to compose outbound messages containing large attachments already on the IMAP server without downloading and re-uploading them, saving bandwidth and processing. It also solves the sent-copy archival problem by avoiding a double upload.
The scope of the extension is deliberately limited to relative URLs referencing the current authenticated IMAP session. Support for absolute URLs or cross-session references would require a separate extension, keeping this specification simple and secure.
The server performs no MIME conversion or validation when catenating URL-referenced parts; the client bears full responsibility for MIME correctness. This avoids complex server-side MIME processing and potential data corruption from well-intentioned but incorrect transformations.
If the server implements the IMAP UIDPLUS extension (RFC 4315), it will return an APPENDUID response code in the tagged OK response to a successful CATENATE APPEND command, just as for a standard APPEND.
The CATENATE extension can coexist with the MULTIAPPEND extension (RFC 3502), allowing APPEND of multiple messages in a single command where each message may itself be a catenation of literals and URLs.
The server may validate URLs as they are received during the literal data exchange and return a tagged NO with BADURL in place of a continuation request, rather than waiting until all data is uploaded. Both behaviors are conformant.
Even if the server does not return TOOBIG, it must still be defensive against misbehaving or malicious clients that attempt to construct a message exceeding the 4-GB IMAP message limit.
No further LOGIN or AUTHENTICATE command is performed for URLs specified in the extended APPEND command, since the APPEND command is valid in the authenticated state and the URLs refer to the current session.
Only relative IMAP message or message part URLs (those having no scheme or <iserver>) are used in the extended APPEND command. Absolute IMAP URLs or URLs referring to resources outside the current authenticated session are outside the scope of this document; a conforming server returns NO to such requests.
The APPEND command MUST NOT cause the \Seen flag to be set for any catenated body part, and MUST NOT change the currently selected mailbox.
The client is responsible for ensuring that the catenated message conforms to RFC 2822 or MIME format, including inserting appropriate MIME boundaries between body parts and writing MIME Content-Type and Content-Transfer-Encoding lines as needed.
When a URL is catenated, the server copies octets unchanged from the indicated message or message part. The server performs no data conversion (e.g., MIME transfer encodings) and no verification that the data is appropriate for the target MIME part.
A server supporting the CATENATE extension returns "CATENATE" as one of the responses to the CAPABILITY command. This is the sole mechanism for capability advertisement.
The BADURL response code is returned in a tagged NO response when the APPEND fails to process one of the specified URLs. The response code contains the first failing URL as a parameter. Possible reasons include bad URL syntax, unrecognized URL schema, invalid message UID, or invalid body part.
The base URL for evaluating relative IMAP URLs in extended APPEND is "imap://user@server/" in the authenticated state, and "imap://user@server/mailbox" (where mailbox is the encoded currently selected mailbox name) in the selected state.
The extended APPEND command accepts "CATENATE" followed by a parenthesized list of message parts, each specified as either a TEXT literal ("TEXT" SP literal) or a message URL ("URL" SP astring). The server catenates all parts sequentially into the new message.
The TOOBIG response code is returned in a tagged NO response if the resulting message would exceed the 4-GB IMAP message limit, or a server-specific message size limit. The server may also use TOOBIG to enforce its own size policy.
This document registers the "CATENATE" IMAP4 capability in the IANA IMAP4 capabilities registry at http://www.iana.org/assignments/imap4-capabilities. Registration follows the standards track or IESG-approved experimental RFC process.
The CATENATE extension does not introduce security considerations beyond those present in base IMAP (RFC 3501) and the IMAP URL Scheme (RFC 2192). Implementors should consult those documents for relevant security analysis.
The ABNF extends append-data to: "CATENATE" SP "(" cat-part *(SP cat-part) ")". A cat-part is either a text-literal ("TEXT" SP literal) or a url ("URL" SP astring). Response codes are extended with toobig-response-code ("TOOBIG") and badurl-response-code ("BADURL" SP url-resp-text).