Thunderbird implements PGP crypto feature requested 21 years ago

Mozilla's mail reader Thunderbird has implemented a feature first requested 21 years ago. The somewhat garbled request – "I'd appreciate a plugin for PGP to ede and encrypt PGP crypted messages directly in Mozilla" [sic] – appears to have gone unimplemented due to concerns about US laws that bar export of encryption, debate …

[Anonymous Coward]

Encryption should be automatic

PGP never took off, because it requires a public key server to verify identity and identity simply has nothing to do with encryption. Those third party servers are just honeypots of 'who is sending encrypted emails to whom and when' and places to attack if you want to substitute a key. They are the Symantec's of the world*.

https://news.softpedia.com/news/three-symantec-employees-fired-for-issuing-fake-google-com-ssl-certificates-492190.shtml

Revoke key is not a good thing either. You let a third party say a key is cancelled because you trust that third party more than the actual email services you're talking too??? No.

Thunderbird should sent a public key with every email in the meta data. Mozilla should automatically collect public keys from the meta data and use them. It should have a setting "Automatically upgrade to encrypted", when it receives an encrypt key, it should use the key when emailing that address, and keep track of which keys were provided.

If you trust an email address enough to talk to them as if they were fred.bloggs@ then you trust their key to encrypt that message. You do not need a third party to verify fred.bloggs is fred.bloggs. If you didn't care enough for other purposes, then you don't care enough for the encryption.

Collect the keys, confirm the key remains constant, if ever the key changes, flash a big alert up "fred.bloggs's encrypt key has changed, is this still him?"

No third party keyholder, not 'trusted' third party. No Symantec's injected into private conversations. There is nothing special about wanting a private conversation in a communication system that is supposed to be private!

* And also notice that Google monitors its public keys, which is how they spotted Symantec issuing fake certificates, but you do not. You would not be aware if the 'trusted' keyholder starts issuing a different public key. PGP was never adopted because it is flawed.

[A Non e-mouse]

Re: Encryption should be automatic

PGP never took off, because it requires a public key server to verify identity and identity simply has nothing to do with encryption

And the fact that Johnny Can't Encrypt.

PGP's usability is very poor.

[Anonymous Coward]

identity and encryption

Thunderbird can really take the initiative here, and simply implement it. If two Thunderbird clients are emailing each other then it will automatically be encrypted after the first email exchange. Without the need for a third party key holder and without the need for the user to do anything.

I do not like third party key holders. They're simply meta data surveillance engines, pretending to be suppliers, who, out of the goodness of their hearts run these servers.

I do not like any protocol with a "revoke", where said third party key holder can flag keys as having been "revoked", letting them swap in a fake key anytime they can also intercept the email exchange. It enables an attack vector.

I do not like "renewing" certificates. Where at renewal time, the attack can be initiated. It's another attack vector similar to revoke but at a preset time.

Notice that to backdoor the above system, you would need to intercept the *very first* exchange of the public key. You would then need to intercept each and every email exchange between those people and always substitute the fake key. Fail one time and a warning is flashing up on a persons screen.

Lost their public key? No problem send them an email and it will be unencrypted, on their system they will get a nice big warnings. "Warning This person normally sends encrypted emails, this email was not encrypted. It may not be them.".

Have two email clients? You won't be able to read the emails for the other client unless you copy the keys folder across to the second Thunderbird. Big deal, you knew enough to configure two email clients to one server. You know enough to copy some files.

Want to change your public key? Then change it. People you communicate with will get a big fat warning that something is wrong because the key has changed. That's as it should be!

[Blank Reg]

Re: identity and encryption

What about the private keys? If you expect people to manage those on their own and ensure that they are backed up then it will never get off the ground.

[Anonymous Coward]

Re: identity and encryption

What about the password? If you expect people to manage those on their own and ensure that they are backed up then it will never get off the ground.

Right back at ya.

[just_some_dude]

Re: identity and encryption

Yeah, not the same at all. People forget/lose their passwords all the time. You just reset it which typically requires a verification email,etc. Lose your email private key and you can't read any emails sent to you until you get a new key pair generated and distributed. Also, presumably all old emails would be stored encrypted, so you'd lose all those also.

[DuncanLarge]

Re: identity and encryption

