Mail header encryption (was Re: It's time for PGP to die.)

Peter Lebbing peter at
Sun Aug 17 11:41:15 CEST 2014

On 17/08/14 03:05, Garreau, Alexandre wrote:
> Well, afaik, there’s *no* MIME header which is required for delivery

However, in practice, MTA's, and specific configurations of MTA's, might depend
on headers in the mail:

- Spam filtering setups. Enough said.

- Microsoft Exchange[1] is not an RFC2822-based messaging system. When
interfacing through SMTP, POP3 or IMAP, messages are converted to and from X.400.

And then there is the problem of RFC 6409, Message Submission for Mail, which
specifies that the SMTP server receiving the message from the user (in other
terms, the MSA receiving the message from the MUA) /is/ allowed to alter the
message. I see a very nice example in the RFC which could be a problem with your

> 8.1. Add 'Sender'
> The MSA MAY add or replace the 'Sender' field, if the identity of the sender
> is known and this is not given in the 'From' field.
> The MSA MUST ensure that any address it places in a 'Sender' field is, in
> fact, a valid mail address.

And as a very specific example, I can't get my Exim server to interface to
Spamassassin without acting as an MSA to Spamassassin. This means it will
invariably add missing 'Date' and 'Message-ID' headers to any mail delivered to
me. This would not be a problem for what you're proposing; I'm just pointing out
that in practice, some unexpected issues might crop up.

> (maybe RFC says there is, but currently mail servers accepts mails with no
> headers at all)

The ones acting as MSA's will usually add them, though.

> Then things like the subject, the date, the message-id, the list of attached
> things, etc. would be protected.

The date is usually the same as the moment it is passing through the internet. A
monitoring adversary doesn't learn anything worthwhile.

The Message-ID by itself doesn't seem interesting to me. However, when combined
with the In-Reply-To and References headers, it can be very interesting.

> That makes less metadata, but it still leaks the more important: recipient
> and receiver.

Yes, it only solves minor issues but leaves the major one untouched.


[1] I'm unsure if there are versions that are pure RFC2822. AFAIK, all Exchange
servers are prone to mangling your message, whether that's caused by X.400
conversions or not. Of course, Microsoft often knows better than RFC's, and
treats "MUST NOT" as purely optional.

I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

More information about the Gnupg-users mailing list