Alumni Email - Detailed Specification

1. Overview

This document provides the technical specification for the implementation of Alumni Email, aka Email Forwarding for Life (EFL). This expands and updates the Alumni Association Network Services document. This document will focus on the items necessary to implement and maintain the EFL service.

The goal of this system is to provide an permanent email address that alumni can use to direct mail to their actual email account. In this manner, if a user changes to a different Internet Service Provider, the user does not have to advertise a new email address. This service will NOT store mail for a user; only forward it.

To implement this service, we also build some infrastructure that can be used for other Alumni services in the future.

Desirable to implement items will be listed as MAY while mandatory to implement items will be listed as MUST.

2. Introduction

2.1. Terminology

EFL
is the acronym for Email for Life; the system described in this document.

user
refers to the alumnus using this system.

username
refers to the name selected by the user. The username is used primarily as the advertised email address for the user.
A username MUST not be re-assigned until that username has been inactive for a period of no less than 1 year.
A username MUST become inactive within a year of notification of the user's death. This limit may be extended. Death may not be the only case when a username may become inactive.

user identifier or UID
is an 9 digit number of the form: N-NNNN-NNNN. Each digit must be a value (inclusive) from 0 to 9. The first digit is a version identifier and is currently set to 1.
This value is assigned to a user and NEVER reassigned or changed. In the event that the same user receives more than one UIDs, only one UID is used by the system but the others MUST NOT be assigned to a different user.

2.2. Assumptions

We will be working with the following assumptions:

  1. There is a database of alumni information which will be used as the definitive source of information about the user. Thus, any updates the user may wish to submit which comes from this source will be sent to Alumni Relations to be updated in the master alumni database. This database will be referred to as the "alumni database." The information in this database will be referred to as "personal data."
  2. The alumni database must be able to export the data into a flat text file that can be transfered to the machine doing the processing.
  3. Information that is used only for this system (e.g. destination email address, UID, etc.) will be kept separate from the alumnus data and stored on this server. This database will be referred to as the "system database." This type of information will be referred to as "system data."
  4. The use of anything but the standard US alphabet for naming (i.e. A-Z and a-z) will not be permitted. For example, "René" would not be allowed. Instead, "Rene" would have to be used.
  5. There are valid (postal) mailing addresses for 92% of the current alumni. This enables us to do the initial loading of data by sending out a (postal) mailing. Those that are not in the alumni database will need to authenticate to Alumni Relations, who will then add them to the alumni database.
  6. The electronic mailing address (i.e. the username) is selected by the user will be allocated on a first-come, first serve basis. For example, the username jsmith may be valid for "John Smith", "James Smith", or "Jacob Smith". However, if "John Smith" registers that name first, James and Jacob must choose a different name.
  7. A user will be able to create their username only if they exist in the alumni database.
The data file exported by the alumni database can either be a complete dump of the database or just changes since the last information. Getting only changes from the alumni database would be more efficient but may require more work on the alumni database. Either way; however, can be handled by the system.

The frequency of update is an administrative decision. However, it is unlikely that it will be possible to be updated more than every 30 minutes without changing the system to have a direct connection to the database.

3. Major Components

3.1. UID Creation

When a new user record is encountered in the data dump from the alumni database, the system MUST generate a new, unique UID and associate it with that record.

The generation process MUST also output [the other fields necessary for a (postal) mailing]. This mailing provides the instruction and information necessary for the user to create his account.

3.2. System Data Updates

When a changed user record is encountered in the data dump from the master alumni database, the system MUST update the appropriate fields in the user's record. These fields are defined in Appendix A.2

NOTE: users desiring to change their own data is discussed in section 4.2.

3.3. Administrative Email Configuration

An earlier proposal was to invalidate a user's forwarding address if it ever became invalid. After further thought, this would not be a significant optimization. Thus, this work will be deferred until such a time that there is a clear benefit.

There are a common set of addresses that are expected to go to an real person. These addresses are: info, support, help, abuse, postmaster, and webmaster. These addresses on the system MUST forward to alumni-efl-support@andrew.cmu.edu. This address, in turn, MUST point to a bboard.

Common mail errors such as bounces from the mailing list or the forwarding service MUST go to alumni-efl-errors@andrew.cmu.edu. This also MUST go to a bboard.

The exact name of the bboards will be decided later.

3.4. Administrative Interface

There MUST be an administrative interface to allow Alumni Relations to easily modify the database. Authentication of Alumni Relation staff MAY be done via Kweb.

The administrative interface MUST permit the following operations:

4. User Interaction

4.1 Username Creation

  1. For existing alumni, the user will receive a physical mail mailing to his current address in the database. This mailing MUST include at least the user's full name, the UID, and the appropriate directions.
    Current students may receive notification via email of his UID or through some other mechanism. [NOTE: The exact nature will depend on when the student is allowed to create his username.]
  2. The user will go to a registration URL, which could be named http://alumni.web.cmu.edu/register. The registration URL MUST prompt the user for the following information: the user's name as it appears in the mailing, the user's UID, and the user's birth date.
    NOTE: The birthday is not a secure or reliable authenticator. In the event of an intercepted or misdelivered mailing, the recipient will have to go out of his way to determine this information and not be able to create a username with just the information in the mailing.
  3. The registration URL MUST provide a list to the user of at least 5 usernames. The user MUST select one of these usernames or choose NOT to create a username.

    Alumni Relations may allow the user submit a request to have a custom username. A special form can be written to verify that the user's choice is available. The question is, if given the option, will there be a large number of requests for custom ids?

    The exact algorithm by which usernames will be chosen for the list has not yet been determined. After getting the list of names from Alumni Relations, some analysis will be done to select the best algorithm. The algorithm (and resulting data) will be submitted for review on 07/26/99.

  4. The user MUST enter a password that will be used to grant access to update his data. This password MAY be used to permit alumni access to restricted areas of the web server. The user MUST be warned this password is not be considered secure and should not be the same as any other password he has as it will, most likely, be stored in plain text on the server.

