[sir]

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.

[rfoo]

Submitted title is misleading. Turns out, it's not "all but OAuth", it's "all but OAuth and app password".

If you can't switch to OAuth, you can simply create an app password and continue using that as your IMAP password as usual.

[fps_doug]

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?

[bandrami]

They provide full access to your entire google account, but you can create as many as you want and revoke them whenever you feel like it.

[rfoo]

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.

Edit: that's incorrect, see replies.

[bandrami]

"This App Password provides full access to your Google account"

-- Google, when you make an App Password

[rfoo]

Ah, ok, I just tried and I'm wrong. That's correct, it provides full access.

[fps_doug]

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.

[nanna]

Brilliant. So this is how you could keep a client like mu/mu4e functional for Gmail and outlook365.

[yashasolutions]

actually app password will keep working. Which is basically all you need for mu4e

[emersion]

Unfortunately this requires users to setup their own OAuth client, which is a pretty manual/cumbersome process.

[sir]

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).

[emersion]

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).

[htrp]

Any good guide on this (registering oauth clients) for people who want to make the move?

[jpc0]

https://support.google.com/cloud/answer/6158849?hl=en#zippy=

There is likely a package/library for your language of choice to do a basic oauth client.

[rollcat]

Same if you're building any OAuth-enabled client from source.

(Remind me, what's stopping me from extracting the client secrets from the compiled binary, and re-using them elsewhere?)

[yrro]

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.

[gaius_baltar]

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!

[1] https://en.wikipedia.org/wiki/Digital_Services_Act#Very_larg...

[polski-g]

I ended up ripping the app ID out of Thunderbird and using that for my OAuth process to Gmail.

[mschuster91]

Thank you for writing that, really helped me out back when Microsoft pushed OAuth for Office 365.

[codepoet80]

Thank you for making this. I'd been puzzling through how to build something similar. Starred and downloaded, I'll definitely be using!