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

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.

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.

I simply cannot believe it. One month since the initial bug report and no fix yet; shouldn't this be a high priority issue?

The bug hit me just yesterday. Our university had the grandiose idea to switch their email server from a local one to the Microsoft 365 cloud.

Looking at the number of people that are using Linux, or macOS-based operating systems, I'd image that thousands of users are affected by this broken implementation on our campus alone. And we even paid for that mess with taxpayer's money.

You would assume that these things are being tested before they are being deployed on a large scale?! Well done Microsoft, well done...

I chased it up on the 30th and no update - and I did point out that they had been sat on a service affecting fault for a whole month.

My previous advice still stands. Each individual O365 system administrator with affected users needs to be raising their own service request in Admin Centre - and perhaps cross referring to the one I have already posted up if they are certain they are seeing the exact same fault. It only takes a few seconds to do this from the O365 Admin Centre menu (see below) so there is no excuse not to, if people want to see this fixed.

Imagining that thousands* of users are affected is not the same as Microsoft having it evidenced to them in the form of incident reports.

*You may well be right, but remember that this is far less likely to affect corporates who will tend to own and be in complete control of end users devices, and will generally be on Outlook over MAPI - so this will simply not be on Microsoft's radar as a priority unless those of us who are affected put it there.

My O365 tenant is non-profit related where I have no control whatsoever over the email client apps my users choose to use, and educational establishments will tend to be in a similar position with their students.

I simply cannot believe it. One month since the initial bug report and no fix yet; shouldn't this be a high priority issue?

The bug hit me just yesterday. Our university had the grandiose idea to switch their email server from a local one to the Microsoft 365 cloud.

Looking at the number of people that are using Linux, or macOS-based operating systems, I'd image that thousands of users are affected by this broken implementation on our campus alone. And we even paid for that mess with taxpayer's money.

You would assume that these things are being tested before they are being deployed on a large scale?! Well done Microsoft, well done...

Morning all. Not much to report yet but I have just been asked to run a test script by Microsoft this morning.

For the non-technical amongst you, this involved a Microsoft product called Powershell running locally on my machine, and the Microsoft script connects to one of my affected mailboxes and issues IMAP commands directly to it. i.e. there is no-ones MUA involved in this test.

It is one particular command - LSUB - that doesn't work on an affected mailbox. That is entirely as expected as this thread shows that some MUA products actually report LSUB as being the problem in the error message they generate.

Conversely, when I run the exact same script (i.e. including the same LSUB commands) against one of my working O365 accounts, the LSUB commands work as expected.

So really, we're just waiting for Microsoft to establish where their problem is.