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.
Thanks!
Jesse Thompson
UW-Madison
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
