davmail + Microsoft - cannot login with davmail, can log in with Thunderbird OWL

[tskirvin]

Well over a year ago my workplace turned off access to Exchange email via most older tools; they want us to use Outlook or not at all. They had turned off most access a few years before that, but I had been able to keep using my mail reader of choice (mutt) via combination of davmail and mbsync. But when the authentication stopped working, I gave up and started just using Outlook Web. Things were sad.

A few weeks ago I found out that there is a workaround: Thunderbird + Owl for Exchange allows me to authenticate properly. Hooray! So I've started using that, and indeed, things are somewhat better?

But now that it's working, I have to ask: what is Owl doing that's different than davmail? Did I just miss something in davmail? Because I'd love to go back to real tools!

Some details: I'm running davmail on a Mac laptop. I've tried a couple of different versions: one installed via homebrew, one by downloading the package from the web site. O365Manual and O365Interactive both eventually point me to the same general web login page. I am able to successfully log in via various browsers (with password + 2FA), and it sends me the error message:

You cannot access this right now
Your sign-in was successful but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app, or location that is restricted by your admin.

I've tried setting or not:

davmail.oauth.redirectUri=urn:ietf:wg:oauth:2.0:oob
davmail.oauth.clientId=d3590ed6-52b3-4102-aeff-aad2292ab01c

...without any real change to the outcome. But a pretty-much default Thunderbird install with https://services.addons.thunderbird.net/en-US/thunderbird/addon/owl-for-exchange/ just worked the first time, and from multiple locations.

It feels like this has something to do with how the apps are or are not approve-listed upstream. I don't have any particular reason to think that Owl was approved upstream in particular, though. So, what's different? And how can I help figure this out so I can go back to doing things in a sensible way?

[esabol]

Do you have davmail.mode=O365Interactive in your davmail.properties file? You might have to install a separate jar file for SWT to use O365Interactive.

What does your log file say?

[esabol]

Just for the record, if you can login to Outlook Web in your web browser, then you should be able to login using O365Manual. The methods are functionally the same.

[tskirvin]

Fundamentally they both do the same thing eventually, right? Either I do O365Manual or O365Interactive, and we eventually end up with a URL pointing at:

https://login.microsoftonline.com/common/oauth2/authorize?client_id=ANONYMIZED&response_type=code&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&login_hint=tskirvin%40MY_SITE&resource=https%3A%2F%2Foutlook.office365.com

And I go there, and I log in, and I get the error message from MS saying that I'm not approved, and I don't have anything to cut-and-paste back in like I used to. But isn't Owl doing the same thing? And, if not, what are they doing instead?

Oh, and for the log files, it's fundamentally asking for me for the authentication code URL and hanging, as you'd expect. The problem is that I'm not able to generate that URL.

I feel like there's a good chance I'm missing something very simple and small.

[esabol]

Is there a "Sign-In Error Code" number below the error message in the web browser? If so, what is the number?

Reference: https://learn.microsoft.com/en-us/answers/questions/1833920/you-cannot-access-this-right-now-your-sign-in-was

[tskirvin]

 Error Code: 53003
Request Id: [...]
Timestamp: 2026-03-09T23:39:42.012Z
App name: Microsoft Office
App id: d3590ed6-52b3-4102-aeff-aad2292ab01c
IP address: [...]
Device identifier: Not available
Device platform: macOS
Device state: Unregistered

[mguessan]

Would need to understand if owl is still based on EWS or if they switched to graph API already.

Next question is: which clientId are they using, most common clientId values require admin consent, exception as already mentioned is native Microsoft applications like Outlook desktop.

Then depending on conditional access settings there will be additional device based checks. On windows best result will be achieved with desktop sso available, which means running authentication in edge (then O365manual) or O365Interactive with SWT backend that is based on Webview2 (Edge chromium engine).

Javafx based embedded browser does not have access to windows session token.

[tskirvin]

Owl looks like it's been around for a while so it's probably EWS, but it's closed-source (I think?) so I can't tell for sure. This is why I don't have the clientid off hand to try either; I can't figure out how I'd find it? I don't imagine that my local admins would have whitelisted a new clientid. I only found out that Owl worked on the grapevine.

[esabol]

I think Owl uses OWA? https://services.addons.thunderbird.net/en-US/thunderbird/addon/owl-for-exchange/versions/

[mguessan]

Found clientId and scope inside Owl extension, scope is "offline_access EWS.AccessAsUser.All" so definitely EWS.

I just checked the authentication with owl clientId triggers admin consent, just like DavMail, so somehow back to initial question Owl must be approved by an admin on tenant.

Regarding 53003 error code, it means BlockedByConditionalAccess, so definitely a conditional access issue:

https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access

[mguessan]

@tskirvin Error Code: 53003 means conditional access error => one of the conditional access checks fails, need to understand which one.

I get best compliance running authentication request in a webview2 browser on windows, see my script and application at:
https://github.com/mguessan/o365psauth

Please note that DavMail on windows with SWT also runs an embedded webview2 browser.

Another approach is to explore clientId and other oauth settings with EntraTokenAid

https://github.com/zh54321/EntraTokenAid

[esabol]

A mention in that last link lead me to this:

https://github.com/dirkjanm/ROADtools/wiki/ROADtools-Token-eXchange-(roadtx)

I'll need to look into that and experiment with it. This may be helpful for Linux and macOS users.

[tskirvin]

I checked, the Windows tools don't work (not that I generally use Windows, but I'd be willing to make an exception if it gave me reasonable email access again). It probably is that Thunderbird was explicitly authorized where davmail was not by our admins. So what would I need to ask for from my admins, specifically, to authorized davmail?

And if @esabol works out the the ROADtools bit, please let me know!

[esabol]

And if @esabol works out the the ROADtools bit, please let me know!

You're probably more motivated than I am to investigate roadtx in the near term, @tskirvin. I asked an AI, and this is the answer it gave: https://grok.com/share/bGVnYWN5LWNvcHk_8e05b5c8-6583-4e31-acb3-d30ca984909e

I hope that helps. Post here with your findings of using roadtx.

[tskirvin]

I worked through a good chunk of the roadtools suite (hint for anybody looking to configure roadtx nowadays: setuptools<81 is required in setup.py, or probably <82 really), but came back to the same general problem: error code 53003 when actually doing the authentication from the MS side.