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.
We will be working with the following assumptions:
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
Computing Services will:
Date | Description |
---|---|
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. |
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 |
This section to be finished by 07/19/99.
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.
Server Hardware: Sun Sparcstation 20 Model 60; 256MB memory Web server software:   Apache Operating system: Solaris 2.6 Mailing list software:   Majordomo
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.
07/01/99 -  | Initial draft |