Brandon Long authored Jun 11, 2018 and Kevin J. McCarthy committed Jun 14, 2018

Gmail supports RFC 7628 for using OAUTH with IMAP, and they really don't
like you using password based auth.  You can still enable "less secure
apps" and then generate an application specific password, but I figured it
was time to support it.

Being mutt, I punted on some of the "hard" work to an external script, ie
getting/refreshing the OAUTH tokens.  This avoids the issue of how do you
have a client-id and client-secret for an open source project, and the fact
that OAUTH discovery is still nascent, so you'd likely need separate things
for each of the providers.

At least for Gmail, you can use the oauth2.py script from Google's
gmail-oauth2-tools:
https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py

You'd need to get your own oauth client credentials for Gmail here:
https://console.developers.google.com/apis/credentials

Then, you'd use oauth2.py with --generate_oauth2_token to get a refresh
token, and configure mutt with:

set imap_authenticators="oauthbearer"
set imap_user="<email_address>"
set imap_pass=`/path/to/oauth2.py --quiet --user=<email_address>
--client_id=<client_id> --client_secret=<client_secret>
--refresh_token=<refresh_token>`

For this patch, I didn't add any new configuration, but I'm open to
suggestions on that.

The patch also only support SASL-IR to reduce round-trips to the server,
but it's certainly possible to change that if we think there are
OAUTHBEARER IMAP servers that don't support SASL-IR.  It also requires the
connection to be encrypted as the access token is re-usable for an hour or
so.  Again, Gmail only allows encrypted IMAP connections, not sure if any
OAUTHBEARER services allow non-encrypted.

Turns out that auth failure leaves you in SASL mode, so I have a hack to
issue a noop command on error.  Not sure if that's just OAUTHBEARER
oddness, or whether I should be using lower level mutt imap functions.