As long as you have backups of your home directory that includes the .gnupg directory you are fine as long as you dont forget your keys password.

Of course most people barely backup anything so I think your question is just one of many similar questions that people only read when they lose all their data and go to reddit to ask how to recover it off a dead hdd.

[bombastic bob]

Re: identity and encryption

As long as you have backups of your home directory that includes the .gnupg directory you are fine as long as you dont forget your keys password.

I have to wonder about Windows users, though... Backup? what's that?

There's always an old school way of doing it:

Fred: Hey Joe, what's your publc key? Mine is {alphabet soup}

Joe: it's {alphabet soup}. Let's mark our e-mail clients to send mail to each other using public key encryption every time from now on.

(old school "just ask for it" public key exchange)

but an automatic way would be better.

What I would like to see [if not done already] is an RFC on mail exchanges having their own public key database, maybe even part of the SMTP server itself. Maybe like this:

HELO example.com

PUBK [e-mail]

'PUBK' would tell the SMTP server to send back the public key for [e-mail], if in fact it is a canonical server for testing.com e-mails, joe is a valid mail user, and joe also registered a public key with the server.

Since I haven't seen how gnu public key stuff works [I definitely should look at what TBird is doing now] this may have already been implemented, or there might be an RFC for it already that I haven't downloaded AND looked at. In any case, making it automatic might require some additional infrastructure and protocol implementation by others...

[A Non e-mouse]

Re: identity and encryption

Thunderbird can really take the initiative here, and simply implement it. If two Thunderbird clients are emailing each other then it will automatically be encrypted after the first email exchange

PGP & Email does two things. It encrypts emails in transit but it also provides identity assurance.

You can't automatically provide the identity assurance without either a manual process or recourse to a trusted third party.

[Anonymous Coward]

Re: identity and encryption

"You can't automatically provide the identity assurance without either a manual process or recourse to a trusted third party."

You don't need identify assurance beyond the email address. Linking the two means you get neither.

[DuncanLarge]

Re: identity and encryption

> you don't need identify assurance beyond the email address

Because everyone is born with an email address tattoo on their foot?

There is nothing in an email address that goes anywhere to prove identity.

Anyone can create a key for any address, even the one you use. Once they make a key for that address and then get hold of your address due to your terrible password choice was leaked in a breach that matched the rainbow table they have for unsalted hashes of common words they can literally impersonate you and just have to blag about how your key has changed etc. Savvy GPG users will then contact you via other means to confirm they key, and if you use a keyserver will think something is up if you have not revoked the old key.

We've had public key crypto for decades its not that hard to understand.

Ultimately to prove identity is to meet each other face to face and exchange public keys, then sign them. At a key signing party. Unfortunately that is a barrier but that is the ONLY way to confirm beyond a doubt that it is YOU behind that address and if you do key signing correctly, behind ANY address and ANY key you sign.

The tech is sound, the web of trust is the problem as its not always used.

No other way exists to prove you own an email address. Not without confirming other factors or confirming you have access certain devices. I could email you a random string then call you and have you read that out, that would work. But nothing allows you to prove identity simply by giving the email address.

[Doctor Syntax]

Re: identity and encryption

"Ultimately to prove identity is to meet each other face to face and exchange public keys, then sign them. At a key signing party. Unfortunately that is a barrier but that is the ONLY way to confirm beyond a doubt that it is YOU behind that address and if you do key signing correctly, behind ANY address and ANY key you sign."

Who's YOU? Even face to face you have to take somebody's word for who they say they are. If somebody tells you they're [e-mail] how are you to know that that's who they really are? A better way would be to have example.com's mail server tell you that [e-mail]'s public key is. You still don't know whether [e-mail] is Fred Bloggs, Fred Flinstone, Frederick the Great or my late uncle Fred of course.

[Charles 9]

Re: identity and encryption

"Who's YOU? Even face to face you have to take somebody's word for who they say they are. If somebody tells you they're [e-mail] how are you to know that that's who they really are? A better way would be to have example.com's mail server tell you that [e-mail]'s public key is. You still don't know whether [e-mail] is Fred Bloggs, Fred Flinstone, Frederick the Great or my late uncle Fred of course."

