Thunderbird:Autoconfiguration:DNSBasedLookup

DNS based discovery of configuration/setup files for mail clients

Proposal by Eddy Nigg

Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

"TB" refers to Thunderbird and may represent any mail client.

Overview

Configuration files for all mail servers would be fetched according to the following standard, providing a unified approach and UI, based on existing discovery channels and transport layers.

Definitions

The location of the configuration file shall be discovered by the following method:

1.) The MX record(s) of the user supplied email address is fetched from the DNS zone. In case no MX record exists, the A record of the base domain name is used [RFC 2821]. If there are MX records of different priorities, only the one with the highest priority is used, because lower priority ones may go to backup servers with a different setup.

2.) A TXT record with the content "mailconf=https://URL" is fetched from the DNS zone based on the lookup above.

3.) A sanity check shall be performed (correctness of the URL) and in case of failure proceed to the next possible TXT record as shown above. Only SSL secured locations are possible, meaning the protocol prefix https:// must be present.

4.) When no valid TXT record is found, automatic setup is not possible and aborted. The first valid TXT record shall be used in order to fetch the configuration file.

5.) In case the SSL secured server

5.1.) can not be chained to a trusted root

5.2.) the domain of the email address that the user entered does not match any of the domain names in the cert,

5.3.) (optional) the domain of the HTTP server hostname does not match any of the domain names in the cert,

the connection must be aborted. TB may use the next valid TXT record if possible and repeat this step.

6.) TB shall include the originally requested email value as referrer information in its GET headers . The value of the referrer header shall have the format "mailto:user@domain.com". Alternatively, the email address is passed as URL query parameter. This allows serving of dynamically generated configuration files, since the referrer information retains the originally requested domain name and allows per domain and per user setup.

7.) The configuration file is downloaded and checked for sanity and parsed. At this stage the user is presented with a UI dialog, stating the location of the configuration file (The actual URL from the which the config was fetched) and present other useful information.

8.) The user may make selections such as different choices (like POP3 versus IMAP or IMAP versus IMAPs etc.). Alternatively TB may use by default best and most secure protocols.

9.) The user confirms his preferences (if any) and confirms the setup of the account.

10.) TB tries to use the new settings and prompt for passwords etc. as usual.

Advantages

1.) Unified standard for all ISPs.

2.) Unified UI implementation possible.

3.) Uses existing infrastructures, protocols and transport layers.

4.) Reasonable secure.

5.) Highly scalable for public Internet and Intranet alike.

6.) Decentralized and autonomous.

7.) Minimal requirements and short implementation time on part of the ISP.

Examples

DNS record example:

mta1 IN A 192.192.202.201

       IN    MX 10    mta1.domain.com.
       IN    TXT     "mailconf=https://someurl/somepath/somefile"

mta2 IN A 192.192.202.202

       IN    MX 20    mta2.domain.com.
       IN    TXT     "mailconf=https://someurl/somepath/somefile"

Disclaimer

This standard shall be licensed according to Mozilla compatible licenses and is copyright (c) 2008 of Eddy Nigg and other contributors. Not sure if this is needed, but prefer to be on the save side for now, just in case other vendors want to adopt it. In short, rather save then sorry ;-) Please advice on this.

Implementation in Thunderbird

DNS record fetches are not trivial to implement, as dmose says, because Mozilla has no API to fetch arbitrary DNS records (like TXT), only to resolve hostnames (A records).

Checking the SSL cert's domain name against an arbitrary domain name (in our case the email address domain) may or may not be easy with Mozilla's APIs, unclear.

 Should be part of NSS. URL should be displayed in the UI. Eddyn 19:15, 17 March 2008 (PDT)

RFC

There is currently a RFC in the making with the same goal: Use of SRV records for locating email services