See bug 1185366 for more details, but the scenario is basically that office365.com-hosted domains use an MX of "domain.mail.protection.outlook.com" which results in an ISPDB lookup of "outlook.com" that collides with email addresses of the form "foo@outlook.com". If Thunderbird's autoconfig learned to also ask for "mail.protection.outlook.com" and "protection.outlook.com", the ISPDB could host entries for them that would result in being able to distinguish between these two colliding use-cases. Other solutions are also possible, but this is the most straightforward that avoids getting into name-mangling collision issues. Note that while I'm still helping out with the ISPDB, I'm not longer writing patches for Thunderbird, so if you're reading this and interested in helping, please do think about contributing a patch! But please do be aware of the pending patches in bug 971347 and try to avoid bit-rot in either direction.

In my infinite wisdom, I use the domain name of "example.com" in my local home LAN where I test C-C TB patches. I thought no sane person would use example.com for a domain name, and thus I thought I was safe. Wrong. It seems that C-C TB mozmil testing seems to use a concocted name of example.com somewhere for internal testing purposes, especially during autoconfig setting. It collide with the real local "example.com" domain name of my home LAN (internal and separated by firewall, but local internal DNS server serves example.com domain names and host names inside. ) Agha. (On a different machine, which is located in a LAN with a globally unique domain name, the clash does not happen and I don't see the failure of autoconfig testing there.) Maybe I should look into this DNS issue to figure out how I can possibly fix this test failure issue. I meant to look into this for a long time. But if anyone wants to look into this, please do so. I will be tied up for about a couple of weeks with business trip for my day job.

Thanks for looking into this! Since example.com is spec'ed to exist on the internet/etc., it's probably advisable to not use it locally. That said, I agree tests should really not be using it; I wonder if they assumed the domain was not hosted (it is), and are accidentally depending on it. The right test fix for that is likely to move to using (more) fake-servers in conjunction with the mochitest proxy mechanism that mochitests use (see https://dxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt).

HI, I have no comprehension of services used during testing, so bear with my totally ignorant questions. Just as I thought, the strange failures of autoconfig of C-C TB during |make mozmill| test are gone once I changed the local LAN's (firewalled internal-only) domain to example.localdomain from example.com. So obviously the test seems to depend on example.com domain in a manner I can't fathom exactly. Can someone enlighten me about the following? How is domain "example.com" resolved during testing?. Specifically, ... Q1. Does the test harness play a funny thing and decides to return its own internal DNS resolution that is independent of the locally available DNS setting? ---> The answer seems to be "No" due to the error when I used "example.com" local domain name (the local DNS server provides the SOA for it), and I could solve it by NOT using "example.com" locally. [OTOH, my environment that uses example.com offered an opportunity to test error recovery handling in automatic configuration when servers do not respond in time, but I digress.] Given that the answer to Q1 above is likely to be "No", then it seems that the tests seem to depend on external DNS (or /etc/hosts table) to provide example.com, www.example.com, autoconfig.com, etc. to be provided. I don't see such file-based data in C-C TB distribution if I am not mistaken, so I assume that "example.com" domain is resolved using DNS. Q2. Does try-comm-server, and/or other build infrastructure environment refer to a specially crafted mozilla-only DNS to resolve example.com and other domain names for test-purposes? (--> I suspect that the answer is likely to be "No" since on TWO (2) PCs where I use local DNS server that does not provide such specific mapping of "example.com" domain) can run |make mozmill| test suite successfully. But there seem to be more than example.com domain involved, and so I am curious to learn.) Q3: If the answer to Q2 is "Yes" and mozilla test infrastructure expects to have certain services at known domain names, then what services are expected where (domain names)? Now it dawns on me that maybe the so-called proxy mechanism mentioned in comment 2 is responsible for mapping specific service expected at a certain test domain name to a fake server or real server used during testing purposes? If so, presumably C-C TB's mozmill probably uses something similar then. That is, it is possible the test harness receives all the queries or requests for services to a proxy and then hands them out to the local fake-servers and such without bothering (?) to check the DNS domain name? [But this still fails to explain why my firewalled internal LAN failed to run the autoconfig tests successfully when I used "example.com" domain name. So the proxy still may refer to the external DNS here and there ???] TIA

BTW, without special local DNS that offers example.com domain, we can usually resolve example.com domain hosted by IANA. cf. From: http://www.iana.org/domains/reserved --- begin quote IANA-managed Reserved Domains Certain domains are set aside, and nominally registered to “IANA”, for specific policy or technical purposes. Example domains As described in RFC 2606 and RFC 6761, a number of domains such as example.com and example.org are maintained for documentation purposes. These domains may be used as illustrative examples in documents without prior coordination with us. They are not available for registration or transfer. --- end quote And we can resolve some names related to example.com that is hosted by IANA. $ nslookup example.com. Server: 172.20.1.3 Address: 172.20.1.3#53 Non-authoritative answer: Name: example.com Address: 93.184.216.34 $ nslookup www.example.com. Server: 172.20.1.3 Address: 172.20.1.3#53 Non-authoritative answer: Name: www.example.com Address: 93.184.216.34 $ nslookup autoconfig.example.com Server: 172.20.1.3 Address: 172.20.1.3#53 ** server can't find autoconfig.example.com: NXDOMAIN SOA record is returned by IANA. ishikawa@debian-vbox-ci:/extra/ishikawa/download/TB-3HG/NEW-COMMSRC$ nslookup -type=soa example.com. Server: 172.20.1.3 Address: 172.20.1.3#53 Non-authoritative answer: example.com origin = sns.dns.icann.org mail addr = noc.dns.icann.org serial = 2015082670 refresh = 7200 retry = 3600 expire = 1209600 minimum = 3600 Authoritative answers can be found from: example.com nameserver = a.iana-servers.net. example.com nameserver = b.iana-servers.net. a.iana-servers.net internet address = 199.43.135.53 a.iana-servers.net has AAAA address 2001:500:8f::53 b.iana-servers.net internet address = 199.43.133.53 b.iana-servers.net has AAAA address 2001:500:8d::53 So example.com domain is hosted by IANA to make sure that it is already registered (and not abused by others since there are many scripts and sample programs that refer to the domain: some people accidentally access the domain for real), and www.example.com and example.com resolve to the same IPv4 address of 93.184.216.34 (this linux image I use don't have IPv6 enabled, it seems) in the current IANA setup. autoconfig.example.com does not exist. I find the following domain names that are used during |make mozmill| test suite of C-C TB, and they don't exist. imap.example.com testin.example.com testout.example.com Both http://www.example.com and https://www.example.com exist and can be accessed and shows an explanatory note --- begin quote --- Example Domain This domain is established to be used for illustrative examples in documents. You may use this domain in examples without prior coordination or asking for permission. More information... --- end quote --- MX does not seem to exist for example.com. $ nslookup -type=mx example.com Server: 172.20.1.3 Address: 172.20.1.3#53 Non-authoritative answer: *** Can't find example.com: No answer Authoritative answers can be found from: example.com origin = sns.dns.icann.org mail addr = noc.dns.icann.org serial = 2015082670 refresh = 7200 retry = 3600 expire = 1209600 minimum = 3600 Conclusion: If the tests somehow depend on these arbitrary settings of example.com (hosted by IANA), that is bad. But still I am not sure how mozilla's test use these test domain names using proxy and real DNS services, etc. Is there a document that gives an overview? [I can't figure out why my local LAN that uses "example.com" setting fails autoconfig test.]

I think the answers to Q1 and Q2 are no. In comment 2 I was referring to https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#How_do_I_test_issues_which_only_show_up_when_tests_are_run_across_domains.3F which suggests mochitests use the proxy autoconfig mechanism of Firefox to allow faking things, although how it does that I do not currently know.

(In reply to Andrew Sutherland [:asuth] from comment #5) > I think the answers to Q1 and Q2 are no. In comment 2 I was referring to > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/ > Mochitest#How_do_I_test_issues_which_only_show_up_when_tests_are_run_across_d > omains.3F which suggests mochitests use the proxy autoconfig mechanism of > Firefox to allow faking things, although how it does that I do not currently > know. Thank you! I will try to digest what FF does in mochitest. Now if only someone knows what C-C TB does during mozmill test... I hope that the trick C-C TB uses during |make mozmill| test is not that different form mochitest magic. TIA