I have this problem also from today, my INBOX failes to update. "User authenticated but not connected" appears. Sending emails still works. In Outlook online the emails are available, so that works. I use Oauth2 since a few months.

So far I've tried

1) Removing OAuth login from Thunderbird password manager and re-authenticating. 2) Setting "maximum number of server connections to cache" to "1" as was suggested on another website 3) Contacting Microsoft, who predictably said "everything is working fine our side, it's a Thunderbird issue".

Setup access to the same inbox on the same PC from eM Client, works fine, I think that proves this is a bug in Thunderbird.

Hello matthewab2001

note that a post from today links this very error message with the fact that the computer has dual network stack IPv4 and IPv6, work around is said to disable IPv6 in the network configuration. About your other client, it may be that its software is not even trying to use IPv6.

Turning off ipv6 fixed this for me on a Windows laptop, not tried linux yet.

K9 Mail on Android has also started failing to connect to Office365 acconts, so its not just TB that is affected. I suspect MS have an issue with there Ipv6 service...

You're absolutely right, disabling IPV6 does appear to be a workaround. Furthermore, disabling IPV4 renders eM Client unable to connect. I will report this to Microsoft.

A better workaround seems to be setting network.dns.disableIPv6 to false on the config editor.

Do you mean network.dns.disableIPv6 to true (rather than false since it's true we want to disableIPV6) ?

Could you kindly remind me how you get to the config editor in Thunderbird these days?

Config editor can be found here:- https://support.mozilla.org/en-US/kb/config-editor

I can confirm setting network.dns.disableIPv6 to true has solved the issue. This does rather point to a fault with Microsoft's infrastructure and I will post an update if there technician says anything useful (i.e anything other than "It's Thunderbirds fault!!!").

deleted

After some unproductive back and forth with a Microsoft technician who was adamant it couldn't be a MS issue, they now seem to at least entertain the possibility that it could be and are asking if I can generate some kind of debugging report in Thunderbird that I can send to them.

Is it possible to somehow generate a report that shows Thunderbird connecting and failing to fetch the mailbox that I could forward to them? I doubt much will be done since the IPV4 workaround is working for most folks, but we can but try.

I had this issue too, and after a couple days of banging my head on various hard surfaces, this thread came up and totally saved my day.

I had a Microsoft support ticket open, too, and since the engineer seemed rather smarter than the average, I pointed him to this thread too so hopefully 1) Microsoft can do something to fix their IPv6 issue with DNS and 2) perhaps save some time to other poor souls.

Interesting, the engineer I'm speaking to insists I'm the only person reporting this!

For reference, the error message that comes out of K9Mail on Android is similar:

"Setup could not finish. Cannot connect to serer. (Command: NAMESPACE response: #6# [BAD, User is authenticated but not connected.])".

It's noteable that this is only happening on K9 when I connect via my Wifi, if I use mobile data, then everything works (regardless of whether IPv4/6 or IPv4 only is set in the data bearer settings). I suspect all of the NAT that seems to go on with Mobile data networks might be "fixing" the problem if the traffic always ends up getting routed to Microsoft via IPv4 when it exits the mobile network.

I suppose the only other possible issue here is that its ISP related and there is some kind of weird routing failure that only impacts IPv6 (I have seen this before). I'm currently away from home on a BT Business line.

I've put in a Microsoft support request of my own now, I have an O365 admin account so perhaps they will take notice.

In the spirit of experimentation, I tried tethering my laptop to my phone and going via 4G internet. That has no impact on the issue for Thunderbird, if IPv6 is on, the connection still fails. So the fact that using 4G fixes things for K9 is a bit of an anomaly!

@ matthewab2001

getting a log is relatively easy with Smtp or Pop, but it is a pain with Imap.

here is the outline with smtp: go to Settings / General, scroll down to the button 'Config Editor', click it, enter 'mailnews.smtp.loglevel', set it to 'All' instead of 'Warning', click the check to validate, then open Tools / Dev tools / Error console, click on the bin to clear it, then try to send a mail. After it fails, copy / paste the error console

For pop3, replace 'smtp' by 'pop3' and try to get mail instead of sending.

For imap, it's more complicated. Open a command line window and go to the thunderbird dir :

cd "c:\program files\mozilla thunderbird" SET NSPR_LOG_MODULES=IMAP:4 SET NSPR_LOG_FILE=C:\temp\log.txt thunderbird

(in this example I have assumed that a c:\temp directory exists, change as needed) then under thunderbird, try to access your imap account. When you have an error message, exit Thunderbird and go to the directory you picked to save log files, here c:\temp in my example. You will find several files, there is usually only one with data (size bigger than 0).

Reply from Microsoft:

"It appears there are some service incidents with IPv6, at the moment no estimated time for resolution. I will keep you updated."

They also pointed me at this thread: https://answers.microsoft.com/en-us/outlook_com/forum/all/thunderbird-imap-responded-user-is-authenticated/062a82f6-e678-4462-88b7-dd6cc318386f

Looks like quite a few people complain.

Reply from Microsoft:

"It appears there are some service incidents with IPv6, at the moment no estimated time for resolution. I will keep you updated."

Hi all,

I want to mention that the Office 365 mail account OAUTH2 authentication failure also occurs with using POP3 to access the mailbox (in addition to the IMAP report above). The workaround to use the Thunderbird Config Editor to set the setting network.dns.disableIPv6 to true also works to restore normal Office 365 POP3 access functionality using OAUTH.

Here are my details:

• using Thunderbird 102.6.1 64-bit on Windows (the current version)
• Starting sometime on Dec. 27, POP3 authentication using OAUTH2 started failing (I had previously switched to using OAUTH2 authentication a few months ago as per Office 365's requirements and it had been working fine with Thunderbird using POP3 and SMTP)

Here are the detailed POP3 log results shown with mailnews.pop3.loglevel set to "All" in the Thunderbird error console (Ctrl+Shift+J).

-- Connecting to pop://outlook.office365.com:995 Connected

...

Possible auth methods: XOAUTH2 Current auth method: XOAUTH2 C: AUTH XOAUTH2 S: + C: Logging suppressed (it probably contained auth information) S: -ERR Authentication failure: unknown user name or bad password Connection closed. --

This problem continues through to (at least) 2023-01-01 at 20:00 Central European Time so it is not fixed on Microsoft's side as of the time of this forum post.

After finding these Thunderbird forum posts (thank you!), I used the Thunderbird Config Editor to set the setting network.dns.disableIPv6 to true (default is false). This presumably caused Thunderbird to only do IPv4 DNS lookups and so only connect to Microsoft's servers using IPv4 addresses.

This solved the problem. The POP3 log now shows:

-- ... Possible auth methods: XOAUTH2 Current auth method: XOAUTH2 C: AUTH XOAUTH2 S: + C: Logging suppressed (it probably contained auth information) S: +OK User successfully authenticated. C: STAT ... --

So, the log is just showing Microsoft reports an OAUTH2 authentication failure when Thunderbird uses DNSv6 AAAA record name lookups but the same account successfully can authenticate using OAUTH2 when Thunderbird uses DNSv4 A record name lookups.

This does really look like a Microsoft-side problem with their IPv6 infrastructure. I will open an Office 365 support ticket to add my report to others on this.

Regards, Tim

@Tim Miller Dyck

Thanks for investigating this. If you could also report on the result of your ticket, it would be nice.