a1/49160395bd6b419f979f389a532bccd34e5d4f

   1 Return-Path: <john.wyzer@gmx.de>\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 D165F431FC3\r
   6         for <notmuch@notmuchmail.org>; Mon,  7 Apr 2014 01:09:00 -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.001\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.001 tagged_above=-999 required=5\r
  12         tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001]\r
  13         autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 135GDOtmBdpW for <notmuch@notmuchmail.org>;\r
  17         Mon,  7 Apr 2014 01:08:53 -0700 (PDT)\r
  18 X-Greylist: delayed 133523 seconds by postgrey-1.32 at olra;\r
  19         Mon, 07 Apr 2014 01:08:53 PDT\r
  20 Received: from mout.gmx.net (mout.gmx.net [212.227.17.22])\r
  21         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  22         (No client certificate requested)\r
  23         by olra.theworths.org (Postfix) with ESMTPS id 3BB9B431FC2\r
  24         for <notmuch@notmuchmail.org>; Mon,  7 Apr 2014 01:08:53 -0700 (PDT)\r
  25 Received: from localhost ([77.185.193.34]) by mail.gmx.com (mrgmx103) with\r
  26         ESMTPSA (Nemesis) id 0LcSWg-1XFn642f8Y-00jrh1; Mon, 07 Apr 2014 10:08:50\r
  27         +0200\r
  28 From: john.wyzer@gmx.de\r
  29 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
  30         Guyzmo <guyzmo+notmuch@m0g.net>,\r
  31         Jameson Graef Rollins <jrollins@finestructure.net>\r
  32 Subject: Re: Feature suggestion. Indexing encrypted mail?\r
  33 In-Reply-To: <5341D252.90405@fifthhorseman.net>\r
  34 References: <86k3b3ybo6.fsf@someserver.somewhere>\r
  35         <878urj1z3j.fsf@maritornes.cs.unb.ca>\r
  36         <87txa7pp8z.fsf@servo.finestructure.net>\r
  37         <20140406091516.GG26903@vilya.m0g.net>\r
  38         <5341D252.90405@fifthhorseman.net>\r
  39 User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1\r
  40         (x86_64-pc-linux-gnu)\r
  41 Date: Mon, 07 Apr 2014 10:08:32 +0200\r
  42 Message-ID: <867g71y327.fsf@someserver.somewhere>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain\r
  45 X-Provags-ID: V03:K0:gtkLtBn/v64D09P+7QQ8FIjRnnwosPsQkUu8BlwiQfZ6N3AQVE5\r
  46         8PtyNa8MlC9X33/4tLF18MFBR/yReiwtj96PDl1kQ7R484JRN2yyO+afGa0aRjIXmafk4/M\r
  47         fYhLmXqW/bhd6owPHhugNsZrO0q9ZVTpO2VTn7Mf8WskUASn8betrxYQmBp83lTmPvlIuCp\r
  48         RJXBeoi7hAZNdFYOM5YhQ==\r
  49 Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor <dkg@debian.org>\r
  50 X-BeenThere: notmuch@notmuchmail.org\r
  51 X-Mailman-Version: 2.1.13\r
  52 Precedence: list\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Mon, 07 Apr 2014 08:09:01 -0000\r
  63 \r
  64 Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  65 \r
  66 > At the moment, notmuch has a "no-modify" policy to the mail storage,\r
  67 > with the exception of changing a few well-known flags on maildir names.\r
  68 >\r
  69 > I would be pretty sad to see that change, and i don't think that's a\r
  70 > good idea for notmuch in general.  let's keep access to the mail store\r
  71 > as read-only as possible.\r
  72 >\r
  73 > additionally, stripping encryption in some cases would mean stripping\r
  74 > cryptographic signatures (e.g. most PGP/MIME encrypted messages are\r
  75 > encrypted+signed, but the signature is a separate PGP part and not a\r
  76 > MIME part) i think it would be bad to lose cryptographic signatures in\r
  77 > this case.\r
  78 \r
  79 I would never have meant to suggest to change that. With decrypting\r
  80 "on-the-fly" I tried to suggest the decryption for the sake of indexing\r
  81 - but only during runtime and without changing the mail storage.\r
  82 \r
  83 >\r
  84 >  * notmuch new --filter=$foo\r
  85 >\r
  86 > The --filter option for notmuch new (or something similar) would  pass\r
  87 > each message in question through a pipeline-style filter and operate on\r
  88 > it the stdout of the filter, rather than the raw message.\r
  89 \r
  90 That idea sounds very nice to me and would make reindexing with other\r
  91 filters easy if needed.\r
  92 \r
  93 > confess i haven't been following closely), it wouldn't be much extra\r
  94 > effort for someone to implement a filter that strips encryption from the\r
  95 > message.  (this might still have the problem mentioned above about also\r
  96 > stripping PGP/MIME signatures, but the signatures and the decrypted\r
  97 > message itself would remain intact so they could be shown directly by\r
  98 > notmuch show without trouble).\r
  99 \r
 100 I don't understand that. :-(\r
 101 This sounds as if the view of the message is not generated from the\r
 102 mail storage. Isn't the purpose of the index to find the appropriate\r
 103 message file and everything else is generated from that file?\r
 104 \r