Summary

  • RFC 9788 makes HP-Outer a protected receipt of the header values a composer deliberately exposed, rather than letting an encryption icon imply that every field was confidential.
  • Actual MIME cryptographic layers outrank the composer's hp intent; protected and outer From, certificate binding, transport authentication, display and reply addressing remain separate decisions.
  • Operators should preserve the whole decision chain and test reply leakage, because a correct standard, registry row or encrypted copy does not prove deployed behavior or end-user privacy.

The message opens with a familiar promise: a lock beside the sender's name, a subject replaced by [...], and a body that decrypts without error. The temptation is to turn those three facts into one sentence—the email was secure. That sentence is too large for the evidence.

Was the visible outer From protected? Did the signer possess a credential correctly bound to the protected inner address? Was the subject genuinely absent outside the cryptographic envelope when the composer injected the message, or merely absent when the recipient inspected it? Did a mailing system add a header later? If the outer sender was changed in transit, should the interface display the inner value, and which value should a reply use?

RFC 9788 is valuable because it refuses to award all of those decisions to the lock. It treats header protection as a set of field-specific claims whose provenance can be examined.

The envelope protects a subtree, not an adjective

RFC 9787 supplies the underlying model. S/MIME and PGP/MIME protect MIME substructures. A signing layer offers integrity and authenticity; an encryption layer offers confidentiality, with integrity depending on the form. Several layers can be nested, and their order matters. The largest contiguous series beginning at the message's outer MIME type is the cryptographic envelope. The first non-cryptographic part inside it is the payload.

That physical structure is the received fact. A signed-then-encrypted message is not the same construction as an encrypted-then-signed message. A cryptographic object buried inside an ordinary MIME part is not automatically part of the message's envelope. Compression inside CMS is not a cryptographic layer merely because it uses the same family of containers.

This matters for headers because ordinary encrypted mail historically protected the body while leaving substantial message metadata outside. An attacker might alter a subject or apparent author without breaking body encryption. RFC 8551 described a header-protection method by wrapping a complete message/rfc822 object. RFC 9788 replaces that construction after legacy clients proved liable to awkward rendering and security behavior.

The new construction copies the header fields known to the composer directly into the cryptographic payload. For an encrypted message, the composer may leave a field unchanged outside, obscure it there, or remove it. Those choices are not equal. A field can have an encrypted copy and still have been disclosed verbatim to every transport agent.

HP-Outer records what the composer exposed

The key instrument is not a stronger icon. It is a new field inside the encrypted payload: HP-Outer.

For every non-structural header deliberately placed outside the envelope, the composing client must include a protected HP-Outer copy containing the field name and the outer value. If Date and From were exposed unchanged, the payload carries protected records of those exact choices. If Subject was replaced outside with [...], its record preserves that replacement. If a protected field has no corresponding HP-Outer, the composer asserts that it placed no instance of that field outside when injecting the message.

The word asserts is important. HP-Outer is a receipt for the composer's act, protected with the rest of the payload. It is not a camera observing the entire delivery path. An intermediary may later remove an outer field, rewrite it or add a new one. A receiving system may attach Received, list-management or archival fields. The recipient may infer an allegedly hidden recipient from the delivery destination or key identifiers. None of those later facts rewrites what the receipt proves.

Without this record, a malicious intermediary could manufacture a false appearance of confidentiality simply by deleting an outer field. Imagine that the composer passed Cc in clear text and also placed it inside the encrypted payload. If an attacker removes the outer Cc, a naive client comparing only the final outside and inside sets might label the inner field encrypted. The matching HP-Outer record reveals that the composer had deliberately disclosed it. The cautious client can call it signed for display while still treating it conservatively during reply.

This is Heng Lu's reality-layer discipline in miniature. A record should describe its layer precisely. It must not inherit the authority of the event, path or outcome that it did not observe.

Confidentiality is a policy function

RFC 9788 calls the composer's rule a Header Confidentiality Policy, or HCP. It is a function over a non-structural field name and value. The output can be identical, an obscured replacement, or null, meaning omission from the outer header section.

