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

+1 affected tenant.

It seems like Microsoft made some changes to O365's IMAP implementation?

This affects our non-Outlook users, both students and faculties.

IMAP with O365 isn't working with Thunderbird, Evolution and others.

It used to work. MS must have changed something around Nov 2022?

I'd bet there is a developer at MS that could find the cause of this in 15 minutes or so if they were to get involved.

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.

I'd bet there is a developer at MS that could find the cause of this in 15 minutes or so if they were to get involved.

I've just just been told there is no further update from the Microsoft Product Group yet which is rather disappointing and I have made my own feelings about that known, even though the impact on my service/users is minimal now.

You might be right, but it could equally be the case that it is so obscure, it is taking time to unearth regardless of who is involved.

It could also be the case that they already know what it is (they certainly know WHEN it happened to within a day) but the change/release control constraints to fix it might be far greater than the incident itself and the current impact. As I've said before on here, this will hit a relative minority of tenants who have no control over the end users/devices accessing their service, and won't hit businesses running Outlook on their corporate desktops as they simply aren't using IMAP. If the fix, or method of fix, poses any risk to the latter, we will likely have to wait for due process to be followed.

[...] even though the impact on my service/users is minimal now.

[...]

this will hit a relative minority of tenants who have no control over the end users/devices accessing their service, and won't hit businesses running Outlook on their corporate desktops as they simply aren't using IMAP.

While the issue for users of Thunderbird as a mail client is a minor inconvenience right now due to mentioned work-around,

such a solution does not seem to exist for other mail clients. They are forced to abandon their MUA and use the web form instead.

I am not sure whether this has been mentioned before, but using mail clients with affected accounts does not only affect the ability to see the subscribed folders, but also the ability to copy messages to these. For example, the sending of an email may apparently fail due to the inability of the mail client to copy the sent message to the SEND folder that it is expecting to be connected to. Happened to me with both Evolution and Thunderbird mail clients, the latter without the work-around.

Let me be clear; the issue is not a cosmetic one, but a service breaking fault.

And let's not fool ourselves, the fault is likely an error and not a deliberate design choice. Just consider that Microsoft's own product, the Outlook email client*,* is equally affected when using the IMAP instead of the MAPI protocol for connections. See: https://answers.microsoft.com/en-us/outlook_com/forum/all/microsoft-365-imap-folders-are-broken-no/3fadaa09-86cf-4129-89f3-09a270afa0b2

I agree that the majority of Microsoft O365 customers may very well be corporate clients or smaller businesses. And most of these are likely in more or less full control of their tenant's user accounts, and are equally likely to force them to use Outlook over MAPI as an email client.

However, consider that Microsoft has been quite aggressive with its push into the Education market, especially since the start of the 2019 COVID pandemic and the urgent rise in need of online tools for collaboration. See their web; this is what O365 - among other things - is primarily being advertised for: https://www.microsoft.com/en-us/education/products/microsoft-365 (Note: They put a lot of work into fancy advertising of their software solutions. But not a single mention that their services may not work for non-Windows OS users.)

During these desperate times many educational facilities may have signed contracts with Microsoft over O365 products simply out of pure desperation.

It is clear though, that educational settings (schools, colleges, universities, research institutions) have no control whatsoever over their users in regard to which operating system or software they use. And this is a good thing for education and science! Tools used in learning and teaching should be independent of corporate (read: Microsoft's) control or student's/researcher's financial situation, and be up entirely to the users' choice.

It is perfectly fine if an educational institution signs a contract with Microsoft over a product that offers additional services or applications to be available for its users. However, it becomes a problem, when such institution outsources a core service to Microsoft, such as the hosting of a O365 mail Exchange server, as we have seen multiple times in this thread.

If Microsoft (inadvertently) breaks compatibility of their O365 mail service with non-Microsoft-based mail clients, and thereby forces users to switch to Microsoft-based client solutions, then this sounds like a break of contract at best, and like them throwing their weight around in their self-governed monopoly at worst.

The current situation is unacceptable for their Education market customer base!

And this is regardless of the relatively small numbers of apparently randomly affected users, as it may be a looming symptom of worse disregard that may be yet to come...