Message

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.

Questions

1. Which system generated the message's primary identifier and what is its uniqueness guarantee and scope?identity
   Expected answer

   • identifier value
   • generating system or domain
   • uniqueness scope (global, source-scoped, room-scoped)
   • identifier syntax or scheme reference
2. Is identity single-valued or composite, and if composite which attributes form the key?identity
   Expected answer

   • composite key components (e.g. source + id)
   • reason for compositeness
   • collision-resolution rule
3. Which secondary identifiers exist for this message and who assigned each one?provenance
   Expected answer

   • identifier value
   • assigning role (originator, submission agent, relay, store)
   • assignment time (RFC 3339)
   • binding strength (authoritative, advisory)
4. Does each recipient copy carry the same identifier, and how is a copy distinguished from the original record?identity
   Expected answer

   • copy identifier
   • custodian reference
   • relation to originator record

Artifacts

• Message recordThe aggregate root: the persisted representation of one communication act, binding identity, classification, content parts, addressing entries and evidence references.

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.

Questions

1. Which classification axes apply to this message and which are mandatory for the channel?classification
   Expected answer

   • axis name
   • code value
   • code system or registry reference
   • obligation (required, conditional, optional)
2. What urgency or priority is asserted, by whom, and does it change handling or retention?classification
   Expected answer

   • priority code
   • asserting role
   • handling effect
3. What sensitivity or confidentiality label applies and what handling constraint does it impose?security
   Expected answer

   • sensitivity label
   • labelling authority
   • permitted handling actions
   • redistribution restriction
4. How is the human-readable subject distinguished from the machine-resolvable topic or about-reference?definition
   Expected answer

   • subject text
   • topic code
   • about reference
   • language tag

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.

Questions

1. Which channel type and provider actually carried this message, and was the hop an origin, relay, gateway or delivery system?classification
   Expected answer

   • channel-type, provider-ref, hop-role enum origin | relay | gateway | delivery, protocol-profile.
2. If federated social transport, which outbox accepted the activity and which inbox or sharedInbox was posted?process
   Expected answer

   • outbox-iri, inbox-iri, shared-inbox-iri, posted-at.
3. If a clinical communication, what medium codes describe how information was shared?classification
   Expected answer

   • List of FHIR medium CodeableConcepts with system and code.

Artifacts

• channel-descriptorChannel type, provider, protocol profile and whether this hop is origin, relay, gateway or delivery.

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.

Questions

1. What is the ordered part tree of this message and what is the structural role of each node?composition
   Expected answer

   • part path or index
   • parent part reference
   • structural role (alternative, mixed, related, signed, encrypted)
2. What media type, subtype, parameters and transfer encoding are declared for each part, and were they verified against the octets?validation
   Expected answer

   • media type and parameters
   • declared transfer encoding
   • verification outcome
   • verifying agent
3. Which part is the canonical representation when several alternatives express the same content?decision
   Expected answer

   • canonical part reference
   • selection rule
   • fallback order
4. What natural language and character encoding apply to each textual part?interoperability
   Expected answer

   • language tag
   • charset parameter
   • directionality

Artifacts

• Message content partOne typed entity in the message content tree, holding either a leaf body or a nested multipart structure.

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.

Questions

1. Is each payload carried by value or by reference, and if by reference what resolves the reference and for how long?composition
   Expected answer

   • carriage mode
   • reference URI or resource identifier
   • resolution authority
   • reference validity window
2. For structured payloads, which schema governs the data and how is schema identity conveyed?interoperability
   Expected answer

   • schema identifier or URI
   • schema version
   • content type of data
   • validation outcome
3. What digest or checksum binds the payload to this message, and over what canonical octets was it computed?evidence
   Expected answer

   • digest algorithm
   • digest value
   • canonicalization applied
   • computing agent
4. Who owns the carried object and does carriage transfer any rights or obligations?ownership
   Expected answer

   • payload owner reference
   • rights statement
   • retention obligation on the copy

Artifacts

• Payload carriage entryThe record binding one carried payload to the message: carriage mode, reference, presented name, declared type, schema and digest.

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.

Questions

1. Who authored the message and who actually released it, and are they the same party?authority
   Expected answer

   • author party reference
   • releasing agent reference
   • delegation basis
   • delegation evidence reference
2. If the message was sent on behalf of another party, what authorises that and is the authorisation still valid at send time?authority
   Expected answer

   • principal party reference
   • authorisation instrument reference
   • validity window (RFC 3339)
   • scope limits
3. Where should replies and where should failure reports be directed, and why do they differ?relationship
   Expected answer

   • reply target address
   • return path address
   • divergence reason
