[MlMt] Default settings for encryption/signing on per accout?

[Bill Cole]

On 10 Jul 2016, at 9:12, yet at gmx.de wrote:

> Hi there,
>
> I have two IMAP accounts where the business account should use 
> encryption by default
> and a second private account which should not encryption. My settings 
> are as in the
> attached screenshot.
>
> By default (opening a new composer window) encryption is enabled and 
> my private email
> from my business account is selected. For sending a private email I 
> have to my private
> identity and the encryption option remains on...so I always have to 
> uncheck the encryption
> option which is kind of annoying...is there any reasonable way for 
> having the encryption/signing
> options per account and not based on some vague "history" magic? It's 
> just not working as expected.

I just want to add whatever reinforcement to this plea I can. I won't 
even try to explain the full complex of failure modes I've run into with 
the history-based system, but I've got more addresses than I can count 
and multiple PGP keys and S/MIME certificates, so it mostly does not 
work. Since keys & certs are bound to *sending* addresses, it makes no 
sense to make sign/encrypt guesses based on the recipient addresses.

Use cases that break:

1. Mailing lists. I  mostly use list-specific addresses which mostly DO 
NOT have any key I can sign messages with. Those addresses are aliases 
for an account that has both a PGP key and a S/MIME cert. Some people 
sign their messages to mailing lists, so if I reply, MM wants to sign my 
reply but it has no key it can use for that.

2. In my primary professional role, I may use any of 3 distinct accounts 
with entirely different addresses that I use in different circumstances 
for business-political reasons too silly and mundane to explain. While 
the set of recipients does play a role in which address I want to use 
and whether I want to sign or encrypt a message, the complete decision 
for what account to use and what sort of crypto treatment to apply is 
immune to deterministic digital logic. I don't even get it right all the 
time, since another input is "who might this be forwarded to?" and I 
never cease to be amazed by that.

3. Talking to myself. Occasionally I have reasons to send myself mail 
from one account to another, in encrypted form. Every time I try this, 
MM does something that causes the GPG passphrase dialog to come up 
asking for the passphrase *of the recipient's private key* which is 
definitely not right.

I think the first thing to fix is to bind the sign/encrypt and protocol 
choices to the From address tightly and never try to second-guess the 
user's sending address choice at sending time. I THINK that's what is 
happening in (3) and I've had too many wrong-sender events not involving 
crypto to accept them all as user error. If there's no way to sign or 
encrypt a message from an explicitly chosen or MM-selected address, 
don't try to do so automatically and don't offer those options. Also, do 
not open up the sender choice to robotic change at sending time, no 
matter how strange the sender/recipient pairing may seem to the logic in 
MM.