1807918 - Microsoft 365 IMAP using OAuth2 suddenly (from 20221227+ on) fails with 'User is authenticated but not connected" for a couple of users and installs. But MTP send with same oauth2 token is working OK

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[thirsch]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

No change at all. TB was running and the problem started from one day to the other.
But persisted over TB and/or OS Restarts.
Recreating the account in a new profile and on a new intall on a fresh computer/os did not solve either. Same behaviour on all attempts: retrieving mail fails, while sendng mail with same oauth2 token is workig flawlessly.

Actual results:

Wen trying to sync my inbox for my outlook.office365.com IMAP-account (using oauth2) no new mails make it to the inbox and TB is logging an error "User is authenticated but not connected"
SENDING Mails through smtp.office365.com (using oauth2) is working without producing this error though.

Environment: MAC OS X Monterey v12.6.2, TB v102.6.1 (64bit)

Expected results:

As there was no config change on the client ant the oauth2 token seems to be valid and not expired (as the SMTP send with that token is working fine), retrieving mails bei IMAP and same oauth2 token should not fail.

Maybe MS changed the flow of IMAP-oauth2-Authenticatin (breaking API-changes?).
I found other useres reporting same problem e.g. at: https://www.thunderbird-mail.de/forum/thread/91106-imap-abruf-von-outlook-office365-com-klappt-seit-2-tagen-nicht-mehr/#post508813

Comment 1

[thirsch]

In the following reddit thread (talking about same 'bug') a workaround was mentinoned which mitigatet it for me for now.
https://www.reddit.com/r/Thunderbird/comments/zxelqn/came_back_to_thunderbird_after_christmas_and_now/

The action take to bring back proper o356 IMAP-oauth2 mail retrieval was:
"Go to about:config via the address bar > search for network.dns.disableIPv6 > change the value to true > restart TB."

Comment 2

[dbloughner]

I had the similar issue of "Authentication failure: unknown user name or bad password" returned on o365 POP3-oAuth2, coinciding with the update to Thunderbird 102.6.1

Disabling IPV6 as suggested above resolved the issue for now.

Comment 3

[matsim]

While trying to understand if it's an overall IMAP issue with Microsoft 365 I tested the following IMAP clients against our company tenant: Thunderbird (102.6.1 and 109.0b1 on Windows), K-9 (6.400) and FairEmail (1.2012a).

K-9: Fails in same way if IPv6 is enabled

K-9 shows the same behavior so long as one connects via an IPv6-enabled network, the issue is discussed in the K-9 Forums here:
https://forum.k9mail.app/t/outlook-oauth2-cannot-connect-to-server-command-namespace-response-4-bad-user-is-authenticated-but-not-connected/5931/2

If I switch to IPv4 only, K-9 works. (in my case by switching to IPv4-only cellular data connectivity on my phone).
Another workaround would be to use a DNS resolver that only responds with IPv4 as described in the K-9 forums, since
K-9 doesn't have the same options as Thunderbird.

FairEmail: Works, but seems to only use IPv4 in any case

FairEmail seems to work as is, but digging a bit deeper showed that it that this app only connects to outlook.office365.com
via IPv4 even if the client and the network support IPv6. (I did some network captures).

I'm not yet certain if it is an issue with K-9 and Thunderbird sharing the same "Bugs" (merging code bases?) or if Microsoft
has changed/broken things with on their side. I hope that helps a bit drilling down to the root cause.

Comment 4

[matsim]

As an update, with the hope that it might help other users or tenant admins receiving support requests:

Refining the workaround: Disable IPv6 just for outlook.office365.com

While the workaround with changing network.dns.disableIPv6 = true (from its default false), it basically disables all IPv6 in Thunderbird.

If you just want to force IPv4 for Microsoft 365 IMAP servers, instead define a String Option network.dns.ipv4OnlyDomains = outlook.office365.com. This option is documented in the MozillaZine Knowledge Base article network.dns.ipv4OnlyDomains and was outlined by a contributor in the Microsoft Support Community thread on that subject on page 4.

Are others also affected?

DavMail seems also to encounter issues as based on the same Microsoft on page 6.

Based on that thread Microsoft might be aware of the issue by now and might be working on it. It may look that they have rolled out a change to some or all regions impacting other OAuth IMAP (and SMTP?) clients, not just Thunderbird and K-9. As of writing I have not come across a statement where they would acknowledge it or indicate they cause or the change that might cause these issues.

Is it related to the announced and required change on the Thunderbird Blog?

I don't think so since I permitted the new Application in the Microsoft tenant I have admin rights as outlined in the Thunderbird Blog. I couldn't tell a difference with neither the current release 102.6.1, nor 109.0b1.

Comment 5

[Magnus Melin [:mkmelin]]

Nothing changed on the Thunderbird side for 102.6.1 (still old settings).
Pretty sure we have another bug reported for this as well.
Nothing we can do though, apparently a long standing issue (that for some reason suddenly got worse) which microsoft need to fix on their side.

Comment 6

[thirsch]

Hmm,

Pretty sure we have another bug reported for this as well.
Which ones?
If there are those, why not reference them from here?

Comment 7

[Magnus Melin [:mkmelin]]

Can't find it, so perhaps this is the only one then.