Message

Message identity and identifier provenance

A message needs one durable identifier whose generator and uniqueness guarantee are known, plus any secondary identifiers assigned by transport or by the adopting Dimension. RFC 5322 requires the generator to guarantee msg-id uniqueness; CloudEvents requires source+id uniqueness; Matrix assigns a server-side event_id; SMTP separately carries an envelope identifier. These are different identifiers with different guarantors and must not be conflated.

1. Which system generated the message's primary identifier and what is its uniqueness guarantee and scope? identity
2. Is identity single-valued or composite, and if composite which attributes form the key? identity
3. Which secondary identifiers exist for this message and who assigned each one? provenance
4. Does each recipient copy carry the same identifier, and how is a copy distinguished from the original record? identity

Subject, classification, priority and sensitivity

Classifiers that drive handling: topic/subject, functional category, urgency and sensitivity. FHIR distinguishes category, priority, topic and about; XMPP types a stanza as chat, groupchat, headline, normal or error; ActivityStreams types the activity itself. These are separate axes and collapsing them loses handling semantics.

1. Which classification axes apply to this message and which are mandatory for the channel? classification
2. What urgency or priority is asserted, by whom, and does it change handling or retention? classification
3. What sensitivity or confidentiality label applies and what handling constraint does it impose? security
4. How is the human-readable subject distinguished from the machine-resolvable topic or about-reference? definition

Channel type and provider

A channel is the transport medium used or intended, not the message. RFC 5321 defines SMTP client, server, relay, gateway, originating and delivery systems. ActivityPub uses inbox and outbox OrderedCollections and optional sharedInbox. FHIR Communication.medium records how the communication was conveyed. Gatewaying may transform headers and envelopes in ways forbidden to a pure relay. Channel type is classification here; credentials and live sockets are out of scope.

1. Which channel type and provider actually carried this message, and was the hop an origin, relay, gateway or delivery system? classification
2. If federated social transport, which outbox accepted the activity and which inbox or sharedInbox was posted? process
3. If a clinical communication, what medium codes describe how information was shared? classification

Body parts, media typing and alternative representations

MIME makes a message body a recursive tree of entities, each with its own Content-Type, transfer encoding, Content-ID and optional description; MQTT types payload with a Payload Format Indicator and Content Type; Matrix types content by msgtype. Interpretation requires knowing the part tree, the declared type of each node and which sibling parts are alternatives rather than additions.

1. What is the ordered part tree of this message and what is the structural role of each node? composition
2. What media type, subtype, parameters and transfer encoding are declared for each part, and were they verified against the octets? validation
3. Which part is the canonical representation when several alternatives express the same content? decision
4. What natural language and character encoding apply to each textual part? interoperability

Carried payloads: attachments and structured data

A message carries payloads either by value or by reference. MIME Content-Disposition supplies filename and attachment role; FHIR payload is content as attachment, reference or coded concept; CloudEvents adds datacontenttype and dataschema for machine-interpretable payloads. The message owns the carriage relation and payload digest, not the referenced object's own lifecycle.

1. Is each payload carried by value or by reference, and if by reference what resolves the reference and for how long? composition
2. For structured payloads, which schema governs the data and how is schema identity conveyed? interoperability
3. What digest or checksum binds the payload to this message, and over what canonical octets was it computed? evidence
4. Who owns the carried object and does carriage transfer any rights or obligations? ownership

Originator roles, delegation and reply routing

RFC 5322 distinguishes the author (From), the actual releasing agent (Sender, required when From lists several addresses) and the intended reply target (Reply-To); SMTP separately carries the return path used for failure reports. ActivityStreams distinguishes actor from attributedTo, and FHIR distinguishes sender from subject. Delegated and machine-generated sending is the normal case for agents, so authority must be explicit.

1. Who authored the message and who actually released it, and are they the same party? authority
2. If the message was sent on behalf of another party, what authorises that and is the authorisation still valid at send time? authority
3. Where should replies and where should failure reports be directed, and why do they differ? relationship
4. Is the originator identity fully disclosed as required for the message purpose and jurisdiction? constraint

Recipient roles and addressing visibility

Primary, secondary and blind recipient roles carry different disclosure obligations. ActivityStreams states that intermediaries MUST remove bto and bcc before redistribution; RFC 5322 treats Bcc handling as sender-agent dependent. A recipient copy therefore legitimately differs from the originator copy, and the model must record which variant it holds.

