Summary

  • RFC 5257 stores persistent metadata beside a message, with explicit private/shared classes and separate read/write rights; attachment does not make the annotation part of the sender's statement.
  • COPY carries all eligible shared annotations and only the current user's eligible private annotations, so a copied message can preserve its bytes while changing the metadata and authority visible around it.

A message arrived with somebody else’s conclusion attached

The mailbox showed a customer request and a bright shared label: “approved.” Months later, nobody could say whether the customer approved the work, a support agent approved a refund, or an administrator copied a label from another folder. The label sat next to the message so convincingly that readers stopped asking who authored it.

RFC 5257 was built to make such metadata useful. It allows comments, alternate subjects, labels and body-part notes to remain on the server and synchronize with disconnected clients. The protocol does not merge that metadata into the original message. The annotation is a separate named entry, attached to the message or one of its parts, with its own attributes and access rules.

That seam is the central governance fact. Proximity is not authorship. Persistence is not endorsement. A note that travels with a message can influence queues, searches and decisions without ever becoming a statement by the sender.

Private and shared are visibility choices

Every annotation attribute implicitly has .priv and .shared forms. A fetch or search can request both by omitting the suffix. A write cannot remain ambiguous: STORE, APPEND and annotation sorting require the client to name the private or shared form.

The distinction solves a real operational problem. A user can keep a personal note on a shared mailbox while the team maintains a common assignment or status. It also creates two failure modes. Put sensitive text in .shared and authorized colleagues may see it. Put an operational handoff in .priv and the team may never receive the state it depends on.

The suffix is not a moral classification. .priv does not mean encrypted, legally privileged or inaccessible to every administrator. .shared does not mean reviewed, correct or approved by the organization. The suffix selects a visibility and access surface inside the server's model.

Rights answer “may act,” not “speaks for”

Without an ACL extension, access follows the selected mailbox state: read-only and read-write modes determine what the client may do. With ACL support, the r right controls private read and write and shared read. The new n right controls shared creation and change.

Those rights are deliberately operational. They make it possible for a team member to update a shared status without granting broader mailbox powers. But a right to write a label does not make the writer the legal principal behind the message. It does not authenticate the customer, transfer ownership or prove approval outside the mailbox.

An audit record must therefore preserve the writer and the ACL snapshot, not just the final shared value. “Approved” written by a workflow account under an n right is one fact. “Approved by the message sender” is a different and usually stronger fact.

Permanent storage can still be rewritten or deleted

RFC 5257 requires annotation data to be stored permanently rather than as session-only state. This ensures a note survives logout and can synchronize to an offline client. It does not make the value immutable.

STORE can create or replace a value. Storing NIL deletes it. Fetching a missing value returns NIL, and the size of a missing value is zero. Without a separate history, the same final absence can mean that no annotation was ever written, that a user deliberately deleted it, or that a copy destination could not carry it.

Disconnected work adds another boundary. The RFC recommends Conditional STORE so a client can detect that somebody changed the state since its last snapshot. Conflict detection prevents one class of blind overwrite. It does not decide which competing annotation is accurate, authorized by the underlying business principal or safe to publish.

Capability is mailbox-specific reality

The server advertises the experimental extension, but each selected mailbox reports what it can actually support. NONE forbids annotation use there. READ-ONLY permits observation but not changes. NOPRIVATE means only shared annotations are supported. Numeric data limits the size of a value; the server may also impose an annotation-count ceiling.

This matters for migrations and automation. A capability banner at the server level does not prove that a particular destination can store a private note or a large binary annotation. A successful message copy does not prove that every associated annotation crossed the same boundary.

The protocol can report size and count failures. Operators should treat those as metadata-delivery failures, not hide them behind a green message-delivery status. The message and its decision context may have separated.

COPY deliberately produces an asymmetric package

On a same-server COPY, an ANNOTATE-capable server copies all shared annotation data and only the current user's private annotation data. It must not copy the private notes of other users. Destination permissions, read-only mode, lack of annotation support and size limits can prevent part of that transfer.

This is sound privacy behavior. It is also proof that “the message was copied” is not enough to describe the resulting record. The destination may contain the identical message plus a different annotation perimeter. One user's private investigation note follows; another user's does not. Shared labels follow if the destination accepts them. Oversized values may remain behind.

A copied shared label also keeps no magical connection to the message author. It may have been written later, under a different ACL, by a different actor and then carried into a new folder. The copy event preserves a value, not its authority.

Search and sort can amplify an unverified annotation

RFC 5257 lets clients search annotation values and sort on private or shared values. That turns metadata into an operational index. A shared status can decide which messages appear in a work queue; an alternate subject can alter order; a vendor label can shape automation.

The greater the influence, the more important provenance becomes. A value can be syntactically valid, readable under ACL and correctly copied while still being stale or wrong. Queryability is not validation. Registration of an entry name says how the field should be interpreted; it does not vouch for an individual instance.

RFC 5464 later defines metadata on servers and mailboxes rather than per-message annotations. The distinction is helpful. “Metadata” is not one universal bucket. Scope determines who can write, what moves, what is queried and which object a claim actually describes.

Build a receipt around the annotation, not only the message

For each consequential value, retain the mailbox and UID context, message or body-part scope, entry name, .priv or .shared class, writer identity and credential, ACL and capability snapshot, previous and new value hashes, state token, server result, deletion event, size/quota decision and any downstream action.

For a copy, add source and destination mailboxes, copy actor, supported annotation modes, each attribute copied or skipped and the reason. Render the note with its writer, time and visibility class. Do not make it visually indistinguishable from message content.

Then describe the evidence precisely. “The shared annotation contained ‘approved’ after this write” is testable. “The sender approved” needs evidence from the sender's authority chain. “The copied folder preserved every reviewer’s context” is false unless the copy receipt proves it.

RFC 5257 created a useful layer of durable context. Leadership should keep it useful by refusing to let contextual metadata impersonate the voice of the record it accompanies.

Sources