And what if example.com has been pwned? Or is under Big Brother's thumb? Frankly, this all boils down to the intractable thing I call the First Contact Problem:

How do Alice and Bob prove who each is to the other if they've never met before and have nothing in common?

Short answer: You can't to any significant degree of certainty. Ultimately, because of the lack of anything in common, ANY attempt to establish the link can be subverted by an adversary (Mallory or Gene) by the simple process of impersonating one of the parties; the other party has no way to tell the difference. Even a Trent can be doubled in this case.

[rg287]

Re: identity and encryption

Thunderbird can really take the initiative here, and simply implement it. If two Thunderbird clients are emailing each other then it will automatically be encrypted after the first email exchange. Without the need for a third party key holder and without the need for the user to do anything.

You can't turn on encryption automatically because you can't assume that users are only using Thunderbird (which has no mobile app). Flick encryption "on" in TB and suddenly whatever you're using on your phone will collect your mail well enough but most likely won't be able to decrypt it.

There are mobile apps like K9 and Canarymail which can handle PGP of course, but what are the odds that you're actually using one of those? If you're using TB as a desktop client for a hotmail or gmail account, you're most likely using the Outlook or Gmail apps on mobile.

Thunderbird can and should prompt for users to enable encryption, but needs to explain the ramifications of doing so (like changing mobile apps).

Once enabled, some sort of auto-detect and key-exchange for PGP would seem to be beneficial. ProtonMail made key-exchange go away by just doing it automatically between ProtonMail accounts, acting as their own internal key server. But encrypting to third party addresses is still a faff. Their selling point is mostly the mail being effortlessly zero-knowledge at rest courtesy of the client-side encryption, even if most mail ends up being sent unencrypted to non-PM users.

[Anonymous Coward]

Re: identity and encryption

You can, because their emails are sending an "here's my public key, please use it" meta data in their outgoing emails, inviting the encryption! *Subsequent* emails are then using that key.

Initially that's only Thunderbird users sending out the public key in email meta headers.

Mobile email apps that don't support inward encryption wouldn't be sending the public key and would not be inviting encryption!

And the only initial recipients who would do the upgrade would be Thunderbird users, because only Thunderbird initially supports that meta-header.

So thunderbird to thunderbird accounts would be encrypted. Mobile app to thunderbird and thunderbird to mobile app would not.

I'd expect others to then follow suite and use the key in the meta data.

Uprgrading thunderbird to mobileapp and mobileapp to thunderbird too.

[rg287]

Re: identity and encryption

Mobile email apps that don't support inward encryption wouldn't be sending the public key and would not be inviting encryption!

...

So thunderbird to thunderbird accounts would be encrypted. Mobile app to thunderbird and thunderbird to mobile app would not.

That isn't how email works. Email is sent to an MX server/inbox - not to a client. How the user collects their mail (POP/IMAP to a client, or webmail) is then irrelevant and entirely outside the control of the sender.

For sure, TB could embed a flag and a public key inviting the use of PGP. That's fine, and then your correspondent's TB client would send you encrypted mail by default. But you would not then be able to read those encrypted messages in your mobile app when fetching them via IMAP.

My correspondent's TB client may have received a TB PGP flag, but they're not sending emails to Thunderbird - they're sending them to my inbox, where I might collect them via TB, webmail or mobile app. The sender has no control over how I access my inbox, but of all the possible methods only TB would be able to decrypt them by default. I would have to perform additional configuration or even change mobile app to read my mail anywhere else.

