Summary

  • IMAP defines \Seen as “message has been read,” yet the observable event is mutable mailbox state: a body fetch can set it, BODY.PEEK can retrieve content without setting it, and authorized clients can add or remove it.
  • A defensible claim about human reading needs a joined receipt for principal, client, mailbox incarnation, message UID, command, pre/post flags, server response and user-interface event. The flag alone proves none of attention, comprehension, consent or reply.

A strong verb attached to a small piece of state

Mark Crispin designed IMAP so that mail could remain on a server while people used it from different clients and places. Stanford’s memorial record says he invented the protocol while working there from 1977 to 1988. His IETF profile lists 25 RFCs, including RFC 3501, the 2003 specification that became the durable reference for IMAP4rev1. The Unicode Consortium, where he also contributed for years, remembers him as an email expert and the father of IMAP.

That history matters because \Seen sits at the centre of the benefit IMAP created. A remote mailbox needs a common way to remember which messages have crossed a reading boundary. RFC 3501 gives the system flag a plain definition: “Message has been read.” Current IMAP4rev2, RFC 9051, retains it.

The phrase is useful. It is also easy to promote into a stronger claim than the protocol can support. IMAP explicitly distinguishes the human “user” from the software “client.” The server does not observe eyes, attention or comprehension. It receives commands, returns data and maintains attributes. \Seen is one of those attributes.

The narrow reading is therefore the reliable one: the mailbox currently carries a standardized read-state flag. To infer a human act, an operator must examine how the bit arrived.

A fetch can write while a peek does not

The clearest evidence boundary appears inside the FETCH command. When a client requests a message body with BODY[...], RFC 3501 and RFC 9051 say that \Seen is implicitly set. If the flag changes, the server reports the new flags. Retrieval and mutation are coupled by the command’s semantics.

The same standards define BODY.PEEK[...] as the alternate form that does not implicitly set \Seen. The contrast creates four possible observations, not one. Content can be fetched and the flag can change. Content can be fetched without that change. A separate flag operation can mark a message seen without fetching its body. A later operation can remove the bit after content was fetched.

None is a protocol defect. They allow clients to build previews, deliberate unread states and synchronized mailboxes. They also mean that the stored bit is not a direct reading sensor.

An automated client may fetch a body for indexing, filtering, caching or preview generation. That is an operational possibility, not a claim about every product. Conversely, a client could display data obtained with BODY.PEEK while leaving the bit unset. The server’s evidence ends at the command and its effect. The interface’s evidence begins elsewhere.

The message can arrive already seen

IMAP also permits flags on APPEND. Both RFC 3501 and RFC 9051 include examples in which a message is appended to a mailbox with \Seen already present. In that case the flag describes the admitted state. It cannot be a receipt proving that a person read the newly stored mailbox copy after admission.

Explicit flag writes widen the gap. STORE can add or remove flags. A “mark as read” control can set \Seen without displaying a body; “mark as unread” can clear it after a person has read every line. Bulk actions can affect many messages. In a mailbox used by more than one client or principal, another authorized actor may cause the state a later observer sees.

This is why “unread” is not the logical opposite of “a human has read.” It means the flag is absent at the observation time. The history may contain a fetch, a manual reset, a synchronization race or an admission state that the current value no longer reveals.

Authorization changes the meaning of absence

RFC 4314 gives \Seen its own access-control right, s. A FETCH that would normally imply the flag must not set it when the current user lacks that right. STORE likewise checks s when changing \Seen.

The same body retrieval can therefore leave different durable evidence depending on authorization. One account can fetch and mutate the flag; another can fetch the same content without permission to record the transition. The absence of \Seen may reveal a rights boundary, not absence of viewing.

Implementations can also differ in whether relevant flags are shared or non-shared. The safe operational question is not simply “is it seen?” but “whose state is this, in which mailbox model, written under which right?” A shared support inbox, delegated executive mailbox and private personal folder do not create equivalent evidence merely because they expose the same flag name.

Synchronization can preserve order without preserving cause

RFC 7162 adds CONDSTORE and QRESYNC machinery. Modification sequences let a client discover that metadata changed, update a cache and condition a STORE on UNCHANGEDSINCE. A failed conditional write can identify a conflict instead of silently overwriting newer state. That is valuable provenance.

But a mod-sequence is an ordering receipt, not a witness statement. It can show that a flag changed after a known version. It does not by itself say whether the cause was an implicit fetch, explicit STORE, another client, an external agent or a human-facing control. Nor does it show which pixels were displayed or whether anyone attended to them.

JMAP carries the idea into a different API. RFC 8621 defines $seen as a special keyword and allows an authorized user to add or remove it. Cross-protocol synchronization can make the bit widely consistent. Consistency increases confidence in the state that was replicated; it does not increase the scope of what that state observed.

Build a reading claim from separate receipts

A defensible mailbox record starts with identity at the protocol boundary: authenticated principal, delegated role, client instance and session. It then needs the mailbox incarnation, normally UIDVALIDITY, plus the message UID so that a recycled sequence number cannot be mistaken for durable identity.

Next comes the cause: FETCH BODY, BODY.PEEK, STORE, APPEND, synchronization or a named external agent. Preserve requested sections, prior flags, resulting flags, server response, timestamp and mod-sequence where available. If a client says it displayed the message, record that as a separate UI event. If the business needs acknowledgement, collect an explicit acknowledgement rather than renaming the flag.

The resulting ledger can say: body fetched by client; \Seen set implicitly; UI display unknown; acknowledgement absent. Or: body fetched with PEEK; UI displayed; flag unchanged; user later acknowledged. Those sentences are less convenient than “read” or “unread.” They are also much harder to misuse.

Mark Crispin’s protocol did not make human reading unobservable. It made mailbox state interoperable. The responsibility of later systems is to stop that useful state from testifying beyond the event it records.

Sources