[../../../commonpages/header.htm]

 

Account AutoDiscovery

Use an e-mail address to lookup ISP Settings to automatically configure software

 

Goal:

When the user starts using a new computer with Neptune, one of their first goals will be to turn it on and access their e-mail with a minimal amount of time and effort.  One of the biggest hurtles for users setting up a computer to their e-mail accounts is knowing all the configuration settings.  This currently requires a 5 page wizard asking for 6 pieces of information.  This should be reduced to a 1 page wizard asking for email address & password.  My grandmother shouldn't need to know the names of her mail servers or the protocol used to connect to them.

 

A lot of potential customers exist that don't use computers because they are too hard or require training.  We need to make accessing information easier for they will agree to use computers.  For example, if someone told you that they read an article in the alt.foo.bar newsgroup and that it would be important to you.  Often users will think, If I could get my computer to that article in 5 minutes or less I would be willing to read it, otherwise I'm just too busy.  Let's say you as the typical Microsoft employee where in this situations.  Could you install the software, configure the NNTP server, port numbers, authentication type, and get to the newsgroup in less than 5 minutes?  (What is Microsoft's NNTP server?  Could you find out in 5 minutes?)  If you would have a hard time, our users will never spend time hassling with this.  This protocol would solve this problem by using the user's email address to automatically(tm) lookup these kinds of settings needed to configure their software.

 

The first application of this protocol will be to reduce the 5 page e-mail account configuration wizard to 1 page.  Future applications can be used be used to configure buddy lists, chat, conferencing, newsgroups (NNTP), and other services.

 

Current User Interface:

Today's out of box experience with Win98 requires 10 steps in the user's adventure to read email for the first time.

Current Screens: 

Step 1. New user gives their login name to login

Step 2. User Double Clicks “Outlook Express” to go read e-mail.

Step 3. User enters display name.

Step 4. User enters e-mail address.

 

Step 5. User enters Server Type

Step 6. User enters server names

Step 7. User Enters e-mail address and password

Step 8. User specifies password authentication type. 

Step 9. User clicks Finish.

Step 10. User gets to inbox.  Success!!

 

A service should be able to automatically configure 5 pieces of information:

  • Display Name (Step 3)
  • Server Type  (Step 4. IMAP, POP/SMTP, DAVMail)
  • Server Names (Step 5. pop.mail.yahoo.com, smtp.mail.yahoo.com)
  • Server Port Numbers (UI is burried)
  • Authentication Type (Step 7)

 

It should be able to reduce this to 2 pieces of information, the e-mail address and password.  User's understand that they are "joe4@aol.com" on the internet so if we align login names with that, we can reduce the number of names and passwords users need to know.

New Screens:

Step 1. New user gives e-mail address

Step 2. User Clicks Read E-mail in the Start Page.

Step 3. User enters password for e-mail access.

Step 4. User’s Inbox, Success!!

 

How AutoDiscovery Works:

Account AutoDiscovery will use an email address to look up information needed to configure software.  Given a email name (like JohnDoe@psyco.psychdept.libarts.ucsd.edu), a list of possible AutoDiscover servers are generated.  The name autodiscover.<domainname> is contacted to provide the information.  If that information isn't found, the level of domains is reduced until one is found or the second level domain is tried.  If the information still isn't retrieved, then a public service is tried.  For this example these servers are tried:

  •  autodiscovery.psyco.psychdept.libarts.ucsd.edu,
  • autodiscovery.psychdept.libarts.ucsd.edu,
  • autodiscovery.libarts.ucsd.edu,
  • autodiscovery.ucsd.edu, and
  • autodiscovery.microsoft.com the public service.

 

Each server is sent an HTTP Post command.  The post data is an XML request for a certain type of information.  Email account configuration will be the first use.  The XML will contain information that will help execute the request.  For mail, it will include the email address, the protocols the client software supports, the web browser installed, the kind of proxy in use, and the types of authentication that can be used.

 

The server can then return an XML file that will provide the information needed for the client to configure local software to get the user to their destination.

 

