Re: Feature suggestion. Indexing encrypted mail?

diff --git a/a1/49160395bd6b419f979f389a532bccd34e5d4f b/a1/49160395bd6b419f979f389a532bccd34e5d4f
new file mode 100644 (file)
index 0000000..b1af673
--- /dev/null
+++ b/a1/49160395bd6b419f979f389a532bccd34e5d4f
@@ -0,0 +1,104 @@
+Return-Path: <john.wyzer@gmx.de>\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 D165F431FC3\r
+       for <notmuch@notmuchmail.org>; Mon,  7 Apr 2014 01:09:00 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.001\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.001 tagged_above=-999 required=5\r
+       tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001]\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 135GDOtmBdpW for <notmuch@notmuchmail.org>;\r
+       Mon,  7 Apr 2014 01:08:53 -0700 (PDT)\r
+X-Greylist: delayed 133523 seconds by postgrey-1.32 at olra;\r
+       Mon, 07 Apr 2014 01:08:53 PDT\r
+Received: from mout.gmx.net (mout.gmx.net [212.227.17.22])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 3BB9B431FC2\r
+       for <notmuch@notmuchmail.org>; Mon,  7 Apr 2014 01:08:53 -0700 (PDT)\r
+Received: from localhost ([77.185.193.34]) by mail.gmx.com (mrgmx103) with\r
+       ESMTPSA (Nemesis) id 0LcSWg-1XFn642f8Y-00jrh1; Mon, 07 Apr 2014 10:08:50\r
+       +0200\r
+From: john.wyzer@gmx.de\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
+       Guyzmo <guyzmo+notmuch@m0g.net>,\r
+       Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: Feature suggestion. Indexing encrypted mail?\r
+In-Reply-To: <5341D252.90405@fifthhorseman.net>\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
+       <5341D252.90405@fifthhorseman.net>\r
+User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Mon, 07 Apr 2014 10:08:32 +0200\r
+Message-ID: <867g71y327.fsf@someserver.somewhere>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-Provags-ID: V03:K0:gtkLtBn/v64D09P+7QQ8FIjRnnwosPsQkUu8BlwiQfZ6N3AQVE5\r
+       8PtyNa8MlC9X33/4tLF18MFBR/yReiwtj96PDl1kQ7R484JRN2yyO+afGa0aRjIXmafk4/M\r
+       fYhLmXqW/bhd6owPHhugNsZrO0q9ZVTpO2VTn7Mf8WskUASn8betrxYQmBp83lTmPvlIuCp\r
+       RJXBeoi7hAZNdFYOM5YhQ==\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: Mon, 07 Apr 2014 08:09:01 -0000\r
+\r
+Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\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
+I would never have meant to suggest to change that. With decrypting\r
+"on-the-fly" I tried to suggest the decryption for the sake of indexing\r
+- but only during runtime and without changing the mail storage.\r
+\r
+>\r
+>  * notmuch new --filter=$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
+That idea sounds very nice to me and would make reindexing with other\r
+filters easy if needed.\r
+\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
+I don't understand that. :-(\r
+This sounds as if the view of the message is not generated from the\r
+mail storage. Isn't the purpose of the index to find the appropriate\r
+message file and everything else is generated from that file?\r
+\r