VoIP Site
Helpline Site
IITS News
 

Student mass e-mail project proposal


Issues and requirements for mass e-mail to students

Note that the project plan has been split off into a separate document.


TABLE OF CONTENTS


EXECUTIVE SUMMARY

Policy and procedure

Policy and procedure documents will be developed for this service. The University of Virginia documents will be used as inspiration.

Maintenance of student e-mail addresses

A "virtual host" called "students.concordia.ca" will be implemented (on Clyde). This will be essentially an e-mail forwarding service. Students will be assigned an address on this service with a username in the current AGEM institutional account style (e.g. "a_benne" for "Anne Bennett"), and students will be responsible for providing the appropriate "real" e-mail address that their e-mail should be sent to. The "real" address is entirely at the discretion of each individual student -- it can be, for example, an Alcor account, or a "hotmail" account, or an account at a local ISP. Thus, e-mail for "a_benne@students.concordia.ca" might be forwarded to "anne@alcor.concordia.ca".

Students will update or provide their "real" (forwarding) e-mail address using the existing web interface on "websis", to which an appropriate item will of course be added. Additionally, when potential students apply to Concordia and provide their contact e-mail address, their permission will be sought to use that address should they eventually be registered at Concordia. In both cases, it will be made clear that requesting an "@students" address (in the first case) or giving consent (in the second case) will result in their receiving informational messages from the University.

The address data will be maintained and stored in the SIS, but tables of username to real e-mail address correspondences will be shipped to Clyde daily (or more often if judged appropriate) for incorporation into the forwarding tables. The process will of course be automated.

To increase the proportion of students providing contact addresses, it is likely that the new forwarding service will be publicized in various ways, including an item on the websis main page.

Queries on the SIS to build mailing lists will return the "username" of each student that (a) matches the query and (b) has provided a forwarding address. Mailing lists thus assembled will periodically be shipped to Clyde for use with Majordomo mailing lists.

Per-class lists

The per class lists will not be implemented as Majordomo mailing lists, but rather, the existing WebCT facility will be used. This means that, for all classes given in the Faculty of Arts and Science, a WebCT class will be created. The departments will be responsible for communicating instructor information to the WebCT administrator, and, where necessary, for providing the WebCT course passwords to the instructors. Side benefits of using WebCT for the per-class mailing lists will be that the full functionality of WebCT will be available to those instructors who wish to use it, including electronically available up-to-date class lists, discussion forums, and a place to put class notes. On-line grade entry could also be made available at the discretion of the Dean.

Currently, the process for an instructor to send an announcement to the class via WebCT requires a cut-and-paste operation. IITS will add a button to make this a one-step operation for the instructor.

Currently, students may consult their WebCT e-mail by logging in to the relevant class on WebCT. They also have the option of forwarding their e-mail (on a per-class basis) to a regular mailbox on some other system. However, at this time, it is not possible to send e-mail in to the WebCT system from the outside, so students cannot reply to an instructor's message which has been forwarded to another system. IITS will look into adding a facility by which e-mail can be sent from the "outside" to WebCT mailboxes.

While we hope that this will meet the need expressed by the Faculty of Arts and Science, it should be remembered that an instructor can always apply for a regular Majordomo mailing list for use by her class; in that case, though, the students must explicitly subscribe to the list.

Other "standing" lists

The other standing lists, such as per-department, per-major, all students in Faculty, and so on, will be implemented as Majordomo mailing lists, owned and moderated by faculty members or other staff assigned by the Dean. These lists will be configured by IITS in accordance with appropriate header and fronter standards.

The description of the lists desired, as well as the name, title, and e-mail address of the listowners, will be provided by the Dean of the Faculty. IITS will create and configure the lists, and will set up automated jobs to periodically update the list membership according to the criteria specified.

"Ad hoc" lists

When a temporary list is needed, the request will be submitted by the Dean to IITS, similarly to the procedure for standing lists. IITS will create, configure, and populate the Majordomo mailing list, and inform the listowner; IITS will remove the list after a specified time period.

Extension of service to faculty and staff

