Thunderbird:Autoconfiguration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Fix MDN link, which MDN broke)
 
(98 intermediate revisions by 11 users not shown)
Line 1: Line 1:
= Goal =
<small>[[Thunderbird:Feature_Discussions|<< Back to Thunderbird:Feature_Discussions]]</small>


Objective: Make my non-tech friends use Thunderbird, by making it dead-simple to set up.


Most people are using webmail these days, mainly because it's so easy. You only need to know the URL (usually linked from the provider's homepage) and 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).
__TOC__


Goal: 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.
Author: Ben Bucksch


= Proposal =
Subpages
* [[Thunderbird:Autoconfiguration:UI|UI screen proposals]]
* [[Thunderbird:Autoconfiguration:ConfigFileFormat|Config file format]]
* [[MailServerList|MailServerList]]
* [[Thunderbird:Autoconfiguration:DNSBasedLookup|DNS TXT-based ISP config lookup]]
* [[Thunderbird:Autoconfiguration:Security|Security considerations]], [[Thunderbird:Autoconfiguration:Security_review_General|General Security review]], [[Thunderbird:Autoconfiguration:Security_review_FetchConfigFromISP|ISP Fetch Security review]]
* [[Thunderbird:Autoconfiguration:MozillaWebservicePublish|ISP configuration database]]
* [[Thunderbird:Autoconfiguration:NextSteps|Next Steps]]


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.
Other resources
* [https://support.mozilla.org/kb/automatic-account-configuration End-user documentation]
* [https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration Description for administrators and technical users]


Email address is properly syntax-checked, and the existance of the domain in DNS is checked.
= See also =


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:
This is the project page. The most up-to-date and readable documentation is the [https://developer.mozilla.org/en/Thunderbird/Autoconfiguration Description for administrators and technical users] at MDC.


# The legacy rdf files in <installdir>/isp/, like we have for Google Mail right now. (This may be dropped in favor of the next steps.)
= Current situation =
# Try to contact a mail configuration server of the provider
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).
#* E.g. define an DNS TXT record or similar on domain example.net (for my.account@example.net) which contains an URL like https://mailconfig.example.net/mozilla.xml .
#* That file contains the mail configuration, essentially the same as in RDF files, just the format in normal XML and a bit cleaned up. The email address (before @ or with domain) that the user can be used as placeholder in the config file, so the file is the same for all users (i.e. static).
# If the email provider does not provide the configuration, we try to find it at a Mozilla server
#* E.g. https://autoconfig.mozillamessaging.com/example.net/config.xml
#* 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 company email addresses.
#* If a provider disagrees with a setting there, it can override the configuration by simply providing the config server in step 2.
# Other ways, esp. for company email accounts? Avoid heuristics and trail&error!
# If all fails, we ask the user to enter the configuration, using the existing wizard.


If we could find a configuration, we're done already, with that one screen.
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.


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.
= Goal =


We should also provide an option to ignore the autoconfig and go into manual config, e.g. using an extra radio button "Email account, manual configuration" (this works exactly like the current "Email account" option) in addition to the new "Email account" option which does the automatic config.
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.


= UI =
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.


<pre>
* Major Goals
+--------------------------------------------------+
** Require only the minimal upfront information from most people
| *Account Setup*                                 |
*** Name, Email address, Password
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
** Provide and offer preset configurations for at least all large ISPs
| (o) E-Mail account                              |
** Use SSL and/or password encryption where possible, to protect passwords and mail contents during retrieval.
|                                                  |
* Important Goals
|      Full name:      [                        ] |
** Set of configurations can be extended and updated
|      E-Mail address: [                        ] |
** Reduce the number of account wizard steps as much as possible
|      Password:      [                        ] |
** 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
|      [ ] Manual configuration                    |
** Don't add complexity/confusion with this
|                                                  |
* Possible Goals
| ( ) RSS News Feeds and Blogs                    |
** Shared system for community to submit, edit, and publish configurations
| ( ) Newsgroup account                           |
** Allow people to publish working configurations peer to peer via email
| ( ) Calendar                                    |
|                                                  |
|                      [ Cancel ]  [ Next/Done ]  |
+--------------------------------------------------+
</pre>


(unchecked Manual config means auto config; network call status at bottom, left of Cancel button)
Assumptions
or:
* 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 =
<pre>
<pre>
+--------------------------------------------------+
+--------------------------------------------------+
Line 68: Line 76:
|      Password:      [                        ] |
|      Password:      [                        ] |
|                                                  |
|                                                  |
|      (o) Auto-detect: Status here(*)            |
|      [ ] Manual configuration                    |  
|      ( ) Manual configuration                    |  
|                                                  |
|                                                  |
| ( ) RSS News Feeds and Blogs                    |
| ( ) RSS News Feeds and Blogs                    |
Line 77: Line 84:
|                      [ Cancel ]  [ Next/Done ]  |
|                      [ Cancel ]  [ Next/Done ]  |
+--------------------------------------------------+
+--------------------------------------------------+
(*) Auto-detect status text:
    1.  Fill-in the fields above
    2.  Searching...
    3a. Completed (found configuration)
    3b. Failed (use manual configuration)
</pre>
</pre>


(The UI mockup above is only an example for better understanding, see [[Thunderbird:Autoconfiguration:UI|UI page]] for more info.)


If the user finished (onblur) the email address text field (e.g. while he enters the password), the wizard makes network requests to try to find the configuration. The network activity is indicated by a spinner next to the "Searching..." text.
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.


If we found a configuration, the spinner is removed and the "Next" button turns into "Done". In that case, there is no second page, not even the summary screen. The user ends up directly in his inbox, which was the goal.
Email address is properly syntax-checked.


If the user checks the [x] manual configuration option, the "Done" button turns into "Next" again. The server names etc. from the autoconfig file are still used in this case, but only to pre-fill the UI fields. That way, an advanced user can see, check and alter the values, but still takes advantage of autoconfig when possible. Open question: What about settings that are in the config file, but not exposed in the wizard? Used or not? May be important, but user can't check them before use.
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:


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


It should be XML, with a clearly defined format, to be stable and usable by other mail clients, too.
# Config files on harddisk, in <i>installdir</i>/isp/<i>emailaddressdomain</i>.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.
# Try to get the configuration from the email provider
## Try to contact http://autoconfig.<i>emailaddressdomain</i>/mail/config-v1.1.xml?emailaddress=<i>emailaddress</i> , 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 [[Thunderbird:Autoconfiguration:ConfigFileFormat|ConfigFileFormat]] as below.
## 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 [[Thunderbird:Autoconfiguration:DNSBasedLookup|DNSBasedLookup]].
## and/or (not yet implemented) use DNS SRV records _imap._tcp.example.com etc. (Problem: Doesn't provide username form etc..)
# Try to find the config at the Mozilla server (if the email provider does not provide the configuration)
#* Fetch https://live.mozillamessaging.com/autoconfig/<i>emailaddressdomain</i> , 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 [[Thunderbird:Autoconfiguration:ConfigFileFormat|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.
# If we couldn't find any configuration file, we try to guess the configuration using some heuristics. We try imap.<i>domain</i>, pop.<i>domain</i>, pop3.<i>domain</i>, smtp.<i>domain</i> and mail.<i>domain</i>, 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..
# If all fails, we ask the user to enter the configuration manually.


The current RDF format seems good in structure, but needs to be cleaned up to remove the RDF bits, Mozilla specifics etc.. It would be processed as normal XML, e.g. using E4X in Thunderbird.
If we could find a configuration, we're done already, with that one screen.


<pre>
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.
<?xml version="1.0"?>
<clientConfig
    xmlns="http://mailconfig.mozillamessaging.com/fileformat/namespace/2008">
 
    <emailProvider id="googlemail.com">
      <domain>gmail.com</domain>
      <domain>googlemail.com</domain>
 
      <displayName>Google Mail</displayName>
      <displayShortName>GMail</displayShortName>
 
      <incomingServer type="pop3">
        <hostname>pop.googlemail.com</hostname>
        <port>995</port>
        <socketType>TLS</socketType>
          <!-- unexcrypted, SSL, TLS
                "if available" options considered harmful -->
        <username>%EMAILFIRSTPART%</username>
        <authentication>DIGEST-MD5</authentication>
            <!-- anonymous,
                plain,
                login,
                CRAM-MD5,
                DIGEST-MD5,
                KerberosV4,
                GSSAPI (Kerberos v5),
            -->
        <displayName>Google Mail</displayName> <!-- needed? -->
        <pop3>
            <leaveMessagesOnServer>true</leaveMessagesOnServer>
            <deleteMailLeftOnServer>false</deleteMailLeftOnServer>
            <authentication>plain</authentication> <!-- todo list -->
        </pop3>
        <!-- remove the following and leave to client/user? -->
        <loginAtStartUp>true</loginAtStartUp>
        <downloadDuringNewMailCheck>true</downloadDuringNewMailCheck>
        <rememberPassword>true</rememberPassword>
      </incomingServer>
 
      <outgoingServer type="smtp">
        <hostname>smtp.googlemail.com</hostname>
        <port>587</port>
        <socketType>TLS</socketType> <!-- see above -->
        <username>%EMAILFIRSTPART%</username> <!-- if smtp-auth -->
        <authentication>smtp-auth</authentication>
            <!-- none (server grants access based on IP address),
                smtp-auth (RFC 2554, 4954),
                smtp-after-pop (authenticate to incoming mail server first
                before contacting the smtp server)-->
        <displayName>Google Mail</displayName> <!-- needed? -->
        <addThisServer>true</addThisServer>
        <useGlobalPreferredServer>true</useGlobalPreferredServer>
      </outgoingServer>
 
      <identity>
        <!-- needed? -->
        <!-- We don't want Verizon setting "Organization: Verizon"
              for its customers -->
      </identity>
 
      <!-- Will not be used with this proposal: -->
      <sampleEmail>example@googlemail.com</sampleEmail>
      <sampleUserName>example</sampleUserName>
      <usernameDescription>Google Mail Username</usernameDescription>
 
    <emailProvider>
 
    <clientConfigUpdate url="https://www.googlemail.com/config/mozilla.xml" />
</clientConfig>
</pre>
 
Placeholders:
* %EMAILADDRESS% (full email address of the user, usually entered by the user)
* %EMAILFIRSTPART% (email address, part before @)
* %EMAILDOMAIN% (email address, part after @)
* %REALNAME% (needed?)
 
TODO:
* IMAP
* All settings and enum values
 
 
= Security =
 
If you are OK with POP3 and plain authentication over the Internet, the following is of no interest to you. :-)
 
