Feature suggestion. Indexing encrypted mail?
john.wyzer at gmx.de
john.wyzer at gmx.de
Mon Apr 7 01:08:32 PDT 2014
Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> 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.
I would never have meant to suggest to change that. With decrypting
"on-the-fly" I tried to suggest the decryption for the sake of indexing
- but only during runtime and without changing the mail storage.
>
> * 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.
That idea sounds very nice to me and would make reindexing with other
filters easy if needed.
> 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).
I don't understand that. :-(
This sounds as if the view of the message is not generated from the
mail storage. Isn't the purpose of the index to find the appropriate
message file and everything else is generated from that file?
More information about the notmuch
mailing list