While the first phase of this project involves e-mail to students only, it is understood that a more general facility is desirable to provide for announcements to faculty and staff. This implementation is expected to take more time because of the greater difficulty of tracking the correspondence between a staff/faculty member, some "identifier" (similar to the AGEM username), and an e-mail address. Thus, it is not included in this project.

Project schedule

Per-class lists could be available as soon as January 1st, 2000. The forwarding service for students and the standing and ad hoc lists will be available before the end of the first quarter, 2000. Tools to permit easier management of and queries on Majordomo lists should become available around the same time, but are considered to have a lower priority. A policy document will be available before any of the lists enter production mode. A procedure document, if one is necessary, will evolve as the service goes into production.


BACKGROUND

In August 1999, the Dean of Arts and Science approached John Woodrow, the director of IITS, about putting in place facilities to permit his faculty to communicate with students using e-mail. In particular, he asked for two things:

There is already a project in progress (but stalled at the moment) to make mass e-mail possible to the Concordia community: "CUBE", the Concordia Unsolicited Broadcast E-mail service. This new project and CUBE will be harmonized.

We need not go into detail concerning why a greater use of e-mail for communication with students is a Good Thing; suffice it to state that not only is it faster and less expensive than paper, but because of those inherent advantages, it becomes possible to accomplish new things, for example, quickly notifying students registered in a class of a room change or a cancellation. From the CUBE project requirements:

The purpose of the service is to encourage and facilitate the official use of electronic mail, in order to reduce costs associated with the generation of mailing labels, the handling of physical mailings, and their printing, and in order to faciliate communication with the members of the "concordia.ca" domain. Environmental benefits are also expected in the form of a reduction of paper consumption.

Back to table of contents


INITIAL REQUIREMENTS

Arts and Science meeting

On September 23, 1999, Bill Miller and Anne Bennett of IITS met with Andrew McAusland and Donald Chambers of Arts and Science to clarify the requirements for the project. The main requirements are those described in the background section above, but additional points were also discussed, as outlined in the subsections below.

Agreement in principle was reached on all points, and Arts and Science showed itself quite flexible with respect to the particulars of the implementation, as long as the service is available to them.

There is no such thing as an "e-mail account"!

With respect to the first request of A&S, that new students be given access to an "e-mail account" by default, it was pointed out that we don't have "e-mail accounts". In theory, such a beast could exist, but in fact, IITS offers full-access computer accounts. IITS also offers e-mail forwarding services using "virtual hosts", for example, the "E-mail For Life" service offered by the Alumni Office, where mail for "username@alumni.concordia.ca" is actually handled by the University mail relay host (Clyde) and forwarded to the client's "real" e-mail address, usually at an ISP.

This is relevant because A&S's first request could be implemented either using a "real" computer account (probably on Alcor), or using a forwarding service (probably "username@students.concordia.ca" implemented on Clyde), and there are arguments for doing it either way, which we will examine below. A&S doesn't mind how it is done.

What is the intended use of the lists?

IITS wanted to make sure it understood how A&S envisaged that the mailing lists would be used. We found that some of our assumptions held, but we had not foreseen some of the uses that were requested.

We discussed the idea that lists could be "standing" or "ad hoc". A standing list would exist all the time, and be updated automatically from the SIS data on a periodic basis (perhaps every week). Examples included:

An "ad hoc" list would generally be a one-time, or very occasional, request, based perhaps on a more complex query to the SIS. An example might be: A&S expects to use other lists, such as: It is not clear whether those lists would be standing or ad hoc; presumably, operational experience would give us a better idea of how best to handle those.

Does A&S need access to the subscription list?

IITS was somewhat concerned about protecting access to the lists, and in particular, about whether A&S wanted their people to have access to the actual list of names, or whether it would be sufficient to make the use of the list available. As it turns out, A&S shared the concern, and stated that only the use, not the contents, of the list were needed.

Who can authorize a mailing?

It was generally agreed that the authorization needed to send to a list would be proportional to the size and scope of the list. For example, an instructor could send to her class, but only the Dean of Arts and Science could authorize a mailing to all or most students in that faculty.

How to ensure appropriate use of the lists?

There was some concern raised that the lists not be used "frivolously", or for advertising, etc. We were assured that such was not the intention.