4. Is the originator identity fully disclosed as required for the message purpose and jurisdiction?constraint
   Expected answer

   • disclosed identity value
   • purpose of the message
   • applicable disclosure rule reference
   • compliance outcome

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.

Questions

1. What addressing role does each recipient entry carry and is that role visible to other recipients?classification
   Expected answer

   • recipient reference
   • role code (primary, secondary, blind, audience)
   • visibility to other recipients
2. Which addressing variant does this stored copy represent — originator view, recipient view or redistributed view?provenance
   Expected answer

   • copy variant code
   • custodian reference
   • fields removed or masked
3. Which addressing fields must be removed or masked before this message is forwarded, archived or exported?privacy
   Expected answer

   • field names to remove
   • triggering rule reference
   • enforcing component
4. When the target is a topic, room or audience rather than a named party, how is the addressed set determined and bounded?relationship
   Expected answer

   • topic or room identifier
   • audience determination rule
   • membership snapshot time (RFC 3339)

Artifacts

• Recipient addressing entryOne recipient slot on a message, holding role, submitted value, resolved value and visibility flags; the unit against which per-recipient delivery evidence is recorded.

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.

Questions

1. What address did the sender submit for this recipient and what address actually received the message?provenance
   Expected answer

   • submitted address value
   • resolved address value
   • resolving component
   • resolution time (RFC 3339)
2. Did this recipient entry expand into multiple targets, and is the resulting set knowable to the sender?composition
   Expected answer

   • expansion indicator
   • expanded target count
   • visibility to sender
   • expanding component
3. Was the message redirected or forwarded after acceptance, and does downstream evidence still correlate to the original entry?relationship
   Expected answer

   • redirection indicator
   • downstream address
   • correlation identifier retained
4. Does a permission or suppression decision taken on the submitted address still hold for the resolved address?constraint
   Expected answer

   • permission scope basis
   • re-evaluation requirement
   • decision outcome

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.

Questions

1. What are the envelope originator and envelope recipients, and how do they differ from the header-declared parties?identity
   Expected answer

   • envelope originator value
   • envelope recipient values
   • header originator value
   • alignment outcome
2. Which of the two identifier sets was authenticated, and by which mechanism?evidence
   Expected answer

   • authenticated identifier
   • mechanism (spf, dkim, dmarc, auth)
   • result value
   • evaluating authority
3. Is envelope data retained after delivery, and under what rule may it be erased?retention
   Expected answer

   • retention indicator
   • retention basis
   • erasure rule reference
4. For non-mail channels, which construct plays the envelope role and what is its retention behaviour?interoperability
   Expected answer

   • channel identifier
   • envelope-equivalent construct
   • broker or server retention behaviour

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.

Questions

1. What is the ordered sequence of handling agents and what did each one assert about time and origin?provenance
   Expected answer

   • handling agent identifier
   • received-from value
   • asserted timestamp (RFC 3339)
   • sequence position
2. What guarantees that trace entries were not altered or reordered after the fact?quality
   Expected answer

   • append-only guarantee
   • signature or hash chain reference
   • verification outcome
3. Which trace entries were created inside the trust boundary of the recording organisation and which are untrusted assertions?security
   Expected answer

   • trust boundary identifier
   • entry classification
   • policy applied to untrusted entries
4. When must trace and traffic data be erased or anonymised, and what is the lawful basis for retaining it longer?retention
   Expected answer

   • erasure trigger
   • retention basis
   • permitted purpose
   • approving role

Artifacts

• Handling trace recordAppend-only sequence of custody entries describing each agent that received, relayed or gatewayed the message, with asserted times and trust classification.

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.

Questions

1. Is the thread identifier channel-assigned or derived by reconstruction, and by which algorithm?identity
   Expected answer

   • thread identifier
   • assignment mode
   • reconstruction algorithm reference
   • confidence
2. What determines whether a message belongs to the thread, and can membership change after the fact?composition
   Expected answer

   • membership rule
   • mutability indicator
   • reassignment event reference
3. Who participates in the thread, and does a participant see the whole thread or only the messages addressed to them?access
   Expected answer

   • participant reference
   • join and leave times (RFC 3339)
   • visible message range
4. How are thread splits, merges and subthreads represented without breaking existing references?relationship
   Expected answer

   • parent thread identifier
   • split or merge event
   • affected message identifiers

Artifacts

• Conversation threadThe grouping object for messages exchanged in one conversation, holding thread identity, root, participation window and split/merge history.

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.

Questions

