Email, Personal Organization, Calendar, Collaboration, and Communication Systems
Request for Proposals

I. Introduction

A. Purpose of RFP

The University of Vermont (UVM) has used essentially the same email architecture (SMTP) since the academic VAX and IBM were replaced by popular Unix-based email systems in the 1990s. In the last decade, the number of users has increased 10 fold; the number of messages has increased by more than 50,000%; plain text has been replaced by rich media; client-server GUI interfaces have largely replaced host-based terminal interfaces; and email viruses and spam have become daily disruptions.

Simultaneously, email has moved from a curiosity to an important business technology and is being joined by other technologies—instant messaging, peer-to-peer file sharing, voice conversations/messaging, video conferences, online calendars, and more.

Our daily information load is compounded by the fact that sometimes we have access to our desktop computer, sometimes to one in the Cyber Cafe, sometimes a notebook computer, sometimes a cell phone, and increasingly other portable personal information managers (or personal digital assistants—PDAs).

What are the advantages of our current environment?

The current email foundation has served to support many functional and capacity enhancements without forcing users to change their email accounts or programs. In general, the current email system has proved to be flexible, reliable and very economical. In a recent cost study, the annual cost for the email, anti-virus scanning and spam management systems, including server and end-user support, was computed to be a small fraction of independently published annual total cost of ownership (TCO) estimates for popular commercial email systems.

Why are we considering alternatives?

Our changing communication environment, plus a number of email disruptions this semester, has led UVM to begin evaluating alternatives to our current email infrastructure to better support email and its alternatives. The goal is not to replace email but to enhance our email infrastructure and explore emerging electronic communication tools to support UVM's mission.

B. RFP Schedule

This schedule is for planning purposes. The University of Vermont reserves the right to adjust the schedule to meet its needs.

Event	Date / Deadline
Issue RFP (announced by email distribution)	July 23, 2004
Confirm intent to respond via email	Through July 29, 2004
Vendor questions (deadline)	Through August 6, 2004
Complete responses to questions	Through August 13, 2004
RFP responses due	August 20, 2004
The following dates are all tentative: Down select to 2-3 proposals	August 26, 2004
Finalist presentations & usability tests	Through September 30
Complete Q&A & negotiations	Through October 15
Select vendor	October 22, 2004
Board of Trustee approval (if needed)	November 12, 2004
Begin implementation	December 1, 2004

C. Software Versions

Your responses should reflect software currently in production and in use by customers; clearly note any responses applicable to future releases, including the version number and the date it will be available in production for customer use, and whether an upgrade charge will apply.

D. RFP Forms Basis for Contract

The vendor’s response will become part of the final contract.

II. Current Institutional Environment

A. Email Clients & Protocols

1. IMAP4

2. POP3

3. MAPI (currently approximately 2 unit servers only)

4. Email clients currently in use:

Email Program	Estimated % Active Users	Trend	Centrally Supported
Apple Mail	<2 %	Growing slightly	Y
Eudora	10%	Gradual decline	Y
Mozilla	< 5%	Steady	N
Mulberry	<1 %	Steady	N
Netscape	<5%	Gradual decline	Y
Outlook	10%	Steady	N
Outlook Express	15%	Steady	Y
PINE, ELM, Mutt, etc.	<5%	Steady	Y (PINE only)
Thunderbird	<1%	Growing	N
Webmail (IMP)	>50%	Steady	Y

5. Popular desktop operating systems

Windows (most versions)

Macintosh (Classic and OS X)

Linux

Unix (various versions)

6. Popular Web browsers

Internet Explorer (MacOS X and Windows 2000/XP)

Netscape (MacOS X and Windows 2000/XP)

Mozilla (MacOS X and Windows 2000/XP)

Safari (MacOS X)

B. Email Hardware & Operating Systems

1. IBM RS6000 & Intel

2. Linux &AIX

3. Dot Hill SAN

4. Sandial Fiber Channel Switches

C. Email Software

1. Email transport & storage

a. POP & IMAP (Univ. of Wash.)

b. SMTP

c. Email storage currently in file system

2. Virus defenses

a. Sophos at the email gateway (with spam management, see below)

b. Symantec on desktop computers

3. Spam and other email management facilities

a. Pure Message (Sophos) spam ranking at email gateway

