Recommendations for Email at UCSB –
Early History

In the Summer of 1993 a group of computing professionals began meeting regularly to identify a set of goals for electronic mail at the University of California, Santa Barbara (UCSB). In early 1994 the resultant set of goals was presented to the campus and, specifically, to the Academic Senate Committee on Computing, Information Technology and Telecommunications Policy.

A group of volunteers was enlisted to focus on each of the electronic mail goals. Each volunteer group was to create a summary of the current situation at UCSB with regard to the specific goal. This summary document was distributed campus-wide in the Fall of 1994.

Following the assessment of the current situation each volunteer group proceeded to create a recommendation for the accomplishment of their specific goal. This document contains these recommendations.

We forward these recommendations to the campus community, the Academic Senate Committee on Computing, Information Technology and Telecommunications Policy and the Campus Networking Committee in the hope that others will support our effort and propose these recommendations be implemented.

Goal 1

Each member of the campus community (Students, Faculty, and Staff) should be registered with a unique electronic mail address. This address should be used for communications to conduct University business. University business encompasses all activities which support the mission of the University which is research, education, and service to the community.

Workgroup Leader

Mike Stevenson, Student Information Systems

Present Student Email Uses

1. MCL (Micro Computer Lab) provides Email accounts for all undergraduates (about 9,000 of 15,000 have activated their account).
2. Computer Center's (CC) Unix system provides over 1,000 Email accounts for graduate students (out of over 2,000 graduate students).
3. A number of other campus systems provide Email to some undergrads and graduate students (Engineering, Graduate School of Education, etc.) When students have a second account, the MCL and CC recommend students setting up a special command to have all MCL/CC mail forwarded.
4. The Student Access Project provides a process for all students to be assigned Email addresses that are stored in each student’s record. This is in preparation for being able to Email to specific sets of students.

5. A few courses now require students to use Email as part of their course activities.
6. In the Spring of 1995 NETSTATIONS from the Student Access Project were used for ASB and Graduate Student Elections. This use included the Emailing of election information to all potential voters as well as Emailing to all students who voted, a Thank You Note (which was used to verify the student voted).

Present Faculty and Staff Email Uses

1. College offices in coordination with academic-department systems and regional systems provide Email services to most UCSB full-time faculty.
2. Some faculty members (usually with administrative responsibilities) have mainframe PROFS Email.
3. A few faculty use Email presently within their instructional responsibilities.
4. Most faculty use Email within their research/public-service responsibilities.
5. UCSB's PROFS system provides over 1,000 staff with Email (and calendar) services.
6. Email has become an essential tool for most professional staff. Email provides quicker, more accurate (at least more consistent) information flows. This has the effect of improving Staff effectiveness and efficiency (less meetings and more responsive service).
7. Many UCSB departments are presently conducting University business via Email (room reservations, event planning, work order requests, etc.).

Summary

While a few other Universities (UC Irvine) have "E4E" (Email For Everyone) programs, UCSB is moving relatively quickly toward this goal. However, there remains a lot of Email infra-structure building to do that is crucial before Email can truly be depended upon to conduct University business. Specifically, goals #3, #4, #5, #6, and #7 are all required while goals #2 and #8 are desirable before UCSB conducts its everyday business using Email.

Recommendation

UCSB students should be able to send (and receive) Email to (from) UCSB departments. UCSB departments should create (and publicize) a "departmental Email address" for student use. For example, academic departments might do this for advising/appointment/ general-information needs.

While students should be able to access UCSB offices, similarly approved UCSB offices should be able to send Email to specific sets of students in order to provide services. Through this type of Emailing, students should be sent notes whenever their record changes (for example: grade changes and financial aid application status changes).

Students should be able to contact their professors via Email whenever the professor wants to allow this. And professors should be able to Email (gopher/web tools are recommended instead of Email for all but special information needs) their students.

Special tools are needed to allow approved faculty and/or staff to create appropriate Email distribution-lists. These tools should be available via UCSB's STAR system.

UCSB departments should start conducting University business using Email and other electronic tools.

A new, on-line data-base of Email addresses for all UCSB Faculty and Staff should be accessible by all UCSB professionals. UCSB's Communications Services department is presently paying for the development of this type of data-base as a more timely source of data than the printed Campus Directory. Summer 1995 completion is planned for this data-base. After this data-base is created, then on-line access to this needs to be developed.

Computer applications should be developed to support interaction between both the Personnel database and the Email address database to allow the creation of Email distribution-lists for use by approved professionals. For example, an Email distribution-list of handicapped employee working on-campus should be available as well as a distribution-list of all MSOs.

Goal 2

Provisions should be made for the handling of electronic mail addressed to those unable to access their electronic mail for a period of time (vacation, leave, etc.).

Recommendation Submitted by

The Electronic Mail Discussion Group

Discussion

During the discussion related to this goal two issues emerged:

• Retention of undelivered mail
• Notification to the sender that their intended recipient may be unavailable

Recommendation

We recommend that those using electronic mail systems be notified, and perhaps reminded regularly, regarding the retention period for undelivered mail. This task should fall to those providing the electronic mail service.

We recommend that those using electronic mail systems able to provide this feature be notified of its existence and the necessary training and customer support be provided to encourage its use.

As electronic mail systems which do not provide this feature are replaced we recommend that this capability be included in the list of requirements for the replacement system.

Goal 3

Access to electronic mail should be governed by policies on ethical behavior. The policies contained in the Student Conduct Handbook and the UCSB Policy and Procedures Manual should be updated in relation to this goal.

Workgroup Leader

Neil E. Villacorta, Facilities Management

The crafting of a philosophy governing access to and use of UCSB computing resources is an incredibly arduous task, especially when trying to balance the academic mission of a university and the realities and vagueness of the law today.

Currently, there are two major philosophies, regarding access to electronic files:

1. Right to privacy for individuals
2. Right to protection of the sponsoring institution

The assumption of only one of these rights will lead to policies that are not in balance with each other. Moreover, for every right listed, there are corresponding responsibilities for both the individual and the institution.

Currently, UC Office of the President (UCOP) is discussing the classification of Administrative versus Academic (and perhaps Student) Email with separate policies for each. Unfortunately, there are numerous "gray area" communication scenarios that limit such simple classifications. We must, however, be prepared to modify our policies or defend our philosophies if and when UCOP enacts its own policies.

Educom’s "Rights and Responsibilities for Electronic Citizens" was used as a guideline in the crafting of the proposed philosophy along with a template of relevant issues from the University of Kentucky.

In light of pending policies on electronic mail originating from UCOP, it would not be prudent to initiate a UCSB specific policy regarding electronic mail.

Included in Appendix 1 are five general principles along with a list of known violations to the principles that may not only guide UCOP in crafting a University-wide policy, but may in the interim, serve as general guidelines for UCSB.

Recommendation

The "Philosophy Governing Access to and use of UC Santa Barbara Computing Resources" document be submitted to Dave Sheldon as our campus representative to a UC committee discussing policies regarding electronic mail.

An ongoing committee be created to implement and monitor adherence to electronic mail usage policies developed at UC Office of the President and at UC Santa Barbara.

Goal 4

Electronic mail systems should allow the exchange of mail between everyone on campus. We recommend that the Simple Mail Transfer Protocol (SMTP) be the standard for the exchange of mail between different systems.

Recommendation Submitted by

The Electronic Mail Discussion Group

Recommendation

The SMTP protocol is widely used within UCSB for the exchange of electronic mail. We encourage, and recommend, its continued use in this manner.

As electronic mail systems which do not support SMTP are replaced we recommend that this support be included in the list of requirements for the replacement system.

Goal 5

Electronic mail addresses should be easily determined if one knows the person's name. People should be able to maintain a unique electronic mail address, but a standard form of electronic mail address should be able to get mail delivered to them. We recommend that the standard form for UCSB be: FIRSTNAME.LASTNAME@UCSB.EDU.

Recommendation Submitted by

• Lou Browdy Accounting
• Ron Dolin, Graduate Student Computer Science
• Larry Murdock, Psychology
• Terri Jo Ortega, English Department
• Vince Sefcik, Communications Services
• Jamie Sonsini, Information Systems & Computing

We considered a "service" which would respond to electronic mail addressed to "firstname.lastname@ucsb.edu." If "firstname.lastname" matches an alias entry this mail would then be delivered to this individual (at their preferred electronic address). If "firstname.lastname" does not match an alias entry a mail message would be returned indicating that "firstname.lastname" was not a match and suggesting other "near matches" (together with these individual’s preferred electronic mail addresses).

For example, mail sent to "jamie.sonsini@ucsb.edu" would be delivered. But, mail sent to "sons@ucsb.edu" would generate an automatic reply like:

