Table of Contents 
Previous Chapter The Andrew II Project:
Electronic Mail
John G. Myers
Computing Services
This document describes the functional requirements of the Andrew II Electronic Mail project. The purpose of the project is to provide an electronic mail system for users of the Andrew system and any other organizational computing facility at Carnegie Mellon that wishes to use it.
Our experience with the Andrew Mail System (AMS) has shown a number of problems with its design, leading to problems with performance and difficulty in administration. This project will attempt to implement a replacement mail system which corrects many of these problems.
The Andrew Mail System has many useful features not found in other mail systems. Some of these features are important to the user community, others are of dubious value. Determining which features of the Andrew Mail System are important and reimplementing them in the new mail system is an important part of this project.
The remainder of this document contains three sections, requirements for functions to be provided to users, requirements for functions to be provided to administrators, and design constraints.
Features described in the Specific Requirements fall into three different categories --- Mandatory, Highly Desirable, and Desirable.
- Features that are mandatory must be included in the Mail System.
- Features that are highly desirable should be included in the Mail System.
- Features that are desirable may be included in the Mail System if they fall within our resource limitations.
It is mandatory that the mail system:
- have at least one user client for each of the X- based workstation, UNIX
terminal, Mac, and PC environments.
- provide a per- user phase-in mechanism to support beta-testing and a smooth transition from AMS/AMDS (Andrew Mail Delivery System). Users must be able to specify that they wish to use the new mail system instead of AMS. This transition need not be reversible. At some point, this transition may be forced upon users.
It is highly desirable that the mail system:
- have the same or similar user interface across platforms. Many of our users read their mail on multiple platforms. Consistency across environments eases training and transition. The clients should conform to the user-interface guidelines of their respective platforms as much as possible.
It is mandatory that the mail system:
- not drop mail, short of hardware failures. Once submitted, mail must either be delivered to the recipient(s) or, if that is not possible, returned back to the sender. Losing data for frivolous reasons (network outage, resource shortages, server unavailability) is unacceptable.
- provide authenticated delivery of local mail. This is a feature of AMDS that is expected by users. Not only does it protect against users being mislead by forged mail, it allows mail-based services like EzFax and restricted-posting bboards to work. If the mail system cannot be assured that mail claiming to be sent from a local user was in fact sent from that account, it must indicate it as such. The delivery system is allowed to lose this assurance under adverse conditions.
- be able to manage multiple mail folders. Many users depend on the ability to classify their messages into different folders.
- provide the option to store folders on local media.
- have some form of subscription/"master update" service. Subscription keeps track of which bboards the user wants to read. "Master update" service tells which of the user's subscribed folders have new messages.
- be able to search the messages within a folder for a specified subject and/ or sender.
- support local and remote printing of messages.
It is highly desirable that the mail system:
- provide integrated Mail and Bboards.
- perform well for mail-only users. Users who don't read bboards should not be affected by the performance needs of the bboard system.
- be able to maintain the read/unread state for each message in a folder. While AMS's "quit here" line is sufficient for recording what messages in a folder a user has read, keeping the read/unread state per message allows users to read the messages in a bboard in a non-linear order. For example, they could read all messages with a given subject before moving to messages with a different subject.
- support an automatic filing mechanism for user's mail.
- be able to search for entire fields in subject and sender searches rather than truncating the field to a fixed number of characters.
- be able to keep copies of all outgoing messages.
- be able to archive and/or compress old messages.
- eliminate duplicate delivery of mail by examining the message-id header.
- provide an email to fax gateway.
- provide gateways to commercial mail systems run by small departments.
It is desirable that the mail system:
- be able to do searches other than by subject or sender.
- eliminate the multiple presentation of messages that have been crossposted to multiple bboards by examining the message-id field.
- support threaded reading of mail folders. That is, automatically group messages in the same conversation together.
- support kill files that allow users to ignore messages on a bboard with a specified subject or sender.
- support subscription invitations, or messages that prompt the user to subscribe to a folder.
- support direct delivery of specified messages to folders other than the main mail folder. This is one mechanism for supporting private bboards.
- allow users to request a return receipt upon the successful delivery of mail they sent.
It is mandatory that the mail system:
- provide a directory service of users which supports "fuzzy matching" name lookups.
- allow users to set a forwarding address.
It is highly desirable that the mail system:
- make changes in a user's forwarding address immediately.
- provide a method to notify users that they have new mail. Zephyr is a likely notification method.
- provide a uniform notation for addressing messages to bboards. For example, being able to post to any bboard by addressing mail to "bb+nameofboard"
- provide mail aliases or address books for each user. The address book should be available regardless of the location or platform being used.
- support user-created and maintained distribution lists.
- support a user-defined portion of the address namespace (userid+whatever). This feature is invaluable to users who automatically file their incoming mail.
It is desirable that the mail system:
- support restricted-sending distribution lists.
- provide a "vacation" facility. This allows users who are unavailable for a period of time to inform people who send them mail of this fact.
It is mandatory that the mail system:
- be able to send and receive files as enclosures. Enclosures should use a common format across platforms and must be encoded using the MIME standard.
It is desirable that the mail system:
- provide full, generalized multimedia support. If supported, this must be done through the MIME standard.
It is mandatory that the mail system:
- be able to enforce disk space quotas. Administrators need to have control over resources and be able to avoid abuse of the mail system as additional storage.
- be able to distribute the bboards across servers. The client must therefore have some mechanism for finding the server(s) for a given bboard. Distribution of bboards is necessary in order to handle a large load.
- be able to distribute users across servers.
- be able to move users and bboard trees between servers in order to load-
balance.
- be able to purge bboards at administratively defined rates. Old messages have to be removed at some point. The rates at which bboards are purged need to be adjustable in order to allow for variations in resource usage and importance.
- monitor centrally maintained resources.
It is highly desirable that the mail system:
- provide usage and resource monitoring of other parts of the mail system. Administrators need to do resource planning, budget justification, detection and diagnosis of problems.
- be able to replicate bboards on multiple servers. This would be an aid to distributing load.
It is mandatory that the mail system:
- support global mail aliases and mailing lists.
- be able to efficiently handle large, frequently read bboards.
- support bboards with restricted reading. Organizations use bboards for internal discussions which they do not want to be available to outside users.
- have some form of BBoard filing mechanism. This is necessary in order to have bboards.
- allow the bboard filing mechanism to enforce restricted posting to bboards.
- have a mechanism to handle the administration of bboards (manipulate Access Control Lists, create, delete, etc.).
It is highly desirable that the mail system:
- be able to distribute parts of administration to outside groups. The bboard system needs to be maintained in some manner. If this maintenance can be distributed, the load on the central maintainers is reduced and outside groups have greater flexibility within their own part of the bboard system.
- be general enough to handle special setups, such as advisor. If the filing mechanism isn't general enough to handle such setups as advisor, special-purpose programs to handle this can be written.
- be able to "Short Circuit" local delivery of mail to both andrew.cmu.edu and to CMU.EDU. This is expected to increase the performance and reliability of the delivery system significantly. For example, both Andrew and CS know how to query the CMU.EDU database directly, so they can deliver mail directly to the user's forwarding address instead of forcing the mail to be processed by the central CMU.EDU servers
It is desirable that the mail system:
- allow an administrator to specify that mail sent to a given address is to be returned with an administratively-set error message. This is a feature of AMDS that is useful for dealing with suspended accounts.
It is mandatory that the mail system:
- use a client/server architecture. This architecture is necessary to support "mobile" users, those who access their mail from different places.
- avoid any reliance on a shared filesystem service. Experience with AMDS shows that layering on top of a shared filesystem leads to serious problems with performance and availability. We may allow users to configure their own environment to make part of their mail service rely on a shared file system.
- support Kerberos V4 whenever a component of the mail system needs authentication. Kerberos V4 is the authentication mechanism currently used by Andrew.
It is highly desirable that the mail system:
- use standardized protocols. If we need to design a new protocol, we should work to make it standardized.
Table of Contents 
Next Chapter