The UTORmail service became available to faculty, staff, and graduate members of the University of Toronto on September 9, 1994. The electronic mail service provides customer assistance, documentation, the ability to create an inbox, a post office, and distributed software for use on personal computers. The post office consists of hardware and software which accepts new mail for delivery, routes electronic mail bound outside of UTORmail to other post offices, and handles items destined for UTORmail customers by sorting it into individual inboxes. The post office is sometimes referred to as an electronic mail server. People use client software to send and receive mail. The client software, running on an individual's local desktop machine or on larger multi-user timesharing service accesses the post office through the network.
Using the guidance provided by the Academic Task Force, the Library Task Force, and the Information Common Implementation Committee the UTORmail service is being extended for the fall of 1995. The most significant change is that we will be extending eligibility to 45,000 undergraduates.
The UTORmail post office was originally architected to support the entire University community. The hardware consists of inexpensive pieces that can be easily added to when the user population grows.
A decision was made at the end of June to purchase a new piece of hardware, a SUN SPARCarray; the rational behind this purchase is in the appendix B. Unfortunately, installing this new hardware would require upgrading to a different operating system, and hence reinstalling every software component at the post office during August. Because there is insufficient time to do this well, and assure a reliable post office for the fall, it was decided to defer installation of the SUN SPARCarray.
As of July, 1995 the post office consists of a Sun SPARCsystem 10 model 30 with 64 MB of memory and a 2.0 GB external hard disk. A second 2 GB external hard disk, on a separate SCSI controller is sitting idle until it is needed. A second SPARCsystem 20 model 50 with 128 MB of memory and 4 GB external hard disk sits idle until it will be needed. In anticipation of demand, we have purchased and will install two additional SPARCserver 20 model 71s, each with 128 MB of memory; we will try to scrounge up a 4 to 8 GB external hard disk for each. (Each of the four machines also has its own internal hard disk for operating system and software.)
These four machines will have identical operating systems and server software installed; in fact, we run the "track" software which automatically propagates changes made from the first machine to the other three. Although the first machine currently runs both mail delivery (zmailer) and inbox access software (imap & popper) on the same machine, we intend to configure them over time so that the first machine specializes in mail delivery and the other three specialize in inbox access.
For the fall of 1994 we used an existing tool for creating, changing, and deleting mailboxes. This tool required individuals contact special staff to create their mailbox for them. For the fall of 1995, we will be providing Web electronic form screens permitting an individual to create their own mailbox. These forms will be accessible from any personal computer or Library terminal running Netscape 1.1 or lynx 2--4; note that older versions of Netscape or lynx are unlikely to work. To use the form, individuals will have to provide the last 8 digits of their University of Toronto bar code and their student number, staff number, or, where someone doesn't have a student/staff number, a special library assigned number. (In planning documents the student/staff/dummy number is referred to as the SSD.)
The Library will provide a subset of the patron database so the 8 digit bar code and SSD an individual provides can be validated. The patron database subset will also provide the individual's name, from which the Web electronic form can manufacture the allowable firstname.lastname and firstinitial.lastname for this individual, and prompt them to chose one of the two. This assumes the Library patron database contains accurate information.
The form for creating a mailbox will also have text describing the conditions of use, which a user must scroll to the end of and click ok before proceeding. The creation of a mailbox will require specification of a password--there is no default initial password. Optionally, a forwarding address can be specified which will be used to forward all received mail without keeping a copy; note that this forwarding address is not checked, and if incorrectly specified, can result in lost mail. After the electronic form is completed, it will return the "post office number", which is required for configuring ECSMail, Eudora, or Pine.
Upon successful completion of the electronic form to create a new mailbox, a request is queued. All queued requests will be processed, and new mailboxes created overnight. User support staff have indicated it is desirable that this be done more often. After we have ensured there is a working system in place, we will return to this issue.
The Library will extract the necessary subset of the patron database and transfer it to the UTORmail Web electronic form software overnight. This means that someone who does not have a valid bar code must get one at the Library, wait overnight, then fill out the electronic mailbox creation Web form, and wait overnight before gaining access to their new mailbox. Again, once a working system is in place we will return to this issue. In particular, we will attempt to arrange that updated records, rather than the whole patron database, be processed more often.
We will provide a second screen for querying and modifying a mailbox. To validate access to the query/modify screen requires providing a mailbox name and the associated password--not the 8 digit bar code and SSD. The information which can be queried is the forwarding address and post office number; information which can be modified is the forwarding address and password.
If someone loses the password to their account, we have not resolved where they will go for human intervention to reset the password. We are planning special administrator Web screens that permit specially authorized staff to query and modify access to mailbox information for other individuals. Early planning suggests functions to get information about mailboxes, delete mailboxes, suspend mailboxes, create mailboxes for testing purposes, and create mailboxes of the allowed form departmentname.position. Because of uncertainty in specification and because of the nature of the functions, the special Web administration screens are likely to be the most time consuming programming component being undertaken. For this reason, for the fall 1995 deployment we will likely continue to use the existing mailbox administration tool for creating, changing, and deleting mailboxes. We believe that this will only require minor retrofitting to mesh with other changes being made.
Starting this fall all mailboxes will be associated with one and only one 8 digit bar code number--without exception UTORmail service will be denied without a valid bar code. Furthermore, any valid 8 digit bar code can be associated with at most one mailbox. (There are a number of reasons for this last requirement, one of which is future compatibility with a universal authentication scheme like that provided by kerberos.) UTORmail provides for mailboxes whose name is firstname.lastname or firstinital.lastname--the bar code number is that of the owning individual. UTORmail also provides for mailboxes whose name is departmentname.position (e.g. geography.info)--such mailboxes would normally be associated with a departmental bar code. A department can obtain one or more departmental bar codes, not associated with an individual, from the Library. Mailboxes of the form departname.position must be created by human administrators using special administrator tools screens--the standard Web screens for creating mailboxes will only support firstname.lastname and firstinitial.lastname. In addition, where the firstname.lastname and/or firstinital.lastname synthesized by the Web creation form is incorrect (e.g. where the patron database has the person's first name, but the individual more commonly uses their middle name), the mailbox will have to be created by human administrators. All bar codes, whether for an individual or departmental, are assigned by the Library.
When a record is deleted from the Library patron database, the corresponding UTORmail mailbox will eventually be deleted. The exact implementation details will be worked out after the fall 1995 deployment.
For the fall 1994 to fall 1995 period we did not record bar code numbers when creating accounts. This creates a transition problem. In some, but not all cases, we recorded the staff or student number, and we may be able to automatically determine the bar code number. In other cases we will need to assign someone to hunt down bar code numbers. In the short term, we will not be deleting any mailboxes created before bar code numbers were used. Users of pre-transitional mailboxes will be able to use the new Web screens to query or modify their mailbox because the bar code is not required for this purpose.
The exact procedure individuals will follow and place they will go to create their mailbox in conjunction with getting appropriate advice, documentation, and software is still being worked on and will be described in another document.
We have a published management policy of limiting all mailboxes to 5 MB. This policy is unenforced because we have no enforcement policy--what do we do when someone exceeds their 5 MB? We propose to look at the technical issue at the beginning of September, and present possible alternatives to management for selection.
To access messages in an individual mailbox the server runs imapd software, for Windows ECSMail & PC Pine, and popper, for Macintosh Eudora. A problem arises should someone try to access their mailbox twice at the same time; this can happen if you try to read your mail from home but left ECSMail/Eudora/Pine running on campus, it can happen when your dial-in line hangs up on you and you come in a "second" time, etc. To prevent scrambling of a mailbox when there is more than one concurrent access to it, the imapd software, used with ECSMail & popper, uses a "most recent access gets exclusive access" while popper uses a "first one in retains exclusive access". The later model requires human intervention when someone can't get in to their mailbox because they left Eudora running elsewhere, or had a dial-in connection hang up on them. The more desirable model can be used with Eudora if we switch from popper to popd. We will be conducting tests to see if we can replace popper with popd. We will also perform a minor upgrade of the version of imapd, in order to do this. We will be testing popd with Macintosh Eudora only. Because POP is not a real standard, we expect that people using other packages, which we do not recommend or support, may have problems when we switch--some packages may cease working altogether.
It was our intention to install IMSP on the server. IMSP, when used with ECSMail 3, now known as Simeon, centrally stores configuration and address book information. As an example of configuration information stored is the post office number, which ECSMail users will no longer have to know. A benefit of address book storage is that the same personal address books can be used from home and office. We have decided to defer IMSP installation.
A key part of any electronic mail service is an integrated directory for looking up the address of recipients and we have a strategy for doing so. (At many Universities, the X.500 or CSO PH directory contains an entry for every member of the community; individuals can access their entry to update personal information. This, however, requires an authentication scheme. For example, at the University of Michigan there are 100,000 entries in the X.500 directory and individuals are authenticated using kerberos before updating their entry.) At this time we are not deploying a directory.
Eudora has a dialog for doing directory searches in a CSO PH directory. Since the fall of 1994 we have supported this using a script that pretends to be a CSO PH directory. The only information which is made accessible is the electronic mail address. (Searches on a name are turned into searches on the electronic mail address to protect the privacy of those who don't want their first name revealed.) Currently searches are taking a long time; we will make minor adjustments which will significantly speed it up.
Since the fall of 1994 we have kept very little information about mailbox accesses in system logs to protect the privacy of individuals. For example, for popper, system logs show the IP address of the requesting machine, but not the mailbox it is accessing or the duration of the connection. Unfortunately, this has hampered our ability to answer basic questions necessary for forecasting future growth. In order that we know how many users access the system per week and how many concurrent connections there are we propose to drop records for every connection, giving the name of the mailbox accessed and the duration of the connection. We will write tools to statistically aggregate these records and provide reports suitable for managing future growth. Records will be deleted from hard disk after two weeks. (Although we will attempt to preserve the privacy of individuals, existence of these records means that University authorities or courts could obtain access to them--users should be made aware of this.)
To ensure reliability, we have written scripts that monitor various indicators and alert Operations staff of potential problems. As we gain experience, these scripts are continually updated to monitor for new things. We will be installing these scripts on the new hardware and trying to take account of changes mentioned above. We will also be changing Operations documentation to reflect hardware, software, and monitoring script changes.
The above scripts connect to a console system based on the NocWatch software. Unfortunately, we have no support for NocWatch or the hardware box it runs on. Operations is currently evaluating alternatives, but new software will not be in place by the fall of 1995. The existing scripts and the enhancements we plan to deploy for the fall of 1995 will use Nocwatch. When a replacement is deployed we may have to redo the scripts.
Some of the changes to the UTORmail post office hardware and software mentioned above will have a large impact on user support staff assisting customers with problems. For example, in ruling out network connectivity problems, user support staff will have to know there are four physical machines instead of one. Another example, is the behavior of popd as compared to the current behavior of popper. We will have to provide information to existing user support staff about these changes.
Mailbox names are not valid for direct login to the post office machines, which happen to run UNIX. However, they do consume UNIX userid numbers (uids). There is a limit of 32,000 with SunOS and 64,000 with Solaris, but it is not a good idea to reuse userid numbers too soon after a mailbox is deleted. We will be examining a method of making the userid numbers unique to each post office mailbox rather than unique across all mailboxes. This may be done after deployment.
We need to build scripts to move groups of mailboxes from one post office machine to another. This may be done after deployment.
It was our intention to add a few thousand new mailboxes to a new post office machine, then the next few thousand to the next machine, etc. At the University of Michigan a more even balance of load on machines is obtained by assigning sequentially created mailboxes to different post office server machines. An implication for user support staff is that every individual with a new mailbox will appear to be randomly assigned to a post office. We will discuss this with user support and make a decision for fall 1995.
We will continue to back up mailboxes to magnetic tape every night to permit recovery from disasters brought on by equipment failure or operator error. Currently we protect against administrator error by keeping copies of deleted mailboxes for an indeterminate period; we propose a policy of eliminating copies of administrator manually deleted mailboxes 2 days after the deletion. There has been some concern expressed that we should improve user documentation to explicitly state that, as with any computer system, a risk of data loss exists and copies of valuable information should be kept.
We currently offer a mailing list service, listserv-like, through UTORmail. However, we know that large mailing lists can adversely affect delivery time of other mail. It can take hours to explode and process a single posting to a large mailing list, during which time other people's mail isn't being processed. Thus far we do not have any really large lists. There are several alternative solutions, but there is insufficient time to implement one for the start of fall 1995.