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