The recommended hcp_baseline is deliberately modest. It replaces the outer Subject with [...], removes the less common Comments and Keywords fields, and passes the rest through. A more ambitious hcp_shy also strips display names from address fields and converts Date to UTC. The latter can reduce human-readable leakage, but it demands more parsing and is not the default recommendation.

The policy name does not travel in the message. The receiver sees the consequences through HP-Outer. IANA's registry stores stable, implementable descriptions and says which policies are recommended. It does not certify that a client implements one, that a particular account selected it, or that a captured message followed it.

This is a useful separation of common and local authority. The common layer defines a small syntax, a testable decision function and registration rules. A client may later adopt a more ambitious policy when its environment can bear the deliverability and usability costs. Hiding To, Cc, References or In-Reply-To may reveal less to transit systems, but filters, threading, rendering and delivery can depend on visible fields. More privacy is not free merely because the registry can name it.

The hp parameter is intent, not outcome

RFC 9788 also defines an hp parameter on the protected Content-Type. cipher says the composer intended encrypted header protection; clear says the construction was signed-only. It is a provenance clue, not a substitute for examining the received envelope.

A signed-only message marked hp=cipher remains signed-only if no encryption layer exists. The recipient must not inflate confidentiality because the sender announced an intention. The reverse complication is equally instructive: an intermediary can wrap an originally signed-only message in encryption. The received object then contains an encryption layer that the original composer did not create.

If the observed envelope and the protected intent disagree, the absence of HP-Outer cannot prove that the composer hid every field. The receiver must treat the fields conservatively. RFC 9787's actual ordered layers answer what arrived; hp helps answer what the composer appears to have tried. Neither alone proves what every intermediary saw.

An audit record that stores only “encrypted=true” destroys this distinction. It should instead retain the MIME tree, layer types and order, hp, all HP-Outer records, actual outer fields, and the parser decision that produced the user-visible status.

One sender field, two authorities

The most difficult case is From. Modern systems often use transport-side mechanisms to evaluate the unprotected outer address, while an end-to-end signature may protect an inner address. Those checks operate at different boundaries.

RFC 9788 defines a mismatch when the address specification in the protected inner From differs from the actual outer From seen by the transport system. The existence of a protected value does not settle the dispute. The signature must also be valid and correctly bound to that inner address. A signature made with an unrelated credential protects bytes without proving the claimed mailbox identity.

When mismatch and missing valid binding occur together, the client should issue a phishing-grade warning and show both addresses. A client that relies on transport authentication should display the actual outer From as the cautious fallback, because that is the value the mail transport could assess.

Reply addressing follows a different rule. The client must populate recipients from protected fields only. Otherwise an on-path attacker could replace the outer sender of an encrypted message and wait for the recipient to disclose the conversation in a misdirected reply.

The apparent contradiction is sound engineering. Rendering asks which identity can be represented without creating a new spoofing channel. Reply composition asks which unprotected value an intermediary must not be allowed to control. One field on one screen can therefore require two evidence paths. A display name remains weaker still: RFC 9787 notes that human-readable names are not globally unique and may not be bound by the certificate check at all.

Privacy has more than one observer

Header encryption divides observers; it does not abolish them. An outer-pass-through field is visible to transport agents even if an encrypted copy is also present. A field removed outside becomes visible to every intended recipient after decryption. Recipient key identifiers can reveal likely correspondents. SMTP delivery reveals a destination to parts of the transport path. Received fields and mailbox ordering can expose timing. A User-Agent or patterned Message-ID can tell a recipient more than the composer intended.

Bcc is especially unforgiving. A client that includes a Bcc field in the encrypted payload for the wrong copy may reveal a hidden recipient to another intended recipient. No end-to-end cipher can conceal information from a recipient to whom the composer deliberately encrypted it.

Replies and forwards open another path. A decrypted subject, reference chain or quoted body can escape into a cleartext response unless the client carries forward an appropriate reference policy. Transit-added list fields should remain explicitly unprotected; placing them near an encrypted payload does not grant them end-to-end status.

The operational conclusion is narrower than “encrypted email is unsafe.” Header protection can materially improve integrity, authenticity and confidentiality. The correction is epistemic: each improvement needs its own receipt.

Sources

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — Running-code primacy
  10. Heng Lu — Minimum initial specification and localized future decision
  11. Heng Lu — Reality layers and symbolic power