The Payload Was the Same. The Transaction Was New.

Summary

• RFC 5365 defines a pager-mode SIP service that accepts one MESSAGE containing a flat URI list and an instant-message payload, then originates a new MESSAGE request for each intended recipient. The payload may be copied, but the service is a specialized B2BUA rather than a transparent forwarder.
• Each outgoing request has a newly constructed transaction surface. The service should create a new To, Call-ID and CSeq count, initializes Max-Forwards, inserts its Via, conditionally propagates asserted identity, applies privacy precedence and removes security bodies encrypted to itself.
• Governance must therefore preserve separate receipts for input acceptance, canonical recipient, copied payload, new transaction, visible From, asserted identity, security-body audience, recipient-history disclosure, downstream acceptance, delivery and user outcome. A 202 response proves only that the service received the request and will try.

A byte-for-byte payload crossed a non-transparent boundary

RFC 5365 solves a narrow operational problem. A sender wants to deliver a short pager-mode instant message to an ad hoc group without establishing a messaging session. The sender builds a multipart SIP MESSAGE containing a flat resource list and the message payload, addresses it to a MESSAGE URI-list service and requires support for the recipient-list-message option tag.

The service expands the request. It creates one outgoing MESSAGE per intended recipient and normally copies the instant-message payload into each. At first glance, this can look like a relay that merely duplicates bytes.

The specification describes something more active. The service behaves as a specialized back-to-back user agent. On one side, it is the server receiving Alice's request. On the other, it is a client originating a new request to Bob. The payload can remain semantically identical while the transaction, routing and trust evidence are rebuilt.

This is the central distinction. Content continuity answers what message bytes were intended to reach the recipient. Transaction continuity would require the same protocol exchange and identifiers to continue across the boundary. RFC 5365 does not promise that. It deliberately creates new exchanges.

New headers made the new transaction visible

For each recipient, the service should generate a new To header containing that recipient's URI. It should create a new Call-ID because the incoming value may disclose addressing information and need not be shared across both sides. It should maintain a separate CSeq count, initialize Max-Forwards and insert its own Via.

These are not cosmetic changes. Call-ID and CSeq contribute to identifying and ordering SIP exchanges. Via records the path for responses. Max-Forwards establishes a fresh loop bound. The outgoing Request-URI now targets one intended recipient rather than the list service.

An operations dashboard that groups every downstream event solely by the incoming Call-ID will either lose the child transactions or invent a continuity the wire does not contain. Conversely, a dashboard that stores only new Call-IDs will lose the fact that they arose from one input.

The evidence model needs a parent-child mapping. The incoming transaction has its own identifiers and acceptance state. Each canonical recipient has one intended operation. Each attempt has its own outgoing Call-ID, CSeq, branch and routing observations. A stable execution identifier links them without pretending they are one SIP transaction.

The visible sender survived only under a privacy rule

RFC 5365 requires the outgoing From value to match the incoming From, subject to privacy requirements. The tag parameter is not carried as if the same dialog endpoint persisted. A co-located privacy service takes precedence over the URI-list service.

That rule preserves a useful user experience: recipients can see the sender rather than the list service as the conversational author. It does not mean the service did nothing to identity. It evaluated privacy, reconstructed a new request and selected which identity material could appear.

The distinction becomes critical during incident review. “The From value was Alice” is a display and routing claim within SIP syntax. It does not prove that Bob authenticated Alice end to end. The list service may have authenticated Alice and then asserted or reproduced her address under its own authority.

A trustworthy record identifies the source of each claim: the incoming From supplied by the UAC, the credential that authenticated the caller to the service, the privacy instruction, the policy decision, and the outgoing From visible to the recipient. Conflating them lets a displayed identity inherit strength from a credential it never carried.

Asserted identity stopped at the trust boundary

P-Asserted-Identity has a different contract. If it arrived from a trusted source and the first outgoing hop is also trusted, the service must propagate it. If the next hop is untrusted and privacy was requested, it must not include the assertion.

The service may also insert an assertion when it can authenticate a user and map that authentication to a SIP or SIPS URI, again subject to privacy. This is an act of assertion by the service. It is not the forwarding of an immutable identity token whose meaning is universal.

Trust is therefore directional and local. An assertion accepted on the inbound side is not automatically safe on the outbound side. The next hop, administrative domain and privacy value change the decision. A configuration change in routing can change whether identity material may leave even when payload and recipient stay constant.

The audit receipt should retain inbound trust classification, assertion value, authentication method, mapping rule, privacy instruction, outbound first-hop trust and the final inclusion or suppression decision. “PAI present” without that path cannot explain why the field was legitimate.

Credentials followed realms, not payloads

Authorization and Proxy-Authorization headers reveal another boundary. If their realm belongs to the MESSAGE URI-list server, the service should not copy them to the outgoing request. Those credentials answered a challenge for the intermediary, not for Bob's server.

If the incoming authorization field names a different realm, RFC 5365 requires the corresponding value to be copied. The decision is scoped by the authentication domain, not by the fact that the message body is being copied.

This is a practical rule against credential leakage and authentication failure. A token useful at the list service may be meaningless or dangerous downstream. Removing it does not alter the instant-message payload. It alters who can claim that the outgoing request was authenticated under which authority.

Operators need a realm-decision log that does not expose secret material: credential type, realm classification, copy or suppression decision and destination trust context. Logging the raw credential would create a new security problem; logging no decision makes it impossible to distinguish deliberate scoping from accidental loss.

A security body belonged to its cryptographic audience

An incoming multipart MESSAGE can contain S/MIME or another security body encrypted for the URI-list service. Recipients cannot decrypt that object. RFC 5365 therefore says the service must not copy a security body addressed to itself into outgoing requests.

