I'm using an e-mail provider that autmatically encrypts received e-mails on their servers.

That may be conveniated, but it isn't the same as Thunderbird built-in end-2-end encryption (e2ee). The provider ultimately has access to the message content. Also I'm not sure how signing is supposed to work. If the provider also signs encrypted messages on your behalf, they control the private key. So you'd ultimately have to trust that provider.

When Thunderbird fetches these e-mails they are encrypted even if the sender did not encrypt the original message.

Are you saying the unencrypted messages travels all the way to your provider's email server, and then only at the last hop it get's encrypted just before you pull it from the server? That doesn't really make sense to me.

Since encryption is automatically enabled when replying to enrypted e-mails, which is a good thing, this is however an issue for me.

You'd need to manually uncheck encryption in the Write window prior to sending the reply.

There was on option in Enigmail that allowed a specific per e-mail address auto encryption, I couldn't find it in the new e2ee.

In terms of features, the current Thunderbird OpenPGP implementation isn't on par with Enigmail (yet). That will improve over time.

Many e-mail providers offer encryption at rest for received e-mails

I still don't see how this is superior to TB e2ee.

Hello christ1 and thanks for your reply.

> The provider ultimately has access to the message content.

If the message is in clear text, yes it can be caught at any point between the sender and the provider, before encryption at his entry. The advantage of this encryption at the provider level is is in case of an intrusion or in case the user account credentials are comprimised, this type of encryption can be helpful, lowering the risk surface for the receipient. Not our topic however.

> They control the private key. The encryption at rest on the provider's servers is done using the user's public key.

> You'd need to manually uncheck encryption in the Write window prior to sending the reply. This is the exact issue. All messages are dwnloaded encrypted, TB e2ee will look for a public key in the key ring and throw an error. Manually unchecking the encryption is somewhat annoying. Doing the opposite and disabling encryption altogether and manually enabling it for specific addresses can lead to sending clear text e-mails by mistake.

> I still don't see how this is superior to TB e2ee. There is no comparison here. E2ee is used at the client level and relates mainly to data in transit (end-to-end). The encryption at the provider level is related only to data at rest. two different approaches and aims. Howerver, the result is the same at the end. all mail gets downloaded encryppted and TB e2ee enforces encryption on this basis.

I've noticed Some bugs/tickets have been reported regarding this issue, I guess i'll be waiting for the next TB release.

Thanks again for your help.

E2ee is used at the client level and relates mainly to data in transit (end-to-end).

With every due respect, you got it completely wrong. The TLS based encryption protects the connection to the server, i.e. data in flight. The TB OpenPGP based encryption protects the message itself, i.e. end-to-end, and data at rest.

As opposed to that, your highly praised provider encryption approach leaves you vulnerable, and is by no means end-to-end.

I appreciate your help but i think I should give you a more detailed view :

- E-mail is sent in plaintext - Gets to my provider and is automatically encrypted with my public key - E-mail fetched with TB and decrypted.

- Reply - Error since there is no public key corresponding to the recipient in the keyring - Need to manually disable encryption.

As for your TLS argument which implies this encryption at the provider level is useless : For a sender TLS is no guarantee when using his local ISPs SMTP servers for example. I assume we both live in free and privacy friendly countries but think of a sender living in a context where all communication is filtered/spied on. On this basis, let's just consider everything flowing between that sender and my provider's servers plaintext e-mails, even with TLS.

Now to the point. Let's be imaginative and think of a recipient living in MITM Land with a somehow tampered with connection, evil DNS resolvers and bogus/fake TLS certificates served at his ISP level. This encryption at the provider's would certainly be helpful. At the least, we can think of a stolen password to the e-mail account, someone could be reading e-mails for years and one wouldn't even know it. ( I'm sure we agree on the fact that many people wouldn't change their passwords as frequently as they should). It's easier to get/sniff/brute force a password to an e-mail account than a passphrase to a private key right?

We could argue about this but this is still not the topic. My post is about the limitations of the new TB E2EE as for specifically chosing with whom to use encryption with in this particular configuration.

> The TB OpenPGP based encryption protects the message itself, i.e. end-to-end, and data at rest. Sure, that's why I said "mainly" and "only" in my last post.

Thanks.

Hey there! There was on option in Enigmail that allowed a specific per e-mail address auto encryption, I couldn't find it in the new e2ee.

I think this is being addressed in Bug 135636 I suggest you read it all but starting at comment 93 appears to cover the immediate plans.https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c93

Thanks Matt!