From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH v2 0/3] postpone and resume support
In-Reply-To: <1464976195-23134-1-git-send-email-markwalters1009@gmail.com>
References: <1464976195-23134-1-git-send-email-markwalters1009@gmail.com>
User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Fri, 03 Jun 2016 14:42:28 -0400
Message-ID: <87eg8eglm3.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
Content-Transfer-Encoding: quoted-printable

On Fri 2016-06-03 13:49:52 -0400, Mark Walters <markwalters1009@gmail.com> =
wrote:
> This is a new version of the WIP patch at
> id:1464915472-5669-1-git-send-email-markwalters1009@gmail.com
>
> So far it seems to deal with all cases that I have tried, and the
> CAVEATS list is rather smaller than before.
>
> The bindings are C-x C-s to save a draft (in notmuch-message-mode) C-c
> C-p to postpone a draft (ie save and exit buffer), and "e" to resume
> editing from either show or tree mode. You may want to add "draft" to
> your list of excluded tags to hide them unless you specifically search
> for them.

This is a really useful series, even with the caveats Mark lists.  i've
tested it and it behaves as expected for me.

A bit more discussion on the caveats:

> Each save saves a separate copy of the message. We hide these copies
> with the deleted tag but we don't actually delete them. Thus if you
> save several copies of message with large attachments you will use a
> lot of space.

This is a little bit weird, because it means that all these deleted
drafts show up in the thread view when viewing the thread from which the
message was composed.  Is there a reason to not actually delete older
drafts when "re-postponing" or sending?  We created the message
ourselves, so it seems like it's fair to delete it.

> If you use signing or encryption then I don't know what will happen:=20
> I have not tested at all.  You might sign a partial message that you
> didn't mean too; you might expose plain text to someone.

I've just tested this for signing, and it's doing the thing i was afraid
it would do :/ When saving a draft marked as a message to be signed, the
message signature is made on the draft.  Even worse, restoring a saved
draft like this leaves the user editing the plaintext while the old
message signature is likely to be appended, which will result in broken
signatures :/

Maybe there's a way to temporarily inhibit the interpretation of all
#secure flags during draft saving (and propagate them through upon
resume)?  I think that would be advisable anyway -- if we ultimately
decide that we want to encrypt drafts, we don't want to encrypt them to
the actual recipients anyway; we only want encrypt-to-self, because we
want to avoid the situation where the person we're sending the message
to gets access to our drafts folder and reads our unfinished/unedited
compositions, so that would be a separate and distinct improvement.

> Finally, and this is not really a caveat, it *may* be possible to resume
> a previously sent message. At the moment I haven't tested this, and
> have made it so that emacs warns before allowing it.

I've tested it.  It's possible, and it even seems to work :) there are
weird interactions between things like DKIM and modified message-ids,
but i think the warning provided is sufficient to let people know that
if they're doing that sort of thing and something breaks, they get to
keep both pieces.  The biggest danger, i think, is in marking the
non-draft for deletion if a user goes ahead with restoring it.

          --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJXUc+UXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy
NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKCxAP/Rby4F1h1heQySr68Q3/kbx+
PZ2hmeZIif5a/mCOG3ZVwM5GFfQEQ5IqhgHsCbirpiGxHTSSJ/k2p8on3d17e9Pw
SUiKVaI0Ii1YoFKkCuDLvaC/LobYApYJitE2YywDKxF8/m7JSXld5lyYlQrjVp84
n7qIWpmk+n80KPDJXxhUS9mk9pXZwiERrhak2c1o9HlqFPWfKeQXRuQcwWNiGLeU
2eEPxDFHhfQoq6kZ1mGrwnqbnbU6il7z1ejsFb02F3UthmQ33WQdsA0ZjMTFWsUu
jOZhpjYzjyudzFz/9azJaVHM7rF8VVbp762fF6iQqiBWZ7aR6guJMJxb31HwTy+d
4Eaa2RFY/BMnQMcfq5XAW2ryxqP4SB4EnVmi8SPoHBO2DYsPw0P5sNBkYhiJVNoA
x+IZBBV2FlyP5DhKAs/VQIb8TMovL9prCJGYdzBoU2LRhAliL7iPggb2KcxXi6Ot
038Ny94fnBoR+khbadDCXlX2Pgx1RFJZxSDMd67knpRhTaae5CMXLtE6sMiXoLQj
YQZi5hWrrI2zJeuLVPjxkKqKRrZ2YpsgHDa5gBs+naecWu7ILKAR185HkqVDA3Y6
XEtYL/5zyWFY4qxeTMhO146LE0BgLSDF0X6lVtB0Y66GFo0KUoa9A7kAyDjbV6nN
V3E0CMJVwftk1z5HZpGx
=XXOg
-----END PGP SIGNATURE-----
--=-=-=--