often be the case that the same document will be sent to more than
one recipient. Since the document portion can usually be expected
to be the major part of the message, much repeated data would be
sent if a copy of the document for each recipient were to be shipped
in the message-bag.
To avoid this redundancy, messages may be assembled in the
message-bag so that actual data appears on its first occurrence and
only references to it appear in later occurrences. When data is
shared, the first occurrence of the data will be tagged, and later
locations where the data should appear will only reference the
earlier tagged location. All references to copied data point to
earlier locations in the message-bag. The data to be retrieved is
indicated by the tag.
This is a very general sharing mechanism. PLEASE NOTE THAT THE MPM
WILL NOT SUPPORT THE FULL USE OF THIS MECHANISM. THE MPM WILL ONLY
SUPPORT SHARING OF WHOLE DOCUMENTS. No other level of sharing will
be supported by the MPMs.
This sharing mechanism may be used within a document as long as all
references refer to tags within the same document.
Sharing is implemented by placing a share-tag on the first
occurrence of the data to be shared, and placing a share-reference
at the locations where copies of that data should occur.
+------+------+------+
12 Share Tag | 12 | share-index |
+------+------+------+
+------+------+------+
13 Share Reference | 13 | share-index |
+------+------+------+
Element code 12 (S-TAG) is a share tag element. The two octets
following the type-octet specify the shared data identification code
for the following data element. Note that s-tag is not a DATA
element, in the sense that data elements encode higher level
objects.
Element code 13 (S-REF) is a share reference element. The two
Postel [Page 31]
August 1980
Internet Message Protocol
Specification
octets following the type-octet specify the referenced shared data
identification code.
An example of using this mechanism is
( ( <a>, <b> ) ( <c>, <b> ) )
could be coded as follows to share <b>
( ( <a>, <s-tag-1><b> ) ( <c>, <s-ref-1> ) )
To facilitate working with structures which may contain shared data,
the two high-order bits of the list and property list element codes
are reserved for indicating if the structure contains data to be
shared or contains a reference to shared data. That is, if the
high-order bit of the list or property list element code octet is
set to one then the property list contains a share-reference to
shared data. Or, if the second high-order bit is set to one the
structure contains a share-tag for data to be shared.
The example above is now repeated in detail showing the use of the
high-order bits.
+------+------+------+------+------+------+------+------+
|11 - 9|01 - 9| <a> | 12 | 0 | 1 | <b> | 11 |
+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+
|10 - 9| <c> | 13 | 0 | 1 | 11 | 11 |
+------+------+------+------+------+------+------+
It is not considered an error for an element to be tagged but not
referenced.
A substructure with internal sharing may be created. If such a
substructure is closed with respect to sharing -- that is, all
references to its tagged elements are within the substructure --
then there is no need for the knowledge of the sharing to propagate
up the hierarchy of lists. For example, if the substructure is:
00-LIST ( a b c b )
which with sharing is:
11-LIST ( a T1:b c R1 )
When this substructure is included in a large structure the high
[Page 32] Postel
August 1980
Internet Message Protocol
Specification
order bits can be reset since the substructure is closed with
respect to sharing. For example:
00-LIST ( x 11-LIST ( a T1:b c R1 ) y )
Note: While sharing adds transmission and memory efficiency, it is
costly in processing to separate shared elements. This is the main
reason for restricting the sharing supported by the MPM. At some
later time these restrictions may be eased.
It is possible to create loops, "strange loops" and "tangled
hierarchies" using this mechanism [32]. The MPM will not check for
such improper structures within documents, and will not deliver
messages involved in such structures between documents.
If an encryption scheme is used to ensure the privacy of
communication it is unlikely that any parts of the message can be
shared. This is due to the fact that in most case the encryption
keys will be specific between two individuals. There may be a few
cases where encrypted data may be shared. For example, all the
members of a committee may use a common key when acting on committee
business, or in a public key scheme a document may be "signed" using
the private key of the sender and inspected by anyone using the
public key of the sender.
Postel [Page 33]
August 1980
Internet Message Protocol
[Page 34] Postel
August 1980
Internet Message Protocol
4. OTHER ISSUES
This section discusses various other issues that need to be dealt with
in a computer message system.
4.1. Accounting and Billing
Accounting and billing must be performed by the MPM. The charge to
the user by the message delivery system must be predictable, and so
cannot depend on the actual cost of sending a particular message which
incurs random delays, handling and temporary storage charges. Rather,
these costs must be aggregated and charged back to the users on an
average cost basis. The user of the service may be charged based on
the destination or distance, the length of the message, type of
service, or other parameters selected as the message is entered into
the delivery system, but must not depend on essentially random
handling by the system of the particular message.
This means it is pointless to have each message carry an accumulated
charge (or list of charges). Rather, the MPM will keep a log of
messages handled and periodically bill the originators of those
messages.
It seems that the most reasonable scheme is to follow the practice of
the international telephone authorities. In such schemes the
authority where the message originates bills the user of the service
for the total charge. The authorities assist each other in providing
the international message transfer and the authorities periodically
settle any differences in accounts due to an imbalance in
international traffic.
Thus the MPMs will keep logs of messages handled and will periodically
charge their neighboring MPM for messages handled for them. This
settlement procedure is outside the message system and between the
administrators of the MPMs.
As traffic grows it will be impractical to log every message
individually. It will be necessary to establish categories of
messages (e.g., short, medium, large) and only count the number in
each category.
The MPM at the source of the message will have a local means of
identifying the user to charge for the message delivery service. The
relay and destination MPMs will know which neighbor MPMs to charge (or
settle with) for delivery of their messages.
Postel [Page 35]
August 1980
Internet Message Protocol
Other Issues
4.2. Addressing and Routing
The mailbox provides for many types of address information. The MPMs
in the ARPA internet can most effectively use the internet address
[2]. The use of other address information is not yet very clear.
Some thoughts on addressing issues may be found in the references
[33,34,35].
An MPM sometimes must make a routing decision when it is acting as a
relay-MPM (or source MPM). It must be able to use the information
from the mailbox to determine to which of its neighbor MPMs to send
the message. One way this might be implemented is to have a table of
destination networks with corresponding neighbor MPM identifiers to
use for routing toward that network.
It is not expected that such routing tables would be very dynamic.
Changes would occur only when new MPMs came into existence or MPMs
went out of service for periods of days.
Even with relatively slowly changing routing information the MPMs need
an automatic mechanism for adjusting their routing tables. The
routing problem here is quite similar to the problem of routing in a
network of packet switches such as the ARPANET IMPs or a set of
internet gateways. A great deal of work has been done on such
problems and many simple schemes have been found faulty. There are
details of these procedures which may become troublesome when the
number of nodes grows beyond a certain point or the frequency of
update exchanges gets large.
A basic routing scheme is to have a table of <network-name,
mpm-identifier> pairs. The MPM could look up the network name found
in the mailbox of the message and determine the internet
mpm-identifier of the next MPM to which to route the message. To
permit automatic routing updates another column would be added to
indicate the distance to the destination. This could be measured in
several ways, for example, the number of relay MPM (or hops) to the
final destination. In this case each entry in the table is a triple
of <network-name, mpm-identifier, distance>.
To update the routing information when changes occur an MPM updates
its table. It then sends to each next MPM in its table a table of
pairs <network-name, distance>, which say in effect "I can get a
message to each of these networks with "cost" distance." An MPM which
receives such an update will add to all the distances the distance to
the MPM sending the update (e.g., one hop) and compare the information
with its own table.
[Page 36] Postel
August 1980
Internet Message Protocol
Other Issues
If the update information shows that the distance to a destination
network is now smaller via the MPM which sent the update, the MPM
changes its own table to reflect the better route, and the new
distance. If the MPM has made changes in its table it sends update
information to all the MPMs listed as next-MPMs in its table.
One further feature is that when a new network comes into existence an
entry must be added to the table in each MPM. The MPMs should
therefore expect the case that update information may contain entries
which are new networks, and in such an event add these entries to
their own tables.
When a new MPM comes into existence it will have an initial table
indicating that it is a good route (short distance) to the network it
is in, and will have entries for a few neighbor networks. It will
send an initial "update" to those neighbor MPMs which will respond
with more complete tables, thus informing the new MPM of routes to
many networks.
This routing update mechanism is a simple minded scheme and may have
to be replaced as the system of MPMs grows. In addition it ignores
the opportunity for MPMs to use other information (besides destination
network name) for routing. MPMs may have tables that indicate
next-MPMs based on city, telephone number, organization, or other
categories of information.
4.3. Encryption
It is straightforward to add the capability to have the document
portion of messages either wholly or partially encrypted. An
additional basic data element is defined to carry encrypted data. The
data within this element may be composed of other elements, but that
could only be perceived after the data was decrypted.
+------+------+------+------+
14 Encrypt | 14 | octet count |
+------+------+------+------+
+------+------+------+-------
|alg id| key id | Data ...
+------+------+------+--------
Element code 14 (ENCRYPT) is used to encapsulate encrypted data. The
format is the one-octet type code, the three-octet octet count, a
one-octet algorithm identifier, a two-octet key identifier, and count
octets of data. Use of this element indicates that the data it
Postel [Page 37]
August 1980
Internet Message Protocol
Other Issues
contains is encrypted. The encryption scheme is indicated by the
algorithm identifier, and the key used is indicated by the key
identifier (this is not the key itself). The NBS Data Encryption
Standard (DES) [36], public key encryption [37,38,39], or other
schemes may be used.
To process this data element, the user is asked for the appropriate
key and the data can then be decrypted. The data thus revealed will
be in the form of complete data element fields. Encryption cannot
occur over a partial field. The revealed data is then processed
normally.
Note that there is no reason why all fields of a document could not be
encrypted including all document header information such as From,
Date, etc.
[Page 38] Postel
August 1980
Internet Message Protocol
5. THE MPM: A POSSIBLE ARCHITECTURE
The heart of the internet message system is the MPM which is responsible
for routing and delivering messages. Each network must have at least
one MPM. These MPMs are logically connected together, and internet mail
is always transferred along logical channels between them. The MPMs
interface with existing local message systems.
Since the local message system may be very different from the internet
system, special programs may be necessary to convert incoming internet
messages to the local format. Likewise, messages outgoing to other
networks may be converted to the internet format and sent via the MPMs.
5.1. Interfaces
User Interface
It is assumed that the interface between the MPM and the UIP
provides for passing data structures which represent the document
portion of the message. In addition, this interface must pass the
delivery address information (which becomes the information in the
mailbox field of the command). It is assumed that the information
is passed between the UIP and the MPM via shared files, but this is
not the only possible mechanism. These two processes may be more
strongly coupled (e.g., by sharing memory), or less strongly coupled
(e.g., by communicating via logical channels).
When a UIP passes a document and a destination address to the MPM,
the MPM assigns a transaction-number and forms a message to send.
The MPM must record the relationship between the transaction-number,
the document, and the UIP, so that it can inform the UIP about the
outcome of the delivery attempt for that document when the
acknowledgment message is received at some later time.
Assuming a file passing mode of communication between the UIP and
the MPM the sending and receiving of mail might involve the
following interactions:
A user has an interactive session with a UIP to compose a document
to send to a destination (or list of destinations). When the user
indicates to the UIP that the document is to be sent, the UIP
places the information into a file for the MPM. The UIP may then
turn to the next request of the user.
The MPM finds the file and extracts the the information. It
creates a message, assigning a transaction-number and forming a
deliver command. The MPM records the UIP associated with this
message. The MPM sends the message toward the destination.
Postel [Page 39]
August 1980
Internet Message Protocol
MPM Architecture
When the MPM receives a deliver message from another MPM addressed
to a user in its domain, it extracts the document and puts it into
a file for the UIP associated with the destination user. The MPM
also sends an acknowledge message to the originating MPM.
When the MPM receives an acknowledgment for a message it sent, the
MPM creates a notification for the associated UIP and places it in
a file for that UIP.
The format of these files is up to each UIP/MPM interface pair.
One reasonable choice is to use the same data structures used in
the MPM-MPM communication.
Communication Interface
It is assumed here that the MPMs use an underlying communication
system, and TCP [3] has been taken as the model. In particular, the
MPM is assumed to be listening for a TCP connection on a TCP port,
i.e., it is a server process. The port is either given explicitly
in the mpm-identifier or takes the default vaule 45 (55 octal) [4].
Again, this is not intended to limit the implementation choices;
other forms of interprocess communication are allowed, and other
types of physical interconnection are permitted. One might even use
dial telephone calls to interconnect MPMs (using suitable protocols
to provide reliable communication) [12,19,20,21].
5.2. The MPM Organization
Messages in the internet mail system are transmitted in lists called
message-bags (or simply bags), each bag containing one or more
messages. Each MPM is expected to implement functions which will
allow it to deliver local messages it receives and to forward
non-local ones to other MPMs presumably closer to the message's
destination.
Loosely, each MPM can be separated into six components:
1--Acceptor
Receives incoming message-bags, from other MPMs, from UIPs, or
from conversion programs.
2--Message-Bag Processor
Splits a bag into these three portions:
[Page 40] Postel
August 1980
Internet Message Protocol
a. Local Host Messages
b. Local Net Messages
c. Foreign Net Messages
3--Local Host Delivery
Delivers local host messages, may call on conversion program.
4--Local Net Delivery
Delivers local net messages, may call on conversion program.
5--Foreign Net Router
Forms message-bags for transmission to other MPMs and determines
the first step in the route.
6--Foreign Net Sender
Activates transmission channels to other MPMs and sends
message-bags to foreign MPMs.
If the local net message system uses the protocol of the MPMs, then
there need be no distinction between local net and foreign net
delivery procedures.
All of these components can be thought of as independent. The
function of the Acceptor is to await incoming message-bags and to
insert them into the Bag-Input Queue.
The Bag-Input queue is read by the message-bag Processor which will
separate and deliver suitable portions of the message-bags it
retrieves from the queue to one of three queues:
a. Local Host Queue
b. Local Net Queue
c. Foreign Net Queue
When an MPM has a message to send to another MPM, it must add its own
handling-stamp to the trace field of the command. The trace then
becomes a record of the route the message has taken. An MPM should
examine the trace field to see if the message is in a routing loop.
All commands require the return of the trace as a trail in the
matching reply command.
All of these queues have as elements complete message-bags created by
selecting messages from the input message-bags.
Postel [Page 41]
August 1980
Internet Message Protocol
The Local Host queue serves as input to the Local Host Delivery
process. This component is responsible for delivering messages to its
local host. It may call on a conversion program to reformat the
messages into a form the local protocol will accept. This will
probably involve such things as copying shared information.
The Local Net queue serves as input to the Local Net Delivery process.
This component is responsible for delivering messages to other hosts
on its local net. It must be capable of handling whatever error
conditions the local net might return, and should include the ability
to retransmit. It may call on a conversion program to reformat the
messages into a form the local protocol will accept. This will
probably involve such things as copying shared information.
The other two processes are more closely coupled. The Foreign Net
Router takes its input bags from the Foreign Net Queue. From the
internal information it contains, it determines which of the MPMs to
which it is connected should receive the bag.
It then places the bag along with the routing information into the
Send Mail Queue. The Foreign Net Sender retrieves it from that queue
and transmits it across a channel to the intended foreign MPM. The
Sender aggregates messages to the same next MPM into a bag.
The Foreign Net Router should be capable of receiving external input
to its routing information table. This may come from the Foreign Net
Sender in the case of a channel going down, requiring a decision to
either postpone delivery or to determine a new route. The Router is
responsible for maintaining sufficient information to determine where
to send any incoming message-bag.
Forwarding
An MPM may have available information on the correct mailboxes of
users which are not at its location. This information, called a
forwarding data base, may be used to return the correct address in
response to a probe command, or to actually forward a deliver
command (if allowed by the type of service).
Because such forwarding may cause the route of a message to pass
through an MPM already on the trace of this message, only the
portion of the trace back to the most recent forward action should
be used for loop detection by a relay relaying MPM, and only the
forward action entries in the trace should be checked by a
forwarding MPM.
[Page 42] Postel
August 1980
Internet Message Protocol
Implementation Recommendations
Transaction numbers can be assigned sequentially, with wrap around
when the highest value is reached. This should ensure that no
message with a particular transaction number from this source is in
the network when another instance of this transaction number is
chosen.
The processing to separate shared elements when the routes of the
shared elements diverge while still preserving the sharing possible
appears to be an O(N*M**2) operation where N is the number of
distinct objects in a message which may be shared across message
boundaries and M is the number of messages in the bag.
Also note that share-tags may be copied into separate message bags
which are not referenced. These could be removed with another pass
over the message bag.
Postel [Page 43]
August 1980
Internet Message Protocol
[Page 44] Postel
August 1980
Internet Message Protocol
6. EXAMPLES & SCENARIOS
Example 1: Message Format
Suppose we want to send the following message:
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIE>
Subject: Meeting Thursday
To: Danny Cohen <Cohen@USC-ISIB>
CC: Linda
Danny:
Please mark your calendar for our meeting Thursday at 3 pm.
--jon.
It will be encoded in the structured format. The following will
present successive steps in the top down generation of this message.
The actual document above will not be shown in the coded form.
1. message
2. (identification, command, document)
3. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
arguments, TRACE:trace),
DOC:<<document>>)
4. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
TYPE-OF-SERVICE:regular, TRACE:trace),
DOC:<<document>>)
5. (ID:(MPM:(IA:12,1,0,52,0,45), TRANSACTION:37),
CMD:(MAILBOX:(MPM:(IA:12,3,0,52,0,45),
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen),
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(MPM:(IA:12,1,0,52,0,45)
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
DOC:<<document>>)
Postel [Page 45]
August 1980
Internet Message Protocol
Examples & Scenarios
6. PROPLIST:(
ID:PROPLIST:(
MPM:PROPLIST:(
IA:12,1,0,52,0,45),
ENDLIST
TRANSACTION:37)
ENDLIST,
CMD:PROPLIST(
MAILBOX:(PROPLIST:(
MPM:PROPLIST(
IA:12,3,0,52,0,45),
ENDLIST
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen ),
ENDLIST
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(PROPLIST:MPM:
(PROPLIST:
IA:12,1,0,52,0,45)
ENDLIST
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
ENDLIST
ENDLIST
DOC:<<document>>)
ENDLIST
[Page 46] Postel
August 1980
Internet Message Protocol
Examples & Scenarios
Example 2: Delivery and Acknowledgment
The following are four views of the message of example 1 during the
successive transmission from the origination MPM, through a relay MPM,
to the destination MPM, and the return of the acknowledgment, through
a relay MPM, to the originating MPM.
+-----------------------------------------------------------------+
| A B |
| sending --> originating --> relay --> destination --> receiving |
| user MPM MPM MPM user |
| |
| D C |
| originating <-- relay <-- destination |
| MPM MPM MPM |
+-----------------------------------------------------------------+
Transmission Path
Figure 6.
Postel [Page 47]
August 1980
Internet Message Protocol
Examples & Scenarios
A. Between the originating MPM and the relay MPM.
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIB"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
ENDLIST
[Page 48] Postel
August 1980
Internet Message Protocol
Examples & Scenarios
B. Between the relay MPM and the destination MPM.
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIB"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
Postel [Page 49]
August 1980
Internet Message Protocol
Examples & Scenarios
ENDLIST
C. Between the destination MPM and the relay MPM.
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:1993
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,1,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIE"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,3,0,52,0,45"
ENDLIST
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"ERROR-CLASS", INDEX:0
NAME:"ERROR-STRING", NAME:"Ok"
NAME:"TRAIL",
[Page 50] Postel
August 1980
Internet Message Protocol
Examples & Scenarios
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:51.567-08:00"
NAME:"ACTION", NAME:"DESTINATION"
ENDLIST
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
ENDLIST
ENDLIST
ENDLIST
Postel [Page 51]
August 1980
Internet Message Protocol
Examples & Scenarios
D. Between the relay MPM and the originating MPM.
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:1993
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,1,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIE"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,3,0,52,0,45"
ENDLIST
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"ERROR-CLASS", INDEX:0
NAME:"ERROR-STRING", NAME:"Ok"
NAME:"TRAIL",
LIST:
PROPLIST:
[Page 52] Postel
August 1980
Internet Message Protocol
Examples & Scenarios
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:51.567-08:00"
NAME:"ACTION", NAME:"DESTINATION"
ENDLIST
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52.345-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
ENDLIST
ENDLIST
ENDLIST
Postel [Page 53]
August 1980
Internet Message Protocol
[Page 54] Postel
August 1980
Internet Message Protocol
7. SPECIFICATION SUMMARY
7.1. Message Fields
All keywords used in this protocol are to be recognized independent of
case.
action: NAME (one of)
"ORIGIN" | "RELAY" | "FORWARD" | "DESTINATION"
address: PROPLIST (one of)
NAME: "MPM", <mpm-identifier>
NAME: "USER", <user>
or
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
answer: BOOLEAN
city: NAME
command: PROPLIST
NAME: "MAILBOX", <mailbox>
NAME: "OPERATION", <operation>
<<arguments>>
NAME: "ERROR-CLASS", <error-class> (only in replies)
NAME: "ERROR-STRING", <error-string> (only in replies)
NAME: "TRACE", <trace>
country: NAME
document: <<document>>
error-class: INDEX
error-string: NAME
host: NAME
Postel [Page 55]
August 1980
Internet Message Protocol
handling-stamp: PROPLIST
NAME: "MPM", <mpm-identifier>
NAME: "DATE", <date>
NAME: "ACTION", <action>
identification: LIST
NAME: "MPM", <mpm-identifier>
NAME: "TRANSACTION", <transaction-number>
internet-address: NAME
mailbox: PROPLIST (some of)
NAME: "MPM", <mpm-identifier>
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
NAME: "ORG", <organization>
NAME: "CITY", <city>
NAME: "STATE", <state>
NAME: "COUNTRY", <country>
NAME: "ZIP", <zip-code>
NAME: "PHONE", <phone-number>
<<other-items>>
message: PROPLIST
NAME: "ID", <identification>
NAME: "CMD", <command>
NAME: "DOC", <document> (only in deliver)
mpm-identifier: PROPLIST (one of)
NAME: "IA", <internet-address>
or
NAME: "X121", <x121-address>
net: NAME
operation: NAME (one of)
"DELIVER" | "ACKNOWLEDGE
| "PROBE" | "RESPONSE
| "CANCEL" | "CANCELED"
organization: NAME
phone-number: NAME
[Page 56] Postel
August 1980
Internet Message Protocol
port: NAME
state: NAME
trace: LIST
<handling-stamp>
...
trail: LIST
<handling-stamp>
...
transaction-number: INTEGER
type-of-service: NAME (one or more of)
"REGULAR" | "FORWARD" | "GENDEL" | "PRIORITY"
user: NAME
x121-address: NAME
zip-code: NAME
Postel [Page 57]
August 1980
Internet Message Protocol
7.2. Deliver Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
ENDLIST
[Page 58] Postel
August 1980
Internet Message Protocol
7.3. Acknowledge Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:"*MPM*"
NAME:"NET", NAME:<net>
NAME:"PORT", NAME:<port>
NAME:"HOST", NAME:<host>
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
Postel [Page 59]
August 1980
Internet Message Protocol
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
[Page 60] Postel
August 1980
Internet Message Protocol
7.4. Probe Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"PROBE"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
Postel [Page 61]
August 1980
Internet Message Protocol
7.5. Response Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"RESPONSE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
[Page 62] Postel
August 1980
Internet Message Protocol
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
Postel [Page 63]
August 1980
Internet Message Protocol
7.6. Cancel Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"CANCEL"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
[Page 64] Postel
August 1980
Internet Message Protocol
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
Postel [Page 65]
August 1980
Internet Message Protocol
7.7. Canceled Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"CANCELED"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
[Page 66] Postel
August 1980
Internet Message Protocol
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
Postel [Page 67]
August 1980
Internet Message Protocol
7.8. Data Element Summary
CODE NAME STRUCTURE LENGTH
---- ---- --------- ------
0 NOP CODE(1) 1
1 PAD CODE(1),COUNT(3),DATA(C) C+4
2 BOOLEAN CODE(1),TRUE-FALSE(1) 2
3 INDEX CODE(1),INDEX(2) 3
4 INTEGER CODE(1),INTEGER(4) 5
5 EPI CODE(1),COUNT(3),INTEGER(C) C+4
6 BITSTR CODE(1),COUNT(3),BITS(C/8) C/8+4
7 NAME CODE(1),COUNT(1),NAME(C) C+2
8 TEXT CODE(1),COUNT(3),TEXT(C) C+4
9 LIST CODE(1),COUNT(3),ITEMS(2),DATA(C-2) C+4
10 PROPLIST CODE(1),COUNT(3),PAIRS(1),DATA(C-1) C+4
11 ENDLIST CODE(1) 1
12 S-TAG CODE(1),INDEX(2) 3
13 S-REF CODE(1),INDEX(2) 3
14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1),
KEY-ID(2),DATA(C-3) C+4
The numbers in parentheses are the number of octets in the field.
[Page 68] Postel
August 1980
Internet Message Protocol
REFERENCES
[1] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[2] Postel, J., "DOD Standard Internet Protocol," USC/Information
Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
[3] Postel, J., "DOD Standard Transmission Control Protocol,"
USC/Information Sciences Institute, IEN 129, NTIS number AD
A082609, January 1980.
[4] Postel, J., "Assigned Numbers," RFC762, USC/Information Sciences
Institute, January 1980.
[5] Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook,"
NIC 7104, for the Defense Communications Agency by the Network
Information Center of SRI International, Menlo Park, California,
Revised January 1978.
[6] Neigus, N., "File Transfer Protocol for the ARPA Network,"
RFC542, NIC 17759, SRI International, August 1973.
[7] Bhushan, A., K. Progran, R. Tomlinson, and J. White,
"Standardizing Network Mail Headers," RFC561, NIC 18516,
September 1973.
[8] Myer, T., and D. Henderson, "Message Transmission Protocol,"
RFC680, NIC 32116, 30 April 1975.
[9] Crocker, D., J. Vittal, K. Progran, and D. Henderson, "Standard
for the Format of ARPA Network Text Messages," RFC733, NIC 41952,
21 November 1977.
[10] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192,
February 1979.
[11] Braaten, O., "Introduction to a Mail Protocol," Norwegian
Computing Center, INWG 180, August 1978.
[12] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo
Distribution Capability - MMDF," Sixth Data Communications
Symposium, ACM/IEEE, November 1979.
Postel [Page 69]
August 1980
Internet Message Protocol
References
[13] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed
Specification of an Inter-site Message Protocol," 8 July 1975.
[14] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW
Working Note 24, Bolt Beranek and Newman, October 1978.
[15] White, J., "A Proposed Mail Protocol," RFC524, NIC 17140, SRI
International, 13 June 1973.
[16] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI
International, 30 May 1974.
[17] White, J., "Journal Subscription Service," NIC 23143, SRI
International, 28 May 1974.
[18] Levin, R., and M. Schroeder, "Transport of Electronic Messages
Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.)
North Holland Publishing Co., 1979.
[19] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications
Study," Computer Science Department, Stanford University, August
1978.
[20] Crispin M., "DIALNET: A Telephone Network Data Communications
Protocol," DECUS Proceedings, Fall 1979.
[21] Caulkins, D., "The Personal Computer Network (PCNET) Project: A
Status Report," Dr. Dobbs Journal of Computer Calisthenics and
Orthodontia, v.5, n.6, June 1980.
[22] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information
Sciences Institute, IEN 38, May 1978.
[23] Haverty, J., "MSDTP -- Message Services Data Transmission
Protocol," RFC713, NIC 34739, April 1976.
[24] Haverty, J., "Thoughts on Interactions in Distributed Services,"
RFC722, NIC 36806, 16 September 1976.
[25] Postel, J., "A Structured Format for Transmission of Multi-Media
Documents," RFC767, USC/Information Sciences Institute,
August 1980.
[26] ISO-2014, "Writing of calendar dates in all-numeric form,"
Recommendation 2014, International Organization for
Standardization, 1975.
[Page 70] Postel
August 1980
Internet Message Protocol
References
[27] ISO-3307, "Information Interchange -- Representations of time of
the day," Recommendation 3307, International Organization for
Standardization, 1975.
[28] ISO-4031, "Information Interchange -- Representation of local time
differentials," Recommendation 4031, International Organization
for Standardization, 1978.
[29] CCITT-X.121, "International Numbering Plan for Public Data
Networks," Recommendation X.121, CCITT, Geneva, 1978.
[30] Postel, J., "NSW Data Representation (NSWB8)," USC/Information
Sciences Institute, IEN 39, May 1978.
[31] Cohen, D., "On Holy Wars and a Plea for Peace," IEN 137,
USC/Information Sciences Institute, 1 April 1980.
[32] Hofstadter, D., "Godel, Escher, Bach: An Eternal Golden Braid,"
Basic Books, New York, 1979..
[33] Harrenstien, K., "Field Addressing," ARPANET Message, SRI