Can't authenticate to Office 365 with oauth

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 Safari/537.36

Steps to reproduce:

upgraded the snap package for thunderbird (sudo snap refresh thunderbird) which took thunderbird from revision 281 (102.6.0-2) to revision 288 (102.7.0-1).

Actual results:

After upgrading, it prompted me to re-sign into my organisation's office 365 account, so I entered my password (the username/email address was prefilled in from the previous version I assume), entering my password gave me a new window asking for my OTP code for 2FA, I gave this and then the window closed and a banner on the screen showed saying authentication failure.

Expected results:

After entering the OTP code, it should have logged me in, and allowed me to use email services.

as an aside, I reverted the package to the previous version using sudo snap revert thunderbird --revision 281, and re-signed in again, and this worked.

To rule out my machine being at fault, I spun up a new ubuntu 22.04 desktop vm, and purged the default thunderbird from the system, and did a fresh snap install of thunderbird which automatically put on the latest revision 288 / 102.7.0-1. I was also unable to log into my office 365 account using 102.7.0-1.

From the Azure side our administrator saw this;

Sign-in error code
9002326
Failure reason
Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: '{origin}'.
Additional Details
The application must fix either the reply URIs registered on the application registration to include a unique reply address of type "spa", or they must fix the token request to not include an Origin header, if being sent from a non-browser client.

Sean will take a look at this. Hopefully a fairly straightforward fix. Thanks for the report, especially the admin side log.

Seconding Andrei's thanks for the admin log.

Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

I ran into exactly the same issue as described above when updating the Thunderbird snap from revision 281 (102.6.0-2) to revision 288 (102.7.0-1) and came across this report when trying to troubleshoot. I can confirm that when using the build linked in the comment above, the Oauth2 authentication works correctly.

Same issue here, using mozillateam ppa on Ubuntu.

