Alumni Association Network Services

1. Overview

This document is to summarize some of the email exchange that has occured between Computing Services and Alumni Relations. I hope it will facilitate the upcoming meeting between our groups.

I have noticed that currently http://www.cmu.edu/alumni implements a set of these services but I have included them in this discussion as the process of automating Email Forwarding for Life requires some support infrastructure which can be extended to other services.

However, if Alumni Relations is willing to designate an individually to be responsible for obtaining, maintaining, and updating the information as necessary, then much of this infrastructure is not required.

2. Services

The services to be provided include the following items.

• Email Forwarding - This has also referred to Email For Life. This service will provide an email address associated with CMU, such as jsmith@alumni.cmu.edu. This address; however, is just an alias and would forward any incoming mail to a specified address. The user would not be using CMU resources to actually read or store email.

• Directory Services - This will enable an alum to be able to find information about other alumni either by searching or by browsing.

• Email Mailing Lists - This will permit individuals to communicate with a specified grouping of alumni in an easy fashion.

• Web Content - This will allow Alumni Relations to provide content on the web. In particular, the assumption is that there will be publically available content as well as pages that should be restricted to alumni only.

• Chat Rooms - This will provide a mechanism for alumni to communicate in a more interactive "real-time" manner.

Implementation notes:
It would be useful to understand the priority of these items and know if there are other services not enumerated that need to be considered.

3. Issues

• Authentication - A user must be identifiable as a valid user when they come in over the network. This means we need to deal with validation of the user and then the creation of a userid and password (or equivalent).
  Validation is the really tricky part. Assuming that it is not acceptable to require the alum in question to show up in person, how do we prove the users are who they claim to be?

• Data Maintenance - The data on the machine needs to be kept up to date with external sources. It may be desirable for the user to update his information and that update propagate back to the central databases.
  Invalid data may be automatically updated. For example, if the destination email forwarding address is unavailable for a specified length of time, the forwarding ceases and the directory information is updated.

• Death - Upon notification of death, services should be terminated in a reasonable manner (both technically and politically).

• Policies - Acceptable use policies need to be set. For example, acceptable use of the data provided; behavior in the chat rooms or mailing lists; use of the email identity; etc. Similarly, a privacy statement to the user is probably desirable.

• Systems Maintenance - Operating system, web, email, and other software needs to be kept up to date to ensure proper functionality and a stable service. Monitoring also needs to be done to detect problems as they arise.

• User Maintenance - There may be the occasional need for users to interact with staff at CMU. Specific examples may include forgotten passwords, assistance using the services, etc.

4. Possible Implementation

4.1. Initial User Contact

1. A paper mail mailing can be made to the known addresses of alum with the entry code.
2. During Homecoming/Carnival, alum can visit a staffed location, present ID and receive the entry code.
3. Alum can send a notarized letter to the alumni office asserting that the address or email provided is valid and an entry code will be sent.

This may also be an opportunity to receive updates regarding people who normally would not update this information.

Implementation notes:
The third item is bordering on the paranoid side of things. However, what is the risk of allowing someone to impersonate another alum?

I suspect the entry code will be something of the form of numbers and digits. Ideally short enough to be easy to remember/communicate but long enough to be unique. This also depends on whether or not the entry code is meant to be temporary or reusable.

There was a mention that the last 4 digits of a SSN can be used. We actually keep the SSN of alum?

We should be able to import the existing user base from the current Alumni Association Online Directory.

We can also facilitate graduating students registering for this before they leave campus. If this is desirable, then when can a student actually register? After paying tuition for the first semester?

4.2. User Creation

This screen can allow the user to:

• Create their own userid where the name is on a first-come, first-serve basis.
• Provide an email forwarding address.
• Update their personal/contact information.
• Join any mailing lists or request not to be included in any.
• Specify what information is to be made available to other alumni and what is not. For example, in the directory listing, does only their Name and graduation info show or are they will to list their address and/or phone number.

Implementation notes:
I presume we can import the current users without too much difficulty.

Depending on the sensitivity of the data served, email can be sent to the forwarding address with a reminder of the userid and password to access this system.

Once a user chooses a userid@alumni.cmu.edu, it would be best if the user could not change it. If a user can change this ID, that means we either allow the system to become inconsistent (foo@alumni.cmu.edu used to go to John Foo) or we deny John Foo access to foo@alumni.cmu.edu even though it doesn't go anywhere because Bob Foo had it at one time.

A similar question is how long after death do we preserve the ID? A year? Two? Forever?

The data available to be entered and/or viewed by others needs be determined. Possible data items are: name; email address; (physical) mail address; phone number(s); current occupation; major; and graduation year.

Similarly, what about data from alum who have not registered with the system? What data is available by default?

4.3. User Access

1. Enter and participate in the chat room.
2. Modify his personal information.
3. Modify his email forwarding.
4. Search/browse other alumni for email/mail addresses, etc.
5. Search/browse the mailing lists.

Implementation notes:
I have not investigated chat room software at all. Something web based is better than something like IRC as if it doesn't go through the web, more work is required to do the authentication.

It is probably best to keep the directory services aspect simple for now by having the data as just HTML pages rather than necessarily throwing in a database back-end. The primary reason is that this makes implementation quicker. The secondary reason is that our future plans with LDAP (see section 6.1) may address this issue then.

4.4. System Overhead

There are other matters with regards to logging and regular log file analysis and reporting. This information is used to diagnose problems as well as to track usage for capacity planning. Details can be provided at a later time.

5. Responsibilities

Alumni relations will provide and maintain the actual data, such as core data to seed and maintain the database (names, addresses, etc.). Also, Alumni Relations will be the contact for all user interaction. For example, contact phone numbers or email addresses will go to Alumni Relations.

The responsibility for the installation of other software (chat room) and the development of the infrastructure to fully enable this system still needs to be decided. However, the installation needs to follow the existing infrastructure to ensure system maintenance can occur so Computing Services will offer (at least) supervisory support.

6. Future Plans

6.1. LDAP

After this service is deployed, we may be able to provide a similar service for Alumni Relations using the existing server.

6.2. Personal Certificates