|
|
Report of the SubcommitteetoRecommend anInstitutional E-Mail PackageSeptember 16, 1998 Back to the Email Evaluation Home Page. |
The institutional e-mail service provided by University of Toronto Computing, UTORmail, has been using ECSmail as the PC client package since August 1994. It is responsible for numerous system "crashes", appearing as "General Protection Fault" errors, is now becoming unsupportable, is unable to connect to newer printers, and lacks desirable features available on newer packages. Since ECSmail did not run on Apple Macintosh computers, a different package, Eudora Light was deployed for Mac users. A single newer package for both environments is desirable to reduce support costs.
In the spring of 1998 it became evident that the e-mail packages included with the two most popular World Wide Web browsers, Netscape's "Messenger", and Microsoft's Internet Explorer's "Outlook Express" were gaining in popularity and use. All new PCs, when purchased, come with one or both browsers, and hence mail package already installed. This ubiquity ensures wide-spread use. Both these packages are now supported by the Information Commons, and are distributed on the CD-ROM that newly arriving students purchase. They are also available for down-loading from the University's software distribution server, UTORdist.
While these packages may be adequate for the large majority of users, including students, faculty and staff, they do lack some desirable features, or implement them poorly, such as support for shared folders. This subcommittee was created to determine the additional functionality required by faculty and staff, including users of the AMS and new Student Record Systems, identify packages that could provide it, test and evaluate them, and recommend a suitable package.
The full text of this report (minus licensing costs, since unique to UofT) as well as links to other institutions' evaluations are available for viewing at URL: http://www.utoronto.ca/ns/eval.fall98/
A "Public" meeting was scheduled to allow members of the University community with an interest in institutional e-mail to make their needs known to the subcommittee. About fifty individuals participated in the three hour meeting. The netware admins and syadmins groups were also specifically queried for input. The information collected from these meetings and specific communications were distilled by the subcommittee into tables of requirements with "Must Have", "High" and "Low" priority, according to how many individuals felt how strongly about them. These are tabulated in Appendix A.
These requirements were then compared to the capabilities of several commercially available e-mail packages: Simeon from ESYS Corp., Eudora Pro 4.0 from Qualcomm, Outlook98 from Microsoft, and Groupwise from Novell. After some discussion, Groupwise was eliminated from further consideration because unlike the other three packages, Groupwise requires a new, different server infrastructure and this subcommittee was charged with recommending a new e-mail client to use with the existing post office servers. Moreover, Groupwise provides a far richer development environment than mere e-mail, and if there were a need for this richness, then other comparable products would need to be considered as well, such as Lotus Notes and Microsoft's Exchange. The directors of AMS and CNS agreed to jointly examine AMS users' needs later this fall to determine whether there was sufficient justification to warrant such a development environment.
The "must have" requirements and the capabilities of the packages are tabulated in Appendix B.
Since the subcommittee felt that there was insufficient differentiation between the three e-mail packages based on their ability to satisfy the "Must Have" and "High" priority requirments, all three were acquired and tested by a variety of individuals, including the subcommittee members, and staff from CNS, AMS, the Information Commons, and UofT at Scarborough. A list of evaluators appears in Section 4, below.. A summary of the feedback from the evaluators is tabulated in Appendix C.
Testing of the three packages revealed that all had various "bugs" or deficiencies of varying degrees of severity. None of the packages was "perfect" . However, it was felt that none of these deficiencies were sufficiently serious or onerous to rule out its use, especially when targetted at a relatively more sophisticated user community. The majority of users with relatively simple e-mail requirments were expected to be satisfied with the mailers provided with the browsers.
Review of the feedback of the evalators, as well as their own experiences, and comparison with the "Must Have" and "High" priority requirements led the subcommittee to unanimously agree that Simeon was the best fit for the University's institutional e-mail needs. It had the advantage of the most pain-free migration for existing ECSmail users, since the same company wrote both packages. It runs on both PCs and Macs, reducing the support overhead. It was also considerably less expensive than the runner-up, Eudora.
A) The subcommittee recommends that ESYS' Simeon be deployed as the institutional e-mail package, supported by the Information Commons. It should be made available for down-loading from UTORdist by faculty, staff and students that require its features. An initial license for 5000 users should be acquired, at a cost of $XXX, with $YYY for one year's support.
The subcommittee also came to realize that the features and functionality of the e-mail packages included with the browsers were rapidly evolving, and in fact, would likely satisfy the great majority of requirements in their next, or succeeding release. There may not be a need for a "more fully functional" institutional e-mail package in a year or so, since the commonly available, free e-mail packages may be more than adequate.
During the course of the subcommittee's deliberations, it became clear that some user requirements were not so much technical issues as policy ones. Current policy to store only the inbox at the post office hampers mobility, making it awkward to access one's e-mail from both office and home.
B) The subcommittee recommends that folders, in addition to inbox be stored at the post office, with a quota of 10 Megabytes of storage per user account. This will result in more disk storage being required, but its costs have also dropped significantly. An initial expenditure of $15,000 is expected for an additional 32GB storage and bus cards. This represents an increase of 25% over the current disk storage capacity.
Documentation should be prepared and disseminated to announce this change, but also stress that users are responsible for the safe storage of their e-mail messages, via back-up to their own systems or storage media.
C) An institutional IMSP server should be deployed for the central storage of System Preferences, Configuration Information and Address Books, again to facilitate access from multiple locations on campus or home. This is expected to cost $ZZZ.
D) E-mail messages, including any attachments, should be limited in size to no more than 5 Megabytes, and this limit strictly enforced. With the growing popularity of graphics being either imbedded or attached in e-mail messages, they are becoming much larger, and hence take longer to transmit. The UTORmail delivery guarantee, which is currently ten minutes will have to be relaxed to thirty minutes.
Note: Prices were removed from the Web version of this document.
Grateful appreciation is extended to the following members of the University community:
The subcommittee members are:
Paul Roth of AMS and Terry Jones of CNS also contributed significantly in testing products and participating at subcommittee meetings.
Contributors and product evaluators, in addition to those above, were:
All the participants in the "Public Meeting" of June 24, and those that submitted input through other venues.
The subcommittee solicited input at an open meeting June 24, 1998. The following was developed by the subcommittee on June 26, 1998 using the input received at the public meeting and via other communications.
|
Must Have Requirements |
|
Client/Server architecture with native support for Internet standards including:
|
|
Basic email functionality:
|
|
Graphical User Interface with included online help |
|
Supports Windows95/98 |
|
An institutional Mac package must be provided but not necessarily the same package |
|
Easy multiple post office access |
|
easy graphical drag & drop moving messages from one mailbox to another including across different servers (e.g. can drag from inbox on one server to saved folder on another server) |
|
Storage of messages in folders located at local PC or at post office:
|
|
Access configuration from multiple locations for mobility (home, office, roaming among offices, lab machines) for easier setup & diagnosis |
|
Access address books from multiple locations for mobility |
|
Address book management: separate group lists |
|
Migration tools to transfer folders/messages |
|
Migration tools to transfer address books |
|
Group interaction/collaboration:
|
|
online (connected to post office) & offline (work on downloaded messages) modes |
|
Support issues: ease of configuration |
|
Support issues: robustness |
|
Support issues: vendor support & responsiveness |
|
Support issues: availability of training materials |
|
MAPI simple v.s. extended |
|
High Priority Requirements |
|
dialup/low-speed connection and/or large mailbox efficiency:
|
|
address book management:
|
|
shared separate address books (e.g. a departmental address book) |
|
message lists alternative views (i.e. sorting & hiding of message lists as opposed to altering the messages or where they are filed):
|
|
message rules (based on criteria match alter message or where it is filed):
|
|
transmission privacy (e.g. can't spy password or content in network transmission): using SSL |
|
digital signature or encrypted with digital signature: S/MIME versus PGP |
|
decoding attachments using uuencode & binhex (not just MIME) |
|
disconnected IMAP mode (as opposed to online/offline, this does resynchronize on reconnect) |
|
HTML content:
|
|
Notification that receiver has read message |
|
Low Priority Requirements |
|
Scalable to large number of customers (not necessary because only advanced users will get this) |
|
UNIX support . Which UNIX? (motif?) |
|
Cross Platform consistency |
|
Subject-based, sender-based, and other field based auto-filing (fcc) |
|
Migration tools to transfer existing ECSMail or Eudora configuration to new package |
|
click on URL to launch favorite browser |
|
integrated USENET News reader and message submit |
|
Other Requirements |
|
Notification of change to
inbox folder or other possibly shared folder |
|
automatic inclusion of user specified signature (all packages under consideration do this) |
|
notify senders of long term absence automatically on message receipt (UTORmail post office function to be implemented ASAP; not dependent on email package.) |
|
Policy Issues |
|
Support of folders other than inbox at the post office |
|
Support of low end machines |
|
Support of large email messages (e.g. large attachments) |
|
Institutional support for scheduling/calendaring |
The following table was developed at the June 26, 1998 meeting of the Institutional Email Subcommittee. It is a start on comparing the three packages under consideration against the "must" requirements.
|
REQUIREMENT |
ESYS |
Qualcomm |
Microsoft |
|
IMAP4 Compliant |
Yes |
Win, Not Mac |
Yes |
|
Win32 |
Yes |
Yes |
Yes |
|
Macintosh |
Yes |
No (not IMAP4) |
No |
|
Client amount resources to run |
fewer |
fewer |
more |
|
Multiple Post Offices |
Yes |
Yes |
Yes |
|
Folder Management |
Yes |
Yes |
1/2 |
|
Remote Folder Management |
Yes |
Yes |
Yes |
|
Mobile Portable Configuration |
Yes |
No |
No |
|
Mobile Portable Address Books |
Yes |
No |
No |
|
Separate Group Lists |
Yes |
Yes |
? |
|
Migration Tools |
from ECSMail |
from Eudora |
No |
|
Group Interaction/Collaboration |
Yes |
Yes |
Yes |
|
Offline/Online |
Yes |
Yes |
Yes |
|
Vendor Support and Responsiveness |
Acceptable |
TBD |
TBD |
|
Training Material Available (evaluate) |
TBD |
TBD |
TBD |
|
Robustness (evaluate) |
TBD |
TBD |
TBD |
|
MAPI (simple/extended) (test) |
TBD |
TBD |
TBD |
NOTE: TBD = to be determined by test/evaluation
