1975860 - Cannot add new imap account - account hub locks up - for autodiscovery pointing to account hosted at 3rd party (i.e. large German providers like IONOS,@online.de)

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect, P2)

Description

[Jaap van der Leer]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 Edg/138.0.0.0

Steps to reproduce:

I tried to add the following account:
Huub Grootveld
[e-mail]

Actual results:

Then the new-account wizards loops, greys out, no asking for password

When loop is cancelled with esc, and add account is pressed again, het greyed out windows reappears and no strings can be entered.

Expected results:

Either, the account is found, asks for password, sets up and adds account to list of accounts. Or, the account is not found and manual setup is asked for.

Comment 1

[Wayne Mery (:wsmwk)]

Can you attach screen shot what you are seeing?

Comment 2

[Jaap van der Leer]

Attachment: Initial entered data

Comment 3

[Jaap van der Leer]

Attachment: After clicking "Doorgaan" (Continue)

Comment 4

[Magnus Melin [:mkmelin]]

Confirming on Daily. Easily reproducible. Nothing in the Error Console.

The old wizard works correctly (and shows "Daily found your account setup information on antagonist.nl. Do you want to proceed and submit your credentials?"). This is a case of hosted account. The basic steps for Microsoft AutoDiscover don't get a response but we find it's hosted elsewhere. Since it's another domain, before doing the final discovery steps, we need to ask the user before we send any creds there (or you would potentially end up sending creds to an attacker domain).

Comment 5

[Martin Giger [:freaktechnik]]

Bug 1976254 made it so this also triggers for domains that have SRV records pointing at autodiscover somewhere else.

Comment 6

[Martin Giger [:freaktechnik]]

S3 because account hub issues can always be worked around by disabling account hub in settings.

Comment 7

[Jaap van der Leer]

Disabling account hub issues does not help with the looping as explained by Magnus Melin.

Comment 8

[Wayne Mery (:wsmwk)]

Are you using Exchange? If yes, then this is probably bug 1957591

Comment 9

[Jaap van der Leer]

No, I was adding a new account using a third-party provider, antagonist.nl . Not exchange, not Microsoft. Add wizard Loops because I need te give permission to proceed (after autodiscovery finds it is not Microsoft) but this permission was not asked for by Thunderbird.
I do have existing Exchange accounts, no problems with them at all.

Comment 10

[Arnold]

The Bug appears in Version 140.0.1esr with the "Neue Kontenverwaltung. I miss the password questions.

Comment 13

[Ralf Römling]

Same here with febas.de, stuck on Auto-Discover.
... and no way to manually override as in older versions... 🙄

Comment 14

[Ralf Römling]

