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

Steps to reproduce:

Upgraded TB from 102.6.x on my various Linux boxes to 102.7.1. Attempt to connect to outlook.office365.com, using pop (port 995 - SSL/TLS, and OAuth2 authentication). Works perfectly under TB 102.6.x.

Actual results:

Under 102.7.1, attempts to authenticate quickly collapse into an endless loop. Try to connect. office365 prompts for authentication. I supply, TB then keeps bouncing me back to the same authentication request. Almost exactly the same problem people were reporting with 102.7.0. The point upgrade to 102.7.1 was supposed to have fixed this. Nope -- at least on my Linux boxes. Using Windows in a VM (Win 10 under VirtualBox), 102.7.1 authenticates just fine.

Expected results:

Should have been able to pull mail off pop for outlook.office365.com. Was unable to on my Linux machines.

Sean asked:

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

2. I also ask: Can you login with a new profile/new account, or does that also fail?

I'm still seeing error messages from Microsoft due to an Origin: null header in the oauth request Thunderbird makes.

I have Thunderbird 1:102.7.1-1 on debian testing (with updates done just now). I am trying to set add an office365 account (I may have the wrong terminology there, outlook account?) to thunderbird. But the authentication fails and the account setup cannot be completed.

The request that fails is a POST to https://login.microsoftonline.com/common/oauth2/v2.0/token
It has an Origin: null header in the request.
The response is http 400, with a JSON body:

{"error":"invalid_request","error_description":"AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: 'null'.\r\nTrace ID: [uuid recated]\r\nCorrelation ID: [uuid recated]\r\nTimestamp: 2023-02-03 08:22:17Z","error_codes":[9002326],"timestamp":"2023-02-03 08:22:17Z","trace_id":"[uuid recated]","correlation_id":"[uuid recated]","error_uri":"https://login.microsoftonline.com/error?code=9002326"}

If I "Copy as curl" the request, remove the "-H 'Origin: null'", and execute the command, I get a response that looks like a successful authentication.

Closed bug 1810760 claims the Origin null-issue was fixed, but I am not seeing that. Though perhaps I am not interpreting those closing comments correctly.

I tried this both with a new profile, and with my existing profile where I had the same account configured before (I tried deleting and adding it again when authentication started failing).

Closed bug 1810760 claims the Origin null-issue was fixed, but I am not seeing that. Though perhaps I am not interpreting those closing comments correctly.

It looks like I'm getting confused by version numbers, and this is all known and being worked on. Sorry for the noise. For reference, the debian bugreport appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029594

(In reply to mjl from comment #3)

It looks like I'm getting confused by version numbers, and this is all known and being worked on. Sorry for the noise. For reference, the debian bugreport appears to be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029594

The problem is that package maintainers don't understand that they can't just build untested things. We release builds after they've been tested internally, and they never wait for that. So they push out known-broken builds to their users.

The correct, actually released 2nd build of 102.7.1 was not built until Jan 31, and not released until Feb 01. Any builds that originated prior to those dates are almost certainly bad.

(if I sound a little exasperated that's because we've gotten MANY incorrect/misleading reports due to this in the past 2 days :/)

(In reply to Andrei Hajdukewycz [:sancus] from comment #1)

Sean asked:

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

Well, AlmaLinux, which amounts to RHEL. As for the install, dnf install thunderbird from the @appstream repo.

102.7.1-1.el8_7.alma

I haven't tried using the tarball (manually extracting to /etc/lib64/thunderbird, on RHEL-based systems), but I'm happy to try.

2. I also ask: Can you login with a new profile/new account, or does that also fail?

Not quite sure what you're suggesting - if you can give me a couple of step-by-steps here, I'll give it a shot.

In the short term, I have 102.6.1 running - and working - on all my Windows and Linux machines, so I'm not at a 'mission critical' stage. But, I never like to get too far behind the release version.

Note: not sure if this is useful data but...if I try upgrading my Windows machines to 102.7.1, the update doesn't work. On the other hand, if I do a new install under Windows (Win 10 in a virtual machine), 102.7.1 works perfectly. Makes me wonder if the issue has to do with in-place updates (which may or may not work) vs clean, new installs (which seems to work based on my VM installs). Same network, same Office365 back-end.

Just a thought...

So, I'm now increasingly convinced that for me (and perhaps a lot of people) that the continuing issues might be a function of in-place upgrades not working 'perfectly'.

Following a question from Andrei Hajdukewycz (comment 1), I tried a manual install on my Linux boxes. I downloaded the latest tarball, and manually extracted all of the contents into /usr/lib64/thunderbird (where TB is installed on RHEL-based distros), overwriting the 102.6.1 files that were there.

Fired up TB, and was prompted to re-authenticate Oauth2, and....it worked!!! Both pulling mail off pop.office365.com, and SMTP out using smtp.office365.com.

I'll need to figure out the best way to do the equivalent 'manual install' on my Windows boxes.

Or -- perhaps the latest tarball is in fact the right tarball, and the version of TB 120.7.1 released by package maintainers to the Almo repos was in fact out of date.

(In reply to evan.cooch from comment #7)

Or -- perhaps the latest tarball is in fact the right tarball, and the version of TB 120.7.1 released by package maintainers to the Almo repos was in fact out of date.

The tarball on https://www.thunderbird.net is definitely the right one, the Thunderbird website is always the canonical place for the correct build of any version.

https://www.thunderbird.net/

102.7.2 is live, please test and report in this bug if you are still experiencing any issues.

(In reply to evan.cooch from comment #5)

Well, AlmaLinux, which amounts to RHEL.
102.7.1-1.el8_7.alma

Please wait for the 102.7.1-2 release.

I am having a similar problem of Fedora 37 Thunderbird build 102.8.0-1.fc37 installed using dnf. Problems started after the upgrade to 102.7. Have deleted .thunderbird directory and started again to no avail.

Bug 1817735 perhaps? Looks like the fedora packages are a bit broken. Try a binary from thunderbird.net

I just downloaded 102.8.0 and ran it from extracted directory and had the same problem.