Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Brandon Long via mailop]

On Fri, Aug 19, 2022 at 3:58 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 19.08.2022 o godz. 10:31:32 Brandon Long via mailop pisze:
> > I won't say that OAUTH is the perfect solution to all of these issues,
> but
> > it is definitely an improvement for them.
> > Could TLS client certs have been issued in place of the tokens in these
> > schemes?  Maybe?  Not sure what it
> > would have gained, though.
>
> It would eliminate browser from the flow, which is critical for automated
> tools, and I guess OP is talking about such tools.
>
> Think headless systems, and scripts working in background without direct
> human intervention.
>

The browser only needs to be in the flow for the initial grant.  When I was
working
with the gmail oauth tools, it just meant copying & pasting between the
browser and
the tool, but I guess that flow is being deprecated (for Google) due to
issues.

https://developers.google.com/identity/protocols/oauth2/resources/oob-migration

OTOH, if you're running on cloud vms (or other execution environments), you
probably have a
mechanism to use the local authority to retrieve oauth tokens to use as
well, ie on GCE
it's with the metadata server, available on GCE/GKE/GAE/GCF/CR

https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#applications

hmm, I guess azure & aws have a similar metadata service, but I didn't see
quickly how to do a similar
thing.

You can also use mTLS to get oauth keys on Google Cloud:
https://cloud.google.com/architecture/using-mutual-tls-to-obtain-short-lived-credentials

I'm sure all that probably breaks down to access Gmail since you won't have
an account for the service account, we'd need to
extend IAM to Apps in some fashion for that.

Sorry, none of this is helpful to the original poster.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Jaroslaw Rafa via mailop]

Dnia 19.08.2022 o godz. 10:31:32 Brandon Long via mailop pisze:
> I won't say that OAUTH is the perfect solution to all of these issues, but
> it is definitely an improvement for them.
> Could TLS client certs have been issued in place of the tokens in these
> schemes?  Maybe?  Not sure what it
> would have gained, though.

It would eliminate browser from the flow, which is critical for automated
tools, and I guess OP is talking about such tools.

Think headless systems, and scripts working in background without direct
human intervention.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Alan Hodgson via mailop]

On Fri, 2022-08-19 at 10:19 -0500, Mike Hammett via mailop wrote:
> 
> I wonder: How do other Microsoft Office365 customers mitigate this
> situation?

If O365 no longer meets their needs, I guess maybe they'll have to
use something different. Or change their needs.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else seeing Avast AVG doing bad modifications of emails?

[ml+mailop--- via mailop]

On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:

> Sorry, thought it was clear, they are using bare line feeds on their
> injected headers..

Hmm, I've seen that bug before in some software at $WORK :-(
They didn't even notice it until some DKIM verifier finally failed
due to that bug.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else seeing Avast AVG doing bad modifications of emails?

[Michael Peddemors via mailop]

On 2022-08-19 09:55, ml+mailop--- via mailop wrote:

On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:

The reason we are seeing this behavior for 2 antivirus:  Both AVG and


Can you share which "bad modifications" are made?



Sorry, thought it was clear, they are using bare line feeds on their 
injected headers..



--
"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://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Brandon Long via mailop]

On Fri, Aug 19, 2022 at 3:06 AM Stuart Henderson via mailop <
mailop@mailop.org> wrote:

> On 2022/08/19 09:08, Gellner, Oliver via mailop wrote:
> > Hello,
> > IMAP, SMTP etc are still being supported with Office365. What gets
> > disabled is Basic Auth for some services. Microsoft announced the
> > decomission of Basic Authentication three years ago and all tenant
> > administrators have been notified several times in the meantime about
> > this change. Originally the change was planned for 2020, but due to
> > interoperability issues it got postponed until 2022. So while I'm no
> > Microsoft fellow I don't think anyone should be caught unprepared.
>
> The interoperability issues have not been fixed though.
>
> > If you need POP3 or IMAP4 access with Basic Auth, then you can either
> > put a proxy or other email server in between which speaks Basic Auth
> > on one side and OAuth on the other.
>
> That proxy will have the same issue as seen by other tools accessing the
> OAuth2-only services. Hideously complicated configuration, having to keep
> tokens refreshed, etc.
>
> It would seem sensible for operators who want to require something
> stronger than basic authentication to have a way to use TLS with client
> certificates as an alternative to OAuth2, it would be a lot more
> straightforward to handle on the client side. Unless they have other
> motives. It's not really surprising to see this exact thing mentioned
> on https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish


