In Thunderbird 78 account settings, for users who configure both own S/MIME and own OpenPGP certificate/key, we offer a configuration "select automatically based on available keys or certificates".

This was initially planned to get implemented for TB 78.

Unfortunately, the functionality has not been implemented yet.

https://searchfox.org/comm-central/rev/93bfded213518bb71f465d6fa17baaafafb9a846/mail/extensions/am-e2e/am-e2e.js#114-116

Is this a bug to remove the UI or to implement the feature?

Good question. I know querying for available keys is super slow for S/MIME, so not sure how feasible it actually is to do this.
I think we could just use the manual user choice and be happy with that. There are many quite more important bugs. Kai, what do you think?

I don't think the time for querying an S/MIME key should be a problem.

When starting to compose a new message, I'd remember that we haven't yet made the automatic choice.

I suggest to base the decision on the first key found.

Each time a new correspondent has been entered, we check if there is any valid key for the recipient. If there isn't any, we keep it at undecided.

As soon as we find a correspondent that has either a valid OpenPGP key, or a valid S/MIME key, we switch to that encryption technology. Once that's done, we can stop the automatic lookup for further keys.

I think this would be a helpful first step. This could be improved later to recheck after recipients get removed, could be done with a temporary list of found keys.

Just tried to tackle this but it seems like this was implemented already. Is that correct Kai?

Lasana, what makes you think this was implemented already?

(In reply to Kai Engert (:KaiE:) from comment #6)

Lasana, what makes you think this was implemented already?

I missunderstood the bug description (I thought the intention was to implement the preferred encryption setting).

I don't think the time for querying an S/MIME key should be a problem.
When starting to compose a new message, I'd remember that we haven't yet made the automatic choice.
I suggest to base the decision on the first key found.
Each time a new correspondent has been entered, we check if there is any valid key for the recipient. If there isn't any, we keep it at undecided.
...

This seems like a lot of work for a small convenience. When I read "Select automatically based on available keys or certificates" I get the impression the setting will detect whether to use openpgp or smime based on the keys or certs configured for my identity, (all this does is change the default option in the security dropdown) not that it will scan available recipient keys to make that decision.

Just want to make sure I'm clear on what's wanted here before I get started.

If you have only one encryption technology configured for yourself, that encryption technology is already selected when composing a new email.

This setting is for users who have configured both technologies (the user configured a personal S/MIME certificate AND a personal OpenPGP key). If not, the "auto" choice cannot be configured.

The idea is to scan for available recipient keys or certificates and select the encryption technology based on that availability.

I think we should start by supporting the "reply" scenario. When the user replies to an existing message, we already know the (initial) set of message recipients at the time the composer window is opened.

It should be possible to scan which recipient keys we have available.

In the easiest scenario, replying to only one correspondent, the check is trivial. If we have the S/MIME key for the recipient, set technology to S/MIME. If we don't have the S/MIME key, then set technology to OpenPGP.

If we don't have any recipient keys, I'd set OpenPGP.

If there are multiple recipients, it's more difficult to make a good decision. You could count the number of good keys for recipinets for each tech. If we have OpenPGP keys for all recipients, but only a smaller number of keys for S/MIME, then select OpenPGP.

If the user composes a new email, we don't have the recipients yet, and we cannot make the decision at the time composer opens. In this scenario, we could check each time the user adds another email address pill. If we find that we don't have all keys for the selected tech, but have all keys for the unselected tech, then switch the tech.

I think we can actually simplify it a bit further: for replies, use the encryption technology of the original message. What keys/certs you have or may obtain is usually irrelevant. I'd say it's not "good manners" either to switch technology in the middle of a thread.

For new mails, I think we shouldn't do guesswork (the UI gets very complicated), but just use the preference of which one is preferable, and simply remove the option for automatic selection.

I confess that the wording of this pref isn't very clear. It's clear that it allows the user a preference for a technnology, but it isn't made clear WHEN this preference should be used.

I've come to the conclusion, the important question here is, which of the following is a higher priority: Is it more important to be able to send an encrypted email (which might be possible with only one technology), or is it more important to stick with the preferred technology?

I think the choice "select technology automatically" expresses the preference "switch technology if that makes encryption possible".

I think the choice for a particular technology should mean "select that technology, even if I cannot encrypt with it". With that choice, the user would be required to manually switch technology.

Consider the following scenario: The user composes an email, the user enables encryption, and initially the OpenPGP technology was chosen. Then the user adds a recipient, but with that new set of recipients, only S/MIME encryption is possible.

If "select technology automatically" is configured, then Thunderbird would automatically switch technology to S/MIME.

If "prefer OpenPGP" is chosen, then Thunderbird would keep the selected techology at OpenPGP. However, Thunderbird could show a reminder that encryption with S/MIME is possible, and the user could decide whether to switch technology or not.

Let's also look at the scenario after bug 135636, which introduces support for automatically enabling encryption.

Let's say the user mail.e2ee.auto_enable set to true, has an identity that is configured for both technologies, but has "prefer OpenPGP" configured. The user composes a new email. The user adds a recipient that works with S/MIME encryption, only.

One could argue, in this scenario encryption should NOT be automatically enabled with S/MIME, because automatic switching of technology isn't wanted.

The necessary code changes will likely overlap with the work for bug 135636. I'd like to postpone until after the code for bug 135636 has been commited.

Just for the record: Bug 1806328 was about switching between two identities, one with PGP only and one with PGP and S/MIME preferring S/MIME. Starting from the second (S/MIME), switching to the first and back leaves one with PGP and the notification that there is no PGP key for the recipient although at the start all was fine as there was an S/MIME cert for the recipient. So both a) using the preferred technology and b) making the choice so encryption is possible should have switched back to S/MIME with no doubts at all. The scenario in bug 1806328 is clear-cut and it's somewhat surprising that is has been duplicated here as no "automatic" selection is necessary.

I'm not really sure it's worthwhile to implement this automatism. Especially now in combination with suggest-encrypt-when-we-can and bug 135636, it really seems it could complicate matters (what to suggest, etc.) more than reasonable. And as we know, nobody really sends encrypted s/mime anyway.