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

I agree that MS does give ample notifications, think this problem isn't an intentional break of subscribing rather a change for something else that happens to break it in some cases. A program I developed several years ago got hit with the discontinuing of basic authentication but it was because I'm not in the MS loop. On Oct 6, at 2:34AM the program stopped working. In researching the problem MS had given ample notice and even had a means of extending the basic support for programs such as this if action was taken by the end of September. Thus the problem was 'ME' not MS. And in fairness to MS in the big scheme of things this problem isn't of high severity in my case since there is a work around with Thunderbird rather an annoyance having all the folders visible.

Thanks for your continuous effort, Mr Midgley.

Here to add some more info about other users affected.

We created an MS support case 3-4 weeks ago, attaching the code you gave, and still haven't found a solution.

I've seen some peers mention their affected tools, and to point it out, we use Roundcube.

There isn't any modification to the open source code, as we use it to power our Webmail built in a CRM.

Can confirm this Subscribe failed issue is affecting our clients using Oauth2, and it all started around the same time this post emerged and some other people noticed this issue.

As some people of this post have experienced, it is annoying that inside the same client using O365, there are users having the "Subscribe Failed" issue and others, with the same tenant and IMAP settings, continuing their lives fine, with all their folders showing or if they just have selected ones.

This annoys users because they haven't done anything different from their peer.

The affected users are only able to see the Inbox folder.

We are in constant communication with the MS Support team (even tho it bothers us a bit that there is silence for some long days), and it looks like we are moving things finally, as they asked us to record and reproduce the issue while this tool is enabled, linked here (https://aka.ms/SaRA-Assisted). Still waiting a response.

We saw the test connectivity URL you gave (https://testconnectivity.microsoft.com/tests/o365) and tried doing some diagnostics, but still it looks like the affected users are all fine, except they aren't.

Hope my comment can show that this is big enough for MS to move things ASAP.

Best regards,

~Arnau

I doubt that the use of the Microsoft Support and Recovery Assistant (SaRA) will get you anywhere.

This tool is designed to look for configuration mistakes on the client side.

It appears that Microsoft insists that the issue exists on either the client or tenant side, while all evidence points towards the MS servers as the root of the issue instead.

In a way they are just pointing fingers and wasting the tenant-administrators' time; this is getting quite annoying by now.

I don't expect them to come up with a fix before beginning of 2023, if at all...

Thanks for your comments. As I mentioned in the thread, the testconnectivity.microsoft.com site isn't actually testing the particular IMAP command which is failing on affected accounts, so that test will always pass.

The only bit of extra testing I have done over the last few days is to send a load of test messages from outside my service into affected and unaffected accounts, and then examine the message headers to see if there was any pattern in the O365 nodes that handled the message. There isn't.

I've also run up Wireshark on my machine to packet capture the response message from the server on affected and unaffected accounts when an LSUB command is issued and this confirms the above i.e. the originating IP address for the reply is pretty random, and you can sometimes see the same IP respond for both affected and unaffected accounts. On both traces.........

Packet 1 - is my machine sending the LSUB command

Packet 2 - Microsoft server acknowledges it

Packet 3 - Microsoft server replies

Packet 4 - my machine acknowledges

The only difference in the two traces is the size of packet 3. The affected account (top) is a short message. The unaffected account (bottom) is a longer one as the server is responding with a load of info.

So the only conclusion I can draw is this is too deep into Microsoft's O365 server architecture for any of us to see what the issue might be from the outside.

+1 affected tenant...