Who thinks managing and refreshing client TLS certificates is easier than
OAUTH2?

I know here at Google we use them extensively with our beyondcorp system
for browser
access to internal tools, and I don't know the amount of effort the corp IT
folks have put into
making it work, but it's far from trivial on the user side.

Given that Google is in the same position in regards to preferring OAUTH
over username/password,
I understand the pain from both sides which is being captured here... but I
don't think TLS would solve
the same problems... perhaps purely in the enterprise space it could work,
which I guess is the
focus here.

Ie, we use it at Google for multiple improvements:
- Stop using just passwords and support other auth mechanisms including 2FA
- Force the user to the browser or OS components for login which are
standardized and have
  much stronger login controls and protections due to the resources put
into this flow.  We've had
  anti-abuse and anti-hijacking teams working on these flows for a very
long time at this point.
  They will then be able to take advantage of improvements to those without
having to update the
  individual application... for instance, the most popular user operating
systems are all moving to supporting
  FIDO2 and WebAuthN directly.
- Better and more controlled error messaging including in multiple
languages... as stated in the original
  message, many clients have poor to non-existent support for login
failures, many treating any failure as
  wrong password.
- Tie a particular authorization to a particular set of abilities.  This
means that if the tokens are stolen, the
  data that's available is limited.  The user is also able to judge whether
a particular ask for access is what
  they want.  That said, email is often the keys to the rest of the
kingdom, so the access level is really high
  anyways... and users will give away just about anything even if asked.
- Tie a particular authorization to a particular application.  There has
been a lot of abuse by third parties with
  access to user data, and the holders of that data have been held
responsible in the court of public opinion
  and sometimes in actual court for that, especially as laws like the GDPR
propagate.  0365 and Workspace
  both allow access to applications on an admin whitelist basis, which is
certainly easier than the certification
  process that is required for consumers.
- Tie a particular authorization to a particular device... this one is not
strongly done, but the mechanism means
  in practice that separate devices are authorized separately.  This helps
with some antiabuse investigations
  and enforcement, especially as users travel.
- Time limit a particular authorization.  By requiring refreshes at
intervals, re-evaluation of the authorization can
  be done.

I won't say that OAUTH is the perfect solution to all of these issues, but
it is definitely an improvement for them.
Could TLS client certs have been issued in place of the tokens in these
schemes?  Maybe?  Not sure what it
would have gained, though.  Maybe it would have been based on mTLS if that
had been available earlier.

And yes, the fact that the OAUTH discovery and registration standardization
came much later, and the fact that
due to the newer requirement for application certification that hasn't
become something that is well supported
is unfortunate for these cases.

As for the embrace and extend argument, OAUTHBEARER used here is an RFC
from 2015, and O

Re: [mailop] Anyone else seeing Avast AVG doing bad modifications of emails?

[ml+mailop--- via mailop]

On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:
> The reason we are seeing this behavior for 2 antivirus:  Both AVG and

Can you share which "bad modifications" are made?

-- 
Address is valid for this mailing list only, please do not reply
to it directly, but to the list.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Anyone else seeing Avast AVG doing bad modifications of emails?

[Michael Peddemors via mailop]

The reason we are seeing this behavior for 2 antivirus:  Both AVG and
Avast antivirus are owned and operated by the same company - Avast
acquired AVG in 2016.

I believe both platforms are using the same cloud proxy system - with
the common issue that said cloud proxy is RFC ignorant with regards to
how line endings in SMTP are supposed to work.

As per RFC 5321:

   The custom of accepting lines ending only in , as a concession to
   non-conforming behavior on the part of some UNIX systems, has proven
   to cause more interoperability problems than it solves, and SMTP
   server systems MUST NOT do this, even in the name of improved
   robustness.  In particular, the sequence "." (bare line
   feeds, without carriage returns) MUST NOT be treated as equivalent to
   . as the end of mail data indication.




--
"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://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Mike Hammett via mailop]

