In the “On Site” by Albert Huang (“Innovative Use of Email for Teaching,” Nov. 2001), a method for using email to support teaching is described. The approach uses client-side email software, such as Microsoft’s Outlook Express, to sort incoming email messages into folders and automate delivery of course content. This client-side approach is only one part of a comprehensive email solution, which also includes server-side processing. This column addresses the problems inherent in a client-only approach and describes how a server-side approach can solve these problems and provide additional functionality.
Client-Side Problems
The two main problems with client-side processing are: the client needs to be active all the time; and the approach causes increased network traffic.
The problem with client-side email processing is it only occurs when the client is active. Therefore, the instructor needs to leave the email client on 24 hours per day, seven days a week (especially for automated document retrieval). This may not be feasible or desirable in many cases. Moreover, if the instructor uses multiple email accounts (as suggested by Huang), the client will only process email correspondence addressed to the current active account.
The client-side approach leads to increased email traffic, some of which may be over slow dialup lines. For example, when automatically retrieving a document, the email message is sent from a student to the server. The instructor then downloads the message and the client responds by sending the document back to the server and then on to the student (see Figure 1). The traffic pattern is similar for forwarding email files.
The Server-Side Approach
The problems outlined can be solved through the use of server-side processing. In particular, the server-side should handle automatic document retrieval and email forwarding.
It should be noted that server-side processing is not a substitute for client-side processing, but rather complements it. Both approaches, working together, lead to a more useful and powerful system.
Using server-side processing for automatic document retrieval reduces the amount of email traffic and does not require a running client. Huang points out that students can become frustrated with Web-based material that might be missing (for example, 404 errors). While this problem may occur with automatic document retrieval, it is just as likely for client-side processing. If the email server is not working, then neither the client nor server approach will work.
The server should also handle email forwarding. Again this would reduce network traffic and not require a running client. In addition, the server-side approach allows the instructor to distribute a single email address to all students. Email can be forwarded based on the subject line of the message. For example, the subject line “MIS 101 Question” might forward to the instructor’s main email address. A subject line “MIS 101 Assignment” might forward to a teaching assistant for grading. When the email message is received the client would place it in the correct folder (see Figure 2).
The server-side approach has the additional benefit of providing the ability to eliminate spam. Most email clients provide the ability to add a sender to a blocked list. However, messages from people on this list are merely deleted after they have been downloaded. Server-side processing allows for the deletion of spam before it is downloaded. This added functionality is particularly important with the rapid proliferation of email viruses and worms.
While server-side processing is potentially very powerful, it is much more difficult to use than client-side processing. Establishing message rules in a client is extremely simple. Server-side processing requires either custom programming or use of a server-side email system, such as Procmail.
Using Procmail for Server-Side Processing
Procmail is an open-source, Unix-based set of utilities that automatically processes email messages. Once installed on the server, the system’s individual user accounts are set to forward all incoming email through Procmail. In order to forward messages or provide an automated response, the user must enter a series of “recipes” into a .procmailrc file. A recipe is a set of statements determining how Procmail should handle messages.
Procmail recipes are broken into three main parts: a recipe header, a condition statement, and action statement. For example, Figure 3 shows a Procmail recipe to forward all messages that contain “MIS 101” in the subject line to mis101@rhsmith.umd.edu.
The :0 is the recipe header. It identifies the beginning of a new recipe. More complex recipes may require a number of flags in the header (a “c” flag is used to keep a copy of the forwarded message). The condition statement looks for any instance of mis-101 on the subject line (this is not case-sensitive). The final line is the action statement. In the example, the action is to forward the message to mis101@rhsmith.umd.edu.
Procmail can also be used for automatic document retrieval. The recipe in Figure 4 automatically sends the syllabus.txt file to the email sender.
This recipe is simplified, as it will only concatenate the contents of syllabus.txt to the body of the return email. It is possible to send the file as an attachment with a more complex recipe. The X-Loop addresses ensure an email loop is not inadvertently created.
A similar recipe without a subject line can be used to handle any message not processed by another recipe. In my programming class, this recipe sends a message to the student indicating his or her email has not been processed and provides a copy of the email guidelines. Therefore, all messages received by the client can be sorted into appropriate folders.
The Procmail system is extremely powerful, as it is able to call Unix commands and Perl scripts. Fortunately, there are a number of good Web sites available with tutorials and examples (see www.ling.helsinki.fi/users/reriksso/procmail/mini-faq.html#description).
Email clients provide a mechanism for instructors to handle course management. However, use of client-side-only processing may lead to problems. Combining processing of messages on both the client and server sides can solve these problems. In addition, the instructor gains additional functionality.
There is no reason to limit this type of system to an instructional environment. Many organizations may benefit from the use of a combined client/server email processing system.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment