E-mail Use, Procedures and Policies
November 24, 2002
Bruce Campbell Engineering
Marko Dumancic Environmental Studies
Bill Ince Math
Mike Kerrigan Federation of Students
David Kibble IST
Rob Hiscott Arts
Dawn Keenan IST
Ken Lavigne Registrar
Neil Murray Human Resources
Req Quinton IST
Carol Vogt IST
Charles Woods Library
The Ad Hoc Committee on E-mail Use, Procedures and Policies was formed in May 2002. The
goal was to offer an overall strategy for the evolution of this crucial service and to ensure that it
evolved in such a way so as to support UW's current and future directions for its use in teaching,
learning and administrative functions. Electronic mail has truly changed the way in which our
society communicates. In recent years, email has grown into a full-fledged communications
medium. It has become a vital tool in business processes and a key method to communicate and
collaborate with friends, family, co-workers, classmates and instructors. This broad usage places
increasing demands on the time that individuals spend in that activity and in the infrastructure and
management needed to support it.
The committee's mandate was to review all aspects of e-mail use on campus and make
recommendations that would improve on existing services and ensure that we are positioned for
proposed business uses, the generally anticipated growth in use, prepare for unknown changes
in a global context and clarify unknowns that might be present on campus in the area of policies
and guidelines. In so doing, the committee undertook a broad based review of current and
planned email usage on campus, current best practices as well as changes in technology and
This review demonstrated UW's already long history of use and reliance on email. It revealed
both a distributed support model with a solid infrastructure that supports its use. Nothing in the
review indicated that a major overhaul of UW's approach or existing email facilities was warranted
at this time. There is no concern in existing facilities not being able to grow to meet the basic
requirements placed on them. It did however show that there are services that will require
additional support, enhancements to be made and efficiencies that will be essential to realize if
email is to remain a productivity tool as well. It is safe in this case to recommend that an
evolutionary change and specific set of upgrades to our services, rather than a revolutionary
approach, will be sufficient. A number of specific recommendations if followed will serve to meet
those pending concerns and objectives.
The committee recommends several interrelated projects and measures that will provide support
and guidance for e-mail initiatives at UW. The core areas and summary of these follow:
A clear acknowledgement that this is a vital community resource and the priority it deserves
in the overall campus computing support scheme. In various ways and means, email has
established itself as a formal method of communication and required the same resources
previously devoted to other hardcopy correspondence or equivalent electronic
communications (eg. phone)
UW should continue to follow its distributed model for support and services, acknowledging
those inherent strengths and weaknesses. In general, existing campus groups provide a
suitable forum for ongoing discussions and monitoring of this service. Further interaction with
major campus-wide projects (eg. SISP, Portal, CECS.Online) will also ensure requirements in
those areas are met.
Continue with and advocate existing efforts in such areas as deployment of tools to deal with
SPAM, which has become a growing concern on campus. Other efforts include virus handling
at the desktop and server level, simplification of mailer and desktop tools, expansion of the
web mail facility, and its use in workflow in IS administrative areas. These may also be
included in the set of tasks assigned the working group.
An interim working group be established to carry forward a series of small projects and
enhancement activities. These would include:
o Establishing a complete online web resource for email. This would document our overall
email model and facilities available for campus users and provide such information as
support policies, account provision, best practices, links to faculty and central resources,
bulk mail guidelines, etc.
o Development of a framework for bulk mailing and mailing lists, including appropriate
documentation, mail list tools, approval mechanisms
o Address data integrity issues through a thorough documentation of data flows and an
identification of any bottlenecks in those processes.
Establish an upgrade charter for UWDir. This project must take into consideration a number
of factors, including its use as an authentication vehicle, the basic directory function,
complete set of community held within it’s database, a more robust technical environment
and ancillary services it provides (eg. voting lists, class list distribution).
The committee believes that implementation of these recommendations will effectively support
the existing and expanding role of email at UW.
The Ad Hoc Committee on E-mail Use, Procedures and Policies was commissioned in response
to growing questions surrounding the current usage of email on campus and a desire for
preparedness to meet what appeared to be ambitious plans and expectations on the part of
various constituent groups. E-mail is a core communication medium, facilitating contact between
the campus and external groups (eg. donors, prospects, employers), in the teaching and learning
process (eg. between students and between students/professors), and in business
communication. It provides for ability to reach large, varied and distant groups, and provide more
timely communications than previously possible. It is in broad use on campus already, and has
filtered into everyday life. In a sense, email has reached maturity. Access is pervasive, most
members joining UW have prior accounts, the only exclusions are in specific populations and
industry segments, well documented in current government literature and university experience.
The committee noted no major concerns set forth in its mandate, i.e. there was no crisis in our
campus situation. Rather, there is a need to deal with specific issues and questions, a proactive
step to ensure viability of future service.
The methodology employed began with a generalized view by committee members and their
respective constituencies of issues and information relevant to the review process. This was
enhanced by a general solicitation of feedback from their constituent groups. This committee
included broad representation of faculty and academic support users, along with representation
from computing support staff responsible for email services across campus. Feedback from the
remainder of the campus was solicited where appropriate. From this initial overview, the
committee held a series of meetings that covered the following topics:
A confirmation of the group’s mandate, refinement of scope and general familiarization and
confirmation of known issues.
Review of the technical architecture on campus, desktop and server software, responsibilities
of various groups and the support model. Appendix A contains a link to a summary of this
An examination of specific issues as identified by the committee or set forth in the original
mandate from UCIST. These included but were not limited to UWDir, data synchronization
and integrity, Spam, viruses, privacy and security, bulk mailing.
Functional requirements for various groups on campus were gathered. This was done
through a survey and via other feedback received from various departments. A link is
provided in Appendix A for this information.
Lastly, the group examined issues and developed suggestions related to various policies.
This was done by using existing and relevant UW documents and a study of several external
samples and resources and policy statements from peer institutions.
Once the group had gathered and completed this exercise, recommendations as had been noted
were confirmed. A final examination of general questions concluded the group’s work.
The following is a summary of the group’s investigations, not meant to be an exhaustive list of
findings. It represents the key points and those relevant recommendations or conclusions where
no action might be required.
There are currently over 500 mail servers running on campus. In general, a few key servers
handle the bulk of the load, including admmail for the majority of academic support staff and one
or more mail servers maintained by each Faculty and the Library for their use. There are
specialized servers in place as well, including those for the alumni “mail for life” program, the
retirees machine, and specific departmental machines in academic units used for research and
Majordomo is currently the primary tool for managing mailing lists, some options like Mailman
have been investigated. Majordomo presents several limitations, including an awkward
administrative interface and no integrated web interface or archival facilities. There is a mailing
list archival facility (MhonArc).
UWDir provides the campus with a mail forwarding service based on a userid and uwarterloo.ca
suffix. This directory merges several sources of data, from Registrars, HR, telephone services
and allows users to maintain an authoritative email address for themselves. This info is
subsequently exchanged with other systems. Other services provided by this central directory
include authentication and class lists. Over a one-week period, it receives over 500000 total
queries from mail servers across campus. The sendmail-UWDir interface is an add-on patch to
sendmail, as compared to the LDAP mail lookup code that is integrated in the source from
Through the Nexus effort, web access using the Endymion Mailman is now available as a web
front end to email. IMP is available through both Nexus and xhier to most Solaris Unix servers on
campus. Most users are currently using IMP versus the Endymion Mailman to read their mail over
Many mail servers use a combination of procedures to filter incoming email on campus. Procmail
is used to deal with dangerous attachments. Sendmail (8.9 and higher) is configured to reject
email from non-Waterloo hosts that are blacklisted by publicly available sources. SpamAssasin
uses context sensitive parameters and textual analysis to tag undesirable email, the destination
for which may be at the choice of the recipient.
In general, our server software is not designed for large volumes of outgoing mail. There is a
machine on campus, “bulkmail”, with a configuration more geared to handling these large
volumes. This setup involves minor changes in the config file and in queuing strategies.
Responsibility for student and faculty facilities on campus lies with the faculties. IST provides
support to their computing units and for academic support departments. Individual units may opt
to run their own email servers. There is distributed use with central support for key components
such as IMAP and POP. Sendmail is the primary engine used to deliver email.
Access & User Support
Each faculty maintains a web site with information for students and those services it provides. IST
has offered courses in email usage and a general FAQ of material on its own site for users. An
email account is available and provided for those where their mission at the university requires
such access. This includes all registered students, faculty and most staff. There are some
exceptions to this which would need to be addressed should this vehicle be used for specific
business processes (eg. pay notifications), though this also raises broader implications for
electronic access in general for these individuals. Not all services are “identical”, local variations
do exist in disk quota for example. In some cases, clients have an option of the type of service
used. For example, in engineering, students can us a simple Netscape/Eudora POP or webmail
clients, or they can use IMAP configurations with procmail filters and other utilities. These are not
viewed as a hindrance to those staff at this time. Access is not guaranteed 24x7, i.e. there is no
dedicated or specific on-call support, though it is routinely available during most hours of the day.
The campus will want to communicate with additional groups, though this does not necessarily
imply providing an account.
This has grown from basic “directory” phone book service to components that include a directory,
source for class lists, authentication vehicle, and email forwarding. UWdir will likely require some
significant re-engineering to provide it with a more robust technical environment and deal with the
increase in scope of use in nature and in volume. Access to user information will require finer
controls and information (eg. coop status, graduation information). If the generic address
uwaterloo.ca address is used more extensively, the forwarding capability will be stretched. More
data will be required to track users forever as they move from being an applicant prospect to a
potential donor phase in their involvement with UW. Additional information and processes will be
required to assist with the human matching problem that arises from unavoidable timing issues in
the feeds of data from various sources. Currently, CSO/PH is the underlying technology, an
evolution to LDAP under ADS (W2K) planned. Moving to LDAP will reduce the level of
customization required to maintain the mail server software. This change would move the single
point of failure from the current UWDir server to a W2K server. Query loads average 7-9 per
second, that figure is significantly higher at peak times.
Functional Issues and Requirements
The basic functional requirements gathered for email service focused on 2 main areas according
to the survey conducted. Full details are found in the link in Appendix A. One dealt with individual
tools, their utility and ease of use. This study did not deal with basic “mailer” functionality, UW
does not build or maintain client software as such. Sample requirements more related to our
implementation included an ability to deal with vacation notifications, filtering SPAM, IMAP versus
POP advantages, the advertising presence within some vendor products. The desire for broader
web access was notable. Also notable was the use in general workflow within our major
information systems efforts. One ongoing problem area was performance on various mail servers.
This should improve when a mailbox format change is introduced (i.e. to the Cyrus system that
uses a private mailbox database that is significantly faster for large mailboxes).
Mass or “broad” communications represented the key concern in most areas. Potential uses were
many, including the handling of admissions queries and early communications with prospects.
During the peak application process for example, approximately 5000 emails per day will be sent
over a 6-day period. It also included library solicitations for feedback on service levels, coop
interview notifications, distance education assignment correspondence and alumni newsletters.
Mailings to “lists” can be considered as personalized (individual content) though done in large
groupings, solicitations for feedback (through a formal survey or otherwise), marketing and other
broadcast information and mass notifications of important events. Email is but one alternative for
these services. Portal technology, web services, other vehicles like the Daily Bulletin, and
hardcopy may be more suitable and are all alternatives for these. There is a need to balance
such items as the intrusion factor with the effectiveness often seen in these notices. Other
general requirements included some interesting in attachments, though it was viewed as better to
insert a link to a resource than a document where practical.
Bulk Mailing and Mailing Lists
Mailing lists themselves are characterized by those with a specific mandate or target audience
(though not necessarily a static list) or those used for broader communication. The formers are
often developed for a specific project or local collaborative group, manually created by an
individual. They may also be smaller lists that can be predefined, such as class lists. The latter
are often larger, sometimes random samplings or one-time mailings for a specific purpose.
Typically, these mailing have been accomplished through a Word merge, though other
departments such as CECS have begun use of alternative tools. Other specific requirements for
bulk mailing facilities need further definition (e.g. an archive of "broadcast" messages that could
The campus has a general set of policies that cover access to all of these lists, this usually
implies consent at the faculty Dean (Associate Dean, etc.) or from HR, the Registrars office or
other unit responsible for that group. These are all documented in university policy, though the
process may not be well understood.
The largest roadblock to more extensive use of email is the accuracy of info maintained on email.
These addresses are developing a similar importance to physical address information, but they
remain a more transient commodity. Individuals routinely use more than 1 account, their
preferences change over time. An emphasis must be placed on the collection at strategic points
for this information in our contact with students in particular, and in a PR effort to maintain such
information. This is further complicated by the fact that many of these are beyond our control, not
UW provided. A recent view of recorded addresses in Trellis yielded less than half as UW in
nature. Synchronization across multiple databases maintained with email remains an issue,
though using the UWDir or uwaterloo.ca address can alleviate that problem. Startup issues
remain for various groups, new employees individually or for new recruits.
Spam and Viruses
In general, nothing is done for virus checking by default. System administrators can employ
defanger, procmail and sanitizer to remove offending files. Periodic scans of Netapp devices are
run in some cases. Significant dollars would be required for tools improvements at the server
level. On the desktop, virus handling is a more global issue, though email remains a primary
vehicle in the spreading of viruses. There is a need to promote the use of anti-virus software
which is readily available (i.e. Norton), ensuring that individuals aply patches and upgrades to that
software. There is an ongoing need to educate the community in the handling of attachments.
SPAM is a widespread problem, one that not only UW experiences. Recent statistics revealed
that in over 1000000 messages received, barely 500000 were legitimate, one quarter were SPAM
or from blacklisted sites, the remainder were relays or contained other problems. SpamAssasin
and blacklists through sendmail are in place on ist, admmail, perhaps later on watserv1, some
facilities have also been implemented in the faculties. These tools are generally viewed as
sufficient, but there is a need to promote and deploy the “procmail sanitizer” and SpamAssasin
more widely, i.e. a full implementation of their functionality and on a broader set of servers.
Additional education and documentation for new or incoming sysadmins would assist that
process. There are some customizable features not being used, improvements to server
architecture and/or performance may be needed to realize these.
A wide variety of desktop mailers are in use on campus, including Outlook, Pine, Netscape,
Eudora, webmail and others. In principle, consolidation on software already on the desktop at no
additional cost, or through the web may be preferable. Other additional requirements include
those related to “public” access, for general use and for specific situations such as access for
campus hosted conferences and their registrants.
Section I - Policies & Practices
General Management Principles & Statements
1. UW should issue a statement acknowledging that electronic mail is an important medium
for communication. The use of this medium by students, faculty and staff is encouraged
for scholarly, work-related and personal communication within the constraints, standards
and responsibilities laid out in university policy. Sufficient resources shall be dedicated to
maintaining an acceptable level of service.
2. The current distributed support model for both the technical architecture and support
services be maintained. Existing groups such as CNAG and CSAG be used as a forum
for ongoing dialogue on matters as they pertain to email use.
3. UW will continue to provide an account for each member of its community, where
required by their role. In the case of students, this need not be their “official” email
account. The designation of official is held as the address noted and maintained in UWDir
(and transmitted with various information systems that may hold a copy of that
information). User responsibilities must be established in ensuring an appropriate
address at which communications can be received.
4. Email may be considered a form of “official” communication to the university community
or a subset thereof. Such a designation or methodology should have the approval of the
appropriate faculty Dean or an Associate Provost as is appropriate. Principles of due
diligence in that specific delivery or other forms of alternative notices would need to be
included in such a designation.
5. Emails that might be considered a formal document be archived in an appropriate
repository (to be established) in order to meet audit and related requirements of future
examination. Principle similar to those required for paper records be followed.
6. Policies related to lists, survey approvals etc. are in place. While email represents a
unique medium for communication, it should follow those established guidelines.
Operations Support and Guidelines
7. Support levels should be in keeping with nature of email as a critical resource, not as with
“phone” service, but vital to its own right. This does not imply equity of service in the
matter of quotas, etc.
8. Core software on servers should be up to date.
9. The Statement on Use of UW Computing and Network Resources provides a basic
framework for email usage within the overall computing resource access. It may be
prudent to establish further guidelines that would cover acceptable use, and cover such
items as valid purpose and uses, representation, personal use. It may also cover
Security, Privacy, Compliance, Archiving, Audit
10. There was no indication that encryption was required at this time, nor was any need
found for registered email (or a receipt / acknowledgement process). This situation
should continue to be monitored. Email privacy tools (such as pinepgp) are available but
not in use to the committee’s knowledge.
11. Outside regular system backups, email record retention remains primarily a user issue or
that for a specific department depending on business needs. Email archiving may offer a
preferred route to quotas and other manual cleanup requirements on the part of user; this
should be investigated as well.
Section II - Projects and Action Items
12. A project should be formed to upgrade or replace UWDir and its service for email address
resolution. Issues there would include a more robust technical environment, perhaps a
relational database as a backend, emphasis on interfaces to and from, authentication
(already underway), integration of new groups (alumni, etc.) and a PR effort to simplify
and make users aware of facilities.
Bulk Mail and Lists
13. Initiate a project to investigate and subsequently implement a new tool to manage mailing
lists. This should provide basic management capabilities, a web interface, import
functions, etc. There should be a web-based interface for both mailing list owners and list
14. A project must be established to provide a comprehensive framework and suite of
services to handle mass mailings. This should include guidelines for approvals, handling
features for returned mail, approval process, bulk mail process and server requirements,
practices and alternatives (approved and recommended uses). This would not
necessarily result in the promotion of bulk mailings, but rather make most efficient use of
resource available to perform those mailings that are appropriate and warranted.
Emphasis should remain on effective communication through most appropriate vehicle
15. IST should implement a web-based mail solution for the campus. This should be done in
close conjunction with the uPortal effort.
SPAM and Related Topics
16. SpamAssassin must receive a broader implementation across the campus. A global
implementation of this and related products now in use should be initiated. Increased use
of its capabilities should be made a priority. This may require enhancements to some
17. Increased consistency in the use of virus checking tools is necessary across campus at
the server level. An increased awareness program is required at the user level for
desktop tools to ensure software is installed, configured correctly and kept up to date.
Users need to be made aware of dangers present in email and a policy established to
require a basic compliance in that setup and installation.
18. The university must ensure that both servers and workstations connected to the network
are equipped with comparable software for virus checking for servers and workstations
as is appropriate in each case. Owners should be required to exercise due diligence in
using tools and practices in keeping with a level of service commonly agreed to.
Education & Documentation
19. Establish a comprehensive web based collection of information on email. This would
include links to faculty specific resources, information on utilities (vacation, forwarding,
attachments, writing style), information on bulk mailings, policies, etc., user
responsibilities, details in use of links versus attachments, etc.
20. Processes surrounding account creation along with userid creation be reviewed with IS
project teams, CHIP, etc. to streamline those processes, reduce duplicate entry and
21. A number of new options for operating systems and hardware platforms (e.g. Linux) that
can support and provide a cost-effective email service are now available. Support for
email services is currently biased towards Solaris. UW in general offers a variety of
support levels for operating systems. In general, for Linux, it relies primarily on vendor
supplied software. A balance will need to be struck between all aspects of implementing
a critical resource such as email on a new platform, including our ability to support all
architectures equally. A standard for email service must be adopted, noting the key
functionality that is required and the consistency across architectures that may be
22. The university establish a core set of supported desktop tools, preferably those already
installed on the desktop and at no cost from the vendor (e.g. Outlook) and enhance the
existing web mail offering.
23. A review of required authentication practices, blocks and procedures for public stations
Appendix A - Links to Web Resources
Committee Information - Internal Submissions
Sample Email Policies and Practices
UW Provided Services and Documentation
Related UW Policy
Appendix B – Electronic Mail Policy & Guideline Template
1. General Provisions
Definitions & Scope
Law and Policy
2. Allowable Use
3. Guidelines and Tips
4. Privacy and Confidentiality
Access without Consent
Privacy Protection & Limits
Authentication and Authorization
Recovery & Audit
6. Retention and Archiving
Appendix C – Sample Mass Mailing Policy Template
1. General Policy Statement
(eg. appropriate working relationship with target group, definitions of unsolicited email)
2. Individuals Covered
(eg. university community, allowable receipt from external agencies and groups)
3. Electronic Mail Systems Covered
(eg. servers and originating domain name)
4. Approval Mechanisms
(eg. grid outlining target group, authority, use)
5. Chain Letters
(eg. invalid regardless of purpose)
6. Broadcast Messages
(eg. urgent matters)
7. Distribution Lists
(eg. one way communication, “opting out” functionality)
8. Discussion Lists and Groups
(eg. two way communication, list owners, course bulletin board)
(eg. Listserv Mailing Lists, Web Page Services, UseNet News Services)
10. General Concerns
(eg. resources required, balancing intrusion with efficiency)
11. Appeals & Legal Context
(eg. relevant Bills, faculty procedures)
12. Relationship to Other Policies
(eg. overall computing use, system administrator responsibilities)
Appendix D – Sample Guidelines