I really lament that you cannot sign in even with an application specific password any more and you need to get an oauth client and go through an oauth flow. It’s my email, but Google takes away an open standard even for myself to access it.
Given the amount of spam I receive on my free Gmail addresses (compared to my paid for freelance one), and the amount of spam I receive from Gmail servers on my non Gmail-E-Mail accounts I get more and more inclined towards degoogling myself.
Especially as I receive more and more information that my freelance e-mail is put into spam by recipient systems.
Not sure how to get rid of my Google ecosystem routines, though. Feels daunting.
I set up Postfix to catch *@immibis.com. I use it for some less important things - first mailing list subscriptions, then I even used it to buy festival tickets. These are lower-risk things. If they don't work then it's not a big deal. In the latter case I'd be out $200 and not be able to go to that festival (which did actually happen, but not because of my email server, but because they tried to invent a hidden fee after I already paid, and I'll have to go to small claims court to get a refund). Now that I know it works, I use it by default for new less-important account signups. (And nobody's questioned me yet why the local-part of my email address is the name of their business)
I still wouldn't use *@immibis.com for my bank account. I'd use gmail for that. The bank is a corporation. If there's a problem between them and my email server, they'll tell me to suck it up, then delete my money. If there's a problem between them and Google's server they'll be forced to fix it. If there's a problem with my Google account, I can go to the bank office and say "Google banned me from Google, so I need to link to a different account" and they'll have a procedure for that. They won't have a procedure for "your mail server sends LF when it should be CRLF" or whatever weird issue could occur between them and a self-hosted mail server. But if my bank account was the last thing remaining on Google, in practice, it would still be a successful email de-googling. 99% is a pretty good success rate. The bank app runs on Android, anyway. Could switch banks and only do banking in person.
I find Youtube a good source of entertaining and informative content (certainly way better than something like Instagram) and I haven't replaced that yet.
After Mozilla jumped the shark and declared they hate privacy, I've been gradually moving things over to Zen Browser, which is based on Firefox. (I don't care that Zen isn't significantly more private than Firefox; I care there's someone in between me and Mozilla and that isn't Google)
This isn’t as hard as you might think. I pay for https://mailwip.com because the founder helped me figure out mine. It was ultimately relatively strait-forward. I stay because I appreciate his work, my email is flawless, and I like the logs they provide.
I've been self hosting email for a few years at this point and haven't had any delivery issues. Just make sure you set up all your DNS correctly and avoid polluted IP ranges like DO or AWS
POP3/IMAP work with any client that supports those protocols.
OAuth really doesn't. Every OAuth integration I've ever built always feels like it needs a tiny bit of custom development.
Also the OAuth flow is usually absolutely horrible for when you're trying to get a token for accessing your own data. I've had to spin up a temporary web app to handle a hunch of redirects just to get my own token!
I built a proxy a while ago to make this easier - it lets you stick with IMAP/POP/SMTP as-is. No need for your client to even know that OAuth exists. See here: https://github.com/simonrob/email-oauth2-proxy
> No need for your client to even know that OAuth exists
Yes, you can do that, however the problem is getting a client_id/client_secret in the first place. You need to register yourself for one, you need to (nowadays) whitelist every single account or go through a google verification process. At one point you could apply for a client_id that allowed anyone to use it, but that ship has sailed.
> So that’s an argument about a protocol preference not an open ness one.
Just to make sure the differences are clear: with username and password and IMAP I can use an RFC standardized protocol to sign into an inbox and I do not need Google's permission. The oauth flow they have is neither standardized (XOAUTH2 is not a standard as far as I know at least), requires provider specific logic (Outlook is different to Google) and most importantly requires me to get Google's permission to sign in. I need to get a client_id with the necessary scope, and that is only granted after a review by Google. [1]
[1]: asterisk is that a development only app can authenticate up to 100 users, and those users need to be explicitly whitelisted in the dev panel.
That's an appeal to IETF canon, which might be a valid concern (I wouldn't share it, as an opponent of the IETF) but remains orthogonal to "openness". A protocol is open if it's published and especially if it's widely used, which this configuration is.
On my Google Workspace org, app passwords don't even show up in the user account settings any more. The documentation says they are recommended against, and the IMAP docs say only oauth2 is supported. However I just found posts that suggest that you can still access them if you navigate directly to the app passwords page. I will try.
We're using app passwords for Marco (https://marcoapp.io), until we get through the unnecessarily-rigorous process of gaining privileged OAuth access for email scopes.
