Header Protection: Why Your Encrypted Email Still Has a Readable Subject

An email is two things stacked on top of each other. There is a set of header fields, one per line, that mail servers read to route and file the message. Below them, after a blank line, there is the body. When you encrypt an email with PGP/MIME or S/MIME, the encryption applies to the body. The headers stay where they are, because the servers that move the message need to read some of them.

That is defensible for To and From, which the delivery path genuinely requires. It is much harder to defend for Subject, which no server needs and which routinely carries the most sensitive summary of the message. "Biopsy results," "layoff list," "wire instructions for closing," "source wants to meet." A Subject line is a summary written by a person who assumed it would be private.

What the encryption boundary actually covers

In PGP/MIME, defined in RFC 3156, the sender builds a MIME structure, encrypts it, and attaches the result as an octet stream to an outer message. That outer message carries the headers. The recipient's client decrypts the attachment and renders what is inside. If the sender's client puts nothing but the body inside the encrypted part, then the Subject exists in exactly one place: outside.

S/MIME, standardised in RFC 8551, works the same way structurally. A CMS EnvelopedData or SignedData object is carried inside a normal message, and that normal message needs a normal header block to be delivered.

So an intermediate server, a mailbox provider, an archiving appliance, or anyone who obtains the mail spool later gets this much without touching the ciphertext:

Field	Visible without decrypting?
Message body and attachments	No
Subject	Yes, by default
From, To, Cc	Yes
Date and Message-ID	Yes
In-Reply-To and References	Yes, which reconstructs the thread
Received chain	Yes, hop by hop
Attachment count and approximate sizes	Inferable from the message size

The threading headers deserve more attention than they get. In a long exchange, In-Reply-To and References let an observer rebuild the entire conversation graph, including who joined which branch and when, from messages whose contents they never read. That is metadata, and it is durable in a way the contents are not.

The memory hole and what came after

The idea that fixed the Subject is straightforward. Put a second, complete copy of the header fields inside the encrypted part, and let the receiving client prefer that copy when it renders the message. The outer headers keep whatever the delivery path needs, and the real Subject travels under the encryption with the body.

This was proposed around 2014 under the name "memory hole," and implemented by marking the inner MIME part with a protected-headers parameter so that a client could tell an intentional protected copy from a stray header block. It reached users first through the mail clients with the most active encryption communities, and later through the Autocrypt effort, which specified encrypted Subject lines as part of its interoperability profile.

The IETF LAMPS working group has since been standardising the general form, covering both S/MIME and PGP/MIME in one document rather than letting the two ecosystems diverge again. The mechanism it settles on is a wrapper: the protected message, with its own full header block, is carried as an inner message inside the cryptographic envelope, and the outer header block presents a reduced set with a placeholder where the Subject would be.

Why it took so long: the legacy display problem

A client that does not implement header protection will show the recipient the outer Subject, which is now a placeholder. The user sees an encrypted message with an apparently blank or meaningless subject, decrypts it, and reads a body with no title. Worse, when they reply, their client quotes the body and writes a new Subject from the placeholder, which then propagates.

Early designs addressed this by prepending a visible line to the encrypted body text, so that older clients would at least display the real Subject somewhere. That fix has an ugly consequence: the injected line is body content. It gets quoted on reply, it appears in the middle of exchanges after the ecosystem has moved on, and there is no clean way for a modern client to remove it without guessing about content the user might have written. Later revisions of the specification stepped back from it for exactly this reason.

The general shape of the problem is familiar to anyone who has shipped a format change. Both endpoints have to agree, the sender cannot detect the receiver's capability in advance, and the degraded mode is visible to a non-technical user who did not ask to be part of a transition. A decade of slow adoption is what that costs.

Signatures, and the attack header protection also closes

Encryption is the obvious motivation, and it is not the only one. When a message is signed but the Subject is outside the signature, the Subject can be changed in transit and the signature still verifies. The client shows a green check mark next to a message whose title now says something the sender never wrote.

A valid signature over a body, displayed next to an unsigned Subject, is an interface that reports more assurance than the cryptography delivers.

Academic work on mail client behaviour through the late 2010s found a broad set of user-interface confusions in this family across many clients, where the indicator shown to the user did not correspond to what had actually been verified. Header protection removes one whole category of those, because a signed inner message covers the fields the user is reading.

Note that this is a different question from SPF, DKIM and DMARC. DKIM does sign the Subject, and that signature is checked at the receiving server. It is a claim by the sending domain about a message it handled, not a claim by the person who wrote it, and it is verified at the boundary rather than end to end. The two mechanisms answer different questions and neither substitutes for the other.

What header protection still does not hide

Being precise about this matters more than the feature itself.

• The envelope. SMTP delivery uses MAIL FROM and RCPT TO commands that are separate from the message headers. Those are how the message actually gets routed and they are never encrypted by anything in the message body.
• The correspondents. The outer From and To remain, because delivery depends on them. Who talks to whom, and how often, survives header protection intact.
• Timing and volume. Message counts, sizes and times form a pattern that is frequently more revealing than any single subject line.
• Anything your provider indexes. A mailbox provider that stores your mail can build a search index over whatever it can read. Protecting the Subject removes one field from that index, and the correspondent graph stays.

Messaging protocols have taken different runs at the correspondent problem. Sealed sender hides the sender from the delivery service, and mix networks break the link between sender and recipient at the network layer. Email has no equivalent in wide deployment, and the honest summary is that email protects contents well and correspondents poorly.

Checking your own mail

You can determine your client's behaviour in about a minute. Send yourself an encrypted message with a distinctive Subject, then view the raw source of the message as it arrived. Our guide to reading email headers covers where that option lives in the common clients. If the outer Subject: line contains your text, the Subject travelled in the clear. If it contains a placeholder and the real one appears after decryption, your client is protecting it.

If it is not protected, the practical workaround needs no software at all: write subject lines that route the message without describing it. "Following up" is not a worse subject than "Following up on the deposition transcript" for any purpose except your own search, and only one of them is readable by everyone between you and the recipient.

Haven encrypts email with PGP/MIME, and the specifics of what a given format leaves outside the envelope are the kind of thing we would rather write down than leave to an assumption. A privacy claim that a user cannot check is not one they should have to take on faith.