Your mail addressed to "sons@ucsb.edu" could not be delivered. Other mail alias[es] which nearly matched your address are:

Alias	Address
jamie.sonsini@ucsb.edu	9531sons@ucsbvm.ucsb.edu
ann.sonstelie@ucsb.edu	ch05sons@ucsbvm.ucsb.edu

The target audience for this service would be individuals off-campus or individuals on campus who are not able to find an address for someone else on campus. We believe current efforts in the directory services area should minimize the need for individuals at UCSB needing such a service. We want to stress that this address is an "alias of last resort" and not intended to be a person’s one and only electronic mail address.

We separated our discussion into two sections: one having to do with the "firstname.lastname" part of Goal #5, and the second having to do with the "UCSB.EDU" part of Goal #5. We apparently felt no need to discuss the "@" sign.

1. FirstName.LastName

   The use of one’s "Firstname" brings up several problems to be solved.

   1. Some individuals do not use their (real) firstname but may use their middle name as their first name (e.g. M Lou Browdy).
   2. Others use a nickname (e.g. Vince Sefcik) instead of their first name.
   3. And others (like Terri Jo Ortega) have spaces in their first name.

2. UCSB.EDU

   We identified a set of requirements for a system providing the service outlined above. These requirements are:

   1. The system must be reliable and stable (a production system).
   2. There must be a long term commitment to providing this service.
   3. The operational procedures of this system must be arrived at by consensus of the campus customers of this service.
   4. The system must be scaleable (must scale up well).
   5. The funding of such a system should not be affected by funding fluctuations from research grants etc.

Recommendation

We suggest that we use a "Commonly used first name" in our "Firstname" field and allow individuals to change this value. Some review of these names will likely be necessary to avoid inappropriate names being used.

With regards to names (both first and last) which contain spaces we suggest that all spaces be removed ("Terri Jo" would become "TerriJo"). We recommend that names consist of alphanumeric characters only.

We recommend expanding already established data bases which contain the names of individuals who are students at UCSB (the Student database) or employed at UCSB (the Payroll Personnel System, PPS) to also contain an individual’s preferred electronic mail address and their commonly used first name. These fields should eventually be changeable by the individual. The data from this source could then populate the "firstname.lastname@ucsb.edu" service.

Since some individuals are employed at UCSB and are also registered as students we recommend that the Student database information (and the associated preferred electronic mail address) take precedence if an individual does not select otherwise.

Since the Center for Computational Sciences and Engineering (CCSE) is already managing a system (hub.ucsb.edu) which is registered as UCSB.EDU we suggest they be asked to provide the service described and meet the requirements listed.

Goal 6

There should be an online directory service that is available to people who want to find someone’s electronic mail address. Responsibility for maintaining up-to-date information in the directory should be defined. Features should include:

1. Directory entries should exist for individuals as well as "functions" (identified entities like a department name or position).
2. The service should be able to resolve address conflicts (e.g. differentiate between two people with the same first and last name).
3. Provide for electronic mail distribution lists with "standard" names (e.g. ALL_MSOS, ENGLISH_101_STUDENTS).

Recommendation submitted by

The Electronic Mail Discussion Group

The Sources

Our recommendation focuses on creating reliable sources of accurate directory information on which service providers can create a variety of directory services. These directory service providers may generate services for different segments of the UCSB community.

In the document below we identify and discuss the Student database and the Payroll Personnel System (PPS). The Office of the Registrar is the office of record for the Student database. There are three offices responsible for UCSB directory type information in PPS: Personnel Services, Academic Personnel Services and Payroll. Personnel Services is responsible for staff and staff student job title code positions, Academic Personnel is responsible for Faculty and academic student job title codes (TA’s, etc.) and the Payroll department is responsible for payroll information.

The office of record for these, and other additional databases, would need to provide the means by which departments (or, perhaps eventually, individuals themselves) may update this information to keep it timely and accurate.

The Services

With an accurate, reliable and timely source of information which includes electronic mail addresses and commonly used first names others at UCSB can choose to construct "directory services." Those creating a directory service would need permission from the office of record to access the fields they desire.

These service providers would then extract the relevant information from the source databases mentioned above (using one or both of the access methods mentioned below) and offer their service to the campus or segment of the campus they choose.

Some, of course, are well understood to have responsibilities in this area and these "well known sources of directory information" would be encouraged to use the database information mentioned above. In this manner any campus, divisional, departmental or individual directory service should, at least, have the same basic information about an individual and their electronic mail address.

