Bugzilla

Another angle to consider:

It has been suggested to implement "automatically encrypt if possible". This won't be a feature of Thunderbird 78, but we're considering it for a future Thunderbird version. (See also bug 135636.)

The idea is, the user could opt in to automatically send messages with encryption, if valid keys for all recipients are available. If not, the message would be sent without encryption, without asking the user for a decision.

If Alice sent an encrypted message to Bob, then Bob doesn't know what Alice had intended.
Did Alice explicitly use encryption, because she consider the message contents highly confidential?
Or does Alice use a client that uses opportunistic encryption, and sent the message with encryption, simply because it was possible to do so?

Bob might not know if protecting the message contents is very important for Alice.

Let's assume we'll implement "encrypt if possible" at a later time, and Bob has that option enabled.
Bob replies, adds Carol to CC, and Carol's key is not available.
Based on the configuration, Bob's Thunderbird could automatically send the message without encryption, but now knowing Carol's intentions, Thunderbird probably shouldn't send without encryption.

I think the fix for this bug should include the future "encrypt is possible" scenario.

It might be OK to allow the "encrypt if possible" strategy for new messages.

However, when replying to an encrypted message, I think we should always make it difficult to reply/forward without encryption - even if Bob has the "encrypt if possible" choice configured.

Another angle to consider:

It has been suggested to implement "automatically encrypt if possible". This won't be a feature of Thunderbird 78, but we're considering it for a future Thunderbird version. (See also bug 135636.)

The idea is, the user could opt in to automatically send messages with encryption, if valid keys for all recipients are available. If not, the message would be sent without encryption, without asking the user for a decision.

If Alice sent an encrypted message to Bob, then Bob doesn't know what Alice had intended.
Did Alice explicitly use encryption, because she consider the message contents highly confidential?
Or does Alice use a client that uses opportunistic encryption, and sent the message with encryption, simply because it was possible to do so?

Bob might not know if protecting the message contents is very important for Alice.

Let's assume we'll implement "encrypt if possible" at a later time, and Bob has that option enabled.
Bob replies, adds Carol to CC, and Carol's key is not available.
Based on the configuration, Bob's Thunderbird could automatically send the message without encryption, but not knowing Carol's intentions, Thunderbird probably shouldn't send without encryption.

I think the fix for this bug should include the future "encrypt is possible" scenario.

It might be OK to allow the "encrypt if possible" strategy for new messages.

However, when replying to an encrypted message, I think we should always make it difficult to reply/forward without encryption - even if Bob has the "encrypt if possible" choice configured.

Another angle to consider:

It has been suggested to implement "automatically encrypt if possible". This won't be a feature of Thunderbird 78, but we're considering it for a future Thunderbird version. (See also bug 135636.)

The idea is, the user could opt in to automatically send messages with encryption, if valid keys for all recipients are available. If not, the message would be sent without encryption, without asking the user for a decision.

If Alice sent an encrypted message to Bob, then Bob doesn't know what Alice had intended.
Did Alice explicitly use encryption, because she consider the message contents highly confidential?
Or does Alice use a client that uses opportunistic encryption, and sent the message with encryption, simply because it was possible to do so?

Bob might not know if protecting the message contents is very important for Alice.

Let's assume we'll implement "encrypt if possible" at a later time, and Bob has that option enabled.
Bob replies, adds Carol to CC, and Carol's key is not available.
Based on the configuration, Bob's Thunderbird could automatically send the message without encryption, but not knowing Carol's intentions, Thunderbird probably shouldn't send without encryption.

I think the fix for this bug should include the future "encrypt if possible" scenario.

It might be OK to allow the "encrypt if possible" strategy for new messages.

However, when replying to an encrypted message, I think we should always make it difficult to reply/forward without encryption - even if Bob has the "encrypt if possible" choice configured.