In the case of email, we can first try to configure the email client software to connect to the mail server for fast access and offline support.  However if this is not possible because we don't support the protocol (MAPI, IMAP, for example) or the proxy blocks access (POP blocked by Web Proxy), then we can fall back to web based email for services that provide it. 

 

IE5 automatically configures the proxy based on a similar system.  However, since it is DNS & DHCP based, it isn't applicable for our use.  (See The IETF WPAD proposal Web Proxy Autodiscovery Protocol) 

 

 

How Is the Request Made:

The HTTP POST headers contain information about the request in XML.  Multiple REQUEST tags can be used to request information about different types of accounts (Mail vs Buddy List, etc.)

 

The request XML format is: 

<?xml version="1.0" ?>
<AUTODISCOVERY>
    <REQUEST
        ACCOUNTTYPE="EMail" <!--The kind of information requested-->
        VER="0.1" <!--The version of the request-->
        RESPONSEVER="0.1" <!--The version of the response the client supports-->
        LANG="en" <!--The user's language-->

        <!--The Following is ACCOUNTTYPE="Email" specific-->
        EMAIL="bryanst@yahoo.com" <!--The version of the request-->
        />
</AUTODISCOVERY>

 

How Is the Response Is:

The response XML format is: 

<?xml version="1.0" ?>
<AUTODISCOVERY>
    <USER
        DISPLAYNAME="Bryan T. Starbuck" <!--The user's display Name-->
        LDAP="<LDAP URL>" <!--FUTURE: We could provide an URL to an LDAP server for more information-->
        <VCARD/> <!--FUTURE: vCard information-->
    />
    <ACCOUNT
        RESPONSEVER="0.1" <!--Version of the response the server uses.  MUST be less than REQUEST's RESPONSEVER.-->
        LANG="en" <!--The response language-->
        EXPIRE="<days>" <!--Now many days should the cached version be used before returning to the server?-->
        
        <!--Either-->
            <!--Redirect to another server-->
        REDIRECT="<url>"
            <!--or Display this message to the user because the information could not be retrieved-->
        MESSAGE="the message"

        <!--or return the account information-->
        TYPE="Email" <!--The response is for this type of account -->

        <!--The Following is ACCOUNTTYPE="Email" specific-->
        EMAIL="bryanst@yahoo.com" <!--The version of the request-->
        AUTHTYPE="none" <!--none means no special password authentication-->
                        <!--SPA means no Secure Password Authentication-->
    >
        <!--Protocols are listed in order of server preference.  Attributes
            should be used to indicate if one protocol supports a feature
            another doesn't.-->
        <PROTOCOL
            TYPE="POP3" <!--Type of Protocol, like: POP3, SMTP, IMAP, HTTP (DAV), or MAPI (Microsoft Exchange).-->
            SERVERNAME="mail.pop.yahoo.com" <!--ID Addr or DNS name of server-->
            PORT="Default" <!--"Default" or the port number.  Default means the default for that protocol-->
        >
            <AUTH>
                <PASSWORD TYPE="none"> <!--"none" means the password is sent plaintext.-->
                                   <!--"SPA" means the password is sent using SPA-Secure Password Authentication-->
                </PASSWORD>
            </AUTH>
            <!--Organizations can add information about their proprietary account or protocol. or
                 not information not yet in this specification.-->
            <CUSTOM ORGANIZATION="microsoft.com">
            </CUSTOM>
        </PROTOCOL>
    </ACCOUNT>
    <!--More RESPONSE tags for each ACCOUNTTYPE in the reply.-->
</AUTODISCOVERY>

 

AutoDiscover.Microsoft.Com:


Why should Microsoft provide this server?  This part is optional but it would provide a great out of box experience when Neptune ships.  The idea of an AutoDiscovery Service is that I bet 80% of users use only 20% of the ISPs for service (@aol.com, @hotmail,com, @yahoo.com, @msn.com, etc.).  So some service could very easily just enter 50-200 ISP setting information for the most common ISPs.  For example, pretty much everyone with an @yahoo.com email address always uses the POP3/SMTP protocol and their server names are pop.mail.yahoo.com & smtp.mail.yahoo.com.  If it's an employee that uses a different server, then yahoo can provide their own AutoDiscovery server or the mail client software can recover when we fail to log into the POP server.

 

