See also the comments in meta bug 1595226.

This is about the encryption "status" for the current message.
This means, are we able or unable to encrypt?

This is different from the encryption "configuration" (what the user asked to do) which is tracked in bug 1630405.

We cannot send an encrypted email, unless the following is true for every recipient of the email:

• we have a public key (openpgp) or public certificate (s/mime) for every recipient
• each key/certificate is valid
• validity means: The public key that we have is not yet expired, not revoked, and we are accepting the key

(Potentially an ambiguity for a recipients key could also be considered as a reason to not send the message unless the situation is resolved.)

If there's a problem with at least one recipient, the status is that we cannot send an encrypted message.

If the configuration requires encryption, the message cannot be sent, unless the problem is fixed, or the configuration is changed (e.g. the user disables encryption),

In past Thunderbird versions, and until today, the "cannot send" was implemented in a very simplistic way: If the user requests to send the message, an error message will be shown.

I suggest that we improve this in the following way and avoid the error prompt.

If the message cannot be sent

• disable the "send" button, and don't accept the hotkey (keyboard shortcut) for sending the message. (Thunderbird already uses this approach if the message cannot be sent because the recipient list is empty.)
• show a visual status that notifies the user that the message cannot be sent because the requested encryption cannot be provided (or needs review, before it can be provided)

A very simply approach could be to show a plain text message in the status bar. We could begin with this simple approach while developing the various states that we need to consider. Later we could decide if the information should be provided in a different way, e.g. with icons or notification bars.

Querying if the message can be sent or not, isn't a cheap operation. We'll have to check how expensive it is, how much delay it causes until we know the status.

So one important aspect is to minimize the number of times that we'll have to calculate the status.

I see that typing individual characters into the recipient fields don't immediately trigger the send button status to change. Rather, the status only changes after pressing enter (which creates the "pill"), or when triggering an action (e.g. save as draft, or send message). It seems we should only update the encryption status display for the same events.

There will be a small conflict. If the user starts typing a new address, but doesn't press enter yet, and then hits send - then we'll only learn about the inability to send, when the user has already requested to send. In that case, we wouldn't allow the send action, but rather update the status, only. Maybe this might confuse the user (types address without enter, hits send)? Maybe we should show a prompt in this scenario anyway?

Note that there's also the suggestion to show individual status icons per recipient - to allow the user to easily discover which recipients are fine, and which aren't.

Maybe we should handle that in a separate bug - and limit this bug to the "overall" status, as the first step.

We have the following states:

If encryption is disabled by configuration, we don't show any status text.
(In the future, we could potentially inform the user that encryption is possible, allowing the user to discover the feature.)

If encryption is enabled by configuration, the following can happen:

Encryption is possible, because we have acceptable valid keys for all recipients.
Show status text: "encryption is possible"

Encryption is impossible because at least one key is missing.
Encryption is impossible because at least one key is available, but hasn't been accepted yet. I suggest to call this "needs review".
These scenarios might happen at the same time, e.g. if two keys need review, and one key is missing.
We could used a dynamic, combined status text, with the following variations:

• "cannot encrypt: 1 receipient key is unavailable"
• "cannot encrypt: 2 receipient keys need review"
• "cannot encrypt: 2 recipient keys need review; one key is unavailable"

Some recipient keys might have been previously valid, but are no longer valid, because they have expired or have been revoked. Or the user could have marked the key as blacklisted/rejected.
I suggest to treat that as "unavailable", if no other valid keys are available for the given recipient.

The "needs review" scenario could also mean that multiple keys are available for a recipient, and none of them has been accepted/reviewed yet.

Eventually, we can consider to also handle ambiguity. For example, if had previously accepted Alice's key 1, but we recently saw another key 2 for her address in a received email. It might be useful to let the user know about the ambiguity and suggest to review it. However, that's probably optional, and doesn't need to block sending. If an ambiguity is detected, with no other problems, then we could display "encryption is possible. (Key ambiguity detected, review recommended)"

We might have to add some more scenarios which I'm currently not remembering, but the above list are the most common scenarios.

I suggest to implement this for OpenPGP in a first step.

Our OpenPGP implementation is completely done at the JavaScript code level.

Our S/MIME implementation is mostly done in C++. I assume we'll have to use completely different code for obtaining the required backend information that's necessary to implement this enhancement.

So in the initial step, we'd still use the old behavior when the S/MIME encryption technology is selected (no status, error message on failure), and use the smarter approach when the OpenPGP encryption technology is selected.

This bug seems to request the "pre-calculated" encryption status (adjusting summary). I don't know if that makes sense. Many times it could conceivably discover keys and do other confirmations (with user input) during the try-to-send, which would resolve blockers.

Our work on bug 1627956 will solve this.

(In reply to Magnus Melin [:mkmelin] from comment #5)

This bug seems to request the "pre-calculated" encryption status (adjusting summary). I don't know if that makes sense.

We have decided that it makes sense, see the work in bug 1627956.

(In reply to nf from comment #6)

Our work on bug 1627956 will solve this.

I agree that bug 1627956 will handle most of the ideas given in this bug here.

The approach that is chosen is:
If encryption is enabled and possible: don't show any status (besides a button that shows that encryption is enabled)
If encryption is enabled and impossible: show warning notifications

However, at this time, that bug focuses on OpenPGP.
We need equivalent feedback for S/MIME.

If bug 1627956 will handle OpenPGP, only, then we'll need a follow-up bug to design and implement equivalent visual feedback for S/MIME.