delta August 2019

delta@codespeak.net

1 participants
2 discussions

Regarding OAUTH/Google and the castle [ben.bucksch@beonex.com: Re: [Maildev] Google stopping IMAP and SMTP access an moving to proprietary protocols?]

by holger krekel

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

5 years, 1 month

good things happening / bugs remaining / please run liveconfig

by holger krekel

tons of good changes to rust-core in the last month, 129 merged PRs :) https://github.com/deltachat/deltachat-core-rust/pulse/monthly thanks in particular to friedel, link2xt, kaction, jikstra, treefit! however, Delta/iOS and Delta/Desktop already depend on rust-core and can not do new releases because of bugs/crashes in rust-core. I hope that in the next 2-3 weeks we get to a stable state and can do releases again. a few notes on this: The python liveconfig tests are prepared to run during CI/PRs and would catch a lot of UI-level issues. What is preventing that is https://github.com/deltachat/deltachat-core-rust/issues/331 https://github.com/deltachat/deltachat-core-rust/issues/326 Meanwhile please run liveconfig tests before offering a PR, see README for how to: https://github.com/deltachat/deltachat-core-rust/tree/master/python#install… If you need test accounts to set through "DCC_PY_LIVECONFIG" please mail me. Note that if you run pytest with the "-s" option you'll see the logs/events and where a test fails -- typically during termination which is not really part of the test but rather of its teardown. in general, to achieve "releasability" we need to file and look at all issues marked as bug: https://github.com/deltachat/deltachat-core-rust/labels/bug holger

5 years, 2 months

2024

2023

2022

2021

2020

2019

2018

delta August 2019