Re: [mailop] mailbox auth for system integration

[Michael Peddemors via mailop]

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

Re: [mailop] mailbox auth for system integration

[Jesse Thompson via mailop]

On 2/10/20 2:24 PM, Brandon Long wrote:



On Mon, Feb 10, 2020 at 11:56 AM Jesse Thompson via mailop 
mailto: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
 > 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

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

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 

Re: [mailop] mailbox auth for system integration

[Brandon Long via mailop]

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


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

Re: [mailop] mailbox auth for system integration

[Jesse Thompson via mailop]

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

Re: [mailop] mailbox auth for system integration

[Brandon Long via mailop]

On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop 
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

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

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

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!


Progress is hard.  I am getting old.  I should invest in a good lawn 
chair.  And a lawn! :-)


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

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?


Interesting times.

"Dear customer: if you want me to be able to read your email after 
Google turns off passwords next year, you will have to arrange to 
forward my email to philip+customern...@trouble.is.  Thank you."


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Stuart Henderson via mailop]

On 2020/02/07 14:36, Philip Paeps via mailop 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.
> 
> It sounds like we have about one year for that to happen before people lose
> access to their email.

I don't think that will be a problem.

> > > Unless fetchmail starts supporting Oauth, I will lose access to
> > > certain customer mailboxes when Google decides to stop accepting
> > > "app passwords".
> > 
> > Do you need to use fetchmail? getmail has supported that for some time.
> > (fetchmail development code supports oauth2, but it isn't in a release
> > yet).
> 
> I'm not married to fetchmail.  I had never heard of getmail.  If it supports
> oauth completely unattended, that would solve my use case.  I'll look into
> it more closely.  Thanks for the pointer.
> 
> As far as I understand it though, oauth requires a human operator and a
> webbrowser to generate the tokens.  I wonder how getmail satisfies that
> requirement.

Only when initially granting permissions for a client to access (or if
permissions were revoked and you need to grant them again). Otherwise it's
automatic, you definitely don't need a human operator for each login.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

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.


It sounds like we have about one year for that to happen before people 
lose access to their email.


Unless fetchmail starts supporting Oauth, I will lose access to 
certain customer mailboxes when Google decides to stop accepting "app 
passwords".


Do you need to use fetchmail? getmail has supported that for some 
time.  (fetchmail development code supports oauth2, but it isn't in a 
release yet).


I'm not married to fetchmail.  I had never heard of getmail.  If it 
supports oauth completely unattended, that would solve my use case.  
I'll look into it more closely.  Thanks for the pointer.


As far as I understand it though, oauth requires a human operator and a 
webbrowser to generate the tokens.  I wonder how getmail satisfies that 
requirement.


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Stuart Henderson via mailop]

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.

> Unless fetchmail starts supporting Oauth, I will lose access to certain
> customer mailboxes when Google decides to stop accepting "app passwords".

Do you need to use fetchmail? getmail has supported that for some time.
(fetchmail development code supports oauth2, but it isn't in a release yet).


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

On 2020-02-07 12:51:24 (-0800), Jesse Thompson via mailop wrote:
Microsoft O365 and Google G Suite are both retiring basic 
authentication for client access to mailboxes.  As a result, ALL 
clients will need to support OAuth on a very short timeline.


End-user MUAs aside, I'm worried about systems that rely on a mailbox 
for integration (RT, and the like).  I suspect that there is a long 
tail of those systems that are critical to line-of-business operations 
which don't switch to OAuth in time (for a variety of reasons).


I was holding on to "app passwords" as the last bastion for these 
systems to integrate.


It's unclear if Microsoft will continue to support app passwords with 
their Azure AD MFA product, which only works for organizations who 
don't federate authentication to a local IdP anyway.  Google plans to 
stop creation of App Specific passwords in June 15th, 2020 and 
grandfathering in the rest until February 2021.


Thoughts?


I think the only viable solution will be to set up forwarders to forward 
the email out of Microsoft/Google to a mailbox that does support working 
authentication for systems that don't come with web browsers and human 
operators.


Unless fetchmail starts supporting Oauth, I will lose access to certain 
customer mailboxes when Google decides to stop accepting "app 
passwords".  Unless those customers can forward my email elsewhere, I 
guess I'll have to find some new customers?  Thanks Google!  (Microsoft 
is probably also part of the larger problem but I don't have any 
customers insisting I have a mailbox in their domain.)


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] mailbox auth for system integration

[Jesse Thompson via mailop]

Microsoft O365 and Google G Suite are both retiring basic authentication for 
client access to mailboxes.  As a result, ALL clients will need to support 
OAuth on a very short timeline.

End-user MUAs aside, I'm worried about systems that rely on a mailbox for 
integration (RT, and the like).  I suspect that there is a long tail of those 
systems that are critical to line-of-business operations which don't switch to 
OAuth in time (for a variety of reasons).

I was holding on to "app passwords" as the last bastion for these systems to 
integrate.

It's unclear if Microsoft will continue to support app passwords with their 
Azure AD MFA product, which only works for organizations who don't federate 
authentication to a local IdP anyway.  Google plans to stop creation of App 
Specific passwords in June 15th, 2020 and grandfathering in the rest until 
February 2021.

Thoughts?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop