Undergraduate Email System Requirements

The current email system for UCSB's 16,000 undergraduates is sorely overtaxed. It cannot accommodate the increasing use of email and the Internet in support of the University's academic mission. UCSB's Campus Network Committee appointed an Email Task Force to make recommendations on the most appropriate solution(s) for undergraduate access to email. The task force, comprised of students, faculty, and staff from across the campus, researched, developed requirements, and will be making recommendations on the best solution for undergraduate email that is currently available. This task force, formed in February 1996, developed this list of requirements for an undergraduate email system, surveyed other universities and other UC campuses, and is evaluating possible email solutions based on these requirements.

The requirements in this document are the result of weekly meetings since February 1996 to evaluate UCSB's needs, and analyze the merits of specific protocols/standards, and possible solutions. While there are many different email systems which would allow students to communicate with faculty, staff, and other students, not all systems meet these requirements, even systems that are well-known and popular.

This document contains several sections. Each section addresses the requirements and technical needs for the following components of email systems:

• Client (the application used by students to access email)
• Server (the computer hardware and software which processes email, stores account information, and allows the system administrator(s) to manage the flow of email)
• Protocol (technical rules and standards used to exchange information between email systems)
• User directory services (the index of information about campus users and methods for searching that index)
• Licensing (considerations for effective implementation of a site license)
• Bonus features
• Other UCSB issues
• Cost considerations

•  Client/Server based solution: A process running on the client and an associated process running on the server system which does not require that the client establish a remote file system "mount" on the server. The client and server are communicating using a mail access protocol (e.g., IMAP) instead of a file sharing access protocol (e.g., NFS, Appleshare). Our objective here is to maximize efficient communication between the client and server and to minimize system demand on the client, server, and the network between them.
•  Client configuration properly supports multiple users in public access environment. Individual users mail should be the same (same interface, same configuration, same mail) from any machine used to access that mail. (e.g., IMSP or ACAP or similar protocol which ensures that user configuration is stored on the server side, not the client side.)
•  Multiple platform support: Mac, DOS, Windows, Windows 95, UNIX
•  Character-based access (terminal/vt100/telnet)
•  X-windows access
•  Use of standard operating system network software (standard TCP/IP protocol implementations) for each client platform
•  Quality of the user interface. In assessing quality, we will evaluate:
  • Functionality, flexibility, and ease of use
  • Minimal training requirements for end users
  • Spell checking
  • Drag and drop enclosures
•  Standard mail functions must include:
  • Printing capabilities
  • Auto-response features for vacation periods, including the ability to retain mail received during this period
  • Autoforwarding
•  Disruption of work when using other programs is minimal when checking or receiving mail.
•  Reasonably effective authentication for outgoing mail. It must be difficult (or impossible) to falsify sender's identity on outgoing mail.
•  Client mailbox management tools which include the ability to search and browse stored messages.
•  User can change his/her own password.
•  Long term viability of client software and vendors.
•  Robust compatibility with commonly used operating systems and commonly used software; i.e., should not crash a normally configured computer/system.
•  Reasonable network performance with minimal network impact. This should include reasonable performance when accessed via modem (remotely).
•  Reasonable use of resources, such as memory and disk space, on different platforms. (E.g., 5MBs of RAM on PC or Mac is probably too big.)
•  Ability to download email and enclosures to workstation or floppy.
•  Filtering/scripting/rules-based mail handling, e.g., ability to easily filter incoming mail to separate mailboxes by subject or by sender.
•  Serial line support. Low speed network access via modems or serial lines on campus not precluded.
•  Return receipt (delivery notification options should be available, e.g., delivery, open, reply receipts on the same system and delivery receipts on different systems).
•  Recall of sent but unopened messages on local system.

•  Accommodation of accounts for all undergraduates (total = 16,000), 1,000 simultaneous client/server email connections, and 50 telnet connections.
•  Can be scaled to support 30,000 users; and can be scaled to support 3,000 simultaneous client/server email connections.
•  Efficient administrative tools for handling large numbers of accounts (e.g., automated account generation, mass account terminations, ability to customize tools).
•  Long term viability of hardware and software products and vendor(s).
•  Features and options which enhance system reliability (e.g., redundancy or automated switch-over in the event of failures.)
•  Must be able to backup and restore system data.
•  Mail/mailboxes are stored and managed on the server by default. IMAP or similar protocol; not POP protocol. IMAP allows for mail to be organized into separate folders and subfolders on the server(s), whereas the POP protocol allows mail to be retained in the mail spool area, hence unorganized on the server or stored and managed on the individual workstation.
•  Ability to control which users are connecting to which servers (by client address or user ID).
•  Email may reside on one or more servers, but will be accessed by users transparently; i.e., users do not need to know on which server their mail is stored. (Distributed mail repository.)
•  Tool to transfer stored messages from continuing students' current UCSB email system to the new system. (Mailbox migration from standard UNIX mailbox; Sendmail is currently being used.)
•  Limits by user ID on server storage space; ability to monitor amount of storage used by individual users.
•  Audit trail. Ability to audit administrative tasks, standard flow of email, patterns of connections, records of mail transmissions. Facilities for investigation of connections and mailbox contents when appropriate.
•  Support for efficient mass communication. Announcements must reach all intended users without generating a copy for each individual user. For example, an emergency announcement to the whole campus must be received by each user without replicating 20,000 copies on the server. Ways to efficiently send messages to related groups of people like classes, majors, or colleges. A method of preventing and/or identifying source of "spamming" (inappropriate bulk emailing).
•  Convenient format for Internet mail addressing (e.g., joe.smith@aol.com, jane.jones@ucsb.edu).
•  Tools to limit or manage message size to avoid catastrophic system impact.
•  Aliases (nicknames), user/administrator created mailing lists, and automated mailing lists are supported on the server. For example, automatic class lists could be stored and used on the server, as well as voluntary subscription lists.
•  The solution should allow the user to select from amongst a group of clients from multiple vendors.
•  Speed - minimal time needed to establish connection and rapid processing for all mail operations.
•  Minimal impact on system resources with standard email gateways. (If using a gateway to SMTP, minimal overhead is required.)
•  Reasonable recovery from lost connections, requiring no intervention on server and minimal work loss on client end. (Timeouts on stateful connections with checkpointing.)
•  Timeouts can be set to disconnect idle clients.
•  Ability to send email from within other standard software. (E.g., Microsoft Word, by use of protocols such as MAPI or VIM.)

