b) E-mail Servers

Monash seeks to engineer its e-mail service to provide prompt delivery and highly reliable storage of users' e-mail messages. The solution chosen needs to be scalable to handle a relentless increase in the numbers of users, the number of messages sent and stored, and the size/complexity of the messages. Support will need to be provided for workflow and directory applications.

The parts of the e-mail service that speak Internet protocols MUST adhere to the recommendations in the relevant Internet RFCs, for example RFC 1123 "Requirements for Internet Hosts -- Application and Support".

Monitoring and Management

There is a need to be able to easily monitor the throughput of and number of still-queued messages in the mail servers. Logs will need to be kept of all e-mail transactions -- receive, process, or deliver a message.

System Instrumentation

We need to be able to tell how much of various resources are being used by mail and hence determine when resource usage is reaching critical levels, and to predict future expansion requirements.

Diagnostic Tools

There needs to be some easy way of identifying stuck messages, determining why a particular message can't be processed and for correcting the problem or bouncing the message. We also need to be able to trace problems like who sent messages to whom, or "why didn't my message get through yesterday?".

Suppliers may choose to offer a solution based around one or a small number of large mail servers, or may choose to offer a larger number of servers some of which have specialised functions. The following descriptions are meant to specify the services to be provided rather than identifying separate boxes.

Mail Hubs

These machine(s) will be used to forward mail to and from servers that don't have direct Internet access, such as the current student NetWare servers. Mail hubs will also provide a "smart" host for client machines or dumb mail servers to upload their e-mail to.

Mail hubs will also be used to temporarily buffer messages destined for other machines that are down or overloaded, and forward the messages on when possible.

Mechanisms need to be available to sort messages according to various criteria such as sender, destination, size and any special processing required and apply different processing strategies such as priority, number of concurrent streams, retry intervals etc.

Some defence mechanisms need to be available to manage the resources used handling e-mail. Unusual events such as peaks in offered load shouldn't drive the system into overload thereby preventing unrelated e-mail from getting through.

Central Post Office

There is a need for some central post office functions. These include:

Standardised Addressing

It is essential to retain the current standardised form of Name-Based E-mail Addresses throughout Monash University, e.g. "Joe.Blow@arts.monash.edu.au" This scheme allows us to hide all the implementation details of people's mail host and usercode. It also allows for substring matching of people's names, and notification if partially specified addresses are ambiguous.

Mailing Lists

As well as messages sent to an individual, there can be messages sent to a group of users, boadcast messages sent to groups of users (possibly everyone), and messages made available for groups of users to look at (like bulletin boards). We wish to support all these modes of communication.

Most mailing lists management will be done through the Directory. The mail servers will have to scan the directory to determine the sender's rights to send to the list, the list membership, and then replicate the mail message (if appropriate).

There will also be some need for some mailing lists outside the directory such as mailing lists that contain non-Monash addresses.

There needs to be some mechanisms to monitor nondeliveries and unsubscribe invalid addresses, automatically if possible.

Message Conversions

The Post Office should also allow for correcting incomplete e-mail addresses provided by a user, and for fixing non-standard message bodies or attachment formats. There should be flexible and easy to use means for specifying such translations. Of course, any modifications made should produce strictly standards-conforming results.

Other message conversion functions are also desirable such as being able to convert Word documents into plain text for people who desire it, or to rewrite e-mail to output to a printer or send it to a FAX modem or pager.

Error Messages

If a mail message can't be delivered for some reason, the user should get back some useful error message describing the problem and what they should do to correct it.

It should be possible to configure the system to return customised advisory messages, such as "ffs02 doesn't exist anymore try user@pfs01" or "you can't send e-mail to a terminal server".

Location

The central post office functions could be replicated across several mail hub systems, providing that there are highly reliable ways of replicating and installing config files and databases, ways of combining / managing multiple sets of mail logs, etc. Note that replicating some but not all of the config files could cause disastrous mail loops or black holes.

It is possible that in the near future, the Computer Centre will operate a duplicate data centre at another site which will be expected to carry on full university core business (including e-mail) even if the primary site is completely out of action for an extended period of time.

Message Stores

Sending and receiving e-mail isn't a synchronous event like a chat session that requires both the sender and recipient people to be online simultaneously for the message to be transferred. Normally there is some delay between when the sender sends the message and the recipient reads the message of some minutes, hours or even days. It is also unusual for e-mail to be delivered directly to the user's desktop machine -- the user's machine is generally not running a mail receiving application all the time, or the user may use different desktop or portable machines at different times.

To cope with this, incoming e-mail is normally deposited into a message store, from which the recipient can retrieve their new messages to the workstation of their choice, at a time when it is convenient for them to do so. In some cases, the user can also save their read messages back into other folders in the mail store. In other cases the user will save their read messages in on their own local machine, or in a directory on a file server.

It is advantageous if the user runs a Mail User Agent on their local machine, which speaks a mail-specific protocol to the message store. This mail-specific protocol can then provide the same service to clients running different operating systems, and provide extra functionality such as "only show me messages from SMITH", or "only show messages smaller than 10 KB". Of course, the Message Store and the Mail User Agents need to speak the same mail-specific protocols.

Support should be provided for strong user authentication protocols such as Kerberos, and if possible encryption of the data transfered.

Message Stores need not do everything that is required to deliver outgoing messages to their final destination, but could merely upload outgoing messages to a mail hub.

Other considerations include the number and location of these message stores in order to provide local mail reading capabilities even if you are at a remote campus and your inter-campus links are down, and the fault-tolerance of individual message stores.