The IMAP COMPRESS Extension
Extracted elements (21)
A server can improve downstream compression by sending Z_FULL_FLUSH at the start and end of large non-text literals (suggested boundary: 5k), and can improve CPU efficiency by adjusting the compression level to 0 for known-incompressible formats (e.g., .gz, .zip, .jpg identified by magic bytes).
Base-64 encoded attachments are particularly poor candidates for DEFLATE compression: 8-bit compression algorithms work poorly on base-64's effectively 6-bit byte structure, hiding most of the underlying 8-bit file format from the compressor.
COMPRESS is specific to IMAP (unlike TLS compression which benefits all protocols on a TLS layer), but benefits from intimate knowledge of the IMAP protocol's state machine, allowing dynamic and aggressive optimization of the underlying compression algorithm's parameters.
DEFLATE (RFC 1951) was chosen as the sole algorithm to maximize interoperability by minimizing the number of different compression algorithms. It is standard, widely available, and fairly efficient.
The compression/encryption layering order (compress first, then SASL, then TLS) ensures data is compressed before encryption regardless of the order the client issues COMPRESS, AUTHENTICATE, and STARTTLS commands.
A client can improve downstream compression efficiency by implementing IMAP BINARY (RFC 3516) and using FETCH BINARY instead of FETCH BODY, with improvement ranging from 5% to 40% depending on the attachment.
The COMPRESS command may return NO with COMPRESSIONACTIVE if the same compression mechanism is already active via TLS, preventing double-compression. The resp-text should identify which layer is compressing.
When using the zlib library, windowBits for deflateInit2() must be in the range -8 to -15; other values cause deflateInit2() to use the wrong format. The Z_FULL_FLUSH argument clears the dictionary without requiring any action from the receiving peer.
If the client and server support both COMPRESS and TLS compression, it is RECOMMENDED that the client choose TLS compression.
If the server issues an OK response, the server MUST compress starting immediately after the CRLF which ends the tagged OK response. If the server issues a BAD or NO response, the server MUST NOT turn on compression.
If the server responds NO because it knows that the same mechanism is already active (e.g., via TLS), it MUST send COMPRESSIONACTIVE as resp-text-code, and the resp-text SHOULD say which layer compresses.
IMAP servers that advertise the COMPRESS extension SHOULD also advertise the TLS DEFLATE compression mechanism as defined in RFC 3749, to increase interoperation.
Implementations MUST accept the COMPRESS command string and algorithm names in a case-insensitive fashion.
The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the response was OK, the client MUST compress starting with the first command after COMPRESS. If the response was BAD or NO, the client MUST NOT turn on compression.
When COMPRESS is combined with TLS or SASL security layers, the sending order MUST be first COMPRESS, then SASL, and finally TLS. When receiving, the processing order MUST be reversed, ensuring data is compressed before it is encrypted.
The COMPRESS command syntax is: 'COMPRESS' SP algorithm, where algorithm is 'DEFLATE'. The capability is advertised as 'COMPRESS=DEFLATE'. The resp-text-code COMPRESSIONACTIVE is used when compression is already active via another layer.
The COMPRESS extension adds one new IMAP command, COMPRESS, which takes a single argument naming the compression algorithm (only 'DEFLATE' is defined). It adds no new responses but introduces the COMPRESSIONACTIVE resp-text-code.
IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.
Security considerations for IMAP COMPRESS are the same as for TLS compression (RFC 3749). No additional security considerations beyond those already addressed for TLS compression are identified.
After COMPRESS is issued, the client waits for the server response. On OK, both sides switch to compressed mode (client after sending next command, server immediately after the OK CRLF). On BAD or NO, both sides remain uncompressed. The state is irreversible within the session.
The ABNF grammar extends command-auth with 'compress', defined as 'COMPRESS' SP algorithm, and extends capability with 'COMPRESS=' algorithm, and resp-text-code with 'COMPRESSIONACTIVE'. The algorithm field is fixed as 'DEFLATE'.