This is not insurmountable - as I say, there are PGP-capable mobile apps which you could import your (and your correspondent's) keys into. It's definitely doable, but to turn it on by default is going to be a breaking change for many users.

[Anonymous Coward]

Re: identity and encryption

"That isn't how email works. Email is sent from my server to your server. How you collect that (POP/IMAP to a client, or webmail is then irrelevant."

No, email is sent end to end, it passes through servers along the way.

Wanting encrypted email that can also be read by software that doesn't support encryption, be it mobile app or webmail is to want encryption backdoored.

Wanting encrypted email that can also be read by software that you didn't give the private key to is to want the encryption backdoored.

What use would end to end encryption be if a webmail client can log in and see it unencrypted. Your mail provider can read it on their servers in order to serve up that webpage?!

What use would end to end encryption be if a mobile app that doesn't support encryption and doesn't have the key yet can read the email anyway?!

It would be backdoored encryption.

It would not be end to end.

There is a case here, where you configure two devices to get access to those encrypted emails, both must support encryption obviously, both must have the private key, obviously, but that case is "copy the private key to both devices just like you copied the account password to both devices". i.e. its a trivial non-case. If you wanted only your home computer to be able to read encrypted emails, you wouldn't give your mobile device the key!

@"This is not insurmountable - as I say, there are PGP-capable mobile apps which you could import your (and your correspondent's) keys into,"

Foock PGP, 21 years of failing to encrypt emails because its a confused mashup of identity revokation and key management.

If I give you an email address with a key then encrypt it.

Email me at [e-mail]?key=jknidfuweiufhwieuhfiwuehifuwheiufwjhbsbcaysyatuyscas

A million deflections, a million attempts to confuse the issue, if you trust my email address, then you trust the public key that came with it equally as much. Or not, because it doesn't matter, trust will build up over time.

[DuncanLarge]

Re: identity and encryption

> No, email is sent end to end, it passes through servers along the way.

That is incorrect.

Email is sent point to point. Usually each point is at each end but if there is a server in-between you, you are forwarding your email TO that server where that server will initiate a separate connection to move it onwards WHEN it decided to do so.

That means that the email may be stored on that server for later delivery.

That is not end to end.

[Anonymous Coward]

Re: identity and encryption

Sorry, all oubound email from my network passes through an smtp proxy in a dmz thats only reachable by smtp from the mail systems and only reachable via ssh from the management systems. Once it reaches the host in the MX record for the recipient domain, I have no way to know if that is a 3rd-party anti-spam/av provider or their Exchange bridgehead server or an smtp relay in their DMZ.

[DuncanLarge]

Re: identity and encryption

> will automatically be encrypted after the first email exchange.

That can be abused, also it wont be used as there are loads of email clients and you basically need this in all of them.

I use Signal on my mobile for sending SMS and if I even find someone in my contacts who uses Signal too I can send secure messages. However I doubt I will ever find another Signal user as everyone else is still using Whatsapp et-al, who also implemented the Signal protocol. ow if only we could trust they implemented the Signal protocol properly and honestly, then we could have Signal and Whatsapp interoperate.

That would be great.

> Without the need for a third party key holder

There is no third party key holder in PGP. Well there isnt the NEED for one. Put your public key on your website, attach it to your unencrypted emails. Anything will do. The savvy users will then confirm your key is valid while more trusting users will simply TOFU. The key servers are useful only if the owner of the keys bothers to use them, which is probably a good idea as it allows key revocation.

> I do not like third party key holders

There arent any, but yes I dont like them either. Keyservers are not key holders, well not how you think and they dont do any tracking (well they could track you based on browser fingerprint). What you are thinking of is key escrow, where you must give up your private key.

> I do not like any protocol with a "revoke"

Why? If my key has been compromised and I'm no longer in control of it then I most certainly want to tell anyone who is sending me encrypted stuff not to use that key. I also want to have those people know that the email I sent them could not have come from me as I revoked the key, so when "I'm" telling my stock broker to transfer all my shares to some guy in South Africa maybe they will think that its probably best to not do that. Or maybe "I" send my solicitor who has never seen my face a scan of my driving license for proving ID on a house purchase.

Unfortunately no solicitor I looked at when I bought a house in 2012 used PGP/GPG so I had to send a colour scan of my ID documents IN THE CLEAR FFS. I seriously would have preffered to FAX it. Oh well, my risk to take. And no, no encrypted zips either, I only fond out about that limitation while in the middle of exchanging contracts.

> Want to change your public key? Then change it. People you communicate with will get a big fat warning that something is wrong because the key has changed. That's as it should be!

Thats how it is.

[just_some_dude]

Re: identity and encryption

You seem pretty fired up about this. Perhaps if it's really important to you and you think your proposal is air tight then you should share it with the Thunderbird devs rather than on an anonymous comment section:

https://thunderbird.topicbox.com/groups/e2ee

[Hubert Cumberdale]

Re: Encryption should be automatic

Yeah. This is most people's understanding of PGP.

[DropBear]

Re: Encryption should be automatic

Re: your link: "Error 503 certificate has expired" - is this some kind of meta?!?

[big_D]

Re: Encryption should be automatic

Without some sort of independent key verification, sending the public key is pointless.

A man-in-the-middle just need to intercept the email, remove the senders public key and put theirs in and sent the email to the destination. The same on the return leg.

Both ends believe they are sending encrypted emails that only they can read, the man-in-the-middle can happily read along.

* And also notice that Google monitors its public keys, which is how they spotted Symantec issuing fake certificates, but you do not. You would not be aware if the 'trusted' keyholder starts issuing a different public key. PGP was never adopted because it is flawed.

Issued SSL certificates are very different from how PGP works.

[Anonymous Coward]

Re: Encryption should be automatic

"A man-in-the-middle just need to intercept the email, remove the senders public key and put theirs in and sent the email to the destination. The same on the return leg."

The window of opportunity for that is 1 email exchange. After the first exchange of emails, both are upgraded to encrypted. So man-in-middle cannot substitute his own public key in the encrypted email.

In contrast to the public key holder, if I control the public key holder, I can swap it the public key anytime that I am in a position to also intercept the email between the two. So I no longer need to do this right from the get go. I no longer need to go back in time and intercept that initial exchange, I no longer need a time machine. I no longer need to do it evertime for every exchange or the users will be warned their comms are man-in-the-middled.

"Issued SSL certificates are very different from how PGP works."

Both suffer the same "trusted third party is actually a trojan organization" flaw. Even without attempting the intercept, you are still notifying this trojan organization each time you exchange encrypted emails with someone. It screams "LOOK OVER HERE THIS COMMUNICATION IS ENCRYPTED". Your PGP client screams that regularly whenever it fetches the key and looks for key revokes from the trojan organization. Both ends scream it, giving the trojan organization meta data. You're also opening up all manner of attack vectors to state level bad actors who could control that trojan organization AND your internet connection at the same time.

The Symantec scenario.

[Anonymous Coward]

Re: Encryption should be automatic

"The window of opportunity for that is 1 email exchange. After the first exchange of emails, both are upgraded to encrypted. So man-in-middle cannot substitute his own public key in the encrypted email."

They can sabotage subsequent e-mails between the two, making it impossible for any party to decrypt. Barring paranoia or the like, the most likely assumption between them will be corrupted keys, necessitating a new key exchange, and this time Eve's ready to sniff it because she's the one who triggered it.

[chroot]

Independent key verification

It does not have to be a third *party*, if that is what you mean by "independent", but there must be a way to verify the keys, by means of fingerprints, hashes, ascii-art, such as used by SSH for example. A different (independent) communcation channel is required for that.

[Anonymous Coward]

Re: Independent key verification

chroot, let me point out that in the system I'm proposing, you build up trust over time.

The first email exchanges, are unencrypted and not trusted.

After that, emails are encrypted, the longer you exchange emails with the same key the harder the man-in-the-middle has to work to keep intercepting and swapping in their keys each and every time. So trust is built up over time.

Suppose, you no longer use your backdoored home-fibre home network, and instead use a 3G connection? Now your man in the middle attacker has to intercept that 3G too.

Suppose you visit a hotel, use their wifi? Your man in the middle attacker has to intercept that too.

One failure to man-in-the-middle means the recipient is alerted to the attack.

In this case an independent channel is not used, its just the accumulation of time. But you can always just mail/post them a USB key, or better still hand them your public key on a USB drive. Send it via another channel. The attacker would really have to catch each and every possible adhoc exchange of that public key!

You could post it on a public website even, or on a public forum.

Here is my email address: "[e-mail]"

Here's my public key : 9028unkjcdsiuwde8hfwoif9wo8yef982wiu2ij2398fyw97ehfwek;fwkepwp9ef

Now your man-in-the-middle attacker has to intercept the elReg too, and Google too, because Google is indexing the websites and searches should bring up that key on this page in elReg. And all other search engines need to be intercepted.

* That's not my public key because Thunderbird has not implemented it.

I'm shopping around for a new trading account. I did an email exchange over about 6 pairs of emails. They asked for further documents which I sent. I know damn well those emails are on some attackers server, even if the link between each server is encrypted, there will be at least one of those links back-doored.

If both of us had Thunderbird and this encrypted system, that link would have been encrypted after the first exchange, and those id docs wouldn't be sitting on a state level bad-actor's server.

[big_D]

Re: Independent key verification

Agreed. Poorly formulated on my part.

[Mage]

Re: Independent key verification

Initial key distribution really needs a separate channel and no identification of what the message is for, but known identity of both parties.

It's been the the problem of every system ever. The Asymmetric system using public and private keys is a part solution.

[Anonymous Coward]

Re: Independent key verification

"Initial key distribution really needs a separate channel ...known identity of both parties."

I disagree. You should not have to hand over your id to a 'trusted' third party to be permitted to encrypt emails and you are introducing an attacker into the conversation. This 'trusted' third party.

The message you're sending is: "Here 'trusted third party' have my id, I'm giving you a heads up that I intend to encrypt emails, so you can decide if you want to swap out my public key ahead of actual email exchanges".

Send the public key over the first email and ever email after that. The only identify that matters is the email address. Sure [e-mail] might not actually be a slappy slut, but why should third parties other than you and slappy slut be allowed to view the emails?

Sure an attacker could intercept that first exchange of keys, and man-in-the-middle that conversation. However they'd need to intercept all key exchanges by all routes from then on, in order to not be found out.

Identity is not encryption.

Linking the two is adding a trojan horse to encryption.

[Anonymous Coward]

Re: Independent key verification

"Sure an attacker could intercept that first exchange of keys, and man-in-the-middle that conversation. However they'd need to intercept all key exchanges by all routes from then on, in order to not be found out."

A state-level adversary, like China, potentially has that power AND the motivation to go Big Brother.

[Twanky]

Re: Independent key verification

Two things:

1) How did you get to hear about my other e-mail address?

