ITS Mail Working Group
Interim Report


Revision: 1.13 This report is available in its entirety in a PostScript version suitable for either viewing or printing or as plain ASCII text.


1 Introduction

At the end of March 1996, after receiving the report The Electronic Mail Service at UWO, ITS management followed the recommendations of that report by forming a small working group consisting of the authors of this report to

...look at the alternatives and interoperability of email applications. EMC2 will need to be phased out and the VAX will be replaced within the next year (or so). (ITS Management Minutes Mar 28)
The goal of this project is to recommend a campus mail system[*] to replace the existing EMC2 system (as a first priority) and to become a general, ITS supported, e-mail system that VAX users and others can gradually adopt. Client, server and desktop interoperability issues will be addressed. It is important to note that the project will focus on the e-mail service rather than trying to replace the ``Total Office Automation'' aspects (scheduling, bulletin board, conferencing services, FAX gateway and forms system) of the existing EMC2 product. We expect that other project groups will be formed to work with us on replacing the non-e-mail functions of that system.

A recommendation from this group was expected by the end of the summer, but this report recommends that this be adjusted to the end of 1996. Implementation and transition phases will follow during 1997.

In the following sections we'll outline the activities and work initiated so far and those planned for the next few months. Our activities have concentrated in three areas: keeping everyone informed; EMC2 research; and defining the new direction.

2 Keeping Everyone Informed

3 EMC2 Research

3.1 EMC2 Training

The three group members that aren't EMC2 users took a short course on the EMC2 package to familiarize themselves with the facilities and features of the package.

3.2 Survey of Key EMC2 Users

A rough survey for existing users of EMC2 was developed to the point that it could be used as a tool in interviews conducted by team members. We felt that an informal, hands-on approach to gathering this information was important.

A group of 12 key users (representing many others) of the existing EMC2 system were identified and surveyed via interviews. In general, this group was supportive and not at all adverse to the move away from EMC2, especially if they could make the move on their own timetable -- most preferred a summer transition. The group consisted of the following people, included is their department followed by any special reason for interviewing them:

3.3 Related Issues and Projects

Many issues were identified by the mail working group and reinforced by our interviews with EMC2 users. We classified these issues into three categories to define how they should be addressed.

  1. Some have either already been or will soon be addressed by this working group -- Mail Working Group.
  2. Others will need to be solved by the follow-on group(s) that will be responsible for the transition of the existing EMC2 users to the new system -- Transition Team. An embryonic version of this team consisting of Reg Quinton and Chuck Reid has already started work on some of these issues.
  3. Still others have been identified as having major impact on the mail replacement project but due to the mandate of the group and the independence of the undertaking, we recommend that they be considered as separate projects -- Spinoff Project. These projects should get underway as soon as possible in order to permit an orderly move from the current system to the new one.
See Appendix A for more details on these projects and issues.

  1. Mail Delivery to Home Directory Project in progress
  2. Addressing and UWO Directory Spinoff Project
  3. Mailing Lists and Nicknames Transition Team
  4. Old Mail Folders Transition Team
  5. Keeping Existing Important EMC2 Features
  6. New Features MAPI, Spellchecker Mail Working Group
  7. Keeping the client lean Mail Working Group
  8. IDs and Passwords Too many... Spinoff Project

4 New Directions

4.1 IMAP Decision Confirmed

Our preliminary investigations of the Internet-based e-mail field showed us that an IMAP4-based[*] service would likely be the best upgrade to the existing systems. Some excellent papers are available at the University of Washington's IMAP Information Centre that outline the reasons why we should implement an IMAP4-based system at UWO. In brief, IMAP4 solves many of the problems associated with the earlier proprietary EMC2-based and POP3-based client/server e-mail models:

The IMAP4 approach is becoming universal in the industry with the Internet Engineering Task Force (IETF) close to finishing a common standard. Vendors from Netscape, Sun and IBM to Microsoft are now supporting, endorsing and implementing this standard for e-mail.

