From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org
Subject: crypto and draft messages [was: Re: Emacs: postponing messages]
In-Reply-To: <87mvn330zr.fsf@qmul.ac.uk>
References: <87mvn330zr.fsf@qmul.ac.uk>
User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Thu, 02 Jun 2016 17:08:51 -0400
Message-ID: <8737ovqows.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain

On Thu 2016-06-02 14:21:44 -0400, Mark Walters wrote:
> There was some discussion on irc yesterday about a better way of
> postponing message when using the emacs frontend. I think getting a
> moderately nice interface should be quite easy (see below) but there are
> some corner cases on what *should* happen that I would like to resolve
> before trying to implement anything.

one other corner case worth thinking about here (it can probably be
postponed until we have base cases handled, but i wanted to bring it up)
is how per-message cryptographic operations (mml-secure-*) interact with
drafts.

In particular, i think that any sort of message signing should *not*
happen during saving of a draft, but the intent to sign should be
preserved.  That is, we should save and restore the #secure tag when
saving a draft or restoring a draft, but the saved draft itself should
*not* be signed.

for encryption, i have a different (and arguably opposite) intuition.
if the sender has the ability to *decrypt* mails, i'd argue that saving
a draft should encrypt the draft, regardless of the draft's stated
intent to encrypt.

These cases matter because i know many people use tools like
offline-imap to sync their mail store with a remote mailserver.

if the remote mailserver can get a copy of the signed draft, it could
replay it (effectively making use of an unintentional signature).
Likewise, if the user doesn't think about encrypting a message until
they're they're ready to send it, then an intermediate/draft version of
the message might end up in cleartext on the remote server.

    --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJXUKBkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy
NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKn/kP/jIAa/vPENgQ0pz3OQQ24Drs
l30qjohwbWPmWee8iPdk7ufmUM8YxU63ZBgYpXT3DhG/7xe7tZFzGqmg4y9dcaUs
XXIDuusVBUpmCokSqedI0IW7kTBV3padFHm9Mm/DHEMnKh8Rv9nzIMuxaDTvsi+i
QZWM2o2LcIkiP/zk6qAHsmCgtSQi77txPcBmGuheludDvs6aXRfkV5CB2Silf095
CLnPCr/8NYQ7TdJpglsuqdBDxrmAUYSKhx2l+tVDe07ksVNcBI+HXghwRjl2SUsE
VOhKD7tz9XQq73cdGe97++GlU0N7p2cECEFEDjyxRUyI6bEYEZ75qT+2lf73QiPi
LEaCJ89SdVMoVBpwiVi0fHlaKY7hehVg1KOXAHoJ+pWNqJhLLj5/O99iIlk/neRR
E98CFiUu95FP9Pc8UJ2ghYVGzfV+9SphcI6MfbNf4xhQSNyyz5f5gmMHeiNn0SV2
z04F7sh5fDfeOBSjLE4U3ApC2aiLqqC3xUHaoKTOrVdUfLEfW55HO8Ik/thQhEx6
QbWFiLReBFlFu7SABnHUF16vXnXJej2ZyZB08wxR22BuEtNDopUgxMh6AUetj9j2
j1CnGLpuwrKGOX+ZawYcLPPWdjApQAlrXbBaENop2OTwP/HZJODtsqFANzu+dcHc
KkNeUvxp5Wxm/6oi7k+I
=+meW
-----END PGP SIGNATURE-----
--=-=-=--