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. ----