When people use the service, we can determine which ISPs are most commonly used.  We can then find out their connection settings by going to their web page or emailing the company.

The AutoDiscovery business model will be either to eat the cost, use ads, or provide it for a while.  If we provide it for a while, we can use the carrot and stick approach to get ISPs to take over supporting it.  Smaller ISPs will be pressured into setting up a server because this works for their competitors.  After we provide this for existing ISPs, we can tell new ISPs that they need to provide the service themselves.  Or they can pay us money to do that (although that's probably not a business we want to get into).

 

Setting Up A Server:

The trick is to make it trivial to setup a server. Most ISPs only need to do this:

  • Create a DNS entry that points AutoDiscover.<domainname> to an existing web server.
  • Create a "AutoDiscover" subdirectory.
  • Create the XML file that will be returned as the default file for that directory.  Web servers normally just return .asp, .htm, or .html files so either the server can be setup to return a static XML file or .asp page can do a server side redirect to the XML file.


This only works if the exact same information can be returned for all users.  If the admin has a couple of servers, they can use server side scripts (ASP or CGI) to redirect to one of a couple of XML files.  Or a database can be used to customize the contents of the XML to return.

 

Prototype:

I currently have several implementations running:

ISP Type Server:

The implementation is on http://bryanst2-email/AutoDiscover/isp.asp.  You can test this by going to http://bryanst2-email/AutoDiscover/test.htm and selecting "ISP type ASP Script".

 

AutoDiscovery.Microsoft.com Server:

The implementation is on http://bryanst2-email/AutoDiscover/default.asp.  You can test this by going to http://bryanst2-email/AutoDiscover/test.htm.  This SQL server can be administered by using the weblication on http://bryanst2-email/SQL/AutoDiscovery/.


UI Prototype:

The UI prototype is on \\bryanst2-email\wwwroot\AutoDiscover\test.hta. It requires a very new build of Neptune (winmail.dll) because it will use the checked in client code. 


 

Future Uses:

I'm currently going to use this for mail (IMAP, POP3/SMTP, & DAV) but it can be used for NNTP, NTP/SNTP, chat/buddylists, among other things. The general structure of the XML response is in three logical levels.  The type of service (<ACCOUNT>) on the first level. The second is the protocol. This way several protocols can be advertised so the client can choose the best. The third level are extensions so companies can add info that isn't yet in the public spec. This way Microsoft can add a whole section for MAPI or Lotus Notes on their special configuration info.

In the future, this could be a way for people to advertise information to the world. For example, there may be a way for a user to upload their vCard, email public key, LDAP server, or home page URL to this service.  Then all users could use this as a way to map e-mail addresses to that kind of information.  The LDAP server could be used for new types on information instead of expanding this protocol.  Finger provides a very informal version of this type of service today, however the caller is required to know the finger server name.

 

Test E-mail Accounts:

Existing:
  • AOL: User="NepTeam", Password="redshark".  Access Types: web, aol protocol.
  • HotMail: User="NepTeam", Password="redshark".  Access Types: web, DAV.
  • Go.com: User="NepTeam", Password="redshark".  Access Types: web.
  • HotPop: User="NepTeam", Password="redshark".  Access Types: web, POP3.
  • Yahoo: User="NepTeam", Password="redshark".  Access Types: web, POP3.
  • User="NepTeam@computermail.net", Password="redshark".  Access Types: web, POP3.
  • User="NepTeam@usa.net", Password="redshark".  Access Types: web, POP3
  • User="NepTeam@anglefire.net", Password="redshark".  Access Types: web, POP3
  • GeoMail: User="NepTeam@dirtybird.net", Password="KOR2900".  Access Types: web, POP3
  • Email.com: User="NepTeam@email.com", Password="redshark".

Need to Create:

  • MSN: User="NepTeam", Password="redshark".  Access Types: web, aol protocol.  NEED to create
  • NWLink: User="NepTeam", Password="redshark".  Access Types: web, aol protocol.  NEED to create
  • JUNO: 
  •  

 

 

Related Information:

 

last updated on 04/11/00 by BryanSt