2) Last I looked all MS 'service' based e-mail accounts mangle the content so that SMIME encrypted (or signed) content fails to decrypt/verify reliably. Does PGP survive MS' tender handling?

[DuncanLarge]

Re: Encryption should be automatic

Correct, the MITM has to hope you dont verify the key validity outside of that conversation too.

How the hell you got 5 downvotes just shows that hardly anyone seems to understand decades old technology!

Even those who know how TLS works should be able to understand a MITM attack.

Its very basic stuff.

[Doctor Syntax]

Re: Encryption should be automatic

"A man-in-the-middle just need to intercept the email, remove the senders public key and put theirs in and sent the email to the destination."

Or just spoof the email address. How many people actually check the source of the email?

[DuncanLarge]

Re: Encryption should be automatic

WTF are you on about?

The key servers are not involved in encrypting the message. They just let you find someones public key and there are plenty of other methods to do that!

One very modern method is to serve your keys via DNS.

The significant issue with public key crypto is the building of the "web of trust". Technically its optional as you can confirm the key fingerprint and mark the key as trusted yourself or you can opt for a TOFU (Trust On First Use) method which if you are careful to tick your specific boxes and not simply do it without caring should be adequate for most people / situations.

SSL sorted out the web of trust by implementing the third party infrastructure you seem to be thinking of. PGP doesnt have that, its totally independent and only as strong as those who use it incorrectly.

