Closed
Bug 1299232
Opened 8 years ago
Closed 5 years ago
Enhance autoconfig MX lookup logic to check FOO.basedomain.tld on ISPDB in addition to basedomain.tld to support office365-hosted domains
Categories
(Thunderbird :: Account Manager, defect)
Thunderbird
Account Manager
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1185366
People
(Reporter: asuth, Unassigned)
Details
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.
Comment 1•8 years ago
|
||
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.
Reporter | ||
Comment 2•8 years ago
|
||
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).
Comment 3•8 years ago
|
||
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
Comment 4•8 years ago
|
||
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.]
Reporter | ||
Comment 5•8 years ago
|
||
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.
Comment 6•8 years ago
|
||
(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
Comment 7•5 years ago
|
||
I think this is what bug 1185366 implemented.
You need to log in
before you can comment on or make changes to this bug.
Description
•