So it's getting weirder. If I go to Account Settings --> Server Settimgs --> Advanced and uncheck "Show only subscribed folders", then I see ALL the folders, even ones I don't need to.

So, I then Right Clicked on the account name and selected "Subscribe …". Here I saw that the "Sent Items" wasn't subscribed. So, I checked the box and click the Subscribe button. Then OK. But the selection doesn't "stick". If I go back to Subscribe, the "Sent Items" box is again UNCHECKED.

Anyone have a clue how to fix this?

Thanks.

Same here, I have 3 microsoft account, 2 of them have this problem since today. I can only subscribe the inbox folder, nothing else. In addition when I open Thunderbird (102.2.2 on Ubuntu 22.04) for a second I can see all the folders, that soon disappear.

In addition when I open Thunderbird (102.2.2 on Ubuntu 22.04) for a second I can see all the folders, that soon disappear.

Yes @rokopi I get the disappearing folder trick too.

I have just experienced this problem with TB 102.4.1. I believe my TB updated itself just a few days ago.

I am an O365 system admin and several of my own test/system accounts dropped to just showing INBOX and DELETED at some point over the last day or so (can't be sure exactly when as they aren't my primary accounts).

1. FOUR of my O365 accounts on the same tenant are affected, which suggests this isn't some random corruption of local TB mail files 2. I have other IMAP accounts from other mail providers in TB which are unaffected 3. I have an account on the same O365 tenant which is configured as pop, not IMAP, and that is unaffected 4. A user has just contacted me to say he has TB 102.2.2 on Linux and is unaffected 5. All the folders are present in Outlook Online

I raised a ticket with Microsoft this morning and they are suggesting attention needs to be on TB which is how I found this post. In summary, it looks like the subscription functionality in IMAP has been messed up. If I try and change the IMAP subscribe options on affected accounts, it does absolutely nothing.

I have been able to work around the issue by configuring an affected account in TB to display all folders by UNTICKING the option "show only subscribed folders" in SERVER SETTINGS, ADVANCED.

It is clear this same problem has occurred at various points in the past but I can't see any resolution to it. Most recent bug report here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1714572

The only change on my tenant recently has been the deprecation of basic authentication at the start of October - i.e. all my TB users (including myself) had to change to using Oauth2 in advance of the change. This makes me wonder if Mozilla have just released an update to TB which fails to take account of Microsoft stopping basic authentication last month. i.e. the subscription functionality is trying to use basic authentication and failing.

I have just experienced this problem with TB 102.4.1. . .

Thanks @midgleyi. Sounds like you're much more knowledgeable in this area than I. Do you know how to start the process of getting this into a Trouble Ticket for TB staff?

@gfvalvo Probably raising a bug report on Bugzilla. I have an account on that but I'm just waiting for some more feedback from my user base before I raise a report. It would also be useful if anyone else seeing this problem takes the time to flag in on here. Thanks.

@midgleyi I did it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1798685 maybe you can add details.

@rokopi Nice one - thanks. Will do.

Bit more info to add to this from my testing this evening.

I have a couple of test accounts on the same O365 tenant as I'm seeing problems, which have never been added to Thunderbird before. When I added these (as IMAP), they worked CORRECTLY. I was able to subscribe to additional folders such as SENT and DRAFT without any problem.

However, I found that deleting one of my affected accounts from TB and then adding it back it resulted in the same problem as before. That's just a bit weird.

I have added all this to the Bugzilla case.

sounds like they created a problem and didn't test the product as they now need us to report their BUG?

I am sorry I am stuck here. who codes and doesn't test. if "You= @ mozilla" please stop coding. so is this help full? They have yet to post that MOZILLA created/suffers from the problem.

NO Posting HUH!!!

At this point the proper people should be reporting they A: expected the work of debugging to be done by others not paid to show them the problem they now have. B: ok so its open source. so no one gets paid? (really?????? I think not) and so they now know about it(the problem) and yet SAY nothing. other than look at the post that agree we are broken!! this was there best answer--WOW. this is the very reason products are worth paying for, its called accountability, I guess I am out, as They take no ownership nor provide any info about there products. not any wonder firefox the browser is just as bad and that is a shame for the GNU world!

my question did not get answered it got deferred.
so "NO SOLUTION" if you have this problem was the MOZILLA response.

I notice the Bugzilla case has been closed on the basis there are issues with IMAP on Outlook too (not tested this myself).

I have done some additional testing this morning based on my findings a couple of days ago.

