Joshua Cranmer 🐧 wrote on 30.08.19 01:26:

On 8/29/2019 3:50 PM, Ben Bucksch wrote:

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

... Every protocol that implements SASL is required to list the supported mechanisms, and OAUTHBEARER is the correct SASL scheme.

Right. Just that Google, who we're talking about here, doesn't use it.

1 CAPABILITY:

Google imap.google.com:

<pre class="prettyprint">```
<span class="pun">*</span><span class="pln"> CAPABILITY IMAP4rev1 UNSELECT LITERAL</span><span class="pun">+</span><span class="pln"> IDLE NAMESPACE QUOTA ID XLIST CHILDREN X</span><span class="pun">-</span><span class="pln">GM</span><span class="pun">-</span><span class="pln">EXT</span><span class="pun">-</span><span class="lit">1</span><span class="pln">
</span>

<https://developers.google.com/gmail/imap/imap-extensions>

<https://developers.google.com/gmail/imap/imap-smtp>

Note the complete absense of any SASL mechanisms, not even AUTH=PLAIN or the old AUTH=XOAUTH2. Which underlines my statement that Google doesn't implement the standards properly, or the standards are lacking. In any case, it's not discoverable for a generic client. You cannot support Google without special hacks for Google. That's not a standard.

Yahoo imap.mail.yahoo.com:

\* OK \[CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=XOAUTH2 AUTH=OAUTHBEARER ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS LITERAL+ CHILDREN X-MSG-EXT OBJECTID\] IMAP4rev1 Hello

They do it properly.

web.de imap.web.de:

\* CAPABILITY IMAP4rev1 CHILDREN ENABLE ID IDLE LIST-EXTENDED LIST-STATUS LITERAL- MOVE NAMESPACE QUOTA SASL-IR SORT SPECIAL-USE THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN AUTH=LOGIN AUTH=PLAIN

They are the best, because they require OAuth2 and support all interesting and latest extensions, like LIST-EXTENDED (instead of XLIST).

> > - 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:
> > - ... 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....
> 
>  There are mechanisms to register the client ID dynamically, and mechanisms for the authentication process to tell you where to find the OAuth parameters to do the request (including endpoint locations). However, these mechanisms are optional. We should have made implementation in Thunderbird contingent on providers actually supporting these flows as an incentive to get them to do the work.

If Google requires OAuth2 and doesn't support these mechanisms (could you provide links, please?), that's not helping us, is it?

As long as I need to have special code or hardcoded values for Google, they are not using standards. They support standards, if I can simply code against IETF specs, without additional information for Google, and it works.

For almost all ISPs in the world, it works without special cases. Google and Microsoft are the big exceptions. Apple works just fine out of the box without any special code whatsoever.