I will refer below to the University of Virginia's method of ensuring accountability for appropriate use, by inserting a "fronter" at the top of the message which clearly identifies the authorizing party, so that complaints can be directed to the right place.

Getting off a list.

A&S requested that it be possible for students to opt out of receiving mailings. It is not clear whether this request can reasonably be accommodated; the technical requirements are discussed below. This issue was not considered a show-stopper.

Other requirements

Other uses of unsolicited broadcast e-mail

While this project was requested by Arts and Science, it dovetails with an IITS initiative in progress, "CUBE". Because of the request from A&S, and because student details are easier to track (via the SIS) than are those of staff and faculty, the implementation of mass e-mailing services will start with mailings to students. However, it is intended that faculty and staff will also be addressed by this project in due course.

Examples of mailing lists that might involve employees are:

In the above cases, though, it may be problematic to find ways to assemble and maintain that data.

IITS requirements

Last but certainly not least, we have the "negative" requirements imposed by the necessity to be good net.citizens and to be perceived as such both by our own community and by others, and also requirements concerning the ease of use and management of the service, and of course security and privacy of the data. Many of the following are taken directly from the CUBE project requirements.

Back to table of contents


DESIGN AND IMPLEMENTATION ISSUES

In this section, text in blue will indicate a design decision, that must be followed up with one or more tasks in the task list section.

Experience at the University of Virginia

The University of Virginia has addressed the challenge of responsibly using mass e-mail to its constituency, and reports on the experience in the ACM SIGUCCS Newsletter, December 1998, pages 19-21. The article by Jayne Ashworth, entitled "Revisiting Institution-wide E-mail: Spamming Our Own", describes what has on the whole been a positive experience for that institution: the systems have been able to handle the load, and there have been few complaints from recipients -- in fact, several recipients have written to state their approval of the new service, and hit counts on the web sites mentioned in the messages confirm that a large part of the target population does indeed read the messages.

The University of Virginia's policy and procedure for managing this service are available online, and the policy especially constitutes a good model for what we hope to accomplish at Concordia:

I believe that the University of Virginia's success stems from good planning and a clear policy. Citing from the article:

In short, the policy recognizes that at times it is necessary and expedient to provide information to much of the University's community via electronic mail. The policy goes on to define who can approve the distribution of messages to all or some of the community.

[...]

So that the approving authorities will be aware of concerns caused by the messages, each message begins with the name and e-mail address of the person(s) who have approved the message. The exact text is:

The following message has been approved for distribution by (name, e-mail address) of (office).

In fact, this last is very similar to the original proposal for the headers of CUBE messages, and I think that Virginia's implementation is better, since the approver is right out there in the body of the message (many people never read the message headers).

One thing that struck me about the report, which reflects some of my concerns about how the service will be used, is that the service was not necessarily used only in the ways envisaged by the policy writers:

The people who wrote the policy were concerned with the distribution of time-critical information that needed to reach the community. The approving authorities see the policy as providing a vehicle that affords an effective and inexpensive method to distribute information to the community.

In practice, this turned out not to be a problem, perhaps in large part because the authorizing party's identity and e-mail address are featured so prominently on the messages.

Usability of the service

Staff access to e-mail

Concordia University is highly networked and computerized, and all regular staff members are entitled to have computer accounts through which they can send and receive e-mail. Thus, we can safely state that all staff members who might need e-mail access can get it.

Student access to e-mail

All students (not counting Continuing Education students) are entitled to have an Alcor account, which they can use to send and receive e-mail, as well as for surfing the Web. They are also entitled to obtain accounts in the Internet Lab, which can be used for Web access, and they are entitled to use the IITS dial-in lines, if they wish to use their home computer to connect to our facilities. Thus, it is also safe to state that students have access to e-mail. In fact, in practice, we are told that the overwhelming majority of students use e-mail regularly.

Policy, netiquette, spam, privacy

The PCF

Item 5 of the Policy on Computing Facilities expressly permits mass e-mailing under some circumstances:

Access to the CCF shall not be used for unsolicited mass mailings of any kind including chain letters and advertising except by University departments and subcontractors acting within the parameters of their University-defined missions. Unsolicited mass e-mailings should be used sparingly and may be made only through distribution channels approved by IITS.

Obviously, CUBE and this project as proposed fall within those parameters.

