On Mon, Feb 10, 2020 at 11:56 AM Jesse Thompson via mailop < mailop@mailop.org> wrote:
> On 2/7/20 6:31 PM, Brandon Long via mailop wrote: > > > > > > On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop > > <mailop@mailop.org <mailto: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 > > <http://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. > > Thank you for sharing this perspective, Brandon. It helps us understand > the "why". It sounds like Microsoft and Google are acting hand-in-hand > to force industry-wide changes since they've gobbled up the market > they've also aggregated most of the credential abuse. > > I'm skeptical that app-specific passwords were a major part of the > credential abuse problem, but I don't have data to challenge it. > > I may be able to force some of our system integrators through "a lot > more hoops", but I think that for the remaining system integration use > cases I'll need to shop around for a smaller mailbox provider that is > willing to commit to supporting basic auth (along with necessary > security controls to mitigate against credential abuse) for the medium > term future. > Ah, one more thing to point out for your case, gsuite admins can whitelist specific oauth clients even if they're not on the google approved list. >From the page i posted above: Domain-wide Installation: The app is used only by G Suite enterprise users. Access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. - To learn how to make your app Domain-Wide Install, see My application has users with enterprise accounts from another G Suite Domain. <https://support.google.com/cloud/answer/9110914#enterprise> I think that'll work for your case, not sure. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