Recommendation

The Student database and the Payroll Personnel System should be modified to contain an electronic mail address and a "commonly used first name" for each individual in that database.

Information from each of these databases should be accessible via a flat file interface or from an SQL query. Both interfaces should be supported.

Those providing directory information at UCSB should use the sources identified above for their directory services.

Goal 7

A means of guaranteeing the authenticity of mail, using evolving standards, should be implemented.

Recommendation Submitted by

• Ben Humphrey, Computer Science
• Kevin Schmidt, Social Sciences Computing
• Alan Stebbens, Center for Computational Sciences and Engineering
• Mark Schildhauer, Subcomm. Chair, Social Sciences Computing

Charge

The Discussion Group's immediate concern is that this workgroup clarify the current status of this issue on campus.

1. Current Status of Email Authentication at UCSB

   There is currently no "campus" standard or plan for ensuring the authenticity of Email transactions. There may be groups using proprietary mail solutions which include authentication and some individuals may be taking advantage of several existing methods to ensure authentication of mail between themselves and other cooperating parties, but we do not believe either of these methods is currently widespread at UCSB.

2. Discussion
   1. Other important related Email security issues

      We feel that security of information systems should be a major concern for UCSB. Authentication of Email, however, only addresses the question of guaranteeing that a note is indeed from the person it appears to be from. There are several other extremely important security issues relative to Email. These issues must be addressed if UCSB intends to carry on official and other administrative work via Email.

      Important security issues include:

      1. Authentication of origin (as mentioned in the draft document): To guarantee that the document did indeed come from the apparent sender. Can involve use of 'digital signatures'.
      2. Message integrity: To determine that the contents of the document has arrived intact and unaltered.
      3. Confidentiality: Transmit the document encrypted over the network, such that only recipients with appropriate authorization can read/decrypt it.
      4. Nonrepudiation by recipient: Provides mechanism for guaranteeing that intended recipient has received and 'processed' the message.

      These items above are all logical components of a comprehensive Email security scheme. The first 3 items are addressed by several existing or proposed Internet protocols. The last entry is not commonly addressed in these protocols, at least relative to the Internet, but the other protocols may be sufficient to provide this if a cooperative model is assumed (that is, the recipient complies with a scheme to assure receipt of message).

   2. Status of Internet mail standards relative to Email security

      The developing standard for secure Email via SMTP on the Internet is defined by RFC's 1421-1424, and called the Privacy Enhanced Mail (PEM) protocol. This standard is still evolving under discussion by working groups on the Internet Engineering Task Force. PEM provides for authentication, integrity, and encryption (items a-c above) of mail. PEM can be viewed as the still emerging, but jure standard for secure Internet Email.

      There is currently much discussion over how PEM services might be incorporated into the more general MIME standard (RFC 1521), which defines how multipart textual and non-textual message bodies are formatted for enclosure within Internet mail. MIME is an acronym for 'multipurpose Internet mail extensions'. The latest working document on this is the Internet draft 'draft-ietf-pem-mime-07.txt', date 11/94, expiring 5/95. This document specifies, among other things, how PEM security services can be applied to a MIME message body part.

   3. Implementations of secure Email

      We are unaware of any software that provides for both MIME and PEM capabilities today. In fact, there is a lack of software that provides for full PEM capability alone. One exception to this is TIS/PEM. Unfortunately TIS/PEM is only available for use in the USA and Canada, and hence inappropriate for foreign correspondence. Furthermore, the source code currently integrates well only with the Rand MH mail agent system. In addition, TIS/PEM is not widely used at this time.

      Another PEM-style solution is RIPEM, which however only provides a subset of PEM capabilities (lack of key certification being an issue), and again is only for use in the United States and Canada.

      A third Email security solution is PGP, which stands for 'Pretty Good Privacy'. This is currently by far and away the most widely used security solution for Internet Email. It is not PEM compliant, however, and until recently was hampered by some alleged patent violation issues relative to its source code. There are now however, versions of PGP freely and legally available for use in the USA (e.g., PGP 2.6.2). The legal status of the international version (e.g., PGP 2.6.i) is less clear, due to potential USA and Canadian export restrictions on cryptographic technology. Nevertheless, PGP is widely used in Europe and throughout the world and is the de facto standard for secure Internet Email.

      One interesting recent development relative to PGP is a new Internet working draft, dated 95Jan, expiring 95Jun30, on 'PGP Message Exchange Formats'. This document likely has emerged in response to 1) the de facto prevalence of PGP as an Internet Email security solution; 2) the recent resolution of legal concerns relative to USA patenting issues for certain cryptographic algorithms used in PGP; and 3) the failure of PEM to emerge as a fully implemented Internet solution despite ongoing discussion for several years. This may then represent a first step towards defining PGP as a 'competing' Internet security solution to PEM.

