Yes they are a foreign company based in Switzerland. Additionally they don't support POP3, which you said you prefer.

When it comes to the free account, it doesn't support using an email client via IMAP/SMTP, so you must use their paid proton unlimited account for that. Additionally, the proton unlimited account limits you to 15 email address, and 3 custom email domains.

The proton bridge application is a pain and can cause issues with email clients. Now in days most transmission of email uses SSL which is encrypted. If you want end-to-end encryption then use PGP or an email service that supports a means of using end-to-end encryption server side for specific email when really needed.

Yes they have SMTP, IMAP, and POP3 access, plus they don't charge per email account like a lot of the high quality providers do. You need to have your own domain name which the email hosting is attached to. They make the migration easy, you just point your domain to their email hosting systems, and when you login it will pull your email off the old server. Of course if you're using POP and downloading all the email to your email client and then deleting it off the server, then you don't need to worry about migrating anything.

I would suggest anyone serious about email to have their own domain name since it allows you to point your domain name to any email hosting you want. If you use the domain name that is the same as the provider, then you are stuck with them unless your willing to change and lose that email address domain. So using your own domain name for your email is always recommended for portability.

In addition to the BBS nostalgia, they support just about every open standard protocol that forms the basis of their legacy device support for people that like to get the nostalgia going by using their old hardware devices for email.

Or you can do the opposite and just block all incoming email to your account unless they are on your whitelist. This will filter out all of the spam, and allow in only the real email you want. This is basically why chat clients don't get plagued with spam, you have to be added as a friend before a random person can send you messages. The problem with email is by default it is open to talk to everyone and accept email from everyone. This is similar to SMS, which is also getting plagued by spam, but not as bad since phone numbers are harder to obtain then email addresses. So if one doesn't want to deal with spam with email or sms (txt messages), then create a whitelist of people to accept messages from, and dump everything else. When it comes to email, you also want to make sure your provider enforces at least SPF to deal with forgery attempts of people that might be on your whitelist.

Additionally, it is giving more power to these corporate monopolies to control email however they want. The more and more people centralize on the corporate monopoly email providers, the more it is killing the federated nature of email services (SMTP) and giving them more power to move away from the open standard RFCs. It feels like the only two protocols left that have not been pushed away for proprietary protocols (such as what happened with chat protocols such as XMPP) is HTTP and SMTP. It feels like SMTP will be next unless more people support the other email providers out there, or even run their own email server if they feel technically inclined to.

Yes they exist, but are becoming much more rare because most people just go with the big two, which in the end hurts these type of providers. One I can suggest that has reliable IMAP and POP services, and even supports features you don't find anywhere else such as 2FA for IMAP and POP is Imageway. You can find more information about them here if you're interested: https://www.imageway.com/

He is correct, the real problem is users tend to create easily guessable passwords that get reused in multiple locations. Even OAuth2 requires you to login to a webpage with a password to obtain a unique token to be used by the client. This alone means a password is still required as part of MFA. You are correct in saying the only possible way to easily manage unique complex passwords is to use a password manager to store them with a single master password that is easy for the user to remember which is stored and used on the client side only so it can't be obtained from a hacked server. The only current fixes I see to passwords themselves, is to use biometrics or physical dongles for authentication instead which don't require you to remember something complex like a unique hard to guess password, or use 2FA to require a second approval method in case the generated password are obtained by an unauthorized party.

Not completely true. If the Basic Auth password is stolen and that password is only for an email account, then it can only be used to access email just like a OAuth2 token. What you are saying is only true if the same password you use for your email is used elsewhere, which is a big no no. You could say users won't do that, then you have the option to force application passwords which will allow you to make forced unique passwords to use used on a per app basis. Limited lifetime? Most have issues with long-lived access tokens. If you had short-lived tokens, then one would need to login again all the time to renew the token. You could use silent authentication, but that bypasses any check to make sure you are the proper owner of the token by using the MFA login account. I have never been asked once to renew my GMail or Office 365 OAuth2 token for my email account when using a IMAP client connecting to those services using a OAuth2 connection method. Lastly, yes they support IMAP and SMTP, but are forcing the use of OAuth for IMAP/POP which breaks decades worth of software and scripts unless they are updated to support OAuth2. Additionally you have to use that services token management to manage the tokens (like revoking or setting how tokens expire) and access rights for those tokens. This adds another layer of complexity. The question is how long will they support IMAP and POP before they depreciate those also for being so called "insecure" or "legacy". These are common reasons they say OAuth2 is secure and Basic Auth is not: 1) OAuth2 is encrypted so it is more secure: Basic Auth can be encrypted and forced using SSL/TLS. 2) OAuth2 uses multiple unique tokens so it is easily to remove access to a specific application: Basic Auth can use forced application passwords which could be used to create a auto-generated unique password for different applications. Basic Auth would require more manual intervention and is not forced. 3) OAuth2 supports MFA: Basic Auth can support the use of 2FA. 4) Tokens can be set to have limited lifetimes: You can enforce Basic Auth passwords to have limited lifetimes and be rotated. The advantages which basic auth for email accounts does not provide a solution for: 1) You can assign limited permission rights to a token, where basic auth is a all or nothing access. 2) Passwords are stored server side only when using OAuth2, while basic auth stores the password in the client and server-side. What OAuth2/OpenID does do is enforce best practices of using encryption, MFA, and per app unique identifier while basic auth these must be enabled to be forced.

Actually if you are not actively using SMTP AUTH it will be disabled according to: https://learn.microsoft.com/en... Additionally in the link you referenced a comment from a Microsoft employee stated: SMTP will continue to function normally as long as: you have SMTP auth enabled either at the tenant level or mailbox level, you don't have security defaults enabled, or MFA enabled for those mailboxes using SMTP auth. So their are instances where things could break unless you take action to prevent it.

This is another case where the large companies like Google and Microsoft are creating more vendor lock-in. What this is going to do is break existing email clients, scripts, and migration tools which use basic IMAP/POP connection methods to manipulate or move emails. Instead they want you to use their own specific API's, clients (web based, GMail, Outlook) and more complex browser based authentication methods for token exchange and management. They say the old method is insecure because of encryption and 2FA, but both of those are supported using basic authentication if done properly. Hackers are already finding ways using proxies to hack the MFA token exchange method: https://www.zdnet.com/article/... If you use encrypted (SSL/TLS) based basic authentication with 2FA, it can be nearly as secure as what they are forcing. The one advantage it does have is that you can provide a token per client, and only revoke access to that specific client, where with basic authentication changing the password would remove access from all clients. Of course is this one feature worth completely breaking decades of old software and scripts by eliminating the old connection method? I think this is the first step of deprecation for Google and Microsoft and wouldn't be surprised if in the near future they didn't eventually force OAuth for SMTP and then eliminate the use of IMAP and POP for email access on their services. If you want more information about this situation and a email provider that values supporting open legacy environments then I would suggest checking out this post: https://www.imageway.com/2022/...

The shirt the South Park Matt Damon was wearing says it all "Fortune Favors Matt Damon", lol...