Summary

  • Legacy support was an implementor’s choice, not an IMAP4 obligation; recognising a server did not certify subsequent operations. RFC 2061
  • Compatibility ranged from useful rewrites to state-changing compensation and outright gaps; successful COPY did not establish metadata preservation. RFC 2061

A mail preview could deliver the requested bytes while changing a flag the client meant to leave alone. Mark Crispin’s December 1996 Informational RFC 2061 advised an IMAP4 client using an IMAP2bis server to replace BODY.PEEK[section] with BODY[section], manually clearing \Seen when necessary. Continued access could therefore require an additional write.

Crispin, at the University of Washington, described IMAP2bis as very common then and widely distributed with Pine, but without a definitive specification. He acknowledged incomplete knowledge and reliance on protocol folklore; his prevalence claim was not a market-share measurement. RFC 2061 concentrated on that likely encounter rather than all old variants, narrowing the broader December 1994 RFC 1732. It directed readers to August 1990’s RFC 1176, an IMAP2 baseline rather than a definitive IMAP2bis specification, and December 1996’s RFC 2060, the IMAP4rev1 specification. Supporting both that revision and December 1994’s RFC 1730 required consulting both.

Recognition was only the entrance

Under RFC 2061’s heuristic, CAPABILITY completing with OK announced supported IMAP4 variants. If none was recognised, the client should treat the server as IMAP2bis; BAD indicated IMAP2bis or older. That was not definitive fingerprinting, and arbitrary failures, timeouts or security errors were not interchangeable with BAD. Recognition selected a voluntary route, not proof of later effects.

The mappings can be divided analytically into useful near-equivalents, semantic approximations or compensation, and absent equivalents. These are editorial classes, not the memo’s terminology.

For useful but bounded discovery, LIST became FIND ALL.MAILBOXES, resembling RFC 1176’s FIND MAILBOXES syntax and response; the latter itself was unlikely to help. Sequence * became the count from unsolicited EXISTS, not a frozen snapshot. RFC 2061

Approximation went further. SEARCH extensions needed RFC 1176 syntax, sometimes several searches. BODYSTRUCTURE became non-extensible BODY; HEADER, TEXT, MIME, HEADER.FIELDS and HEADER.FIELDS.NOT sections gave way to section numbers. Rewriting commands did not manufacture equivalent character-set support, richer criteria or structural and section semantics. RFC 2061

Restoring a flag was not leaving it untouched

RFC 2060 specifies that ordinary BODY[section] implicitly sets \Seen, whereas PEEK does not, and recognises external flag changes with recommended updates. The engineering implication is conditional: where flags are mutable and shared, another observer might see the intervening state, or another client might set \Seen before compensation clears it. A pre-existing \Seen must not be blindly removed. RFC 2061 supplies no atomic restoration mechanism. This is a possible consequence, not a documented incident, universal shared-flag policy or inevitable race.

Likewise, FLAGS.SILENT, +FLAGS.SILENT and -FLAGS.SILENT became corresponding non-silent STORE items; the client ignored returned untagged FETCH responses. Ignoring a reply locally did not suppress its transmission, undo server-side changes or prevent their observation elsewhere. RFC 2061

What a successful command could not prove

IMAP2bis left preservation of flags and internal dates on COPY ambiguous. RFC 2061 says server behaviour could not be known under that compatibility description. RFC 2060’s preservation SHOULD cannot be imposed retroactively. COPY completion did not certify retention of those attributes; a per-server experiment could establish an observed case, not a missing universal contract.

TRYCREATE arrived separately in an unsolicited OK, not inside NO. A parser needed to retain the failure context: that separate hint did not make a failed COPY successful. RFC 2061

The UID fetch item, UID commands and CLOSE had no functional equivalent. LSUB, SUBSCRIBE and UNSUBSCRIBE had no direct equivalent; bboards were a separate concept whose old commands Crispin discouraged in new software, including servers supporting old clients. RFC 2061

In reverse, the memo reported only quoted-string backslash incompatibility for a well-written IMAP2bis client using an IMAP4 server, recommending literals for embedded backslashes or quotation marks. That qualified account was not a warranty for all old clients.

Its substitution of LOGIN for unavailable AUTHENTICATE was historical advice in a memo explicitly excluding security. RFC 2061 is no present-day cleartext or downgrade recommendation. January 2018’s RFC 8314 recommends TLS for mail access; it is not evidence of 1996 deployment.

The defensible claim was therefore narrower: the client could keep offering specified operations, with specified losses. Each command, returned data shape and lasting side effect still needed its own evidence.

Sources

  • RFC 2061 — December 1996; compatibility mappings, scope and uncertainty.
  • RFC 2060 — December 1996; IMAP4rev1 fetch, flag and COPY semantics.
  • RFC 1176 — August 1990; IMAP2 baseline and older syntax.
  • RFC 1730 — December 1994; earlier IMAP4 specification.
  • RFC 1732 — December 1994; broader predecessor compatibility guidance.
  • RFC 8314 — January 2018; later mail-access TLS guidance only.
  • Lu Heng on voluntary adoption — 2026 interpretation, not historical IMAP evidence.
  • Lu Heng on symbolic and executable power — 2025 interpretation, not evidence of Crispin’s intentions.