Re: Feature suggestion. Indexing encrypted mail?
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Sun, 6 Apr 2014 22:16:50 +0000 (18:16 +2000)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 18:01:22 +0000 (10:01 -0800)
9e/86ce262bde73ba6bbbc4832395567b80e3a939 [new file with mode: 0644]

diff --git a/9e/86ce262bde73ba6bbbc4832395567b80e3a939 b/9e/86ce262bde73ba6bbbc4832395567b80e3a939
new file mode 100644 (file)
index 0000000..c1923f1
--- /dev/null
@@ -0,0 +1,152 @@
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id DB0A9431FB6\r
+       for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 15:17:06 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id csdNGIu9O2Wv for <notmuch@notmuchmail.org>;\r
+       Sun,  6 Apr 2014 15:17:01 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4BBC7431FBC\r
+       for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 15:17:01 -0700 (PDT)\r
+Received: from [10.21.2.224] (unknown [107.19.144.191])\r
+       by che.mayfirst.org (Postfix) with ESMTPSA id 8BC18F984;\r
+       Sun,  6 Apr 2014 18:16:55 -0400 (EDT)\r
+Message-ID: <5341D252.90405@fifthhorseman.net>\r
+Date: Sun, 06 Apr 2014 18:16:50 -0400\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+User-Agent: Mozilla/5.0 (X11; Linux x86_64;\r
+       rv:24.0) Gecko/20100101 Icedove/24.3.0\r
+MIME-Version: 1.0\r
+To: Guyzmo <guyzmo+notmuch@m0g.net>, \r
+       Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: Feature suggestion. Indexing encrypted mail?\r
+References: <86k3b3ybo6.fsf@someserver.somewhere>\r
+       <878urj1z3j.fsf@maritornes.cs.unb.ca>\r
+       <87txa7pp8z.fsf@servo.finestructure.net>\r
+       <20140406091516.GG26903@vilya.m0g.net>\r
+In-Reply-To: <20140406091516.GG26903@vilya.m0g.net>\r
+X-Enigmail-Version: 1.6+git0.20140323\r
+Content-Type: multipart/signed; micalg=pgp-sha512;\r
+       protocol="application/pgp-signature";\r
+       boundary="5isNjlwQfkr5DIQNGreml8XkOmff5dB08"\r
+Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor <dkg@debian.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 06 Apr 2014 22:17:07 -0000\r
+\r
+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)\r
+--5isNjlwQfkr5DIQNGreml8XkOmff5dB08\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On 04/06/2014 05:15 AM, Guyzmo wrote:\r
+>     I indeed agree with this view, and I think the best process would b=\r
+e\r
+> to have the MUA decrypt and index an encrypted mail when the  user want=\r
+s\r
+> it to be indexed. So the user do not get really  highly  secret message=\r
+s\r
+> disclosable by the index, and for the others take that kind of risk.\r
+\r
+At the moment, notmuch has a "no-modify" policy to the mail storage,\r
+with the exception of changing a few well-known flags on maildir names.\r
+\r
+I would be pretty sad to see that change, and i don't think that's a\r
+good idea for notmuch in general.  let's keep access to the mail store\r
+as read-only as possible.\r
+\r
+additionally, stripping encryption in some cases would mean stripping\r
+cryptographic signatures (e.g. most PGP/MIME encrypted messages are\r
+encrypted+signed, but the signature is a separate PGP part and not a\r
+MIME part) i think it would be bad to lose cryptographic signatures in\r
+this case.\r
+\r
+That said, i agree that there are some scenarios where having\r
+well-indexed mail storage even for the cleartext of encrypted messages\r
+would be useful and could even be done with some level of safety (e.g.\r
+where the index is itself stored on an encrypted filesystem -- notmuch\r
+has no explicit/builtin support for an encrypted index today).\r
+\r
+I think the most sensible way to approach this goal for notmuch would be\r
+a two-part series of generic notmuch enhancements, which could then be\r
+leveraged by those who need them into a cleartext index for those\r
+messages that they are willing to take a risk on.\r
+\r
+here are the notmuch enhancements:\r
+\r
+ * notmuch new id:$msgid\r
+\r
+This capability would allow notmuch to reindex a given message, clearing\r
+the entire index of any old references and adding new references to the\r
+current filter.\r
+\r
+ * notmuch new --filter=3D$foo\r
+\r
+The --filter option for notmuch new (or something similar) would  pass\r
+each message in question through a pipeline-style filter and operate on\r
+it the stdout of the filter, rather than the raw message.\r
+\r
+Given these two enhancements (some of which may be already underway, i\r
+confess i haven't been following closely), it wouldn't be much extra\r
+effort for someone to implement a filter that strips encryption from the\r
+message.  (this might still have the problem mentioned above about also\r
+stripping PGP/MIME signatures, but the signatures and the decrypted\r
+message itself would remain intact so they could be shown directly by\r
+notmuch show without trouble).\r
+\r
+once such a filter was in place, my personal preference would be that\r
+the messages would be imported as ciphertext initially, but then when an\r
+end-user-facing MUA gets the user to decrypt a message that has not been\r
+indexed with this filter, it could offer a button that says "index this\r
+message in cleartext (will leak contents to anyone who can read the index=\r
+)"\r
+\r
+       --dkg\r
+\r
+\r
+--5isNjlwQfkr5DIQNGreml8XkOmff5dB08\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+Content-Description: OpenPGP digital signature\r
+Content-Disposition: attachment; filename="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+Comment: Using GnuPG with Icedove - http://www.enigmail.net/\r
+\r
+iQJ8BAEBCgBmBQJTQdJVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB\r
+NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc250P/1PrZE8MPGVZxb/lLSr41tSZ\r
+OggjQZhMg3TGPcYkX9UWIOn9QBxfh4Q40Ds1DccrWZeWAnVnwq7biJni3/a1kdBK\r
+xuH5ZC32NqK/VnJftEjibq/oEI9+qozWK2BPea7qLCxD/heoQu1+15EKUpINy4ll\r
+5ohzCxQehYBPG37KlVE02A31MRoWz38XAAbtTT3ajzHC6CeVF75OsPZD2wRG9xM0\r
+5sfMnntzVvJvQnXW9Iuy/pEZyTpEubwyV2BbDKP8k6Z2sOu+h2AGQii2bimoaB+R\r
+eLUxBGDChoqr2/rEY3yuzCH10DHqdHd8qbRbHXACCLI0uIzqba561cADWC8dEYJa\r
+DQLATAYAY4X/4IAO7tYYHJ+uGgiSdxDi1NW0y3p4CHSO8Xt8NJnc+LmOeMkOKkA0\r
+la+0SxV7f4okf44f05/cO83wLf/RZU5TUH5fA9GKYCwP6O5Ho2cffSYuF54e0znD\r
+NRpqOiNSZ3qX8Eph0X9RUESqsV7qBPTrkwBUnry44kRf2jO+255k4mCacwOkd6wf\r
+JLIc9TUjQTc78fLt+U9B10bT+xFGAp9TJnXfi3DHTmCnPfDu3O71K/GYwQuKfSzb\r
+RGiEjjTeGZQeQZnbP5TPOZkikdpnaATo24GFCcsr36Tqrniqewh37ejNDTQaBeWG\r
+kBS8SuCPcWU33jp6fANi\r
+=gQuN\r
+-----END PGP SIGNATURE-----\r
+\r
+--5isNjlwQfkr5DIQNGreml8XkOmff5dB08--\r