Summary

  • RFC 9979 gives IMAP and JMAP shared names for useful mailbox states. It also keeps their meanings deliberately narrow: $istrusted is a server assertion, $unsubscribed records an attempt, $new directs attention and Scheduled identifies storage.
  • A defensible system records who set a label, under which rule and evidence, at what time and scope, how clients projected it, which action followed and what separate receipt established the result.

The audit export looked unusually decisive. One message was trusted. A second was unsubscribed. A third was new. A draft sat in Scheduled. Read at executive speed, the row appeared to say that the first sender was authentic, the second mailing list had stopped, the third message had just arrived and the fourth had already entered a delivery queue.

Every word came from a real state. None supported the conclusion attached to it.

The scene is constructed, not a report about a provider, mailbox or incident. Its distinctions come from RFC 9979, an Informational IETF document published in May 2026. The RFC standardizes 17 IMAP/JMAP message keywords and three mailbox name attributes already used across implementations. That is valuable minimum-layer work: shared spelling and intended semantics reduce collisions and let different clients recognize the same state. It is not certification of the state on a particular message.

The IANA keyword registry shows the boundary clearly. A row records a keyword, whether it is private or shared, its usage and scope, and the specification that defines it. The mailbox-attribute registry does the same for names such as Memos, Scheduled and Snoozed. IANA coordinates the vocabulary. It does not inspect the classifier that set $istrusted, watch a user press unsubscribe or observe an SMTP delivery.

That distinction matters because the labels do not all describe the same kind of fact. Some are set by a server during delivery. Some are set or cleared by a client after a user action. Some are advisory. Others may cause automatic behavior. A portable token can therefore be syntactically identical across devices while deriving its meaning from a different actor, clock and decision surface.

RFC 9979 inherits a mature substrate. RFC 5788 created the keyword registry. RFC 8457 supplied an earlier shared model for importance. RFC 9051 defines IMAP4rev2, while RFC 8621 defines JMAP Mail. Their common state vocabulary improves interoperability. It does not erase the local policy that produced the state.

Attachment detection gives the simplest proof. $hasattachment and $hasnoattachment are mutually exclusive. The second is not redundant: RFC 9979 says absence of $hasattachment is inconclusive because analysis may not have occurred. That creates three operational states—positive, explicit negative and unknown—even when a dashboard offers only a paperclip and blank space. Blank is not no.

JMAP's hasAttachment property must reflect the same information. Agreement across protocols is a coherence receipt. If both surfaces say “no attachment,” an operator has evidence that the synchronized projections agree. The operator still needs to know which parser ran, which MIME tree it inspected, when it ran and whether a later mutation invalidated the result.

Memo state adds a transition problem. $memo belongs to the note-to-self message; $hasmemo belongs to the message being annotated. Creating or removing a memo requires coordinated changes on both sides. RFC 8474 supplies the stable object/thread identity used by related IMAP behavior. If a client crashes between writes, the remaining label may be valid syntax and stale relationship evidence. Current state alone does not reconstruct the interrupted transaction.

The trust keyword is more consequential. RFC 9979 defines $istrusted as a server-set advisory indication that both the sender name and email address were verified with high confidence. It warns that a mistaken assertion can induce users to trust fraudulent mail. Most importantly, it says the keyword must not be applied merely because standard mechanisms such as SPF, DKIM or DMARC passed.

That is not an attack on mail authentication. RFC 7208 evaluates whether a host is authorized to use an envelope identity. RFC 6376 binds a domain's signature to selected message material. RFC 9989 evaluates alignment with the visible author domain and requests receiver policy. Those are useful, bounded proofs. None automatically proves the human-readable display name, a natural person, business authorization, safety of every link or the truth of the message.

RFC 9979 leaves “high degree of confidence” to the server. It names no universal algorithm or numeric threshold. That local freedom is legitimate, but it makes provenance essential. A trust label should carry, in an adjacent protected record, the asserting server, rule version, evidence classes, confidence, time, expiry and revocation path. The UI should disclose the scope in language proportionate to the proof. A bright badge without a method turns a local classifier into borrowed authority.

The RFC's security section makes the principal explicit: interpretation depends on the client and user trusting the IMAP server. A compromised or malicious server can set or manipulate keywords to mislead. Transporting the token faithfully does not repair a false assertion at its origin. A second client can reproduce the same misleading badge perfectly.

Subscription state exposes a different category error. $canunsubscribe says a message has a compliant List-Unsubscribe mechanism and passed implementation-specific reputation checks. RFC 8058 defines one-click signaling. Capability to offer the action is not performance of the action.

$unsubscribed moves one step further but still stops short of completion. It records that the user attempted to unsubscribe, even when confirmation of success has not arrived. It must not be set after a definite failure. The resulting state machine needs at least offer, attempt, definite failure, unknown result and confirmed completion. Calling every middle state “unsubscribed” makes a convenient UI while destroying the fact a support team needs when mail continues.

Attention labels live on another axis. $new can mark an old snoozed message as worthy of renewed prominence after it wakes. It says nothing about creation or delivery time. $notify asks a supporting client to present a notification unless user configuration says otherwise. It does not prove that the client displayed anything, that a person noticed it or that an action followed. A notification request, rendered notification, user view and response are four receipts.

Mailbox attributes are similarly modest. Snoozed identifies where temporarily deferred messages are stored; RFC 9979 expressly says the attribute does not define the snoozing mechanism or interface. Scheduled identifies a mailbox holding messages intended for later sending. Presence there is not proof of submission, relay acceptance or delivery. The message needs a schedule record, execution attempt, transport response and final disposition.

The $followed and $muted pair shows why deterministic semantics still need history. They are mutually exclusive, and if contradictory state exists, followed wins. That is a sound interoperability rule: clients converge on behavior instead of guessing. It does not explain whether a stale client, race, attacker or recovery process created the contradiction. RFC 9979 warns that an account intruder can mute threads to hide replies and advises reviewing mute actions during account recovery.

This is where a state token becomes an operational control. The same keyword that helps reduce noise can suppress evidence of a payment change, password reset or security conversation. Recovery that resets the password but accepts synchronized mute state as authoritative has restored access without restoring attention integrity.

The RFC Editor record and errata search bound the documentary baseline. They do not establish which providers implement the labels, how their classifiers work or whether any message was correctly handled. The authors' affiliations are not deployment evidence.

Heng Lu's Reality Layers provides the appropriate ledger: registry meaning, local rule, server assertion, synchronized state, client presentation, human belief, automated action and external outcome are separate layers. Running-Code Primacy gives executed classification and effect priority over the elegance of the token. Minimum Initial Specification explains why the common layer should remain small: agree on names and deterministic conflicts, then keep local judgment visible and accountable.

A useful event record therefore names the message, thread or mailbox; the exact keyword or attribute; the actor allowed to set or clear it; server, client and protocol identity; previous and new state; rule or user action; evidence reference and confidence; timestamp and expiry; synchronization event; rendered UI; user preference; action taken; downstream receipt; and correction or rollback. Sensitive classifier inputs need not be exposed to every client. Their existence, ownership and reviewability must be provable.

RFC 9979 makes compact state portable. Good governance prevents portability from turning that state into a claim about authenticity, success, time or delivery that no one actually observed.

Sources