Down with big mail! ;-) 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Benoît Panizzon via mailop"  
To: mailop@mailop.org 
Sent: Friday, August 19, 2022 1:41:21 AM 
Subject: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP. 

Hi Team 

I am involved in a large non profit organisation in Switzerland. 

A couple of years ago, that organisation got persuaded to switch to 
Office365 as they got a good offer for non profit organisations. One of 
the promises at that time: Everyone could continue working as before as 
all clients could connect via IMAP and SMTP, so migration all existing 
volunteer accounts and tools would work seamlessly. 

Most email user are 'external' volunteers. 

Now more and more co-volunteers, including myself get locked out of 
their email accounts, because Microsoft disabled non Oauth2 token 
authentication. Tools stop working. (usually found out after repeatedly 
going through the password reset recovery procedure and still not being 
able to log in). 

Using the web-based tools is not an option. 

The Problem: Most client are unable to use Oauth2. There are 
mailinglist tools which connect to a mailbox to process bounces as 
example. But any other tool generating emails and sending them via SMTP 
is affected. 

Some tools are able to do Oauth2, but the help from the 'Domain 
Administrator' is needed, to register those tools as 'trusted app' with 
Microsoft Azure to get a unique client-id for that tool, but then again 
the token renewal then fails after some time (this needs to be 
done via a HTTP request somehow) needing a lot of attention to keep 
those tools running. 

Microsoft Support states, they won't re-enable tokenless authentication 
and the provide no help at all to get tools back online which do not 
work any more. 

I wonder: How do other Microsoft Office365 customers mitigate this 
situation? 

-- 
Mit freundlichen Grüssen 

-Benoît Panizzon- @ HomeOffice und normal erreichbar 
-- 
I m p r o W a r e A G - Leiter Commerce Kunden 
__ 

Zurlindenstrasse 29 Tel +41 61 826 93 00 
CH-4133 Pratteln Fax +41 61 826 93 01 
Schweiz Web http://www.imp.ch 
__ 
___ 
mailop mailing list 
mailop@mailop.org 
https://list.mailop.org/listinfo/mailop 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Gellner, Oliver via mailop]

On 2022/08/19 12:03, Stuart Henderson wrote:
> It would seem sensible for operators who want to require something
> stronger than basic authentication to have a way to use TLS with
> client certificates as an alternative to OAuth2, it would be a lot more
> straightforward to handle on the client side. Unless they have other
> motives.

I agree that mutual TLS would be a good alternative to Oauth, but then again no 
one at Microsoft cares what I or others on this list think. The bottom line is: 
If you don't like Microsofts Modern Authentication scheme, don't use O365 as 
your mailbox hosting provider. Maybe Microsoft will delay the decomission of 
Basic Auth once more for selected tenants, but this will only buy you some 
additional months of time.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft 365 - Regular auth for IMAP/SMTP

[Luke Thompson via mailop]

Hi,

Typically we find IMAP can be authenticated against "normally" once 
security defaults are disabled. They are working to enforce this onto 
tenants, so it would be an uphill battle.


https://docs.microsoft.com/en-us/microsoft-365/business-premium/m365bp-conditional-access?view=o365-worldwide#security-defaults

Good luck,

Luke Thompson
Chief Technical Officer

The Network Crew Pty Ltd
https://thenetworkcrew.com.au
On 19 August 2022 8:01:16 pm mailop-requ...@mailop.org wrote:


Send mailop mailing list submissions to
mailop@mailop.org

To subscribe or unsubscribe via the World Wide Web, visit
https://list.mailop.org/listinfo/mailop
or, via email, send a message with subject or body 'help' to
mailop-requ...@mailop.org

You can reach the person managing the list at
mailop-ow...@mailop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mailop digest..."


Today's Topics:

  1. Re: Microsoft Office365 blocking non Oauth2 authentication on
 IMAP and SMTP. (Gellner, Oliver)


--

Message: 1
Date: Fri, 19 Aug 2022 09:08:08 +
From: "Gellner, Oliver" 
To: Benoît Panizzon , "mailop@mailop.org"

Subject: Re: [mailop] Microsoft Office365 blocking non Oauth2
authentication on IMAP and SMTP.
Message-ID:


Content-Type: text/plain; charset="utf-8"

