Hacker News Reader

Comment by superkuh | Hacker News Reader

Too bad that most megacorp email providers no longer allow you to use just IMAP. Instead there's a bastardized OAuth2.0 (not good like Oauth1 was) toolkit they use for requiring HTTP(s) mediated authorization. Just IMAP will not work. And every megacorp's implementation of this is different so they have to be handled by slightly different plugins/etc.

The megacorps are trying real hard to kill off open protocols and switch everyone over to their in house "versions" of a public protocol for making proprietary protocols.

View on HN

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

You do still need details for an authorised client, but it’s possible to use those of one that’s already approved. See the readme section that explains this aspect: https://github.com/simonrob/email-oauth2-proxy#oauth-20-clie...

actually that has nothing to do with imap. Imap supports even OAuth2 Authentication trough sasl and the oauth2 authentication for imap will be more and more of an standard, it just sucks that most providers don't support a few things that makes it easier, like dynamic clients, etc.

I don't even want to use 'plain' IMAP authentication, because it doesn't support 2FA.

This amongst other similar reasons is why large providers also don't want to allow plain IMAP authentication. Too easy to abuse and too disruptive to curtail.

If the endpoint supported mutual TLS, then the client side certificate could serve as a factor and the account credentials would be the other factor.

Reply on news.ycombinator.com