Unable to subscribe to Office 365 IMAP folders from MUA since 2022-11-01

This is purely speculation but I'm wondering if Microsoft broke IMAP again in a similar way on this occasion, issued a quick code patch to fix it, but didn't restart the relevant services properly - leaving some accounts to hang in a broken state with the defective code. Affected accounts could simply be the ones that happened to try and connect with IMAP within the time frame it took Microsoft to realise they had a problem.

I suspect the real cause is different from the hypothesized one.

The reason is that issues with my affected account arose not at the beginning of November,

but only later that month when our Exchange tenant was migrated from a local server to the Microsoft O365 cloud. During this procedure classic password authentication was also substituted for OAuth2.

The issues started immediately after.

I must have missed that point in your particular case. It certainly puts a different slant on it. What does your system administrator think of the issue? Did it affect all of the pre-existing accounts that were migrated? Have they had any problems with any new mail accounts created since the migration took place?

I'm still not convinced of any link to the Oauth2 change though. My affected and unaffected accounts were running Oauth2 long before the change. The Microsoft test script requires you to log in as the user you're testing at the start of the script and it is clearly using Oauth2 to do that. The only difference between an affected and an unaffected account is the server response to the LSUB commands.

I'd take that with a pinch of salt, as I'm sure they didn't provide any justification/evidence for why they think it might be a client side problem + as we know, Microsoft's own test script provided to me exhibits the exact same problems as the various affected MUAs too.

[...]

I suspect this will mysteriously resolve itself at some point.

Gotta love that transparency and open communication; makes you really trust the service provider whom you are dependent on.

This is purely speculation but I'm wondering if Microsoft broke IMAP again in a similar way on this occasion, issued a quick code patch to fix it, but didn't restart the relevant services properly - leaving some accounts to hang in a broken state with the defective code. Affected accounts could simply be the ones that happened to try and connect with IMAP within the time frame it took Microsoft to realise they had a problem.

I suspect the real cause is different from the hypothesized one.

The reason is that issues with my affected account arose not at the beginning of November,

but only later that month when our Exchange tenant was migrated from a local server to the Microsoft O365 cloud. During this procedure classic password authentication was also substituted for OAuth2.

The issues started immediately after.

Wow - I am flabbergasted by the "support's" incompetency.

But hey, let's just archive and forget about these bug reports; problem solved.

Only thing left to do now, is to wait for some forum agent's run-of-the-mill reply to be selected as the accepted answer and this thread to be locked.

When Microsoft "Archive" a case, I think that is just their strange terminology for what everyone else in the IT world calls "suspend". They have archived my case a couple of times when they weren't expecting any update for a few days.

We are on break so my case is archived. They looked at your ticket and they were not convinced it wasn't a client problem. They were convinced that

112 lsub "" *

was much different than

1780 lsub "" *.

I tried to explain RFC3501 and tagged responses but they couldn't understand.

I'd take that with a pinch of salt, as I'm sure they didn't provide any justification/evidence for why they think it might be a client side problem + as we know, Microsoft's own test script provided to me exhibits the exact same problems as the various affected MUAs too.

I found this old posting from 2016 the other day where Microsoft caused the same problem as we are all seeing now. Unfortunately, I can't access the Microsoft incident report after all this time to see if there is any more useful info on what happened - so I have flagged it up to Microsoft.

https://thunderbirdtweaks.blogspot.com/2016/01/outlookcom-office365-imap-subscribed.html

This is purely speculation but I'm wondering if Microsoft broke IMAP again in a similar way on this occasion, issued a quick code patch to fix it, but didn't restart the relevant services properly - leaving some accounts to hang in a broken state with the defective code. Affected accounts could simply be the ones that happened to try and connect with IMAP within the time frame it took Microsoft to realise they had a problem. That would explain:

1. Why the problem affected ALL of the O365 accounts on Thunderbird on my own machine, as all will have been accessed at the same time when I started Thunderbird
2. Why I was able to add several test accounts to Thunderbird after the event, that had never been accessed with IMAP before, and these all work perfectly well - and still do.

I suspect this will mysteriously resolve itself at some point.