Summary

  • RFC 9979 registers $istrusted as a shared, advisory IMAP/JMAP keyword set by the server on delivery when both the sender name and email address have been verified with high confidence. Ordinary SPF, DKIM or DMARC success alone is expressly insufficient.
  • The keyword can become a verification indicator in several clients, but the registry token does not prove message safety, user authorization, correct presentation or continued validity. The RFC warns that a compromised server can manipulate keywords to mislead users.
  • Daniel Kade proposes a privacy-preserving correction record that joins the server’s evidence and policy epoch, keyword state, client rendering, reliance and later correction without storing message bodies, secrets or unnecessary behavior.

The most consequential part of the badge may happen after delivery

Imagine a provider sends an urgent account notice. Its receiving mail system recognizes strong, provider-controlled evidence for the displayed name and address and sets $istrusted. A desktop client shows a check mark. A phone client adds a verified-sender label. The user follows the notice because the service itself appears to vouch for it.

Now change one fact. An investigation later concludes that the message should not have received the marker: perhaps the decision service used an obsolete policy, a source of high-confidence evidence was misclassified, or the server itself had been compromised. The original mailbox keyword can be changed. What the organization needs, however, is not merely a new bit. It needs to know which verdict was made, under which policy, where that verdict was displayed, what reliance it invited and whether the correction reached every material surface.

RFC 9979, published in May 2026 as an Informational product of the IETF, defines seventeen message keywords and three mailbox name attributes already seen across implementations. It registers them to avoid collisions and to give servers and clients a common account of intended use. This is coordination work in the best sense: a shared token becomes less ambiguous because its purpose, scope, setter and behavioral consequences are written down.

$istrusted is one of those tokens. The RFC says it indicates that the server has verified the authenticity of both the sender’s name and email address with a high degree of confidence. The typical example is a mailbox provider recognizing its own legitimate communications to customers. A supporting client may use the state to show a verification indicator and help a reader distinguish a real provider message from an impersonation.

The threshold is deliberately stronger than routine mail authentication. RFC 9979 tells servers to exercise caution because the keyword conveys trust to the user and a false application could induce trust in a fraudulent message. It then draws a bright negative line: the marker must not be used merely because SPF, DKIM or DMARC passed. Those mechanisms can contribute evidence within their respective scopes; their ordinary success is not, by itself, the high-confidence judgment represented here.

A registered state is not a self-explaining decision

The IANA IMAP and JMAP Keywords registry classifies $istrusted as shared, common-use and applicable to both protocols. The RFC’s registration calls it advisory and says the server sets it on delivery. These details matter. Shared state can be observed across clients. Server ownership tells a client where the assertion originates. Advisory status distinguishes the token from keywords that may directly trigger an automatic action.

But none of those properties makes the bit self-authenticating or self-explanatory. A client that receives $istrusted learns the server’s current conclusion. It does not receive the server’s evidence bundle, the applicable decision-rule version, the time at which supporting evidence was observed, the identity of a later reviewer or an explanation of why the conclusion changed. Nor does the token state what a client actually showed. One interface may use a small icon; another may use emphatic language; an accessibility layer may express it by sound or text; a third client may ignore it.

That separation is structurally similar to the RFC’s treatment of other keywords, but the consequences differ. $new is an advisory attention signal that a client can clear after interaction. $notify can cause a notification. $muted is set by a client and can lead a server to reduce the prominence of future messages in a thread. $unsubscribed records an attempted unsubscribe, not confirmed completion. Each name coordinates one state or action boundary. It does not absorb the entire workflow around it.

The mailbox attributes reinforce the point. Snoozed identifies a storage location for temporarily deferred mail, but RFC 9979 explicitly says the attribute does not itself define the snoozing mechanism or interface. The IANA mailbox-name registry can make that location discoverable without becoming the scheduler. In the same way, $istrusted can make a server verdict portable without becoming the complete evidentiary and correction system behind the verdict.

“Verified sender” must not quietly expand into “safe instruction”

The semantic limit deserves operational discipline. RFC 9979 describes high-confidence authenticity of the displayed From name and email address. It does not certify every statement in the message, inspect every destination behind a link, authorize a payment, validate an attachment, or prove that a request is appropriate for this recipient at this time. A legitimate sender account can still transmit erroneous, outdated or harmful instructions. A trusted identity and a safe proposed action are different decisions.