1. Which message does this one reply to, and is that parent resolvable in the current holding?relationship
   Expected answer

   • parent message identifier
   • resolution status
   • holding location
2. What ancestor chain is asserted, and does it agree with the parent pointer and the thread assignment?validation
   Expected answer

   • ancestor identifier list
   • consistency outcome
   • conflict description
3. How is a broken, forged or circular reference chain detected and represented?quality
   Expected answer

   • defect type
   • detection rule
   • representation of the unresolved link
4. Does the reply quote or transclude the parent content, and does that create a second copy under separate custody?provenance
   Expected answer

   • quotation indicator
   • quoted extent
   • custody implication

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.

Questions

1. What kind of derivation produced this message: forward, resend, correction, replacement or recall?classification
   Expected answer

   • derivation type code
   • source message identifier
   • deriving party reference
   • derivation time (RFC 3339)
2. Who is accountable for the redistributed message, and does original authorship survive the derivation?ownership
   Expected answer

   • redistributing party
   • original author reference
   • attribution statement
3. Was the original content preserved unaltered, and how is any alteration recorded?quality
   Expected answer

   • fidelity indicator
   • alteration description
   • integrity evidence reference
4. Does the channel support withdrawal of an already-released message, and what does withdrawal actually guarantee?exception
   Expected answer

   • withdrawal support indicator
   • withdrawal scope
   • copies not reachable by withdrawal

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.

Questions

1. What correlation token binds this response to its request, and who minted it?identity
   Expected answer

   • correlation token
   • minting party
   • token scope and lifetime
2. Where should the response be sent, and is that target different from the request's reply address?process
   Expected answer

   • response target address or topic
   • divergence from reply target
   • validity window
3. Is a response required, optional or forbidden, and what happens if none arrives within the expected window?constraint
   Expected answer

   • response obligation code
   • expected response deadline (RFC 3339)
   • timeout handling rule
4. Does this message fulfil a prior request or order, and is that fulfilment complete or partial?state
   Expected answer

   • fulfilled request reference
   • fulfilment completeness
   • remaining obligation

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.

Questions

1. At which level is state asserted — the whole message, one recipient entry, or one delivery attempt?state
   Expected answer

   • state scope code
   • subject reference
   • asserting agent
2. Which states are terminal, which are retryable, and what distinguishes a permanent from a transient failure?lifecycle
   Expected answer

   • state value
   • terminality flag
   • failure class (permanent, transient)
   • retry window (RFC 3339)
3. Which state transitions are permitted and which agent role may assert each transition?authority
   Expected answer

   • from state
   • to state
   • authorised role
   • required evidence
4. How is a message recorded as entered in error or never actually sent, without deleting the record?exception
   Expected answer

   • error state value
   • reason code
   • correcting party
   • correction time (RFC 3339)

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.

Questions

1. Which distinct time points are recorded for this message and what does each one actually mean?temporal
   Expected answer

   • time point name
   • value with explicit offset
   • asserting agent
   • semantic definition reference
2. Is event time separated from observation or ingestion time, and which one is authoritative for ordering?temporal
   Expected answer

   • event time
   • observation time
   • ordering basis
   • tie-break rule
3. Whose clock produced each timestamp and what is known about its trustworthiness or synchronisation?quality
   Expected answer

   • clock owner
   • synchronisation source
   • trust classification
   • known skew
4. Is the sender's local offset known, and how is an unknown offset represented rather than guessed?temporal
   Expected answer

   • offset value
   • unknown-offset representation
   • originating locale if known
5. Does the message expire, and what happens to it and to its evidence at expiry?lifecycle
   Expected answer

   • expiry instant or interval
   • expiry behaviour
   • evidence generated at expiry

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.

Questions

1. Which agent issued the status record and was it authorised to speak for the delivery attempt?authority
   Expected answer

   • reporting agent identifier
   • authority basis
   • trust boundary position
2. What outcome code was reported, from which registry, and how does it map to the model's outcome classifier?interoperability
   Expected answer

   • status code value
   • code registry reference
   • mapped outcome class
   • mapping confidence
3. How does the status record correlate back to the original message and to a specific recipient entry?relationship
   Expected answer

   • original message identifier
   • envelope identifier
   • original recipient value
   • correlation confidence
4. Can multiple, later or contradictory status records exist for the same recipient, and which one prevails?validation
   Expected answer

   • record sequence
   • supersession rule
   • conflict resolution outcome

Artifacts

• Delivery status recordA machine-readable report about the outcome of a delivery attempt for one or more recipients, issued by a handling agent and correlatable to the original submission.

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.

Questions