(In reply to Ralf Römling from comment #13)

... and no way to manually override as in older versions... 🙄

Two workarounds:

• Disable the new hub wizard can be disabled under _Settings > General > Account Hub
• Hit escape key and then go through manual account creation

Comment 15

[Ben Bucksch (:BenB)]

Reproduction

1. Start TB 141 release
2. Set up any account (no matter, but there has to be another account, to go into the new Account Hub)
3. Go to Account Settings | Add account | Mail account
4. Enter my first name @bexchange.net as email address
5. [Continue]

Actual result

• A spinner comes up, above the entire dialog, blocking the window
• The spinner never stops. It goes on forever (that's the bug)
• There is no error on the error console (Ctrl-Shift-I, tab Console)

Expected result

• It asks whether to log in to 1und1.info
• It fetches the config via Exchange AutoDiscovery protocol
• It finds 2 configs:
  • OWA at winmail.eu something
  • EWS config
• I have the choice between Thunderbird EWS and Owl
• I can set up the account, at least with Owl, because Owl can use this account.

Factors

• It works in the old account creation dialog, which is used for the first email account. The bug is specific to the new Account Hub.

Impact

• Major. Blocks people from using the product.

Comment 16

[Ben Bucksch (:BenB)]

AutoDiscover of Exchange on-premise requires authentication, by (bad) design.
It is also very common for Microsoft Exchange on-premise to have usernames that are based on the Windows login username and domain and not on the email address. This affects many Exchange on-premise accounts.

Comment 17

[Ben Bucksch (:BenB)]

Similar: bug 1957591

Comment 18

[Magnus Melin [:mkmelin]]

S2: product severely impaired, and disabling account hub is not a satisfactory workaround as it's unreasonable to think users would figure that out (they did not opt in to begin with, it's default functionality).

Comment 19

[Martin Giger [:freaktechnik]]

By the way, you can close account hub when you're in this state by pressing Escape.

I think this is also affecting the @online.de domain, which is a somewhat popular email provider in Germany.

Comment 23

[Robert Hartmann]

(In reply to Ben Bucksch (:BenB) from comment #16)

AutoDiscover of Exchange on-premise requires authentication, by (bad) design.
It is also very common for Microsoft Exchange on-premise to have usernames that are based on the Windows login username and domain and not on the email address. This affects many Exchange on-premise accounts.

And if one would like to configure an IMAP-Account hosted on a local Exchange which are "shared-folders" for the individual account,
than the username becomes i.e.
[e-mail]\shared.account
where [e-mail] is the IMAP-Account you want to read with your individual password of [e-mail]

Comment 24

[Laurent]

I manage the domain name formaintinfo.com that is hosted on OVH. I was able to add it with the Account Hub without any problems.
I also manage the domain name sun-valley-systems.fr that is hosted on Ionos. When I add it the Account Hub crash.
So, in the Settings I disabled the Accound Hub and I was able to add it. When I did it mentioned Echange.
I hope this helps.

Comment 25

[Laurent]

(In reply to Laurent from comment #24)

I manage the domain name formaintinfo.com that is hosted on OVH. I was able to add it with the Account Hub without any problems.
I also manage the domain name sun-valley-systems.fr that is hosted on Ionos. When I add it the Account Hub crash.
So, in the Settings I disabled the Accound Hub and I was able to add it. When I did it mentioned Exchange.
I hope this helps.

Comment 26

[Laurent]

I manage the domain name formaintinfo.com that is hosted on OVH. I was able to add it with the Account Hub without any problems.
I also manage the domain name sun-valley-systems.fr that is hosted on Ionos. When I add it the Account Hub crash.
So, in the Settings I disabled the Accound Hub and I was able to add it. When I did it mentioned Exchange.
I hope this helps.

Comment 30

[qlum]

In general, seems to be the case for any service that enabled EWS via SmarterMail.
Tested this myself and have a relevant thread here:
https://portal.smartertools.com/community/a97408/thunderbird-140-introduces-experimental-support-for-ews-has-anyone-tested-this-with-sm.aspx#txtPostAReply

Probably a bit redundant at this point though, but may point people searching for it to the right bug.

Comment 31

[Henri D/CH]

Facing urgency to connect to my account, I found a WORK-AROUND: create a new, fake account on a server known to TB (this works fine, in this case TB finds easily the parameters). Then edit manually all the parameters including the E-mail address...
Nasty but O.K. !
The bug should be corrected by escaping the search after a while (eg 30") when no parameters are found, leaving the user entering them himself.
Note that in many cases the mail servers are on websites different from the mail address: for ex. [e-mail] <---> pop3s.hostprovider.zzz !

Comment 34

[Luc VB]

Confirmed bug for a domain hosted by the university kuleuven.be
As with Herni D/CH: I will try the workaround; a timeout of 30" for access to manual configuration should be a good solution.

Comment 37

[Vineet Deo]

Attachment: Bug 1975860 - Account Hub Email - UI for credentials confirmation for 3rd party hosted account. r=#thunderbird-front-end-reviewers

How to Test

• This is a design review, so there is no functionality
• I've set it so when you open account hub, you automatically see the new confirmation step (this will be removed when it is ready to land)
• No notification, will come when adding functionality
• No domain in text above config, will come when adding functionality

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6aab0f202bad
Account Hub Email - UI for credentials confirmation for 3rd party hosted account. r=aleca

Comment 43

[Vineet Deo]

Attachment: Bug 1975860 - Account Hub: Logic for showing credentials confirmation for 3rd party hosted account. r=#thunderbird-reviewers

Comment 44

[Ben Bucksch (:BenB)]

Hey Vineet, thanks for working on this, and thanks for posting a draft patch early. I've made an important review comment in Phab, see https://phabricator.services.mozilla.com/D265893#9193728 .

Comment 48

[De Mus]

Today I was using Thunderbird 140.3.0esr on Fedora 42 KDE and saw that I could not make connection to my e-mail address at gmail. This is an installation which was not installed today, although I could have had an update, that I don't know. Also the account existed already.
Didn't matter what I tried I could not get to my mail on the server. I then decided to delete my account and set it up fresh, and now also that doesn't work. In other words, I am now without e-mail.
Setting up an account can be done with an automated system which never asks for a password and later on when you want to make the connection to the server complains that something, probably username or password, is wrong.
When using the non automated way, you are asked for username and password, but the result is the same: no connection because something with username or password is wrong.

I also tried 128.13.0esr and this one has the same error. But as long as there is an account you never notice it. Only today in the 140.3.0esr the connection to the server is gone, also for an existing account.

Comment 49

[Arazil]

Reproduced on Debian Sid/Unstable using Thunderbird 140.3.0esr (64-bit). The target mailbox to be added was hosted on a private Mailcow server. Debian recently (as of late September 2025) pushed all supported platforms to 140.x after the 128.x branch went end of support. (https://lists.debian.org/debian-security-announce/2025/msg00176.html)

Comment 53

[github.a2]

The new Autoconfig Hub feature in Thunderbird breaks the documented CNAME-based autoconfig method that was specifically designed to support domain hosters and email service providers serving multiple customer domains.

Steps to Reproduce

1. Set up CNAME DNS record: autoconfig.customerdomain.com CNAME autoconfig.mailprovider.com
2. Host autoconfig XML at https://autoconfig.mailprovider.com/mail/config-v1.1.xml
3. SSL certificate on mailprovider.com covers *.mailprovider.com but not customer domains
4. Enable new Autoconfig Hub in Thunderbird settings (mailnews.auto_config.hub.enabled = true)
5. Attempt to configure email account for [e-mail]

Expected Results

Autoconfig should work via CNAME record, as documented in Mozilla's Thunderbird Autoconfiguration documentation and as it worked in the legacy autoconfig system.

Actual Results

Thunderbird is stuck forever with rotating circle, non responsive. There is no timeout.

Additional Information

Why This is a Regression

According to Mozilla's own security review (https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Security_review_General), the autoconfig system was explicitly designed to support domain hosters without requiring per-domain SSL certificates:

"Domain hosters and mail service providers which allow customers to buy their own domain and use that for email... want to set up an autoconfig server for their customers (incl. customers with their own domain). If we require SSL, we'd need to require that the cert domain matches the email domain... However, it's not feasible for a domain hoster to get a cert for each customer domain."

The original design decision was to allow HTTP precisely to support this use case.

Impact

This breaks autoconfig for:

• Email hosting providers serving multiple customer domains
• Domain resellers
• Web hosting companies offering email services
• Any service provider using the documented CNAME method
• Potentially thousands of domains currently using this standard configuration

Workaround

Disabling the new Autoconfig Hub (mailnews.auto_config.hub.enabled = false) restores the previous behavior and allows CNAME-based autoconfig to work.

Comment 54

[Ben Bucksch (:BenB)]

(In reply to github.a2 from comment #53)

The new Autoconfig Hub feature in Thunderbird breaks the documented CNAME-based autoconfig method that was specifically designed to support domain hosters and email service providers serving multiple customer domains.

This is an unrelated issue with the same symptom, but a different cause than this bug here. Sorry that it was marked a duplicate. I reopened bug 1992687 to track this separately.

Comment 57

[Bughunter]

I would like to provide additional information on this.

In version 143.0 / 143.0.1 the behaviour of new Autoconfig Hub is really strange: The first mail account will be added flawlessly. For the second one and every other account (at least related to same mail provider / same domain) the detection of the mail server fails. Thunderbird proposes "mail.$domain.de" what looks like a fallback to me.

Nevertheless it is possible to add mail server's data manually and finish the mail account configuration.

Comment 58

[Ben Bucksch (:BenB)]

the behaviour of new Autoconfig Hub is really strange: The first mail account will be added flawlessly ...
the second one and every other account ... fails

The first account setup uses the old account creation dialog, not the new "Account Hub". This bug is about the latter. That's why you see the confusing discrepancy between first and second+ account.

Comment 59

[Martin Giger [:freaktechnik]]

(In reply to Bughunter from comment #57)

In version 143.0 / 143.0.1 the behaviour of new Autoconfig Hub is really strange: The first mail account will be added flawlessly. For the second one and every other account (at least related to same mail provider / same domain) the detection of the mail server fails. Thunderbird proposes "mail.$domain.de" what looks like a fallback to me.

This sounds unrelated to this bug, this is about never getting past the first step where you enter your email address. Please open a separate bug for this issue. Note that you might have to provide an example email domain to reproduce this with.

Comment 60

[Vineet Deo]

Attachment: Bug 1975860 - Account Hub: Tests for credentials confirmation for 3rd party hosted account. r=#thunderbird-reviewers

Depends on D265893

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/624ccb9e2527
Account Hub: Logic for showing credentials confirmation for 3rd party hosted account. r=freaktechnik

Comment 62

[Vineet Deo]

Comment on attachment 9515147 [details]
Bug 1975860 - Account Hub: Logic for showing credentials confirmation for 3rd party hosted account. r=#thunderbird-reviewers

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: There has been a lot of bug reports for users with emails hosted on a 3rd party server unable to set up an account through account hub. This patch fixes that issue.
• User impact if declined: Users on Beta would who have accounts hosted on a 3rd party server would not be able to create an account via the account hub email setup.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: No
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1993071
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The code has a different flow for autodiscovery now in account hub, which may lead to a regression. The automated tests patch for this patch has also not yet been approved, but is not showing failures in the try run.
• Does the fix cause any migrations to be skipped?: No
• String changes made/needed: None

Comment 63

[Corey Bryant]

Comment on attachment 9515147 [details]
Bug 1975860 - Account Hub: Logic for showing credentials confirmation for 3rd party hosted account. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Note: There are string changes in AccountHub.ftl and it's not ideal to uplift in that case, however I think the impact of the fix outweighs the limited translation time in this case.

Comment 64

[Corey Bryant]

Thunderbird 145.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/4269e742a812

Comment 65

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3d808078ecc7
Account Hub: Tests for credentials confirmation for 3rd party hosted account. r=aleca

Comment 66

[Magnus Melin [:mkmelin]]

There's a new test failure, but seems only one: https://treeherder.mozilla.org/jobs?repo=comm-central&resultStatus=success%2Csuperseded%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&selectedTaskRun=f-nO2NitRH6pcLPRT-ovtA.0