On 2020-02-10 11:47 a.m., Jesse Thompson via mailop 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.
Thanks!
Jesse Thompson
UW-Madison
Yes, there is still a concern (and maybe justified) that business
considerations at the BIG guys, do 'force' user behaviour in a method
that is geared towards business concerns and not technical or altruistic
in nature.
Eg, AutoDiscovery in Office 2016, where did it go?
Which is why I hope that everyone sees our alternative to transparent
two factor to be more altruistic, no matter which email provider you
use, (providing they have implemented it) without dependency on a 3rd
party systems.
And it would be nice if at least the email clients offered by the big
providers support that, for connectivity to resources other than their own.
I do worry is that the trend is moving towards 'closed eco-systems' for
email, eg you need to use their email clients, to access their email,
and the email clients are only designed to use their email platforms.
But, it has spawned a huge new round of entrants to the email space,
some with just email clients, some with a combination of
client/cloud/hosting provider, and some with just client/cloud closed
eco-systems.
Companies like SaneBox, BlueMail, SuperHuman, and others..
Nice to see many are starting to engage in a conversation regarding open
transparent two factor, eg Sanebox, BlueMail and others.. We hope
everyone supports CLIENTID at the server level, or client level of course.
It has also generated new conversations on whether the 'lock-in' plans
at big providers is ideal, and more and more we hear about companies
that are looking for hosting providers to host their business email,
that isn't locked in, for various reasons..
I do hope the big guys, also keep looking at open methods and standards,
in the end I do think it will be better for their businesses as well,
when their tools are secure, no matter where the email is hosted.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
