Re: Feature suggestion. Indexing encrypted mail?

[john . wyzer]

Daniel Kahn Gillmor d...@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?

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Feature suggestion. Indexing encrypted mail?

[john . wyzer]

Jeremy Nickurak not-m...@trk.nickurak.ca writes:

 Off the top of my head, you could have an encrypted index too, which you
 can only search while able to decrypt. Certainly another level of
 complexity.


But why add so much complexity? 

If a user decides that either transport security is enough or
additionally the hard disk is encrypted (why store an encrypted index on
an encrypted hard disk?), said user could just switch on an option in
the notmuch configuration that causes notmuch to ask for the password
before or while indexing new messages and to add decrypted messages to the
normal index as well.


The level of security would be up to the user by means of said
configuration option and those that want the convenience of searching
encrypted messages could have it.

Personally I would argue that if an attacker has the means to access the
content of my hard disk either via the network or physically, there is
no difference between having whole disk encryption and storing an
encrypted index...

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch