1 Return-Path: <dme@dme.org>
\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 6136B431FAF
\r
6 for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:26 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 vUU9L34R3n0o for <notmuch@notmuchmail.org>;
\r
16 Thu, 26 Jan 2012 00:53:25 -0800 (PST)
\r
17 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
\r
18 [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id 8B11F431FAE
\r
21 for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:25 -0800 (PST)
\r
22 Received: by wibhi8 with SMTP id hi8so232020wib.26
\r
23 for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:24 -0800 (PST)
\r
24 Received: by 10.180.24.105 with SMTP id t9mr1823674wif.19.1327568004245;
\r
25 Thu, 26 Jan 2012 00:53:24 -0800 (PST)
\r
26 Received: from hotblack-desiato.hh.sledj.net
\r
27 (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])
\r
28 by mx.google.com with ESMTPS id d9sm4221152wiy.2.2012.01.26.00.53.22
\r
29 (version=TLSv1/SSLv3 cipher=OTHER);
\r
30 Thu, 26 Jan 2012 00:53:22 -0800 (PST)
\r
31 Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)
\r
32 id EF3769FD9F; Thu, 26 Jan 2012 08:53:20 +0000 (GMT)
\r
33 To: Jameson Graef Rollins <jrollins@finestructure.net>,
\r
34 Notmuch Mail <notmuch@notmuchmail.org>
\r
35 Subject: Re: Emacs: Crypto: How to get automatic encryption?
\r
36 In-Reply-To: <878vkv7k2q.fsf@servo.finestructure.net>
\r
37 References: <87pqejj5nl.fsf@marcos.anarcat.ath.cx>
\r
38 <cunfwfer8i0.fsf@hotblack-desiato.hh.sledj.net>
\r
39 <87ehuo7pjr.fsf@algae.riseup.net>
\r
40 <87ehuoljzs.fsf@servo.finestructure.net>
\r
41 <cunvco0nvwa.fsf@hotblack-desiato.hh.sledj.net>
\r
42 <87liow6slg.fsf@servo.finestructure.net>
\r
43 <cund3a8nkwl.fsf@hotblack-desiato.hh.sledj.net>
\r
44 <878vkv7k2q.fsf@servo.finestructure.net>
\r
45 User-Agent: Notmuch/0.11+114~g550724b (http://notmuchmail.org) Emacs/24.0.92.1
\r
46 (x86_64-pc-linux-gnu)
\r
47 From: David Edmondson <dme@dme.org>
\r
48 Date: Thu, 26 Jan 2012 08:53:20 +0000
\r
49 Message-ID: <cunk44elu9r.fsf@hotblack-desiato.hh.sledj.net>
\r
51 Content-Type: multipart/signed; boundary="=-=-=";
\r
52 micalg=pgp-sha1; protocol="application/pgp-signature"
\r
53 X-BeenThere: notmuch@notmuchmail.org
\r
54 X-Mailman-Version: 2.1.13
\r
56 List-Id: "Use and development of the notmuch mail system."
\r
57 <notmuch.notmuchmail.org>
\r
58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
59 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
61 List-Post: <mailto:notmuch@notmuchmail.org>
\r
62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
64 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
65 X-List-Received-Date: Thu, 26 Jan 2012 08:53:26 -0000
\r
68 Content-Type: text/plain
\r
69 Content-Transfer-Encoding: quoted-printable
\r
71 On Wed, 25 Jan 2012 09:45:01 -0800, Jameson Graef Rollins <jrollins@finestr=
\r
73 > On Wed, 25 Jan 2012 10:20:26 +0000, David Edmondson <dme@dme.org> wrote:
\r
74 > > Isn't it still necessary to ensure that you have encryption keys
\r
75 > > appropriate to the recipient?
\r
77 > I want to ensure that all replies to encrypted to be encrypted. I
\r
78 > would rather have the reply fail outright than fall back to
\r
81 That's a policy decision that a user can (and perhaps should) take, but
\r
82 not something that should be enforced by the tool. Encouraging this
\r
83 approach is fine, of course. I can think of various situations where I
\r
84 might send an un-encrypted reply to an encrypted message.
\r
86 > Here's a behavior that I think would be reasonable:
\r
88 > * notmuch reply outputs JSON encrypted flag
\r
90 > * emacs does a quick check to see if the needed key is available
\r
92 > * if key not available: give a nice mini-buffer prompt, something like:
\r
94 > 'encryption key for "Foo Bar <foo@bar.com>" not found. Retrieve?'
\r
96 > * if response is yes: call gpg to retrieve the key
\r
98 > * if key available: add encrypt flag
\r
100 > else: I feel like this should abort, but maybe there's something to
\r
101 > be done here. Allow reply but don't quote the original?
\r
104 - notmuch reply outputs JSON encrypted flag,
\r
105 - emacs inserts the relevant mml to request that the reply is sent
\r
106 encrypted if the flag is present.
\r
108 With this approach the default behaviour is to send an encrypted reply
\r
109 to an encrypted message, but the user has the chance to change the
\r
110 behaviour using familiar (well, as familiar as mml can be) tools.
\r
112 Adding improvements to retrieve keys for outgoing messages would be
\r
113 generally useful - it's not just an issue for replies.
\r
116 Content-Type: application/pgp-signature
\r
118 -----BEGIN PGP SIGNATURE-----
\r
119 Version: GnuPG v1.4.11 (GNU/Linux)
\r
121 iEYEARECAAYFAk8hFIAACgkQaezQq/BJZRYmVwCfTcVgXyz+yXySlEZphtOXaxfy
\r
122 vbgAn3LrogNQVa8HEtsFAOjN+oDtnBiU
\r
124 -----END PGP SIGNATURE-----
\r
projects / notmuch-archives.git / blob