82
edits
Thunderbird:Autoconfiguration: Difference between revisions
Jump to navigation
Jump to search
→Security
PeterLairo (talk | contribs) |
|||
| Line 192: | Line 192: | ||
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. | 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 == | |||
Configuration files for all mail servers would be fetched according to the following standard, providing a unified approach and UI, based on mostly existing discovery and transport layers: | |||
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.) 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. | |||
7.) 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. | |||
8.) The user confirms his preferences (if any) and confirms the setup of the account. | |||
9.) TB tries to use the new settings and prompt for passwords etc. as usual. | |||
= Related Information = | = Related Information = | ||