[Anonymous Coward]

Re: Encryption should be automatic

"The key servers are not involved in encrypting the message. They just let you find someones public key and there are plenty of other methods to do that!"

I mostly agree with your comment, but I disgree with the "web of trust". Perhaps I'm wrong here, but I assume that lots of public key servers are government run. They're simply logging each and every IP that queries a public key.

"Hey IP 00.00.00.00 is sending an encrypted email to [e-mail] because its verifying or requesting the public key, is this something we should target?"

By implication, a server that wants to track public keys has an interest in emails using public key encryption!

There simply is no reason a user should trust a "web of trust". They have the email address, in theory email is sent encrypted, at least server to server. What's missing is end to end encryption.

The email exchange should also exchange public keys and Thunderbird should upgrade the sending and receiving of emails using those keys when it has them, automagically to end to end encryption. It should also track and monitor those keys themselves for changes to alert the user of man in the middle attacks.

No meta-data leaking, no intervention needed by the user. They should never see the encrypted version of the email, it should be done transparently to them.

[Doctor Syntax]

Re: Encryption should be automatic

"Thunderbird should sent a public key with every email in the meta data."

How many public keys can HMRC and IRS have?

[Twanky]

Re: Encryption should be automatic

If only they would use Thunderbird.

Most e-mails from HMRC are automated and simply say 'login to read the message we sent you'.