== ISP config lookup ==
 
To avoid password stealing (DNS attacks are easy), we should verify the authenticity of the configuration file, that it's from the company which owns the email domain. This could be done by downloading the config file via https, but that's only useful when we actually check the domain name (subject) in the certificate against the email address domain that the user entered. That would be as secure as HTTPS on the web, but runs in a problem for email providers with vanity domains like coolpeople.com, they won't buy a cert for each domain.
 
== Mozilla config lookup ==
 
If the configuration files on the Mozilla service can be contributed in a wiki-like way by anonymous people, the password theifs could just submit a config file for a big ISP and wait for the passwords to come in. The server should check that the domain of the IMAP/SMTP servers matches the domain of the email address that the config applies to, e.g. config file for aol.com must have something.aol.com as IMAP/SMTP server. That will work for many, but not for those which have several domains goign to the same server (e.g. gmail.com = googlemail.com), so probably there either need to be some automated tests (e.g. checking that both domains are served by the same DNS server and return the same MX entries) or failing that a trusted human moderator.
 
== DNS based discovery of configuration/setup files for mail clients ==
 
=== 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 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” 1997.).
 
=== 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 would 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 compliant).
 
2.) A '''TXT''' record with the content "''mailconf=https://''" is fetched from the DNS zone based on the highest priority '''MX''' record found. If no matching '''TXT''' record is found the next lower '''MX''' record shall be fetched. At last the '''A''' record of the domain is checked for a '''TXT''' record.
 
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.
 