This is the sharpest proof that “copy the message” is not “copy every byte.” The service must interpret the cryptographic audience. It consumes material intended for its own processing and constructs a recipient-appropriate body set.

The remaining instant-message payload may still need protection for recipients. RFC 5365 says a recipient-list-history body should be encrypted to the receiver when included. That is a new protection operation with a different audience and potentially a different key.

End-to-end is not a magic property of a multipart envelope. It is a relationship between protected content, origin, audience, algorithms and keys. A body can be end-to-end from Alice to the list service and still not be end-to-end from Alice to Bob. The intermediary cannot extend that statement merely by preserving plaintext after decryption.

Representation changed even when meaning was retained

The service should copy the remaining message bodies, such as text or images. If only one body remains after removing list and service-addressed security material, it must remove the multipart/mixed wrapper.

Bob may therefore receive a different wire representation of the same intended content. MIME boundaries disappear. Content-disposition structure changes. A recipient-history part may be added. Cryptographic parts may be removed or newly created.

Byte equality across whole requests is neither expected nor desirable. The stronger verification compares declared semantic components: the source payload part, its media type and hash; transformations permitted by the contract; the outgoing payload part and hash; and every added or removed body with a reason.

This prevents two opposite errors. Requiring full-message byte identity would reject compliant transformation. Checking only rendered text would miss a changed attachment, media type or body disposition. The receipt must be at the level where the RFC promises preservation.

Embedded hints did not outrank service authority

SIP URIs can carry header components through the question-mark mechanism. The UAC may ask the service to add a header such as Accept-Contact for one destination. The special body hname must not be used, and a service may discard such a body parameter if it appears.

A URI can also include a method parameter. RFC 5365 is unequivocal: the MESSAGE list service generates only MESSAGE requests and must ignore a method parameter requesting something else.

This keeps the service's authority legible. An embedded hint can refine a request on a component-by-component basis; it cannot silently turn a messaging service into an INVITE or another action. The service contract outranks untrusted or accidental method syntax in a list entry.

The output record should show which URI components were honored, rejected or ignored. Otherwise the caller may believe a preference was enforced when it was not, while the recipient sees an unexplained header that came from list data rather than service policy.

Recipient history was a constructed disclosure

To support reply-to-all, the service may attach a recipient-list-history body based on the input list and RFC 5364 rules. Non-anonymous To and Cc targets can be shown, while Bcc and anonymized entries require different treatment.

The history is not simply the original list copied into every message. It is a view constructed for a particular receiver after applying copy-control, anonymization and count rules. RFC 5365 recommends encrypting it with the receiver's public key.

This view creates new consequences. It can enable a reply to the other participants, and it can disclose membership relationships. Correct delivery of the message payload does not prove correct construction of the history. Correct construction for Bob does not prove Carol should see the same view.

RFC 5364 owns the detailed disclosure policy and is adjacent coverage. The RFC 5365 boundary here is architectural: the B2BUA creates a new body whose provenance and audience differ from the original payload. It needs its own transformation and protection receipt.

A 202 response ended at acceptance

On receiving the group MESSAGE, the service returns 202 Accepted. RFC 5365 explicitly warns that this status says nothing about whether the generated MESSAGE requests were successfully delivered. It means the service received the request and will try.

That limitation is not a defect in 202. It is the correct scope of an asynchronous acknowledgement. The downstream requests do not share one terminal state, and RFC 5365 leaves delivery-status design outside scope.

The caller therefore needs separate observations if delivery matters. The service can record request creation, routing and downstream SIP responses. An application may have delivery receipts. Only an endpoint or user-facing mechanism can establish later effects.

This supports but does not duplicate the RFC 5363 Article. The present thesis is not merely that results are plural. It is that a service which preserves payload semantics is simultaneously the authority that reconstructs the transaction and security surfaces on which those results depend.

Twelve receipts kept the boundary honest

A defensible record separates at least twelve claims:

1. The incoming MESSAGE was authenticated and accepted by the list service.
2. The exact flat recipient list was parsed, canonicalized and authorized.
3. The service identified the payload parts it promised to preserve.
4. It created one intended operation per canonical recipient.
5. Each attempt received a new downstream transaction identity and routing state.
6. Outgoing From was derived under the applicable privacy rule.
7. Asserted identity was propagated, suppressed or generated under a recorded trust decision.
8. Authorization material was copied or withheld according to realm scope.
9. Service-addressed security bodies were consumed rather than misdirected.
10. Payload and recipient-history bodies were transformed and protected for their actual audiences.
11. Each downstream operation produced acceptance, failure or bounded uncertainty.
12. Independent evidence established delivery or user-visible outcome when required.

No earlier receipt supplies a later one. Same payload is not same transaction. Same From is not end-to-end authentication. A trusted assertion is not portable across an untrusted hop. A 202 is not delivery.

The registry standardized capabilities, not execution

IANA records recipient-list-message and the related recipient-list dispositions in the SIP parameter registry. These shared names let implementations negotiate and parse the feature. They do not prove that a server implements it correctly, that a particular identity transformation was legitimate or that any message arrived.

RFC 5365 was published in October 2008 on the Standards Track. RFC 3851 later became obsolete through the S/MIME specification lineage, including RFC 8551. That succession matters when selecting current cryptographic mechanisms, while the audience boundary described by RFC 5365 remains the analytical point.

Lu Heng's Minimum Initial Specification note supplies a later lens: standardize the smallest shared contract and leave future decisions to the actors with local information. The option tag and body formats form a shared layer; privacy, trust mapping, credential realm and result evidence remain local decisions.

His Reality Layers note supplies the second lens. A preserved payload hash is symbolic evidence about content. A newly originated request, a recipient's security view and actual delivery are different operational realities. The notes are disclosed analytical lenses; the RFCs and IANA registry carry the protocol facts.