Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
updated by
Extracted elements (17)
Multiple pipelined APPEND commands are non-atomic by definition, provide no way to revert the mailbox on error, may not allow the server to coalesce open/lock+sync/unlock/close operations, and can result in partial appends (e.g., messages 1, 2, 4, 5 appended when message 3 hits a quota error). MULTIAPPEND addresses all three deficiencies.
When used together with the LITERAL+ extension, an entire multi-message upload can be accomplished in a single command/response round trip, providing substantial performance improvements for clients uploading multiple messages.
Servers supporting both MULTIAPPEND and UIDPLUS modify the resp-code-apnd rule to: resp-code-apnd = "APPENDUID" SP nz-number SP set, where the set contains as many UIDs as messages appended, in append order, with no extraneous UIDs or the symbol "*".
The APPEND command is not used for message delivery because it does not provide a mechanism to transfer SMTP envelope information.
A MULTIAPPEND APPEND operation is atomic: either all messages are successfully appended, or no messages are appended. No partial appending is permitted.
A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a MIME content transfer encoding.
A zero-length message literal argument is an error and MUST return a NO response. This can be used to cancel the append.
If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date is set to the current date and time by default.
If a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set empty by default.
If the append is unsuccessful for any reason (including cancellation), 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 does not exist, a server MUST return an error and MUST NOT automatically create the mailbox. Unless it is certain the mailbox cannot be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the tagged NO response.
If the destination mailbox is currently selected, the server SHOULD notify the client immediately via an untagged EXISTS response. If it does not, the client MAY issue a NOOP or CHECK command after one or more APPEND commands.
The message literal argument SHOULD be in the format of an RFC 2822 message. 8-bit characters are permitted in the message.
A server that supports the MULTIAPPEND extension advertises this with the capability name "MULTIAPPEND" in its CAPABILITY response.
The APPEND command accepts one or more messages to upload, each specified as an optional flag parenthesized list, an optional date/time string, and a message literal. The ABNF is: append = "APPEND" SP mailbox 1*append-message; append-message = [SP flag-list] [SP date-time] SP literal.
The MULTIAPPEND extension does not raise any security considerations beyond those present in the base IMAP protocol. However, IMAP4rev1 transactions including mail data are sent in the clear unless STARTTLS, AUTHENTICATE privacy protection, or another protection mechanism is negotiated.
The APPEND command ABNF is extended to: append = "APPEND" SP mailbox 1*append-message, and append-message = [SP flag-list] [SP date-time] SP literal. The "1*" quantifier (one or more) is the key change from the base IMAP4rev1 syntax which allowed only a single message.