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.
- 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.
Yeah well that's IMAP-compliant. IDs can change between sessions, that's always been part of that terrible standard.
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.
/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.
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.
The bridge was broken in the past, but since around maybe 2-3 years it seems to be working fine.
When came the steps "can I easily move from this service?", I realized you have to _pay_ to export all your emails from the service. They make it super easy for you to open an account and receive emails, and then makes you pay if you want to get a copy of your own data.
I contacted the support to tell them it is likely illegal under European Data Privacy laws. They replied I can still export email for free one by one if I wanted to... (which is obviously not a valid answer when you have 5000 emails)
Then I looked in Swiss laws for a similar clause, and found that Swiss laws doesn't give users of online services the right to easily and freely get a copy of their data. It was a law proposal at the time of my research.
So yeah... Your data is so secure in Switzerland that you don't even own your data !
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.
Protonmail claims to support offline access, but in every rare occasion I needed it, it wasnt working for me.
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
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.
See: https://proton.me/support/export-emails-import-export-app
When I was using Protonmail in free tier, the Import-Export feature was only for the paid tier.
Seems strange that they only opened it for free tier now. This should be a feature available to any tier in the first place.
If it's true they require you pay to export emails it sounds like borderline extortion.
- 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...
edit: As mentioned by a sibling comment, my email is currently on Fastmail, zero problems.
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.
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.
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.
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.
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.
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.
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.
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?
They do have offline support now as far as I know.
https://fastmail.blog/advanced/why-we-dont-offer-pgp/
I don't believe the encryption/key management from a company.
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.
It’s really fast, but come on, that’s one low bar to jump over. Gmail is the electron of mail interfaces.
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.
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.
The fact that Bridge and its client can become desynchronized sporadically for some users is a high priority issue we have been working on. Bridge is open source, and as a result relies upon open-source components, and the root cause is an architectural issue in a library that Bridge uses to implement IMAP. When there are network issues, this library returns errors to email clients.
Unfortunately, there are hundreds of email clients, and some email clients don’t handle errors properly, and this leads to desynchronization.
Our error tracking shows this does not happen often (1-2% of Bridge users) and the symptom is usually incorrect display of messages or read/unread status which is fixed with an inbox resynchronization. There are cases where a combination of a desynchronized mailbox and a specific series of user actions can lead to accidental email deletion, but this is far rarer than desynchronization. Our implementation tries as hard as possible to avoid this. If you find you are missing an email, our implementation works around the issue by placing it in a users’ All Mail folder.
As Bridge is open source, updates on this issue have always been publicly posted on GitHub. Addressing this issue at the source requires replacing the core IMAP library. Unfortunately, there are no FOSS IMAP libraries that are sufficiently well maintained. Therefore, the solution is to build our own IMAP library called Gluon, which we have been focusing on since this issue was reported to us. You can follow the progress of this open-source project here: https://github.com/ProtonMail/gluon
We are not refusing to fix the problem. The only possible solution is writing a new open-source IMAP library which we can maintain ourselves to ensure this class of errors cannot occur again. We have doubled the size of the team working on this this year so it is a priority for us.
We’re confident that this addresses the main sources of desynchronization and will be available in the beta version of Bridge by the end of the year.
Thus in practice IMAP servers generally assign `UID`s ephemerally per-session, which means that clients can't rely on the stability of `UID`s, which means that clients have to re-obtain `UID`s before operating on emails via IMAP even if they have cached those emails locally. `UIDVALIDITY` exists to help clients cache and invalidate `UID`s. The RFC has text about this.
A bridge from IMAP to something else (which is basically what every IMAP server ever is) needs to deal with this. To make `UID`s stable requires keeping state.
Clients should really not assume stable `UID`s. Instead clients should `SEARCH` or list to get [temporarily] valid `UID`s then use those to delete etc.
I don't get it. Bridge is open source does not imply it should relies upon open-source components.
> Addressing this issue at the source requires replacing the core IMAP library.
Why building an IMAP library from scratch instead of fixing/forking go-imap? Even a temporary fix to go-imap when you are developing gluon? Another repetitive work which does not guarantee the mentioned issues will be resolved completely.
It could be open source and depend on proprietary components, but then the public wouldn't be able to build and use it from source.
This protocol should be an open source effort, allowing mail clients to implement it and other provider to implement it on their own server.
This could clearly be a major move, making unencrypted IMAP a thing of the past, allowing direct competitors (tutanota? Mailfence?) to collaborate on the bridge and on the ecosystem and targeting directly the only competitor worth talking about : Gmail.
These issues have been around since I started using bridge 3 yrs ago. So im sorry but my patience is running out soon.
I just renewed my yearly membership, but if these bugs concerning the MAIN FEATURE of proton arent taken care of in the next few months than i will be looking for alternatives.
(If so, I will make the jump from the free plan.)
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.
> 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
Aside from the UID issue discussed I also had problems with Bridge not supporting my particular use-cases. I created my own fork (see https://github.com/polaris64/proton-bridge) to work around some limitations and to add features, but maintaining this was too much work, especially as paying for a mail provider was supposed to reduce maintenance burden. I have had a pull request open since the 23rd of June to merge these to the upstream version, but so far I haven't received any comments from the Proton team.
I like ProtonMail, I just wish Bridge was more standards-compliant.
I've been using them since around 2015 and they have been excellent.
If no user steps up then it might not be that important issue in the first place.
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.
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…
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.
The Protonmail Bridge with Thunderbird (the only somewhat supported desktop mail client on Linux) has always been buggy at times, such as archiving not working as expected, or creating a new mail subfolder in Thunderbird creates a parent folder with a "/" in front of it in web mail.
I understand there's probably some difficulty keeping everything E2E encrypted on the desktop side of things, but Thunderbird feels crippled if you want to use it with Protonmail/Bridge. For example, calendar doesn't work at all.
I love what Protonmail has been trying to do and have done, but all I really want is to be able to use a desktop mail client with calendar, and the Protonmail Bridge is not there yet. My subscription is up in January, so I may switch to something like Fastmail for the time being.
> 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.
But it is one of the worst UXs I have ever paid for.
The app rarely works and is slow. Clicking notifications results in an infinite loading screen resulting in you needing to find that email manually.
I am sure this is blamed on the encrypted backend, but to me it just seems lazy regarding UX.
Not sure why they can’t make it work, but I guess trying to make their custom encrypted mail set-up simply doesn’t translate well to IMAP’s weird idiosyncrasies.
I do think it's relatively early stage. Yes, the email product has been around, but the more business orientated suite of products seems very early.
The email app misses some functionality, but what's there works and looks great. Calendar is progressing nicely. Drive is kinda useless beyond file sharing atm, it really needs a sync app to be useful.
Another qualm I have is that you can't buy extra storage, custom domains, etc. It makes little sense to me, for now it's fine, but at some point it might force me to find a different solution.
They certainly have a lot of work to do, and they need to get a grip on issues like this asap, but I'm willing to wait it out for a bit as I do like the direction, I think there is a lot of potential.
That said I am not sure I would move the company over to Proton like the issue raised, idk if it's ready for that.
mailbox.org
hey
fastmail
tutanota
mailfence
disroot
posteo
barracuda (for businesses)
vivaldi mail
mailpile
countermail
hushmail
I haven't used any of these, so if anyone has others or has experience with any of these, please share your experience.
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
That being said, I've evaluated other providers like Fastmail. While their service is good I am not a fan of reducing my privacy. So people like me are stuck between a rock and a hard place.
That is literally the selling point of ProtonMail: the email is encrypted in storage on their servers (they don't have access to it), and thus you have to decrypt it locally on your machine, and the Bridge does that for you, because your email client does not know how to handle the encrypted content otherwise.
No support for format=flowed or restricting the number of columns from what I can tell.
Super annoying.
i do not know how you would want to pay a service from such a company.
Rarely have I seen such mastery of the art of understatement.
I hope they check out Migadu, which has been excellent for me — and would seem to be a much better fit for them, too.
It was terrifying enough that it has made me rethink how I manage all of my online accounts. Incidentally, I never had that issue with Gmail in 10+ years.
Not a Protonmail fan.
In your example, you have the choice not to buy the license. In the case of Protonmail, they already have your emails, and are already serving them to you, so holding your correspondence hostage if you want to export it all in one go is a bit of a dick move.
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.
And yeah, this UID situation with Protonmail is not good. As a long-time Protonmail customer, I've been concerned that they seem to have gotten bored with keeping a stable product.
Back to the point... I still will be using Protonmail because no product is perfect. For example, Fastmail I believe is in Australia which is one of the last western nations where I would want my data to be stored. I wouldn't use them, but does that mean someone else shouldn't use them? Not really. All of these products have tradeoffs. Since Protonmail's delete function is likely to still work most of the time, I won't yet be abandoning them. Fact is that I find all of the alternatives preferable to relying upon The Google.
But, it just works once its setup, and if all you want is IMAP support it's all good there. They usually do a Black Friday sale that's pretty decent. Last year they had a 25gb storage option for $25/year. I have like 5 domains on it, and about as many mailboxes. Smooth sailing since.
If anyone here is looking for a business idea, I would absolutely sign up for an email service that is based in U.S. and provides a guarantee (in writing) that it 1) doesn't track the user across the web after they sign in to email 2) doesn't scan or parse data from emails in any way 3) doesn't sell any information it obtains from me or about me to any third party 4) doesn't make any of its money at all from advertising 5) maintains high operational security standards.
Notice that I'm not even asking for end-to-end encryption like Protonmail provides. I just want something that is in my home country's legal jurisdiction (for business reasons), doesn't track me invasively nor sell my data, and is well-run.
I believe a company could make a lot of money if they communicated this offering to the public and maintained a decent brand reputation.
I actually don't have an issue with that. Once it is available to free tier users, it frees up the devs to go to the next item on the list once again only available to the paid users. Lather, rinse, repeat. Sounds like a fairly sound bizplan.
The obvious reason is that a company has an incentive to make it easy to onboard and no incentive to help you migrate off or even an incentive to make it difficult or costly to leave. I don't see how making import/export something only a payed tier has is specifically or especially for funding development. It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
>It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
Yet here we are on a dev centric forum talking about it being a "bad" decision. From a dev perspective, the decision of starting something in a paid tier then (if ever) releasing to the free tier is not offensive to me. A company offers a free thing that has fewer features than a paid tier, "news at 11" type of story it is not. Doing poor research into the limitations of the free tier and complaining publicly about not having access to the paid features on the free tier is also not news worthy. Again, yet, here we are.
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.
Same way people would refer to "Facebook" meaning the whole of Meta
And I don't believe that accidental MD5 collisions are something to worry about.
But certainly something to be included in personal risk analysis when self-hosting.
Here: https://github.com/ProtonMail/proton-bridge
Briefly looking at the files and code it's hard to tell whether that is still the case, but it's fair to assume Import-Export would reuse most of the machinery behind Bridge.
If they decide to use third party libraries, that's their responsibility to review those libraries and include them to their code base.
Not "it's not my fault; it's others fault"
Which they are doing.
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.
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.
The sooner everyone moves to jmap the better.
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).
IDs can also change between sessions, and can be different between simultaneous sessions.
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 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.
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.
Care to explain which are those concerns about privacy that you may find when owning a custom email address? Thanks in advance.
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 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
Do you mean you can lose your domain if your country leaves the EU, or are you talking about other issues?
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
.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.