(In reply to Sean Burke [:leftmostcat] from comment #4)
> Seconding Andrei's thanks for the admin log.
>
> Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

Yes this seems to work fine standalone, I extracted it and ran thunderbird-bin and after re-setting up my office365 mail account it did connect and allow me to get to my email.

Thanks for the quick help!

*** Bug 1811013 has been marked as a duplicate of this bug. ***

I have the same problem since upgrading from 102.4.2 to 102.7.0. I can confirm that when using the build above OAuth2 authentication works for both outgoing and incoming email.

*** Bug 1811279 has been marked as a duplicate of this bug. ***

Users of version 102 will want to be using [**102.6.1**](http://ftp.mozilla.org/pub/thunderbird/releases/102.6.1/) until probably 102.7.1.
Someone on Kubuntu 22.04 wrote this worked well:
`sudo apt-get install thunderbird=1:102.4.2+build2-0ubuntu0.22.04.1`

Users of nightly (daily) builds will want to use the build artifacts of [Sean's try build](https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=3f93137249556d2e228e02db437d812f8a7d0a34), until at least a day or two after this bug is marked fixed
* [linux](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2)
* [Windows](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/R6SjuwMOSrOxLRuQOadGCQ/runs/0/artifacts/public/build/install/sea/target.installer.exe)
* [Mac](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/KC-mgcR4SX6gMYkaB7SW3A/runs/0/artifacts/public/build/target.dmg)

(In reply to Sean Burke [:leftmostcat] from comment #4)
> Could you try the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XeTLt6FkQaiBK_-Mez5e-A/runs/0/artifacts/public/build/target.tar.bz2 and see if that fixes the issue?

Hey Sean, can you attach your patch here, please?

(Thanks christian for the admin log. Very helpful. And thanks to the MS devs who gave a helpful error message.)

In response to bug 1811279 (see further details there) and this one, I'm still using Ubuntu 20.04LTS , reverted TB back to previous version and then did:
```
sudo apt-mark hold thunderbird
```
... in order to temporary hold this version.

For ubuntu snap users that received an automatic update to version 102.7.0, the following commands will revert to the previous version and temporarily hold updates for one week until the new version is (presumably) released. Make sure you quit any running instance of Thunderbird before executing the commands. Note that the 'hold' option requires snapd v2.58 or higher.

```
snap revert thunderbird
snap refresh --hold=168h thunderbird
```

If a fixed version is released before this time the hold can be lifted by executing:

```
snap refresh --unhold thunderbird
```

Created attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

Comment on attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): 1685414
User impact if declined: Microsoft oAuth account users will not be able to authenticate.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): Although the code changes are isolated to Microsoft accounts, it's possible we break some other oAuth flow. Testing should mitigate this risk. I have personally tested with gmail in addition to outlook.com and it seems fine.

Pushed by <email address hidden>:
https://hg.mozilla.org/comm-central/rev/638f3a309f8c
don't use CORS with client requests. r=sancus

*** Bug 1811752 has been marked as a duplicate of this bug. ***

Comment on attachment 9313356
Bug 1810760 - don't use CORS with client requests. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Approved for er102, pending beta release, per Chat with sancus

wsmwk: I think we should push it through. Like build and ship beta on Monday and build 102.7.1 on Monday to ship Tuesday or Wednesday
sancus: OK sounds good

Thunderbird 110.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/00ca8e3c8d58

*** Bug 1811966 has been marked as a duplicate of this bug. ***

Thunderbird 102.7.1:
https://hg.mozilla.org/releases/comm-esr102/rev/88d80acadbab

*** Bug 1812000 has been marked as a duplicate of this bug. ***

*** Bug 1811998 has been marked as a duplicate of this bug. ***

Based on the report in bug 1812090 the final fix for this bug didn't work.

What happened here is that the patch does not seem to work properly on 102 branch. The "Origin: null" header remains. Daily and 110b2 are both working in my testing.

*** Bug 1812090 has been marked as a duplicate of this bug. ***

*** Bug 1812077 has been marked as a duplicate of this bug. ***

(In reply to Andrei Hajdukewycz [:sancus] from comment #26)
> What happened here is that the patch does not seem to work properly on 102 branch. The "Origin: null" header remains.

Bug 1605305 fixed this, particularly: https://hg.mozilla.org/mozilla-central/rev/28cf8d7e9723#l2.13, also see commit message:
This patch [...] prefers to send **no Origin header instead of Origin: null.**

Just a drive-by thought, without having dug into this problem:

The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs.

Adalbert's comment 29 suggests one specific code block to be related.

You could test a build that removes this one block (red) from mozilla-esr102. Maybe that code block could be slightly improved to keep the header if the origin is non-null. (In other words, only suppress if origin is null).

If that indeed works without other regressions for Thunderbird, you could ask for that change on mozilla-esr102 with ```#ifdef MOZ_THUNDERBIRD```

(In reply to Kai Engert (:KaiE:) from comment #30)
> Just a drive-by thought, without having dug into this problem:
>
> The patch from that bug is probably too big for uplift to mozilla-esr102, and it also had regression bugs.
>
Yes, I don't think uplifting that one is going to happen.
> Adalbert's comment 29 suggests one specific code block to be related.

Yeah, Sean and I found that code earlier. We could patch only that block ourselves the way you suggested or by applying a patch during the build process. A JS workaround would be preferred, however, so we're still investigating that.

(In reply to Kai Engert (:KaiE:) from comment #30)
> Adalbert's comment 29 suggests one specific code block to be related.

That's a misunderstanding. That block likely creates the `Origin: null` header for the "POST" that is run in the fetch() in OAuth2.jsm. However, the functionality of this hunk is added elsewhere. IOW, if you only remove this code without taking the other hunks of the patch, no Origin header will ever be sent, even in situations where it's needed.

In earlier versions of TB ESR there was a branch on the Mozilla ESR repo for uplifting patches that TB needed but FF didn't want to uplift. Looks like this practice was abandoned from TB 91. BTW, the regressions don't look relevant to TB.

Thanks for your helpful clarification!

It does seem likely that we can use a different method in JS rather than trying to patch the fetch code so Sean is currently working on that.

Created attachment 9314399
Bug 1810760 - use HTTP channels instead of fetch for oauth token. r=darktrojan

Created attachment 9314407
Bug 1810760 - use HTTP channels for Microsoft oauth. r=darktrojan

Created attachment 9314408
bug-1810760-use-http-channels-for-microsoft-oauth.patch

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: continued inability to use Microsoft OAuth
Testing completed (on c-c, etc.): verified able to log in to both Microsoft and other OAuth providers
Risk to taking this patch (and alternatives if risky): small potential for negative effect on non-Microsoft OAuth providers

Comment on attachment 9314408
bug-1810760-use-http-channels-for-microsoft-oauth.patch

I'm okay with this, but: from `let result = JSON.parse(resultStr);` downwards, I think this is an exact copy of the last Promise chain function. It would be better if both code branches had a Promise which returned the parsed result, which was then passed onto the last piece. This is a one-off patch for a dead-end code branch that we're hopefully never going to have to deal with again, so you can take or leave my advice.

Additionally, it's missing certificate error handling, but I imagine if that happens on Microsoft's servers we've got bigger problems.

Until this lands, 102 is still affected (again).

(In reply to Sean Burke [:leftmostcat] from comment #37)
> Created attachment 9314408
> bug-1810760-use-http-channels-for-microsoft-oauth.patch
> [Approval Request Comment]
> Regression caused by (bug #):
> User impact if declined: continued inability to use Microsoft OAuth

Created attachment 9314698
1810760-tidy-trunk.patch

May I suggest to simplify/tidy the trunk revision a little? Specifically since `mode` can have three values `cors`, `no-cors` and `same-origin`, having a variable named `useCORS` to imply setting `no-cors` when `false` and doing nothing when `true` is confusing. This also aligns the trunk code a bit more with the ESR code. No functional change. Attachment 9314408 doesn't apply to trunk, so I assume you're planning to apply this to ESR only.

I'm using 102.7.1 -- 1:102.7.1+build1.2-0ubuntu0.22.10.1~mt1 (from MozillaTeam PPA) -- and I can't login to a live.com account. It's from a charitable organisation managed by users so no chance that anyone is using some Azure admin tools or anything like that.

I now get a popup going to https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=9e5f94bc-e8a4-4e73-b8be-63364c29d753&redirect_uri=https%3A%2F%2Flocalhost&scope=https%3A%2F%2Foutlook.office365.com%2FIMAP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FPOP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FSMTP.Send+offline_access&<email address hidden> which bounces to https://login.live.com/Me.htm?v=3 with no action, then when the password for the account is entered the popup closes and I get a message that "Authentication failure while connecting to server outlook.office365.com.".

Thunderbird works for a different live.com account. Is this an actual bug on the Thunderbird end or is MS blocking Thunderbird use?

[Aside: This issue gave me problems with Pihole, as microsoftonline.com actually doesn't appear to be an accessible domain (no nslookup response, even on azure-dns.com nameservers, can't ping), instead login.microsoftonline.com subdomain exists, and appears to terminate at "www.tm.ak.prd.aadg.trafficmanager.net" which as domains go is quite dodgy looking. Presumably there's something going on here to ensure you don't block MS's tracking/ads. Thought this was worth mentioning as the loading of the popup being to a blocked domain was the first step for me in debugging this.]

I should add that https://mysignins.microsoft.com/ tells me that the Thunderbird signins were all "Successful sign-in" despite me being unable to download new mail to Thunderbird.

(In reply to [:dandarnell] from comment #20)
> Thunderbird 110.0b2:
> https://hg.mozilla.org/releases/comm-beta/rev/00ca8e3c8d58

(In reply to Adalbert Chamisso from comment #41)
> Created attachment 9314698
> 1810760-tidy-trunk.patch
>
> May I suggest to simplify/tidy the trunk revision a little? Specifically since `mode` can have three values `cors`, `no-cors` and `same-origin`, having a variable named `useCORS` to imply setting `no-cors` when `false` and doing nothing when `true` is confusing. This also aligns the trunk code a bit more with the ESR code. No functional change. Attachment 9314408 doesn't apply to trunk, so I assume you're planning to apply this to ESR only.

I'd actually like to back this patch out. It turns out it does nothing to address the issue and OAuth is working in trunk due to internal changes in Gecko. Rob, can we revert that change?

Linux users who have experienced this issue...

We would greatly appreciate your feedback ASAP by using linux test build https://drive.google.com/file/d/14KJ90g-AznkURWduESRV5m8TR1t2gjDZ/view?usp=share_link

I just gave the test build a try but I'm getting the error "Couldn't load XPCOM" when starting the thunderbird binary. The dist/bin folder has many broken symlinks and I'm wondering if the test build might be missing some top-level folders?

(In reply to Harm van Bakel from comment #46)
> I just gave the test build a try but I'm getting the error "Couldn't load XPCOM" when starting the thunderbird binary. The dist/bin folder has many broken symlinks and I'm wondering if the test build might be missing some top-level folders?

Here is a try build with the patch applied that should solve symlinking issues: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BuhKe7o5RCC3KxNK-ky0JA/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Daniel Darnell [:dandarnell] from comment #47)
> (In reply to Harm van Bakel from comment #46)
> > I just gave the test build a try but I'm getting the error "Couldn't load XPCOM" when starting the thunderbird binary. The dist/bin folder has many broken symlinks and I'm wondering if the test build might be missing some top-level folders?
>
> Here is a try build with the patch applied that should solve symlinking issues: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BuhKe7o5RCC3KxNK-ky0JA/runs/0/artifacts/public/build/target.tar.bz2

Still no luck I'm afraid. I'm getting the following error on Ubuntu 22.04:

```
XPCOMGlueLoad error for file thunderbird/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
```

Well, it was a bit of a pain to test being a 32-bit executable so I has to install all of the 32-bit library deps - that's likely what the other responders are experiencing. But it does appear to run fine and authenticate to MS365 while 102.7.1 did not.

This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Geoff Lankow (:darktrojan) from comment #50)
> This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

This build seems to work for me with an office365 mail unlike 102.7.1 from the mozillateam PPA.

(In reply to Geoff Lankow (:darktrojan) from comment #50)
> This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

It works on my ArchLinux

*** Bug 1813990 has been marked as a duplicate of this bug. ***

Comment on attachment 9314408
bug-1810760-use-http-channels-for-microsoft-oauth.patch

[Triage Comment]
approved for esr102

Backout comm-central:
https://hg.mozilla.org/comm-central/rev/ca9c8d1b1be1c5def914519b355ea9ac453d3ddc

Backout comm-beta:
https://hg.mozilla.org/releases/comm-beta/rev/d174e55b81ef14caef4cedc1410986e6bf6720f

Per Sean (leftmostcat), no backout is needed on comm-esr102 as the patch in comment 54 includes the backout.

(In reply to Geoff Lankow (:darktrojan) from comment #50)
> This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

Thank you for providing the 64-bit build. I can confirm that it is also working for me with Oauth2 on office365 and two-factor authentication enabled.

Thunderbird 102.7.1:
https://hg.mozilla.org/releases/comm-esr102/rev/bd348a7dd1a9

(In reply to Geoff Lankow (:darktrojan) from comment #50)
> This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

Working for me on Ubuntu 22.04. Mail provider is O365 with a custom OAuth system that our university uses.

I tried the tarball listed above:

This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

Unfortunately, it didn't pick up my existing profile, which has some history. I didn't want to troubleshoot myself into a corner. I reverted back to 1:102.4.2+build2-0ubuntu0.22.04.1 which does work.

If someone has a pointer on how the tarball image can pick up my existing profile under Ubuntu 22.04 , I would be happy to try it.

build 2 of 102.7.1 is now shipped.

Thank you all for your patience and testing results. This gives us more confidence in what we are shipping.

(In reply to Wayne Mery (:wsmwk) from comment #60)
> build 2 of 102.7.1 is now shipped.

Manual update from 102.7.0 to 102.7.1 from Help menu is available now on Win 10, but OAuth2 with M365 personal account is still not available.
(I am the reporter of bug 1799259, a dup of bug 1685414)

Authentication dialog (https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=08162f7c-0fd2-4200-a84a-f25a4db0b584&redirect_uri=http%3A%2F%2Flocalhost&scope=https%3A%2F%2Foutlook.office365.com%2FIMAP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FPOP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FSMTP.Send+offline_access&<email address hidden>) appeared, but it showed nothing (only blank page) and disappeared soon.
Then Tb says "Authentication failure while connecting to server outlook.office265.com."

Error console log:
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIRequest.name] OAuth2.jsm:170
    onStateChange resource:///modules/OAuth2.jsm:170

(In reply to Kosuke Kaizuka from comment #61)
> (In reply to Wayne Mery (:wsmwk) from comment #60)
> > build 2 of 102.7.1 is now shipped.
>
> Manual update from 102.7.0 to 102.7.1 from Help menu is available now on Win 10, but OAuth2 with M365 personal account is still not available.
> (I am the reporter of bug 1799259, a dup of bug 1685414)

It's possible you're experiencing a different issue. To find the real error message, you'll want to open Tools -> Developer Tools -> Developer Toolbox and go to the Network tab BEFORE ATTEMPTING A LOGIN.

Then, filter the requests for "token" and you should be able to find it. Here is a screenshot of the error for this bug: https://i.imgur.com/YqrqAbp.png

(In reply to Andrei Hajdukewycz [:sancus] from comment #62)
> (In reply to Kosuke Kaizuka from comment #61)
> > (In reply to Wayne Mery (:wsmwk) from comment #60)
> > > build 2 of 102.7.1 is now shipped.
> >
> > Manual update from 102.7.0 to 102.7.1 from Help menu is available now on Win 10, but OAuth2 with M365 personal account is still not available.
> > (I am the reporter of bug 1799259, a dup of bug 1685414)
>
> It's possible you're experiencing a different issue. To find the real error message, you'll want to open Tools -> Developer Tools -> Developer Toolbox and go to the Network tab BEFORE ATTEMPTING A LOGIN.
>
> Then, filter the requests for "token" and you should be able to find it. Here is a screenshot of the error for this bug: https://i.imgur.com/YqrqAbp.png

There is no "token" in Network tab.
screenshot: https://i.imgur.com/utaGpVS.png

1st (302): https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=9e5f94bc-e8a4-4e73-b8be-63364c29d753&redirect_uri=https%3A%2F%2Flocalhost&scope=https%3A%2F%2Foutlook.office365.com%2FIMAP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FPOP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FSMTP.Send+offline_access&login_hint=my-account%40outlook.com
2nd (302): https://login.live.com/oauth20_authorize.srf?client_id=9e5f94bc-e8a4-4e73-b8be-63364c29d753&scope=https%3a%2f%2foutlook.office365.com%2fIMAP.AccessAsUser.All+https%3a%2f%2foutlook.office365.com%2fPOP.AccessAsUser.All+https%3a%2f%2foutlook.office365.com%2fSMTP.Send+offline_access&redirect_uri=https%3a%2f%2flocalhost&response_type=code&login_hint=my-account%40outlook.com&uaid=82766f2603ee423aabfef9d21d1139cc&msproxy=1&issuer=mso&tenant=common&ui_locales=ja&epct=AQABAAAAAAD--DLA3VO7QrddgJg7WevrmV7N1PWisLLReOWpDJXJNtvDm9ZJnEKfCZk4l8CxoHnkJgpUoAAdrs9NX5Z-cdkOwIh8GDjZPBvpUWGOhvAZhu8_eBXWEmxCbZUCI-5efh0U9jKN8HUFO9gzhYgfpBGe6jXi9ffPBp63x1rnAxa04pQbnSXw8p-hohf98kZ8-0_zkEuSTWkXLptjOXQVwXhUBQTxrcE5Kgiy1sq-Y9je4yAA&jshs=0#
3rd: https://localhost/?error=invalid_scope&error_description=The%20provided%20resource%20value%20for%20the%20input%20parameter%20%27scope%27%20is%20not%20valid.

Same result for all.
In Request section, "No payload for this request".
In Response section, "No response data available for this request".

(In reply to Kosuke Kaizuka from comment #63)

> Same result for all.
> In Request section, "No payload for this request".
> In Response section, "No response data available for this request".

Yeah, I don't think you're hitting this bug, it's something completely different. I'm going to reopen your bug and move discussion of that issue back there so we don't clutter this one.

(In reply to Wayne Mery (:wsmwk) from comment #60)
> build 2 of 102.7.1 is now shipped.
>
> Thank you all for your patience and testing results. This gives us more confidence in what we are shipping.

When will it hit the mozillateam PPA?

Hi,

I can confirm that after installing the 102.7.1 (64-bit windows) I can now READ e-mails from office365 account, but I still cannot SEND them.
SMTP auth window pops up, everything goes as normal, except that after a couple of seconds TB shows "Login to server outlook.office365.com failed". I've tried deleting OAuth tokens from the password manager and re-authenticating but to no avail.

@hotmail.com still not working.

110.0b3 (64-bit) Windows

windows

I can confirm that with the recent Thunderbird 102.7.1-2 build in the latest/candidate snap channel I can both receive (imap) and send (smtp) emails on a Microsoft O365 account with OAuth2. Other OAuth accounts such as google are also working.

(In reply to Andrey Kiryanov from comment #66)
> Hi,
>
> I can confirm that after installing the 102.7.1 (64-bit windows) I can now READ e-mails from office365 account, but I still cannot SEND them.
> SMTP auth window pops up, everything goes as normal, except that after a couple of seconds TB shows "Login to server outlook.office365.com failed". I've tried deleting OAuth tokens from the password manager and re-authenticating but to no avail.

Here's what I see in the error console:

ailnews.smtp: Command failed: 535 Authentication unsuccessful [GVYP280CA0032.SWEP280.PROD.OUTLOOK.COM 2023-02-01T13:00:01.837Z 08DB04378CB01E1D]; currentAction=_actionAUTH_XOAUTH2 SmtpClient.jsm:515:19
    _onCommand resource:///modules/SmtpClient.jsm:515
    _parse resource:///modules/SmtpClient.jsm:360
    _onData resource:///modules/SmtpClient.jsm:414
mailnews.smtp: Error during AUTH XOAUTH2, sending empty response

IMAP authentication with the very same credentials works though.

TB 102.7.1 as posted to servers does not correct this issue for me (Linux x86-64). After reverting to 102.6.0 , works fine again.

Update:

I tried the tarball listed above:

This is the 64-bit one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/elCjpk4eRS2h-NtTpQXllw/runs/0/artifacts/public/build/target.tar.bz2

This worked properly to send and receive emails from my corporate office365 account. Need to pass the --ProfileManager option to the manual start to ensure that I could select an existing profile.

Hi everybody !
Sorry for my poor english but I want to share a thing with you !

On Arch Linux, i installed TB 109.0b4 and I can send I receive mail from office server.

But, in same time , and I don't know is it possible ! but the same account on TB 102.7.0 (64 bits) that was bad are NOW useful !

I have not the explaination but I want to write this to you !

Why ? somebody could say ?

Thanks

Turns out SMTP will be a different bug. Will post a bug# soon.

<dang, wising one could edit their own post>
official TB 102.7.1 does NOT correct the Office365 issue w/ IMAP (receive mail is still broken). I cannot get far enough to test SMTP 'mail-send'. Both send/receive mail work just fine after downgrade to TB 102.6.0 though.

Because of the inconvenience this issue causes users, 102.7.1 should be retracted until both IMAP and SMTP issues are resolved and *much* positive testing-feedback has been received.

 Just a suggestion- could a config/registry setting be added to TB to disable this recent feature-addition? It would be much easier to instruct users to simply disable this feature than to force them to uninstall/downgrade/reinstall the entire program to restore their email capability.

(In reply to Ron Flory from comment #75)
> <dang, wising one could edit their own post>
> official TB 102.7.1 does NOT correct the Office365 issue w/ IMAP (receive mail is still broken). I cannot get far enough to test SMTP 'mail-send'. Both send/receive mail work just fine after downgrade to TB 102.6.0 though.

I can't reproduce any issues signing into Office365. Do you experience this problem with a new profile or only an old profile? There are some problems with old oAuth settings being retained which we may still need to resolve.

We could revert, yes, but this will only kick the can down the road, because 115 will still be changed. It's not possible for oAuth to continue working the way it does in 102.6.1 and prior.

> Because of the inconvenience this issue causes users, 102.7.1 should be retracted until both IMAP and SMTP issues are resolved and *much* positive testing-feedback has been received.

The testing you're suggesting isn't actually possible. We did have these changes on nightly/beta for some time, and didn't have any problems reported. 102 is its own branch and in addition there is an absolutely absurd amount of variation in Microsoft policies and technical setups, far more than is represented in the beta population.

The reality is, Microsoft REALLY does not want this to work easily.

If you're having problems with *only* SMTP, please see [bug 1775077#c10](https://bugzilla.mozilla.org/show_bug.cgi?id=1775077#c10) and follow the instructions in the comment.

Problem persists for my Linux machines (RHEL), after upgrading to 102.7.1. My Windows machines don't seem to have a problem, but 3/3 Linux machines - nope. And, I'm using pop, not imap.

This is still not working on my Mac or my family member's Mac. When trying to configure for POP3, I get a message that says "You are about to override how Thunderbird identifies this site." The location is set to "outlook.office365.com:995" and it asks me to get a certificate, the certificate lists "outlook.office365.com" but without any ports.

When I try the "Get Certificate" button, it replies "This site attempts to identify itself with invalid information. When I remove the port 995, so the location says "outlook.office365.com" and press the "Get Certificate" button it replies "Valid Certificate, this site provides valid, verified identification. There is no need to add an exception." Except that this point there is only a Cancel button.

If I leave in the port so the location says "outlook.office365.com:995" and press the "Confirm Security Exception" button, it replies "Unknown Identity. the certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature".

And the checkbox on the is unchecked as mentioned in bug 1775077#c10 on the Admin Exchange panel.

(In reply to steve from comment #79)
> This is still not working on my Mac or my family member's Mac. When trying to configure for POP3, I get a message that says "You are about to override how Thunderbird identifies this site." The location is set to "outlook.office365.com:995" and it asks me to get a certificate, the certificate lists "outlook.office365.com" but without any ports.

Haven't a clue what's going on here, and can't reproduce any of this. Not even sure how it could be related to this bug. So you're saying:

1) This worked before 102.7.0 ?
2) Does this work if you make a new profile and login on 102.7.1?
3) If the answer to #2 is "no" does it work on 110 beta?

Thanks.

It worked for 19 years on my own POP3 server, then 10 years on outlook hosted on Rackspace, then after the Rackspace meltdown in November, Thunderbird worked for about 2 months on outlook.office.365.com. Then on about January 23rd, (we had not yet upgraded to 102.7.0), both my Thunderbird and my Wife's started looping on asking for the password over and over again. I tried many different things (ports, protocols, etc.) and never got a download again, the IT guy at my corporate account said that he could see me signing in, but I never got a download. We can get our mail with Mac Mail and iOS Mail, but those are IMAP. I have a couple of decades of thunderbird emails that I would like access to again (I really want to get thunderbird going again).

I lost all my profiles, in the "trying things" stage, so yes, I created a new profile on 102.7.1 and used both autodetect, and ports and protocols experiments. Still looping.

I just downloaded Thunderbird 110.0b3.pkg, I'll give it a try.

 110.0b3.pkg creates a executable called "Thunderbird Daily.app". Starting it up takes you to the Startup screen, where the same problem occurred. I think it said "You are about to override how Daily identifies this site."

So I went to the About page, and there was a button that said "Restart to update" and after the restart the About pane said "111.0a1 (2023-02-01) (64-bit)" This time it did take my password, but maybe did not redirect to the Microsoft OATH page, but signed me in. It does not however download new messages.

The contents of the error log:

```
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
1675313850290 addons.xpi WARN Checking /Applications/Thunderbird Daily.app/Contents/Resources/distribution/extensions for addons
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
```
```
TypeError: can't access property "parentNode", mainKeyset is null
DevToolsStartup.sys.mjs:696:5
Found 0 public keys and 0 secret keys (0 protected, 0 unprotected) RNPLib.jsm:546:15
services.settings: Failed to load last_modified.json: TypeError: NetworkError when attempting to fetch resource. Utils.jsm:330
1675313851206 places TRACE FrecencyRecalculator :: Initializing Frecency Recalculator
1675313851206 places TRACE FrecencyRecalculator :: Start frecency recalculator interval check
1675313851207 places TRACE FrecencyRecalculator :: Got places-init-complete topic
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
1675313851403 Sync.Status INFO Resetting Status.
1675313851407 Sync.Service INFO Loading Weave 1.113.0
Trying to load /Applications/Thunderbird Daily.app/Contents/MacOS/libotr.dylib OTRLib.sys.mjs:64:11
While creating services from category 'app-startup', service for entry 'ExtensionsChild', contract ID '@mozilla.org/extensions/child;1' does not implement nsIObserver.
While creating services from category 'app-startup', service for entry 'OS Integration', contract ID '@mozilla.org/messenger/osintegration;1' does not implement nsIObserver.
Successfully loaded OTR library /Applications/Thunderbird Daily.app/Contents/MacOS/libotr.dylib OTRLib.sys.mjs:72:13
1675313851534 Sync.Service INFO Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0 Thunderbird/111.0a1
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITelemetry...

Well the pasting is not going well, so here is the log in a google doc
https://docs.google.com/document/d/1W0v1b8joDAQlZBCX9qu6D0SgpDRByUJFkAkmi8GZeyY/edit?usp=sharing

(In reply to steve from comment #83)
> 110.0b3.pkg creates a executable called "Thunderbird Daily.app". Starting it up takes you to the Startup screen, where the same problem occurred. I think it said "You are about to override how Daily identifies this site."
> I'll paste the rest in the next comment (Bugzilla problems with large pastings)

I don't think you're experiencing anything related to this bug at all, sorry. If you had problems before upgrading to 102.7.0 it's not possible.

Also, there is nothing wrong with the office365.com SSL certificate, the fact that you're seeing these certificate issues implies you have some sort of antivirus installed that MITMs certificates or something like that, [as described in this support request](https://support.mozilla.org/en-US/questions/1311167).

You should never, ever have to do a certificate override on a mail server and it's not related to oAuth.

Then I restarted Thunderbird (110.0b3 (64-bit)) and tried it again, and got the MS OAUTH pop up which was good progress, and signed in, then on the Thunderbird Account Setup page "Account successfully created" was displayed also good progress.

Now it is downloading 293 of 5444 emails -- a good start! I get a lot of emails, and have lots of Thunderbird filters to deal with them. I'll have to see in the morning if it completed.

I'll look into antivirus issues in the morning. Thanks

(In reply to Fabian Dellwing from comment #65)
> (In reply to Wayne Mery (:wsmwk) from comment #60)
> > build 2 of 102.7.1 is now shipped.
> >
> > Thank you all for your patience and testing results. This gives us more confidence in what we are shipping.
>
> When will it hit the mozillateam PPA?

Still not available on the PPA

Good morning,

It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?

Thank you in advance.

Regards.

David

(In reply to David F from comment #88)
> Good morning,
>
> It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?
>
> Thank you in advance.
>
> Regards.
>
> David

You always needed a 3rd party addon (mostlikly TbSync+EAS) to get calendar access?

(In reply to Fabian Dellwing from comment #89)
> (In reply to David F from comment #88)
> > Good morning,
> >
> > It seems that with 102.7.1, the synchronisation works excepted the calendar. No calendar sync with O365. Anyone has an idea?
> >
> > Thank you in advance.
> >
> > Regards.
> >
> > David
>
> You always needed a 3rd party addon (mostlikly TbSync+EAS) to get calendar access?

The problem with TBSync +EAS, you will not see the details of the meeting and with Owl, you will see the meeting details but if you postpone or modify the meeting, the changes will not be synchronized.

Hello, having issues with connection to Office365 Calendar since 102.7.0 (using EAS + TBSync).

I installed 102.7.1 and the issue persists, even deleted the account and recreating it...

It seems a browser window is directed to the following url after input of EAS account details for creation (Office 365 account type) and it's failing.

https://undefined/?response_type=code&client_id=undefined&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient&scope=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize&login_hint=<accountusername>%40<accountdomain>

Note: <accountusername> and <accountdomain> had actual data, hidden for privacy.

I tried with 102.7.1 under Linux and the problem occurred there. TB 102-.76.1 is working fine.

(In reply to Lars Hennig from comment #92)
> I tried with 102.7.1 under Linux and the problem occurred there. TB 102-.76.1 is working fine.

But not with the calendar...

(In reply to Lars Hennig from comment #92)
Need to correct the version working for me: TB 102.6.1 is working fine for IMAP.
Calendar never worked for me as IT does not allow to access the calendar through Thunderbird.

Testing with Ubuntu 22.04.1:

**102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.
However, the standalone download version ([thunderbird-102.7.1.tar.bz2](https://download.mozilla.org/?product=thunderbird-102.7.1-SSL&os=linux64&lang=en-US)) works fine: login, sending, receiving mails works again.

> **102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.
> However, the standalone download version ([thunderbird-102.7.1.tar.bz2](https://download.mozilla.org/?product=thunderbird-102.7.1-SSL&os=linux64&lang=en-US)) works fine: login, sending, receiving mails works again.

Update: **102.7.1+build2-0ubuntu0.22.04.1** was just released on the Mozilla Team PPA and this build **fixes the problem** for me. Thanks!

There is a problem with upgrading to 102.7.1+build2-0ubuntu0.22.04.1.

1. Currently running 1:102.4.2+build2-0ubuntu0.22.04.1 from mozillateam PPA
2. Close TB and upgrade to 102.7.1+build2-0ubuntu0.22.04.1 from mozillateam PPA
3. Backup my profile folder
3. Run TB
4. Can't authenticate. My university's OAuth popup just says "Stale request". Nothing can do will let me reauthenticate.
5. Close TB and create a test profile.
6. Works
7. Close TB and Downgrade to 1:102.4.2+build2-0ubuntu0.22.04.1
8. Run TB using original profile
9 Same problem as above
10 Close TB and try test profile.
11. Works
12. Restore original profile from backup
13. Run TB. Works.

Running a diff between the backup profile and the broken one shows a lot of changes in lots of files.

I worked with the broken profile and found that by deleting logins.json from the profile I was able to get it working again.

(In reply to emeitner from comment #97)
> There is a problem with upgrading to 102.7.1+build2-0ubuntu0.22.04.1.
>
> 1. Currently running 1:102.4.2+build2-0ubuntu0.22.04.1 from mozillateam PPA
> 2. Close TB and upgrade to 102.7.1+build2-0ubuntu0.22.04.1 from mozillateam PPA
> 3. Backup my profile folder
> 3. Run TB
> 4. Can't authenticate. My university's OAuth popup just says "Stale request". Nothing can do will let me reauthenticate.
> 5. Close TB and create a test profile.
> 6. Works
> 7. Close TB and Downgrade to 1:102.4.2+build2-0ubuntu0.22.04.1
> 8. Run TB using original profile
> 9 Same problem as above
> 10 Close TB and try test profile.
> 11. Works
> 12. Restore original profile from backup
> 13. Run TB. Works.
>
> Running a diff between the backup profile and the broken one shows a lot of changes in lots of files.
>
> I worked with the broken profile and found that by deleting logins.json from the profile I was able to get it working again.

Did you try to remove any auth information from your university's mail server (e.g. "oauth://" entries) from the stored credentials in Thunderbird? I can force a reauth by doing that.

Thunderbird does not support O365 calendars in the first place, so please don't post in this bug if you're having a calendar problem. If you have a problem with an add-on, report that to the add-on author -- not here, where we can't do anything about it.

Bugzilla is also NOT a place for tech support.

(In reply to cr0n from comment #95)
> Testing with Ubuntu 22.04.1:
>
> **102.7.1+build1.2-0ubuntu0.22.04.1~mt1** from the PPA does **not** fix the problem for me, login is still not possible.

Ubuntu PPA is not a build from Mozilla, and it seems they pushed a broken build of 102.7.1 that we never released. For anyone else on the PPA, make sure you are on the NEWEST 102.7.1 PPA build - **build 2**. Yes, there's two. Yes it's dumb.

(In reply to Andrei Hajdukewycz [:sancus] from comment #99)
> Thunderbird does not support O365 calendars in the first place, so please don't post in this bug if you're having a calendar problem. If you have a problem with an add-on, report that to the add-on author -- not here, where we can't do anything about it.
>
> Bugzilla is also NOT a place for tech support.

Sorry, no.

TBSync + EAS worked - with their own known limitations - perfectly before 102.7.0.
This Thunderbird version broke everything and the extensions did not change. So it's definitely Thunderbird (102.7) fault, especially because no changes in plugin compatibility were announced.

And this is a place about Thunderbird issues, right?

Thanks,
   Mario

(In reply to evan.cooch from comment #78)
> Problem persists for my Linux machines (RHEL), after upgrading to 102.7.1. My Windows machines don't seem to have a problem, but 3/3 Linux machines - nope. And, I'm using pop, not imap.

What method do you use for installing on RHEL? I've attempted to reproduce by downloading the Linux tarball, running that version, and adding a Microsoft enterprise account using POP with OAuth, but I was unable to reproduce any issue.

The original bug(data in Origin header) has been fixed, so I'm going to close this, as it's gotten unwieldy. We do have other regressions and new bugs caused by Microsoft, so if you are experiencing any of the following you can comment... **WITH DETAILED STEPS TO REPRODUCE, PLEASE**:

**ON LINUX**, can login on 102.6.1, cannot on 102.7.1: Bug 1814536
Can login to IMAP/POP3 but **NOT SMTP** with OAuth: Bug 1775077 (note a workaround is to use basic authentication eg user/pass for SMTP only)
**On 102.7.1**, have certificate error messages with OAuth: Bug 1814824
**Profiles created prior to 102.7.1 cannot login**, but new profiles CAN: Bug 1814823

If you're experiencing something that doesn't fall into any of these categories, please check the [Microsoft OAuth Meta Bug](https://bugzil.la/1814820) and if your problem is not represented there, file a new bug. Calendar issues should be reported to the respective add-on, Thunderbird does not support Exchange calendars.

Unfortunately, these changes were required by Microsoft policy and technical changes to their OAuth system, and while reverting to 102.6.1 may temporarily solve some problems, the authentication on 102.6.1 is broken and has [other bugs](1685414) in it.

Thank you for bearing with us. We're equally frustrated with these problems and we will fix them.

Also, if you are **on Linux** and think you are still experiencing this specific bug(Origin: null in the header), make sure you are using 102.7.1 as it was released on https://www.thunderbird.net.

Multiple package maintainers built an untested, unreleased build of 102.7.1. If a 102.7.1 build originated prior to Jan 31, 2023, then it is probably a bad build and you need to update again.

*** Bug 1811460 has been marked as a duplicate of this bug. ***

Comment on attachment 9314698
1810760-tidy-trunk.patch

Review of attachment 9314698:
-----------------------------------------------------------------

The revision in question has been backed out of the tree, patch is no longer needed.