Thunderbird:Autoconfiguration

From MozillaWiki
Jump to: navigation, search

<< Back to Thunderbird:Feature_Discussions


Author: Ben Bucksch

Subpages

Other resources

See also

This is the project page. The most up-to-date and readable documentation is the Description for administrators and technical users at MDC.

Current situation

Most people are using webmail these days, mainly because it's so easy. You only need to click on a link on the provider's homepage and know your email address and password, and there's your inbox already. ISPs, although all of them provide POP/IMAP, are leading users to webmail because of that ease of use (and free mail providers do so for the advertizing revenue).

The Thunderbird account setup wizard requires knowledge of a lot of technical settings, most of which users have no clue what they mean nor where to get this information (even if it's provided readily by the ISP). For them, this is a real stop gap - at least sufficiently problematic to not bother.

Goal

Make my non-tech friends use Thunderbird, by making it dead-simple to set up. I.e. make it easy for as many users as possible to get a working Thunderbird configuration, and as secure as possible.

Ideally, setting up Thunderbird should be as easy as download/install and entering real name, email address and password. The Account Setup Wizard consists of only one screen.

  • Major Goals
    • Require only the minimal upfront information from most people
      • Name, Email address, Password
    • Provide and offer preset configurations for at least all large ISPs
    • Use SSL and/or password encryption where possible, to protect passwords and mail contents during retrieval.
  • Important Goals
    • Set of configurations can be extended and updated
    • Reduce the number of account wizard steps as much as possible
    • Reduce overall distractions for normal case (distractions = text and clutter, things not understandable or needed by most users)
    • Increase the prominence of the Email account choice
    • Don't add complexity/confusion with this
  • Possible Goals
    • Shared system for community to submit, edit, and publish configurations
    • Allow people to publish working configurations peer to peer via email

Assumptions

  • User Segmenting
    • Large ISPs (google, msn, yahoo, etc.)
      • Set of users is very large
      • Set of ISPs is small
    • Smaller ISPs
      • Set of users is moderate-sized
      • Set of ISPs is large
    • Corporate employee accounts
      • Set of users per server is small, accumulated very large
      • Set of providers and server implementations is very large and diverse
    • Personal Servers
      • Set of users per server is tiny (1-20), accumulated very small
      • Set of providers and server implementations is very large and diverse

Implementation

+--------------------------------------------------+
| *Account Setup*                                  |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| (o) E-Mail account                               |
|                                                  |
|      Full name:      [                         ] |
|      E-Mail address: [                         ] |
|      Password:       [                         ] |
|                                                  |
|      [ ] Manual configuration                    | 
|                                                  |
| ( ) RSS News Feeds and Blogs                     |
| ( ) Newsgroup account                            |
| ( ) Calendar                                     |
|                                                  |
|                       [ Cancel ]  [ Next/Done ]  |
+--------------------------------------------------+

(The UI mockup above is only an example for better understanding, see UI page for more info.)

In the Account Setup wizard, if the "Email account" radio button is selected (which is the default), 3 text fields are visible and enabled: real name, email address and password.

Email address is properly syntax-checked.

The domain if the email address is used to determine the configuration (POP/IMAP and SMTP server names, SSL yes/no, authentication methods etc.), via several mechanisms:

(For most current information, please see https://developer.mozilla.org/en/Thunderbird/Autoconfiguration .)

  1. Config files on harddisk, in installdir/isp/emailaddressdomain.xml , e.g. C:/Program Files/Mozilla/Thunderbird/isp/example.com.xml .
    • Same file format as below.
    • This is only for intranet deployments, we won't be shipping any configs by default anymore, in favor of the following alternatives.
  2. Try to get the configuration from the email provider
    1. Try to contact http://autoconfig.emailaddressdomain/mail/config-v1.1.xml?emailaddress=emailaddress , e.g. http://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=fred@example.com, as well as fallback http://example.com/.well-known/autoconfig/mail/config-v1.1.xml, and see whether that host/URL exists. The returned file must have the ConfigFileFormat as below.
    2. and/or (not yet implemented), define a DNS TXT record on domain example.net (for my.account@example.net) which contains an URL like e.g. https://www.example.net/mozilla.xml , which also returns this file format. A similar, but slightly different proposal is described in detail on DNSBasedLookup.
    3. and/or (not yet implemented) use DNS SRV records _imap._tcp.example.com etc. (Problem: Doesn't provide username form etc..)
  3. Try to find the config at the Mozilla server (if the email provider does not provide the configuration)
    • Fetch https://live.mozillamessaging.com/autoconfig/emailaddressdomain , e.g. https://live.mozillamessaging.com/autoconfig/example.com . (Email address of user is not passed, otherwise Mozilla would have a list of email addresses of all users.)
    • That file contains the mail configuration. Content is described on ConfigFileFormat.
    • This service will have the configuration for all the major ISPs and email providers, so there's a 90+% hit rate
    • It will not work for corporate email accounts.
    • If a provider disagrees with a setting there, it can override the configuration by simply providing the config server in step 2.
  4. If we couldn't find any configuration file, we try to guess the configuration using some heuristics. We try imap.domain, pop.domain, pop3.domain, smtp.domain and mail.domain, and for each, try the common 2-3 ports. We check whether SSL is available, which authentication algorithms are announces by the server in the CAPABILITIES etc..
  5. If all fails, we ask the user to enter the configuration manually.

If we could find a configuration, we're done already, with that one screen.

The password dialog does not need to come up either, as the password has already been entered by the user and the wizard filled it in using the password manager.

We should also provide an option to ignore the autoconfig and go into manual config, e.g. using a link button "Create in advanced editor" (this works exactly like the current "Email account" option) in addition to the new "Email account" option which does the automatic config.

Related Information