Migrate Off Proton Mail

Proton Mail Ignores Security

A few days ago, there was a report from 404 Media about some internal drama at Proton. Proton’s main product is Proton Mail, an email service whose selling point is security and privacy. The report says Proton’s CEO pushed AI usage so hard that he wanted to “re-interview” all the employees about their AI usage and fire the ones that don’t meet the bar. And some other behaviours like insulting an engineer who wants to have enough time to properly test the code before releasing: the CEO called the engineer “bullshit” and “loser thinking” in a Slack channel. The “re-interview” plan backfired and the CEO eventually cancelled it, but he never apologised for it, just “acknowledged” it.

This is such bizarre news to me. I don’t oppose AI usage for coding. I even built my own AI coding agent so that I can use it more efficiently. But pushing AI so hard to ignore security, especially for a company whose selling point is security and privacy, is just so stupid. I cannot trust the company anymore, so I just migrated off Proton Mail to another provider. And I urge you to do so too if you are using Proton Mail.

Not The First Sign

I actually wanted to migrate off Proton Mail a long time ago in 2024, before the AI era. The trigger was a problem in Proton Bridge, software that is needed to use a third party mail client with Proton Mail. One day, when I upgraded my system, I found Proton Bridge could no longer be started. After some investigation, it turned out to be a problem caused by them using an older version of Qt. There was already an issue reporting it. (The project seems to have disabled the issue feature on GitHub, but you can still see it on Wayback Machine). During the discussion, it turned out to be a larger problem than simply a dependency incompatibility: the Qt version they depended on had been end of life for more than a year. This means a critical dependency they are using hasn’t received any security updates for more than a year, including in the releases for their officially supported systems.

What’s worse is the developers’ attitude to this problem. They continuously deny this is a security problem, even in a PR created to fix it, and downplay it as an incompatibility problem for the systems they don’t officially support. I couldn’t believe this was from a company whose whole selling point was security and privacy, so I decided to migrate off Proton, but didn’t get motivated enough to do it until now.

It Is Easy to Migrate Email Providers

It is very easy to migrate email providers once you decide to do it, if:

1. You are using your own domain.
2. The email provider supports third party email client.

Point 1 needs money to buy a domain, and very likely needs a non free tier subscription from the email provider. But I think the money is totally worth it to avoid the hurdle of updating emails for all the online accounts and contacts.

Point 2 only matters if you want your old emails in the new provider. With Thunderbird (and I believe it can be done in other mail clients as well), you can just log in to both accounts, then copy all the old messages to a folder in the new account.

Supporting third party mail clients seems to be a trivial thing which almost all email providers have been doing since the beginning. But that’s not the case for the ones that provide end to end encryption. End to end encryption means the messages are encrypted between the sender and the receiver, and the server can never see them. This requires the clients to be able to encrypt and decrypt messages with a custom protocol, which third party clients don’t have. Proton Mail supports third party clients with Proton Bridge: a client that sits in between the third party client and Proton’s server so that it can do the encryption. Many other end to end encryption email providers don’t support third party mail clients at all. But it turns out, end to end encryption is not really that useful, and I would trade it for third party mail clients if I must choose one.

End to End Encryption in Email Is Not Very Useful

Most email providers that support end to end encryption come with a requirement: both the sender and the receiver need to use that provider. This is really a hard requirement: I don’t think I even have a single frequent contact of mine using Proton Mail or any other end to end encryption email provider. This means almost all of my email communications are not end to end encrypted at all.

There is already an end to end encryption protocol for email called OpenPGP, and Proton Mail says they also support end to end encryption when the other party uses it. But OpenPGP is still something that’s hard to set up and use correctly. So I think the best mindset is just to treat email as a not so secure communication channel, and use other things like Signal or self hosted ones like Matrix/Element if security and privacy is really needed. Interestingly, while Proton Mail says it uses OpenPGP, you still need Proton Bridge to use a third party client.

Most importantly, even though theoretically you don’t need to trust the provider with end to end encryption, in practice you still need to put a lot of trust in it, because they also provide the clients, which do all the encryption. It’s a little bit better if you can freeze to a client version that you’ve already audited (which is very hard, and I don’t think any normal user does this in practice). But for emails, it’s often that you need to open the web app, where the server can load whatever client code. So essentially, you still need to trust the provider a lot, and this removes most of the advantage of end to end encryption. The reason I migrated off Proton Mail, for example, is that the trust is broken.

What About Self Hosting an Email Service?

To fully take back control of the email service, one option is to selfhost it. There are already many projects around it and I see many people do it without problems. One concern many people have may be the stability. One way to improve the stability is to have a backup email service: put both the primary and backup email service into MX DNS records, with the backup one having a lower priority. This way when other servers cannot reach your service at the primary MX record, it will try other ones with lower priority. And you log in to both your primary and backup accounts in your mail clients to receive emails from both.

Another concern is the IP reputation: many email services will ban IPs without a good reputation to avoid spam. That means it’s better not to use a residential IP that can change. However, many VPS providers also ban outbound port 25, which is needed to send email. There is a workaround by using an external SMTP provider, but that means you still need to depend on an external service.

At the end of the day, at least for me, I think it isn’t really worth the hurdle to self host a mail server. I chose Mailbox.org in the end. I cannot say if I can recommend it for now since I just migrated to it and I’m still evaluating it.