IMAP4 Binary Content Extension
updated by
- rfc-4466 — Collected Extensions to IMAP4 ABNF
Extracted elements (21)
CTE modification of APPENDed literal8 data should only be done when absolutely necessary because gratuitous encoding changes will render useless most cryptographic operations that have been performed on the message.
Server processing of FETCH BINARY involves two logical steps: (1) performing CTE-related decoding and (2) determining the domain of the decoded data. Step 2 is necessary to decide whether to use <nstring> or <literal8> for transmission.
The Binary extension was introduced to reduce the overhead of MIME content-transfer-encoding (particularly base64) in contexts such as slow radio links and streaming multimedia, allowing the server to perform CTE decoding before transmitting data to the client.
The <literal8> element was introduced because certain identity-encoding CTEs (e.g., MIME "binary") produce decoded data whose domain includes NUL octets, which cannot be expressed in normal IMAP4 string protocol elements; a fully eight-bit-transparent literal type was required.
Every IMAP4 body section has a MIME CTE; those without an explicit Content-Transfer-Encoding header are implicitly treated as "7bit" content. The Binary extension's decoding applies to these CTE labels as defined in RFC 2045.
The BINARY.PEEK variant is provided as an alternate form of FETCH BINARY that does not implicitly set the \Seen flag, maintaining consistency with the BODY.PEEK pattern in base IMAP4.
A server MUST NOT perform any conversion of MIME encoded-word (RFC 2047) header text in response to any binary FETCH or APPEND request; the CTE decoding transformations do not apply to encoded header text.
Clients supporting this extension SHOULD be prepared to perform their own CTE decoding operations; this extension is an optimization and does not absolve clients of providing basic content-transfer decoding functionality.
If the destination mailbox does not support storage of binary content, the server MUST fail the APPEND request and issue a "NO" response containing the "UNKNOWN-CTE" extended response code.
If the domain of the decoded data is "8bit" and the data does not contain the NUL octet, the server SHOULD return the data in a <string> instead of a <literal8>, allowing the client to determine NUL presence without scanning the data stream.
If the server does not know how to decode a section's CTE, it MUST fail the request and issue a "NO" response containing the "UNKNOWN-CTE" extended response code. This applies to both FETCH BINARY and BINARY.SIZE requests.
IMAP4 servers that support this extension MUST include "BINARY" in the response list to the CAPABILITY command.
Regardless of internal storage format, the server MUST issue BODYSTRUCTURE responses describing the message as though binary-encoded sections are encoded in a CTE acceptable to the base IMAP4 specification, and FETCH BODY MUST return content in the format described by FETCH BODYSTRUCTURE.
The APPEND command is extended to allow appending data containing NULs via <literal8> syntax. The server MAY modify the CTE of appended data, but any such transformation MUST NOT result in a loss of data.
The BINARY.SIZE value returned MUST match the size of the <nstring> or <literal8> that will be returned by the corresponding FETCH BINARY request.
When sending data using the Binary extension, servers MUST ensure that textual line-oriented sections are always transmitted using IMAP4 CRLF line termination syntax, regardless of the server's internal storage representation.
A new extended response code "UNKNOWN-CTE" is defined for use in "NO" responses when the server cannot decode a section's content-transfer-encoding, applicable to FETCH BINARY, FETCH BINARY.SIZE, and APPEND operations.
Three new FETCH command data items are defined: BINARY<section-binary>[<partial>] to retrieve CTE-decoded section data, BINARY.PEEK<section-binary>[<partial>] as an alternate form that does not set the \Seen flag, and BINARY.SIZE<section-binary> to request the decoded size of the section.
Two new FETCH response data items are defined: BINARY<section-binary>[<<number>>] returning an <nstring> or <literal8> with CTE-decoded content, and BINARY.SIZE<section-binary> returning the decoded size as a number.
There are no known additional security issues with this extension beyond those described in the base IMAP4 protocol (RFC 3501). Implementors should refer to the base protocol's security considerations.
The <literal8> protocol element is defined as "~{" followed by a decimal number (octet count), CRLF, and then that many octets. It is fully eight-bit transparent, allowing NUL octets to be transmitted.