Skip to content
Protected E-mail Headers
Python Ruby Shell Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
guidance initial guidance Jul 16, 2015

Memory Hole Protected E-mail Headers

Encrypted or signed e-mail does not have cryptographic protection of headers -- only the body of an e-mail message is encrypted or signed.

The Memory Hole project aims to fix this problem by stashing relevant headers within the body of the e-mail in a standardized way. Compatible mail user agents should be able to use this structure to display the cryptographically protected headers to the user, indicating their protection.

Messages composed using either PGP/MIME or S/MIME should be able to use Memory Hole to add cryptographic protection for mail headers.

Memory Hole works by copying the normal message headers into the MIME part headers. Since the MIME part headers are themselves covered by the protection mechanisms (signing or encryption) they share the protections of the message body.

Things in this repository

corpus/ -- A collection of of e-mail messages that follow the Memory Hole standard. Mail user agents interested in supporting this technique can use this corpus as a test vector to verify their implementations.

generators/ -- scripts to generate e-mails in the corpus. Each email in the corpus is generated by a single script in this directory.

inboxes/ -- Contains email inboxes in different formats, so that you can view the emails in the corpus directory using various Mail User Agents. This directory is generated when running make.

specs/ -- A draft standard of how to structure and interpret these messages.

guidance/ -- Documentation of guidance for implementors, including UI/UX, deployment, and configuration considerations

screenshots/ -- Screenshots of mail user agents rendering the corpus

history/ -- Documents showing early development and documentation of the project.

Alternatives Considered

Wrap the whole message as an message/rfc822 sub-part

This is how S/MIME specifies protected headers should be done. Unfortunately, this is also how forwarded mail is represented, and most MUAs present it as such (see Alexey Melnikov's proposed draft for an improvement over this strategy).

Only use embedded text/rfc822-headers parts

This was the original memoryhole approach. It has a few downsides compared with the current MIME part header block approach:

  • introduces an additional change in the MIME structure of the message being protected

  • for non-memoryhole-aware MUAs, it produces an extra attachment that the user is exposed to. MUAs that render signatures as attachment objects already confuse recipients, and this would make that confusion worse.

  • embedded headers protected by encryption that we want to be visible to the recipient present an extra challenge -- we need an additional embedded header part with different Content-Disposition: to make that work.

Embedded headers associated by tagging instead of structure

The current memoryhole proposal identifies the headers by virtue of their placement within the MIME structure of the message. An alternate approach is to try to associate the headers with the message based on tagging (e.g. by Message-ID) or by some sort of shared identifiers.

This approach is risky because it makes interpretation of the protected material dependent on unprotected context.


  • pyMemoryHole. A generic python library under development.
  • enigmail has integrated support for Memory Hole but it's not enabled by default.
  • r2mail2 Memory Hole implementation is mostly finished.
  • notmuch Memory Hole for parsing is under development, notmuch doesn't generate emails.
  • bitmask Memory Hole implementation is under development using pyMemoryHole.
  • gpg4o has an implementation of the early draft of memory hole.
  • mailpile has some experiments using memoryhole.


You can’t perform that action at this time.