In case it helps inform a decision, here's the OAuth2 status of several
IMAP providers:
OAUTHBEARER: Google, Yahoo, ATT, Comcast, Sky
XOAUTH2 only: Microsoft, AOL, Yandex
Neither: Apple, Cox, Zoho, Mail.com, GMX, FastMail, 1&1
For each service, I searched for the IMAP server name, then did
openssl s_client -crlf -connect IMAPSERVERNAME:993
Typically they respond with * OK [CAPABILITY blablabla], but in some
cases only with * OK so then I typed "a CAPABILITY".
I don't have contacts at these companies, but if Microsoft and AOL
could be urged to add OAUTHBEARER support then that would be the best
solution.
Alex
On Thu, 2019-04-04 at 10:37 -0700, Brandon Long wrote:
> XOAUTH2 is just OAUTHBEARER but based on an earlier draft, so yes,
> it's very similar. We had to ship it at Google because we we're
> deprecating oauth1 and our XOAUTH with it, and the rfc was taking
> longer than we'd hoped.
>
> Given the large population of outlook.com users, I'd be for
> supporting it, maybe with the caveat that we'll remove it when they
> support OAUTHBEARER. Up to you.
>
> I'll see if I can find someone at MS to ping about it, my old contact
> decamped to FB last year.
>
> Brandon
>
>
>
> On Thu, Apr 4, 2019, 9:17 AM Kevin J. McCarthy <ke...@8t8.us> wrote:
> > On Wed, Apr 03, 2019 at 06:47:19PM -0500, Alexander Perlis wrote:
> > >Mutt supports OAUTHBEARER. Would patches adding XOAUTH2 be
> > welcome?
> >
> > Authentication schemes and OAUTH/XOAUTH2/etc are not really my
> > area.
> > I'm Cc'ing the original contributor of the OAUTHBEARER patches.
> > Brandon, I would greatly appreciate your input on this matter.
> >
> > Based on your description, _technically_ it wouldn't be hard to
> > refactor
> > the existing functions with a XOAUTH2/OAUTHBEARER flag and just
> > generate
> > the correct string for each. If it did get done, I would prefer it
> > to
> > be explicit (i.e. approach #2), and would lean toward XOAUTH2 not
> > being
> > auto-tried when the authenticators list is empty.
> >
> > However, this feels to me like a step in the wrong direction. The
> > RFC
> > is coming up on 4 years old, and as you mentioned Microsoft
> > themselves
> > had a hand in producing it. Even though the patch probably
> > wouldn't be
> > horrific, it is still a technical burden for an already deprecated
> > non-standardized scheme.
> >
> > Unless Microsoft has indicated they have no intention of
> > implementing
> > OAUTHBEARER support, I would lean against the change.
> >