After the username is created, the data desired and required from the user should be the same as if the user were returning to update his information, except that there may not be any previous data. As such, either during or after the username creation process, the user will be directed to the data management URL as described in section 4.2.

Once the creation process completes and an email forwarding address is provided, an introduction message MUST be sent to the address specified by the user. This message MUST contain:

4.2 Data Management

If this section is entered during the creation process, no password is required. If the user already has created a username and enters this section for the purpose of updating data, the user's password MUST be provided before any data can be changed.

The user MUST provide or be able to update the following information:

The system MAY attempt to verify the email forwarding address by checking to see if the destination host has a valid DNS entry. At this point, there is not a feasible way to verify if the user exists at the destination host so no attempt will be made to check that. If the address is found to be invalid, the user MUST be notified (and given an opportunity to assert that the address is indeed correct).

The user MAY also obtain the following information from the user:

If a user modifies data from the alumni database (Appendix A.2), those changes will be transferred to the server housing the alumni database. System Database (Appendix A.1) items MAY be updated immediately but MUST be updated within 24 hours.

4.3 Usage

Mail to username@alumni.cmu.edu MUST be forwarded to the specified email address.

Instructions MUST be provided to Alumni Relations on how perform the administrative tasks.

Instructions on how to use the authentication system to restrict data to only alumni MUST be provided.

Other services MAY be added such as a simple directory listing of users.

There MUST be a URL to handle forgotten passwords. Given the password is not considered secure, the password will be mailed to the current forwarding address.

5. Alumni Relations Ongoing Support

Alumni Relations will be the point of contact for the people using the system. Any issues raised directly with Computing Services will be redirected to Alumni Relations. A support email address and phone listing will be clearly stated with any associated reference to this service.

6. Computing Services Ongoing Support

Computing Services will:

7. Timeline

DateDescription
06/15/99 -  DONE: Operating system and web server loaded.
07/12/99 -  Alumni Relations: Data provided to Computing Services for analysis.
07/19/99 -  Finished administrative email configuration; mailing lists available.
Data definition completed. (Appendix A).
Acceptable Use policy selected. (Appendix B
07/26/99 -  Final draft of this document completed. Development of items described in this document begun.
Username selection algorithm available for review.
Alumni Relations: Document detailing the support plans for EFL submitted to Computing Services for review.
08/02/99 -  Finished data import and UID generation subsystems.
08/16/99 -  Finished registration and update subsystems.
08/18/99 -  First demo and documents delivered to Alumni Relations.
Support document completed.
08/30/99 -  Resolve any outstanding issues from the demo have been resolved.
09/20/99 -  Generation of data for the mailing to initial group complete.
09/27/99 -  Development and documentation completed. Initial limited deployment can start after this date.
12/06/99 -  Two month status report available.
These are actually two documents: one from Computing Services to Alumni Relations and one from Alumni Relations to Computing Services. These documents should confirm that the initial limited deployment is running smoothly and detail any changes that may be required before full deployment (including, but not limited to, additional hardware purchase)
12/20/99 -  Any changes as a result of the status report must be complete by this date.
01/24/99 -  Any changes from the December review finished.
Any new hardware (if necessary) MUST be ordered by this date to meet the deployment date.
02/21/00 -  Everything should be ok by this date. Last chance for changes.
03/06/00 -  Full deployment to begin.

8. Cost Projections

Hardware: $  2,000 Approximate market value for current hardware configuration
Staff: $ 18,000 $10000 for 2 months developer time; $4000 for management/design overhead; $4000 for initial deployment.
Total: $ 20,000

Appendix A: Data Definition

This section to be finished by 07/19/99.

A.1 Alumni Database


A.2 System Database

Appendix B: Acceptable Use Policy

This section to be finished by 07/19/99.

The purpose of the acceptable use policy is to help prevent:

In the event this behavior occurs the document MUST clearly outline disciplinary procedures such as a temporary or permanent removal of the forwarding address and any other service.

Appendix C: System Configuration

Server Hardware: Sun Sparcstation 20 Model 60; 256MB memory
Web server software:   Apache
Operating system: Solaris 2.6
Mailing list software:   Majordomo

Appendix D: Sizing Information

The currently allocated machine should be able to handle the following load per day:

Web:  500,000 requests
Mail:  50,000 messages

It is unlikely that EFL usage will exceed these values within the next two years. However, if usage does surpass these figures, additional hardware and network reconfiguration may be required and additional costs incurred.

Appendix E: Revision History

07/01/99 -  Initial draft

Last modified: Fri Jul 2 10:42:09 EDT 1999