Re: [Fetchmail-users] Is Oauth supported?

[Matthias A. <mat...@gm...>]

Am 17.11.2015 um 15:17 schrieb Carlos E. R.:

> I finally got my IEEE mail setup in Thunderbird. It is using a
> GoogleApps account (thunderbird recognizes the ieee email address and
> sets it up from data in its database, something that did not happen
> previously).
> 
> I would like to set it up also using fetchmail, but I don't know if it
> is possible.
> 
> The settings in Thunderbird are:
> 
>   Connection security:    SSL/TLS
>   Authentication method:  OAuth2
> 
> I'm not familiar with this "OAuth2". I don't see it in "man fetchmail",
> but maybe my version is old:
> 
> cer@Telcontar:~> fetchmail -V
> This is fetchmail release 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5.
> 
> 
> Ideas? A link to somewhere is fine (rtfm :-) )

Fetchmail does not support OAuth2.  The relevant RFC 6749,  reads:

>    This specification is designed for use with HTTP ([RFC2616]).  The
>    use of OAuth over any protocol other than HTTP is out of scope.
<http://tools.ietf.org/html/rfc6749>


First, Is configuring "access for less secure apps" on the Google end an
option, and would it help?


Fetchmail does not talk HTTP, and OAuth2 is breaking media.  Checking
Google's SASL XOAUTH2 spec, it seems we'd need to write an HTML client,
a JSON parser, perhaps a cookie handler, a callback to the user (which
is incompatible with cron rigging and daemon mode setups) per the
"limited-input devices" MSC on
https://developers.google.com/identity/protocols/OAuth2.

I think the only chance is if someone provides an open-source and
compatibly-licensed OAuth2 implementation including fetchmail
integration code for the master branch, that has a third-party public
audit report, and a sustainable plausible support offer for the OAuth2
code -- but even then I might as well steer clear of such contributions
given the experience I've made with the MAPI code.

MAPI was offered as a summer of code project, with moderate code
quality, relying on OpenConnect and no support for integration or
maintenance, and no-one ever responded with a test account I could use
to complete the integration.  The contributed code wouldn't even compile
for me.  I received two updates, but ultimately, the MAPI contribution
was buried in the BRANCH_MAPI branch, without even a proper funeral.

I don't like the idea of adding such complex matters to fetchmail that
make it a web browser, that takes it way out of scope I'm afraid.

If Google want to force you to use a browser, that's fine - only
fetchmail won't be that browser.

I think the utmost I'd consider is making an alternative to "plugin" but
for SASL authentication, so an external command (perhaps an ECMAScript
or Python or Ruby stuff) can cough up the credentials for a particular
SASL dialogue.  It would require someone to provide a sound design for a
protocol between fetchmail and that program.