Open Bug 1600493 Opened 1 year ago Updated 1 year ago

Impossible to create mail account when the autodiscover.xml 401 response was not from exchange

Categories

(Thunderbird :: Account Manager, defect)

defect
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: mails.bugzilla.mozilla.org, Unassigned)

Details

Attachments

(4 files, 1 obsolete file)

Attached image Screenshot_20191201_103011.png (obsolete) —

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/78.0.3904.108 Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

Thunderbird 68.2.2, Ubuntu Linux 18.04, 64 Bit

I started with a new profile (thunderbird -p) because Thunderbird 68 totally messed up my calendar and I wanted to try if it might work with a new user profile.

In the new profile, I tried to create a mail account for my main mail address.

Actual results:

The mail account creation dialog does not provide any way to proceed and actually create the mail account (see attached screenshot).

There is no way to actually configure the server names and protocols, and no way to proceed with the dialog.

Expected results:

The mail account creation dialog obviously should allow to create a new mail account...

Additional info: I'm using Thunderbird installed from the official tar.bz2, not the version packaged by Ubuntu.

Still does not work with Thunderbird 68.3.0 - it's not possible to setup new mail accounts in Thunderbird...

This is a severe bug, especially in an officially released version.

It most likely does not occur under all circumstances, as I doubt Thunderbird 68.2 or 68.3 would have been released at all in this case.

Still, I don't know what makes my account special - Thunderbird completely refuses to allow me to configure it, doesn't provide any diagnostics information, does not give any other clue what went wrong, as far as I can see, and just "does not work" from a users point of view. And that's really bad.

I simply want to set up an IMAP account which is served by a Dovecot IMAP server. The mail addresses domain ist "ohrner.net".

I know all configuration data I would need to enter, Thunderbird just doesn't let me do it.

As I noticed that I'm just not understood in web forums if I ask how I can configure / setup a mail account in Thunderbird, I'll attach all individual steps of the setup dialog to this issue.

This screenshot shows the fresh "setup account" dialog - so far so good. I cannot enter my server configuration, but at least some information...

Attachment #9112733 - Attachment is obsolete: true

Step 2 and it's still fine:

I filled in the requested information, and the "Next" button ("Weiter") bcomes active...

Now it becomes somethat strange - klicking "Next" ("Weiter") does not advance the dialog, it just causes a "username" box to appear which wasn't there before.

That's ok in the sense that I wasn't able to enter any username before, so it's clearly still missing.

It's strange, though, as this box talks about something of "domain login" ("Domänenanmeldung"), but I simply want to configure an IMAP account on a server where I just have an individual login account. Not sure what's referred to with "Domain", but at least a Windows Domain is not involved in any way - I don't even have systems running Windows, actually.

Now there's clearly something wrong - I entered my IMAP username into the field, but still cannot click "Next" ("Weiter").

I cannot see any way to advance with the setup process at this step and am stuck.

How to continue here?

I still wasn't even able to enter my IMAP and SMTP server addresses, let alone further protocol details.

This really sucks actually, I just need a page where I can enter all server details and I'd be done in two minutes. I've now already wasted hours with this strange wizard which does not allow me to enter any relevant information and then simply does not provide any means to continue any more.

This just does not make sense.

Your account seems to be a exchange account. Please can you give us the name of the server you want to access? Without we can't help as we don't know what's happening.

Flags: needinfo?(mails.bugzilla.mozilla.org)

Your account seems to be a exchange account. Please can you give us the name of the server you want to access?
Without we can't help as we don't know what's happening.

Thanks for your reply.

No, it's a plain IMAP account (Dovecot IMAP on Linux). There's no Windows involved, neither on the server nor on the client side.

However, so far, I wasn't even able to get far enough to enter the server name in the dialog, so it cannot be related to the problem.

As I wrote above, the email account I want to configure ends with the "@ohrner.net" domain name. This is hosted by myself, clearly not present in any ISP DB and thus I'd just expect to be able to setup all technical details manually.

I also didn't setup any autoconfig information for this domain at all.