Final Statements

There is currently no clear solution for a broad scale implementation of secure Email systems at UCSB, since the standards themselves are still under discussion. The PEM standard continues to be worked over by IETF workgroups, most recently with regards to incorporation into the MIME standard--a document which is now in draft 7. At the same time the most popular method for transacting secure Email over the Internet, PGP, is now cleared of some of the legal ambiguities that once precluded its endorsement as a solution for UCSB. An Internet working draft describing the PGP standard was recently released--a first time in formalizing the PGP protocols for official adoption as an Internet standard for privacy.

In any case, implementation of PEM/PGP-style solutions is not trivial since these services are not fully integrated into any of the popular mail user agents at this campus. There are also other issues that must be worked out if UCSB is to deploy a PEM-style strategy for ensuring the privacy, integrity, and authentication of official Email transactions. Perhaps most acute of these is the need for a Certifying Authority (CA)--an official organizational body responsible for vouching for the authenticity of individual’s public keys.

Recommendation

We feel that the campus should approach these issues through experimental implementations of existing methodologies involving small test groups on campus. Small groups in need today of secure Email could theoretically implement any of several solutions without too much effort. At the same time, campus working groups must keep abreast of the standards that are still evolving relative to the IETF and IAB. We should implement solutions here at UCSB cautiously during this period in order to remain flexible for adopting a fully 'Internet-compliant' solution if and when one becomes prevalent.

It is also worth noting that the implications of these security measures extend beyond simple SMTP Email transactions. Privacy and authentication are important components of any service in which confidential, financial or other official information is transacted over the increasingly popular and convenient "Internet."

Goal 8

Electronic mail systems should support the exchange of non-text mail, for example, multimedia objects like sound, pictures or video.

Work Group Leader

Dan Ringwald, Instructional Resources

Multimedia Definitions

At this point in time multimedia Email at UCSB is a rare breed. There are some Unix Email products being used. There are Apple and PC products in the works but very little usage at the moment. I have sent requests to CSF, UCSD, UCSC, and others, on this topic, and have received very little in replies. This is probably because so few are up and running at this level. We should also try to define different levels of providing multimedia information so individuals may see at what level they would like to participate. Multimedia is a medium for providing sound, picture, graphics, video and text. Below are a few beginnings of definitions that relate to multimedia and networks.

Multimedia Documents

This is currently being done from programs such as word-processing and spreadsheets. Microsoft, Wordperfect, and Lotus have current features for providing this technology. Multimedia documents can be attached to Email files and passed along local area networks and enterprise networks like the Internet. The current 10Mbps speed is fine because this is not real-time.

Multimedia Email

This is the ability for Email to handle multimedia objects directly in the mail product without the need to attach a file. It should also have the ability to attach multimedia files. Mime, used in the emerging Email products, is for the purpose of handling multimedia objects. Microsoft Mail currently does not offer Mime. Apple's System 7 Pro offers PowerTalk and incorporates Mime. This is state of the art multimedia Email for local area networks. Apple also offers PowerShare which is a server base application for delivering enterprise wide PowerTalk multimedia Email. PowerTalk is a technology for creating and passing multimedia in the Email, not just attaching document files that contain multimedia objects.

Multimedia Email Gateway

Starnine offers a gateway for linking PowerShare to the Internet. There is extensive information on Apple's gopher sever about this technology and PowerTalk. Instructional Development Computer Services has conveniently downloaded and categorized a small portion of this information, on ID's gopher server. It is located in ID's gopher server under the folder instructional resources\engineering services\computer services\multimedia Email\apple press releases. We will continue to add information on multimedia Email in this area.

Multimedia in Real Time