The ones that ask you to 'click here to login to read our message to you' are certainly not from HMRC.

The ones that say 'we've issued a tax refund to you. Click here to claim it' are, of course, completely genuine.

[JakeMS]

About time..

This is a little late for me to be honest, I switched from Thunderbird over to Gnome Evolution a few years ago now. Don't get me wrong, in many ways Thunderbird was great, but over the 6-7 years or so using it I grew tired of trying to find and add add-ons that make basic functionality I needed work.

A few things annoyed me about thunderbird at that time

- Contact sync was terrible, if you wanted it to work properly, with say, Zimbra or OpenXchange, you needed an add-on for that.

- Often those add-ons would break and delete your contacts (Grr, but thank you for backups..)

- Lighting calendar/task sync worked okay, but again it's an add-on and often broke.

- The PGP add-on actually worked well, but still.. an add-on.

- If you have large amounts of IMAP mail coming in, sometimes Thunderbird would get "stuck" while syncing.

So, after dealing with these problems, and trying to keep add-ons to match the current release for several years, Mozilla changed the addon system which broke my contact sync add-on entirely. So, yup. Decided at that point to look at others. I think Thunderbird would be great if you're a gmail user, there are lots of addons for that.

But if you don't use Gmail, and like me use mailbox.org (previously fastmail, moving away) and Zimbra (self hosted, business) - then Thunderbird often falls short.

I ended up choosing Evolution because, as yet, it hasn't broken (contrary to most internet posts) and supports all the syncing out the box, has built in PGP, and as yet I haven't needed to install add-ons or "change" anything to make it work. It just works, and it works well.

Sure, it's GNOME based, but it works well on my XFCE desktop, and it's actually got more stable, not less, over the time I've been using it.

But before I get tons of downvotes for not using a Mozilla product, I'm still a Mozilla user! I still use Firefox (With several addons....) :-D.

[Mage]

Re: About time..

I moved from Firefox to Waterfox simply because of GUI stupidity. They are slowly breaking the Thunderbird GUI. I may try Evolution. I had to get a plugin for export as that vanished ages ago.

[JakeMS]

Re: About time..

