From 488bb065b4fb3cd7b8305f85451fec169f6b17c4 Mon Sep 17 00:00:00 2001 From: "john.wyzer" Date: Mon, 7 Apr 2014 10:08:32 +0200 Subject: [PATCH] Re: Feature suggestion. Indexing encrypted mail? --- a1/49160395bd6b419f979f389a532bccd34e5d4f | 104 ++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 a1/49160395bd6b419f979f389a532bccd34e5d4f diff --git a/a1/49160395bd6b419f979f389a532bccd34e5d4f b/a1/49160395bd6b419f979f389a532bccd34e5d4f new file mode 100644 index 000000000..b1af67376 --- /dev/null +++ b/a1/49160395bd6b419f979f389a532bccd34e5d4f @@ -0,0 +1,104 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id D165F431FC3 + for ; Mon, 7 Apr 2014 01:09:00 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.001 +X-Spam-Level: +X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 + tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 135GDOtmBdpW for ; + Mon, 7 Apr 2014 01:08:53 -0700 (PDT) +X-Greylist: delayed 133523 seconds by postgrey-1.32 at olra; + Mon, 07 Apr 2014 01:08:53 PDT +Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 3BB9B431FC2 + for ; Mon, 7 Apr 2014 01:08:53 -0700 (PDT) +Received: from localhost ([77.185.193.34]) by mail.gmx.com (mrgmx103) with + ESMTPSA (Nemesis) id 0LcSWg-1XFn642f8Y-00jrh1; Mon, 07 Apr 2014 10:08:50 + +0200 +From: john.wyzer@gmx.de +To: Daniel Kahn Gillmor , + Guyzmo , + Jameson Graef Rollins +Subject: Re: Feature suggestion. Indexing encrypted mail? +In-Reply-To: <5341D252.90405@fifthhorseman.net> +References: <86k3b3ybo6.fsf@someserver.somewhere> + <878urj1z3j.fsf@maritornes.cs.unb.ca> + <87txa7pp8z.fsf@servo.finestructure.net> + <20140406091516.GG26903@vilya.m0g.net> + <5341D252.90405@fifthhorseman.net> +User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Mon, 07 Apr 2014 10:08:32 +0200 +Message-ID: <867g71y327.fsf@someserver.somewhere> +MIME-Version: 1.0 +Content-Type: text/plain +X-Provags-ID: V03:K0:gtkLtBn/v64D09P+7QQ8FIjRnnwosPsQkUu8BlwiQfZ6N3AQVE5 + 8PtyNa8MlC9X33/4tLF18MFBR/yReiwtj96PDl1kQ7R484JRN2yyO+afGa0aRjIXmafk4/M + fYhLmXqW/bhd6owPHhugNsZrO0q9ZVTpO2VTn7Mf8WskUASn8betrxYQmBp83lTmPvlIuCp + RJXBeoi7hAZNdFYOM5YhQ== +Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 07 Apr 2014 08:09:01 -0000 + +Daniel Kahn Gillmor 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? + -- 2.26.2