1. What addressing role does each recipient entry carry and is that role visible to other recipients? classification
2. Which addressing variant does this stored copy represent — originator view, recipient view or redistributed view? provenance
3. Which addressing fields must be removed or masked before this message is forwarded, archived or exported? privacy
4. When the target is a topic, room or audience rather than a named party, how is the addressed set determined and bounded? relationship

Recipient resolution, expansion and redirection

The address a sender submitted is often not the address that received the message. RFC 3464 keeps Original-Recipient for sender correlation and Final-Recipient as seen by the reporting agent, and defines expanded and relayed actions for list expansion and gatewaying. Losing the submitted value breaks correlation, consent scoping and suppression.

1. What address did the sender submit for this recipient and what address actually received the message? provenance
2. Did this recipient entry expand into multiple targets, and is the resulting set knowable to the sender? composition
3. Was the message redirected or forwarded after acceptance, and does downstream evidence still correlate to the original entry? relationship
4. Does a permission or suppression decision taken on the submitted address still hold for the resolved address? constraint

Envelope versus content separation

RFC 5321 states the delivery reverse-path is simply the address given in MAIL FROM, independent of any header field, and that content is what is sent in DATA. Header From and envelope originator routinely differ, which is the basis of both legitimate forwarding and impersonation. Any model that stores only one of the two loses the ability to reason about authenticity and bounce routing.

1. What are the envelope originator and envelope recipients, and how do they differ from the header-declared parties? identity
2. Which of the two identifier sets was authenticated, and by which mechanism? evidence
3. Is envelope data retained after delivery, and under what rule may it be erased? retention
4. For non-mail channels, which construct plays the envelope role and what is its retention behaviour? interoperability

Handling trace and custody path

Each relay must prepend its own trace entry and must not alter existing ones, producing an append-only, reverse-chronological custody path; Matrix achieves the equivalent through a signed event graph with prev_events. The trace is the primary provenance evidence for when and where a message was handled, and is the main source of traffic data subject to erasure duties.

1. What is the ordered sequence of handling agents and what did each one assert about time and origin? provenance
2. What guarantees that trace entries were not altered or reordered after the fact? quality
3. Which trace entries were created inside the trust boundary of the recording organisation and which are untrusted assertions? security
4. When must trace and traffic data be erased or anonymised, and what is the lawful basis for retaining it longer? retention

Thread identity, membership and participation scope

Threads are constructed differently per channel: XMPP carries an opaque thread identifier with an optional parent, Matrix uses a room plus a thread relation to a root event, and mail has no thread field at all and must be reconstructed from References. Thread identity is therefore either channel-assigned or derived, and the model must record which.

1. Is the thread identifier channel-assigned or derived by reconstruction, and by which algorithm? identity
2. What determines whether a message belongs to the thread, and can membership change after the fact? composition
3. Who participates in the thread, and does a participant see the whole thread or only the messages addressed to them? access
4. How are thread splits, merges and subthreads represented without breaking existing references? relationship

Reply and reference chains

Mail carries In-Reply-To for the immediate parent and References for the ancestor chain; ActivityStreams carries inReplyTo; Matrix carries an explicit reply relation. These pointers can be missing, wrong, or point at messages the holder cannot resolve, so chain reconstruction must be treated as fallible evidence rather than fact.

1. Which message does this one reply to, and is that parent resolvable in the current holding? relationship
2. What ancestor chain is asserted, and does it agree with the parent pointer and the thread assignment? validation
3. How is a broken, forged or circular reference chain detected and represented? quality
4. Does the reply quote or transclude the parent content, and does that create a second copy under separate custody? provenance

Forwarded, resent and corrected messages

RFC 5322 resent fields explicitly reintroduce a message to new recipients without making it a new message, and require their own resent identifier and date; Matrix supports replacement and redaction relations. Redistribution changes the accountable sender and the addressing view while preserving the original content, so the derivation relation must be typed.

1. What kind of derivation produced this message: forward, resend, correction, replacement or recall? classification
2. Who is accountable for the redistributed message, and does original authorship survive the derivation? ownership
3. Was the original content preserved unaltered, and how is any alteration recorded? quality
4. Does the channel support withdrawal of an already-released message, and what does withdrawal actually guarantee? exception

Request-response correlation and expected reply

Machine messaging makes the reply contract explicit: MQTT carries Correlation Data and a Response Topic, XMPP correlates by stanza id, and FHIR distinguishes basedOn (the order being fulfilled) from inResponseTo. For agent-to-agent communication this is the difference between a conversational reply and a contractual response to a request.

