Summary

  • IMAP COMPRESS let a client request DEFLATE inside an existing session, but only a tagged OK authorized the switch: the server compressed immediately after that reply's CRLF, and the client compressed its first later command.
  • The shared history that reduced repeated commands, headers and message text also became a parsing, resource and confidentiality boundary. Later TLS guidance warned that observable compressed length can betray relationships between secret and influenced input without proving that IMAP suffered a specific attack.

The reply ended in one language and continued in another

IMAP already lived as a conversation of tagged commands, untagged data and tagged results. RFC 4978 added no new response form. A server merely advertised COMPRESS=DEFLATE; an authenticated client could send COMPRESS DEFLATE; the familiar OK, NO and BAD results carried the decision.

The familiar syntax concealed a severe boundary. The client was forbidden to send another command while the verdict was outstanding. On OK, it compressed the first command that followed. The server kept the successful tagged reply itself uncompressed, then enabled its encoder immediately after the CRLF ending that line. A rejection left both directions unchanged.

This choreography made one byte position authoritative. If a client switched before reading the complete result, it could feed plain text to a decompressor. If the server waited one response too long, the client would interpret compressed bits as IMAP grammar. TCP could deliver every byte perfectly and the session would still become unreadable because the peers disagreed about what the bytes meant.

Capability was permission, not a measurement

The capability said that the server understood an algorithm. It did not promise that a particular mailbox would shrink, that the CPU cost was acceptable or that the connection was confidential. The command let each participant choose its own outbound compression effort; the peer had to decode the selected stream.

The refusal rules preserved that narrow meaning. A server that knew the same compression mechanism was already active through another layer could reply NO with COMPRESSIONACTIVE. Trying to activate the extension twice was invalid. The protocol avoided stacking the same stateful transform merely because two negotiation surfaces offered it.

There were two histories as well, one in each direction. Repeated client commands made the upstream stream predictable. Server responses, field names and mailbox text populated the downstream history. Compression did not create a single mystical dictionary shared by all traffic; each sender maintained the context for the bytes it produced.

Layer order did not follow command order

An IMAP session could also acquire a SASL security layer or TLS. RFC 4978 prescribed one outgoing stack: compress first, then apply SASL signing or encryption when present, then protect the result with TLS. The receiver reversed those operations.

That order held even if the client had issued the enabling commands in another sequence. Administrative chronology and data transformation were separate facts. The extension therefore had to integrate with the protocol state machine rather than sit invisibly beneath it.

Current IMAP4rev2 keeps the same general discipline around security transitions: a successful response identifies the exact point where a new layer begins. A long-lived connection can change representation or protection, but only if both peers assign the same meaning to the boundary.

Repetition made the dictionary valuable

IMAP was unusually friendly to compression. Clients repeated a small command vocabulary. Servers repeated response forms and header names. Messages in a thread repeated quotations. One evolving history could replace later phrases with short references to earlier material.

The traffic was not uniform. A compressed archive or JPEG could resist further reduction. A large attachment could displace useful IMAP patterns and make the compressor spend resources learning the wrong material before ordinary responses returned. The specification discussed full flushes near large literals and changing effort around data that looked incompressible. Those were local optimizations, not new wire commands.

This is why the extension mattered as more than a file zipper. It compressed a mixed, interactive stream while the application still knew whether the next bytes were syntax, headers, text or a literal. That knowledge could save bandwidth and CPU, but it also made the application responsible for the context.

Encryption did not make length meaningless

In 2007, the security section of the extension simply referred to the contemporary considerations for TLS compression. Later attacks changed the industry's understanding. CRIME and related work showed that encryption can hide content while leaving observable length. When a secret and attacker-influenced text enter the same compression history, repeated guesses can change the compressed size and reveal relationships about the secret.

The documented attacks summarized by the IETF concerned TLS and web compression. They do not prove that an IMAP COMPRESS exploit was deployed, or that every IMAP compression context is vulnerable. They do establish why “compressed before encrypted” is not a complete confidentiality argument.

Current TLS best practice tells TLS 1.2 deployments not to support ordinary TLS-level compression except in an application shown safe, and notes that TLS 1.3 removed it. The same guidance warns that compression above TLS can create related disclosure risks that TLS itself cannot repair. Application knowledge enables better compression; it also owns the decision about which values may share history.

The hidden state needed an owner

Compression made later bytes depend on earlier bytes without changing the logical IMAP messages. That dependency was useful only while both endpoints agreed on activation, direction, algorithm and context. Decode failure, resource exhaustion or a confidentiality concern therefore could not be diagnosed from an encrypted packet capture alone.

The durable design lesson is narrower than “never compress secrets.” Name the context. Decide who can influence its inputs, who can observe its output size, how long history survives, what resources decoding may consume and how compression can be disabled without corrupting the session. An optimization that remembers is a state machine, not decoration.

Sources and limits

The DEFLATE format is defined by RFC 1951. The IMAP capability, command boundary, layer order and tuning discussion come from RFC 4978. The attack class is summarized in RFC 7457; the current IMAP core is RFC 9051; current TLS advice is RFC 9325; and the capability remains in the IANA IMAP registry. These sources do not measure current use or document a specific IMAP COMPRESS compromise.