Waterfox sounds good in its features and original goal, but I'm a little paranoid about the fact it is now owned by System1, a US advertising company. I'd be worried about it starting to collect data (even if it isn't) - So for me that feels the same as Chrome (privacy wise).

[David Roberts]

Thunderbird only?

I have diverse systems with diverse clients and diverse email addresses.

I use Thunderbird on PCs because it is good for looking in SPAM folders for emails the few remaining POP3 clients aren't seeing.

I have some legacy Windows Live Mail clients because they organise multiple email accounts in a much more friendly way than Tbird.

I use K9mail on my phone and tablets.

I want all devices to be able to access all email accounts, not have to go to a specific device.

When something goes bad in email the standard way to resolve it is to go to the provider's webmail to confirm via another route what is actually on the server.

So any encryption strategy has to work with the above clients, plus Outlook (Hotmail), Gmail, Virgin (NTL) and BT web interfaces.

Possibly one reason that email signing and encryption never really took off, despite being more or less standard product since the '90s.

Oh, and being into PKI I once bought a certificate to enable secure identification with HMRC. Didn't renew it because it cost money and the non-PKI method worked and still does. Whatever happened to the personal certificate?

[Anonymous Coward]

Re: Thunderbird only?

Then you're stuck with the lowest common denominator, BT Web interface.

i.e. no encryption.

"Possibly one reason that email signing and encryption never really took off, despite being more or less standard product since the '90s."

Nah, its because they linked 'signing' and 'encryption'. So they got nothing. People who want privacy, by implication, will not trust third party key servers with their details.

[Snake]

Re: Thunderbird only?

This exactly. Implementing encryption is a waste of time as the vast, vast, vast majority of recipients will never use it themselves. It doesn't matter what you want in this instance, for the fact that you are attempting to communicate with others means that you must synchronize yourself to THEIR requirements.

"Thunderbird implements PGP 21 years late" is less important a statement (in regards to Thunderbird's developers) than what should also have been covered:

"Thunderbird 78 implements 'pill' support for multiple email recipients. FINALLY. Decades after everyone else."

[Doctor Syntax]

Re: Thunderbird only?

"Possibly one reason that email signing and encryption never really took off, despite being more or less standard product since the '90s."

Two reasons, I think.

One was because it wasn't part of the email protocol so it had to be a lot of added on bits, not just to the clients but a whole added on separate key distribution system.

The second was that because of one very few people used it. If you didn't know anybody who used it you didn't need to go to all that trouble to add it yourself and you not using it meant that people emailing you didn't need to use it and because they didn't you didn't either. Critical mass hasn't been achieved.

[Dazed and Confused]

Re: Thunderbird only?

"Possibly one reason that email signing and encryption never really took off, despite being more or less standard product since the '90s."

Another reason was that one of the people I was experimenting with encrypted email back in the 90s was in France and it was illegal to use encrypted email (or just about anything such as GSM A5/0 "French Mode"). So he was advised to stop.

[A.P. Veening]

Re: Thunderbird only?

Yup, one of the easiest methods to decrypt an encrypted hard drive under Windows is telling Windows the computer has moved to France.

[Anonymous Coward]

Third parties?

There seems to be some confusion here. Exactly what third parties are required for GPG encryption?

It is precisely the flexibility in your trust model that differentiates GPG from say X.509.

[P.B. Lecavalier]

Why Not Use PGP?

Why not use PGP? I would be open to it, but never managed to get any encrypted exchanges. There are practical obstacles in terms of requirements on the recipient:

1. Must know a thing or two or be willing to learn.

2. Must be willing to bother setting that up.

3. Must be using compatible application/process. If using Gmail application on phone, it won't work.

At that point most people would ask you to get in touch with them through Facebook (shudders). It's already hard enough to get people to simply reply to your messages, if they even read it.

[Gene Cash]

No thanks

With current Mozilla developer levels of skill, I'd expect Thunderbird to send my private keys directly to China. I trust them to be about as competent on security as Trump is competent being president.

[Geoffrey W]

I'm a bit peeved about the loss of Mozilla Send. I used it quite a bit for a while and will miss it if I need it again. I don't care much for Dropbox, and that MS one was awful last I looked. Google...not in a million years.

[JakeMS]

Tresorit could be an option for you, but it is on the expensive side. It's end-to-end encrypted, and based in Switzerland however, and has a client for all platforms (Linux, Mac, Windows and Android/iOS).

[Anonymous Coward]

Couple of points.....

1. Article mentions thunderbird version 78.2.1. My (up to date) Fedora 32 install has version 68.11.0. Makes you wonder!

2. Reading the comments it becomes clear the PGP and the public key server infrastructure MIGHT be secure....but is pretty hard to use (PHTU).

3. Some of us use a private cipher - single C program, single directory, text only messaging. It might be "poor" or "weak"....but Eve will still have a hard time!

*

08dA1Yob09L=1gnE0udB1WZO124w0Luz0$O701lX

1Wlj0sAA0RPI0zza0Qkr19QQ1d1s0Mux0SMv12Sc

0B730e2R1HA81WSO0XEy0M2R0yWw1jCN0AXo1PJu

189=10$E11pz1HIg1PR70Fy$1ery01LK1a3J1JHj

0YyI0$sd0xPo0nml0gcm0kms0sEv0gtB0GK41G8P

0kM70P9j1AQt0$FT0JP$104h0xo50h161Ls=121K

19yC11MH

*

[Charles 9]

Re: Couple of points.....

Maybe Eve, but not Gene, who will have ways of getting to your cipher: either directly or through you.

[Anonymous Coward]

Re: Couple of points.....

> My (up to date) Fedora 32 install has version 68.11.0. Makes you wonder!

The Thunderbird people asked distros to hold on releasing the latest version until they iron out the (rather numerous) bugs in their stripped down version of Enigmail.

Frankly, why didn't they just keep using Enigmail which we were all happy with, I do not understand.

[Anonymous Coward]

What a shame,, "send" was dead handy, anyone know of a similar programme ?