b. Web interfaces for: (see http://www.uvm.edu/account/)

Individual setting spam diversion threshold

Selecting auto-deletion of virus-infected, but cleaned, email messages

Vacation and other autoresponse messages

Autoforwarding email

Server-based message filtering

4. Webmail

a. Customized version of IMP

5. Encryption - Secure Sockets Layer (SSL) and Transport Layer Security (TLS)

a. SSL/TLS IMAP & POP

b. SMTP with TLS & authentication

D. Directory Services & Authentication

1. Open LDAP (authoritative directory)

2. Kerberos for authentication

3. Automatically sourced daily from HR & Student databases

4. Active Directory – synchronized daily with authoritative directory

E. Calendar & Scheduling Services

1. Oracle Calendar (formerly Corporate Time) available for faculty & staff

2. Microsoft Exchange used by Medicine & Business faculty and staff

3. Event calendars in Oracle roll up to campus events

4. Both Oracle and Schedule/Resource 25 used to schedule rooms

F. Email Volume

1. Peak messages per day

a. 350,000 messages incoming per day

b. 160,000 messages outgoing per day

2. Peak inbound messages per hour

a. Typically 30,000 /hour peak incoming (up to 50,000 / hour)

b. Typically 20,000 / hour peak outgoing

3. Size of message storage

a. 1,000 GB currently allocated for email files

b. Approximately 50% in active use

4. Total accounts (central servers)

a. 35,000-50,000 total accounts (many not actively used)

b. 13,000-15,000 unique user logins per week

c. 2000 concurrent active IMAP sessions

d. 20 POP connections per second

e. POP users represent about 15% of our active user base.

f. IMAP & Webmail currently comprise 85%.

g. 4000 accounts are forwarded to other email servers.

5. Email quotas

a. No general limit on email storage

b. Inbox limited to 50 MB

c. Individual message size limited to 10 MB

6. Estimated mailbox size distribution

a. Small (1-20MB) 83%

b. Medium (20-400MB) 15%

c. Large (400-1000MB) 2%

G. Estimated Email Growth

1. Message volume & storage needs have been increasing at more than 50% per year.

2. Enrollments have been projected to grow 2-4% annually.

3. New ERP[1] systems and other workflow changes will increase email usage.

4. Lifetime email accounts for alumni under consideration

H. Backup System

1. Legato Networker

2. Remote AIT3 tape library

III. Current Departmental Email Environment [2]

A. College of Medicine

1. Microsoft Exchange server

2. Approximately 1,000 accounts; projected to grow to 1,400 within one year

B. School of Business

1. Microsoft Exchange server

2. Approximately 900 to 1,500 user accounts

C. College of Engineering

1. Unix-based, IMAP & POP (similar to central email services)

2. Approximately 2,000 accounts

IV. Fundamental Expectations

1. Reliability: scheduled server uptime = 99.99% or better for email and all components included in proposal

2. Performance: Normal email IMAP response < 1 second to open 10k message; subsecond response time for routine functions of all components included in the proposal

3. Capacity: capable of handling current load

4. Scalability: able to increase capacity economically and without significant service interruption

5. Integration with current environment and infrastructure: including directory, authentication, authorization, and possibly calendar

6. Manageability & ease of use: minimal administrative & support costs

7. Low Total Cost of Ownership: including software, hardware, implementation, training and ongoing support

V. Email

The University email service must be capable of supporting 50,000 user accounts, of which 40% are used weekly or more frequently. IMAP, POP, and Web access must be available for all users of the email service.

Please describe how your proposed system would meet each of the needs listed below.

A. Email End-User Features

1. End-User Narrative

1.1. Dedicated Clients

1.1.1. If your proposal includes a dedicated email client other than the POP/IMAP/SMTP clients listed in the Current Environment section, please detail how its capabilities, use, and supported OS platforms differ from your responses concerning those POP/IMAP/SMTP clients.

1.1.2. Are the Microsoft Outlook (Windows) and Entourage X (Macintosh) clients fully supported, and in which versions on which platforms? If not, which features are not supported or partially supported?

1.1.3. Describe your support for MAPI.

1.2 Web-mail interface

1.2.1. Please compare the Web email interface to your preferred dedicated client, in terms of performance and features.

1.2.2. Does the Web-mail interface require Java? JavaScript?

1.2.3. Does the Web-mail interface work with browser pop-up blocking enabled?

1.2.4. Does the Web-mail interface use IMAP or POP protocols, or does it use other methods? Please describe the rationale for other methods. If it uses IMAP, does it keep a persistent connection alive throughout the session, or does it reconnect and re-authenticate each time the user requests an action?

1.2.5. In the Web-mail interface, describe when and how attachments are opened. Is it possible for the user to adjust this setting?

1.2.6. Describe any address book features available in the Web-mail interface.

1.2.7. Describe how deletion occurs in the Web-mail system.

1.2.8. Describe the flexibility in branding the Web-mail interface. Please provide an example.

1.2.9. Are there ways to use PGP, S/MIME, or similar encryption built into the Web-mail interface?

1.2.10. What browsers and versions do you support?
If a browser is "supported" with less than full functionality, please specify what features don't work.
Describe the necessary browser standards requirements and browser configurations required by your product.

1.3. In addition to features listed in the following tables, are there any other end-user account management (self-help) features available to users of dedicated clients? For users of the Web-mail interface?

1.4. Address book

1.4.1. Describe address book, OS integration, and portability or synchronization across multiple clients and user workstations.

1.4.2. Is user address book stored on server, client workstation, or both?

1.4.3. Is there support for shared address books, both in dedicated clients and Web-email interface?

1.4.4. Ability to create groups of recipients?

1.5. Anti-spam Features

1.5.1. Describe any features provided by the service to block, tag, discard, or route spam to an alternate mailbox. These may include use of SMTP server rules, black lists, independent modules such as Pure Message or Spam Assassin, etc. This may be part of the email service or may be obtained separately.

1.5.2. What independent modules can be used successfully?

1.5.3. Please describe the user interface and the controls available to each user

1.5.3.1. How does a user specify what spam messages should be deleted, delivered to the Inbox, and delivered to a separate spam mailbox?

1.5.3.2. What control does the user have to handle different types of spam by different rules?

1.5.3.3. Can user “train” the system, to distinguish spam and wanted messages based on personal preferences or examples? Do the “learned” rules apply across clients and platforms?

1.5.3.4. Describe how the user creates and manages white and black lists. Do the settings apply across clients and platforms?

1.5.4. Do all user spam settings automatically apply across all clients, including the Web email interface?

1.5.5. If a spam mailbox is supported, how long are messages retained?

1.6. PDA and mobile device access:

1.6.1. List which PDAs, phones, and other mobile devices can be used with your email service.

1.6.2. Does the service send new messages generated by the PDA and process changes to existing mail on the service?

1.6.3. Can the user specify rules for forwarding some messages to pagers or to SMS-enabled mobile phones?

1.6.4. Does use of a PDA require connection to a workstation, or does the PDA function independently via modem or wired or wireless network interface?

1.6.5. Describe any Wireless Application Protocol (WAP) or microbrowser (PDA or phone) features of the email service. Are the features included with the service or purchased from third parties?

1.7. Describe any unified messaging features.

1.8. Describe integration of the features in this section with other services in your proposal.

2. End-User Checklist

	End-User Checklist
#	Feature	Feature is Supported (Y/N)	Product(s), Version(s), date available	Additional Vendor Response
2.1	Dedicated Email Client
2.1.1	IMAP protocol interoperability: The email service must comply with RFC 3501 and related RFCs, included by reference.
2.1.2	POP protocol interoperability: The email service must comply with RFC 1939 and related RFCs, included by reference.
2.1.3	SMTP Protocol Interoperability: The service must comply with RFC 2821 and related RFCs, included by reference
2.1.4	POP3, IMAP4, and SMTP client support Although we would like to converge on one client in the future, the proposed system must offer full support, with excellent performance and reliability, for existing clients. Are all of the clients listed in Current Environment section fully supported by your product? List any other email clients, platforms, and versions that your email service supports.
2.1.5.	Address lookup for dedicated email clients is integrated with existing Open LDAP directory
2.1.6	Newsgroup reader is included with dedicated email client
2.2.	Web Email Client
2.2.1.	Web interface provides 100% of the features and capabilities available to users of dedicated client.
2.2.2.	Web email client works with same mailboxes as dedicated or IMAP client; Web-mail interface is able to access all mail folders, not just the INBOX.
2.2.3.	Web-mail interface fully supports IMAP folder nesting (folders within folders).
2.2.4.	Web-mail interface fully supports all valid IMAP mailbox names.
2.2.5.	If a dedicated email client is provided, it and the Web email client utilize the same address book.
2.2.6.	Web email interface fully supports Web browsers, platforms, and versions listed in Current Environment section.
2.2.7.	Web-mail interface requires no protocol or port other than http and https.
2.2.8.	In the Web-mail interface, folders are available for drafts, sent messages, and deleted messages, and the folders are the same ones seen from dedicated IMAP clients.
2.2.9.	We want to encourage students to use the University’s email service. Can the Web-mail interface access mailboxes from IMAP or POP accounts outside the proposed system?
2.2.10.	Web email user can append a “signature” (typically containing contact information of the user) on selected outgoing email messages.
2.2.11.	Web email user can change the name that appears in the “From” field.
2.2.12.	Web email user can choose (or change) address that appears in the “From” field, allowing what is currently defined as email delivery address (e.g., jsmith@uvm.edu) or alias (Janet.Smith@uvm.edu).
2.2.13.	Web-mail interface supports the ability to attach and send files as MIME attachments.
2.2.14.	Web-mail interface can receive MIME attachments, and provides a means to save attachments as files on the client system.
2.2.15.	User of the Web-mail interface can choose to display and forward full message headers.
2.2.16.	User of the Web-mail interface can choose to get an audio or a visual notification of the arrival of new mail.
2.2.17.	The Web-mail interface is compliant with the Americans with Disabilities Act.
2.2.18.	Address lookup for Web email interface can be integrated with UVM's current Open LDAP-based directory server.
2.3	Email-Borne Virus Handling
2.3.1.	User controls whether messages in which the system has detected and removed viruses are to be delivered or automatically deleted.
2.4.	Filters and Rules
2.4.1	Proposed system supports system-wide email filters (rules).
2.4.2.	Proposed system supports user-defined filters (rules), stored on server and automatically effective across multiple workstations and client software, including Web-mail interface.
2.4.3.	Email filters (rules) use the Sieve standard (if system uses another rule definition language, please note).
2.4.4.	Per-User Mail Blocking: the user can prevent email from an email address from arriving in their mailbox.
2.4.5.	Users can subscribe to administrator-defined filters, including option for user-controlled parameters.
2.4.6.	Users can filter based on all or part of text in all standard headers (including To, From, Subject, Reply-to, CC, BCC, Date), e.g., to send messages to a user-specified folder.
2.4.7.	Users can filter based on hidden X-headers.
2.4.8.	Users can filter based on all or part of text in message body.
2.4.9.	Users or support staff can view a log to see filter actions, such as what folder messages are saved to, and to where messages were forwarded.
2.5.	Autoresponder/Vacation Message Utility
2.5.1.	System provides self-service (user initiated and user-configurable) automated response message (vacation message) for users of dedicated clients and users of the Web-mail interface.
2.5.2.	Automated response message is set and configured by same means for users of dedicated clients and Web-mail users.
2.5.3.	Service avoids mail loops when autoresponding.
2.5.4.	The autoresponder can be set to only respond to email received after this date or before this date.
2.5.5.	The autoresponder action can be modified based on fields in the mail header.
2.5.6.	The frequency with which it responds to mail from the same sender can be changed.
2.5.7.	The autoresponder can be set to reply to or ignore messages with "Precedence: junk" or "Precedence: bulk" in the header.
2.5.8.	The autoresponder can filter incoming email messages for separate actions. For instance, an email from oskibear@uvm.edu would get one reply while an email from calbear@uvm.edu would get another reply.
2.5.9.	The autoresponder can be set to respond to or ignore messages with the account name or additional specified names in the "To:" versus "Cc:" fields.
2.5.10.	Users or support staff can view a log to see autoresponder actions.
2.6.	Automatic Forwarding
2.6.1.	The email service can be configured by the account holder to automatically forward incoming email messages to another address.
2.6.2.	The service supports forwarding to multiple destination addresses.
2.6.3.	The service supports forwarding to multiple destination addresses based on user-specified rules.
2.6.4.	The service prevents email loops due to forwarding.
2.6.5.	Email forwarding is set and configured by the same method for users of dedicated clients and Web-mail users.
2.6.6.	Email forwarding is effective for all messages sent to the user, across multiple workstations and client software, including the Web-mail interface.
2.6.7.	Email forwarding can be set to only respond to email received after this date or before this date.
2.6.8.	Email forwarding action can be modified based on fields in the mail header.
2.6.9.	The system can filter incoming email messages for separate actions. For instance, an email from oskibear@uvm.edu would be forwarded to one address, while an email from calbear@uvm.edu would go to another address, or email with “urgent” in the subject line would be forwarded to a mobile phone or pager.
2.6.10.	Users or support staff can view a log to see forwarding actions.
2.7.	Sign On and Authentication
2.7.1.	The system uses a single username and password for all functions and clients.
2.7.2.	The system gives access to all functions with one authentication per session (single sign-on).
2.8.	Other Self-Service Features
2.8.1.	System provides self-service password changes (initial, forgotten, and routine) for users of dedicated clients and users of the Web-mail interface.
2.8.2.	System provides self-service message and mailbox restoration or recovery for users of dedicated clients and users of the Web-mail interface.
2.9.	Other Features
2.9.1.	Message delivery status notification (confirmations or receipts) for sent and received messages with all supported client software, including the Web-mail interface.
2.9.2.	A group of users can share a mailbox collection, with concurrent read-write access to the same mailbox (for example, an administrative assistant previewing an executive’s incoming messages, or a service department sharing the task of responding to customer email).
2.9.3.	No administrator or user action is required to share an account’s mailbox among multiple users; multiple users simply open any mailbox to share it.
2.9.4.	When users concurrently share a mailbox, message status indicators (new, read, replied, forwarded, deleted, etc.) are updated in near real-time for all users. Messages added or deleted are reflected in the views of all users concurrently working with the shared mailbox.
2.9.5	User can queue message for later delivery (e.g., to provide opportunity to revise or cancel message before it is sent)
2.9.6	Users can take back (undeliver) messages they’ve sent.

B. Email System Architecture

1. System Architecture Narrative

1.1. Describe the architecture of the proposed system, including a diagram of the major components.

1.1.1. Which aspects of UVM’s current environment would remain; which would be replaced?

1.2. Authentication & directory integration

1.2.1. Can we use our existing directory service for the proposed email service?

1.2.2. Can we use one of our existing authentication services (Open LDAP, Active Directory, or Kerberos) for the proposed email service?

1.2.3. We use Kerberos for authentication. Do you have support for both plain-text Kerberos and gssapi (using a service ticket)?

1.2.4. List any LDAP attributes that are required for the proposed email service, and describe the way that the LDAP attributes listed are used.

1.2.5. Describe what impact the proposed email service will place on the university directory servers. At a minimum, include the following:

1.2.5.1. Describe how authentication would integrate with our current environment, including a detailed description of the authorization process.

1.2.5.2. The attributes and associated conditions where the email service will write back to the university directory server.

1.2.5.3. The expected access rate for reads and writes that the proposed email service will place on our university directory server given a proposed email service that serves the number of simultaneous connections listed in Current Environment section.

1.2.6. Can all user password changes occur via the University’s Open LDAP authentication service?

1.2.7. If the proposed system requires a separate directory, provide specific details on any necessary software structure used to transparently populate the email directory service from the university directory server. For example, XML interface, Perl script, none needed, etc.

1.2.8. Describe in detail and include as part of the proposal any software structure programming or configuration necessary to provide the translation between the proposed email directory service and the university directory server.

1.3. Open source/proprietary software

1.3.1. List the parts of the service that are built with open source components and which parts are closed source/proprietary.

1.4. List supported operating system platforms for the proposed email service software.

1.5. To what extent is the system modular, and do communications between components use Internet standard protocols, e.g. the Web-mail service could be replaced by another, or the SMTP server could be replaced by another, etc? Please note which components are interdependent.

1.6. Security: The email service must provide security features including secure connections, authentication before relaying mail, and virus protection support.

1.6.1. Describe the security features of your service. Describe any included host-based or network-based IDS (intrusion detection system).

1.6.2. List the authentication methods supported for each applicable system component.

1.6.3. Encryption

1.6.3.1. Note the areas where encryption is or can be enabled, including the encryption mechanism and strength of encryption.

1.6.3.2. Note the components that will function in an encrypted environment.

1.6.3.3. Are passwords sent in clear text over the network?

1.6.3.4. Is the service HIPAA (Health Insurance Portability and Accountability Act of 1996) compliant?

1.7. Scalability of System Architecture

1.7.1. Describe how the proposed system would scale to handle three times our current volume with no decrease in performance

1.8. Redundancy

1.8.1.1. Redundancy is required of all major components in the service, including the network interfaces.

1.8.1.1.1. Describe the redundancy of each component in the email service.

1.8.1.1.2. Are service component spares enabled automatically upon failure of the primary component or service?

1.8.1.1.3. Is Administrator notification automatic upon failure of any component or service in the email service?

1.8.1.1.4. State the notification methods available.

1.8.1.1.5. When a message storage system server component fails, will the storage still be automatically accessible from the other message storage system server(s)without human intervention on either the server or the client?

1.8.1.1.6. After an email service component failure, do the transactions that were in progress at the time of the failure continue processing without any intervention (such as a server reboot) necessary by the administrator?

2. System Architecture Checklist

	System Architecture Checklist
#	Feature	Feature is Supported (Y/N)	Product(s), Version(s), date available	Additional Vendor Response
2.1.	If a message is to be delivered to multiple recipients, only one copy is stored in the message storage system, and the metadata for each of the recipient accounts is updated showing the new message.
2.2.	All services (Web-mail, IMAP, etc.) are able to activate/deactivate as needed without affecting other email services.
2.3.	All email services integrate with UVM’s existing authentication and authorization services

C. Email System Administration

1. System Administration Narrative

1.1. Virus Protection: Anti-virus software may be part of the email service or obtained separately. The University of Vermont requires that there at least be hooks in the software for an anti-virus package.

1.1.1. Diagram and describe how anti-virus software works in your solution.

1.1.2. Specify all locations in the life cycle of an email message where viruses are detected.

1.1.3. Is the anti-virus software packaged with the email solution or is it available as an add-on feature?

1.1.4. If there is more than one anti-virus software package that can work with your email service package, list the anti-virus software packages that will work with your email service.

1.1.5. Update process: Describe the process by which virus database files are updated.

1.1.6. It is preferred that virus-laden messages are blocked during the SMTP dialogue. Cleansing by deleting the virus, but still sending the mail is a less desirable solution. In addition to end-user control (see End-User Checklist, above), can the handling of cleansed messages be controlled by system administrators?

1.2. Account creation and removal

1.2.1. Describe how creating and removing accounts would be automated, and how these processes would integrate with our current environment.

1.2.2. How would system implement graceful and client-friendly account termination (e.g., upon graduation)?

1.2.3. Detail the ability to suspend or lock some functions while keeping others open (e.g., email, Web publishing, file storage, autoresponse, forwarding).

1.2.4. Which functions can be managed via a command line interface, and which via a GUI? Which must be managed by command line? By GUI?

1.3. Dynamic Load Balancing: Describe how this balancing is done among server loads, among shared disk space, among any routing devices, and among any paths between the components on the email service.

1.4. Message Queuing: Describe and diagram the message queuing system provided by your service. Describe whether your service includes multiple timed queues, where messages are retried at successively longer intervals.

1.5. Error Message Generation

1.5.1. Describe the standard error messages generated by the email software and the types of errors that trigger these messages.

1.5.2. If the email software has a customizable API for error message generation, note that here and discuss this API's salient features.

1.5.3. If the email software has any other way to customize the error messages displayed or logged, note that here and describe the details of how this customization is accomplished.

1.6. Remote Management of Servers

1.6.1. Describe the software and network management that can be performed remotely.

1.6.2. Describe the hardware management that can be performed remotely.

1.6.3. Describe the methods of remote access.

1.7. Mail Relay Blocking: The email service must prevent unauthorized open mail relaying as designated by the email administrator.

1.7.1. Describe the different types of mail relay blocking supported.

1.8. Address Harvesting: Describe the mechanism that the email software uses to block address harvesting.

1.9. Delivery Status Notification: Describe how the email service provides delivery status notification that the administrator can turn on/off, if necessary.

1.9.1. Can the setting be varied on a user-by-user basis?

1.9.2. Can the setting be varied by class of service or service level for a group of users?

1.9.3. Can users control it themselves?

1.10. Quota Administration

1.10.1. Please describe how the proposed service manages quotas and how quotas are enforced. Can or must a quota apply to all mailboxes in aggregate, or to particular mailboxes?

1.10.2. Describe how the email service administrator would assign mailbox storage quotas to classes of user mailboxes and override quotas for individual users.

1.10.3. Does the system allow quotas by:

1.10.3.1. Maximum Mailbox Size - the maximum size allotted to a mailbox

1.10.3.2. Maximum Size of Message Allowed - the largest message size that can arrive in a mailbox

1.10.3.3. Quota Threshold - point at which warnings or throttling measures on the account are taken

1.10.3.3.1. Describe how quota threshold warnings are communicated to the user. Describe any throttling measures.

1.10.3.4. Can quotas be set from LDAP fields?

1.10.4. Delegation of Quota Administration: Describe how the service allows the email administrator to delegate the administration of quotas for selected user accounts to designated quota managers

1.11. Message Store System Disaster Recovery: The email service must provide an easily recoverable message store system.

1.11.1. Describe how the proposed system would be restored, and how long it would take, under scenarios ranging from the failure of a single disk in the message store to loss of the entire email system.

1.12. Describe what would be necessary to have two copies of the mail store in separate locations.

1.12.1. Describe what would be needed to keep the two copies in-synch at all times, and what that would cost.

1.12.2. Describe alternate methods which could have a backup copy slightly behind the main mail store, but so that it could take over in a catastrophe while losing only a few minutes of mail. What would this cost in terms of additional equipment and in terms of the effect on system performance?

1.13. Message Aging: Describe how the email service supports message aging.

1.14. Shared Email Folders: Are shared folders available in your service?

1.14.1. Can individual users create them?

1.14.2. Describe how to mail to a shared folder and how a user accesses a shared folder.

1.15. System Administration Management

1.15.1. Granular Delegation of Administration: Does the proposed email service allow for granular delegation of account management tasks by central email administrators to specified account managers? Describe in detail the ability of your service to delegate administrative authority, and the granularity to which such delegation can be done.

1.15.1.1. Describe if this assignment can be made on the basis of LDAP attributes from the main university directory service.

1.15.1.2. Describe the account management tasks available. Can the administrator delegate the following account management tasks to personnel with lesser authority?

1.15.1.2.1. Configuring mail forwarding for the managed user

1.15.1.2.2. Configuring vacation autoresponder for the managed user

1.15.1.2.3. Configuring email filtering for the managed user

1.15.1.2.4. Changing user mailbox storage quota values

1.15.1.2.5. Purging of trash and spam/virus/junk mail folders

1.15.1.2.6. Restoration of email folders from backup

1.16. Ease of Administration: Describe any features that automate or facilitate management of the proposed system, including: number of machines needed to run the email service, complexity of email function setup, tools used to administer, and employees required to handle all functions of the email service.

1.16.1. Specify the number of full-time employees required to do administrative tasks, based on our current environment. Break down this description by:

1.16.1.1. Number required for installation, and a description of their tasks

1.16.1.2. Number required for system maintenance and a description of their tasks

1.16.1.3. Number required for account maintenance and a description of their tasks

1.17. Basic Administration

1.17.1. Describe how to perform basic administrative functions such as creating, inactivating, deleting, and renaming an account.

1.17.2. In renaming, are the folders and metadata, e.g. IMAP flags and data, preserved? Is the password or authentication preserved?

1.17.3. Describe what happens if someone mails to an inactive account.

1.17.4. Describe what happens if someone tries to read mail in an inactive account.

1.18. Multiple Domains

1.18.1. Can more than one domain be controlled from the centralized servers (for example, uvm.edu and catamountclub.org)?

1.18.2. Sub Domains: Does the email service allow subdomains to be created (for example, uvm.edu would have two separate distinct sub domains of collegeA.uvm.edu and collegeB.uvm.edu that can be manipulated as separate entities)?

1.19. Identity Management

1.19.1. Multiple Email Addresses for One Account: State if the email service allows a user account to have more than one email address associated with it (for example, sailing@uvm.edu and sailing.club@uvm.edu would appear in the directory and would be mapped into the same account).

1.20. Accounting Module: Describe any billing functions including charge-back functionality at an individual and class of service level.

1.21. Bulk Mailing: Describe any capabilities of the service to perform bulk mailing to accounts on the service.

1.22. Global Message Filtering: Describe any APIs (application program interfaces) available for the email service. Note any performance issues due to the API itself.

1.22.1. Of particular interest is ability to allow blocking the message, blocking the sender, or allowing it to be accepted.

1.22.2. Deletion of an Email Message: Can the administrator delete a single or several email messages from the email service, either in the SMTP stage or from the message store?

1.23. System Logging

1.23.1. List the errors and administrative items logged by the email system.

1.23.2. Is it possible for the administrator to turn on complete logging of an email session, showing each command executed and the results of the command?

1.23.3. Logging must be at least as complete as that of open source mail systems like those based on Sendmail. Describe how easily changeable the log levels are.

1.24. Statistical Gathering: Describe the tools in the proposed email package that provide an aggregate total of quantity of certain email functions. Include a list of the statistics gathered and if the timing intervals for monitoring these totals are configurable by the administrator.

1.25. Backup Software Support: Describe if and how the proposed system would work with UVM’s existing backup environment, or what would be required to back up the proposed system. If you recommend or require a different backup system than our existing Legato Networker system, please specify and describe.

1.25.1. Describe how operational recovery of small amounts of data (e.g. specific mailboxes or messages) differs from techniques/tools used to perform recovery for all mailboxes in the event of a disaster.

1.26. Postmaster email handling: What functions does the system provide to help administrators manage the high volume of messages to postmaster or an abuse-reporting address?

1.27. Inactive Accounts: We grant accounts to admitted students (who may not come to UVM), to recent graduates, and to others who may discontinue accessing their account. These accounts continue to accumulate email from list servers and spam. We need to limit the amount of space consumed by unused accounts. How would the proposed system handle inactive accounts?

VI. Additional Functions

The University will consider proposals for functions closely related to email services, when the additional functions bring greater integration, utility, and return on investment.

A. Calendar, Group Scheduling, Personal Task Management

The current Oracle Calendar system is meeting our functional needs. However, two units rely upon Microsoft Exchange for their calendaring, email and other needs. While the use of separate email systems does not present an unacceptable barrier, not easily being able to schedule meetings between the Oracle and Exchange users can be a significant problem. The University is willing to consider a replacement for Oracle Calendar if the new product would:

effectively provide all of the features of Oracle Calendar;
provide significantly better features, user interface, and integration; and
allow us to use the same calendar for the entire university.

1. Calendar Narrative

1.1. We want to have a single calendar system that serves all UVM faculty and staff – and potentially all students -- for purposes of group and individual scheduling. We would prefer a single calendar system that could be accessed from Outlook/Entourage, the Web and (optionally) any supplied custom client software.

1.2. We do not wish to lose existing functionality of our email and calendar implementations.

1.3. Please compare your proposed calendar, group scheduling, and personal task management (to-do list) software to Oracle Calendar, including functions and platform support. You may wish to refer to “Oracle Collaboration Suite Oracle Calendar,” found online at http://otn.oracle.com/products/ocal/html/datasheet_ocal.html or to the calendar-related items in “Oracle Collaboration Suite (Release 2) Datasheet,” at http://otn.oracle.com/products/cs/pdfs/cs_datasheet.pdf.

1.4. Describe other features of the proposed system that are not available with Oracle Calendar.

1.5. If there is a dedicated client program, in what ways is it integrated with your dedicated email client, if any?

1.6. Exchange integration and interoperation:

1.6.1. Does the proposed calendar system integrate with Microsoft Exchange calendars?

1.6.2. Is the interaction real-time, via email, or by some other means?

1.6.3. Can one immediately confirm that there are no conflicts when creating a meeting?

1.6.4. How would one schedule a meeting to include people and resources in an Exchange calendar and your proposed calendar system?

1.7. Are the Microsoft Outlook (Windows) and Entourage (Macintosh) clients fully supported, and in which versions on which platforms? If not, which features are not supported, or are partially supported?

1.8. Web calendar interface

1.8.1. Please compare the Web Calendar interface to your preferred dedicated client, in terms of performance and features.

1.8.2. Does the Web calendar interface require Java? JavaScript?

1.8.3. Does the Web calendar interface work with browser pop-up blocking enabled?

1.8.4. Describe support for subscribing to calendars, such as an institutional calendar of events.

1.9. PDA and mobile device access

1.9.1. List which PDAs, phones, and other mobile devices can be used with your calendar service.

1.9.2. Can the user specify rules for sending some meeting notices to pagers, or to SMS- or IM-enabled mobile phones?

1.9.3. Does use of a PDA require connection to a workstation, or does the PDA function independently via modem or wired or wireless network interface?

1.9.4. Describe any Wireless Application Protocol (WAP) or microbrowser (PDA or phone) features of the calendar service. Are the features included with the service or purchased from third parties?

1.10. System architecture

1.10.1. Describe the architecture of the proposed system, including a diagram of the major components.

1.11. Authentication & directory integration: If not the same as your email proposal:

1.11.1. Can we use our existing directory service for the proposed calendar service?

1.11.2. Can we use one of our existing authentication services (Open LDAP, Active Directory, or Kerberos) for the proposed calendar service?

1.11.3. Describe how authentication would integrate with our current environment, including a detailed description of the authorization process.

1.11.4. List any LDAP attributes that are required for the proposed calendar service, and describe the way that the LDAP attributes listed are used.

1.11.5. Provide specific details on any necessary software structure used to transparently populate the calendar directory service from the university directory server (for example, XML interface, Perl script, none needed, etc).

1.12. List supported operating system platforms for the proposed calendar service software, if not the same as your email proposal.

1.13. Scalability of System Architecture: The calendar service as proposed must handle 4,000 users, and must be able to scale efficiently to 15,000 users as usage grows with no loss in performance. Show the hardware configurations for 4,000 users and 15,000 users.

1.14. Redundancy: If not the same as your email proposal:

1.14.1. Please describe reliability and redundancy features of the proposed architecture.

1.14.2. Are service component spares enabled automatically upon failure of the primary component or service?

1.14.3. Is administrator notification automatic upon failure of any component or service in the email service?

1.14.4. State the notification methods available.

1.15. Account creation and removal

1.15.1. If calendar accounts are different from email accounts, describe how creating and removing accounts would be automated and would integrate with our current environment.

1.15.2. How would the system implement graceful and client-friendly account termination (e.g., upon graduation)?

1.15.3. Which functions can be managed via a command line interface, and which via a GUI? Which must be managed by command line? By GUI?

1.16. Error Message Generation

1.16.1. Describe the standard error messages generated by the software and the types of errors that trigger these messages.

1.16.2. If the software has a customizable API for error message generation, note that here and discuss this API's salient features.

1.16.3. If the software has any other way to customize the error messages displayed or logged, note that here and describe the details of how this customization is accomplished.

1.17. Remote Management of Servers

1.17.1. Describe the software and network management that can be performed remotely.

1.17.2. Describe the hardware management that can be performed remotely.

1.17.3. Describe the methods of remote access.

1.18. Calendar System Disaster Recovery: The calendar service must provide an easily recoverable storage system.

1.18.1. Describe how the proposed system would be restored, and how long it would take, under scenarios ranging from the failure of a single disk to loss of the entire calendar system.

1.19. Describe what would be necessary to have two copies of the calendar data in separate locations.

1.19.1. Describe what would be needed to keep the two copies in-synch at all times, and what that would cost.

1.19.2. Describe alternate methods which could have a backup copy slightly behind the main data store, but so that it could take over in a catastrophe. What would this cost in terms of additional equipment and in terms of the effect on system performance?

1.20. System Administration Management

1.20.1. Granular Delegation of Administration: Does the calendar service allow for granular delegation of account management tasks by central administrators to specified account managers? Describe in detail the ability of your service to delegate administrative authority, and the granularity to which such delegation can be done.

1.20.1.1. Describe if this assignment can be made on basis of LDAP attributes from the main university directory service.

1.20.1.2. Describe the account management tasks available. Can the administrator to personnel with lesser authority delegate the following account management tasks?

1.20.1.2.1. Configuring authority over resources

1.20.1.2.2. Configuring agenda delegate rights

1.21. Ease of Administration: Describe any features that automate or facilitate management of the proposed system, including: number of machines needed to run the service, complexity of calendar function setup, tools used to administer, and employees required to handle all functions of the calendar service.

1.21.1. Specify the number of full-time employees required to do administrative tasks, based on our current environment. Break down this description by:

1.21.1.1. Number required for installation, and a description of their tasks

1.21.1.2. Number required for system maintenance and a description of their tasks

1.21.1.3. Number required for account maintenance and a description of their tasks

1.22. Basic Administration

1.22.1. Describe how to perform basic administrative functions such as creating, inactivating, deleting, and renaming an account.

1.22.2. In renaming, are the agenda entries, tasks lists, and other user data preserved? Is the password or authentication preserved?

1.22.3. Describe what happens if someone tries to schedule a meeting with an inactive agenda.

1.23. System Logging

1.23.1. List the errors and administrative items logged by the system.

1.23.2. Describe how easily changeable the log levels are.

1.24. Backup Software Support: Describe if and how the proposed system would work with UVM’s existing backup environment, or what would be required to back up the proposed system.

1.24.1. Describe how operational recovery of small amounts of data (e.g. specific agendas or task lists) differs from techniques/tools used to perform recovery for all data in the event of a disaster.

1.25. We populate numerous Web-viewable event calendars automatically from Oracle Calendar. Please describe how we would accomplish that with your calendar system.

1.26. Describe integration with other services in your proposal.

2. Calendar Checklist

	Calendar Checklist
#	Feature	Feature is Supported (Y/N)	Product(s), Version(s), date available	Additional Vendor Response

Email, Personal Organization, Calendar, Collaboration, and Communication Systems Request for Proposals

Dedicated Email Client

Web Email Client

Other Self-Service Features

Email, Personal Organization, Calendar, Collaboration, and Communication Systems
Request for Proposals