Gaia/Email/Autoconfig

From MozillaWiki
< Gaia‎ | Email
Jump to: navigation, search

The Gaia e-mail app has an 'automatic' configuration mechanism which is the default, where the user just enters their display name (what they want their name to look like when sending e-mails), their e-mail address, and their password. This mechanism is derived from Thunderbird's autoconfig mechanism but with changes to support the ActiveSync protocol, slightly stricter security restrictions (encryption is always required!), a lack of domain guessing support (bug 823640), and no current support for trying multiple configurations from the XML configuration file.


Adding entries

Note: See https://wiki.mozilla.org/Thunderbird:Autoconfiguration for more details.

  • If you are a mail server operator or can convince the operator to do so:
    • The best thing is for the mail server operator to create and host an autoconfig entry.
  • If you are anyone else:
    • Create an XML configuration and file and bug in the Webtools product under the ISPDB Database Entries component. If you think there is sufficient justification to ship the file with the e-mail app, please note this in that bug. The interested parties working on the Gaia E-mail app follow that component as well. Note that this is currently only likely to happen for mail server operators with extremely large user-bases and for which vanity domains are not used.

Thunderbird's Implementation

Details can be found at:

Autoconfig Steps

There are a number of steps we perform:

  • /autoconfig/xampl.tld: Check for an XML configuration definition for the domain locally in the application at '/autoconfig/xampl.tld'.
    • Advantages:
      • Requires no network requests to be made, so:
        • The account will configure faster
        • There is no chance for attackers to interfere with the autoconfiguration process during any of the non-https-backed steps
    • Disadvantages:
      • The only way to update the configuration file is to update the e-mail app. If the account setup steps change, until the app is updated, manual setup may be the only way to create a working account.
      • Disk space. Although the app is packaged as a zip file so there are some compression benefits, supporting N domains using the same configuration requires N files. This potentially does not scale well. It is probably necessary to create a more space-efficient mechanism that is aware of such duplication.
  • https://autoconfig.xampl.tld/mail/config-v1.1.xml?emailaddress=user%40xampl.tld: Check for a XML configuration definition hosted by the server operator at a subdomain.
    • Advantages:
      • The server operator completely controls the settings for their domain. We don't need to ship a configuration with the phone or add it to the Thunderbird ISP database.
      • Because the e-mail address is included in the request, the operator can provide user-specific settings. This is most useful when the ISP maintains multiple mail clusters that require different settings to use. If the mail cluster are fronted by a proxy implementation, this does not matter.
      • https encrypted/authenticated connection
    • Disadvantages:
      • Requires the server operator's initial and continued involvement.
      • While the Thunderbird autoconfig mechanism has been adopted by some other open-source clients and has a non-trivial user-base, it's also not the world's largest user-base so not all operators do this.
  • https://xampl.tld/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=user%40xampl.tld: Check for a XML configuration definition hosted by the server operator at the root-domain using a well-known URI. All the advantages/disadvantages are the same as for the previous server-operator hosted mechanism, the domain is simply different.
  • https://xampl.tld/autodiscover/autodiscover.xml: Look for an ActiveSync AutoDiscover server hosted by the server operator. This is a secure authenticated POST request that includes the e-mail address in the POST payload; the credentials (e-mail address and password) are provided as part of the usual authentication header.
    • Advantages:
      • If the operator is using ActiveSync, especially via MS Exchange, there's a very good chance they already have an AutoDiscover infrastructure.
      • Secure requests.
    • Potential issues:
      • A server operator that supports both IMAP and ActiveSync and has an AutoDiscover server but no hosted XML configuration file will end up using ActiveSync instead of IMAP. IMAP is a better protocol, so this tends to be bad for the users. There can also be complications where ActiveSync is a pay service but IMAP is free, although as long as the status code 403 is returned, we do the right thing.
        • The implication from this as things are currently implemented is that if an operator provides both ActiveSync (with AutoDiscover) and IMAP then we want to host an XML config in the app to force use of IMAP.
  • https://autodiscover.xampl.tld/autodiscover/autodiscover.xml: ActiveSync AutoDiscover via sub-domain. Same advantages/disadvantages as the previous lookup.
  • https://live.mozillamessaging.com/autoconfig/v1.1/xampl.tld: Look for a XML configuration definition in the Mozilla-hosted Thunderbird ISP database.
    • Advantages:
      • Entries are shared with Thunderbird, many already exist.
      • No involvement by the server operator is required; any interested party can submit a configuration.
      • Entries can be changed/updated when the server configuration changes. (Note: the user will need to re-create their account for this to have any impact.)
      • A secure connection to the Mozilla-controlled server is used. (Note, however, that if an attacker has sufficient control over the device's network or the network path to the server-hosted configuration, including the ability to spoof HTTP or DNS requests, then this is not particularly helpful.)
    • Disadvantages:
      • The Mozilla hosted-server is a single-point-of-failure. The good news is that there is currently no dynamic code invovled in the server. All entries that are served are static entries checked into a subversion code repository that is periodically checked out, reducing the attack surface greatly.
  • https://live.mozillamessaging.com/dns/mx/xampl.tld: The Thunderbird ISP Databse server is used to perform a DNS MX lookup on the domain, which is used for the next steps in autoconfiguration.
    • Frequently, the mail server for a domain is hosted elsewhere or using a shared infrastructure at the ISP. For example, when gmail apps-for-domains is used, the MX entries will point to google domains. While DNS entries may exist on the vanity domain that refer to the mail server infrastructure, the mail server usually does not serve valid SSL certificates for all the domains it hosts, so secure access requires using non-vanity domains. The MX lookup helps us handle this. We are unable to do this on the device because gecko and our web API's do not support DNS MX lookups. See bug 342242 and related bugs.
    • Advantages:
      • Depending on the MX entry lets us support many vanity domains while only requiring one XML configuration file per domain. However, an XML configuration file is required. We do not repeat the ActiveSync AutoDiscover process.
    • Disadvantages:
      • The Mozilla server is also a single-point-of-failure. If the server is down, this step does not work for any users. If the server is compromised or its DNS lookups are compromised, this affects all users who make it to this step for the duration of the compromise. However, the server has been operational for many years with no compromises and no meaningful downtime.
  • /autoconfig/mx-xampl.tld: Look for a XML configuration definition for the domain returned by the DNS MX lookup (if it differs from the original domain) stored locally in the e-mail app. See the first local lookup for advantages/disadvantages.
  • https://live.mozillamessaging.com/autoconfig/v1.1/mx-xampl.tld: Look for a XML configuration definition Thunderbird ISP database entry for the domain returned by the DNS MX lookup. See the first ISP database lookup for advantages/disadvantages.

Things that could be done to enhance the implementation:

  • bug 342242: Perform DNS MX and DNS SRV lookups locally on the device.
  • bug 823640: Implement sub-domain guessing consistent with Thunderbird's sub-domain guessing. Given "xampl.tld", Thunderbird will try things like "mail.xampl.tld" and "imap.xampl.tld"/"smtp.xampl.tld". Because we don't currently do this, this means the Gaia e-mail app needs locally-hosted or Thunderbird ISP-database-hosted entries that Thunderbird does not need (and accordingly may not exist).
  • Ship the entire ISP database on the device (in a more compressed fashion).
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/Email/Autoconfig&oldid=1066344"