I took a test laptop of mine, installed TB 104.4.2 (same as my desktop), and added one of my affected accounts to it. I got the same fault as I see on my desktop. I then took yet another test account on the same O365 tenant that has never been used on TB - and added it to my laptop and that worked perfectly well - mirroring what I was seeing on my desktop a couple of days back.

So I think we can now say:

1. This fault only affects O365 accounts which were already using IMAP at the time the issue occurred. 2. An O365 account that has never been used for IMAP before can be added to TB and works correctly (I have now done this with three test accounts - twice on my desktop and once on my laptop) 3. Completely deleting an affected account in TB and adding it back in, makes no difference - suggesting that O365 is somehow hanging on to the problem such that it is reintroduced when the account is added back into TB.

I still have my original ticket open with Microsoft on this so I have passed the additional findings to them, and also highlighted peoples comments on the Bugzilla case regarding Outlook.

midgleyi, and rokopi, thank you for posting the helpful information.

Microsoft has been publicizing for months that their method of authentication was going to change to oauth. That is a summary of https://bugzilla.mozilla.org/show_bug.cgi?id=1798685

sounds like they created a problem and didn't test the product as they now need us to report their BUG?

Actually, no. This is a Microsoft change.

https://bugzilla.mozilla.org/show_bug.cgi?id=1714572, although informative, is unrelated.

@Wayne Mery

I think we need to be careful not to lump the basic authentication change (which hit my O365 tenant at the start of October) with this fault unless there is clear evidence. Microsoft are not getting rid of support for IMAP - they are getting rid of IMAP using basic auth.

The accounts I have that are affected were reconfigured to use Oauth2 months ago in readiness for the October deadline as we system admins had plenty of advanced warning. They have been working fine for all that time - and the only problem is we now have a subset of the IMAP functionality (folder subscription) that has suddenly stopped working at the end of the month when the rest of the IMAP account functionality is OK.

As already detailed above, I can take an O365 test account of mine on the same tenant that has never been accessed with TB before, configure it in TB identically to an affected account (i.e. Oauth2), and folder subscription works fine. But all my affected accounts remain broken for folder subscription, and nothing I have done so far has fixed them - including setting up one of the affected accounts on a separate machine with a fresh install of TB and seeing the exact same fault.

i.e. the fault is staying with the affected O365 account and not with the device that is accessing it.

So right now, I see no evidence that TB is at fault, and no logical reason why deprecation of basic authentication would have anything whatsoever to do with a subset of the IMAP functionality stopping working when the rest of the functionality is perfectly fine. Still doesn't tell us where precisely the fault is yet.

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.

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 ....

Sorry, I'm unfamiliar with the term ... what is a "tenant"? Just curious because you mention it a lot.

midgleyi said

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 ....

Sorry, I'm unfamiliar with the term ... what is a "tenant"? Just curious because you mention it a lot.

If an organisation/company takes the O365 service, the dedicated lump of O365 infrastructure they control themselves is officially called a "Tenant" by Microsoft and those of us who look after one. I should have been clearer as end users of O365 may not have heard the term.

I've just chased Microsoft on the back of my support ticket, but I'm not expecting a rapid resolution to it, given there is a workaround available to display all folders.

Remember too that the number of users and O365 tenants affected is going to be a small percentage of the overall O365 service - simply because most corporate users of O365 will have users on Outlook accessing with the standard Microsoft connection protocol MAPI, and not IMAP. None of my Outlook users are affected by this issue for that very reason - and it was Thunderbird using IMAP where the problem first surfaced for me.

All I can suggest is those of you who manage O365 tenants open your own support ticket in Admin Centre so Microsoft can at least see who is affected. By all means cross-refer to mine which is ticket ref. 33661676

If you are an end user and certain you are seeing this exact same issue, then maybe contact your service desk/O365 sys admin and ask them to do the same.

Morning all. Not much to report yet but I have just been asked to run a test script by Microsoft this morning.

For the non-technical amongst you, this involved a Microsoft product called Powershell running locally on my machine, and the Microsoft script connects to one of my affected mailboxes and issues IMAP commands directly to it. i.e. there is no-ones MUA involved in this test.

It is one particular command - LSUB - that doesn't work on an affected mailbox. That is entirely as expected as this thread shows that some MUA products actually report LSUB as being the problem in the error message they generate.

Conversely, when I run the exact same script (i.e. including the same LSUB commands) against one of my working O365 accounts, the LSUB commands work as expected.

So really, we're just waiting for Microsoft to establish where their problem is.

Just to close this thread down, Microsoft seem to have resolved the issue with their service yesterday morning.