Skip to content
This repository has been archived by the owner on Feb 7, 2020. It is now read-only.

autocrypt/memoryhole

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

88 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Archived Content

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

Implementations

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

Workshops