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]