1. Which named evidence event does this record attest, and at which point of the transfer?evidence
   Expected answer

   • evidence type code
   • transfer point
   • subject message identifier
   • event time (RFC 3339)
2. Who issued the evidence, under which issuing policy, and is that issuer a qualified provider?authority
   Expected answer

   • issuer identifier
   • issuing policy reference
   • qualified status
   • supervisory listing reference
3. What legal presumption, if any, does this evidence carry and in which jurisdiction?constraint
   Expected answer

   • presumption claimed
   • jurisdiction
   • legal basis reference
   • rebuttability note
4. How is the evidence cryptographically bound to the exact payload it attests?evidence
   Expected answer

   • payload digest
   • digest algorithm
   • signature or seal reference
   • validation outcome
5. How long must the evidence remain verifiable, and what preserves its validity beyond signature expiry?retention
   Expected answer

   • evidence retention period
   • preservation mechanism
   • re-validation schedule

Artifacts

• Registered delivery evidence tokenA signed or sealed record issued by a registered delivery service attesting a named event in the transfer, bound to the payload digest and the identified sender and recipient.

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.

Questions

1. What delivery guarantee did the channel provide for this message, and who selected it?constraint
   Expected answer

   • guarantee level code
   • selecting party
   • channel identifier
2. How is a duplicate delivery detected and what is the idempotency key?validation
   Expected answer

   • idempotency key components
   • duplicate detection rule
   • action on duplicate
3. What may be concluded from the absence of an acknowledgement under this guarantee level?decision
   Expected answer

   • inference permitted
   • inference forbidden
   • escalation rule
   • observation window
4. Does the channel retain the message for later subscribers or offline recipients, and for how long?retention
   Expected answer

   • retention behaviour
   • retention period
   • recipients affected

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.

Questions

1. What disposition is reported, and does it mean the content was actually presented to a person?evidence
   Expected answer

   • disposition type
   • action mode (manual, automatic)
   • sending mode
   • presentation inference permitted
2. Did the sender request a disposition notification, and did the recipient consent to sending one?authority
   Expected answer

   • notification requested indicator
   • request target address
   • recipient consent indicator
   • consent capture time (RFC 3339)
3. What is the evidential weight of this report and which specific claims may not be made from it?quality
   Expected answer

   • forgeability note
   • non-repudiation claim permitted
   • absence-of-report interpretation
4. What does a disposition report disclose about the recipient, and is that disclosure permissible?privacy
   Expected answer

   • disclosed attributes
   • lawful basis
   • suppression option offered
5. How is the notification target validated to prevent amplification or mail-bombing abuse?security
   Expected answer

   • target validation rule
   • mismatch with return path
   • action on mismatch

Artifacts

• Disposition notification recordA recipient-side report of what was done with a message, carrying disposition type, mode, correlation identifiers and an explicit reliability qualification.

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.

Questions

1. Which authentication methods were evaluated, against which identifier, with what result?evidence
   Expected answer

   • method name
   • evaluated identifier
   • result value
   • evaluation time (RFC 3339)
2. Which authentication service stamped the result and is it inside the consuming organisation's trust boundary?authority
   Expected answer

   • authentication service identifier
   • trust boundary relation
   • trust decision
3. How are forged or externally injected authentication assertions detected and removed?security
   Expected answer

   • detection rule
   • removal action
   • audit entry reference
4. What downstream decision may be based on the result, and what must not be inferred from a pass?decision
   Expected answer

   • permitted decisions
   • prohibited inferences
   • fallback when result is none or temperror

Artifacts

• Authentication results assertionA stamped record of authentication outcomes for one message, attributable to a named authentication service and scoped to a trust boundary.

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.

Questions

1. Which parts of the message are confidentiality-protected and which metadata remains observable to intermediaries?security
   Expected answer

   • protected part references
   • observable metadata list
   • protection mechanism
2. Can integrity still be verified from the stored form, and what canonicalisation is required to do so?validation
   Expected answer

   • canonicalisation rule
   • verification procedure
   • last successful verification time (RFC 3339)
   • verification outcome
3. Which storage or transport transformations would invalidate the integrity evidence, and are they prohibited?constraint
   Expected answer

   • prohibited transformations
   • permitted transformations
   • mitigation when transformation is unavoidable
4. If content is end-to-end protected, what remains discoverable, auditable or retainable by the custodian?access
   Expected answer

   • custodian-visible fields
   • recoverability of plaintext
   • governance consequence for retention and disclosure

Artifacts

• Protected content objectThe signed or encrypted representation of message content together with the parameters needed to verify or decrypt it later, excluding key material itself.

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.