1. What correlation token binds this response to its request, and who minted it? identity
2. Where should the response be sent, and is that target different from the request's reply address? process
3. Is a response required, optional or forbidden, and what happens if none arrives within the expected window? constraint
4. Does this message fulfil a prior request or order, and is that fulfilment complete or partial? state

Message state model and terminal outcomes

FHIR types Communication.status from an event status value set including in-progress, completed, not-done, entered-in-error and unknown; DSN types the transport action as failed, delayed, delivered, relayed or expanded. These are different state machines — one about the communication act, one about a delivery attempt for one recipient — and both are needed.

1. At which level is state asserted — the whole message, one recipient entry, or one delivery attempt? state
2. Which states are terminal, which are retryable, and what distinguishes a permanent from a transient failure? lifecycle
3. Which state transitions are permitted and which agent role may assert each transition? authority
4. How is a message recorded as entered in error or never actually sent, without deleting the record? exception

Distinct time points and clock trust

Standards deliberately keep several times apart: the origination date is when the creator finished the message for transmission, not when transport occurred; DSN adds Arrival-Date, Last-Attempt-Date and Will-Retry-Until; FHIR separates sent from received; Matrix records origin_server_ts. RFC 3339 requires an explicit offset and reserves -00:00 for unknown local offset.

1. Which distinct time points are recorded for this message and what does each one actually mean? temporal
2. Is event time separated from observation or ingestion time, and which one is authoritative for ordering? temporal
3. Whose clock produced each timestamp and what is known about its trustworthiness or synchronisation? quality
4. Is the sender's local offset known, and how is an unknown offset represented rather than guessed? temporal
5. Does the message expire, and what happens to it and to its evidence at expiry? lifecycle

Delivery status records and outcome coding

A DSN is a distinct message reporting per-message fields (reporting agent, arrival date, envelope identifier) and per-recipient fields (final recipient, action, status code, diagnostic code, retry window). The enhanced status code is a three-part class/subject/detail structure maintained in an IANA registry, which is the correct vocabulary source rather than local status strings.

1. Which agent issued the status record and was it authorised to speak for the delivery attempt? authority
2. What outcome code was reported, from which registry, and how does it map to the model's outcome classifier? interoperability
3. How does the status record correlate back to the original message and to a specific recipient entry? relationship
4. Can multiple, later or contradictory status records exist for the same recipient, and which one prevails? validation

Registered delivery evidence and legal presumption

An electronic registered delivery service transmits data and provides evidence about its handling, including proof of sending and receiving. Under eIDAS the presumptions of integrity, sending, receipt and accuracy of date and time attach only to qualified services; ETSI EN 319 522 names the evidence set (submission, relay, notification, consignment acceptance or rejection, retrieval, expiration). Evidence must not be conflated with ordinary status reports.

1. Which named evidence event does this record attest, and at which point of the transfer? evidence
2. Who issued the evidence, under which issuing policy, and is that issuer a qualified provider? authority
3. What legal presumption, if any, does this evidence carry and in which jurisdiction? constraint
4. How is the evidence cryptographically bound to the exact payload it attests? evidence
5. How long must the evidence remain verifiable, and what preserves its validity beyond signature expiry? retention

Delivery guarantee level and duplicate control

MQTT makes the guarantee explicit and bounded: at most once may lose messages, at least once may duplicate, exactly once is assured by a four-step handshake. CloudEvents pushes deduplication onto consumers via source+id uniqueness. An agent must know the guarantee before treating an absent acknowledgement as non-delivery or a repeat as a new message.

1. What delivery guarantee did the channel provide for this message, and who selected it? constraint
2. How is a duplicate delivery detected and what is the idempotency key? validation
3. What may be concluded from the absence of an acknowledgement under this guarantee level? decision
4. Does the channel retain the message for later subscribers or offline recipients, and for how long? retention

Disposition notifications and read evidence

MDN reports a disposition (displayed, deleted, dispatched, processed) together with an action mode (manual or automatic) and a sending mode; Matrix reports read receipts and read markers. RFC 8098 states plainly that MDNs do not provide non-repudiation with proof of delivery, can be forged as easily as ordinary mail, may be lost, and may be bypassed by the recipient, and it requires recipient consent before sending.

1. What disposition is reported, and does it mean the content was actually presented to a person? evidence
2. Did the sender request a disposition notification, and did the recipient consent to sending one? authority
3. What is the evidential weight of this report and which specific claims may not be made from it? quality
4. What does a disposition report disclose about the recipient, and is that disclosure permissible? privacy
5. How is the notification target validated to prevent amplification or mail-bombing abuse? security

