Hi all,

the subject says it all: Google stopping IMAP and SMTP access an moving
to proprietary protocols?

That's what I heard on the grapevine, can anyone confirm or deny?

Jörg.

Claudio Luck wrote on 29.08.19 18:02:

I understood it like Google is apparently calling software companies to ```

<pre class="moz-quote-pre" wrap="">convince them to use their proprietary API [1] instead of IMAP and SMTP to access Gmail. Given that they also happen to decide which app goes into their Play Store, their convincing would be ... well ... very convincing. [1] <a class="moz-txt-link-freetext" href="https://developers.google.com/gmail/api/guides/">https://developers.google.com/gmail/api/guides/</a> ```

Thanks for this information.

I hope Google respects Thunderbird to not propose this to us, and respects standards enough to keep IMAP enabled.

I'd be in favor for a replacement of IMAP, but any new standard should first be widely accepted by everybody before the old one is disabled.

<pre class="moz-quote-pre" wrap="">

<pre class="moz-quote-pre" wrap="">
I think he means that Google generally shows not much respect for
standards, by practically forcing OAUTH2 on IMAP etc.. I say
"practically", because they make using an IMAP password so difficult
that most of our Thunderbird users won't be able to do it, which
practically forces us to use OAUTH2, but technically, the possibility is
still there. It sounds like the user referred to that.

<pre class="moz-quote-pre" wrap="">

The OAuth2 authentication "callout" from
SMTP and IMAP to a browser session is standardized with the IETF in the
SASL Framework with RFC 6750. So, it's as proprietary as any other IETF
Proposed Standards.

An overview of the registered SASL Mechanisms is here:
[2] <a class="moz-txt-link-freetext" href="https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml">https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml</a>

RFC 7628 «A Set of Simple Authentication and Security Layer (SASL)
Mechanisms for OAuth»
Search for OAUTHBEARER therein.
[3] <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7628">https://tools.ietf.org/html/rfc7628</a>

OAuth 2.0 is itself RFC 6750 «The OAuth 2.0 Authorization Framework:
Bearer Token Usage»
[4] <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6750">https://tools.ietf.org/html/rfc6750</a>

Thanks for these references. I cross-read RFC 6750, but it does not seem to standardize how to integrate OAUTH2 with IMAP.

If you've tried to implement OAUTH2 correctly in a mail application (not a website), then you'll quickly notice serious problems. OAUTH2 leaves tons of things implementation-specific, but these details matter a lot in the implementation. See what the author had to say about it: https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529 If you try to implement it as a client, you notice that very quickly.

A few quotes from RFC 6570 that should give immediate laughs to everybody who ever implemented a standard:

• No response defined
  "4. Example Access Token Response. Typically, a bearer token is returned to the client as part of an OAuth 2.0 [RFC6749] access token response. An example of such a response is:". Now, I love examples in specs. The problem here, there is no actual specification. There is only this example. "Typically" is not good enough, if you implement an app for millions of users.
• Scope is not defined.

My minimum bar for a "standard" is that I can implement it in a client, and then it will work with every server that implements the same standard. Given that we talk with thousands of ISPs, I cannot "know" or hardcode stuff about the ISP. This is most definitely not the case for OAUTH2, not even for the core spec.

Concrete things that I'm missing in our case:

• Definition of the specific SASL scheme, so that I can connect IMAP with OAUTH2. (As said, this must work 100% identical for all ISPs.)

• Knowing how I get the JSON result, given that I'm in an interactive browser session.

• Google says I should use the system web browser for their OAUTH2 login. I can launch a URL there, but wouldn't know how to follow which URL we're at or get the JSON result from that, given that there is no defined API that works cross-browser. Obviously, we'd need an API for all of Windows, Mac, Linux, Android and iOS.

• The "scope" is currently completely up to the ISP to define, yet I need to pass the right scope in. I'm dead already with this little detail. This would need to be defined in a standard.

• Google, Microsoft and others want me to register my application and authenticate the calls from my app. That poses 3 concrete problems:

• Given that I'm Open-Source, that's theoretically impossible. Thunderbird simply publishes its key and begs people not to use it. The silliness of that should be obvious.

• I have to enter into a legal contract with Google and Microsoft. That means they can stipulate legal terms on me. That is highly problematic and goes against any idea of an open standard.

• It's practically impossible to get the secrets from all ISPs in the world, because there are thousands. Note that all app authors would need to get the secrets for all ISPs. Imagine I just want to make an open-source "mail check" app. That's practically impossible. (This "imagine" is not just theoretical. I've created several mail check apps in my life, one of them got 3 million users.)

• Definition of how expiry works, exactly. It makes a difference whether a session lasts 6 minutes or 6 hours or 6 months or forever. The UI would be different, too. Take, for example, a non-interactive mail check session. And your token expires. This is a serious problem in some scenarios. It has to be clearly defined when the various tokens expires. Note that there are 3 different expiry times involved (server, auth token, refresh token, unless I missed some more).

Before all of these problems are resolved in a standard, OAUTH2 isn't a standard for me. It's a framework, not an actual protocol.

Ben