Spam and public relations

It should be borne in mind that even though this project will benefit the University community, the issue of unsolicited broadcast e-mail (UBE, or "spam") is extremely sensitive, both within Concordia and without.

No matter how good our intentions, unsolicited broadcast e-mail is spam, and sending it offsite is very likely to cause a public relations disaster. For that reason, our mailings must be sent only to addresses in the ".concordia.ca" domain, which we own. Since no one offsite can justifiably complain about e-mail which is internal to the institution, that should be sufficient to stave off any serious problems in that respect. Of course, our users may choose to forward their mail to an offsite address, but that is their privilege and does not change the fact that we mailed only to "our" addresses.

There is also the issue of members of our community taking exception to receiving such broadcast mail. Should it be possible for them to "opt out" of CUBE, or better yet, should they have to "opt in"? The argument can be made that Majordomo ("opt in" or voluntary) mailing lists are already offered by the University, but they do not meet the needs articulated by, among others, the Faculty of Arts and Science. We can add that, in practice, it is not always easy to inform people of such lists and get them to subscribe.

Clearly, CUBE is intended to be used only for information of sufficient importance to justify sending unsolicited mail; anything else should be done using regular "opt-in" lists. A possible compromise is to have a flexible "UCE choice" system, where students (and others) can select what kinds of e-mail they are willing to receive. However, it could be quite tricky to come up with such a categorization.

If explicit consent can be obtained from the student (and staff or faculty member) to receive such mailings, it would be best. One possibility in the case of students is to add such consent to the registration contract. In that case, though, giving consent is not voluntary, but becomes part of the agreement of being a student at Concordia. Alternatively, if mailings are done through a "forwarding service" (e.g. username@students.concordia.ca), then the registration of a "real" e-mail address with the forwarding service could be made contingent on consenting to receive CUBE mailings; this would address the issue of explicit consent, permit people to not opt in, and yet encourage them to do so, since most students would probably want to have a "fixed" address in a domain such as "students.concordia.ca". Also, since they might use and advertize the "@students" address, they would be motivated to keep it up to date, something they might not remember (or bother) to do for a record which is used only for CUBE mailings.

Privacy concerns

In general, the membership list of any mailing list should be considered private, or in some cases, available to list members only. For WebCT lists, students can see the membership of their own class, by name and "WebCT ID"; student IDs and e-mail forwarding addresses are not visible to the students. For Majordomo lists, steps are taken to ensure that the list membership cannot be revealed using the sendmail EXPN command. Whether or not the list membership is revealed by Majordomo upon receiving the "who" command depends upon the individual list's configuration; IITS will configure lists with "who_access = closed" to prevent anyone from seeing the membership list.

The correspondence between a student's name and her ID number is private by law. The ID number will not be stored on Clyde at all, so cannot be revealed by any use of the standing or ad hoc lists. While WebCT does store students' ID numbers, these are revealed only to the instructor and grade-approvers.

Who can use these lists? (AUP)

Because membership in the mailing lists described in this document is for the most part involuntary, it is particularly important that the lists not be misused, and that mailings to them be restricted to what is necessary. Therefore, appropriate use guidelines should be provided to listowners. In the case of standing and ad hoc (Majordomo) lists, each message will be preceded with a "fronter" identifying who has approved the message; thus, complaints of misuse can be directed appropriately.

All CUBE mailing lists should be moderated, thus only the moderator will be able to send messages to a list; a message submitted by anyone else will be sent to the moderator. A mailing list will be owned by the person who is authorized to approve mailings to it, or their representative. That person will have the moderator password, which in itself will be sufficient to send messages to the list.

Use of Majordomo

We already have mailing list management software: Majordomo. We are in general quite satisfied with this software. Because the software is written in Perl and we therefore have the source code, we can change it if necessary to accommodate particular needs. Also, the software uses standard text files to store the per-list configuration and membership lists, so we can munge those as needed with home-grown scripts. Finally, additional free software is available to assist us in putting up Web interfaces to Majordomo. Thus, we have decided to use the existing Majordomo set-up to implement most of the mailing lists requested by Arts and Science.