Just try it for yourself, setting up an account with an address like "randomsomething@ohrner.net" and a random password. This won't make any difference, as, to re-iterate, I didn't even get so far that I could tell Thunderbird which server to use, so it also cannot make any difference if the password is right or not.

Flags: needinfo?(mails.bugzilla.mozilla.org)

Thank you for the information. I CCed two that knows the autoconfig very well. Let's see what they say.

Mh, ok. Actually, as I wrote, this domain does not use any autoconfig setup at all, so I'd be surprised if the auto-config code on the Thunderbird side would cause any trouble here.

However, something clearly has to cause trouble... ;) Let's see if someone might have any clue what's going on. In any case, the behaviour is totally reproducable for anyone with the information I gave, so it should be relatively simple to debug.

The main think I'm wondering, though: Is there really absolutely no way to simply skip auto-whatever-magic (which obviously does not always works as desired) and configure the account manually? I'd have to do this anyway, so why isn't there just a button or any alternative way which allows me to edit the config settings myself? I know what I would have to enter there, even if Thunderbird itself has no clue... :-/

The UI is indeed confusing, and we're currently working on fixing it. (The manual setup button got fixed in bug 1590636)

What seems to happen is that there is that Thunderbird finds http://autodiscover.ohrner.net/autodiscover/autodiscover.xml but can't login. So you do have an exchange server setup?

The UI is indeed confusing, and we're currently working on fixing it. (The manual setup button got fixed in bug 1590636)

Great news, and - referring to bug 1590636 comment 23 and 24 - it would indeed be desirable to already see this fix in the 68 series.

What seems to happen is that there is that Thunderbird finds http://autodiscover.ohrner.net/autodiscover/autodiscover.xml but can't login.
So you do have an exchange server setup?

Oh dear, I never would have thought of something like this. Maybe I should have monitored Thunderbird's network communication with Wireshark or something.

No, I do not have Exchange, and there is no "autodiscover" for ohrner.net (so far).

There is, however, a wildcard DNS entry for *.ohrner.net which points to the same host as several other VHOSTS in the ohrner.net domain.

And there also is no explicit placeholder "default" VHOST config, so the first VHOST in Apache somewhat randomly ended up being stats.ohrner.net, which requires authentication. (I'm not really using this VHOST any more, otherwise I most likely would already have added a transparent redirect to https://stats.ohrner.net/ to ensure secure authentication, in which case the error would probably have been more obvious.)

So this HTTP basic authentication request has absolutely nothing to do with any mail-related things.

In my optinion it's a bug that the wizard does not provide any means to continue with account setup in case it cannot properly access some of the autodiscovery sites it "magically" and silently accesses without even telling the user about it.

And maybe I should place a "harmless" default VHOST which just shows an error message to catch HTTP accesses to unknown host names, but I would never have imagined that not having one will ever cause trouble setting up an email client... ;)

Well that's unexpected. We should probably check that the server is actually a Microsoft server and not Apache. If it's as expected, the Server header would read something like "Server: Microsoft-IIS/8.5"

Summary: Regression: Impossible to create mail account → Impossible to create mail account when the autodiscover.xml 401 response was not from exchange

Hmm, in this case, also this is the http version, http://autodiscover.ohrner.net/autodiscover/autodiscover.xml which would NEVER be authenticated anyway (just used as for redirection further), so we shouldn't care if that gives 401.

And there also is no explicit placeholder "default" VHOST config, so the first VHOST in Apache somewhat randomly ended up being
stats.ohrner.net, which requires authentication. (I'm not really using this VHOST any more, otherwise I most likely would already
have added a transparent redirect to https://stats.ohrner.net/ to ensure secure authentication, in which case the error would
probably have been more obvious.)

This really looks like a misconfigured server. Can you please just fix this, and we can move on?

We follow the AutoDiscover protocol. I'd rather not change a correct implementation of documented protocol due to a single misconfigured server that can easily be fixed.

Sorry, I haven't read the whole bug, but why does a non-exchange server serve an autodiscover.xml, and that behind an auth prompt?

Why doesn't is serve an autoconfig, like this one: http://autoconfig.jorgk.com/mail/config-v1.1.xml?

The server is not serving an autodiscover.xml, but a request to anything on http://autodiscover.ohrner.net/ is triggering a 401 and TB now thinks, it has found a valid Exchange server but the user provided wrong creds and the wizard is now stuck in the exchange wizard and asks for the EWS user name (which is different from email).

The user actually has not setup http://autodiscover.ohrner.net/ he has a catch all DNS entry and that is triggered.

Yep, but since this non-https version isn't ever supposed to give anything except 404 or a redirect to the real autodicover.xml, this part of the process is flawed. (It can't because we're not even sending it the creds.)

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

This really looks like a misconfigured server. Can you please just fix this, and we can move on?

I admit this is a probably very rare constellation and I will probably also reconfigure my server, but actually I cannot see a real "misconfiguration" here.

I'd assume that wildcard DNS entries are not that uncommon, and AFAIK there's also no rule or convention which forbids a domain's default host to use HTTP Basic Authentication.

I've not dealt with Exchange AutoDiscover before, but read about it now at https://docs.microsoft.com/de-de/exchange/architecture/client-access/autodiscover?view=exchserver-2019 (no idea if it's an authorative description) and glanced at https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxdisco/d912502b-c0e2-41a1-8b0e-f714ba523e08 (which seems to be the discovery protocol spec) and https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxdscli/78530279-d042-4eb0-a1f4-03b18143cd19 (which seems to be the actual lookup protocol).

Concerning [:mkmelin] comment that the protocol would not expect / allow the http-redirect URL to query for username and password, the "[MS-OXDISCO] Autodiscover HTTP Service Protocol" document at least discourages serving config settings via http directly, and only using the http-URL to perform a 302 HTTP redirect to an https-URL. It does not strictly require it, though. (The wording is "SHOULD" and "SHOULDN'T", not "MUST".) It does not say anything about authentication, as far as I could see.

"[MS-OXDSCLI]: Autodiscover Publishing and Lookup Protocol" recommends the use via HTTPS and recommends the use of client authentication before serving config details, but does not strictly require either.

However, sending login credentials via unencrypted channels is probably no really good idea nowadays. (At least not before explictly asking. Which brings me to the question: Did the TB Exchange Wizard possibly send my mail username and password in plain text to my server in an attempt to authenticate?!? I really hope it didn't, and this would be a real security hole from my point of view...)

However, once you're redirected to the https-URL, a certificate name mismatch would make it immediately clear that the TB Exchange Wizard is on the wrong track. (And would need to react accordingly of course.)

The current UX is pretty bad, though, as such constellations (even though rare) can happen (as my case shows) and the TB Exchange Wizard does not give any indication concerning what went wrong or why it gets stuck.

@Magnus:
Yeah, if you wanted, I guess it could be fixed this way. If the http call didn't redirect to https, return an error.
I'd rather not complicate the code for this extreme edge case, or even break other cases for it, but I'll have to see how this would look like in code. It's possible that there is a clean fix.

@Gunter:

wildcard DNS entries are not that uncommon, and AFAIK there's also no rule or convention which forbids a domain's default host to use HTTP Basic Authentication.

Wildcard DNS entries are generally a bad idea, for reasons like this. Some hosters offer them. But they break a lot of stuff. This isn't the only thing that will go wrong.

DNS wildcards surely do exist, I've never seen one with HTTP auth on it. Usually, they just redirect to the main website. Sure, it's not forbidden, but it causes this specific issue here.

Your server does respond to AutoDiscover requests, so your server is clearly causing this bug, and not TB.

sending login credentials via unencrypted channels is probably no really good idea nowadays

We're not.

Did the TB Exchange Wizard possibly send my mail username and password in plain text to my server in an attempt to authenticate?!? I really hope it didn't, and this would be a real security hole from my point of view...

Ok, according to my server's logs, apparently it didn't. Which is good, at least. :)

You need to log in before you can comment on or make changes to this bug.