They also don’t care about locking you permanently out of your own e-Mail with no warning, for no reason, with no recourse.
Honestly - there are far better options out there. They’re not in anyway a responsible enough business to manage an e-mail service. It’s run more like a hobby project than critical infrastructure.
What are those better options that HN likes? I just switched all my accounts to protonmail, but stories like this make me want to reconsider. The fact that they won't allow me to set up a forwarding rule in case I want to switch again doesn't help.
HN is hooked on fastmail which is a great provider to be honest. Have a look at mailbox.org which is in business since the 90s too. Avoid the privacy trending providers promising you to encrypt your emails.
First of all, bring your own domain. That way you can just point the same address elsewhere if you need to switch again without having to deal with forwarding.
edit: As mentioned by a sibling comment, my email is currently on Fastmail, zero problems.
Sounds reasonable. Any gotchas there? I already read that vanity TLDs are bad, obscure countries' TLDs are bad, and even .eu may be unstable. Which are good services that can sell me an .org or .de domain for a fair price?
.eu domains may only be registered to a person or entity that exists within the EU. As soon as Brexit crystallised any British person or entity owning a .eu domain was unable to renew it unless they had an address they legally occupied within an EU country.
I know a few companies who rented a small amount of office space in France so that they could retain their .eu domain.
I guess you can get a .eu domain for ten years. So that could be an option to make sure you have enough time to shift to another domain should your country leave the EU too. Assuming, well, that the EU won't take it away from you before the expiry date just because you lost your EU residence.
I have heard people say "vanity TLDs are bad" but never experienced it myself.
I have email addresses at .co.uk, .digital and .social never had deliverability issues with sending or receiving.
When I worked at a large (100m emails/wk) email service provider the key thing was sending IP reputation followed by things like DKIM and SPF DNS records on the sending domain.
IP reputation would be an issue if you self hosted your email, but using a reputable provider such as tutanota and fastmail should pose no issue.
Speaking from personal experience, if you have to spell your domain for people, you will regret it!
Also - have separate email stacks for communications and operations. Like it or not, your email is a low-friction way to get access to many of your other accounts, and maybe even a good way to LOSE access to some of your accounts. Your operational email domain should never be published, only used to register accounts and maybe do alerting, etc. You would whitelist senders. You would never use it to say anything, or associate with anyone, that someone might one day find offensive or controversial.
I wouldn't go for the cheapest price, I'd go to some established place in your jurisdiction with a wider product range and size, that targets small businesses. You have a chance to get some useful hotline, and things can be 'integrated' and are more likely to work, i.e. host your website - book the domain example.com - book a managed nextcloud and have it be at cloud.example.com etc.
Their email service is likely to have some credibility from the global anti-spam force. They probably have the budget for best practices and reasonable security. As you mention .de domains: The online legal text generators for Impressum/Datenschutzerklärung are likely to have the correct text fragments to use for larger vendors. Overall they just have to uphold some level of reputation I hope.
Why? They aren't offering an end-to-end encrypted service, so as far as I know Australia's laws aren't much worse than, say, the US' laws in this regard.
I don't need a custom domain anymore and I find it trivial to change email addresses. I can use 1password to locate accounts, easily migrate, apply a tag, and work through the change over a few hours. I typically change email every 2-3 years and it serves as a good way to review security settings/change passwords. Modern email providers have mailbox porting tools, and they work fine. I use to like having a domain, but dunno, for a privacy nut, seems more secure to not use one.
I was being a bit pedantic but ... a domain registrar could be an attack vector, its not as anonymous as something like proton/tutanota, not beholden to ICANN, if you use an alias related to your domain it could be tied to you. If I give up the domain in the future, it could be used against me in a social engineering way.
FWIW, I went from gmail -> protonmail -> fastmail, and have been very happy with fastmail.
protonmail is great as a secure disposable email, but as a go-to daily email service I found it too difficult to manage. Hard to use other email clients due to requiring this bridge, and their mobile apps and web guis are just not up-to-par with other offerings. Being able to use any frontend on mobile (and not deal with complicated proxy setups) was my biggest issue.
Using a custom domain has made the switches easier, as I don't have to tell anyone to update their contacts or worry about forwarding. Just exporting/importing, change some MX records, and I can switch providers any time.
I did the same thing. Custom domain with Protonmail. Ended up frustrated that I couldn't set up forwarding rules and alike. I realised I didn't need the privacy as much as I needed features.
Swapping from Protonmail to Fastmail was super easy. Exported all my email, imported into Fastmail, and swapped over the DNS records. Took me a couple of hours in between other tasks.
I’ve been a Fastmail user for about a decade (I just checked; wow!) and am very, very happy with them. I wish more companies were like them. The service is very reliable, the product is great, their support is amazing and very kind. A lot of companies get distracted by big pivots and hyper-growth ideas, while companies like Fastmail focus on doing their main job very well.
Today I've just given up on Protonmail, the Bridge is a POS. When things were reliable, I was ok to jump through hoops in maintaining a separate app, but I cannot be bothered any longer. Just set up a Fastmail account to see what it's all about.
I uses FastMail after I discover this serious issue about Proton.
I would say it work flawlessly and their web mail client is super fast; even faster than Gmail.
Besides, FastMail exists before Gmail and the people in FastMail are active standard protocol developers like IMAP and recently JMAP (a modern mail protocol will replace SMTP/IMAP, FastMail as a reference implementation), which is good because at least I know they understand the protocol and implement it by themselves.
I'm quite positive on it, nice interface and unique useful features, and it's reliable in my experience. However you have to be ok with its particularities, mainly that it doesn't have IMAP, and it's expensive.
Ultimately it's for people who love their unique interface/features, and don't mind paying so much for email.
I personally use mailbox.org for years now. Granted, I don't have remotely the usage mentioned in the linked issue and I know users that aren't very satisfied with features like the integrated office webapp, but it does everything I need (emails & calendar sync) and I haven't found a reason not to trust them.
Originally my reason to choose them instead of Protonmail was that Protonmail only works with their official client, which is a far too limiting dependency in my eyes.
I think it's worse than that - they are well into the stage of growth where privacy and reliability are just marketing deceptions. Some other recent data points:
- Yesterday they decided to throw up a big modal advertisement for a bulk plan at login, even to paying customers. Note that they chose NOT to do this for the aforementioned privacy-weakening change. - https://old.reddit.com/r/ProtonMail/comments/yj5m59/pm_visio...
That changed setting should have been a huge story. I've paid for ProtonMail for like 6 years now, and this was the most disappointing thing I've dealt with.
Thank you; it's frustrating that this isn't being covered more widely, but good to know that there are people who see the problem. If nothing else, don't give up trying to inform people!
Randomly, I get locked out of my Protonmail webmail interface by an hCaptcha.
This in itself isn't a problem. The problem starts because I can't actually see the captcha images. So in order to get at my email, I have to provide hCaptcha with a third party email which isn't protonmail, and enable third party cookies and/or install a browser extension for them to set an "accessibility cookie" to get past the captcha.
And, well, nobody wants to do anything about that either. I'm sorry, but that doesn't seem reasonable to me.
This sort of reaffirms my belief that UIDs are not sufficient for syncing mail. Emails should be hashed and synced by the hash which would solve other issues, like being able to redownload specific messages that may have got corrupted locally.
Even so, isn't this a violation of the IMAP standard, which says that UIDs are, by design, not permanent identifiers, but UID + UIDVALIDITY is? (I don't know much about IMAP.)
It is definitely a recommendation, but UIDVALIDITY just checks the folder from what I understand. Hashing the entire message would be the best way from my understanding to sync messages.
> The unique identifier of a message MUST NOT change during the
> session, and SHOULD NOT change between sessions. Any change of
> unique identifiers between sessions MUST be detectable using the
> UIDVALIDITY mechanism discussed below. Persistent unique identifiers
> are required for a client to resynchronize its state from a previous
> session with the server (e.g., disconnected or offline access
> clients); this is discussed further in [[IMAP-DISC](https://www.rfc-editor.org/rfc/rfc3501#ref-IMAP-DISC)].
so, "SHOULD NOT", but in practice it's really hard to make {UID, UIDVALIDITY} assignments persistent and unique, so IMAP servers don't, and as you can see, they are allowed to not.
I.e., it's perfectly compliant to generate a new UIDVALIDITY for each session and then assign UIDs to emails in folders when you open them
In practice the odds can be astronomically low, as in lower than the odds that an asteroid collides with Earth right now and the entire humanity becomes extinct. But only for hashes without known vulnerabilities.
For a vulnerable hash like md5, an attacker can find a collision in a few seconds.
I only say this in case anyone reads your message and gets the wrong idea. Currently, there is no feasible preimage attack for MD5. You can easily generate two colliding inputs, but cannot, given a hash, find an input to generate that hash.
And I don't believe that accidental MD5 collisions are something to worry about.
They don't have anything to replace it with yet. They appear happy to leave it in place being buggy instead of removing it and really upset a lot of people.
- a hosted service because host one myself is too much work CAUSED by anti-spam measure by some "self-appointed sheriffs" of the net;
- mail fetched from remote via fetchmail, no messages left on the server, filtered on my homeserver via maildrop, indexed via notmuch, muchsync-ed over SSH to desktop(s)/laptop.
Simple meaning: I'm not tied to anyone specifically (personal domain name) and I own my data. They are also on someone else iron, but also on mine and I use them locally. Composing a new mail is just hitting a key on my keyboard, searching my messages like GMail is another key for search&narrow results a modifier+the same key for notmuch-emacs UI. All mails can be linked on all my org-mode/org-roam managed docs equally.
It's FAR simpler and FAR more powerful than any modern crapware UI, BUT is hard to setup due to the little development compared to the mainstream UI.
Who have a little fetchmail part. I've nerve used getmail, before I've used OfflineIMAP (buggy but support IMAP IDLE) and mbsync. The only issue is fetching from multiple accounts that demand firing up multiple instances, but that's not much of an issue. You just set FETCHMAILHOME before any invocation pointing to the right config dir and set a different --pidfile for concurrent* fetching if you wish so. MailDrop is a (very) little (very) big setup since you need filters for anything if you are not a piler and that take MUCH time. Normally here my suggestion is fetch anything on a zfs volume, clone it, test on the cloned maildir or snapshot and revert after any test until you get nothing in the INBOXes. A slow step at a time you'll add the rest.
If you’ve been using your mailbox (and deleting mail) for a while, have over 50K mails in it now, and see (what you think is) a UID of 51950 on the most recent email, the chances that it’s “U” are extremely low, meaning there’s a gap in understanding or in implementation.
Every time I see that, I’m floored by it. The fact that message IDs in IMAP change when you delete messages has got to be one of the worst design choices in any in-use protocol. I’m flabbergasted by it.
IMAP UIDs are guaranteed to be static and unique within a mailbox and a UIDVALIDITY. They don't just change by themselves while you're working on them because if you do you get this bridge issue. They aren't necessarily message IDs (those exist and are part of a different email standard) but clients shouldn't need them to be. If you delete a message, the ID doesn't normally change because all you do is add a flag.
Many mail clients often have a recycle bin/trash folder where "deleted" email will go. When you click delete, the application lies to you about what it's about to do and starts a move to another folder/mailbox.
This completely ignores the standard method IMAP has for deleting email. You can mark email as deleted but that email will remain stored until you call EXPUNGE (or UID EXPUNGE) on the server to empty the trash/actually delete the message. In other words, a virtual trash folder doesn't need to be stored on the server as a mailbox at all, the protocol already has a solution for this.
There are mechanisms for globally unique mail identifiers, like Message-ID, but those are part of the emails themselves and not the protocol. IMAP deals with a combined primary key of (mailbox, UID, UIDVALIDITY) and that works just fine in my opinion. If the UID ever changes, your mail client will know about this because the UIDVALIDITY changes and the cache needs to be refetched. I see my mail client as a view for the backend data, because that's how IMAP was designed.
To forestall confusion: there are two different ID mechanisms in IMAP.
The first mechanism is message sequence IDs. If you have a mailbox with N messages in it, these messages are numbered 1-N (inclusive); a new message gets N+1; and deleting message, say, 3 causes 4-N to be renumbered to 3-(N-1). Note that the server can be the one to delete the message (say another connected client deletes it), but server-to-client notifications of message deletion can only happen at specified times in the protocol. The client might still have stale sequence numbers when it sends you the next command however, because IMAP is pipelined. And if you think this sounds like a recipe for lots of weird bugs, you are indeed correct in those thoughts.
So what everyone uses instead are UIDs, which are stable IDs for a message (kind of). UIDs are monotonically increasing (a message with UID 100 is newer than one with UID 95, but there's no guarantee that UID 97 exists), and are not impacted by message creation or deletion. One way to think of them are offsets in the underlying mbox file of where the message lives. If UIDs need to be renumbered (... yay mbox), the server changes the UIDVALIDITY which means that previous UIDs are no longer necessarily valid.
The message sequence numbers kind of make sense, if you imagine that IMAP clients are very, very thin clients that don't maintain any local information, and if you imagine that servers are not expected to support two clients connecting to the same mailbox at the same time. But modern email clients need to maintain their own local database of email metadata, which means that the IMAP protocol has become, in effect, a database synchronization protocol, even though it's not originally designed as such (later IMAP extensions added features that made some elements of synchronization much faster).
There's arguably a third: Message-Id. It's meant to be globally unique and comes from the message itself. I don't know how workable it is for email synchronization with IMAP; IMAP servers will provide them (they're just another header) but I'm not sure the client commands exist for a message-id approach to be as efficient or ergonomic.
Message-IDs aren't workable as unique IDs in an email client. There are a few ways where two different messages can end up with the same message-id (e.g., multiple drafts, or the copy in the sent folder versus the copy in your inbox), where the differences are not really relevant for the purposes message ids are used for (e.g., threading).
It's an artifact of IMAP having evolved in the presence of older mailstore technologies like mbox and maildir that couldn't easily accommodate long-term stable message IDs.
It's fine though, as long as the MUA developers understand this and don't expect UIDs to be more stable than they actually are.
I'm pretty sure Proton didn't invent IMAP, and from the protocol log it seems like IMAP insists on the incrementing ids. Probably thanks to it having been designed in the late eighties and early nineties.
I switched a few weeks ago. The process was fine. They have a tool to help you port your mailbox, calendar, contacts. The web client is great. The mobile/android app sucks. The search doesn't work. If you archive an email on web, it wont always apply to the app. The sync between clients is screwy. Gmail is no doubt a better email product but given I paid a year, I'm going to suck it up and deal with it.
I switched from Gmail to Proton Mail earlier this year in an attempt to de-Google. The Proton Mail website and Android app is just about on par with Gmail's. My only complaint is Proton Mail will refuse to load images if something about the host domain isn't configured 100% to spec which is common for non-tech companies such as home utilities. You can only reply from "+tag" addresses, not send outright from them which is a feature of Gmail. Though Proton Mail's email aliases alleviates my need for that.
Since I've used this for years, way before this ticket, the bridge has always been problematic (periodic full mailbox downloads even with the QT version for example), but since the version with the new ui it got even worse, emails coming and going.
Could the title be update to contain the word bridge as the issue is in the Protonmail bridge application and not on Protonmail itself. The entire title is clickbaity, but adding the birdge moves it away from being misleading.
The problem is they've been aware of this very serious bug for more than a year, and haven't tried informing their users. So "Protonmail" in this context refers to the business, and the issues surrounding their responsibility, competence and ethics.
Or it's important, but nobody has the skills/time/familiarity/acceptance from upstream maintainers combo.
Compared to the FOSS origin myths, many huge projects, with tons of end users, including very foundational ones, like GTK+ and OpenSSL and such, are understuffed (or just 1-2 base maintainers heavily overworked, who do 99% of the work and can't take it anymore), and nobody cares or has the time to dive in and fix anything.
Other projects that might have some person interested to bugfix, have maintainers that don't like contributions outside a clique, and ignore bugfixes submitted for years or forever.
So, "any user can fix it" is sometimes just in principle, while actual users than can fix and do fix it are thin on the ground, and othertimes it's just an option for external patches, that will not be merged upstream.
When OpenSSL got and noticed to be critical, it was fixed, funded and also forked tons of time. So open source model works here.
I gut feeling is that Protonmail Bridge is such an obscure project that no one really cares enough, and thus it cannot be “important” or “critical”.
Alternatively, users have an option to change to another system if they are unhappy. Protonmail has no monopoly. But complaining about open source maintenance is not going to change anything. Especially complaining on HackerNews is ungentlemanly.
The complaint is about a payed commercial product having a bug causing data loss going unfixed for over a year with still no fix in sight. That said product is also open-sourced is not really relevant.
Proton-bridge is a premium product you only get by being a paid subscriber. If it is open source, they should not be expecting contributions. One pays to make sure issues like this can be fixed, they don't pay to fix the issue themselves.
You keep saying this but not providing any evidence. I just read the entire issue thread on Github, and yes, you have to use the bridge. (If I missed a comment, please link directly to it.)
"Nobody cares" and "this is a complicated thing that we've spent a year+ building a replacement for" don't seem very congruent to me. That said, it's a rather awful issue for a service like this to have for that long.
I don't think that was the intention of the submitter, but IMO it's significant enough that you providing a link to such an issue would be welcome and appreciated.
Happens occasionally on the mobile app on iOS for me.
I am slowly migrating everything away from my paid ProtonMail account, and I intend to just go back to using a megacorp email... despite absolutely loathing and detesting megacorps. At this point in life, email is simply too important. Notices from government agencies, my accountant, my lawyers, my various banks... I quit self hosting for these reasons (no matter how good I am, I am not full time keeping my self-hosting pristine), and now I apparently cannot fully trust Proton.
For what it is worth I have never had an IMAP export/import go cleanly. Hey offers you an MBOX/vcard export which is quite nice. I just do not use their service because the UI is hideous.
Instead of megacorp, I recommend Mailfence (Belgium) or Mailbox (Germany). There are many other providers which are trustworthy and work well (protonmail is also not that bad but receive a very bad press at every bug).
The only durable solution for email is:
1. Have your own domain
2. Have a copy of all your mailboxes locally (easily done with IMAP).
With that setup, migrating email is only a matter of opening a new account and changing the DNS record.
I moved from Protonmail to Migadu and am happy with them. They support standard protocols and otherwise get out of the way. They also seem to be paying the Sourcehut guys to make an open source webmail client for them, which is cool but I will probably never use.
To clarify because comments (so far) seem to ignore what Proton Bridge does.
Proton Mail is web mail, like Gmail. That part is fine.
You use Proton Bridge as a connector to mail client software.
The thing that’s perhaps unclear is, Proton Mail is end-to-end encrypted email. You use Proton Bridge to walk your secure email beyond that enclave into whatever YOU are running in your userland scenario.
Part of all this is, you’re completely unclear on the concept of secure email the moment you need to use this bridge.
Which begs the question, why would you use Proton Mail if you’re gonna negate its unique value proposition?
Proton Mail is fine. It’s this misguided extension that’s the problem here.
If you’re fine with web mail then this issue doesn’t matter. If you’re not fine with web mail, maybe Proton Mail isn’t really for you.
The bridge is just another client in the sense that any ProtonMail client would need to decrypt emails so you can view them. To be honest, their web client is probably less secure and trustworthy than other mail toolchains you could run locally. So if the bridge was reliable and trustworthy (which it may not be, hence this submission), using it is probably the most secure option.
You're not looking for a discussion, but rather a fight. I hope you find some peace. Understand that not everyone who responds with a counterpoint also downvoted you.
But I'll respond once in good faith - a browser, which is designed to load and run obfuscated remote scripts from quasi-trusted sources, and display complex untrusted HTML mail content, and which is subject to XSS vulnerabilities, will always be inherently less secure than, e.g., mutt. It exposes you to potentially malicious second parties (e.g. ProtonMail) and third parties. This is true regardless of any mitigations and security measures that are also built in to the browser. If you have enough distrust in your threat model to use ProtonMail, you also likely acknowledge the browser's weaknesses.
> Which begs the question, why would you use Proton Mail if you’re gonna negate its unique value proposition?
Because most users don't care about the end to end encryption. They just want to host their email somewhere [1]. And perhaps have it available offline.
All this encryption on everything is mostly turning into security theatre. All mostly because identity theft is so easy in the US. Perhaps that's the problem that needs to be fixed.
Yep, I could see myself using PM just as a replacement for Gmail, since they have a semblance of a brand and reputation in this space—plus at least somewhat privacy-oriented attitude, which is more than many others got.
Well, no, not really. That is the claim that they make but such a thing doesn't really exist, well at least not in the way they suggest. It is e2e if either both parties are using PGP or Proton mail. That is a very small percentage of global mail flow.
If I understood correctly I run this bridge on my computer which connects to the protonmail API, downloads my mail, then decrypts it and starts a local IMAP server, so I can read it with my thunderbird.
The email stays encrypted on the server, and this extension only decrypts it locally like it would happen in the web browser.
> You use Proton Bridge to walk your secure email beyond that enclave into whatever YOU are running in your userland scenario.
Look, if I won’t trust the software which is running in my userspace, I’m doing something wrong anyway. Even if I wouldn’t use this extension, a malicious userspace application would still hook itself into your webbrowser, or simply steal cookies/tokens from your browser’s profile folder and hijack the protonmail session.
> Which begs the question, why would you use Proton Mail if you’re gonna negate its unique value proposition?
If I’m not mistaken with my assumptions at the top, the email still stays encrypted everywhere except on my PC. I don’t trust the mail provider, and I don’t trust protonmail. Protonmail could just change their web app at any moment to upload your second password which is used for unlocking your keys, and you wouldn’t notice. This can’t happen with an extension which doesn’t even have an auto updater.
Anyway, it goes both ways. And some people just want to use their email client, instead of a web app.
Some people want to subscribe to a premium encrypted email provider so they can download that email locally so it can live perpetually in ever expanding sub folders on disk, in plaintext.
Bridge is part of the Proton Mail paid service. They advertise it right here: https://proton.me/mail. It's not unreasonable to say that if you are paying for Proton Mail, you would expect the bridge to work considering they advertise it as a feature
In short: The idea was to move from a custom mail server to a paid, hosted solution. ProtonMail was chosen, with the bridge being used to get mails into a local mail client. Issues with the bridge eventually cropped up.
I've been a paying Protonmail customer for years and recently started worrying about having put my eggs into the Protonmail basket.
/rant
Recent outage issues surfaced some major flaws with the mobile clients, on top of shaking my faith in the infrastructure (though no one can easily stand up to nation state actors so I do not blame PM).
And yesterday I was shown ads inside the web portal, along with a big call-to-action button that wasn't there before to go buy a new tier. Have I mentioned that I have been a customer already for years?
Never used the bridge, but honestly I am not surprised that it may be broken and not receiving the attention it deserves.
It feels like Proton (with its vpn, email and the whole 'suite' they are promoting under the brand) is simply another growth company, focused on adding more and more features rather than on good old fashioned stable products.
I also got this ad yesterday when I opened PM. It's the kind of ad you'd expect from a free tier but not as a paying customer. At first it made me wonder if my subscription had expired.
Do you mean the ad about the Visionary subscription? I'm also a paying customer but I'm OK with these one-time notification kind of ads about the product I'm using. Just don't shove it in my face every time I open it.
I had recent concerns too; between the mobile app not really working well anymore, and their confusing rebrand where I now have to go to a different URL, and these popups, and now this.
Issues with the app:
- notifications sometimes don’t pop up on iPhone. Yes, I have the enabled.
- app can take a minute to load
- when you click on a notification, it opens the app on the previous email you read, while taking a very long time to load the one you clicked on
I seriously hope they refocus on their core product. These issues are new.
I didn't know what exactly is proton mail bridge. This is what I've found:
> Proton Mail Bridge is a desktop application that runs in the background, encrypting and decrypting messages as they enter and leave your computer. It lets you add your Proton Mail account to your favorite email client via IMAP/SMTP by creating a local email server on your computer.
Protonmail doesn't support email clients with POP/IMAP like most hosting companies do. They only let you use their proprietary apps on mobile. Desktop users can log in to the website or use Bridge which is just a hacky way of creating a local Protonmail server that your email client thinks is a hosting provider. I could never get it set up on my machine so I just used the browser implementation. sigh.
I don't know, and it's why I moved off them. Additionally, the Bridge is only available for Windows/Linux/Mac, so if you want to use your own email client on mobile, I guess your only option is to VPN into your home network and expose a bridge instance there or something. No hard feelings, but I can't really recommend them as an email host if what you're looking for is... an email host.
If they offer IMAP, they would also need to decrypt your data on their side, which I'm happy they go to lenghts to avoid.
This is a case of Proton sacrificing convenience for privacy. If the former is more important for you than the latter, there are better alternatives out there.
I think it's sadly a bit of a chicken and egg problem, unless someone sets out to write support for servers (mostly dovecot I assume) and clients (web and desktop).
It would be worthwhile for many reasons not just the immutable IDs. I'd certainly donate to someone showing initiative working on this.
Emails should really be identified by Message-Id (which isn't guaranteed unique, but is very selective) and a hash of the body and a subset of the headers (e.g., excluding Received headers, and maybe using only Message-Id, Date, and From, maybe not even Subject).
A good email store is very searchable, and a good MUA searches email, and a good MAP gives the client temporary (ephemeral) handles for "open" emails.
A good workaround for email hosting is to run an IMAP server somewhere you control, and add it to your mail client. The server doesn’t need 24/7 five-nines or anything. It’s not for receiving mail. It could even be on your local laptop if that is the only place you need old mail, though I keep mine on a dedicated hosting machine in a colo so I can use/search it from my iPhones and iPads and other workstations.
You use an IMAP compatible email service like Proton or whatever to receive and check mail like normal. A couple times per month, move all the messages from the service to your own IMAP server’s folders, instead of the “archive” command that moves them to a different folder on the same server that received them. This is pretty straightforward in Apple’s Mail.app on macOS, and I imagine similarly so in most GUI IMAP clients.
This gives you the best of both worlds: a single set of maildir folders on your own server you can zip or back up with normal tools like rsync or whatever, as well as 24/7 HA reliable provider servers to receive incoming mail at all times in case your long term mail storage machine is temporarily down. You also won’t bump up against provider storage limits.
Self-hosting inbound and outbound email is a drag (though I do it for many of my less critical domains), but a 90% availability selfhosted message storage IMAP service is fairly easy to run. This has the added benefit of a provider hack or legal process presumably affecting only a subset of your most recent messages due to those being the only ones stored there.
I am a Proton and FastMail user (and use the affected software) but I regularly move all the messages from these providers to my IMAP storage server (in different folders) so if their systems fail the blast radius is not “all of my emails going back to whenever I started using the provider”.
Banks also seem to love scolding you when they have the slightest problem delivering you email. (Or also when they see that you haven't loaded their tracking pixels in a while.)
Yea the bridge is quite a hot mess, really.
I use it with Outlook on Mac and there are always syncing issues, passwords missing and i have to re-sync the whole inbox every 2 months or so.
I didnt realise some mail got deleted though, i need to investigate that.
I am a proton customer since 3 years and they seemed like a good bunch but now with all the stuff they are offering it seems like they have lost their way.
There is also no way of integrating the proton calendar into a 3rd party app like Outlook. This feature has been promised forever…
Around 2003 Hotmail deleted half of my emails. I was able to reach an actual Microsoft employee, who apologized a lot (this happened to a lot of users nationally that day), and told me they were gone permanently. They weren't even backing up these emails. Glad that you have had no problem with them. I haven't either since leaving them behind.
IMAP UIDs aren't unique IDs per message, they are an incrementing number assigned to a message that's unique per mailbox ("folder"). Their incrementing nature is part of the standard, a random number would likely break mail clients. They should be stable between sessions but when you move a message back and forth between folders, the UID changes every time.
There are events where the UIDs change, for example when a server needs to rebuild its indices after corruption, but those should be extremely rare. Your server should also show this change when asked for UIDVALIDITY.
A message is defined by (UID, UIDVALIDITY, folder name). If this tuple changes, the message needs to be refetched. It's not the best mechanism for supporting multiple mail clients at once but it's easy to implement at least.
BTW, "unique per-mailbox" utterly fails to be sufficient in a post-gmail labels-as-folders world. That's because folders are lame. But doing better than folders really makes you want a relational database for email.
Not specific to this bug, but I recently setup a hosted Protonmail account with a custom domain and got myself and my wife on it because we do not trust G suite and don’t want all our eggs in one basket.
We both use the native mobile app and web based mail client.
In general it’s useable but the search functionality is useless. I’m hoping they’ll improve it.
253 comments
[ 4.4 ms ] story [ 291 ms ] threadHonestly - there are far better options out there. They’re not in anyway a responsible enough business to manage an e-mail service. It’s run more like a hobby project than critical infrastructure.
https://fastmail.blog/advanced/why-we-dont-offer-pgp/
I don't believe the encryption/key management from a company.
edit: As mentioned by a sibling comment, my email is currently on Fastmail, zero problems.
Do you mean you can lose your domain if your country leaves the EU, or are you talking about other issues?
.eu domains may only be registered to a person or entity that exists within the EU. As soon as Brexit crystallised any British person or entity owning a .eu domain was unable to renew it unless they had an address they legally occupied within an EU country.
I know a few companies who rented a small amount of office space in France so that they could retain their .eu domain.
I have email addresses at .co.uk, .digital and .social never had deliverability issues with sending or receiving.
When I worked at a large (100m emails/wk) email service provider the key thing was sending IP reputation followed by things like DKIM and SPF DNS records on the sending domain.
IP reputation would be an issue if you self hosted your email, but using a reputable provider such as tutanota and fastmail should pose no issue.
We resolved it by pointing clients to use google dns.
Never had similar problems with .com
Also - have separate email stacks for communications and operations. Like it or not, your email is a low-friction way to get access to many of your other accounts, and maybe even a good way to LOSE access to some of your accounts. Your operational email domain should never be published, only used to register accounts and maybe do alerting, etc. You would whitelist senders. You would never use it to say anything, or associate with anyone, that someone might one day find offensive or controversial.
Their email service is likely to have some credibility from the global anti-spam force. They probably have the budget for best practices and reasonable security. As you mention .de domains: The online legal text generators for Impressum/Datenschutzerklärung are likely to have the correct text fragments to use for larger vendors. Overall they just have to uphold some level of reputation I hope.
Example: ionos.de
Care to explain which are those concerns about privacy that you may find when owning a custom email address? Thanks in advance.
protonmail is great as a secure disposable email, but as a go-to daily email service I found it too difficult to manage. Hard to use other email clients due to requiring this bridge, and their mobile apps and web guis are just not up-to-par with other offerings. Being able to use any frontend on mobile (and not deal with complicated proxy setups) was my biggest issue.
Using a custom domain has made the switches easier, as I don't have to tell anyone to update their contacts or worry about forwarding. Just exporting/importing, change some MX records, and I can switch providers any time.
Swapping from Protonmail to Fastmail was super easy. Exported all my email, imported into Fastmail, and swapped over the DNS records. Took me a couple of hours in between other tasks.
Besides, FastMail exists before Gmail and the people in FastMail are active standard protocol developers like IMAP and recently JMAP (a modern mail protocol will replace SMTP/IMAP, FastMail as a reference implementation), which is good because at least I know they understand the protocol and implement it by themselves.
It’s really fast, but come on, that’s one low bar to jump over. Gmail is the electron of mail interfaces.
I'm quite positive on it, nice interface and unique useful features, and it's reliable in my experience. However you have to be ok with its particularities, mainly that it doesn't have IMAP, and it's expensive.
Ultimately it's for people who love their unique interface/features, and don't mind paying so much for email.
Originally my reason to choose them instead of Protonmail was that Protonmail only works with their official client, which is a far too limiting dependency in my eyes.
- They suddenly weakened a privacy setting, and even exposed some client IPs for good measure. - https://news.ycombinator.com/item?id=33375424
- Yesterday they decided to throw up a big modal advertisement for a bulk plan at login, even to paying customers. Note that they chose NOT to do this for the aforementioned privacy-weakening change. - https://old.reddit.com/r/ProtonMail/comments/yj5m59/pm_visio...
Protonmail claims to support offline access, but in every rare occasion I needed it, it wasnt working for me.
They do have offline support now as far as I know.
> The unique identifier of a message MUST NOT change during the > session, and SHOULD NOT change between sessions. Any change of > unique identifiers between sessions MUST be detectable using the > UIDVALIDITY mechanism discussed below. Persistent unique identifiers > are required for a client to resynchronize its state from a previous > session with the server (e.g., disconnected or offline access > clients); this is discussed further in [[IMAP-DISC](https://www.rfc-editor.org/rfc/rfc3501#ref-IMAP-DISC)].
so, "SHOULD NOT", but in practice it's really hard to make {UID, UIDVALIDITY} assignments persistent and unique, so IMAP servers don't, and as you can see, they are allowed to not.
I.e., it's perfectly compliant to generate a new UIDVALIDITY for each session and then assign UIDs to emails in folders when you open them
For a vulnerable hash like md5, an attacker can find a collision in a few seconds.
And I don't believe that accidental MD5 collisions are something to worry about.
- a hosted service because host one myself is too much work CAUSED by anti-spam measure by some "self-appointed sheriffs" of the net;
- mail fetched from remote via fetchmail, no messages left on the server, filtered on my homeserver via maildrop, indexed via notmuch, muchsync-ed over SSH to desktop(s)/laptop.
That's is.
It's FAR simpler and FAR more powerful than any modern crapware UI, BUT is hard to setup due to the little development compared to the mainstream UI.
- https://www.howtoforge.com/procmail_tips_recipes
- https://dnns.no/switching-from-procmail-to-maildrop.html
Who have a little fetchmail part. I've nerve used getmail, before I've used OfflineIMAP (buggy but support IMAP IDLE) and mbsync. The only issue is fetching from multiple accounts that demand firing up multiple instances, but that's not much of an issue. You just set FETCHMAILHOME before any invocation pointing to the right config dir and set a different --pidfile for concurrent* fetching if you wish so. MailDrop is a (very) little (very) big setup since you need filters for anything if you are not a piler and that take MUCH time. Normally here my suggestion is fetch anything on a zfs volume, clone it, test on the cloned maildir or snapshot and revert after any test until you get nothing in the INBOXes. A slow step at a time you'll add the rest.
The sooner everyone moves to jmap the better.
IDs can also change between sessions, and can be different between simultaneous sessions.
Many mail clients often have a recycle bin/trash folder where "deleted" email will go. When you click delete, the application lies to you about what it's about to do and starts a move to another folder/mailbox.
This completely ignores the standard method IMAP has for deleting email. You can mark email as deleted but that email will remain stored until you call EXPUNGE (or UID EXPUNGE) on the server to empty the trash/actually delete the message. In other words, a virtual trash folder doesn't need to be stored on the server as a mailbox at all, the protocol already has a solution for this.
There are mechanisms for globally unique mail identifiers, like Message-ID, but those are part of the emails themselves and not the protocol. IMAP deals with a combined primary key of (mailbox, UID, UIDVALIDITY) and that works just fine in my opinion. If the UID ever changes, your mail client will know about this because the UIDVALIDITY changes and the cache needs to be refetched. I see my mail client as a view for the backend data, because that's how IMAP was designed.
The first mechanism is message sequence IDs. If you have a mailbox with N messages in it, these messages are numbered 1-N (inclusive); a new message gets N+1; and deleting message, say, 3 causes 4-N to be renumbered to 3-(N-1). Note that the server can be the one to delete the message (say another connected client deletes it), but server-to-client notifications of message deletion can only happen at specified times in the protocol. The client might still have stale sequence numbers when it sends you the next command however, because IMAP is pipelined. And if you think this sounds like a recipe for lots of weird bugs, you are indeed correct in those thoughts.
So what everyone uses instead are UIDs, which are stable IDs for a message (kind of). UIDs are monotonically increasing (a message with UID 100 is newer than one with UID 95, but there's no guarantee that UID 97 exists), and are not impacted by message creation or deletion. One way to think of them are offsets in the underlying mbox file of where the message lives. If UIDs need to be renumbered (... yay mbox), the server changes the UIDVALIDITY which means that previous UIDs are no longer necessarily valid.
The message sequence numbers kind of make sense, if you imagine that IMAP clients are very, very thin clients that don't maintain any local information, and if you imagine that servers are not expected to support two clients connecting to the same mailbox at the same time. But modern email clients need to maintain their own local database of email metadata, which means that the IMAP protocol has become, in effect, a database synchronization protocol, even though it's not originally designed as such (later IMAP extensions added features that made some elements of synchronization much faster).
It's fine though, as long as the MUA developers understand this and don't expect UIDs to be more stable than they actually are.
The amount of bad, long-lived bugs that aren't addressed because "we'll rewrite it any day now!" in many software organizations is very upsetting
Same way people would refer to "Facebook" meaning the whole of Meta
If no user steps up then it might not be that important issue in the first place.
Compared to the FOSS origin myths, many huge projects, with tons of end users, including very foundational ones, like GTK+ and OpenSSL and such, are understuffed (or just 1-2 base maintainers heavily overworked, who do 99% of the work and can't take it anymore), and nobody cares or has the time to dive in and fix anything.
Other projects that might have some person interested to bugfix, have maintainers that don't like contributions outside a clique, and ignore bugfixes submitted for years or forever.
So, "any user can fix it" is sometimes just in principle, while actual users than can fix and do fix it are thin on the ground, and othertimes it's just an option for external patches, that will not be merged upstream.
I gut feeling is that Protonmail Bridge is such an obscure project that no one really cares enough, and thus it cannot be “important” or “critical”.
Alternatively, users have an option to change to another system if they are unhappy. Protonmail has no monopoly. But complaining about open source maintenance is not going to change anything. Especially complaining on HackerNews is ungentlemanly.
It makes it seem as if using just protonmail could result in deleting a wrong email. This is not the case, you have to be using proton bridge.
People who care about protonmail but don't care about proton bridge have to click the link to learn that.
UIDs get desynced between IMAP client and bridge, as the bridge does not seem to use persistent UIDs for messages.
If you don't use the bridge you won't have issues with mismatched UIDs.
I am slowly migrating everything away from my paid ProtonMail account, and I intend to just go back to using a megacorp email... despite absolutely loathing and detesting megacorps. At this point in life, email is simply too important. Notices from government agencies, my accountant, my lawyers, my various banks... I quit self hosting for these reasons (no matter how good I am, I am not full time keeping my self-hosting pristine), and now I apparently cannot fully trust Proton.
But very opinionated and no IMAP.
Alternatively, another person in the comments here mentioned mailbox.org and I am thinking about that.
I just know I need email I can rely on a little bit more.
The only durable solution for email is:
1. Have your own domain 2. Have a copy of all your mailboxes locally (easily done with IMAP).
With that setup, migrating email is only a matter of opening a new account and changing the DNS record.
Proton Mail is web mail, like Gmail. That part is fine.
You use Proton Bridge as a connector to mail client software.
The thing that’s perhaps unclear is, Proton Mail is end-to-end encrypted email. You use Proton Bridge to walk your secure email beyond that enclave into whatever YOU are running in your userland scenario.
Part of all this is, you’re completely unclear on the concept of secure email the moment you need to use this bridge.
Which begs the question, why would you use Proton Mail if you’re gonna negate its unique value proposition?
Proton Mail is fine. It’s this misguided extension that’s the problem here.
If you’re fine with web mail then this issue doesn’t matter. If you’re not fine with web mail, maybe Proton Mail isn’t really for you.
To be honest, you’re guessing amirite? Be honest.
Bizarre statement, it’s like in-browser security doesn’t exist? The password manager browser extension you may use, that’s Swiss cheese right?
But I'll respond once in good faith - a browser, which is designed to load and run obfuscated remote scripts from quasi-trusted sources, and display complex untrusted HTML mail content, and which is subject to XSS vulnerabilities, will always be inherently less secure than, e.g., mutt. It exposes you to potentially malicious second parties (e.g. ProtonMail) and third parties. This is true regardless of any mitigations and security measures that are also built in to the browser. If you have enough distrust in your threat model to use ProtonMail, you also likely acknowledge the browser's weaknesses.
Because most users don't care about the end to end encryption. They just want to host their email somewhere [1]. And perhaps have it available offline.
All this encryption on everything is mostly turning into security theatre. All mostly because identity theft is so easy in the US. Perhaps that's the problem that needs to be fixed.
[1] lately somewhere that is not Google.
Well, no, not really. That is the claim that they make but such a thing doesn't really exist, well at least not in the way they suggest. It is e2e if either both parties are using PGP or Proton mail. That is a very small percentage of global mail flow.
The email stays encrypted on the server, and this extension only decrypts it locally like it would happen in the web browser.
> You use Proton Bridge to walk your secure email beyond that enclave into whatever YOU are running in your userland scenario.
Look, if I won’t trust the software which is running in my userspace, I’m doing something wrong anyway. Even if I wouldn’t use this extension, a malicious userspace application would still hook itself into your webbrowser, or simply steal cookies/tokens from your browser’s profile folder and hijack the protonmail session.
> Which begs the question, why would you use Proton Mail if you’re gonna negate its unique value proposition?
If I’m not mistaken with my assumptions at the top, the email still stays encrypted everywhere except on my PC. I don’t trust the mail provider, and I don’t trust protonmail. Protonmail could just change their web app at any moment to upload your second password which is used for unlocking your keys, and you wouldn’t notice. This can’t happen with an extension which doesn’t even have an auto updater.
Anyway, it goes both ways. And some people just want to use their email client, instead of a web app.
Some people want to subscribe to a premium encrypted email provider so they can download that email locally so it can live perpetually in ever expanding sub folders on disk, in plaintext.
These are the people who need Proton Bridge.
However, bridge is a paid feature used to attract more users.
Also, I don't understand your point about e2ee.
Bridge to proton server is also e2ee.
The mail interface is just a implementation of e2ee in browser, isn't it?
Proton mail is a paid service. It comes with the bridge. The bridge is not extra.
Free-tier Proton Mail may charge for the bridge. I don’t know, I don’t use free-tier Proton Mail.
https://blog.sigma-star.at/post/2022/07/protonmail-adventure...
In short: The idea was to move from a custom mail server to a paid, hosted solution. ProtonMail was chosen, with the bridge being used to get mails into a local mail client. Issues with the bridge eventually cropped up.
/rant
Recent outage issues surfaced some major flaws with the mobile clients, on top of shaking my faith in the infrastructure (though no one can easily stand up to nation state actors so I do not blame PM).
And yesterday I was shown ads inside the web portal, along with a big call-to-action button that wasn't there before to go buy a new tier. Have I mentioned that I have been a customer already for years?
Never used the bridge, but honestly I am not surprised that it may be broken and not receiving the attention it deserves.
It feels like Proton (with its vpn, email and the whole 'suite' they are promoting under the brand) is simply another growth company, focused on adding more and more features rather than on good old fashioned stable products.
The bridge was broken in the past, but since around maybe 2-3 years it seems to be working fine.
Issues with the app:
- notifications sometimes don’t pop up on iPhone. Yes, I have the enabled.
- app can take a minute to load
- when you click on a notification, it opens the app on the previous email you read, while taking a very long time to load the one you clicked on
I seriously hope they refocus on their core product. These issues are new.
> Proton Mail Bridge is a desktop application that runs in the background, encrypting and decrypting messages as they enter and leave your computer. It lets you add your Proton Mail account to your favorite email client via IMAP/SMTP by creating a local email server on your computer.
Source: https://proton.me/mail/bridge
This is a case of Proton sacrificing convenience for privacy. If the former is more important for you than the latter, there are better alternatives out there.
[0] https://jmap.io/#faq
[1] https://jmap.io/software.html
It would be worthwhile for many reasons not just the immutable IDs. I'd certainly donate to someone showing initiative working on this.
A good email store is very searchable, and a good MUA searches email, and a good MAP gives the client temporary (ephemeral) handles for "open" emails.
You use an IMAP compatible email service like Proton or whatever to receive and check mail like normal. A couple times per month, move all the messages from the service to your own IMAP server’s folders, instead of the “archive” command that moves them to a different folder on the same server that received them. This is pretty straightforward in Apple’s Mail.app on macOS, and I imagine similarly so in most GUI IMAP clients.
This gives you the best of both worlds: a single set of maildir folders on your own server you can zip or back up with normal tools like rsync or whatever, as well as 24/7 HA reliable provider servers to receive incoming mail at all times in case your long term mail storage machine is temporarily down. You also won’t bump up against provider storage limits.
Self-hosting inbound and outbound email is a drag (though I do it for many of my less critical domains), but a 90% availability selfhosted message storage IMAP service is fairly easy to run. This has the added benefit of a provider hack or legal process presumably affecting only a subset of your most recent messages due to those being the only ones stored there.
I am a Proton and FastMail user (and use the affected software) but I regularly move all the messages from these providers to my IMAP storage server (in different folders) so if their systems fail the blast radius is not “all of my emails going back to whenever I started using the provider”.
You don't need 24/7 server for receiving email. You can have it offline for a day or two a week and you'd only lose maybe some spam.
I'd call that involuntary graylisting. :D
But certainly something to be included in personal risk analysis when self-hosting.
I didnt realise some mail got deleted though, i need to investigate that.
I am a proton customer since 3 years and they seemed like a good bunch but now with all the stuff they are offering it seems like they have lost their way.
There is also no way of integrating the proton calendar into a 3rd party app like Outlook. This feature has been promised forever…
If you are not paying, you are what is being sold.
There are events where the UIDs change, for example when a server needs to rebuild its indices after corruption, but those should be extremely rare. Your server should also show this change when asked for UIDVALIDITY.
A message is defined by (UID, UIDVALIDITY, folder name). If this tuple changes, the message needs to be refetched. It's not the best mechanism for supporting multiple mail clients at once but it's easy to implement at least.
We both use the native mobile app and web based mail client.
In general it’s useable but the search functionality is useless. I’m hoping they’ll improve it.