1907714 - Experimental EWS doesn't work with our on-prem EWS instance

Status: UNCONFIRMED

(Thunderbird :: Account Manager, defect)

Description

[Savely Krasovsky]

Attachment: screenshot

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Went usual process of adding an account, entered name, email, password, clicked Next, wait until warning about DOMAIN\username missing thing, entered it, clicked Next. Got "Configuration found" on the green background, clicked Done, got "Password is correct" but "Password checking..." continued to spin forever.

Using Charles I saw a few successful request to autodiscover.xml entpoint with settings of our server, but after clicking the "final" Done I didn't see any requests at all, why it continues to spin is a mystery for me. There were some requests to EWS endpoint as it would be IMAP/POP/SMTP, but it's not unfortunatelly, so they all failed, but I didn't see nothing EWS/EAS/MAPI special.

Actual results:

EWS works. Out setup is pretty simple in my opinion: just a Basic auth for external users.

Expected results:

It doesn't allow to even add an account.

Comment 1

[Savely Krasovsky]

Sorry, of course I meant EWS NOT works.

Comment 2

[Savely Krasovsky]

After updating to the newest Daily, resetting it and starting again I was able to achieve that account added successfully, but there are no any folders to interact. I don't know why, I see SOAP request to get them with 200 response (and the list of them of course).

To do it I was needed to intercept request and modify Content-Type header from application/xml to text/xml, otherwise EWS returned code 415. Also I was needed to modify response body and replace AuthenticationMethod="Fba" to AuthenticationMethod="Basic" (we use SSO to authorize in OWA itself, but not EWS).

Those measures doesn't help release Thunderbird 128 version, it just continues to spin, while Daily successfully starts to probe our server and in results add it successfully.

In my opinion devs incorrectly parse protocol with type WEB instead of type EXPR where you can find settings for EWS (details).

• EXCH = MAPI, "moden" API which uses desktop Outlook for Windows
• EXHTTP = old pre-MAPI RPC over HTTP API which uses desktop Outlook 2010 and older
• EXPR = basically Exchange Web Services (EWS)
• WEB = Outlook Web App, for example Outlook uses it to show buttons to open OWA in browser. In my opinion you SHOULDN'T parse it at all, only if in some case you didn't get EXPR settings.

In EXPR we are correctly sending <AuthPackage>Basic</AuthPackage>. And of course there is <EwsUrl> tag with correct /EWS/Exchange.asmx link.

Comment 3

[Savely Krasovsky]

Also I noticed that no matter what both release and daily version forgot my password and keep sending just username constantly getting 401. There is no even a popup to enter it, the only way is to remove the account and add it again.

Comment 4

[p.albrecht]

I tried setting up an EWS account on Thunderbird Daily 131.0a1 on Ubuntu 22.04 and can confirm the issue.

I am able to add the account (wizard completes successfully).
After adding the account I can see the name of the account / e-mail address in the main view but there are no actual folders to browse.
E.g. inbox is missing.

I can see the following error message in the terminal which I used for starting Thunderbird Daily:

[ERROR ews_xpcom::client] an unexpected error occurred while syncing folders: Ews(UnexpectedResponse([]))

If I can / should provide additional information that may help fixing this issue, please let me know.

Thanks and best regards
Philipp

Comment 5

[Jack M]

I am also experiencing this issue exactly as described by p.albrecht with Daily 131.0a1 on Windows 11 23H2 (22631.4037).

Comment 6

[p.albrecht]

(In reply to p.albrecht from comment #4)

I tried setting up an EWS account on Thunderbird Daily 131.0a1 on Ubuntu 22.04 and can confirm the issue.

I am able to add the account (wizard completes successfully).
After adding the account I can see the name of the account / e-mail address in the main view but there are no actual folders to browse.
E.g. inbox is missing.

I can see the following error message in the terminal which I used for starting Thunderbird Daily:

[ERROR ews_xpcom::client] an unexpected error occurred while syncing folders: Ews(UnexpectedResponse([]))

If I can / should provide additional information that may help fixing this issue, please let me know.

Thanks and best regards
Philipp

Re-tried using Thunderbird Daily 132.0a1 (2024-09-10) (64-bit) to check whether or not there has been some progress regarding EWS.
Same issue as described earlier.

Comment 7

[Savely Krasovsky]

I tried 136.0a1, account adds, but it's empty, no list, no anything.

Comment 8

[Alexander]

+1
137.0a1 (2025-02-10) (64-bit)
EWS mailbox added but no folders are listed.
Logs shows 401 - [HTTP/1.1 401 Anonymous Request Disallowed 6ms]
when try to show details - console crashes.

`TypeError: serviceContainer.getToolboxStore is not a function
React Component Stack

in MessageContainer

in LazyMessageList

in div

in ConsoleOutput

in Connect(ConsoleOutput)

in div

in div

in App

in Connect(App)

in AppErrorBoundary

in LocalizationProvider

in Provider

in Provider
Stacktrace

NetworkEventMessage@resource://devtools/client/webconsole/components/Output/message-types/NetworkEventMessage.js:205:35

render@resource://devtools/client/webconsole/components/Output/MessageContainer.js:79:12

finishClassComponent@resource://devtools/client/shared/vendor/react-dom.js:10638:31

updateClassComponent@resource://devtools/client/shared/vendor/react-dom.js:10601:44

beginWork@resource://devtools/client/shared/vendor/react-dom.js:11419:16

performUnitOfWork@resource://devtools/client/shared/vendor/react-dom.js:14702:12

workLoop@resource://devtools/client/shared/vendor/react-dom.js:14720:24

renderRoot@resource://devtools/client/shared/vendor/react-dom.js:14803:15

performWorkOnRoot@resource://devtools/client/shared/vendor/react-dom.js:15655:17

performWork@resource://devtools/client/shared/vendor/react-dom.js:15567:24

performSyncWork@resource://devtools/client/shared/vendor/react-dom.js:15541:14

interactiveUpdates$1@resource://devtools/client/shared/vendor/react-dom.js:15808:7

interactiveUpdates@resource://devtools/client/shared/vendor/react-dom.js:1901:10

dispatchInteractiveEvent@resource://devtools/client/shared/vendor/react-dom.js:4328:21`

Comment 9

[Savely Krasovsky]

Tried 138.0a1, same behavior.

Comment 10

[Toby Pilling [:tobyp]]

Hi all,
Some of the behaviour here sounds similar to issues that were reported in bug 1961218 which are unrelated to specific on-prem problems.

Would it be possible for somebody to verify whether you are still experiencing the same problem now that we have tackled more of our backlog?