The major push to make IMAP universal has just started (the first IMAP conference was held in January 1996 with attendees that included the who's-who of the e-mail world) so UWO will be well positioned to adopt this technology as we replace our old systems over the next year or two. We believe that an IMAP4-based service will meet the e-mail requirements for the most users for at least the next five years.

In June we installed the University of Washington's IMAP4 server on the mail hub machine for testing by the working group.

Standards Groups

Our Peers

4.2 IMAP4 Client Programs

LAN vs Internet Mail

We decided to put our primary efforts into finding an e-mail system that has grown out of the open Internet tradition rather than a LAN-based system that is gradually adding Internet capabilities. This has the advantage of fitting well into our existing mail infrastructure (i.e. the back-end) and into the Internet without the need of troublesome gateways. The disadvantage (and thus tradeoff) is that the LAN-based systems currently present a somewhat glossier application to the end-user -- the client programs are more mature. We have noted that the gap between the two types is shrinking as more fully featured Internet Mail applications appear.


For the PeopleSoft project, it is important that simple MAPI-based interface is provided by the client applications. All of the leading commercial products do provide the simple hooks required.


We also expect that POP3-based clients (like the current freeware version of Eudora) will continue to be supported for quite some time in parallel with the IMAP4 service. Indeed the most popular IMAP4 server includes POP3 support.

Some Promising IMAP Clients

Using a list of client programs supplied via the IMAP Information Centre at the University of Washington, we identified the major players in the market and will be concentrating on these. All of the software is currently under very active development so there is some risk in choosing any of them. Indeed, we expect the list to change during the next few months of our investigation. Our hope is that a clear winner will emerge before the end of the year.

Siren Systems
Siren can use a IMAP4 server, but to take advantage of all of its features you have to use a IMAP server with extensions from Siren. They have promised to make their server IMAP4 compliant in the near future.

From our preliminary trials it looks as if Siren has the best user interface so far (we haven't been able to test the X-window or MAC versions yet). This is the commercial system favoured by SSCL in their evaluation of mail clients. It has been chosen and heavily endorsed by the University of North Carolina as their campus-wide mail package.

Siren includes MAPI support on the Windows platforms which is important for PeopleSoft compatibility.

Solstice Internet Mail
Sun's server and clients are still very early on in their development -- production versions mightn't be ready for our deadlines. The product does provide MAPI support. It is not available for Macs. We are working with the local Sun office to try to get more information about the future of this product and to perhaps participate in a beta-testing program. Current indications are that Sun may be relying on Netscape to provide a client rather than further developing a client. They may be moving towards just supporting an industrial strength IMAP4 server.
The University of Washington's Pine and PC-Pine programs are free but not available on the Mac platform -- Maildrop has been suggested as a free IMAP-based client for Macs. Pine does not provide a MAPI programming interface for PeopleSoft. Nevertheless it provides an excellent migration path for existing Unix terminal users since the learning curve for them would be very gentle.

Moving people to the PC version of Pine would significantly off-load our central time-sharing systems while providing a better interface to our users. Most terminal users do use PCs, but they use the mainframe-based Pine rather than the POP3-based Eudora so that their folders are always accessible on the central system. PC-Pine provides this facility without requiring a ``dumb terminal'' connection while providing users with a quick and familiar e-mail environment.

At first glance, Simeon seems to have a very difficult user interface, but a predecessor is used extensively by UofT. Also this company seems to be in the forefront of IMAP4 and related protocol development. Perhaps with more familiarity we could learn to love the flexibility of the interface. Simeon presents a common look-and-feel on all platforms (MAC, Windows and Unix). This means, however, that it is native to none and because it was developed with an abstraction layer above the operating system, it tends to be slow on all platforms.
Netscape has been promising to include an IMAP4-based client in their v4 browser. They have said that they would deliver this product by the end of 1996. Currently version 3 of the product is still being beta tested so there has been no chance to test this (vaporware) product. Netscape recently hired the key author of Stanford's X-11 IMAP4 client, ML.

Using Netscape as the mail client has some advantages in that versions of Netscape is available widely on campus already and it is well accepted. Judging by its current POP3-based mail capabilities Netscape might not have the specialized mail handling features of the other stand-alone programs. The question is ``Will that matter to the majority of our users?''

Z-Mail Pro
NetManage has recently announced the next generation of the very sophisticated Z-Mail package, Z-Mail Pro. The new version now embraces IMAP4 enthusiastically. York University chose Z-mail (in its POP3 incarnation) as their campus mail system a few years ago. Its glossy user interface coupled with its cross-platform support (Windows 3.x Windows 95, Windows NT, Mac, X-window and dumb-terminal) make it a major contender (especially if we could get a copy of it!)

4.3 Planned Activities

5 Recommendations

    Transistion timeline Figure 1: Rough Mail Transition Timeline

  1. That the timeframe for this project be adjusted to expect a final report for the end of 1996. This will allow the working group to do a more thorough investigation but more importantly allow the vendors of IMAP4 products a few more months to get their products to market. Since there isn't yet a clear winner and the users of the current systems tell us that a conversion at their pace in the summer of 1997 would be best, an early spring 1997 start for the transition to the new system seems feasible. Figure 1 illustrates via a time line the recommended sequence of events.
  2. That a IMAP4-based mail system be adopted as the basis for the next generation mail system on campus with selection, implementation and user transition to occur over the next 18 months.
  3. That Reg and Chuck continue their investigations into pulling information out of the EMC2 database with the eventual goal of feeding this information into the new system. We are confident that the hard part of this is getting the information out while getting it into one of these new systems will not be a major task and certainly not highly dependent on the IMAP4 client chosen.
  4. That the non-e-mail facilities provided by EMC2 that are somewhat peripheral to this project be pursued by appropriate teams in cooperation with this working group while this group concentrates on e-mail and the facilities very closely related to that service. Spinoff summary:
    1. Addressing and Directory Issues
    2. BBS/Shared Folders
    3. Calendaring/Scheduling
    4. Forms
    5. FAX Gateway
    6. IDs and Passwords
  5. That e-mail should be considered as a major part of the VAX shutdown/transition.

A More Details on Related Issues and Projects

A.1 Issues

The following issues were identified by the group and reinforced by our interviews with EMC2 users. Some have been addressed already while others will solved during the following 6 months by the working group in cooperation with others at ITS. Still others will be left to the new groups mentioned below

New mail addresses for EMC2 users

The UWO Directory
The use of addresses for non-EMC2 users.

Mailing Lists and Nicknames
(a transition issue)

Old Mail Folders
(a transition issue)
Keeping Existing Features
Many existing users have expressed a need to maintain (in some form) some of the advanced features of the existing system:
Departmental Mailboxes
Shared spots for corporate mail -- or filtering/pre-sorting?
Private Conferences
EMC2 feature, not extensively used, could mailing lists handle this?
standardized (MIME, UUENCODE), easy to use.
Timed Mail
Ability to have mail go out at a pre-determined time - and for reminders. Could be handled by a scheduling/calendaring package.
Auto Reply
Vacation messages

Important New Features
Features that aren't currently available in EMC2.
MAPI Support
A minimal implementation the Microsoft's Mail Application Programming Interface is important for the workflow-enabled applications within the PeopleSoft suite.
Spell Checker
A good and personally extendable vocabulary is important. (We never purchased the spell-checking package for EMC2.)
Keeping the Mail Application Small
EMC2 is seen as a resource hog.

A.2 Projects

The following projects have been identified by the group as having a major impact on the mail replacement project but due to the mandate of the group, they should be considered as separate projects. Note that while some of these are already in progress, some are not but should be soon in order to permit an orderly move from the older mail systems. We would like to request that cooperating groups be established soon to investigate and make recommendations for these areas.

Mail Delivery to Home Directory
A performance issue.

Addressing and the UWO Directory
See above for details.

BBS/Shared Folders
A current EMC2 feature

A current EMC2 feature

A current EMC2 feature

FAX Gateway
A current EMC2 feature

IDs and Passwords
Too many...

About this document ...

ITS Mail Working Group
Interim Report

This document was generated using the LaTeX2HTML translator Version 96.1-c (Feb 29, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -t mail-i.tex -address Peter Marshall, ITS, UWO <> Last update: 96-08-27 00:17 by peter -show_section_numbers -dir /usr/internal/nst/peter/public_html mail-i.tex.

The translation was initiated by Peter Marshall on Tue Aug 27 00:17:04 EDT 1996

Mail Working Group: Peter Marshall (leader),Colleen Bretzlaff, Debbie Jones and Reina Tebby all of ITS at UWO
By a campus mail system we mean both the client front-end program and the back-end systems used to gather, deliver and sort e-mail. It does mean that we adopt a common protocol but that doesn't necessarily mean a single client for all users.
Internet Message Access Protocol

Peter Marshall, ITS, UWO <> Last update: 96-08-27 00:17 by peter