1777714 - TB 102 break OAuth2 connections to outlook.office365.com

Status: RESOLVED DUPLICATE of bug 1778576

(Thunderbird :: Security, defect)

Description

[evan.cooch]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

Steps to reproduce:

I recently updated TB from 91.10.x.x -> 102.0. Win 10 Pro - fully patched. Previously, been using OAuthy2 and TLS/SSL to connect to POP at outlook.office365.com. Worked perfectly.

Following the upgrade, no longer able to connect to outlook.office365.com, at all.

To confirm it wasn't an addon issue, or anything else, I did a clean install of TB 102 in a fresh Win 10 install inside a virtual machine. I first tried using TLS/SSL and OAuthy2 to connect to pop.gmail.com. Worked perfectly (suggesting the issue isn't with the OAuthy2 implementation in TB). But, when I tried again to connect to outlook.office365.com, failed completely.

Issue has been replicated by a number of people I work with who use TB -- 102 breaks connecting to outlook.office365.com.

Actual results:

No connection

Expected results:

I should have been able to connect to outlook.office365.com, and download email.

Comment 1

[evan.cooch]

As part of experimenting with things, I re-configured and used IMAP instead of POP. Worked perfectly. So, this tells me that something fundamental has changed on the MS side of things. (maybe?) So, perhaps not a 'bug' after all, but merely (another) Draconian decision on the MS side of things?

Comment 2

[Matt]

You might want to try changing the user agent string. Just to see if the Outlook environment is responding differently to the newer version.

Perhaps try Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1

The default can be overridden by setting the preference general.useragent.override in the config editor. See https://support.mozilla.org/en-US/kb/config-editor

The preference does not exist by default, so you will have to add a new string preference.

Is your office set up a business one? OAuth, at least in my case, does not work with free accounts. Office subscription arrangements however are probably being subjected to the process Microsoft have embarked on to automatically disable IMAP, SMTP and POP access to office business users unless a business admin actively enables it. There has been plenty of activity in recent months in support as organisations lock out IMAP, POP and SMTP for "security reasons". Not that any of those doing so can actually advise what the security reason is. My guess is they are just quoting Microsoft and they really have no idea.

Comment 3

[evan.cooch]

Alas, I tried setting the general.useragent.override preference (thanks for the suggestion!), but that didn't work, I'm afraid. Troubleshooting information showed the modified User Agent had been set correctly, so I don't think its a 'typo' or anything that silly on my end.

I think the fact that configuring outlook.office365.com for IMAP connections worked, while my preferred protocol (POP) didn't, is likely informative.

Comment 4

[evan.cooch]

If it helps at all, if I look at the Error Console output, I see the following generated at TB tries to connect to outlook.office365.com via POP:

09:05:20.879 services.settings: Failed to load last_modified.json: TypeError: NetworkError when attempting to fetch resource.
about:accountsettings : Unable to run script because scripts are blocked internally.

Comment 5

[evan.cooch]

Forgot to add - setup is 'business' (well, not stricly -- ['higher education' -- large research-based university). Booth POP and IMAP have been turned on by our site admins (confirmed) -- must be true since both IMPA and POP were working fine with Oauth2 using TB 91.x.x. So, something has changed in TB 102.x.x that no longer plays nice with POP. Which is why I (tentatively) think this is a bug.

Comment 6

[evan.cooch]

And, another byte of information: Using TB 102, OAuth2 works fine form smtp.office365.com.

So, for OAuth2 --- IMAP - 102 works; SMTP - 102 works; POP - 102 fails.

Comment 7

[Far Flung]

I'm using version 103b4 and for me the breakdown with protocols and OAuth2 is:

IMAP - works
SMTP (STARTTLS) - fails
POP - don't use it

Was working perfectly fine last week, this week, nup. How can I debug the SMTP connection? I suspect the change was on the Microsoft side.

Comment 8

[Magnus Melin [:mkmelin]]

Far: smtp would be unrelated (and likely just a network issue)

Comment 9

[evan.cooch]

Indeed - resolved in code hack implemented in TB 103.0b6. Tested against POP for outlook.office365.com, pop.gmail.com, and a few others. All worked without obvious problems.