•  TCP/IP. Transport Control Protocol/Internet Protocol. The standard by which communication is conducted across the Internet. TCP/IP is required on the new campus FDDI network.
•  Open standards, including generally accepted Internet protocols, that allows for interoperability of various messaging components. For example, such a scheme allows for different clients, exchanging mail between systems, etc. (Open standards or published API transport mechanisms.)
•  SMTP (ESMTP). Simple Mail Transport Protocol, and Extended Simple Mail Transport Protocol. The standard way of sending and receiving email between computer systems on the Internet.
•  Client authentication. User has to log on with a unique user ID and password to use mail.
•  MIME Support. Multipurpose Internet Mail Extensions is a standardized way of attaching to an email message documents that were created in other programs, so that the document is received in the same format that it was sent. E.g., an excel file is sent and received as an excel file.
• In evaluating MIME support, the following points should be considered:
  • How are helper applications integrated for MIME support?
  • What does the receiver have to do to use the MIME attachment, whether or not the receiver has the same program that the sender used to create the file?
  • Which MIME clients, other than your own, have you tested for compatibility with your MIME enclosures?
•  IMAP Version 4. The advantage of the IMAP protocol is that it allows email to be stored and managed on the server, rather than the client, which facilitates users accessing mail from multiple locations.
•  Kerberos Version 5 support. Kerberos is a standard way of using a unique user ID and password for initial logon, which provides general security and authenticated access across a wide array of systems and networks for the duration of each session.
•  Security: Public key verification. (E.g., PEM (Privacy Enhanced Mail), or PGP (Pretty Good Privacy).) These are methods for verifying that the contents of a document have not been tampered with, and allowing the receiver to confirm the identity of the sender.
•  Encrypted client authentication. No clear text passwords are sent across any networks.

•  Supports distributed hierarchical user directory service (e.g., X.500, LDAP (Lightweight Directory Access Protocol), Whois++). If information is distributed, it may reside on multiple servers; and the user database will be organized hierarchically.
•  Supports distributed administration of user database. Provides the capability for more than one person to be responsible for different facets of the data.
•  Directory service must be extensible. Additional data elements can be provided by the appropriate departments to be added for either general campus use or the departments' private use.
•  Data migration tools for integration with campus directories and databases. There must be efficient tools for moving the existing campus directory information to the new directory service. Automated mass insertion tools are needed, with minimal reentry of data.
•  Provide multiple access levels to directory services. Access privileges can vary by individuals as well as by groups (categories of users).

  One example is NFR (Not For Release): only someone with University "need to know" can access an NFR record. Traceable real name identification shall not be listed in the University-wide directories for NFR records. In user-initiated email, the user's identification need not be protected.

•  Authenticated access to directory services. For example, general public record information (name, email address, department, phone, job title) should be accessible to anyone. Other UC information (class level, GPA) should require an authenticated (user name and password) logon.
•  Advanced searching features. E.g., name, pattern, or sound matching; searching by database fields such as first name, last name, major, job titles or categories.
•  Extensible directory delivery service. Ability to work with multiple look-up methods such as ph, cso (gopher look-up protocol), or finger.

•  Simple campus-wide licensing; easy distribution of (and upgrades to) software, with minimal reporting required. (No per system or per user registration.)
•  Technical resources and documentation to allow support staff to better understand, customize, or extend the system. (Source code or Application Programming Interfaces [API].)

•  Easy calendaring/scheduling integration with email.
•  Interface into bulletin boards or UseNet News.
•  FAX gateway.
•  Interactive talk (IRC, Talk).

•  Existing infrastructure (equipment, networks and organizational units) should be used when possible.
•  The design for undergraduate email should allow for the accommodation of faculty, staff or graduate students accounts as necessary or desired.
•  Addition of other services should not be precluded.

The cost considerations take into account the up-front capital costs, but also the ongoing operational costs of the entire project (including impacts on campus information systems resources and infrastructure).

As email is on the brink of a fundamental change, we are seeking a solution that accommodates these new technological advances by being based on the emerging open industry standards.

One-time costs include site preparation to accommodate equipment (including appropriate room facilities, air conditioning, power, network facilities, security) and to accommodate personnel, as well as the hardware and software purchase costs.

Ongoing annual costs include:

• staffing for system administration, operations, help desk, current documentation and training (for support staff and end users); supplies and expenses for operation and staff support; anticipated replacement or amortization costs of the hardware and software; and annual maintenance contracts for the hardware and software.
• Network configuration + support
• User training and support
• Training classes and manuals
• Distribution of client software