Hello,
IMAP, SMTP etc are still being supported with Office365. What gets disabled 
is Basic Auth for some services. Microsoft announced the decomission of 
Basic Authentication three years ago and all tenant administrators have 
been notified several times in the meantime about this change. Originally 
the change was planned for 2020, but due to interoperability issues it got 
postponed until 2022. So while I'm no Microsoft fellow I don't think anyone 
should be caught unprepared.


If you need POP3 or IMAP4 access with Basic Auth, then you can either put a 
proxy or other email server in between which speaks Basic Auth on one side 
and OAuth on the other. Or you can move the mailboxes somewhere else, if 
necessary even to an Exchange server if you prefer to stay with Microsoft 
for whatever reason.


Basic Auth with SMTP on the other hand is not being phased out, you can 
still enable and use it.


--
BR Oliver


-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Benoît Panizzon via 
mailop

Gesendet: Freitag, 19. August 2022 08:41
An: mailop@mailop.org
Betreff: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP.


Hi Team

I am involved in a large non profit organisation in Switzerland.

A couple of years ago, that organisation got persuaded to switch to
Office365 as they got a good offer for non profit organisations. One of the 
promises at that time: Everyone could continue working as before as all 
clients could connect via IMAP and SMTP, so migration all existing 
volunteer accounts and tools would work seamlessly.


Most email user are 'external' volunteers.

Now more and more co-volunteers, including myself get locked out of their 
email accounts, because Microsoft disabled non Oauth2 token authentication. 
Tools stop working. (usually found out after repeatedly going through the 
password reset recovery procedure and still not being able to log in).


Using the web-based tools is not an option.

The Problem: Most client are unable to use Oauth2. There are mailinglist 
tools which connect to a mailbox to process bounces as example. But any 
other tool generating emails and sending them via SMTP is affected.


Some tools are able to do Oauth2, but the help from the 'Domain 
Administrator' is needed, to register those tools as 'trusted app' with 
Microsoft Azure to get a unique client-id for that tool, but then again the 
token renewal then fails after some time (this needs to be done via a HTTP 
request somehow) needing a lot of attention to keep those tools running.


Microsoft Support states, they won't re-enable tokenless authentication and 
the provide no help at all to get tools back online which do not work any more.


I wonder: How do other Microsoft Office365 customers mitigate this situation?


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
sich bei uns bewerben, verarbeiten wir personenbezogene Daten. 
Informationen unter anderem zu den konkreten Datenverarbeitungen, 
Löschfristen, Ihren Rechten sowie die Kont

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Vladimir Gabrielescu via mailop]

Sorry but I disagree, as someone who manages multiple 365 tenants, including 
one with 150k users, and one for a small nonprofit, this should not have been a 
surprise for any administrator of the service. As previously mentioned this was 
announced years ago and repeatedly communicated. If you care about security, 
compromised accounts, etc it is  pretty good thing as it allows well managed 
tenants to deploy MFA and reduce the risks of everyone else being attacked via 
compromised accounts. We can't be mad at the big vendors for being not blocking 
abuse and then be mad at them when they try to prevent abuse, there are plenty 
of other better reasons to be mad at them .

They have made their implementation of OAUTH based imap available to developers 
quite a while ago and offered to help with supporting it. Few third party 
clients have chosen to support it, but that is on the third party clients, for 
example Thunderbird was updated to support it quite a while ago. Similarly, on 
the mobile devices that want to use activesync, Apple updated their client to 
support it, Google decided they only want to support modern authentication for 
their own services.

Also please note that SMTP itself is not affected by this change, they plan to 
support that a lot longer for exactly the reasons you outlined.

I hate to tell you this but on this one the fault can only be attributed to 
whoever manages your tenant for not preparing for this change over the last 3 
years or so.

From: mailop  on behalf of Stuart Henderson via 
mailop 
Sent: Friday, August 19, 2022 6:03 AM
To: Gellner, Oliver 
Cc: mailop@mailop.org ; Benoît Panizzon 

Subject: Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP.

On 2022/08/19 09:08, Gellner, Oliver via mailop wrote:
> Hello,
> IMAP, SMTP etc are still being supported with Office365. What gets
> disabled is Basic Auth for some services. Microsoft announced the
> decomission of Basic Authentication three years ago and all tenant
> administrators have been notified several times in the meantime about
> this change. Originally the change was planned for 2020, but due to
> interoperability issues it got postponed until 2022. So while I'm no
> Microsoft fellow I don't think anyone should be caught unprepared.

