9e/86ce262bde73ba6bbbc4832395567b80e3a939

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id DB0A9431FB6\r
   6         for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 15:17:06 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id csdNGIu9O2Wv for <notmuch@notmuchmail.org>;\r
  16         Sun,  6 Apr 2014 15:17:01 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 4BBC7431FBC\r
  19         for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 15:17:01 -0700 (PDT)\r
  20 Received: from [10.21.2.224] (unknown [107.19.144.191])\r
  21         by che.mayfirst.org (Postfix) with ESMTPSA id 8BC18F984;\r
  22         Sun,  6 Apr 2014 18:16:55 -0400 (EDT)\r
  23 Message-ID: <5341D252.90405@fifthhorseman.net>\r
  24 Date: Sun, 06 Apr 2014 18:16:50 -0400\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 User-Agent: Mozilla/5.0 (X11; Linux x86_64;\r
  27         rv:24.0) Gecko/20100101 Icedove/24.3.0\r
  28 MIME-Version: 1.0\r
  29 To: Guyzmo <guyzmo+notmuch@m0g.net>, \r
  30         Jameson Graef Rollins <jrollins@finestructure.net>\r
  31 Subject: Re: Feature suggestion. Indexing encrypted mail?\r
  32 References: <86k3b3ybo6.fsf@someserver.somewhere>\r
  33         <878urj1z3j.fsf@maritornes.cs.unb.ca>\r
  34         <87txa7pp8z.fsf@servo.finestructure.net>\r
  35         <20140406091516.GG26903@vilya.m0g.net>\r
  36 In-Reply-To: <20140406091516.GG26903@vilya.m0g.net>\r
  37 X-Enigmail-Version: 1.6+git0.20140323\r
  38 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  39         protocol="application/pgp-signature";\r
  40         boundary="5isNjlwQfkr5DIQNGreml8XkOmff5dB08"\r
  41 Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor <dkg@debian.org>\r
  42 X-BeenThere: notmuch@notmuchmail.org\r
  43 X-Mailman-Version: 2.1.13\r
  44 Precedence: list\r
  45 List-Id: "Use and development of the notmuch mail system."\r
  46         <notmuch.notmuchmail.org>\r
  47 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  49 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  50 List-Post: <mailto:notmuch@notmuchmail.org>\r
  51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  52 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  54 X-List-Received-Date: Sun, 06 Apr 2014 22:17:07 -0000\r
  55 \r
  56 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)\r
  57 --5isNjlwQfkr5DIQNGreml8XkOmff5dB08\r
  58 Content-Type: text/plain; charset=UTF-8\r
  59 Content-Transfer-Encoding: quoted-printable\r
  60 \r
  61 On 04/06/2014 05:15 AM, Guyzmo wrote:\r
  62 >     I indeed agree with this view, and I think the best process would b=\r
  63 e\r
  64 > to have the MUA decrypt and index an encrypted mail when the  user want=\r
  65 s\r
  66 > it to be indexed. So the user do not get really  highly  secret message=\r
  67 s\r
  68 > disclosable by the index, and for the others take that kind of risk.\r
  69 \r
  70 At the moment, notmuch has a "no-modify" policy to the mail storage,\r
  71 with the exception of changing a few well-known flags on maildir names.\r
  72 \r
  73 I would be pretty sad to see that change, and i don't think that's a\r
  74 good idea for notmuch in general.  let's keep access to the mail store\r
  75 as read-only as possible.\r
  76 \r
  77 additionally, stripping encryption in some cases would mean stripping\r
  78 cryptographic signatures (e.g. most PGP/MIME encrypted messages are\r
  79 encrypted+signed, but the signature is a separate PGP part and not a\r
  80 MIME part) i think it would be bad to lose cryptographic signatures in\r
  81 this case.\r
  82 \r
  83 That said, i agree that there are some scenarios where having\r
  84 well-indexed mail storage even for the cleartext of encrypted messages\r
  85 would be useful and could even be done with some level of safety (e.g.\r
  86 where the index is itself stored on an encrypted filesystem -- notmuch\r
  87 has no explicit/builtin support for an encrypted index today).\r
  88 \r
  89 I think the most sensible way to approach this goal for notmuch would be\r
  90 a two-part series of generic notmuch enhancements, which could then be\r
  91 leveraged by those who need them into a cleartext index for those\r
  92 messages that they are willing to take a risk on.\r
  93 \r
  94 here are the notmuch enhancements:\r
  95 \r
  96  * notmuch new id:$msgid\r
  97 \r
  98 This capability would allow notmuch to reindex a given message, clearing\r
  99 the entire index of any old references and adding new references to the\r
 100 current filter.\r
 101 \r
 102  * notmuch new --filter=3D$foo\r
 103 \r
 104 The --filter option for notmuch new (or something similar) would  pass\r
 105 each message in question through a pipeline-style filter and operate on\r
 106 it the stdout of the filter, rather than the raw message.\r
 107 \r
 108 Given these two enhancements (some of which may be already underway, i\r
 109 confess i haven't been following closely), it wouldn't be much extra\r
 110 effort for someone to implement a filter that strips encryption from the\r
 111 message.  (this might still have the problem mentioned above about also\r
 112 stripping PGP/MIME signatures, but the signatures and the decrypted\r
 113 message itself would remain intact so they could be shown directly by\r
 114 notmuch show without trouble).\r
 115 \r
 116 once such a filter was in place, my personal preference would be that\r
 117 the messages would be imported as ciphertext initially, but then when an\r
 118 end-user-facing MUA gets the user to decrypt a message that has not been\r
 119 indexed with this filter, it could offer a button that says "index this\r
 120 message in cleartext (will leak contents to anyone who can read the index=\r
 121 )"\r
 122 \r
 123         --dkg\r
 124 \r
 125 \r
 126 --5isNjlwQfkr5DIQNGreml8XkOmff5dB08\r
 127 Content-Type: application/pgp-signature; name="signature.asc"\r
 128 Content-Description: OpenPGP digital signature\r
 129 Content-Disposition: attachment; filename="signature.asc"\r
 130 \r
 131 -----BEGIN PGP SIGNATURE-----\r
 132 Version: GnuPG v1\r
 133 Comment: Using GnuPG with Icedove - http://www.enigmail.net/\r
 134 \r
 135 iQJ8BAEBCgBmBQJTQdJVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 136 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB\r
 137 NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc250P/1PrZE8MPGVZxb/lLSr41tSZ\r
 138 OggjQZhMg3TGPcYkX9UWIOn9QBxfh4Q40Ds1DccrWZeWAnVnwq7biJni3/a1kdBK\r
 139 xuH5ZC32NqK/VnJftEjibq/oEI9+qozWK2BPea7qLCxD/heoQu1+15EKUpINy4ll\r
 140 5ohzCxQehYBPG37KlVE02A31MRoWz38XAAbtTT3ajzHC6CeVF75OsPZD2wRG9xM0\r
 141 5sfMnntzVvJvQnXW9Iuy/pEZyTpEubwyV2BbDKP8k6Z2sOu+h2AGQii2bimoaB+R\r
 142 eLUxBGDChoqr2/rEY3yuzCH10DHqdHd8qbRbHXACCLI0uIzqba561cADWC8dEYJa\r
 143 DQLATAYAY4X/4IAO7tYYHJ+uGgiSdxDi1NW0y3p4CHSO8Xt8NJnc+LmOeMkOKkA0\r
 144 la+0SxV7f4okf44f05/cO83wLf/RZU5TUH5fA9GKYCwP6O5Ho2cffSYuF54e0znD\r
 145 NRpqOiNSZ3qX8Eph0X9RUESqsV7qBPTrkwBUnry44kRf2jO+255k4mCacwOkd6wf\r
 146 JLIc9TUjQTc78fLt+U9B10bT+xFGAp9TJnXfi3DHTmCnPfDu3O71K/GYwQuKfSzb\r
 147 RGiEjjTeGZQeQZnbP5TPOZkikdpnaATo24GFCcsr36Tqrniqewh37ejNDTQaBeWG\r
 148 kBS8SuCPcWU33jp6fANi\r
 149 =gQuN\r
 150 -----END PGP SIGNATURE-----\r
 151 \r
 152 --5isNjlwQfkr5DIQNGreml8XkOmff5dB08--\r