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

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.

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.

Microsoft do publish major incidents, because system administrators see these on the system health view in the Admin Centre - and you can see there are some currently showing below. Just not this issue yet.

There are two things that can constructively be done by system administrators in this case.

1. Get their own ticket logged as I have been saying for some weeks, so Microsoft can see what the service impact looks like.
2. Help users with any workarounds.

We'd probably all agree that Thunderbird users have an adequate workaround. But even using Outlook Online as the very worst case doesn't have to be quite as annoying as it sounds and it is within system administrator's gift to help.

For example, I have users who by choice, only ever access my service via Outlook Online - and what I do to make their lives easier is give them access to an application called Power Automate in O365 and instructions on how to setup a notifier message. What this does is trigger when a new mail message arrives, and sends a separate email message to a personal account of their choice with the subject and sender added to the body of the message so they know what it might be about and whether to bother logging on to take a proper look. I could see this being helpful for students in an educational setting for example.

It's quite common for us system admins to universally block the users from setting up autoforwards to external/personal addresses as it's a potential leak of corporate info. But depending on the particular situation, that policy could be temporarily relaxed as an alternative to the notifier message approach above. O365 can provide alerts and reports to allow that situation to be managed.

To be clear, I'm not trying to defend Microsoft. I am simply pointing out that in the world of relatively cheap cloud computing, there is actually a price to be paid in terms of service and support. But on the flip side, this is the first incident that has consumed any significant amount of my time in five years of operation to date.

Concerning the number of affected users: I want to add that most 'annoyed users' are probably not invested or tech savvy enough to find this single thread in the Microsoft Community forum, which is quite hard to find if one doesn't know the right keywords to describe the issue.

On a side note I am baffled why this forum, besides repeated suggestions for years, has not gained a filter-by-year option of search results yet. It almost looks like this feature is missing on purpose, as it can't be that hard to implement. Yes, you can use search engine syntax to mitigate that, but which run-of-the-mill end-user really is aware of those?

Besides that I entirely agree with you. This is the current reality of cloud computing. But with the power of a service provider of global scale also comes a great responsibility, doesn't it?

I am disappointed.

• Disappointed because there was apparently no thorough testing of the IMAP protocol of whatever has changed on the Microsoft Exchange server side before release of the November update. I would have wished that things had been tested properly before release. Granted, only some accounts are affected, and this may have slipped their oversight. But is there actually any indication that tests over the IMAP protocol were ran at all..? I imagine that Microsoft's development team has a set of test-tenants, each with a few thousand clients inside of some virtualized containers on a spare server. Considering their resources they can be expected to routinely evaluate this test setup automatically before they launch any change on their Exchange servers into the wild. I would bet that their routine set of tests includes their MAPI communication as a target. It appears that they have simply neglected to also test IMAP here. Let me be clear: I am not angry due to the emergence of a bug. I am angry because there is no indication of any testing having been done beforehand, or at least because of the absence of communication indicating otherwise.
• Disappointed because there seems to be a lack of exchange between different channels of the Microsoft support and development teams. Which is apparent by the many support replies, each suggesting that the issue may have to do with the clients and not with the server, even when referencing Ian's support ticket or this thread. Looking at the scale of its operation and power I would have imagined that Microsoft had the proper tools in place to collect bug-reports in real time. And to streamline the communication and work on these bugs in a bidirectional manner. Or is this the proprietary-code hell that hasn't adopted bug trackers like any open source project does nowadays?!
• Disappointed because the communication from Microsoft's side is slow and unsatisfactory. Perhaps there are good reasons for the fix of the bug being delayed. It may be a deep-rooted, convoluted cause that is simply hard to solve, or there may be a good reason for an intentional delay of an already existing fix for an error that they have found weeks ago... Regardless, it would be highly appreciated if they were more open in their communication. For example by providing a rough time-frame in which to expect a solution to the issue. Or by providing regular updates from their side. But instead I get the impression that they leave people hanging in thin air. I get it, Microsoft likes secrecy and doesn't want customers too look into their deck of playing cards and what might be going wrong, perhaps for legal reasons. But being ignored is next level customer service hell!