GNU bug report logs - #18513
24.3; message-mode sends unencrypted on error

Previous Next

Full log

Message #37 received at 18513 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Cc: 18513 <at> debbugs.gnu.org, David Bremner <david <at> tethera.net>,
 Daiki Ueno <ueno <at> gnu.org>
Subject: Re: bug#18513: 24.3; message-mode sends unencrypted on error
Date: Wed, 25 Sep 2019 15:05:06 +0200

Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:

>> It's not difficult to bug out on <#unknown>, but since Message mode
>> buffers mostly free text, doing so would lead to people having their
>> emails fail if they were to type such a thing by hand.  MML is only
>> recognised if it's one of the keywords it er recognises.
>
> It seems to me that there's a sensible balance to be struck, where MML
> can carve out a recognizable, predictable space, while still not causing
> unncessary failures.
>
> For example, it could try to interpret every sequence that starts with
> the two characters U+003C LESS-THAN SIGN, U+0023 NUMBER, and ends with
> U+003E GREATER-THAN SIGN, if those characters are all on a single
> line. (does mml handle tags split across multiple lines?)

But that would trigger on this <#no-mml tag> and would annoy people.

> I do note that mml-mode itself offers some help, because it seems to
> apply a different textual style to strings that mml will act on.  As
> long as the user can visually distinguish between these textual styles,
> and assuming that the matching rules in mml-mode are precisely aligned
> with the mml-based transformation that happens just before a buffer is
> sent, then the user has some amount of feedback -- but i'm not sure that
> both of those assumptions holds in a buffer during arbitrary editing.
> Does it?

I think so.

But perhaps there should be a secondary level of testing for
encryption-related commands.  That is, if you've typed `C-c C-m c p'
(for instance), and then the MML parser doesn't find any encryption tags
in the buffer, then it could ask something like "You indicated that you
wanted this to be encrypted, but it won't be; send anyway?"

I mean, you may have used that command and then removed the "secure"
tag because you changed your mind, so completely refusing to send
probably isn't a good idea.

This warning stuff could be done via a buffer-local variable, I
guess...  Although that wouldn't survive a round trip to the drafts
group.

Perhaps a header?

User-Wants-Encryption: yes

?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.