This is what is known as video conferencing. Apple's PowerTalk will probably turn in to a real-time product of some sort in the future. A real-time product is worth mentioning because they will eventually have the ability to capture and pass a video conference as an Email. This would be used in situations when a current connection cannot be made due to a busy line or no one at the other end. The current limits for this are the campus ethernet, broadband, and Internet speeds. We are operating at about 10Mbps and the ability for real-time multimedia or video conferencing demands about 100Mbps. This will be realized with the implementation of FDDI and ATM. As the ability for compressing video increases the demand for bandwidths of 100Mbps is coming down. The campus currently does not have a fiber backbone for distributing FDDI or ATM. At this point departments are linking fiber networks that can deliver these technologies. We are also seeing what looks like extensive linking via fiber on a departmental level rather than a common backbone. There is currently a common campus fiber backbone in the works. Intel ProShare is an example of a product that operates at 10Mb and provides video conferencing and document sharing. Capturing and passing a conference as an Email is in the works. Instructional Resources is currently in the process of purchasing and testing the Intel ProShare product line. This can be used on a LAN or and ISDN phone line.

Recommendation

Mime is the recommend standard which should be adhered to when considering any multimedia Email products. UNIX, Apple, and the PC compatibles are all migrating to the Mime standard. Mime can handle multimedia objects and is emerging as a standard for this purpose.

Appendix 1

Two Basic Rights

Access to computing resources is granted to an individual by UC Santa Barbara solely for the grantee's own use. Every user of UC Santa Barbara computing resources has two basic rights regarding computing:

1. Privacy
2. A fair share of resources

It is unethical and a violation of this policy for any person to violate these rights.

All users, in turn, are expected to exercise common sense and decency (due to regard for the rights of others) with respect to the public computing resources, thereby reflecting the spirit of community and intellectual inquiry at the University. Access is a right that may be limited or revoked if an individual misuses the right or violates applicable University policies or state or federal laws.

Principles Governing Use of Computing Resources

1. User access is granted to an individual and may not be transferred to or shared with another without explicit written authorization by the appropriate system administrator.

   This principle is intended to protect the integrity, security, and privacy of your account. Sharing access with another individual undermines the security of your account, leaving it vulnerable to abuse by others. By not sharing your account, you protect against unauthorized activities on your account, for which you would be responsible. You may be charged with a violation if someone uses your account with your permission and violates policy. Just as important, sharing or transferring access jeopardizes the security of the entire computing system because it weakens one of the "links" in the system "chain."

2. User access to computing resources is contingent upon prudent and responsible use.

   Imprudent use of computing resources can lead to consequences affecting many other users, not just yourself. For example, not using virus protection software on networked microcomputers could allow the introduction of a virus that could destroy the work of many other users.

   Prudent and responsible use begins with common sense and includes respect for the rights and privacy of other users. For example, as a prudent and responsible user, you should:

   1. Not share your account with any other user.
   2. Protect your password by choosing it wisely, keeping it secure, and changing it regularly.
   3. Back up files on a regular basis to ensure the safety of important data in the event of a system failure.
   4. Log off your account when leaving.
   5. Always use virus protection software.
3. The user may not use computing resources for any illegal or unauthorized act; in particular, the user may not use computing resources to violate any state or federal laws.
4. The user may not use computing resources for any commercial purpose without prior written authorization from the appropriate system administrator.

   Work under approved University contracts and grants is covered under the usual internal approval processes, which serve as the requisite "prior written authorization."

5. Computing resources must be shared among users in an equitable manner. The user may not participate in any behavior that unreasonably interferes with the fair use of computing resources by another.

   Computing resources are finite and must be shared. During periods of peak demand, facility staff may enforce guidelines to require sharing resources for the benefit of everyone.

   Examples of unreasonable interference include, but are not limited to:

   1. Playing games for recreation when another user needs the resource for more scholarly activities.
   2. Exceeding established disk space, time, or other allocations
   3. Intentionally running programs that attempt to execute endless loops.
   4. Printing large jobs during periods of heavy computer use.
   5. Printing multiple copies of a document.

Some Examples of Violations

This section of the Policy consists of a list of several activities that you cannot or should not do. While these are not all of the possible violations, there are still many more things you can do than things you can't do. This list is intended to inform you and to reinforce the principles of fair and responsible computer use that we seek to engender at UC Santa Barbara.

Violations of these principles or any attempt to violate these principles constitutes misuse. Violations include, but are not limited to:

1. Sharing passwords or acquiring another's password without prior written authorization from the appropriate system administrator.

   The consequences of sharing your password can be significant for the system and for you as well. This action leaves you vulnerable to such things as impersonation by another user.

   However, even if you are not concerned about the safety of your own account and data, you have a responsibility to other users to help maintain the security of the system. Your responsibility is like that of a tenant in an apartment building. Though the tenant may not be concerned about his or her own apartment, feeling that it contains little or nothing of value, he or she still has a responsibility to the other tenants to keep the main entrance secure.

   On occasion, you may want to share files or data or Email with other users. For information on how to do that safely, contact your system administrator.

2. Unauthorized accessing, using, copying, modifying, or deleting of files, data, userids, access rights, usage records, or disk space allocations.

   You are authorized to access, use, copy, modify, or delete files, data, or access rights on your own account as specified. You are not authorized to perform any of these functions on another user's account or a University system unless specifically given permission by the account holder, your job description, a designee, or the appropriate system administrator.

   A person who finds a door to another's home unlocked does not have the right to enter the home simply because it is unsecured. Similarly, the fact that someone's account and its data are unprotected does not mean that you have the right to access it.

3. Accessing resources for purposes other than those for which the access was originally issued, including inappropriate use of authority or special privileges.

   User privacy is not to be violated; all users are to be protected from unauthorized activity by a system administrator or other users.

4. Copying or capturing licensed software for use on a system or by an individual for which the software is not authorized or licensed.

   UC Santa Barbara subscribes to the principles expressed in the EDUCOM Guide to the Ethical and Legal Use of Software. According to US Copyright Law, all intellectual works are automatically covered by copyright unless explicitly noted to the contrary.

   "Unauthorized copying and use of software deprives publishers and developers of a fair return for their work, increases prices, reduces the level of future support and enhancements, and can inhibit the development of new software products."

   US Copyright law applies to all software users. For a full reproduction of the EDUCOM guidelines, check VIEW. For a printed copy of the guidelines, write or call: EDUCOM, 1112 16th Street, NW, Suite 600, Washington, DC 20036, (202) 872-4200. If you are unsure about whether you possess legal software copies, contact your system administrator for more information.

   UC Santa Barbara does not condone or authorize the illegal copying or possession of software. University students and employees are prohibited from copying software illegally and possessing illegal copies of software, whether for course, job related, or private use. Any violations of this policy or of Copyright law are the personal responsibility of the user. The University will not assume any liability for such acts. Furthermore, system administrators will refuse to provide support for a user who cannot demonstrate that the software involved was obtained legally.

5. Use of computing resources for remote activities that are unauthorized at the remote site.

   For example, if you are accessing another university's system using a UCSB computing resource, you must obey that school's own computing rules. Your actions reflect upon the entire UC Santa Barbara community.

6. Causing computer failure through an intentional attempt to "crash the system," or through the intentional introduction of a program that is intended to subvert a system, such as a worm, virus, Trojan horse, or one that creates a trap door.

   You have a responsibility to other users to help maintain the security of the system. The intentional introduction of a subversive program is considered a grave offense. Taking reasonable precautions is part of your responsibility. If you think you may have accidentally introduced one of these programs, contact your local system administrator.

7. Intentional obscuring or forging of the date, time, physical source, logical source, or other header information of a message or transaction.

   Header information of electronic mail, files, and printouts is an essential part of the identification and documentation of your work. Forging electronic mail or masking identification information--for amusement, personal gain, or other reasons--is not allowed.

   H. Interception of transmitted information without prior written authorization from the appropriate system administrator.

   This violation is a serious invasion of another user's privacy and is analogous to tapping that person's telephone line. The University respects the right to privacy of all users and endeavors to do all in its power to maintain that right. You should be aware that sometimes, in the course of system maintenance, transmissions are tracked, but the contents are not read. You should also be aware that unauthorized users of the system are not afforded this same protection from invasion of their privacy. This means that the University can and will read transmissions by unauthorized users, to maintain the integrity and security of the computer resources for all authorized users.

8. Failure to protect one's account from unauthorized use (e.g., leaving one's terminal publicly logged on but unattended).

   When you do not protect your account from unauthorized use, you weaken the security of not only your account, but the entire system. Keeping your password secure and attending to your account when logged on are key means of protection.

9. Violation of priorities for use of computing resources as established by an individual facility within the UCSB system.

   Some UCSB computing facilities may have no usage rules beyond those given in this brochure. However, many have established priorities for use of computing resources to ensure that scholarly activities are granted more weight than, for example, recreational gameplay and other non-academic pursuits. These priorities must be respected.

Back to 07/18/01 Minutes