The interoperability issues have not been fixed though.

> If you need POP3 or IMAP4 access with Basic Auth, then you can either
> put a proxy or other email server in between which speaks Basic Auth
> on one side and OAuth on the other.

That proxy will have the same issue as seen by other tools accessing the
OAuth2-only services. Hideously complicated configuration, having to keep
tokens refreshed, etc.

It would seem sensible for operators who want to require something
stronger than basic authentication to have a way to use TLS with client
certificates as an alternative to OAuth2, it would be a lot more
straightforward to handle on the client side. Unless they have other
motives. It's not really surprising to see this exact thing mentioned
on https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Stuart Henderson via mailop]

On 2022/08/19 09:08, Gellner, Oliver via mailop wrote:
> Hello,
> IMAP, SMTP etc are still being supported with Office365. What gets
> disabled is Basic Auth for some services. Microsoft announced the
> decomission of Basic Authentication three years ago and all tenant
> administrators have been notified several times in the meantime about
> this change. Originally the change was planned for 2020, but due to
> interoperability issues it got postponed until 2022. So while I'm no
> Microsoft fellow I don't think anyone should be caught unprepared.

The interoperability issues have not been fixed though.

> If you need POP3 or IMAP4 access with Basic Auth, then you can either
> put a proxy or other email server in between which speaks Basic Auth
> on one side and OAuth on the other.

That proxy will have the same issue as seen by other tools accessing the
OAuth2-only services. Hideously complicated configuration, having to keep
tokens refreshed, etc.

It would seem sensible for operators who want to require something
stronger than basic authentication to have a way to use TLS with client
certificates as an alternative to OAuth2, it would be a lot more
straightforward to handle on the client side. Unless they have other
motives. It's not really surprising to see this exact thing mentioned
on https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Gellner, Oliver via mailop]

Hello,
IMAP, SMTP etc are still being supported with Office365. What gets disabled is 
Basic Auth for some services. Microsoft announced the decomission of Basic 
Authentication three years ago and all tenant administrators have been notified 
several times in the meantime about this change. Originally the change was 
planned for 2020, but due to interoperability issues it got postponed until 
2022. So while I'm no Microsoft fellow I don't think anyone should be caught 
unprepared.

If you need POP3 or IMAP4 access with Basic Auth, then you can either put a 
proxy or other email server in between which speaks Basic Auth on one side and 
OAuth on the other. Or you can move the mailboxes somewhere else, if necessary 
even to an Exchange server if you prefer to stay with Microsoft for whatever 
reason.

Basic Auth with SMTP on the other hand is not being phased out, you can still 
enable and use it.

--
BR Oliver


-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Benoît Panizzon via 
mailop
Gesendet: Freitag, 19. August 2022 08:41
An: mailop@mailop.org
Betreff: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP.

Hi Team

I am involved in a large non profit organisation in Switzerland.

A couple of years ago, that organisation got persuaded to switch to
Office365 as they got a good offer for non profit organisations. One of the 
promises at that time: Everyone could continue working as before as all clients 
could connect via IMAP and SMTP, so migration all existing volunteer accounts 
and tools would work seamlessly.

Most email user are 'external' volunteers.

Now more and more co-volunteers, including myself get locked out of their email 
accounts, because Microsoft disabled non Oauth2 token authentication. Tools 
stop working. (usually found out after repeatedly going through the password 
reset recovery procedure and still not being able to log in).

Using the web-based tools is not an option.

The Problem: Most client are unable to use Oauth2. There are mailinglist tools 
which connect to a mailbox to process bounces as example. But any other tool 
generating emails and sending them via SMTP is affected.

Some tools are able to do Oauth2, but the help from the 'Domain Administrator' 
is needed, to register those tools as 'trusted app' with Microsoft Azure to get 
a unique client-id for that tool, but then again the token renewal then fails 
after some time (this needs to be done via a HTTP request somehow) needing a 
lot of attention to keep those tools running.

Microsoft Support states, they won't re-enable tokenless authentication and the 
provide no help at all to get tools back online which do not work any more.

