--- /dev/null
+Return-Path: <dme@dme.org>\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 6136B431FAF\r
+ for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:26 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 vUU9L34R3n0o for <notmuch@notmuchmail.org>;\r
+ Thu, 26 Jan 2012 00:53:25 -0800 (PST)\r
+Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com\r
+ [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 8B11F431FAE\r
+ for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:25 -0800 (PST)\r
+Received: by wibhi8 with SMTP id hi8so232020wib.26\r
+ for <notmuch@notmuchmail.org>; Thu, 26 Jan 2012 00:53:24 -0800 (PST)\r
+Received: by 10.180.24.105 with SMTP id t9mr1823674wif.19.1327568004245;\r
+ Thu, 26 Jan 2012 00:53:24 -0800 (PST)\r
+Received: from hotblack-desiato.hh.sledj.net\r
+ (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])\r
+ by mx.google.com with ESMTPS id d9sm4221152wiy.2.2012.01.26.00.53.22\r
+ (version=TLSv1/SSLv3 cipher=OTHER);\r
+ Thu, 26 Jan 2012 00:53:22 -0800 (PST)\r
+Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)\r
+ id EF3769FD9F; Thu, 26 Jan 2012 08:53:20 +0000 (GMT)\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
+ Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: Re: Emacs: Crypto: How to get automatic encryption?\r
+In-Reply-To: <878vkv7k2q.fsf@servo.finestructure.net>\r
+References: <87pqejj5nl.fsf@marcos.anarcat.ath.cx>\r
+ <cunfwfer8i0.fsf@hotblack-desiato.hh.sledj.net>\r
+ <87ehuo7pjr.fsf@algae.riseup.net>\r
+ <87ehuoljzs.fsf@servo.finestructure.net>\r
+ <cunvco0nvwa.fsf@hotblack-desiato.hh.sledj.net>\r
+ <87liow6slg.fsf@servo.finestructure.net>\r
+ <cund3a8nkwl.fsf@hotblack-desiato.hh.sledj.net>\r
+ <878vkv7k2q.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.11+114~g550724b (http://notmuchmail.org) Emacs/24.0.92.1\r
+ (x86_64-pc-linux-gnu)\r
+From: David Edmondson <dme@dme.org>\r
+Date: Thu, 26 Jan 2012 08:53:20 +0000\r
+Message-ID: <cunk44elu9r.fsf@hotblack-desiato.hh.sledj.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha1; protocol="application/pgp-signature"\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: Thu, 26 Jan 2012 08:53:26 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Wed, 25 Jan 2012 09:45:01 -0800, Jameson Graef Rollins <jrollins@finestr=\r
+ucture.net> wrote:\r
+> On Wed, 25 Jan 2012 10:20:26 +0000, David Edmondson <dme@dme.org> wrote:\r
+> > Isn't it still necessary to ensure that you have encryption keys\r
+> > appropriate to the recipient?\r
+>=20\r
+> I want to ensure that all replies to encrypted to be encrypted. I\r
+> would rather have the reply fail outright than fall back to\r
+> unencrypted.\r
+\r
+That's a policy decision that a user can (and perhaps should) take, but\r
+not something that should be enforced by the tool. Encouraging this\r
+approach is fine, of course. I can think of various situations where I\r
+might send an un-encrypted reply to an encrypted message.\r
+\r
+> Here's a behavior that I think would be reasonable:\r
+>=20\r
+> * notmuch reply outputs JSON encrypted flag\r
+>=20\r
+> * emacs does a quick check to see if the needed key is available\r
+>=20\r
+> * if key not available: give a nice mini-buffer prompt, something like:\r
+>=20=20\r
+> 'encryption key for "Foo Bar <foo@bar.com>" not found. Retrieve?'\r
+>=20\r
+> * if response is yes: call gpg to retrieve the key\r
+>=20\r
+> * if key available: add encrypt flag\r
+>=20\r
+> else: I feel like this should abort, but maybe there's something to\r
+> be done here. Allow reply but don't quote the original?\r
+\r
+How about:\r
+ - notmuch reply outputs JSON encrypted flag,\r
+ - emacs inserts the relevant mml to request that the reply is sent\r
+ encrypted if the flag is present.\r
+\r
+With this approach the default behaviour is to send an encrypted reply\r
+to an encrypted message, but the user has the chance to change the\r
+behaviour using familiar (well, as familiar as mml can be) tools.\r
+\r
+Adding improvements to retrieve keys for outgoing messages would be\r
+generally useful - it's not just an issue for replies.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk8hFIAACgkQaezQq/BJZRYmVwCfTcVgXyz+yXySlEZphtOXaxfy\r
+vbgAn3LrogNQVa8HEtsFAOjN+oDtnBiU\r
+=P3tD\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r
projects / notmuch-archives.git / commitdiff