From 52b5b1f1c82a165e73a2d32d7d0eff953e5ade62 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Sat, 4 Jun 2016 14:42:28 +2000 Subject: [PATCH] Re: [PATCH v2 0/3] postpone and resume support --- 18/5efaaeba1459021f9ca6e47b02b952f458272a | 140 ++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 18/5efaaeba1459021f9ca6e47b02b952f458272a diff --git a/18/5efaaeba1459021f9ca6e47b02b952f458272a b/18/5efaaeba1459021f9ca6e47b02b952f458272a new file mode 100644 index 000000000..6e79be815 --- /dev/null +++ b/18/5efaaeba1459021f9ca6e47b02b952f458272a @@ -0,0 +1,140 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id 183DA6DE0243 + for ; Fri, 3 Jun 2016 11:42:43 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: -0.019 +X-Spam-Level: +X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 + tests=[AWL=-0.019] autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id LMuPH4Wk4oNQ for ; + Fri, 3 Jun 2016 11:42:35 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) + by arlo.cworth.org (Postfix) with ESMTP id 027F46DE0159 + for ; Fri, 3 Jun 2016 11:42:34 -0700 (PDT) +Received: from fifthhorseman.net (unknown [38.109.115.130]) + by che.mayfirst.org (Postfix) with ESMTPSA id BB8C3F98B; + Fri, 3 Jun 2016 14:42:31 -0400 (EDT) +Received: by fifthhorseman.net (Postfix, from userid 1000) + id 64AA020245; Fri, 3 Jun 2016 14:42:31 -0400 (EDT) +From: Daniel Kahn Gillmor +To: Mark Walters , 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" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.20 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Fri, 03 Jun 2016 18:42:43 -0000 + +--=-=-= +Content-Type: text/plain +Content-Transfer-Encoding: quoted-printable + +On Fri 2016-06-03 13:49:52 -0400, Mark Walters = +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----- +--=-=-=-- -- 2.26.2