Computational Mail as Network Infrastructure/Borenstein 1 Computational Mail as Network Infrastructure for Computer-Supported Cooperative Work Nathaniel S. Borenstein Bellcore Abstract Computational email -- the embedding of programs within electronic mail messages -- is proposed as a technology that may help to solve some of the key problems in deploying successful applications for computer-supported cooperative work. In particular, computational email promises to alleviate the problem of remote installation at separately-administered sites, the problem of getting users to "buy in" to new applications, and the problem of extremely heterogeneous user interaction environments. In order for computational email to be practical, however, key problems of security and portability must be addressed, problems for which this research offers new solutions. This paper outlines the promise of this new technology, the solutions to the key technical problems, and the areas where further work and application development are needed. The Goal: Distributed Computer-Supported Cooperative Work In recent years, increasing attention has been focused on the problem of computer-supported cooperative work (CSCW). This work, broadly defined, is the attempt to provide computer-based solutions to the problems that arise when two or more people attempt to cooperate to perform a task or solve a problem. The simplest CSCW systems, from an architectural perspective, are those in which the cooperating individuals share a computerized application on a single machine, perhaps even using a single process. In such systems, many problems of coordination and communication can be avoided. However, such systems are increasingly implausible for solving the problems of real-world users, who may be widely separated geographically and may have significant amounts of computing power on their individual desks. Truly distributed applications seem natural in the face of a high ratio of computing power to available communications bandwidth. For many cooperative applications, distributed solutions seem inevitable, and indeed a growing number of CSCW prototypes are implemented in a distributed manner. Unfortunately, the practical success of such systems to date has been extremely limited. This paper begins with a discussion of three key problems that have inhibited the widespread use of distributed applications for CSCW. Following this, the paper offers a description of a new technology, "computational electronic mail (email)", that offers a potential solution to these problems. Problems that have, in the past, rendered computational email impractical are discussed, along with proposed solutions to these problems. Following this is a discussion of the author's particular realization of these solutions, a language designed specifically for the unusual requirements of computational email. The design of this language and its prototype implementation are presented as a "proof-of-concept" for the practicality of computational email. The preliminary results of that implementation, and its implication for future systems, are discussed briefly at the end of the paper. The Practical Difficulty of Widely-Distributed User-Oriented Computation When building a user-oriented distributed application, the programmer faces a special set of constraints above and beyond the usual substantial hurdles entailed in every new user interface. In particular, he or she must solve at least three problems that are not generally faced by single-user or single- machine applications: I. The Problem of Remote Installation In order for an application to be used by multiple users at multiple sites, it must, perforce, be installed at all such sites. This is not a problem for applications in which all of the potential users are eager and knowledgeable participants, in which case they can be counted on either to install the software themselves or request such installation by the local authorities. However, this is by no means the normal situation for distributed applications. In many distributed systems, as noted by Grudin [Grudin, 1990], there is a substantial imbalance between the motivations of the various particpants. A common scenario, for example, involves one user asking a question of a group of users. In such a situation, it is much more reasonable to expect the questioner to ensure the local installation of some CSCW software than to expect it of the people being asked. In short, the participants in a cooperative application often have widely differing degrees of motivation, and are therefore likely to exert similarly varying degrees of persistence and effort in order to ensure that the software for that application is locally installed. Almost inevitably, this leads to a situation in which the highly-motivated individuals find themselves wheedling, cajoling, or even begging the less motivated individuals to install the software on their systems. Without extreme persistence, CSCW applications can fail without ever really being tried, simply because a sufficient installed user base was never created. II. The Problem of User Buy-In Related to the problem of getting software installed at widely distributed sites is the problem of getting people to actually use the software once it is installed. Because of the differing motivations of the participants, it is likely that some users are far more likely than others to actually run the software. As Grudin has noted, the users who are most crucial to the success of a CSCW application often have the least personal stake in using it. For example, in any system that seeks to help novices get information from experts, the experts who know the answers have relatively little motivation to provide it. Some systems, such as the Answer Garden of Malone and Ackerman [Ackerman and Malone, 1990] rely on the good will (and memory) of the experts to periodically run a program to see if anyone needs help. Since the necessary combination of good will, reliability, and memory are relatively rare, this requirement can be crippling to the practical success of a system. III. The Problem of Heterogeneous User Environments For better or worse, there are a wide variety of user interaction environments in use today, and this seems unlikely to change in the foreseeable future. Potential participants in a cooperative application may be running on dumb terminals, Macintoshes, personal computers running MS-DOS with or without MS-Windows, OS/2 with Presentation Manager, UNIX with X11, SunTools, NeWS, or various other environments. It is unlikely, to say the least, that the purveyors of a cooperative application will be able to dictate, to all potential users of the system, a single interaction environment. (Malone and Ackerman's Answer Garden was an exception in this regard: they were able to assume that all users were running X11, for the simple reason that their application domain was questions and answers about the X11 system itself.) In order for a distributed application to see widespread use and acceptance, it will have to run on a very wide variety of platforms, probably including all the ones just mentioned. But, as programmers well know, getting any piece of software to work on such a variety of platforms is a major task in itself, above and beyond the main thrust of the cooperative application. Needed: A Platform On Which to Build If all of these problems afflict a wide variety of cooperative applications, it seems natural to seek a mechanism to solve them for the entire class of applications, rather than for each application individually. What is really needed is a platform on which distributed applications can be built without concern for the problems of distribution, user buy-in, and heterogeneous interaction environment. If a computational engine can be defined in such a way as to support the requirements of many cooperative applications, yet without commitment to a particular user interaction technology, and if that single engine can somehow overcome the first problem, the problem of remote installation, then neither the problem of remote installation nor the problem of heterogeneous user environments will afflict applications that are built on top of such an engine. This leaves the problem of user buy-in: assuming such an engine were defined and widely implemented and installed, how could users be persuaded to use it regularly? One solution is to "piggyback" the engine on top of a technology that is already at the fingertips of most computer users today, electronic mail. The Case for Computational Email The basic idea of computational email is very simple: Instead of sending plain text, or even multimedia information, in a mail message, what is sent instead is a computer program in a well-defined language. At the recipient's end, the mail-reading software recognizes (via a well-defined mechanism) that the mail message is intended to be executed rather than read, and (accordingly) executes it. Thus, when the recipient reads a mail message, the message might first show him some introductory text, and then engage him in a question/answer dialogue. For example, it might ask him to select which of ten proposed dates and times he can make it to a meeting. The program might then mail the answers back to a network server that was collecting such answers from several such people, in order to find a meeting time suitable to all of them. The greatest appeal in the idea of embedding applications within email is the simple way it solves the problem of user buy-in. Because nearly everyone who uses a networked computer nowadays is likely to be a regular reader of email, an application that is delivered to a user in the form of email requires no special effort or feat of memory, on the part of the recipient, in order to run it. Most important, remote users of a distributed application can, by embedding computation in email, solicit information or participation from a user who does not yet know that his participation is required. While the idea of embedding computation in email suffers no less than any other application from the problems of distributing the initial software and devising an interaction mechanism that works regardless of interaction environment, it can be designed in such a way that the solution of the problem for computational email makes the problem simply nonexistent for applications built on a platform of computational email. In other words, solving the remote installation once, for a computational email infrastructure, will solve it for a whole class of follow-on applications. Prior Art The idea of computational or "active" mail is sufficiently simple as to have been mentioned, in the research literature, at least fifteen years ago, in a paper by Anderson and Gillogly [Anderson and Gillogly, 1976], who discussed the concept without implementing it. Several researchers have implemented computational email, or "active messaging," including Vittal [Vittal, 1981], Hogg [Hogg, 1985], Borenstein and Hansen [Borenstein, 1991a, and Hansen, 1990], and Shepherd [Shepherd, 1990]. Each of these systems demonstrated facilities for embedding computation and email, and several offered convincing evidence for the general utility of such a facility. Nonetheless, all of the prior work has suffered from at least two of four crucial flaws, which have prevented a generalized facility for computational email from becoming widely available: 1. Lack of generality. Some systems, notably the Andrew system without Ness [Borenstein, 1991a], offered only highly specialized facilities for active messages, such as special-purpose "voting" messages. Though useful, such facilities do not provide a platform on which larger applications can be built. 2. Lack of conformity to the standard email transport model. Some systems, notably Imail [Hogg, 1985], did not use asynchronous store- and-forward delivery, and thus might arguably not be called electronic mail. In particular, Imail provided a very powerful active messaging language, but could only be used to exchange messages between authenticated users of a single machine. Since most email crosses insecure network connections, such mechanisms do not generalize well to the real world. 3. Lack of security. Some systems, such as R2D2 [Vittal, 1990] and Andrew with Ness [Hansen, 1990], provided general-purpose mechanisms that were exceedingly dangerous. In such systems, a user is typically asked a question such as "There is a program here. Do you want to try running it?" If the user answers in the affirmative, he may have risked the destruction of all his files. This is probably unacceptable to most users in the real world. 4. Lack of portability. Computational mail that provides a rich user interface mechanism, such as Andrew with Ness [Hansen, 1990], or Strudel [Shepherd, 1990], has typically been extremely non-portable with regard to user interaction environments. With Andrew messages, for example, the interaction mechanisms only worked properly if the recipient read his mail using the Andrew Messages program, under the X11 or WM window systems. In a highly heterogeneous world, such restrictions are not acceptable to many communities. Thus, although the existing literature amply documents the continuing fascination that computational email holds for email researchers, it fails to provide a practical model for making computational email a part of the general shared infrastructure of a large, diverse, and not entirely trusting network community. This is the starting point for the research reported here. Portability Across User Environments Stated in the most general and ambitious manner, the goal of making user interfaces entirely portable between a wide range of user interface environments is probably impossible. However, a lesser goal will suffice for computational email. A significant number of applications can be built using user interface primitives that require only textual input and output, and that are specified in a manner that assume nothing about the capabilities of the user interaction environment. Examples of such primitives might include: 1. Get text (a string) from the user. 2. Get a number from the user. 3. Ask the user a multiple choice question. 4. Fill in the blanks in a form. 5. Display a chunk of text to the user. As long as the language primitives refer only to the information that must be given to or obtained from the user, and make no reference to the technologies by which that information is to be given or obtained, and as long as the information can be expressed as simple text, such primitives can be implemented in virtually any interaction environment. For example, a multiple choice question might produce a dialog box for a user running in a graphical environment, while it might produce a numbered list on a teletype, with a request to "choose a number from 1 to 7." What matters, in such primitives, is that the mechanism by which the information is conveyed is left unspecified by the definition of the primitive. Given that fact, a user can expect to compose and test a program in one environment, secure in the knowledge that it will behave well even in a very different environment, where the interpreter understands the same language, even though it might interact with the user rather differently. Security of Computational Email The security of a computational email message is an area where virtually no compromise is acceptable. This might not have been true a few years ago, but well-publicized episodes such as the Internet Worm [Spafford, 1989] have made most computer users highly conscious of, and concerned about, the security of their computer systems. However, despite such concerns, it must be explicitly recognized that certain risks are routinely accepted by the general computing public. Conventional electronic mail, for example, is not without risks. The most common risk in current mail systems is resource deprivation. For example, by repeatedly sending large mail messages, any network user can often fill the disk of another, depriving him (at least temporarily) of the use of that disk. This can often be done completely anonymously, and can be a minor nuisance or a major problem, depending on what else shares the disk. Similarly, a program that uses mail protocols on a network can, by playing "cat and mouse" with someone else's mail transport agent, effectively tie up much of the bandwidth available on a network, or even a substantial portion of the computational power of the remote processor. Beyond resource deprivation, an even more insidious risk in mail systems is that they are vulnerable to intruders using essentially non-technical means. Recently, many users on the Internet were told, via official looking mail, that they had to change their passwords to "SYSTEST01" immediately; apparently more than a few complied. The infamous "Christmas Tree Virus" that afflicted the IBM networks a few years back was entirely based on social engineering: Users received mail that appeared to come from someone they knew, saying "here's a neat program that will make an animated Christmas Tree on your screen." When executed, the program did exactly that, thus avoiding suspicion, but it also sent copies of itself to all of the users' regular correspondents. Finally, existing mail systems, like all network software, are vulnerable to security problems through bugs. The Internet worm, for example, exploited a bug in a mail transport program as one of several mechanisms for transporting itself. The point of the foregoing discussion is not to frighten the reader out of ever using email again, but rather to point out that a "risk free" solution is chimerical. A more realistic security goal for computational email might be characterized as follows: Computational email should entail no security problems that are worse, either in kind or in degree, than the problems that afflict ordinary (textual) email. Given such a goal, we may begin by characterizing the potential risks into three broad categories: 1. Destruction of Resources (e.g. files) 2. Theft of Resources (e.g. private files) 3. Deprivation of Resources (e.g. filling up a disk or tying up a CPU) To understand how these problems can be addressed, it is instructive to consider an analogy. Imagine, for a moment, that somewhere in the basement of the Pentagon there are two computers. They are identical hardware, and they run identical software; they are as alike as two peas in a pod. On each of them, there is an executable procedure called "DestroyBaghdad". On one of the machines, executing this procedure does nothing. On the other, the effects of executing the procedure are disastrous, at least for the citizens of Iraq. The only difference between the two machines is a single wire coming out of the back of the second machine.1 The point, of course, is that nothing inherent to a computational language is dangerous; danger is posed only insofar as the effects of executing statements in a language include "side-effects" in the external world. If all the "wires" connecting a computational language to the outside world are cut, then executing programs in that language is harmless. (An exception to this claim is that such a program can still tie up the CPU, virtual memory, or swap space on a machine by going into an infinite loop; this can be handled via resource limitations.) More concretely, if one starts with a conventional programming language, such as LISP [Steele, 1990], and removes all input and output from the language (including not only input and output to and from the user, but also to and from files, other processes, and arbitrary memory locations which might be connected with physical devices), one is left with a language without "wires" to the outside world. No matter what can be expressed in such a language, it can do no harm to the outside world. Unfortunately, though it can do no harm, it can do little good, either. So the task of devising a secure language for computational email reduces, in practice, to the construction of a secure input/output mechanism for a conventional language. Devising such a mechanism is really just a matter of judicious trade-offs. For example, one can specify that the language has no general-purpose access to the file system, but has a limited form of access to a subset of the file system. In the system to be described below, programs have access only to a restricted subdirectory of the user's files, and the interpreter is expected to ensure that no "tricks" (such as, in UNIX, the use of ".." or symbolic links) can be used to access files outside that area. Within that restricted area, programs are additionally restricted in their ability to overwrite existing files, and in the number and size of the files they can create. In such a way, the potential harm to the file system that is caused by computational email is not greater than the disk-filling potential of textual email. Similar restrictions are applied to other input/output processes, including sending mail. Some security constraints also apply to user interaction: for example, in order to prevent subversion through the clever exploitation of "intelligent" terminals, input and output is restricted to printable characters. Heterogeneous Mail Reading Software A major impediment to any enhancements to electronic mail systems is the tyranny of the lowest common denominator. Multimedia mail systems such as Andrew [Borenstein, 1991a] and Diamond [Forsdick, 1984] have long suffered from the fact that, in the absence of widely accepted standards for multimedia mail formats, most email traffic will necessarily be plain text, even for users of multimedia systems, because most of their correspondents will not be users of compatible systems. The same problem affects any attempt to promote the use of computational email. In order for such a system to be widely used, it must not require the use of a special mail-reading tool. Instead, a mechanism is needed whereby a wide variety of mail-reading tools can easily be given the capability to handle computational email. Such a mechanism has been prototyped by the author, and is described elsewhere [Borenstein, 1991b]. Its essence, however, is simple. Each mail- reading user interface is modified in a small but crucial way: it is modified so that, whenever a user requests to see the body of a message, the software first checks to see whether or not the message is plain text. (In Internet mail, this is done by checking the Content-type header field.) If it is not plain text, then the body is not directly displayed; instead, an external program called metamail is invoked. The metamail program is a simple switch that compares the content-type of the current message to a configuration file (mailcap file) that tells how various types of mail can be handled at the local site. If a handler is found for the current message type, the message is passed off to that handler for presentation to the user. Otherwise the user is informed about the unrecognized data, rather than shown the (probably incomprehensible) raw data stream. Given this mechanism, it is easy to integrate computational email into a wide variety of mail-reading agents. Once those agents have been modified to use the metamail software, as described above, it is simply a matter of installing an interpreter for the computation mail language, and adding an appropriate line to the local mailcap file. ATOMICMAIL: A Practical System for Computational Email In accordance with the ideas described above, the author has designed a language suitable for embedding computation in electronic mail, known as ATOMICMAIL.2 The ATOMICMAIL software is designed to provide a secure and portable language for distributed applications that use electronic mail as a transport mechanism, or implement what might be called "User to User Remote Procedure Call." ATOMICMAIL Language Definition ATOMICMAIL uses LISP [Steele, 1990] as its basic language model. There is nothing essential about LISP for this purpose, although it is a very clean interpreted language, which eases the validation of the security mechanisms. (It would be considerably harder to be sure about the security of a compiled language, and particularly one like C [Kernighan and Ritchie, 1988] that includes mechanisms (e.g. pointers) for accessing arbitrary memory locations.) Of course, LISP is just a starting point. As mentioned before, all input and output facilities were removed from the basic language and replaced with input and output mechanisms that did not compromise security and that were portable to virtually any user interaction environment. Thus, for example, LISP's READ primitive is gone, but new primitives such as GETSTRING and GETBOOLEAN are defined. Similarly, new file system primitives permit a strictly limited access to a circumscribed local file system. A complete specification of the ATOMICMAIL language is too lengthy and detailed to be included here. The language is, however, rigorously specified in [Borenstein, 1990]. Figure 1 shows a small ATOMICMAIL program. The Bellcore Prototype ATOMICMAIL Interpreter Although a computational email language should be designed for portability and abstraction of user interface, an implementation (interpreter) must inevitably be grounded in some particular user interaction environment. Based on the realities of the heterogeneous environment at Bellcore, the initial ATOMICMAIL interpreter was written to use the curses library [Arnold, 1984] for its user interface. The prototype interpreter will, therefore, run on any machine that is (or can emulate) a UNIX terminal. Under window systems such as X11, a terminal emulator window is used. This architecture clearly sacrifices a good deal of potential usability, but it ensures that the facilities of computational email will be available to the widest possible number of users. A graphical (X11) interpreter for the same ATOMICMAIL language is also planned. The prototype ATOMICMAIL interpreter uses, as its basic LISP engine, the Embedded LISP Interpreter (ELI) from the Andrew Message System [Borenstein, 1991a]. Like any network service, the implementation of a computational email system may be less secure than its specification. A great deal of attention has been paid, in the design of ATOMICMAIL, to ensure that there would be no serious security problems in a hypothetical perfect implementation. No claims are made, however, that the prototype is such a perfect implementation. It seems likely that an ATOMICMAIL implementation is neither more nor less likely to contain unexpected and accidental security risks than any other network service software. Figures 2 through 4 show the prototype ATOMICMAIL interpreter at work. As of September, 1991, the ATOMICMAIL software has been deployed in at least four different laboratories at Bellcore. It is available to universities with a royalty-free license for non-commercial use. Initial Uses of ATOMICMAIL The initial deployment of ATOMICMAIL has demonstrated that computational email can be made to work portably and securely. It has not, however, proven that such a mechanism is worthwhile. Before such a claim can be made, it is necessary to have one or more substantial applications that are highly valued by the user community. While it is too early to evaluate their overall utility, six applications have been prototyped at Bellcore: a survey generator, a meeting scheduler, a document distributor, an information finder, an activist alert mechanism, and a distributed mail-based game. The survey generator is a tool for generating simple surveys with ATOMICMAIL. With this tool, the user simply enters a set of questions (fill in the blank, multiple choice, etc.) and the mail addresses to which he wants the questions sent. The recipients are surveyed interactively by an ATOMICMAIL message, which then sends the response back as normal electronic mail, or (optionally) sends it to a process which collates the results and sends back only a high-level summary. The meeting scheduler allows the person calling a meeting to specify the purpose of the meeting, a list of participants, and a set of possible dates and times for the meeting. Each participant is surveyed via ATOMICMAIL, and the results are collected and returned to the originator as a summary that quickly shows which times, if any, everyone can make it. The document distributor is a tool that makes it easy for someone who is distributing documents to generate an ATOMICMAIL message that offers recipients a scrollable list of document titles. When a recipient selects a title, he is shown an abstract of the document and asked whether he wants to order it. Orders are sent to a designated "fulfillment" address via normal electronic mail. The information finder is an application that maintains a database of expertise within an organization. Users are encouraged to send questions on any topic to the information finder, which will use ATOMICMAIL to ask the question of one or more relevant experts. If the experts don't know the answers, they are asked to suggest other experts, who are then surveyed in turn. This process continues, spreading out to more specialized and possibly more distant experts, until an answer is obtained that satisfies the user. The activist alert mechanism is a program that shows its recipient a brief text explaining a "hot" political issue. It then asks if the user wants to lobby his or her elected officials on this topic. If the user assents, the program verifies the names of the user's elected representatives, and either generates a paper copy of a letter to those representatives or sends a fax to them directly. Finally, it asks the user if there are any other people to whom the alert should be redistributed. The "Name That Tune" game is an ATOMICMAIL version of the familiar game show. All of the "bidding" steps in the game are conducted via ATOMICMAIL. In the final step of the game, a multipart message, including both audio and ATOMICMAIL, is used to play the tune and ask the user to name it. Earlier, ATOMICMAIL was also used to prototype another mail-related service, dynamic mailing lists. In this service, a message to a mailing list contained, in addition to its normal text, an ATOMICMAIL component that asked people whether or not they wanted to take part in further discussions on the same topic. In this case, although ATOMICMAIL facilitated a quick prototype, it soon became obvious that the functionality was better accomplished by modifying the message reading software so that even plain text messages could be the start of new dynamic mailing lists. Future Work There are many directions for the future of ATOMICMAIL. Beyond additional and enhanced ATOMICMAIL application services, there are several other promising directions for future work. A graphical interpreter for the current ATOMICMAIL language would both further demonstrate the interface- independence of the language and make the execution of ATOMICMAIL programs much more pleasant for those who could use it. By incorporating cryptographic techniques and digital signatures, it should be possible to extend ATOMICMAIL's capabilities to allow users to permit more dangerous actions to be executed when the mail is authenticated as coming from a trusted source. Another direction for extension would be to relax somewhat the assumptions about user interface environments. For example, an ATOMICMAIL-like language that presumed the presence of a bitmap display might permit substantially more interesting applications to be developed. Overall, there is no shortage of promising new directions for research on computational electronic mail. Acknowledgements The ATOMICMAIL project has been made possible by the enlightened management with which Bellcore is generally blessed. The development of the language and the prototype software has benefited greatly from the many clever people who have helped me with useful suggestions and encouragement, including Bob Kraut, Al Buzzard, Jonathan Rosenberg, Louis Gomez, John Patterson, Steve Rohall, Ralph Hill, Will Leland, Peter Clitherow, Shoshana Hardt-Kornacki, Steve Uhler, Mike Bianchi, Scott Stornetta, Michael Littman, Ron Underwood, Mike O'Dell, Nat Howard, Dana Chee, Mark Segal, Steve Butera, Dave Sincoskie, Mark Donadio, Laurence Brothers, and, no doubt, others whom I have inadvertently omitted. References [Ackerman and Malone, 1990] Ackerman, M. and Malone, T., "Answer Garden: A Tool for Growing Organizational Memory", Proceedings of the Conference on Office Information Systems, Cambridge, Massachusetts, 1990] [Anderson and Gillogly, 1976] Anderson, R. H., and J. J. Gillogly, "Rand Intelligent Terminal Agent (RITA): Design Philosophy", Rand Corporation Technical Memorandum R-1809-ARPA, February, 1976. [Arnold, 1984] Arnold, Kenneth C. R. C., "Screen Updating and Cursor Movement Optimization: A Library Package", UNIX Programmer's Manual Supplementary Documents, USENIX Association, 1984. [Borenstein, 1990] Borenstein, Nathaniel S., "MAGICMAIL Language Reference Manual", Bellcore Technical Memorandum. [Borenstein, 1991a] Borenstein, Nathaniel S., and Chris A. Thyberg, "Power, Ease of Use, and Cooperative Work in a Practical Multimedia Message System", International Journal of Man-Machine Studies, April, 1991. [Borenstein, 1991b] Borenstein, Nathaniel S., "Multimedia Electronic Mail: Will the Dream Become Reality?", Communications of the ACM, April, 1991. [Forsdick, 1984] Forsdick, H.C., Thomas, R.H., Robertson, G. G., and Travers, V. M., "Initial Experience with Multimedia Documents in Diamond", Computer Message Service, Proceedings IFIP 6.5 Working Conference, IFIP, 1984. [Grudin, 1990] Grudin, J., "Seven plus one challenges for Groupware Developers", Rev. of DAIMI PB 323 Aarhus University Computer Science Department. [Hansen, 1990] Hansen, W. Fred, "Enhancing Documents with Embedded Programs: How Ness Extends Insets in the Andrew Toolkit", Proceedings of IEEE Computer Society 1990 International Conference on Computer Languages, New Orleans, 1990. [Hogg, 1985] Hogg, John, "Intelligent Message Systems", in Office Automation, D. Tsichritzis, editor, Springer-Verlag, 1985. [Kernighan and Ritchie, 1978] Kernighan, Brian W., and Dennis M. Ritchie, The C Programming Language, Prentice-Hall, 1978. [Shepherd, 1990] Shepherd, Allan, Niels Mayer, and Allan Kuchinsky, "Strudel -- An Extensible Electronic Conversation Toolkit", Proceedings of CSCW '90, October, 1990. [Spafford, 1989] Spafford, Eugene H., "The Internet Worm: Crisis and Aftermath," Communications of the ACM, June, 1989. [Steele, 1990] Steele, Guy L., Common Lisp: The Language, Second Edition, Digital Press, 1990. [Vittal, 1981] Vittal, John, "Active Message Processing: Messages as Messengers", in Computer Message Systems, R. P. Uhlig, editor, North-Holland Publishing Company, 1981. Figures Figure 1 -- program code for a simple survey Figure 2 -- The ATOMICMAIL help screen Figure 3 -- An ATOMICMAIL survey 1It should be noted that no ethically-trained software engineer would ever consent to write a "DestroyBaghdad" procedure. Basic professional ethics would instead require him to write a "DestroyCity" procedure, to which "Baghdad" could be given as a parameter. 2The original name for this language was MAGICMAIL, which stands for "Messages that are Active Generate Innovation and Cooperation, but Mustn't Allow Internet Larceny." Unfortunately, a trademark was unavailable, so the language has been renamed ATOMICMAIL, which stands for "A Trademark On MAGICMAIL is Impossible; Clearly Monikers Are Inhibited by Legalisms."