Date: Wed, 28 Jun 1995 04:02:05 -0400 (EDT)
From: Alex Nishri <nishri@utcc.utoronto.ca>
Reply-To: alex.nishri@utoronto.ca
To: eugene.siciunas@utoronto.ca, norman.housley@utoronto.ca, peter@library.utoronto.ca,gorrie@ecf.utoronto.ca, don.gibson@utoronto.ca, john.bradley@utoronto.ca,eric.ng@canada.sun.com, alex.bewley@canada.sun.com, jdd@cdf.utoronto.ca,Dennis.OReilly@ubc.ca, lindholm@ucs.ubc.ca, hooper@post.queensu.ca, pkern@utcc.utoronto.ca, cks@utcc.utoronto.ca, oattes@utcc.utoronto.ca, norman@utirc.utoronto.ca, britton@utcc.utoronto.ca, cheryl.ziegler@utoronto.ca, ip@manitou.astro.utoronto.ca
cc: Gordon Good <ggood@umich.edu>
Subject: FYI--what Michigan is doing
Big chunks of this summary are taken from the following two documents authored by Gordon Good of the University of Michigan:
<URL: http://terminator.rs.itd.umich.edu/projects/imap/imap.html>
<URL: http://terminator.rs.itd.umich.edu/projects/imap/imap tech.html>
and from a conversation Glenn Britton had with Gordon Good of Michigan
The University of Michigan began deploying their IMAP server based e-mail system in 1993. As of March 5, 1995 there were a total of 23,704 accounts on the IMAP servers. During that week 16,075 different people connected to an IMAP server at least once. There were a total of 230,045 sessions and the estimated maximum concurrent number of sessions was 774. Currently they have approximately 26,000 accounts and 800 peak concurrent users. This fall they expect 40,000 accounts.
There were four IMAP server machines, two SPARCServer 10/30 and two 10/40 machines. In February they added two Sparc 20/50 machines for a total of six IMAP servers. User accounts are spread evenly across machines. Each machine has 96 MB of RAM. They are planning to go from approximately 3 GB of disk for user accounts on each machine to 7 GB.
Michigan permits creation of folders, other than "inbox", on the server. So, for example, you could store your already read correspondence in folders on the IMAP server. [At UofT we do not permit this. It means that users must file correspondence on local file systems, which are inaccessible if you read your e-mail from a different location.]
Michigan implements disk quotas on the IMAP servers using standard Berkeley quotas. If you are over your 3 megabyte quota a message explaining the situation is added to your inbox. Incoming mail is held for you for one week, and is delivered once you reduce your disk usage below your quota. To check their quotas and usage at any time, people can send e-mail to a magic address and get a report in return. (The report is put in their inbox even if they are over quota.)
The Information Technology Division (ITD) supports Mailstrom (for Macintosh) and PC-Pine (for DOS machines). [At UofT, we rejected Mailstrom because it does not support MIME-however, we temporarily went with Eudora which supports MIME poorly and does not support IMAP. At UofT, we went with ECSMail for Windows, which supports IMAP and MIME, but is less mature as a product. Finally, at UofT we support PC-Pine, but only encourage its use for those not running Windows.] Michigan runs POP, in addition to IMAP, on their IMAP servers, although no POP-based e-mail packages are supported. [Accessing the same inbox from POP and IMAP, as can happen at UofT can lead to problems.]
In addition, a distinct group within ITD provides academic and administrative access to "login servers", a UNIX timesharing service offering Pine e-mail, Usenet news, programming languages, and other computing. It is accessible via telnet, dumb terminals, or dumb terminal emulators such as Procomm. The Pine email running on the ITD Login service uses IMAP to access the same IMAP servers mentioned above. The "login servers" use Solaris.
Users create their own accounts by telneting to a specific advertised machine. They authenticate to this machine using a universal pre-assigned userid, shared with other network based services, and their kerberos password. They type a magic command "imapme", which confirms their intentions and then creates their IMAP server passwd entry, user quota information, and X.500 entry.
The universal userid at Michigan must be 3 to 8 lower case alphabetical characters with no spaces or punctuation. [At UofT we tried to be nice guys by modifying the software to support userids up to 100 characters in length; this permits userids of the form alex.nishri@utoronto.ca but it can also be a costly modification to keep carrying.] Those without one can get it from the ITD Accounting Office or one of six other locations on campus. In addition, some departments have individuals authorized to create or change the universal userid and password.
Users are assigned one of 26 letters when an account is created, corresponding to 26 logical IMAP servers, a.imap.itd.umich.edu through z.imap.itd.umich.edu. With two IMAP servers, earlier in the service history, "a" through "m" were domain name aliases for the first box, and "n" through "z" for the second. As more boxes are added, users are re-distributed across them. Users do not have to change their e-mail client configuration because the domain name aliases are updated suitably. Those using the "login server" do not have to remember their letter, since it is programmatically determined based on the provided universal userid. The letter is also programmatically determined for those using Macintosh Mailstorm, which has been modified at Michigan to use kerberos. [A more general solution which Michigan and UofT will move to in the future is IMSP (Internet Message Support Protocol)-this will permit storing address books, IMAP server name, and other configuration information at the server rather than the local client.]
Backups are only used for recovery from disasters brought on by equipment failure or operator error. There is no on-demand restore service. Once per month, the IMAP servers are all shut down for a level 0 dump. This is done on the third Monday of every month at 2:30 am. Each machine has an HP DDS-2 DAT tape drive, and performs dumps of its local file systems. Other days of the month, an incremental dump is performed in multi-user mode.
The imap and pop servers were modified to provide instrumentation. There are daily reports. This is used for upgrade planning.
For security, no user logins to the IMAP servers are permitted. Administrators use encrypted telnet sessions.