This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I'm using Thunderbird to access my Office 365 mail account and it has been working fine (a couple of month ago I also switched to OAuth2 due to deprecation of basic IMAP authentication). However, since 2022-11-01, Thunderbird is unable to subscribe to IMAP folders. Last time I know it was working was last Friday 2022-10-28. Thunderbird is able to list to available folders (e.g. when opening the "Subscribe" dialog from the mail account settings), but cannot subscribe to them. I enabled IMAP logging in Thunderbird, and it shows that the server answer the subscribe request with "BAD SUBSCRIBE".
It is not a password/authentication issue, as Thunderbird can still see the content of "Inbox" and "Deleted Items". And if I disable the option "Show only subscribed folders", it can access everything in my Office 265 account.
Edit: here's the relevant logs from Thunderbird (note: I've replaced the actual folder name with "xxxx"):
[Parent ...: IMAP]: I/IMAP ...:outlook.office365.com:A:SendData: 76 subscribe "INBOX/xxxx"
[Parent ...: IMAP]: I/IMAP ...:outlook.office365.com:A:CreateNewLineFromSocket: 76 BAD SUBSCRIBE failed.
Microsoft 365 features that help users manage their subscriptions, account settings, and billing information.
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Ian, Thank you so much for your work here. I appreciate it.
-Jonathan
Ian, By my support team, I should have just said Microsoft. I was escalated to level 2 of MS support. I roll my eyes when he says it could not be on the server side. He says he is trying to cover all bases. Ok, I'll go look for your ticket number. Thanks!
-Jonathan
Thank you for this great summary of the current state of knowledge!
I suppose the only thing to do now is to wait for Microsoft to...
(1.) confirm that they did indeed break the protocol,
(2.) and either fix their IMAP4 rev.1 implementation to support LSUB consistently, or push the problem that they have created themselves onto the developers of all affected MUAs by officially supporting IMAP4 rev.2 only. (Really hope the latter will not be the case; that would feel like an abuse of power and a punch in the community's gut.)
Speaking of SLAs:
Assuming an educational establishment had recently signed a contract with Microsoft concerning or including mail services provided by them,
unaware of these emerging issues for non-Outlook users and due to lacking documentation thereof. Do you see any way that such contract could be terminated early if Microsoft were not willing or able to come up with an viable solution..?
I think their efforts will be focused on trying to find the underlying fault. It would just be nice to see WHAT those efforts currently are so IT staff can manage the expectations of affected and pretty hacked-off end users.
It's difficult to assess the level of adoption of the new standard - but in my view, it simply wouldn't be credible for Microsoft to push back a significant change onto so many other major players when they are the only one with a problem and the standard is relatively recent.
In fairness to Microsoft, they do give ample warning to us system admins of major changes normally, so I don't believe this was intentional. For comparison, the basic auth change was 12+ months notice - and that was for MUAs that ought to have been Oauth2 capable for years already (because Gmail have required it for the last few years) and wouldn't have needed any development. Thunderbird added Oauth2 back in 2015 for example. But Microsoft knew that the logistics of getting users to reconfigure across a plethora of different MUAs was going to be a challenge for IT people.
As for terminating contracts, the migration has been done and it could prove more costly and time consuming to back it out, than try and manage the current situation. But if your organisation is big enough to have a Microsoft sales representative, no harm in a senior manager giving them a call.
As an aside, Microsoft themselves offer up a means to test email connectivity into the their service and you can see it at https://testconnectivity.microsoft.com/
I ran this early on but it doesn't test the LSUB functionality so the test passes. It wouldn't surprise me if their test script is similar to what this site is doing.
Same result here.
The connection to the IMAP protocol woks fine but accessing subscribed folder via the LSUB command, doesn't work for some mailboxes.
Thanks - useful to see the same consistent results no matter what MUA it is.
But to be clear, Microsoft aren't claiming this is client side, and I assume the reason I was sent the test script by them was to prove that beyond doubt by using a test method Microsoft themselves could have full confidence in as being independent from any particular MUA. It was pretty conclusive before that if you ask me, but I can see why they would want to do that step.
Jonathan will no doubt confirm, but I assume "my support team" means his own organisation/company first or second line support who might be struggling to get to grips with this.
As an aside, Microsoft themselves offer up a means to test email connectivity into the their service and you can see it at https://testconnectivity.microsoft.com/
I ran this early on against one of my affected accounts but it doesn't test the LSUB functionality as you can see below - just does a list - so the test passes. Wouldn't surprise me if the Microsoft test script I have is a tweak of the code behind this site.