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

I think the issue is a little more nuanced than Microsoft dropping the support of LSUB and not telling anyone + it wouldn't be on some mailboxes and not others. As you might recall, I have a test script Microsoft sent to me. After I'd done my initial testing and reported back to them, I added the IMAP command CAPABILITY to their script which asks the server to report back what IMAP standard it is working to. The results from my test are below:

Affected mailbox:

2022-11-23T16:49:40.4595128+00:00 C 0002 capability

2022-11-23T16:49:40.4887962+00:00 S * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS MOVE ID UNSELECT CLIENTACCESSRULES CLIENTNETWORKPRESENCELOCATION BACKENDAUTHENTICATE CHILDREN IDLE NAMESPACE LITERAL+

0002 OK CAPABILITY completed.

Unaffected mailbox:

2022-11-23T16:56:22.8614932+00:00 C 0002 capability

2022-11-23T16:56:22.8885873+00:00 S * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS MOVE ID UNSELECT CLIENTACCESSRULES CLIENTNETWORKPRESENCELOCATION BACKENDAUTHENTICATE CHILDREN IDLE NAMESPACE LITERAL+

0002 OK CAPABILITY completed.

You will see that the server reports exactly the same on both mailboxes - IMAP4 Rev1 - and that standard includes the LSUB command.

The Vivaldi folks obviously hit the same issue with their MUA as everyone else and I see in one of those replies that they noticed Microsoft's servers were reporting Rev1 too. I assume what they have done is engineered the problem out altogether by issuing a new build compliant with Rev2 which doesn't use the LSUB command anymore as it is obsolete in that standard. Nothing wrong with that approach, and other MUA developers could do the same with their products - accepting that they are being forced into unplanned code changes with limited testing, and that carries its own challenges and risks.

Thank you for clarifying.

Seeing that the server response is the same for affected and unaffected accounts, this points towards an account-specific configuration file issue, doesn't it?

I am not sure how this is implemented on the server side though.

It does tend to point that way, but my money is on some deep and obscure infrastructure issue.

When I set a new user up in O365, it's literally a one minute job. You just assign what O365 services the user has (Exchange online etc.) and that's it. There is virtually nothing you can change config wise or would want to. I've looked for patterns in the way affected/unaffected accounts are setup and found absolutely nothing so far.

The only clear and verified pattern I have actually seen to this is the one I noted early on in this thread and fed back to Microsoft. i.e.

My AFFECTED accounts were all being accessed via IMAP at the time the fault materialised.

My WORKING accounts* had never been accessed with IMAP before, and were added to mail clients AFTER the fault materialised by way of testing.

*These were in fact some test accounts of mine, but they have been setup for years, and are identical in setup to all other user accounts.

I originally assumed that this was some glitch and if I could find a way of resetting the IMAP interface on an affected account, it would spring back into life. As an administrator, I can turn IMAP off/on for an individual user account - so I tried that on one of my affected accounts and it made no difference.

The only clear and verified pattern I have actually seen to this is the one I noted early on in this thread and fed back to Microsoft. i.e.

My AFFECTED accounts were all being accessed via IMAP at the time the fault materialised.

My WORKING accounts* had never been accessed with IMAP before, and were added to mail clients AFTER the fault materialised by way of testing.

I have three different O365 accounts, and I have been using all three with IMAP & OAuth2 (Thunderbird on Linux) for over a year. Now two of them are affected by this issue, while the third one is still working fine. No idea what the difference is between the working account and the affected ones.

Not a situation I've personally seen. Are all three accounts on the same tenant just out of curiosity?