563958 - Consider DNS MX in autoconfig, client-side DNS lookup

Status: RESOLVED WORKSFORME

(Thunderbird :: Account Manager, defect)

Description

[Ben Bucksch (:BenB)]

+++ This bug was initially created as a clone of Bug #551519 +++

When we try to find a configuration for an email address, we currently only look at the domain in the email address.
This won't work for domain hosters which host many customer domains and do not publish the config themselves (see bug 534722).
For those, we are likely to find a config, if we query based on the domain the DNS MX record (the server which receives mail for that domain). Due to SSL limitations, it typically has the hostname in the domain of the hoster, not the customer.

So,
If all lookups apart from the heuristic failed,
1. look up DNS MX <domain-in-emailaddress>, get e.g. mx1.dreamhost.com
2. take the SLD only, e.g. dreamhost.com
   (attention for .co.uk - Mozilla/Firefox has a list of those)
3. start the lookup again from the beginning, for that new domain,
   including ISP fetch, Mozilla DB.
4. I'm not sure whether we should start the heuristic on the original domain or the MX domain, or both. In favor of a faster probe and/or limiting the amount of connections, we should be careful before doing both.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

We need to be able to do DNS MX lookups for that. We don't have that ability in Mozilla yet, that's what bug 545866 is about. For the mean-time, we used a webservice to do the DNS lookup, which is of course silly, but was the only alternative.

This bug tracks changing to the client-side DNS lookups. I.e. once bug 545866 is fixed, we just replace the function getMX() in fetchConfig.js.

Comment 1

[Michael A. Pasek]

Note that server "A", which receives SMTP connections from Internet servers for mail destined to recipients of that domain, may not be the same as server "B", which is the SMTP server to which customers of the ISP are supposed to send their mail for relay/delivery elsewhere.

Also, doing permanent configuration based on DNS lookups is subject to fail for a split-DNS scenario, depending on the "view" the client has at the time of the configuration and whether the MX records are the same (i.e., same hostname) for all views.

Comment 2

[Nikolay Shopik]

That's why SRV RR is superior than MX records for that type of configuration.

Comment 3

[Ben Bucksch (:BenB)]

Nobody is claiming that the MX server is the same as the IMAP server. We're looking at the *domain* of the MX server. Please read the proposal.

Comment 4

[Ben Bucksch (:BenB)]

As for SRV: That's bug 342242 (and only helps when DNS SRV records exist)

I think none of you two have actually read the initial description.

Comment 5

[Michael A. Pasek]

(In reply to comment #3)
> Nobody is claiming that the MX server is the same as the IMAP server. We're
> looking at the *domain* of the MX server. Please read the proposal.

I read the description (never claimed MX==POP/IMAP).  I think the statement "For those, we are likely to find a config, if we query based on the domain the DNS MX record (the server which receives mail for that domain)." is an assumption, but I don't know why you would make the assumption that the domain of the MX server for the user's email address is any more likely to produce a viable configuration than the domain of the email address domain would.

Looking through 534722, I don't see what problem you're trying to solve in this bug -- other than the case where "Domain X" doesn't have a config file for you to access; there's no reference to this bug in 534722, and the description (#3) starts the whole lookup process over -- not just the ISP fetch part.

In my example in Comment #1, server "A" wasn't intended to be seen as an IMAP/POP server; that would likely be a completely different server.  For "domain hosters which host many customer domains", server "A" might deliver mail to server "C" for domain "C", and server "D" for domain "D" -- the lookup based on the domain of server "A" will not produce a viable config for users whose email addresses are in domain "C" or "D".

The split-DNS observation of comment #1 still applies.

Comment 6

[Ben Bucksch (:BenB)]

You didn't understand what this bug is about. Please read the last 2 paragraphs of the initial description again. We *already* do the MX lookups and use them. We just use a webservice to do the lookup. This bug is about doing the DNS lookup within Mozilla. Nothing in the logic changes, only the technical way to do the DNS lookup.

Comment 7

[Ben Bucksch (:BenB)]

In other words, we already do everything between the +++++ lines. We just couldn't do the DNS looup in Mozilla, so we use a HTTP webservice for that. This bug should fix that: to not use a webservice for MX lookups anymore, but directly the DNS protocol.

Comment 8

[Michael A. Pasek]

Yes, the description was not clear that the process using the MX's domain was already done.  Looked at 545866, but not 551519 (where the part between the "+++" came from).  Given Comment #2 in 551519, I'm surprised it was done -- but that's "water under the dam".

I definitely agree that doing the DNS lookups directly rather than relying on an HTTP server is likely to provide a more reliable service.  Sorry for the spam.

Comment 9

[Ben Bucksch (:BenB)]

> Given Comment #2 in 551519, I'm surprised it was done

FWIW, we're not doing what I describe in bug 551519 comment 1.

Comment 10

[Magnus Melin [:mkmelin]]

We do client side DNS MX lookups these days (using DNS.sys.mjs)