Re: Feature suggestion. Indexing encrypted mail?

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]

On 04/06/2014 05:15 AM, Guyzmo wrote:
>     I indeed agree with this view, and I think the best process would be
> to have the MUA decrypt and index an encrypted mail when the  user wants
> it to be indexed. So the user do not get really  highly  secret messages
> disclosable by the index, and for the others take that kind of risk.

At the moment, notmuch has a "no-modify" policy to the mail storage,
with the exception of changing a few well-known flags on maildir names.

I would be pretty sad to see that change, and i don't think that's a
good idea for notmuch in general.  let's keep access to the mail store
as read-only as possible.

additionally, stripping encryption in some cases would mean stripping
cryptographic signatures (e.g. most PGP/MIME encrypted messages are
encrypted+signed, but the signature is a separate PGP part and not a
MIME part) i think it would be bad to lose cryptographic signatures in
this case.

That said, i agree that there are some scenarios where having
well-indexed mail storage even for the cleartext of encrypted messages
would be useful and could even be done with some level of safety (e.g.
where the index is itself stored on an encrypted filesystem -- notmuch
has no explicit/builtin support for an encrypted index today).

I think the most sensible way to approach this goal for notmuch would be
a two-part series of generic notmuch enhancements, which could then be
leveraged by those who need them into a cleartext index for those
messages that they are willing to take a risk on.

here are the notmuch enhancements:

 * notmuch new id:$msgid

This capability would allow notmuch to reindex a given message, clearing
the entire index of any old references and adding new references to the
current filter.

 * notmuch new --filter=$foo

The --filter option for notmuch new (or something similar) would  pass
each message in question through a pipeline-style filter and operate on
it the stdout of the filter, rather than the raw message.

Given these two enhancements (some of which may be already underway, i
confess i haven't been following closely), it wouldn't be much extra
effort for someone to implement a filter that strips encryption from the
message.  (this might still have the problem mentioned above about also
stripping PGP/MIME signatures, but the signatures and the decrypted
message itself would remain intact so they could be shown directly by
notmuch show without trouble).

once such a filter was in place, my personal preference would be that
the messages would be imported as ciphertext initially, but then when an
end-user-facing MUA gets the user to decrypt a message that has not been
indexed with this filter, it could offer a button that says "index this
message in cleartext (will leak contents to anyone who can read the index)"

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1010 bytes --]