User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Set your account to send [PGP signed but] unencrypted email by default.
Have your own private PGP key and your recipient public PGP key.
Compose an email.

Actual results:

TB sends unencrypted email.

Expected results:

Since both parties have a known PGP key, TB should notice it and encrypt the email.

Only a minority of people in the world use PGP, therefore it makes sense to not have encrypted email by default for the people who don’t care about it.

In Enigmail there was an option to automatically “upgrade” your email to encrypted if all your recipients have known PGP keys.

Whether we like or not, there are people in this world who use PGP and some who don’t. Hence a strict option “encrypt everything” or “don’t encrypt anything” is unsatisfactory.

TB should detect the problem and offer :
• If your setting is “don’t encrypt”, TB should offer to upgrade from signed email to encrypted email or even encrypt by default if you have the recipient keys. (You could even have a list of emails that always require encryption.)
• If your setting is “encrypt”, TB should not only warn you that there is no recipient key, but also offer to downgrade your email to unencrypted (but signed).

This “regression” or loss of functionality from Enigmail is a step beyond what was useful before.

I would like to second this request. At the moment I have to choose between:

• "Do not enable encryption by default": Remember to enable encryption for the few contacts I have a key for, which I will fail doing once in a while.
• "Require encryption by default": Click away two dialog boxes when sending mail to a majority of my contacts, or remember to turn encryption off every single time before sending.

Enigmail's opportunistic approach was perfect for a person with a few contacts with keys, working like "HTTPS everywhere". The current options seem to target people either wanting to encrypt a single mail once in a while or having solely encrypted correspondence.

Also, in "Do not enable encryption by default"-mode, when replying to encrypted messages, encryption is automatically enabled, which is inconsistent to writing the person a new message - but halfway to opportunistic mode ;-)

This is a must-have feature in my opinion. No way anyone remembers to enable/disable encryption every time - there isn't even a possibility to toggle it with a single button, you always need to go through a menu. People that aren't very privacy concerned or aware will just disable encryption by default, leading to unintentionally non-encrypted mails.
To me, this borders on unusable, the workflow is simply too complex for something done as frequently as writing an email.
Sorry for the redundant comment, but i couldn't find a way to '+1' the issue.
If i can help solve it, please let me know.

This is a must feature, as any other controls for the user are completely missing

Hard to imagine there isn't an earlier bug covering this.

And bug 1681408 is a duplicate?

perhaps Bug 1644085 - Support automatic multiparty encryption, similar to groups in GnuPG or Per-Recipient Rules in Enigmail

(In reply to Wayne Mery (:wsmwk) from comment #4)

Hard to imagine there isn't an earlier bug covering this.

And bug 1681408 is a duplicate?

Yes, those two reports are asking about more or less the same thing. Proof that it’s necessary.

This is not a duplicate of bug 1644085, which asks to assign alternate keys to email addresses.

Bug 1681408 requests the ability to make a manual configuration for enabling/disabling of email encryption/signing based on email address.

The bug here is different from the above.
The bug here seems to request "automatically encrypt if possible", which has been requested in bug 135636.

+1

(In reply to govinda from comment #1)

Remember to enable encryption for the few contacts I have a key for, which I will fail doing once in a while.

Just happened to me, forgot to enter the menu to enable encryption for the new composed mail to one of the rare contacts I am able to send encrypted to. It was just a "normal" mail, "nothing to hide", so I did rather not care about actively enabling encryption on purpose. Annoying and sad to have sent cleartext mail, when it could have been encrypted.

Duplicate of Bug 1711294 ?

Hello TB-Developers!

I just wanted to remind you, that this bug is still not fixed ;-)
I would be very happy, if the recipient rules would be enabled again!

Thank you!
Leon

duping per comment 7. It is known that this feature is wanted per bug 135636 comment 126 - no further comments are needed.