Concerns were expressed yesterday in the ACADCOM forum about the
direction York has taken with distributed computing, and in particular
the strategy used for e-mail. Several people have suggested that my
reply explaining the e-mail strategy might be of interest to others
not subscribed to the ACADCOM mailing list.

The following is an excerpt from ACADCOM:

----
Given York's distributed computing environment, the strategy for delivering
campus-wide e-mail is sound. It's based on open standards and protocols, it
allows for growing demands and capacity, and it accommodates a range of
end-user mail products.

The open standards and protocols include RFC822 for the format of stored
mail, SMTP for the exchange of messages over the Internet, MIME for the
encapsulation of attached files, POP and IMAP for accessing stored mail, and
MAPI for interfacing with mail-enabling applications.

Presently, there are six UNIX servers for mail service and two specialized
disk arrays that provide central storage for users' home directories and mail
via the network to each of the servers. These machines are connected to a
high bandwidth FDDI backbone network. There are nearly 20,000 registered
e-mail accounts with several thousand more expected to be added over the next
few months. Plans are well underway to upgrade the UNIX servers; new hardware
is already on site and being evaluated and tested prior to being ordered.

The six UNIX servers for mail allow us to grow the system in several ways. We
can increase the capacity of the individual machines by buying replacement
machines, we can buy additional machines to distribute the load, and we can
tune the performance by assigning various components of the mail service to
separate machines. For example, one of the servers is dedicated to receiving
incoming mail while all six share the task of sending outgoing messages.
Likewise, five of the servers provide both interactive access (eg. for Z-Mail
Pine, Lynx, Gopher, etc.) and POP/IMAP services. We are considering
separating the interactive from the POP/IMAP to gain better responsiveness
for the POP/IMAP based mail readers.

Z-Mail has been selected as the primary mail reader application because of
its richness of function and features, its support for the open standards,
its cross-platform support, and its ease of use. It is the only choice for
people who will be using JetForms or other mail enabling applications based
on MAPI. However, our overall e-mail strategy allows other mail reading
programs like Pine, Elm, Eudora, etc. to be used instead, if so desired. CCS
supports Pine as an alternative for people that do not require MAPI
functionality.

The design of the overall e-mail system gives us flexibility to meet growing
capacity requirements and accommodates a variety of mail reading programs. It
also is much more complex than running PROFS on a single mainframe. Problems
can arise in many areas, the mail reader program (eg. Z-Mail, Z-Mail for
Windows, Z-Mail for Macintosh, Pine, etc.), the hardware platform (eg. PC's
with varying memory, disk, and CPU capacities, any of the six UNIX servers or
the disk arrays for central file storage, Macintosh computers, etc.), the
operating systems (eg. Windows, UNIX, Macintosh), overall network and/or
subnet loads, and so on.

Over the past few weeks we have been plagued by a problem with one of the
high speed disk arrays used to store incoming/outgoing mail messages. The
effects of this problem have been very disruptive, causing some of the UNIX
servers to halt completely and others to become overloaded to the point of
being unusable, and causing Z-Mail for Windows to hang indefinitely or crash.
We have been working hard with the vendor to correct this problem and believe
we are very close to a solution. Most of these incidents and our efforts to
address them have been reported in the york.announce newsgroup and the
york-announce-l LISTSERV mailing list.

We have just recently identified a capacity problem with the UNIX server that
handles the incoming/outgoing mail. The load on this system is sporadic but
peaks to high levels when there is high volumes of incoming or outgoing
messages. Z-Mail for Windows relies on this system for sending its messages
and when the load is high, Z-Mail will appear to freeze as it waits for a
connection. We have a faster machine ready to replace it and will be
switching to it as soon as possible and with as little disruption as
possible.

If you have questions about any of the specifics of the e-mail design or
would like more details about the disk array problems, I'll try to answer
them as best I can.
----