Client copy can erase that distinction. A compact check mark may be interpreted as “the provider recognizes this sender.” A banner saying “this message is safe” makes a broader claim. A design that lifts the badge next to a payment button can cause readers to treat identity evidence as transaction approval. Nothing in a shared keyword records which of those interpretations the product encouraged.

The problem is not solved by forcing every client to repeat the server’s authentication work. That would throw away the efficiency and consistency of server-set state. It is solved by preserving a narrow semantic contract: the server owns the sender-authenticity judgment; the client owns how it communicates that judgment; the user or downstream system owns the later decision. Interfaces should name the first without impersonating the third.

Why BTW Media Exists makes the relevant editorial demand: observable reality must not be replaced by an attractive narrative. Here the observable state is that a particular server, under a particular policy, set a particular keyword for a particular message. “The email is safe” is an interpretation that requires more evidence.

Trust in the server is part of the claim, not background scenery

RFC 9979’s general security section is concise and decisive. Use and interpretation of the keywords and attributes depend on the client and user being able to trust the IMAP server. A compromised or malicious server can set or manipulate them incorrectly to mislead users. The trust badge therefore cannot float free of the system that asserted it.

That point changes incident reconstruction. A screenshot of a badge does not establish that the sender was authentic. It establishes that a client rendered some state at some time. To understand the event, an investigator must connect that rendering to the synchronized keyword, the mailbox server that supplied it, the version of the server’s decision policy and the evidence class that satisfied that policy. If the server’s integrity is itself in doubt, the marker becomes part of the contested evidence rather than an independent witness.

The shared nature of the state also creates a distribution problem. A correction made on the server may propagate promptly to one connected client, remain in a local cache on another, or leave behind a notification and screenshot whose persuasive effect cannot be recalled. RFC 9979 does not promise a particular caching or user-interface behavior. Accountable operators should therefore avoid claiming that clearing the bit automatically retracts every human impression created by it.

This is where The Policy Mirror is useful. Policy should reflect the control surface that actually exists. The server controls the keyword decision. Synchronization controls how state reaches clients. Product design controls how authority is expressed. A human controls a later action only within the information the interface reveals. Treating all four as one green check conceals the owners needed for correction.

Correction needs a record of travel, not a copy of the message

The appropriate repair is not a surveillance archive. Mail content, credentials, cryptographic keys, complete authentication traces and detailed reading behavior do not belong in a new central log. The goal is to keep the minimum joins necessary to answer a bounded question: how did this server judgment reach a person or automated surface, and what was done when the judgment changed?

A trust-display correction record can contain six planes.

First, identify the message with a mailbox-scoped object identifier or salted digest, the delivery time and the account scope. Do not duplicate the body. Second, record the decision service, evidence classes, policy/version epoch, decision time and confidence band that produced the high-confidence sender judgment. Raw secrets and unnecessary personal data stay outside.

Third, preserve the keyword-state event: who set $istrusted, the state version, the synchronization scope, and any later removal or replacement with a reason class. Fourth, capture the client rendering at a coarse but useful level: client family and version, the semantic label used, accessibility treatment, first and last known display, and whether the reader could inspect what the badge meant.

Fifth, record only material consequence categories that the organization is entitled to observe—for example, whether a high-risk flow was initiated while the badge was visible—without capturing message content or unrelated behavior. Sixth, preserve correction: who investigated, what conclusion changed, which state interval and clients were affected, how users or accounts were notified, what remediation or appeal route was offered, and who owns closure.

These planes must remain separately attributable. The server team should not claim that a client actually removed a visible badge merely because the server cleared a keyword. The client team should not infer authentic sender evidence from a cached icon. An incident team should not describe a user action as caused by the badge unless timing and presentation support that link. A correction record is useful precisely because it allows uncertainty instead of filling gaps with a smooth story.

This proposal belongs to Daniel Kade, not to RFC 9979. The RFC defines a shared token and its intended semantics. The record makes the operational life of that token reviewable without altering its wire meaning.

Sources