Connecting IMAP4 Clients to Exchange Online with OAuth 2.0

Easy When Vendor Does the Work to Upgrade Client

Last week, I discussed the need for email client upgrades to cope with the imminent termination of support for basic authentication for seven protocols used to connect to Exchange Online. In some cases, vendors are stepping up to the mark and making sure that clients switch easily over to modern authentication, with Apple’s project to upgrade mail app profiles being a notable example. Apparently, that’s going to happen when devices apply the iOS 15.6 upgrade.

Connecting IMAP4 clients to Exchange Online is popular in some market segments. Microsoft upgraded the IMAP4 and POP3 protocols with OAuth 2 support in April 2020, but an internet search doesn’t reveal much activity in terms of client upgrades with the except of Mozilla Thunderbird. The instructions to connect Thunderbird to Exchange Online using OAuth 2.0 are available online, including some nice write-ups from universities (here’s an example).

It’s a while since I used an IMAP4 client with Exchange Online, so to test the OAuth 2.0 connection, I downloaded Thunderbird 102.0.2.

Thunderbird’s Azure AD App

The implementation to achieve OAuth 2.0 support is interesting. Like any app that depends on Graph permissions, Thunderbird needs to create a registered Azure AD. In turn, the service principal for the app can receive consent for the permissions needed to access Exchange Online with POP3 and IMAP4, and to send messages using SMTP. Michel de Rooij has a good write-up on how the OAuth flow works for Thunderbird. Essentially, you to open a browser and run a command to add the app identifier created by Thunderbird to your tenant. The command I used was:

https://login.microsoftonline.com/22e90715-3da6-4a78-9ec6-b3282389492b/oauth2/authorize?client_id=08162f7c-0fd2-4200-a84a-f25a4db0b584&response_type=code&prompt=admin_consent

This command breaks down into:

  • Login to Microsoft Online.
  • Pass your tenant identifier (use the Get-MgOrganization cmdlet to get the identifier or look for it in the Azure AD admin center).
  • Pass the client identifier (app identifier) for the Thunderbird app. This is always 08162f7c-0fd2-4200-a84a-f25a4db0b584.
  • Prompt for consent.

When you create a registered app in Azure AD, you decide if the app is available in just your tenant or any organizational directory (any Microsoft 365 tenant). The app knows what permissions it needs to function, so when you run the command, you do two things:

  • Create an entry for the app in the tenant’s Azure AD.
  • Consent to the permissions needed by the app to run. As you can see from Figure 1, these are read and write access to mailboxes using IMAP4 and POP3. and send messages using SMTP AUTH. It’s best if an admin gives consent for an organization as this avoids the need for individual users to grant consent for the app to access their mailbox (if allowed by Azure AD settings).
Granting IMAP4 and POP3 permissions to the Thunderbird app
Figure 1: Granting IMAP4 and POP3 permissions to the Thunderbird app

When these permissions are in place, users can follow the instructions to configure their client to use OAuth for authorization (Figure 2). The important thing is to use SSL/TLS with OAuth2 to fetch messages from Exchange Online and StartTLS and OAuth2 to send messages via SMTP.

IMAP4 settings for Thunderbird to connect to Exchange Online with OAuth 2.0

IMAP4 clients to Exchange Online
Figure 2: IMAP4 settings for Thunderbird to connect to Exchange Online with OAuth 2.0

Guidance online (like these hints) offers some good suggestions like subscribing to folders in your Exchange Online mailbox to make them available to Thunderbird. It’s worth reading and passing to end users if they don’t already know this stuff.

SMTP AUTH Needed to Send Email

Everything works swimmingly. That is, if the mailbox is allowed to use SMTP AUTH to send messages. Usually, the IMAP4 connection works without a hitch and no problems are detected until the time comes to send messages, at which the server refuses to accept the message. Invariably, this is because the mailbox isn’t allowed to use SMTP AUTH. To fix the problem, run the Set-CasMailbox cmdlet to remove the block:

Set-CasMailbox -id "Tony Redmond" -SmtpClientAuthenticationDisabled $False

Once the block is lifted, mail should flow freely and you should have a happy IMAP4 user (Figure 3).

The Thunderbird IMAP4 client connected to Exchange Online
Figure 3: The Thunderbird IMAP4 client connected to Exchange Online

Connecting IMAP4 Clients to Exchange Online Might Need Upgrades

The Thunderbird implementation is smooth and should be easy for anyone to use. The difficulties I see are:

  • People who have old Thunderbird clients with configurations that use basic authentication. These folk won’t be able to connect to Exchange Online after Microsoft switches basic authentication off and will need to change their settings and potentially update their client. Before anything works, the tenant administrator must create the registered app and consent to the necessary permissions.
  • People who have other IMAP4 and POP3 clients where the app creator hasn’t produced an upgraded version to support OAuth 2.0. These people are out of luck and will need to adopt a different client.

With 78 days to go before October 1, it’s time to ensure that the IMAP4 clients to Exchange Online connection remains intact after basic authentication disappears. And while you’re at it, make sure that all your ActiveSync clients can too.


So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

10 Replies to “Connecting IMAP4 Clients to Exchange Online with OAuth 2.0”

  1. Hi Tony,
    Any clue on the way to get the job done with a shared MailBox ?
    The fact is that the authentication dialog thrown via à browser window asks a valid email address, while the authentication string for a shared mailbox is something like “myaccount@my.co\my-shared.mailbox@my.co” … which is obviously not a valid e-mail address :/
    I’ve struggled a bit these days, since OAuth2 is our only left option to use an MS365 account on ThunderBird/Linux :/
    Have a nice day 🙂

    1. Honestly, I’d use OWA to access a shared mailbox on whatever platform you use. I doubt that many client vendors have figured out how to resolve the permissions needed to access shared folders from regular IMAP4 clients.

    2. Try as follows:
      Email address:
      When prompted to log in via web, click ‘Sign in as a different account’, then enter the login details for the mailbox which has delegated permissions.
      Works for us in another OAuth product (Jira)

  2. So I see the export option is now available to export Wikis from standard Teams channels. But what are we supposed to do for wikis in private or shared channels??

      1. Thanks Tony – (clearly I commented on the wrong post). I was hoping Microsoft had an alternative for those channels.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.