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

Question

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.

Answer 1

For those that missed it....

DISABLE the Thunderbird option: "SHOW ONLY SUBSCRIBED FOLDERS"

Located at: 'Tools' > 'Account Settings' > 'Server Settings' > 'Advanced' > "show only subscribed folders"

Uncheck that and then get messages and all folders will show up.

Having all folders shown is better than missing the important ones.

Answer 2

Just to be clear, this thread is about a particular bit of functionality in IMAP not working properly with effect from the start of November - which is folder subscription - and only affecting some O365 accounts, even within the same tenant. The symptoms are affected users just seeing the INBOX and DELETED folders in their mail client where others (SENT, DRAFTS etc,) were previously visible.

Thunderbird users have a workaround for this issue, which is to go into SERVER SETTINGS, ADVANCED, and untick the box marked "Show only subscribed folders". This effectively ignores the subscription functionality that isn't working properly, and displays all the remote folders - including stuff you wouldn't normally be bothered about. Slightly irritating but tolerable until this gets fixed. Whether a similar workaround is available on other MUAs is something you need to look at on a product by product basis.

If your users have lost all IMAP connectivity and getting authentication errors and the like when trying to access O365, then that is going to be a different issue - possibly the deprecation of basic authentication change that took place during October and had been widely publicised by Microsoft for over a year beforehand i.e. the users need to reconfigure their mail client to use Oauth2 rather than basic authentication.

Hope this clarifies.

Answer 3

All - my latest test findings as follows:

I took the decision today to run the diagnostic to temporarily re-enable IMAP/basic auth on my tenant (this gives system admins a bit of extra time if they were caught out by the basic auth deprecation), and see if the fault is still there with an affected account reconfigured back to basic auth.

Findings as follows:

1. It doesn't make the slightest bit of difference to the fault - an affected account remains broken for subscription. So this doesn't appear to have any connection with the basic auth change/setting. This is what I expected if I'm honest as the change hit my tenant early in Oct and this problem didn't appear until a few days back.
2. Because my tenant accepts basic auth now, I was able to add an affected account as type IMAP to Outlook 2021 on my test machine and that gives the Outlook error "The folder list was not fully refreshed. An IMAP command failed" when I tried to query IMAP folders. Ticking the equivalent box to TB to display all folders works in Outlook too. I then added one of my known working accounts to Outlook as IMAP, and subscription works fine on that.

So, what this proves in summary is the fault presents itself the same in both Outlook 2021 and Thunderbird and the fault is sticking rigidly to the affected accounts. So it rather looks like the problem is at the O365 end on a number of tenants.

I have updated the ticket I have open with Microsoft for the fault on my tenant.

Answer 4

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!

Answer 5

My ticket ref is already on here - just so other IT support teams can cross refer to it in any ticket they might raise, as it contains a fair bit of testing on this matter. Only I and Microsoft will have visibility of my ticket, and no point putting your own ticket number up for that same reason. Regarding your other questions, here is a summary as I see it for the benefit of your support folks:

IMAP4 Rev1 (RFC 3501) dates back to 2003 and LSUB is a supported command in that version.

IMAP4 Rev2 (RFC 9051) was issued in August last year, and LSUB is no longer used in that version.

But the publishing of a new proposed standard doesn't mean the old one is immediately null and void, as it requires plans, and often development work, and often industry co-operation too, to adopt it. So the answer to the question in my opinion is: LSUB is a valid command to be sending to an IMAP server that supports the earlier standard.

Other questions and my view on the answers is currently as follows:

Q Do Microsoft support the earlier standard and therefore LSUB?

A Yes - because their server responds to an IMAP CAPABILITY command with IMAP4 Rev1, and some O365 mailboxes are receiving and processing the LSUB command issued by MUAs correctly.

Q Why are some O365 mailboxes affected and not others?

A That's for Microsoft to explain - they have the inconsistency. I've certainly found nothing to explain the inconsistency in my affected/unaffected accounts to date, and I haven't been able to get a FAILED account working, nor have I been able to get a WORKING account to fail.

Q Is this a client/MUA problem?

A It was never likely once the pattern started to emerge. So many different MUA products were simultaneously affected at the start of November, and only O365 mailboxes were impacted, not other mail service providers. MUAs either reported an LSUB related error directly to the user OR reported it when IMAP was debugged at an appropriate level within the MUA product. Microsoft Outlook when configured for IMAP (as opposed to the more usual MAPI) is also on the list of affected MUAs. A Powershell test script issued to me by Microsoft and capable of simulating what an MUA does, replicates exactly what the MUAs are seeing/reporting too on affected mailboxes.

Q Can anyone else have a play with the Microsoft Powershell script?

A Not if you are an end user, as it needs administrative access to the Azure AD on the O365 tenant where the affected user is. If IT support people would like to give it a go, I can post instructions up, but bear in mind you're going to need the password (or reset it) for the affected account as you need to log in as them. In any case, I have already posted up what the script is doing, and what the results are in this thread.

Q Is there an SLA Microsoft should be working too to fix this?

A Microsoft have an SLA for availability of Exchange Online when accessed with OWA. I can see no SLA covering the IMAP interface.

Q Is there a workaround?

A Seems to depend on your MUA product. Thunderbird and Outlook over IMAP - I can personally say yes because I have tested both. You can configure both of those to override folder subscription and display all the remote folders (includes a load of rubbish you won't want to see but it's tolerable). Any others, you might have to research your own product. Nastier workarounds if you're really stuck include users using Outlook Online, or changing the MUA they are using - and neither are going to go down well.

Q Is this problem linked to the deprecation of basic authentication that happened on O365 in November?

A My accounts, both affected/unaffected, had been using Oauth2 for months. On my tenant, I have had basic auth re-enabled for testing purposes and still see the problem with an affected account reconfigured back to basic. So I see no evidence the issues are linked.