I wonder: How do other Microsoft Office365 customers mitigate this situation?


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Andrew C Aitchison via mailop]

On Fri, 19 Aug 2022, Christopher Hawker via mailop wrote:


Hello Benoit,

What mail client is being used, that doesn't support Oauth2?


Benoit seems to be talking about "tools" more than "programs" or "apps", 
so I am not sure that his problem is just mail clients, but likely also 
includes other software, such as tracking and ticketing systems etc.,

that run an organisational information system on top of email.

 From my experience with alpine and fetchmail, Oauth2 support is not 
sufficient; you also need a layer which keeps the token up to date.


This seems to be different for each service/authentication provider
and requires an application specific code, which for open source 
seems to require several of the following: a developer who is happy to
spend large amount of time jumping through licencing hoops including data 
protectiong agreements; users signing up as app developers; weekly 
re-licencing (I don't believe that this is just the user token) or 
substantial fees.




Regards,
Christopher Hawker

From: mailop  on behalf of Benoît Panizzon via mailop 

Sent: Friday, August 19, 2022 4:41 PM
To: mailop@mailop.org 
Subject: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP.

Hi Team

I am involved in a large non profit organisation in Switzerland.

A couple of years ago, that organisation got persuaded to switch to
Office365 as they got a good offer for non profit organisations. One of
the promises at that time: Everyone could continue working as before as
all clients could connect via IMAP and SMTP, so migration all existing
volunteer accounts and tools would work seamlessly.

Most email user are 'external' volunteers.

Now more and more co-volunteers, including myself get locked out of
their email accounts, because Microsoft disabled non Oauth2 token
authentication. Tools stop working. (usually found out after repeatedly
going through the password reset recovery procedure and still not being
able to log in).

Using the web-based tools is not an option.

The Problem: Most client are unable to use Oauth2. There are
mailinglist tools which connect to a mailbox to process bounces as
example. But any other tool generating emails and sending them via SMTP
is affected.

Some tools are able to do Oauth2, but the help from the 'Domain
Administrator' is needed, to register those tools as 'trusted app' with
Microsoft Azure to get a unique client-id for that tool, but then again
the token renewal then fails after some time (this needs to be
done via a HTTP request somehow) needing a lot of attention to keep
those tools running.

Microsoft Support states, they won't re-enable tokenless authentication
and the provide no help at all to get tools back online which do not
work any more.

I wonder: How do other Microsoft Office365 customers mitigate this
situation?


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Christopher Hawker via mailop]

Hello Benoit,

What mail client is being used, that doesn't support Oauth2?

Regards,
Christopher Hawker

From: mailop  on behalf of Benoît Panizzon via 
mailop 
Sent: Friday, August 19, 2022 4:41 PM
To: mailop@mailop.org 
Subject: [mailop] Microsoft Office365 blocking non Oauth2 authentication on 
IMAP and SMTP.

Hi Team

I am involved in a large non profit organisation in Switzerland.

A couple of years ago, that organisation got persuaded to switch to
Office365 as they got a good offer for non profit organisations. One of
the promises at that time: Everyone could continue working as before as
all clients could connect via IMAP and SMTP, so migration all existing
volunteer accounts and tools would work seamlessly.

Most email user are 'external' volunteers.

Now more and more co-volunteers, including myself get locked out of
their email accounts, because Microsoft disabled non Oauth2 token
authentication. Tools stop working. (usually found out after repeatedly
going through the password reset recovery procedure and still not being
able to log in).

Using the web-based tools is not an option.

The Problem: Most client are unable to use Oauth2. There are
mailinglist tools which connect to a mailbox to process bounces as
example. But any other tool generating emails and sending them via SMTP
is affected.

Some tools are able to do Oauth2, but the help from the 'Domain
Administrator' is needed, to register those tools as 'trusted app' with
Microsoft Azure to get a unique client-id for that tool, but then again
the token renewal then fails after some time (this needs to be
done via a HTTP request somehow) needing a lot of attention to keep
those tools running.

Microsoft Support states, they won't re-enable tokenless authentication
and the provide no help at all to get tools back online which do not
work any more.

I wonder: How do other Microsoft Office365 customers mitigate this
situation?

--
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop