1902742 - Some display names from ISPDB are mistakenly parsed as a date

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect, P2)

Description

[Brendan Abolivier [:babolivier]]

When experimenting with outgoing EWS configurations for Thunderbird's upcoming Exchange implementation, I noticed that the display name for an outgoing Microsoft 365 server (which is discovered via ISPDB, following an MX record lookup) would turn up as "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)", which I found weird.

When digging a bit further, I stumbled upon our JXON implementation, which role is to turn an XMLDocument into a more JS-like object structure, i.e. one where a child element can be accessed with parent.child rather than parent.getElementsByTagName("child")[0]. This implementation comes from bug 759422, which copies it from https://web.archive.org/web/20121105150802/https://developer.mozilla.org/en-US/docs/JXON with a few modifications.

When parsing text (here), because JXON doesn't know what kind of data is in the text of an XML node, it tries to be helpful and parse this text as different types via trial an error, before deciding it can't do anything more with it and returning it as plain text. One of these checks is whether Date.parse(text) returns a finite number. If so, it returns a new Date object from the text.

It turns out that for some reason, Date.parse("Microsoft 365") does return a finite number. And the string representation of a Date object created from the string "Microsoft 365" is "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)".

When looking at the comm-central repository, it appears we nowadays only use JXON (or its main consumer, FetchHTTP) in two contexts, both in the account setup code:

• when parsing an autoconfig file, or
• when parsing an Exchange autodiscover response

The autoconfig file format does not specify any element containing a date, and the method used to process an Exchange autodiscover response does not seem to access any element that is expected to contain a date.

Therefore, and considering the discussion in bug 759422 (which leads me to think we do this only because the place we copied it from does), I propose removing this check/conversion to Date from the JXON implementation.

Ideally I think we should remove these conversion attempts altogether and let the consumer (which is the code that is supposed to know how to interpret each element's content) in charge of converting a value to the correct type, but I can settle with considering this as a future step.

Comment 1

[Ben Bucksch (:BenB)]

Date object created from the string "Microsoft 365" is "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)".

😂

Comment 2

[Ben Bucksch (:BenB)]

removing this check/conversion to Date from the JXON implementation.

Makes sense, +1

Thanks for having checked that we never expect values to be a Date.

Comment 3

[cketti]

It looks like none of work done by JXON.parseText() is depended upon by code using a JXON object. +1 for removing all of JXON.parseText().

Comment 4

[Alessandro Castellani [:aleca]]

I'm not sure if we want to uplift this to 128 if it's only Exchange related.
Let's see how "simple" is the fix and we can consider.

Comment 5

[Brendan Abolivier [:babolivier]]

It's not Exchange-related in itself (but more that we stumbled upon it when testing Exchange support). It's a fairly uncommon failure, but could theoretically apply to any email service which name falls into the weird edge cases of JavaScript's supported date formats, regardless of whether this service uses Microsoft Exchange (we use JXON to parse ISPDB/autoconfig responses). In this case something like "Foo 9001" would also be impacted, or even an M365 account using IMAP/SMTP.

It's still a fairly rare bug, so I'm not sure uplifting would make sense, although that might be balanced out by happening for a major provider.

Comment 6

[Francesco]

FWIW, I set up an O365-based IMAP account in TB 128 the other day and was very surprised about the strange account name that was assigned.

Comment 7

[Magnus Melin [:mkmelin]]

Attachment: Bug 1902742 - Prevent display names from ISPDB mistakenly being parsed as a date. r=#thunderbird-reviewers

Comment 8

[Magnus Melin [:mkmelin]]

Strange that this wasn't reported before...

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5bff57dca023
Prevent display names from ISPDB mistakenly being parsed as a date. r=babolivier

Comment 10

[Magnus Melin [:mkmelin]]

Comment on attachment 9421215 [details]
Bug 1902742 - Prevent display names from ISPDB mistakenly being parsed as a date. r=#thunderbird-reviewers

[Approval Request Comment]
User impact if declined: badly displaying smtp server name for i365
Testing completed (on c-c, etc.): c-c, beta
Risk to taking this patch (and alternatives if risky): safe

Comment 11

[Corey Bryant]

Comment on attachment 9421215 [details]
Bug 1902742 - Prevent display names from ISPDB mistakenly being parsed as a date. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr128

Comment 12

[Daniel Darnell [:dandarnell]]

Thunderbird 128.2.1esr:
https://hg.mozilla.org/releases/comm-esr128/rev/333b99c93dfc