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.
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.
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.
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).
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.
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.