On Wed, 25 Jan 2012 09:45:01 -0800, Jameson Graef Rollins <jroll...@finestructure.net> wrote: > On Wed, 25 Jan 2012 10:20:26 +0000, David Edmondson <d...@dme.org> wrote: > > Isn't it still necessary to ensure that you have encryption keys > > appropriate to the recipient? > > I want to ensure that all replies to encrypted to be encrypted. I > would rather have the reply fail outright than fall back to > unencrypted.
That's a policy decision that a user can (and perhaps should) take, but
not something that should be enforced by the tool. Encouraging this
approach is fine, of course. I can think of various situations where I
might send an un-encrypted reply to an encrypted message.
> Here's a behavior that I think would be reasonable:
>
> * notmuch reply outputs JSON encrypted flag
>
> * emacs does a quick check to see if the needed key is available
>
> * if key not available: give a nice mini-buffer prompt, something like:
>
> 'encryption key for "Foo Bar <f...@bar.com>" not found. Retrieve?'
>
> * if response is yes: call gpg to retrieve the key
>
> * if key available: add encrypt flag
>
> else: I feel like this should abort, but maybe there's something to
> be done here. Allow reply but don't quote the original?
How about:
- notmuch reply outputs JSON encrypted flag,
- emacs inserts the relevant mml to request that the reply is sent
encrypted if the flag is present.
With this approach the default behaviour is to send an encrypted reply
to an encrypted message, but the user has the chance to change the
behaviour using familiar (well, as familiar as mml can be) tools.
Adding improvements to retrieve keys for outgoing messages would be
generally useful - it's not just an issue for replies.
pgptOgiOzfeaj.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
