This repository is an archive of the memory hole protected e-mail headers effort. It has been inactive for a few years.
The most recent effort in this field is documented here: https://github.com/autocrypt/protected-headers It tracks the Internet Draft documenting shared experience in providing end-to-end cryptographic protection for e-mail headers.
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
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
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
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.
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
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
MIMEstructure 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
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.