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

Anonymous
2022-11-02T07:33:01+00:00

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 and Office | Subscription, account, billing | For business | Other

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.

0 comments

106 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2022-12-15T13:31:30+00:00

    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.

    Was this answer helpful?

    0 comments
  2. Anonymous
    2022-12-15T12:50:55+00:00

    +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?

    Was this answer helpful?

    0 comments
  3. Anonymous
    2022-12-14T21:35:14+00:00

    +1 affected tenant...

    Was this answer helpful?

    0 comments
  4. Anonymous
    2022-12-14T18:43:27+00:00

    Thanks for your comments. As I mentioned in the thread, the testconnectivity.microsoft.com site isn't actually testing the particular IMAP command which is failing on affected accounts, so that test will always pass.

    The only bit of extra testing I have done over the last few days is to send a load of test messages from outside my service into affected and unaffected accounts, and then examine the message headers to see if there was any pattern in the O365 nodes that handled the message. There isn't.

    I've also run up Wireshark on my machine to packet capture the response message from the server on affected and unaffected accounts when an LSUB command is issued and this confirms the above i.e. the originating IP address for the reply is pretty random, and you can sometimes see the same IP respond for both affected and unaffected accounts. On both traces.........

    Packet 1 - is my machine sending the LSUB command

    Packet 2 - Microsoft server acknowledges it

    Packet 3 - Microsoft server replies

    Packet 4 - my machine acknowledges

    The only difference in the two traces is the size of packet 3. The affected account (top) is a short message. The unaffected account (bottom) is a longer one as the server is responding with a load of info.

    So the only conclusion I can draw is this is too deep into Microsoft's O365 server architecture for any of us to see what the issue might be from the outside.

    Was this answer helpful?

    0 comments
  5. Anonymous
    2022-12-14T13:51:36+00:00

    I doubt that the use of the Microsoft Support and Recovery Assistant (SaRA) will get you anywhere.

    This tool is designed to look for configuration mistakes on the client side.

    It appears that Microsoft insists that the issue exists on either the client or tenant side, while all evidence points towards the MS servers as the root of the issue instead.

    In a way they are just pointing fingers and wasting the tenant-administrators' time; this is getting quite annoying by now.

    I don't expect them to come up with a fix before beginning of 2023, if at all...

    Was this answer helpful?

    0 comments