--- /dev/null
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id A3EE46DE01D0\r
+ for <notmuch@notmuchmail.org>; Thu, 2 Jun 2016 14:09:04 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.02\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.020]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id jZKYse1YD9sk for <notmuch@notmuchmail.org>;\r
+ Thu, 2 Jun 2016 14:08:56 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 4F0726DE00DB\r
+ for <notmuch@notmuchmail.org>; Thu, 2 Jun 2016 14:08:56 -0700 (PDT)\r
+Received: from fifthhorseman.net (unknown [38.109.115.130])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id BE94BF98B;\r
+ Thu, 2 Jun 2016 17:08:55 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id 46A3220205; Thu, 2 Jun 2016 17:08:55 -0400 (EDT)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: crypto and draft messages [was: Re: Emacs: postponing messages]\r
+In-Reply-To: <87mvn330zr.fsf@qmul.ac.uk>\r
+References: <87mvn330zr.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Thu, 02 Jun 2016 17:08:51 -0400\r
+Message-ID: <8737ovqows.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha512; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 02 Jun 2016 21:09:04 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+On Thu 2016-06-02 14:21:44 -0400, Mark Walters wrote:\r
+> There was some discussion on irc yesterday about a better way of\r
+> postponing message when using the emacs frontend. I think getting a\r
+> moderately nice interface should be quite easy (see below) but there are\r
+> some corner cases on what *should* happen that I would like to resolve\r
+> before trying to implement anything.\r
+\r
+one other corner case worth thinking about here (it can probably be\r
+postponed until we have base cases handled, but i wanted to bring it up)\r
+is how per-message cryptographic operations (mml-secure-*) interact with\r
+drafts.\r
+\r
+In particular, i think that any sort of message signing should *not*\r
+happen during saving of a draft, but the intent to sign should be\r
+preserved. That is, we should save and restore the #secure tag when\r
+saving a draft or restoring a draft, but the saved draft itself should\r
+*not* be signed.\r
+\r
+for encryption, i have a different (and arguably opposite) intuition.\r
+if the sender has the ability to *decrypt* mails, i'd argue that saving\r
+a draft should encrypt the draft, regardless of the draft's stated\r
+intent to encrypt.\r
+\r
+These cases matter because i know many people use tools like\r
+offline-imap to sync their mail store with a remote mailserver.\r
+\r
+if the remote mailserver can get a copy of the signed draft, it could\r
+replay it (effectively making use of an unintentional signature).\r
+Likewise, if the user doesn't think about encrypting a message until\r
+they're they're ready to send it, then an intermediate/draft version of\r
+the message might end up in cleartext on the remote server.\r
+\r
+ --dkg\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2\r
+\r
+iQJ8BAEBCgBmBQJXUKBkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
+NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKn/kP/jIAa/vPENgQ0pz3OQQ24Drs\r
+l30qjohwbWPmWee8iPdk7ufmUM8YxU63ZBgYpXT3DhG/7xe7tZFzGqmg4y9dcaUs\r
+XXIDuusVBUpmCokSqedI0IW7kTBV3padFHm9Mm/DHEMnKh8Rv9nzIMuxaDTvsi+i\r
+QZWM2o2LcIkiP/zk6qAHsmCgtSQi77txPcBmGuheludDvs6aXRfkV5CB2Silf095\r
+CLnPCr/8NYQ7TdJpglsuqdBDxrmAUYSKhx2l+tVDe07ksVNcBI+HXghwRjl2SUsE\r
+VOhKD7tz9XQq73cdGe97++GlU0N7p2cECEFEDjyxRUyI6bEYEZ75qT+2lf73QiPi\r
+LEaCJ89SdVMoVBpwiVi0fHlaKY7hehVg1KOXAHoJ+pWNqJhLLj5/O99iIlk/neRR\r
+E98CFiUu95FP9Pc8UJ2ghYVGzfV+9SphcI6MfbNf4xhQSNyyz5f5gmMHeiNn0SV2\r
+z04F7sh5fDfeOBSjLE4U3ApC2aiLqqC3xUHaoKTOrVdUfLEfW55HO8Ik/thQhEx6\r
+QbWFiLReBFlFu7SABnHUF16vXnXJej2ZyZB08wxR22BuEtNDopUgxMh6AUetj9j2\r
+j1CnGLpuwrKGOX+ZawYcLPPWdjApQAlrXbBaENop2OTwP/HZJODtsqFANzu+dcHc\r
+KkNeUvxp5Wxm/6oi7k+I\r
+=+meW\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r