= Template =
== Overview ==
''Describe the goals and objectives of the feature here.''
;Background linksWe're currently implementing "autoconfig" for Thunderbird, which is intended to be able to automatically figure out the mail settings needed to configure an email account, like hostnames, ports, SSL on/off, secure auth algo etc.. All that the user should need to provide is his real name, email address and password. We take the domain of the email address and try to find the configuration from that.* feature-tracking bug links* specs or design docsIdeal way is that the ISP publishes the configuration. This is the security review of the protocol for this specific part (fetch configuration from ISP). For a general description of the flow, see [[Thunderbird:Autoconfiguration]]. The original discussion of the idea and protocol has been on the [http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/e8bdb0af31961908/a73bd97251b18777?q=#a73bd97251b18777 newsgroup in March 2008]. The linked, first post also contains a description. A security review has already been initiated on the [http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/e85fd8d5db0a4a6d/2b36ce3fbb7c2142?q=#2b36ce3fbb7c2142newsgroup in Jan 2009].
== Security and Privacy ==
* Is this feature a security feature? If it is, what security issues is it intended to resolve?See below* What potential security issues in your feature have you already considered and addressed?* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?* Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.* How are transitions in/out of Private Browsing mode handled?== Exported APIs ==
# [ Try to contact https://<i>emailaddressdomain</i>/mail/mozilla.xml?emailaddress== Exported APIs ==<i>emailaddress</i> ]* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc# Try to contact https://autoconfig.)* Does it interoperate with a web service? How will it do so<i>emailaddressdomain</i>/mail/mozilla.xml?emailaddress=<i>emailaddress</i>* Explain # The URL is expected to return an XML file in the significant defined [[Thunderbird:Autoconfiguration:ConfigFileFormat|Config file formats, names, syntax, and semanticsformat]] with mimetype "text/xml" or "application/xml".* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?* Does it change any existing interfaces?
== Module interactions ==
* What other modules are used (REQUIRES in the makefile, interfaces)?XmlHttpRequest* E4X
== Data ==
* What data is read or parsed by this feature?Input: [[Thunderbird:Autoconfiguration:ConfigFileFormat|Config file]]* What is the output of this feature?* What storage formats are used?Output: AccountConfig data structure
== Reliability ==
* What failure modes Error UI: If the file cannot be found, or decision points are presented it's invalid, we ignore the error and go to the user?other autoconfig possibilities (database, probing etc.).* Can its files be corrupted by failures? Does User confirmation: If we find a config, we present it to the user, so that he can glimpse over it clean up any locks/files after crashes?before hitting "Create account".
== Configuration ==
* Can The URL is constructed from the email address the end user configure settingsentered. The other parts are fixed, via a UI or about:config? Hidden prefs? Environment variables?as defined above.* Are there build options for developers? [#ifdefsThere's currently no pref to skip this step. The user can, ac_add_optionshowever, etc.]* What ranges for ignore the tunable are appropriate? How are they determined?* What are its on-going maintenance requirements config we detected and enter a configuration (epop server hostname, port etc.g) manually instead. Web links, perishable data files)?
== Relationships to other projects ==
Are there related projects None known. = Security considerations = * We hope that autoconfig in general will let more users use SSL and secure authentication.* The risk here is that we find and offer a configuration that contains mail servers operated by an attacker. E.g. Emily wants to set up emily@example.net, but we find a configuration for example.net that includes imap.evil.com. Then, evil.com would gain Emily's email password. Or imap.example.net offers SSL, but the attacker manages to return a config without SSL nor password encryption, and then using a MITM to read the community?cleartext password.* If soTo find the config, we chose https (including insisting on SSL and a proper certificate) over DNS, what is because it's more secure. = Mitigating factors = * We present the configuration we found to the user before we create the proposalaccount.* Most users today use no SSL and no "secure auth", because that's relationship too cumbersome to set up without knowing which combination works, and official instructions are usually imcomplete and outdated. So, people are already sending their work? Do you depend on others' workpassword in the clear, the attacker just has to sniff it. With this feature, if the attacker feeds a bad configuration and we use that (worse case scenario here), the attacker leaves fairly obvious traces and has a very high risk of being detected. Compared to passively sniffing, or vice-versa?this is a fairly high bar.* Are you updatingThe risk exists only in the moment when the user creates the account, copying not during daily normal login.* For comparison: Addons/Extensions or changing functional areas maintained by other groups? downloads of EXEs pose a far, far larger risk. = Review comments = == Philor == Philor:A webhoster which is allowing customers to register subdomains. So, a customers has fred@hoster.com and fred.hoster.com. How are you coordinating , if the attacker registers autoconfig.hoster.com, it can redirect Fred to imap.evil.com and communicating with them? Do they "approve" get the password. Ben Bucksch:I can see two possible counter-measures for that:1) The webhoster must block the autoconfig subdomain or register/use it himself.2) We also contact https://www.<domain>/autoconfig/mail/mozilla.xml /before/ we contact autoconfig.<domain>.Upside of what you propose?2) is that it's a bit easier to set up (no new host). Downside is that it creates more 404 spam in the hoster's logfile (same as /favicon.ico, which I hate).
== Review comments ==Microsoft has a very, very similar feature in Outlook / Exchange 2007, which also contacts "https://<domain>/autodiscover/autodiscover.xml" and "https://autodiscover.<domain>/autodiscover/autoodiscover.xml", so they do exactly the same (same idea independently), and they used 2) above. (There are some differences in the XML files, so dropping our own format in favor of Microsoft's is not a good idea, but I plan to implement the autodiscover as well, in case we talk to Exchange 2007 servers).
