Traditionally, encrypted and signed e-mail covers only the body of the message. New standards are emerging that are capable of protecting the headers as well. In particular, Enigmail and an upcoming version of K-9 mail both use the "Memory Hole" approach to encrypt the Subject: header when sending encrypted mail. It is awkward to receive encrypted messages from those clients with notmuch, because all notmuch sees is "Subject: Encrypted Message"
This series solves that problem specifically: it enables viewing (and indexing and searching, if desired) of the cleartext of the encrypted Subject:. It also lays sensible groundwork for handling other protected headers in the future. For a discussion of protected headers and the various challenges and opportunities they present, see my writeup here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html What this series does *not* do (yet) is emit any protected headers from notmuch itself. I think the series can be applied without that, because just consuming the protected headers and being able to work with them is a win on its own terms. The series is also careful not to accidentally leak cleartext headers (e.g. in reply), so it should be safe to adopt even if we don't immediately become capable of emitting protected headers. If we can land this series, i think the next steps along this direction include: * emitting a protected Subject: line when sending mail via notmuch-emacs * restructuring messages that had protected headers so that any weird internal structure isn't clumsily visible (either the "force-display" part of a Memory Hole-structured message, or the wrapped message/rfc822 part encouraged by Melnikov's draft could be "skipped") * dealing with other protected headers _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch