1679759 - Exchange autodiscover email redirect nonfunctional

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[[e-mail]]

The email redirect functionality in the Exchange autodiscover sequence appears to be based on either outdated or erroneous documentation, so it is checking for the wrong XML elements. Even if the XML elements were correct, the code is attempting to invoke a non-existent function, so the redirect would fail anyway.

Comment 1

[[e-mail]]

Attachment: Proposed patch

Comment 2

[Ben Bucksch (:BenB)]

Yes, I mis-read the docs: They said 'If the value of the Action element is "Redirect"', which is an attribute value, and I mis-read it as element. I had no test-case, so I couldn't find this.

Comment 3

[Ben Bucksch (:BenB)]

Comment on attachment 9190281 [details] [diff] [review]
Proposed patch

Review of attachment 9190281 [details] [diff] [review]:
-----------------------------------------------------------------

r+, with the changes mentioned.

::: mail/components/accountcreation/content/sanitizeDatatypes.js
@@ +118,5 @@
> +   * A value which resembles an email address.
> +   */
> +  emailAddress(unchecked) {
> +    let str = this.nonemptystring(unchecked);
> +    if (!/^[a-z0-9\-%+_\.\*]+@[a-z0-9\-\.]+\.[a-z]+$/.test(str)) {

Compare `emailRE` in emailWizard.js.

We should move that here and use `sanitize.emailAddress()` within emailWizard.js  `validateEmail()`.

Comment 4

[Ben Bucksch (:BenB)]

Thanks!

Comment 5

[[e-mail]]

(In reply to Ben Bucksch from comment #2)

Yes, I mis-read the docs. I had no test-case, so I couldn't find this.

Actually that document itself contained an erroneous example of the non-existent element, so it's not surprising that you were confused.

(In reply to Ben Bucksch from comment #3)

Compare emailRE in emailWizard.js.

We should move that here and use sanitize.emailAddress() within emailWizard.js validateEmail().

I had a look at validateEmail and it's just used to display a hint, so calling sanitize.emailAddress() appears to be inappropriate. But I could still use emailRE from emailWizard.js if you think it's appropriate to use.

Comment 6

[Ben Bucksch (:BenB)]

Comment on attachment 9190281 [details] [diff] [review]
Proposed patch

OK, r=BenB

Comment 7

[Magnus Melin [:mkmelin]]

Please attach a sample xml for this, which we could use for testing and also automated tests.

Comment 8

[Magnus Melin [:mkmelin]]

Comment on attachment 9190281 [details] [diff] [review]
Proposed patch

Review of attachment 9190281 [details] [diff] [review]:
-----------------------------------------------------------------

Also, please set up hg properly so that the patch header contains the user details.

Comment 9

[Ben Bucksch (:BenB)]

Please attach a sample xml for this, which we could use for testing and also automated tests.

Good idea

Comment 10

[[e-mail]]

Attachment: Sample XML file

Taken from https://o365info.com/autodiscover-flow-in-an-exchange-hybrid-environment-part-2-of-3-part-33-of-36/ step 11 of 30.

Comment 11

[[e-mail]]

Attachment: Patch with HG headers

Comment 12

[[e-mail]]

(In reply to Magnus Melin from comment #7)

Please attach a sample xml for this, which we could use for testing

I'm writing a detailed comment on what would be required to test this manually, at least.

Comment 13

[[e-mail]]

The most common use of this feature is in a hybrid Exchange scenario, but for testing purposes we can use a regular Exchange account. This will be the destination account listed in the dummy XML. I’ll assume that Autodiscover already works for this account. Since we’re not using hybrid Exchange, the source account must not be an Exchange account, so that we can set up the dummy XML for it.

The dummy XML must be accessible at one of the three supported Autodiscover locations:

• POST https://autodiscover.domain/autodiscover/autodiscover.xml
• POST https://domain/autodiscover/autodiscover.xml
• GET http://autodiscover.domain/autodiscover/autodiscover.xml redirecting to POST https://

A real Autodiscover Server would authenticate the https: connections so that it can provide a user-specific redirect address although for testing purposes Thunderbird will accept a "static" unauthenticated document.

I understand that Ben is willing to host a script on the beonex.com domain which will respond with an XML file that will redirect to an Exchange email address of your choice.

Comment 14

[Ben Bucksch (:BenB)]

Ben is willing to host a script on the beonex.com domain

Actually, I can only host static files (via HTTP GET), not scripts. Given that HTTP POST is required, I don't think that will work.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/df66147d9492
Use correct XML elements to detect email autodiscover redirection r=BenB

Comment 16

[Magnus Melin [:mkmelin]]

I assume 78 is affected as well?

Comment 17

[Ben Bucksch (:BenB)]

Yes, sir!

We still need to change the login email address to the redirected one, though. UPDATE: That's bug 1682890.

Comment 18

[[e-mail]]

I'll file a new bug for that to make it easier to keep track.

Comment 19

[Ben Bucksch (:BenB)]

Comment on attachment 9193054 [details] [diff] [review]
Patch with HG headers

[Approval Request Comment]
User impact if declined: Certain users whose server uses the RedirectAddr feature cannot set up their account
Testing completed (on c-c, etc.): Bake a few days on trunk
Risk to taking this patch (and alternatives if risky): Old code was completely broken (based on faulty spec). Risk close to zero.
Should be landed together with bug 1682890.

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9193054 [details] [diff] [review]
Patch with HG headers

[Triage Comment]
Approved for esr78

Comment 21

[Rob Lemley [:rjl]]

Thunderbird 78.6.1:
https://hg.mozilla.org/releases/comm-esr78/rev/981ca0f7b96d