Re: the OAuth issues: to remove some of the hassle of this, you can use my proxy/relay to allow any IMAP (or POP/SMTP) client to be used with a “modern” email provider, regardless of whether the client supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
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.
What makes you say the protocol is different for each provider?
I maintain a proxy that transparently adds support for OAuth 2.0 support to IMAP/POP/SMTP clients (https://github.com/simonrob/email-oauth2-proxy), and for normal use it doesn’t need to know anything about which service it is connecting to. Apart from advanced features such as CCG or ROPCG which are mostly O365 only, what is different?
If you can’t switch to OAuth, you can use my proxy to allow any IMAP (or POP/SMTP) client to be used with a “modern” email provider, regardless of whether the client supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
This is surprisingly non-shitty by Google. I must admit that I didn't know that before. Can you limit such a passcode to just IMAP/SMTP, or can it be used to log in to other parts of Google?
This passcode is inherently limited to the service it bound to (IMAP or POP3), that's the whole point: don't expose your account password to something which only needs a finer-grained access.
You're directly contradicting your sibling comment. I guess I'll experiment with this in the coming days, although I'm a little worried tinkering too much will just completely lock me out of my account.
There's no good way around that unfortunately. The proxy could build in an OAuth client for the major providers, but it's unlikely that this would be trusted by default without significant effort being put into review processes.
As the readme explains, there's nothing to stop you using the existing OAuth client details from another source (such as the many already trusted open source email clients that exist).
Yes. I'd argue the problem is not on the project's side, it's on the Google side (they have ridiculously high requirements for registering OAuth clients for IMAP/SMTP use, especially for a small open-source project).
The provider might notice that their key is being used in an unauthorized way and terminate your account, prosecute you for computer fraud and abuse, etc.
I think this is the only assured way to interop, as I expect Google may try to kill other competing apps (specially in mobile) that does not capture user data or generate data points for its ads.
I wonder if any intentional limitation here should not trigger some of the EU Digital Services Act provisions for interoperability ... in this list [1] I see Google Play, Maps, and Shopping but not GMail!
When it became clear many major email providers were going to require OAuth for IMAP/POP/SMTP access, I was pretty frustrated that I’d have to stop using clients/scripts that didn’t support this method.
Rather than spending lots of effort on migration, or switching clients entirely, I made a local proxy so that any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
This looks quite interesting. A few years back I needed (quickly) to find something like this, and at the time there seemed to be only Davmail (which I see your notes mention). I will be curious to see if this is an easier solution than Davmail (since I really just need the email imap/smtp part of oauth for Outlook).
If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
Google only lets you use app-specific passwords if you have set up two-step verification (and provided a phone number).
If you have an email client that doesn't speak OAuth and you can't/won't set up 2FA then this proxy of mine lets you use any IMAP (or POP/SMTP) client with an OAuth email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
Just FYI, you can also do this with the inbuilt Shortcuts app - create a shortcut to scan a QR code then copy its contents to the clipboard for example.
If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
This looks great! Does it work in a way that would make it need to be "authorized" by the organization?
Recently I wanted to use the alpine terminal email client, which does support OAuth2, but I was thwarted by a notice saying "application alpine requesting access; write to your admin to authorise". Several months later, apparently whether to add alpine or not to the list of approved software is still "being discussed". Not exactly holding my breath for it ...
