Institutional Email Subcommittee

Unapproved Draft

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.

Back to the Email Evaluation Home Page.

Must Have Requirements

Client/Server architecture with native support for Internet standards including:
TCP/IP Internet network, rfc822 message content, SMTP for sending messages, IMAP for viewing messages including on demand attachment transmit, LDAP for directory, MIME for attachments, etc.

Basic email functionality: compose with standard editing functions, viewing, to/cc/bcc, printing, reply, forward, attachments including calling helping applications, message filing folders & management of folder contents, personal address book for individuals & lists, institutional directory access, cut/copy/paste/drag between email windows and other applications, etc.

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:
- remote and local folder management
- "sentmail" folder at local personal computer or remote post office
- drafts can be filed in remote post office or local personal computer folder.

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:
- shared folders
- view by thread
- changing access control list for post office folders

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:
- get required message headers, not every message in a folder
- post office-based searching and selection to minimize data transfer

address book management: easy graphical drag & drop moving entries, easy add to address book of addresses found in a message, print address book or address book entry, import/export in de-facto formats, nicknames and nickname expansion prior to sending

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):
- show messages by status (e.g. read, answered, etc.) or by field match (e.g. from=prichard, body contains "magic"), by size, date
- order of messages by status, field match, size, date
(i.e. show messages from boss at top, unread messages next, etc.)

message rules (based on criteria match alter message or where it is filed):
- support actions like move, copy to folder, delete

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:
- rendered inline versus by favorite browser
- can easily send HTML as MIME standard attachment

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
(IMAP/POP do not provide for notification of changes in unopened folders. All packages provide for notification of new messages in open folders.)

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

Email Evalutaion|Network Services Group | University of Toronto

This page is maintained by Alex Nishri
Copyright © 1998 Network Services Group - University of Toronto