Thunderbird/AccountProvisioner
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.