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

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.

Sort of sounds like the same lack of understanding that is causing the problem to start with. I guess this is what happens when you outsource software development and support departments to AIs...

If I was the one deciding, I would take my money elsewhere. Unfortunately, I am not the one deciding here, only the one suffering. So far, I can use Alpine as a workaround, but that will probably stop working if they go ahead and disable password-based login... Then I guess I will just have to tell my bosses that I no longer will read or respond to company email...

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.

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.

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