On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop <mailop@mailop.org> wrote:
> On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote: > > On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote: > > On 2020/02/07 13:41, Philip Paeps via mailop wrote: > > I think the only viable solution will be to set up forwarders > > Or pass it through a proxy which knows how to authenticate. I'm not > aware of any that have been written yet but it shouldn't be too complex. > > I just spent an instructive half hour in a web browser trying to jump > through the hoops to set this up. Before you can create a "token", you need > to create a "credential". In order to create that you need a "project". And > then you need a "application consent screen". > > All of this to fetch email unattended. > > This is the very definition of "user hostile". > > And reportedly, the "tokens" can expire. So supposedly, this needs to be > done regularly? > > Furthermore: this only fixes *retrieving* email (and then only IMAP, > because it doesn't seem to work for POP3). Presumably similar hoops need to > be jumped to send email through smtp.gmail.com. What fun! > Note you should be able to use the same project and client id/secret for smtp and pop/imap. You might be able to use the same token if you ask for the scopes for both. I know it's annoying. See the previous long thread on why passwords are bad, as for restricting access to your mailbox, there was the excitement from 2018: https://www.androidauthority.com/gmail-snooping-882270/ which lead to Google being a lot more paranoid about third party access https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems . The hoops you're jumping through aren't for users, they're for developers... and they're only the first steps, you then need to get approval <https://support.google.com/cloud/answer/9110914?hl=en&ref_topic=3473162> from Google to expand beyond 100 users. Many open source projects have decided to punt on that, and so they require their users to get their own client tokens. I understand, I made the same choice when I added oauth support to mutt last year. For users just using the most popular mail apps, using oauth instead of password auth is at least as easy. We worked hard to make sure Gmail supported open standards for access by third parties, and not locking our services down or locking people in... and then others took advantage of our users, and that's why we can't have nice things. Access is still possible, the process is still mostly standards based (automated discovery of oauth endpoints and client registration is the missing part)... but there are a lot more hoops. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