Questions

1. On what basis was this recipient contacted for this purpose on this channel?authority
   Expected answer

   • basis code (consent, soft opt-in, contract, legal obligation, legitimate interest)
   • purpose
   • channel
   • evidence reference
2. When was the permission state evaluated relative to release, and was a fresher state available?temporal
   Expected answer

   • evaluation time (RFC 3339)
   • release time
   • staleness window
   • re-evaluation requirement
3. Does the basis cover this purpose and this resolved address, or only the address originally submitted?constraint
   Expected answer

   • covered purposes
   • covered endpoints
   • gap description
   • decision outcome
4. What would be produced to demonstrate the permission if challenged, and where is it held?evidence
   Expected answer

   • evidence artifact reference
   • holding system
   • retention period
   • retrieval procedure

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.

Questions

1. Does the message carry a valid, working cessation mechanism appropriate to its purpose and channel?requirement
   Expected answer

   • mechanism type
   • target URI or address
   • validity check outcome
   • checking agent
2. Are the opt-out headers covered by the message's authentication signature so a receiver may act on them?security
   Expected answer

   • signature coverage indicator
   • covered field list
   • receiver action permitted
3. When an opt-out is exercised, what scope does it suppress and within what deadline must it take effect?process
   Expected answer

   • suppression scope (endpoint, subject, purpose, all channels)
   • effective deadline
   • confirming record reference
4. How does a suppression signal interact with a still-valid permission record or a non-marketing message?exception
   Expected answer

   • precedence rule
   • exempt message classes
   • override authority

Artifacts

• Suppression entryA record that a given endpoint, subject or purpose must not be contacted, created from an exercised opt-out or objection and consulted before any subsequent send.

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.

Questions

1. What retention rule applies to this message, at what granularity, and who assigned it?authority
   Expected answer

   • schedule or rule reference
   • granularity (item, role, category, thread)
   • assigning role
   • assignment time (RFC 3339)
2. Do content, addressing metadata, traffic data and evidence share one retention period or different ones?retention
   Expected answer

   • component name
   • retention period
   • erasure trigger
   • legal basis
3. What event starts the retention clock and what event ends it?lifecycle
   Expected answer

   • clock-start event
   • clock-end event
   • computed disposition date
4. What suspends disposition, who may impose and lift that suspension, and how is it evidenced?exception
   Expected answer

   • hold identifier
   • imposing authority
   • scope
   • imposition and release times (RFC 3339)

Artifacts

• Applied disposition instructionThe record binding a message or a class of messages to a retention rule, the computed disposition date, any holds, and the executed disposition outcome.

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.

Questions

1. Which fields are removed by a redaction and which are deliberately preserved, and why?process
   Expected answer

   • removed field list
   • preserved field list
   • preservation rationale
   • authorising role
2. Which copies does a deletion or redaction actually reach, and which remain beyond the actor's control?access
   Expected answer

   • reachable custodians
   • unreachable custodians
   • notification obligation
3. What tombstone or audit evidence remains after destruction, and is it sufficient to prove lawful disposal?evidence
   Expected answer

   • tombstone fields retained
   • audit record reference
   • destruction time (RFC 3339)
   • executing role
4. How does redaction interact with signatures, digests and delivery evidence over the redacted content?constraint
   Expected answer

   • invalidated evidence references
   • mitigation
   • record of the conflict

Artifacts

• Redaction or destruction recordEvidence that an erasure action occurred, naming the target message, the fields removed, the surviving tombstone, the authority and the execution time.

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.

Questions

1. Which custodians hold a copy of this message and how does each copy differ from the originator's?ownership
   Expected answer

   • custodian reference
   • copy variant
   • fields absent or masked
   • holding system
2. Who may read each copy by default, and which role grants exceptions?access
   Expected answer

   • default access rule
   • granting role
   • exception basis
   • expiry of the grant
3. Under what authority may a message be disclosed to a third party, and what is recorded about the disclosure?authority
   Expected answer

   • disclosure authority reference
   • requesting party
   • scope disclosed
   • disclosure time (RFC 3339)
4. What access and disclosure events must be audited, and how long is the audit trail itself kept?evidence
   Expected answer

   • auditable event types
   • audit fields
   • audit retention period
   • audit custodian
5. When the message contains personal data about a third party, how are their rights handled without breaching the correspondents' confidentiality?privacy
   Expected answer

   • affected subject reference
   • request type
   • redaction applied
   • balancing decision record

Artifacts

• Message copy holdingA custodied instance of a message in one holding system, with its variant, access rule, grants, disclosure history and audit trail.