Office360 and OAuth2 not working with IMAP

[AEtherScythe]

My company is in the process of switching to Exchange on outlook.office365.com.
I have been using our beloved SeaMonkey with our old e-mail infrastructure and Mozilla since before SeaMonkey.
Unfortunately, I cannot get SeaMonkey to work with our SSO-enabled / OAuth2 authentication scheme on Office365 (via company login).

I referenced this thread:
http://forums.mozillazine.org/viewtopic ... &t=3060515

And this RFE:
https://bugzilla.mozilla.org/show_bug.cgi?id=1293958

I read elsewhere, that SeaMonkey 2.53.x picked up the above RFE, but it isn't working with Exchange on outlook.office365.com.
When I try to use OAuth2 in SeaMonkey, I get a message that outlook.office365.com doesn't work with that authentication scheme.
When I try to use normal (basic) auth, with my password it doesn't work (not surprisingly, since my company insists on SSO via OAuth2).

I even went so far as to install Thunderbird 78.6.0, to confirm that the OAuth2 support works with my company's SSO handling and it does.
So I took that working profile from Thunderbird and copied it to SeaMonkey 2.53.5.1, and SeaMonkey understand the profile perfectly well, but the error message is the same:

"The IMAP server outlook.office365.com does not support the selected authentication method. Please change the 'Authentication method' in the 'Account Settings | Server settings'."

I even went so far as to access the https://outlook.office.com/mail/inbox webmail via SeaMonkey browser, and I authenticated all the way through to Outlook and told SeaMonkey to remember me / save my credentials, but unfortunately that was no help.

I was really hoping that all that was done re: authenticating to https://outlook.office.com/mail/inbox would be stored in the way of cookies and such, so that the SeaMonkey mail client could utilize the same stored credentials for IMAP, but it isn't working that way.

Any advice?
Perhaps some hack to take the outlook.office.com credentials from the browser and copy them to outlook.office365.com IMAP credentials in the profile (and/or cookies)?

Meanwhile, please advise how I can get further diag / debug logging on MacOS to aid in uncovering what exactly isn't working with the OAuth2 / SSO to outlook.office365.com.

[AEtherScythe]

I referenced @frg's comment on a similar topic over here: http://forums.mozillazine.org/viewtopic ... &t=3055147
Hoping @frg or another will have some insights on my post above. :S

[frg]

This needs a bunch of backports. Was only fixed for Thunderbird 77. The first batch will be in todays unofficial 2.53.7b1 pre build. If I manage I will do the remaining parts next but need to make sure caldav access is not affected.

In any case I can't test because I am staying away from google and ms stuff as far as I can So please test todays builds for regressions using OAuth2. It already added support for yandex.com and using pop3 with OAuth2. Might work might not so keep the old one. Bill tested google mail briefly.

FRG

[frg]

The backports now landed. Prerelease builds are available at:

https://www.wg9s.com/comm-253/

Unable to test. gmail still works but no one from the dev team has an office365 account. So please test and let us know. While it is prerelease code it is very stable and should cause not much problems. Still profile compatible with 2.53.5.1 but Lightning needs to be reinstalled if for whatever reason you want to go back.

[Rob_S]

Working fine for me as browser and email client, but I'm just using standard pop mail accounts with Rockland.web.

[RDaneel]

So, not sure of the protocols for reviving an "old" thread - at least this is from 2021!

I have the impression that frg has completed the work to let the SM email client talk OAuth2 to the Office 365 email servers, so I tried today with the Build by Bill(tm) from 20210802 and my usual POP access to my email...

I changed the authentication method from "Normal password" to "OAuth2" and it looked promising at first, going off and asking me in a popup window to authenticate with the Office 365 servers "on behalf of my organization", which seemed to go fine - but when we got back to SM-land and tried to fetch email, it doesn't work ("Authentication failure: unknown user name or bad password") - and yes, I restarted SM before coming here to ask for help.

Note that I *only* changed the auth method, keeping the same "outlook.office365.com" and same <Office365-user> server settings - should I be changing either of these to something else? Reading the MSFT doc

https://docs.microsoft.com/en-us/azure/ ... -code-flow

we see a whole protocol flow described, and I can only assume that the SM client now is doing these things using code inherited from TB (with appropriate backporting work from frg)... so the whole base64 thing is being done for me, and I am not expected to supply some base64 version of my user or password info?

Oh, possibly a clue - I notice that when my email access failed in SM, I *only* needed to change back to normal password authentication, and my email was accessible once more - without asking me again for my old non-OAuth2 password. So clearly the SM email client is remembering my old credentials... might this point at a problem?

I am glad I decided to try this before MSFT eventually requires it.

[frg]

I got confirmation via newsgroup or a bug that imap works. pop3 don't know. Best to backup profile remove old passwords and change settings then retry. When I tested gmail I had to temporary disable NoScript until I saved the password.

FRG

[RDaneel]

Well... setting up OAuth2 for SMTP (still at MSFT, like the POP server) works!

That is, assuming we can believe that the SM/TB code understands that the servers outlook.office365.com (POP3) and smtp.office365.com (outgoing SMTP) are different, and it isn't doing something funny like using the same entry for the two.

Note that I tried changing *both* at the same time to OAuth2, and it didn't help with the POP access.

Also, the OAuth code is really trying to do all the right things... note that ONCE, the first time I tried using it, it both asked for a login in a popup at MSFT, AND it went through a whole second window where it asked me to verify all the privileges my "organization" wanted granted.

But doing the SMTP-side OAuth setup, I *only* was asked to do the MSFT login ONCE (like on the POP side), but was NOT required to do the second "rights granting" window... I take this to mean that it is remembering the answers for this for the "organization", and "knows" it doesn't need to ask again.

Final comments - the "user" and "password" entries are the same for both the POP and SMTP servers, which makes sense as both are using the same Office365 account at MSFT. So while this is likely good - and the "right thing", it doesn't make it easier to separate out the two behaviors.

But like I said, the SMTP access apparently *works* with OAuth2... and if it appears that IMAP works also, then maybe we are just down to POP issues / differences.