5.) The first valid '''TXT''' record shall be used in order to fetch the configuration file. In case the SSL secured server can not be chained to a trusted root, has a domain name mismatch or other failures, connection shall 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''". This allows serving of dynamically generated configuration files.
 
7.) The configuration file is downloaded and checked for sanity and parsed. At this stage the user is present 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.
 
 
=== Examples ===
 
None yet.
 
=== Disclaimer ===


This standard shall be licensed according to a Mozilla compatible licenses and is copyright (c) 2008 of Eddy Nigg. 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. Please advice on this.
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 =
= Related Information =


The newsgroup discussion is at news://news.mozilla.org:119/mozilla.dev.apps.thunderbird (Subject: '''Proposal: Auto-configuration''', Date: 2008-03-04)
* The newsgroup discussion is at news://news.mozilla.org:119/mozilla.dev.apps.thunderbird (Subject: '''Proposal: Auto-configuration''', Date: 2008-03-04)
* [  ] [  ] [https://hg.mozilla.org/users/dascher_mozilla.com/autoconfig/ hg branch]
* [http://groups.google.com/group/ispdb Google discussion group about ISPDB]
* The old/current RDF file format is documented at [http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks Thunderbird ISP hooks]
* mscott made a [[Thunderbird:Easy_Account_Setup|similar proposal]] one year ago
* An [http://tools.ietf.org/html/draft-daboo-srv-email-02 Internet Draft] about SRV records for locating email services.


There's related information on "Thunderbird ISP hooks" at http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks.
[[Category:Thunderbird|*]]

Latest revision as of 10:27, 8 June 2021

<< 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

Retrieved from "https://wiki.allizom.org/index.php?title=Thunderbird:Autoconfiguration&oldid=1235989"