Origin authentication results and trust boundaries

Authentication-Results records, per method, which identifier was tested and with what result, stamped by an authentication service identifier. The specification requires handling agents to delete any instance claiming to originate inside their trust boundary when it arrives from outside, and warns that consumers should not interpret the field unless configured to trust the stamper.

1. Which authentication methods were evaluated, against which identifier, with what result? evidence
2. Which authentication service stamped the result and is it inside the consuming organisation's trust boundary? authority
3. How are forged or externally injected authentication assertions detected and removed? security
4. What downstream decision may be based on the result, and what must not be inferred from a pass? decision

Protection scope, integrity and post-hoc verifiability

Protection is scoped: MIME allows signing or encrypting individual entities, Matrix encrypts room events end to end while leaving structural fields visible, and eIDAS requires protection of transmitted data against unauthorised alteration. What is protected, what remains observable, and whether verification is still possible after storage transformations are separate questions.

1. Which parts of the message are confidentiality-protected and which metadata remains observable to intermediaries? security
2. Can integrity still be verified from the stored form, and what canonicalisation is required to do so? validation
3. Which storage or transport transformations would invalidate the integrity evidence, and are they prohibited? constraint
4. If content is end-to-end protected, what remains discoverable, auditable or retainable by the custodian? access

Permission basis asserted at send time

Direct-marketing electronic mail generally requires prior consent, with a narrow soft opt-in for existing customers of similar products who were given an easy objection route; GDPR requires the controller to be able to demonstrate consent and makes withdrawal as easy as giving. The message model records the basis cited and the evidence pointer at send time; the consent record itself is governed by a sibling model.

1. On what basis was this recipient contacted for this purpose on this channel? authority
2. When was the permission state evaluated relative to release, and was a fresher state available? temporal
3. Does the basis cover this purpose and this resolved address, or only the address originally submitted? constraint
4. What would be produced to demonstrate the permission if challenged, and where is it held? evidence

Message-carried opt-out and suppression signals

Opt-out is partly a property of the message itself: a valid address for cessation requests must be present, and one-click unsubscribe requires an HTTPS URI, a specific post header and DKIM coverage of both headers, with receivers obtaining user consent before posting. Suppression outcomes then feed back into future send decisions.

1. Does the message carry a valid, working cessation mechanism appropriate to its purpose and channel? requirement
2. Are the opt-out headers covered by the message's authentication signature so a receiver may act on them? security
3. When an opt-out is exercised, what scope does it suppress and within what deadline must it take effect? process
4. How does a suppression signal interact with a still-valid permission record or a non-marketing message? exception

Retention basis, appraisal and disposition

Personal data must not be kept in identifiable form longer than necessary, while public-sector electronic messages are scheduled records that may be appraised by originator role rather than item-by-item. Traffic data carries its own erasure duty distinct from content. Retention is therefore multi-basis and can be assigned at different granularities.

1. What retention rule applies to this message, at what granularity, and who assigned it? authority
2. Do content, addressing metadata, traffic data and evidence share one retention period or different ones? retention
3. What event starts the retention clock and what event ends it? lifecycle
4. What suspends disposition, who may impose and lift that suspension, and how is it evidenced? exception

Redaction, deletion and what survives

Deletion is rarely total: Matrix redaction removes content fields while preserving event identity, sender, timestamp and room, precisely so the conversation graph stays intact. Copies held by recipients and intermediaries are outside the sender's control, so the model must state which copies an erasure action actually reaches.

1. Which fields are removed by a redaction and which are deliberately preserved, and why? process
2. Which copies does a deletion or redaction actually reach, and which remain beyond the actor's control? access
3. What tombstone or audit evidence remains after destruction, and is it sufficient to prove lawful disposal? evidence
4. How does redaction interact with signatures, digests and delivery evidence over the redacted content? constraint

Copy custody, access control and disclosure

Every message exists as several copies with different custodians and different visible content, because blind addressing is stripped on redistribution and confidentiality of communications restricts interception and access by anyone other than the users concerned. Access decisions therefore attach to a specific copy, not to an abstract message.

1. Which custodians hold a copy of this message and how does each copy differ from the originator's? ownership
2. Who may read each copy by default, and which role grants exceptions? access
3. Under what authority may a message be disclosed to a third party, and what is recorded about the disclosure? authority
4. What access and disclosure events must be audited, and how long is the audit trail itself kept? evidence
5. When the message contains personal data about a third party, how are their rights handled without breaching the correspondents' confidentiality? privacy