Note that it would be wise to upgrade to the latest version of Majordomo, perl, sendmail, and bulk_mailer before putting this new service into production. We will also want to make sure that we have appropriate statistical software on hand and in use to analyze the traffic generated.

Real computer account or forwarding service?

A forwarding service should be used

I recommend that a forwarding service be used, "students.concordia.ca" (and eventually similarly for staff and faculty). The reasons are:

Of course, a "real" (Alcor) account is available to any student who wants one, and forwarding from the virtual host may be set to the Alcor account.

Addresses kept on WEBSIS vs addresses kept on Clyde

Since we already have, in the SIS, not only a record for each student to which an e-mail address field could easily be added, but also, in WEBSIS, the ability to allow students to update their data, it makes the most sense to use these existing facilities and keep the e-mail addresses in the SIS.

The correspondences between "username@students.concordia.ca" and the "real" addresses will be communicated from the SIS to Clyde by a mechanism to be determined (either ssh, if the VMS version works well enough, or, if necessary, e-mail). This will happen automatically on a periodic basis.

Username for virtual host chosen by user or AGEM?

While the users would certainly prefer to choose their own "usernames" (Anne.Bennett@students.concordia.ca), avoiding name conflicts would necessitate additional programming effort on the part of the SIS team. Also, we already have unique usernames for most students in AGEM, the account management system. It makes the most sense to reuse existing code to generate unique usernames, but to move the generation and storage of usernames from AGEM to the SIS . The use of our usual "fi_last" usernames is "natural" and permits the student to have the same username on all IITS computers -- potentially even on non-IITS computers, if other large departments, such as Computer Science, pick up that field from the SIS for their own computer accounts (my belief is that they will).

Note that it will be necessary to generate usernames for ContEd students in the SIS as well, to make sure that the "underscore username" namespace is managed in one location, to avoid name clashes.

Data management

Keeping student contact addresses up to date

In view of the number of students at Concordia, it must be possible to make the students themselves responsible for directly updating their e-mail addresses, preferably using the Web. Issues of authentication of the updates must be addressed; however, there is already a mechanism in place to protect students' access to the information in the SIS, namely, the student number, CARL PIN, and date of birth: WEBSIS. Therefore, students will update their "students.concordia.ca" addresses using the existing WEBSIS interface, to which an appropriate item will be added.

As a separate but related project, thought should be given to the possibility of providing some kind of searchable online directory service for students who use an "@students" address, possibly including their full name (or an alias chosen by them), their "@students" e-mail address, and their web page URL.

Keeping lists up to date

Individual Majordomo lists will be updated automatically by file transfer from the SIS. This means, of course, that any subscriptions or unsubscriptions done via Majordomo will be overwritten, therefore individual opt-out on a per-list basis is not possible. It may be possible to eventually have more fine-grained settings at the level of the SIS (and the WEBSIS interface) to permit the user to be excluded from certain lists, but for now, we do not envisage implementing any such mechanism.

Password/access management for listowners

Each new list must have a listowner, whose e-mail address needs to be known at list creation time, and for each list, the list password must be relayed back to the listowner. We can do this manually for the standing and ad hoc lists, since their number will be small and their owners relatively static, but for per-class lists, this must be automated. The difficulty of automating this process at this time is part of the reason why we have opted to use WebCT for the per-class lists, as explained below.

Handling requests for ad hoc lists

Initially, these requests will be handled manually by IITS, as mentioned in the previous subsection. If ever we find that there is a large number of such requests and that the handling of those requests is generating too much work, we will reconsider, and perhaps find a way to automate the management of ad hoc lists.

Special case: per-class lists

The requirement to have one mailing list for each class (or for each section) presents an interesting set of problems. Of course, it means having a very large number of mailing lists (in the thousands). I think we could handle that on Clyde (using Majordomo lists) with no problem, but I admit it has not been tried. Because the list of lists would be fairly dynamic, changing significantly every semester, we'd have to develop a protocol for the automatic creation and deletion of these lists; again, not an insurmountable problem, but one whose solution would require a bit of careful programming. Certainly, the sheer number of lists could cause a problem with, for example, any web-based list or subscription management utilities, but I believe that a few small code hacks could resolve that problem by hiding the class lists from any such utility.

