draft A Model for Enabled Mail (EM) Oct 1993 A Model for Enabled Mail (EM) Sun Oct 3 15:40:50 1993 Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us Nathaniel Borenstein Bellcore nsb@bellcore.com Status of this Memo This document is a working draft. Do not cite, copy, or circulate. [Page 1] draft A Model for Enabled Mail (EM) Oct 1993 1. Introduction This memo defines an enhancement, termed Enabled Mail (EM), to the message handling model used in computer-communications systems. The memo begins by describing the traditional model for message handling. Next, an enhancement to the model is suggested which augments the final delivery process with additional services. Finally, specific technology choices are recommended for experimental purposes within the Internet community. 2. The Traditional Model for Message Handling In 1979, the International Federation for Information Processing (IFIP), a pre-standards organization, developed a model for message handling. This model was eventually adopted and expanded by the the International Telephone and Telegraph Consultative Committee (CCITT), which developed the X.400 series of recommendations. Pictorially, the message handling model is organized thusly: +----+ messaging +----+ | UA | - - - - - - - - - - - - - - - -> | UA | +----+ +----+ | /|\ | | | posting | delivery |--------- |---------- | | | | +---|---------------------------------------------+ | | MTS | | | \|/ | | | +-----+ +-----+ +-----+ | | | MTA | --> | MTA | --> ... --> ... --> | MTA | | | +-----+ +-----+ relaying +-----+ | | | +-------------------------------------------------+ As shown here, electronic mail messages are transported by a "message transfer system" (MTS), which is composed of one or more "message transfer agents" (MTAs). The message transfer system is distributed in nature, and not under a single [Page 2] draft A Model for Enabled Mail (EM) Oct 1993 administrative entity; in contrast, a collection of message transfer agents are usually controlled by a single administrative entity. At the edges of the system, a "user agent" (UA) acts on behalf of a user to interact with the local message transfer agent. From the perspective of the message transfer system, the electronic mail message being sent is called the "content", and all delivery information associated with the message is called the "envelope". In theory, the message transfer system is ignorant of the structure of the content it transports; the user agents bilaterally agree as to what this structure is. Although there are no strict requirements as to the structure, there are usually two components in each electronic mail message: control information (often called the "headers"), and data information (often called the "body"). A convenient way of thinking about all these terms is: o the envelope is meaningful to the message transfer agents; o the headers are meaningful to the user agents; and, o the body is meaningful to the users (which may be people or programs). When an electronic mail message is sent from one user to another, the following activities occur: the originator indicates to the user agent the address of the recipient; the user agent places the destination address and the sender's address into the envelope and then posts the message through a "posting slot" to a message transfer agent, which involves a posting protocol in which the validity of those addresses and the syntax of the electronic mail message are considered. Upon successful completion of the submission protocol, the message transfer agent accepts responsibility either to deliver the electronic mail message, or, if so requested and if delivery fails, to inform the originator of the failure by generating an "error report". After accepting responsibility to deliver the electronic mail message, a message transfer agent must decide if it can deliver the message directly to the recipient; if so, it delivers the electronic mail message through a "delivery slot" to the recipient's user agent, using a delivery protocol. If [Page 3] draft A Model for Enabled Mail (EM) Oct 1993 not, it contacts an adjacent message transfer agent, which is closer to the recipient, and negotiates transfer of the electronic mail message. This process repeats until some message transfer agent is able to deliver the electronic mail message, or some message transfer agent determines that the message is undeliverable. To summarize, there are three general protocols involved in the model: o a "messaging" protocol used between two user agents; o a "relaying" protocol used between two message transfer agents; and, o "submission/delivery" protocol used between a message transfer agent and a user agent. In the Internet community, RFC 822 [1] and MIME [2,3] define the messaging protocol, whilst SMTP [4] defines the relaying protocol. Submission and delivery protocols are considered a local matter, although it is common to use SMTP for submission and DMSP [5], IMAP2 [6], or POP3 [7] for delivery. [Page 4] draft A Model for Enabled Mail (EM) Oct 1993 3. Enhancing the Model with Enabled Mail The Enabled Mail (EM) enhancement to the model occurs during and after delivery processing. Specifically, the model is enhanced by viewing the delivery process as consisting of three distinct phases: o "delivery-time", which occurs immediately before the message crosses the delivery slot; o "receipt-time", which occurs immediately after the message crosses the delivery slot; and, o "activation-time", which occurs whenever the recipient processes the message. (Traditionally, activation-time is the realm of mail enabled applications.) In each of these phases, a user-defined program may be evaluated, each with a different execution environment. 3.1. The Delivery-Time EM Phase Immediately before the message crosses the delivery-slot, a program defined by the originator, if present in the message, is evaluated by the message transfer agent performing final delivery. Such a program has access to the message being delivered and its envelope, can engage in a negotiation process with the recipient's user agent, but has no interactive access to the recipient. An example of a program evaluated during Delivery-Time EM would be something which automatically sends a delivery acknowledgement to the originator. Note that any program transported through the message transfer system must be evaluated in a "execution-safe" environment, one in which arbitrary programs, written by an unknown or hostile party, can be evaluated without any possibility of system compromise. [Page 5] draft A Model for Enabled Mail (EM) Oct 1993 3.2. The Receipt-Time EM Phase Immediately after the message crosses the delivery slot, a program defined by the recipient, if present in the recipient's local configuration, is evaluated by the recipient's UA. Such a program has access to the message being delivered and its envelope, but has no interactive access to the recipient. An example of a program evaluated during Receipt-Time EM would be something which automatically files a message into one or more folders, based on originator and subject. Note that the program evaluated during Receipt-Time EM is provided by the recipient, and, if properly coded, should be safe for execution in the recipient's environment. This is often a necessity, as many receipt-time EM activities are likely to require the recipient's privileges when accessing system resources. 3.3. The Activation-Time EM Phase Whenever the recipient processes the message, e.g., for rendering, a program defined by the originator, if present, is evaluated by the recipient's UA. Such a program does not have access to the message or its envelope, but may have interactive access to the recipient, or to some particular body parts of the message. An example of a program evaluated during Activation-Time EM would be something which queries the user for some information and then sends the response back to the originator. Note that any program transported through the message transfer system must be evaluated in a "execution-safe" environment, one in which arbitrary programs, written by an unknown or hostile party, can be evaluated without any possibility of comprising either the system or the user's environment. [Page 6] draft A Model for Enabled Mail (EM) Oct 1993 4. An Experiment in EM for the Internet Community In order to foster interoperability, this memo recommends the following EM technology choices for the Internet community. 4.1. Delivery-Time EM If during final delivery, the message transfer agent determines that the message is of content-type "multipart/enabled-mail" [8], then the Delivery-Time EM phase is entered. When this phase terminates, the entire message is delivered to the recipient's user agent. This content-type contains two parts, the first is an arbitrary content-type, and the second is of content-type "application/safe-tcl" with parameter "evaluation- time=delivery". Safe-Tcl [8] is a subset of the Tcl [9] environment which is believed to be safe for evaluating programs written by an unknown or hostile party. 4.2. Receipt-Time EM If the recipient's user agent has been configured to evaluate a Tcl script when messages are received, then the Receipt-Time EM phase is entered whenever final delivery occurs for that recipient. The Tcl script will be evaluated with the recipient's privileges. In addition to the standard Tcl environment, the Tcl procedures and variables defined in Sections 4.2, 4.3, and 4.4 of [8] are available. Further, the Tcl environment may be augmented by platform-specific enhancements, in order to provide a richer evaluation environment to the user's Tcl script. Note that no recipient-interaction is possible during Receipt-Time EM, as such any attempts at user interaction will always generate an error during Receipt-Time EM. [Page 7] draft A Model for Enabled Mail (EM) Oct 1993 4.3. Activation-Time EM The Activation-Time EM phase occurs whenever the recipient renders a MIME entity containing the "application/safe-tcl" content-type and having a parameter value of "evaluation- time=activation". 4.4. Configuration Information A user agent participating in EM provides configuration information to the local message transfer agent. This information includes, but is not limited to: (1) customization information for Safe-Tcl's getconfigdata primitive; (2) size and time limits for the Delivery-Time, Receipt-Time, and Activation-Time EM phases; (3) a Tcl script to be evaulated during Receipt-Time EM; and, (4) a collection of user-defined Tcl scripts, for use during EM. [Page 8] draft A Model for Enabled Mail (EM) Oct 1993 5. Security Considerations Delivery-Time EM and Activation-Time EM should occur in "execution-safe" environments. Any technology choice used for either of these phases should be the subject of intense scrutiny. 6. Acknowledgements Einar Stefferud of Network Management Associates suggested the names used to denote the three phases of EM. 7. Authors' Addresses Nathaniel S. Borenstein MRE 2D-296 Bellcore 445 South Street Morristown, NJ 07962-1910 US Phone: +1 201 829 4270 Fax: +1 201 829 5963 Email: nsb@bellcore.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US Phone: +1 415 968 1052 Fax: +1 415 968 2510 Email: mrose@dbc.mtview.ca.us [Page 9] draft A Model for Enabled Mail (EM) Oct 1993 8. References [1] Crocker, D.H., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August, 1982. [2] Borenstein, N. and N. Freed, "MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June, 1992. [3] Moore, K.. "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, Unviersity of Tennessee, June, 1992. [4] Postel, J.B., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August, 1982. [5] Lambert, M.L., "PCMAIL: A Distributed Mail System for Personal Computers", RFC 1056, MIT, June, 1988. [6] Crispin, M.R., "Interactive Mail Access Protocol: Version 2", RFC 1176, University of Washington, August, 1990. [7] Rose, M.T., "Post Office Protocol: Version 3", RFC 1225, Dover Beach Consulting, Inc. June, 1993. [8] Borenstein, N. and M.T. Rose, "MIME Extensions for Mail- Enabled Applications: application/Safe-Tcl and multipart/enabled-mail", Draft in preparation, Bellcore, Dover Beach Consulting, September, 1993. [9] Ousterhout, J., Tcl and the Tk Toolkit, Addison-Wesley, (to appear in 1993). [Page 10] draft A Model for Enabled Mail (EM) Oct 1993 Appendix A. Usage Example: Receipt-Time EM Here is a brief example of a program that might be evaluated during the Receipt-Time EM phase: MIME_savemsg mailbox "mhbox/INCOMING" if {(([set id [SafeTcl_getheader "Resent-Message-ID"]] != "") || ([set id [SafeTcl_getheader "Message-ID"]] != "")) && ![catch { set file [open ".message-id" "a+"] }]} { seek $file 0 start while {[gets $file line] >= 0} { if {"$line" == "$id"} { close $file exit 0 } } puts $file "$id" close $file } MIME_savemsg mailbox ... exit First, the incoming message is appended to the user's mailbox named "mhbox/INCOMING". Next, a check is made to see if this message was received before. If so, the program terminates. Otherwise, the incoming message is appended to the user's default mailbox. Finally, other commands might be executed prior to the program's termination. [Page 11] draft A Model for Enabled Mail (EM) Oct 1993 Table of Contents 1 Introduction .......................................... 2 2 The Traditional Model for Message Handling ............ 2 3 Enhancing the Model with Enabled Mail ................. 5 3.1 The Delivery-Time EM Phase .......................... 5 3.2 The Receipt-Time EM Phase ........................... 6 3.3 The Activation-Time EM Phase ........................ 6 4 An Experiment in EM for the Internet Community ........ 7 4.1 Delivery-Time EM .................................... 7 4.2 Receipt-Time EM ..................................... 7 4.3 Activation-Time EM .................................. 8 4.4 Configuration Information ........................... 8 5 Security Considerations ............................... 9 6 Acknowledgements ...................................... 9 7 Authors' Addresses .................................... 9 8 References ............................................ 10 A. Usage Example: Receipt-Time EM ..................... 11 [Page 12]