30 Aug
2019
30 Aug
'19
6:10 p.m.
Hi all,
some of you might have seen bjoern's post regarding the current problematics with
GMail/OAUTH:
https://support.delta.chat/t/workaround-for-gmail-oauth2-simplified-setup-p…
below i'll inline a post on the Thunderbird-mailing list which is also
discussing Gmail/IMAP policy trajectories. Some folks claimed on that list that
Gmail would be actively discouraging mail apps from using imap and instead
use Gmail-special APIs. There are rumors but no announcements/links.
FYI, since beginning August DC saw a constant flow of people complaining
on twitter, DC contact addresses and other channels, about DC not working
with Gmail anymore. We had submitted a DC application (end july) to Google to be allowed
to continue to use OAUTH (it worked since Feb 2019) but despite multiple contact
attempts we have not heart a human reply, and got an initial "rejected" without
any reasons. Bjoern even tried to phone a german Google phone number but only
found a machine voice speaking some very generic 0800 numbers to try next.
Apart from taking a lot of time, this situations already damaged early adoption of
Delta Chat so it's more than unfortunate that Google's policy-makers apparently
take
Kafka's Castle as an inspiration for designing social interactions.
cheers
holger
----- Forwarded message from Ben Bucksch <ben.bucksch(a)beonex.com> -----
Date: Fri, 30 Aug 2019 16:44:47 +0200
From: Ben Bucksch <ben.bucksch(a)beonex.com>
To: maildev(a)lists.thunderbird.net
Subject: Re: [Maildev] Google stopping IMAP and SMTP access an moving to proprietary
protocols?
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:
* CAPABILITY IMAP4rev1 UNSELECT LITERAL+ IDLE NAMESPACE QUOTA ID XLIST CHILDREN
X-GM-EXT-1
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.
_______________________________________________
Maildev mailing list
Maildev(a)lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
----- End forwarded message -----