Thunderbird/AccountProvisioner

From MozillaWiki
< Thunderbird
Revision as of 16:02, 31 May 2012 by Bwinton (talk | contribs) (Created page with "<p>Account Provisioner API (such as it is). </p><p>A few of the email providers we’ve been in contact with have told us that they would prefer to host the registration pages t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Account Provisioner API (such as it is).

A few of the email providers we’ve been in contact with have told us

that they would prefer to host the registration pages themselves, to give them more flexibility to deal with changing requirements and security concerns.

Before the flow happens, we need the following information:

  • An API for the Suggestion Engine, including the format you return
 suggestions in.
 * We will provide the IPs we'll call the Suggestion API from.
 * We will pass in the first and last name the user entered, as well as
    their 2-letter ISO 3166-1 country code.
  • A url to registration start point with query parameters for the first
 name, last name, and requested email address.

We propose to implement the following flow:

1) Thunderbird contacts a Mozilla Messaging server to get configuration

  information for each supported provider, including a template for
  that provider's registration url.

2) Thunderbird gets the user's first and last name, and sends them to a

  Mozilla Messaging server, which then contacts each provider to get a
  list of suggested (and hopefully-available) email addresses,
  collates the suggestions, and passes them back to Thunderbird, which
  displays them to the user.
  * Mozilla Messaging will handle any required rate-limiting on this
    call to ensure that Thunderbird is not used as an abuse vehicle on
    provider's suggestion engines.  In particular we'll rate-limit the
    number of suggestions to N queries per M minutes per IP address.
    The rate of queries from the Mozilla server to the provider will
    be much higher, as we'll aggregate all of the rate limited queries
    from our users, but those will come from a restricted, well-known
    set of IP addresses over HTTPS.

3) The user picks one of the email addresses.

4) Thunderbird creates a sub-browser, and loads the per-provider

  registration url it got in step 1, passing in the first name, last
  name, and email address.  (This url will come from the Mozilla
  Messaging server, with placeholders for the data.  i.e.

https://provider.com/tbReg?first={firstname}&last={lastname}&email={email}

  .)
  * That browser will be in a Thunderbird tab, and so general browser
    layout can be assumed.

5) The provider will display a page or set of pages, culminating in a

  page with a content-type of text/xml.
  * On the successful creation of an account, that XML will contain the
    information Thunderbird needs to create the account, in the
    Autoconfig format.  For example:
    <clientConfig version="1.1">
      <emailProvider id="provider.com">
        <domain>provider.com</domain>
        <displayName>Email Provider</displayName>
        <displayShortName>Provider</displayShortName>
        <incomingServer type="imap">
          <hostname>imap.provider.com</hostname>
          <port>993</port>
          <socketType>SSL</socketType>
          <authentication>password-cleartext</authentication>
          <username>username@provider.com</username>
          <password>the password the user chose</password>
        </incomingServer>
        <outgoingServer type="smtp">
          <hostname>smtp.provider.com</hostname>
          <port>465</port>
          <socketType>SSL</socketType>
          <authentication>password-cleartext</authentication>
          <username>username</username>
          <password>the password the user chose</password>
        </outgoingServer>
      </emailProvider>
    </clientConfig>
  * If the user chooses to cancel the registration, return XML with the
    following set of tags:
    <clientConfig version="1.1">
      <emailProvider id="provider.com"/>
      <error code="USER_CANCEL">Error message goes here.</error>
    </clientConfig>
     The following codes will be recognized:
      USER_BACK: The user wants to retry the suggestion process.
      USER_CANCEL: The user does not want to set up an account.
      ERROR: There was an error processing the registration.
  * The provider's pages are responsible for handling errors (input,
    rate limit, or otherwise) and displaying recovery options to the
    user.