One problem that is not easily resolved, however, is the issue of obtaining the instructor's e-mail address and communicating the list password to the instructor in an automated way. The e-mail address is required at list creation time, because each (Majordomo) mailing list must have a listowner. If we had the e-mail address, we could conceivably send the list password to that address. However, currently, instructor identities are rarely kept up to date in the SIS, and even where they are available, there is no automated way to map them to an e-mail address. This issue is unfortunately a show-stopper; we cannot reasonably implement per-class lists with Majordomo until (a) instructor identities are available in the SIS database, and (b) there is a way to map those identities to e-mail addresses.

Fortunately, the corresponding issue has been resolved in practice for the implementation of WebCT in the Faculty of Commerce. Since WebCT already provides e-mail access to class members, we have decided to use it for this application. Side benefits of using WebCT for the per-class mailing lists will be that the full functionality of WebCT will be available to those instructors who wish to use it, including electronically available up-to-date class lists, discussion forums, and a place to put class notes. On-line grade entry could also be made available at the discretion of the Dean. Of course, it is not necessary to use these other facilities if they are not wanted.

The current implementation of WebCT for the Faculty of Commerce involves having the chair of each department take responsibility for the transmission of the instructors' identities and e-mail addresses for classes given by their department -- or, in cases where that information was not available on time, the transmission back to the instructor of the WebCT course password. WebCT courses, however, are generated automatically by IITS, and populated with the registered students, again automatically. The list of registered students is updated by IITS on a periodic basis. Initial passwords for student accounts are created based on information known by the student, so the use of "yellow cards" is avoided.

It is already possible for students to forward their WebCT e-mail (or a per class basis) to a regular computer account. IITS is looking into the possibility of enabling replies back into WebCT, and into the possibility of making "mail to the entire class list" a one-button operation for the instructor.

Therefore, IITS has decided to use WebCT to meet the "per class lists" requirement of Arts and Science. For those courses for which, for some reason or other, this is not suitable, regular Majordomo lists are of course still available, though they will not be created or populated automatically.

Performance and capacity

Can Clyde take the load of running several additional and possibly large mailing lists, as well as acting as a virtual host (forwarder) for tens of thousands of students? The postmaster's gut feeling is yes, but tests should be performed. Clyde will be upgraded in the unlikely event that this proves necessary.

A large number of students have their e-mail on Alcor, and a mailing to most of them is likely to place a significant load on the system. Can Alcor take the load of incoming mail? The postmaster is quite sure that the answer is yes, based on the experience of the pilot CUBE mailing in early 1999. However, for the sake of thoroughness, we should analyze the data gathered during the CUBE test to confirm this.

Extending the service to faculty and staff

Extending CUBE to employees is something for which there is already a demand; several University offices have a legitimate need to be able to send e-mail announcements to faculty and staff, and subsets thereof.

However, the implementation of such a service is somewhat trickier than for the students' case: we don't currently have a handy way to combine data from the Human Resources database and the online telephone directory (which contains e-mail addresses). Also, our requirement that we "spam" only "our own" (i.e. addresses in the .concordia.ca domain) means that we would need to set up virtual hosts "@staff.concordia.ca" and "@faculty.concordia.ca", or else insist that employees supply real e-mail addresses in our domain only. And in any case, we don't currently have a well-authenticated automated way for employees to submit updates to their personal data.

Thus, a mechanism similar to WEBSIS should be provided to staff and faculty (perhaps through the internal directory) to permit them to update their forwarding addresses.

Also, ideally, we'd want to have some kind of faculty identifier so that we could match up instructors in the SIS with their e-mail addresses, so that we would have a way to e-mail "everyone teaching in the Basketweaving Department", say, or "everyone in the Faculty of Arts and Science who had not yet submitted all of their grades".

Back to table of contents


Copyright, © 2004, Concordia University,
Instructional and Information Technology Services (IITS).


Author: Anne Bennett
Credits: Andrew McAusland and Donald Chambers (Arts and Science); Bill Miller and Michael Keefe (IITS); John Woodrow (IITS, with thanks for reference to Virginia paper)
Maintained by: postmaster@concordia.ca
Last update: 2001/02/22 -- Sylvain Robitaille

  [IITS Home]
  [Concordia Home]