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

I am not an admin, just an annoyed user. Hence I cannot open a tenant support ticket.

Feel free to reference my 'results' though. And tell me which information would be required to convince the support team that the issue is indeed host-independent. I just want this mess to get sorted out ASAP.

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.

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 don't see how MS can think it's a client side issue, as several of us have one or more accounts that work and one or more that fail on the same client. In my case I was looking at a subscribed folder and disappeared before my eyes and my first thought was did I do something that deleted the folder. I have an email program that runs as a service/daemon that reads email, parses it, and based upon the contents forwards it to the appropriate email address/addresses. Recently I had to add OAuth2 login and happen to have a test program for testing OAuth2 still around. The program uses Javamail. Last night I tried to list subscribed which fails with LSUB error, tried to subscribe and it failed, and tried to check if a folder was subscribed and it failed with an LSUB error. Below is the output of the program ran against an account that doesn't work. On the account that Thunderbird can subscribe all of the commands complete normally. I don't have the capability of submitting a ticket to MS.

DEBUG: JavaMail version 1.6.2

DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map

DEBUG: setDebug: JavaMail version 1.6.2

DEBUG: getProvider() returning javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle]

DEBUG IMAP: mail.imap.fetchsize: 16384

DEBUG IMAP: mail.imap.ignorebodystructuresize: false

DEBUG IMAP: mail.imap.statuscachetimeout: 1000

DEBUG IMAP: mail.imap.appendbuffersize: -1

DEBUG IMAP: mail.imap.minidletime: 10

DEBUG IMAP: closeFoldersOnStoreFailure

DEBUG IMAP: trying to connect to host "outlook.office365.com", port 993, isSSL true

* OK The Microsoft Exchange IMAP4 service is ready. ***************magic stuff ********

A0 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS MOVE ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+

A0 OK CAPABILITY completed.

DEBUG IMAP: AUTH: PLAIN

DEBUG IMAP: AUTH: XOAUTH2

DEBUG IMAP: protocolConnect login, host=outlook.office365.com, user=email address, password=<non-null>

A1 AUTHENTICATE XOAUTH2 **************************magic stuff ***************

A1 OK AUTHENTICATE completed.

A2 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL- IR UIDPLUS MOVE ID UNSELECT CLIENTACCESSRULES CLIENTNETWORKPRESENCELOCATION BACKENDAUTHENTICATE CHILDREN IDLE NAMESPACE LITERAL+

A2 OK CAPABILITY completed.

DEBUG IMAP: AUTH: PLAIN

DEBUG IMAP: AUTH: XOAUTH2

Get subscribed list

A4 LSUB "" "%"

A4 BAD LSUB failed.

A5 SUBSCRIBE Outbox

A5 BAD SUBSCRIBE failed.

A6 UNSUBSCRIBE Outbox

A6 BAD UNSUBSCRIBE failed.

Check if subscribed folder: Outbox

A7 LSUB "" Outbox

A7 BAD LSUB failed.

Java Code Fragment

try

		{

			System.out.println("Get subscribed list");

			Folder[] s = store.getDefaultFolder().listSubscribed();

		}

		catch(Exception e)

		{

		}

		Folder fs = store.getFolder("Outbox");

		System.out.println(fs);

		try

		{

			fs.setSubscribed(true);

		}

		catch (Exception e)

		{

		}

		try

		{

			fs.setSubscribed(false);

		}

		catch (Exception e)

		{

		}

		try

		{

			System.out.print("Check if subscribed folder: ");

			System.out.println(fs);

			System.out.println (fs.isSubscribed());

		}

		catch (Exception e)

		{

		}

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.

![Image](https://learn-attachment.microsoft.com/api/attachments/c2beff21-1073-48e1-86b5-6484d689ec1a?platform=QnA