IEN: 85
RFC: 753
INTERNET MESSAGE PROTOCOL
Jonathan B. Postel
March 1979
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
(213) 822-1511
< INC-PROJECT, MAIL-MAR-79.NLS.38, >, 31-Mar-79 19:50 JBP ;;;;
[Page 0] Postel
March 1979
Internet Message Protocol
TABLE OF CONTENTS
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. The Internetwork Environment ................................. 2
1.4. Operation .................................................... 2
1.5. Interfaces ................................................... 3
2. FUNCTIONAL DESCRIPTION ........................................... 5
2.1. Relation to Other Protocols .................................. 5
2.2. Terminology ................................................. 5
2.3. Assumptions .................................................. 6
2.4. General Specification ........................................ 7
2.5. Mechanisms .................................................. 11
3. DETAILED SPECIFICATION .......................................... 13
3.1. Overview of Message Structure ............................... 13
3.2. Data Elements ............................................... 13
3.3. Message Objects ............................................. 16
3.4. Command ..................................................... 23
3.5. Document .................................................... 31
3.6. Message Structure ........................................... 33
3.7. MPM Organization ............................................ 36
3.8. Interfaces .................................................. 39
4. EXAMPLES & SCENARIOS ............................................ 41
Example 1: Message Format ........................................ 41
Example 2: Delivery and Acknowledgment ........................... 43
GLOSSARY ............................................................ 49
REFERENCES .......................................................... 51
APPENDICES .......................................................... 53
Postel [Page i]
March 1979
Internet Message Protocol
[Page ii] Postel
March 1979
Internet Message Protocol
PREFACE
This is the first edition of this specification and should be treated as
a request for comments, advice, and suggestions. A great deal of prior
work has been done on computer aided message systems and some of this is
listed in the reference section. This specification was shaped by many
discusions with members of the ARPA research community, and others
interested in the development of computer aided message systems. This
document was prepared as part of the ARPA sponsored Internetwork
Concepts Research Project at ISI, with the assistance of Greg Finn, Alan
Katz, Paul Mockapetris, and Mamie Chew.
Jon Postel
Postel [Page iii]
March 1979
Internet Message Protocol
[Page iv] Postel
March 1979
IEN: 85 J. Postel
RFC: 753 USC-ISI
March 1979
INTERNET MESSAGE PROTOCOL
1. INTRODUCTION
This document describes an internetwork message system. The system is
designed to transmit messages between message processing modules
according to formats and procedures specified in this document. The
message processing modules are processes in host computers. Message
processing modules are located in different networks and together
constitute an internetwork message delivery system.
This document is intended to provide all the information necessary to
implement a compatible cooperating module of this internetwork message
system.
1.1. Motivation
As computer supported message processing activities grow on individual
host computers and in networks of computers, there is a natural desire
to provide for the interconnection and interworking of such systems.
This specification describes the formats and procedures of a general
purpose internetwork message system, which can be used as a standard
for the interconnection of individual message systems, or as a message
system in its own right.
We also provide for the communication of data items beyond the scope
of contemporary message systems. Messages can include typed segments
which could represent drawings, or facsimile images, or digitized
speech. One can imagine message stations equipped with speakers and
microphones (or telephone hand sets) where the body of a message or a
portion of it is recorded digitized speech. The output terminal could
include a graphics display, and the message might present a drawing on
the display, and verbally (via the speaker) describe certain features
of the drawing. This specification provides basic data elements for
the transmission of structured binary data, as well as providing for
text transmission.
1.2. Scope
The Internet Message Protocol is intended to be used for the
transmission of messages between networks. It may also be used for
the local message system of a network or host. This specification was
developed in the context of the ARPA work on the interconnection of
networks, but it is anticipated that it has a more general scope.
Postel [Page 1]
March 1979
Internet Message Protocol
Introduction
The focus here is on the internal mechanisms to transmit messages,
rather than the external interface to users. It is assumed that a
number of user interface programs will exist. These will be both new
programs designed to work with system and old programs designed to
work with earlier systems.
1.3. The Internetwork Environment
The internetwork message environment consists of processes which run
in hosts which are connected to networks which are interconnected by
gateways. Each individual network consists of many different hosts.
The networks are tied together through gateways. The gateways are
essentially hosts on two (or more) networks and are not assumed to
have much storage capacity or to "know" which hosts are on the
networks to which they are attached [5].
1.4. Operation
The model of operation is that this protocol is implemented in a
process. Such a process is called a Message Processing Module or MPM.
The MPMs exchange messages by establishing full duplex communication
and sending the messages in a fixed format described in this document.
The MPM may also communicate other information by means of commands
described here.
A message is formed by a user interacting with a User Interface
Program or UIP. The user may utilize several commands to create
various fields of the message and may invoke an editor program to
correct or format some or all of the message. Once the user is
satisfied with the messages it is "sent" by placing it in a data
structure shared with the MPM.
The MPM discovers the unprocessed input data (either by a specific
request or by a general background search), examines it, and using
routing tables determines which outgoing link to use. The destination
may be another user on this host, a user on another host in this
network, or a user in another network.
In the first case, another user on this host, the MPM places the
message in a data structure shared with the destination user, where
that user's UIP will look for incoming messages.
In the second case, the user on another host in this network, the MPM
transmits the message to the MPM on that host. That MPM then repeats
the routing decision, and discovering the destination is local to it,
places the messages in the data structure shared with the destination
user.
[Page 2] Postel
March 1979
Internet Message Protocol
Introduction
In the third case, the user on a host in another network, the MPM
transmits the messages to an MPM in that network if it knows how to
establish a connection directly to it, otherwise the MPM transmits the
message to an MPM that is "closer" to the destination. An MPM might
not know of direct connections to MPMs in all other networks, but it
must be able to select a next MPM to handle the message for each
possible destination network.
A MPM might know a way to establish direct connections to each of a
few MPMs in other nearby networks, and send all other messages to a
particular big brother MPM that has a wider knowledge of the internet
environment.
A individual network's message system may be quite different from the
internet message system. In this case, intranet messages will be
delivered using the network's own message system. If a message is
addressed outside the network, it is given to a MPM which then sends
it through the appropriate gateways via internet procedures and format
to (or toward) the MPM in the destination network. Eventually, the
message gets to a MPM on the network of the recipient of the message.
The message is then sent via the local message system to that host.
When local message protocols are used, special conversion programs are
required to transform local messages to internet format when they are
going out, and to transform internet messages to local format when
they come into the local environment. Such transformations are
potentially information lossy. The internet message format attempts
to provide features to capture all the information any local message
system might use. However, a particular local message system is
unlikely to have features equivalent to all the possible features of
the internet message system. Thus, in some cases the transformation
of an internet message to a local message discard of some of the
information. For example, if an internet message carrying mixed text
and speech data in the body is to be delivered in a local system which
only carries text, the speech data may be replaced by the text string
"There was some speech here". Such discarding of information is to be
avoided when at all possible, and to be defered as long as possible,
still the possibility remains, that in some cases, it is the only
reasonable thing to do.
1.5. Interfaces
The MPM calls on a reliable communication procedure to communicate
with other MPMs. This is a Transport Level protocol such as the TCP
[20]. The interface to such a procedure conventionally provides calls
to open and close connections, send and receive data on a connection,
and some means to signal and be notified of special conditions (i.e.,
interrupts).
Postel [Page 3]
March 1979
Internet Message Protocol
Introduction
The MPM receives input and produces output through data structures
that are produced and consumed respectively by user interface (or
other) programs.
[Page 4] Postel
March 1979
Internet Message Protocol
2. FUNCTIONAL DESCRIPTION
2.1. Terminology
The basic unit transferred between networks is called a message. A
message is made up of a transaction identifier (a number which
uniquely identifies the message), a command list (which contains the
necessary information for delivery), and the document list. The
document list consists of a header and a body, which contains the
actual data of the message.
For a personal letter the document body corresponds to the contents
the a letter, the document header corresponds to the the address and
return address on the envelope.
For an inter-office memo the document body corresponds to the text,
the document header corresponds to the header of the memo.
The commands correspond to the information used by the Post Office or
the mail room to route the letter or memo.
The messages are routed by a process called the message processing
module or MPM. Messages are created and consumed by User Interface
Programs (UIPs) in conjunction with users.
Please see the Glossary section for a more complete list of
terminology.
2.2. Assumptions
The following assumptions are made about the internetwork environment:
It is in general not known what format intranet addresses will assume.
Since no standard addressing scheme would suit all networks, it is
safe to assume there will be several and that they will change with
time. Thus, frequent software modification throughout all internet
MPMs would be required if such MPMs were to know about the formats on
many networks. Therefore, each MPM which handles internet messages is
required to know only the minimum necessary to deliver them.
We require each MPM to know completely only the addressing format of
its own network. In addition, the MPM must be able to select an
output link for each message addressed to another network or host.
This does not preclude more intelligent behavior on the part of a
given MPM, but at least this minimum is necessary. Each network has a
unique name and number.
Each MPM will have a unique internet address. This feature will
Postel [Page 5]
March 1979
Internet Message Protocol
Functional Description
enable every MPM to place a unique "handling-stamp" on a message which
passes through it en-route to delivery.
2.3. General Specification
There are several aspects to a distributed service to be specified.
First there is the service to be provided, that is, the
characteristics of the service as seen by its users. Second there is
the service it uses, that is, the characteristics it assumes to be
provided by some lower level service. And, third there is the
protocol used between the modules of the distributed service.
User User
\ /
\ /
\ /
--+----------------------------------------+-- Service
! \ / ! Interface
! +--------+ +--------+ !
! ! Module ! <--Protocol--> ! Module ! !
! +--------+ +--------+ !
! \ / !
! +-----------------------+ !
! ! Communication Service ! !
! +-----------------------+ !
! !
+----------------------------------------+
Message Service
Figure 1.
The User/Message Service Interface
The service the message delivery system provides is to accept
messages conforming to a specified format and to attempt to deliver
those messages, and to report on the success or failure of the
delivery attempt. This service is provided in the context of an
interconnected system of networks, and may involve relaying a
message through several intermediate MPMs utilizing different
communication services.
The Message/Communication Service Interface
The message delivery system calls on a communication service to
transfer information from one MPM to another. There may be
different communication services used between different pairs of
[Page 6] Postel
March 1979
Internet Message Protocol
Functional Description
MPMs, though all communication services must meet the following
service characteristics.
It is assumed that the communication service provides a reliable two
way data stream. Such a data stream can usually be obtained in
computer networks from the transport level protocol, for example,
the Transmission Control Protocol (TCP) [20]. In any case the
properties the communication service must provide are:
o Logical connections for two way simultaneous data flow of
arbitrary data (i.e., no forbidden codes). Data is delivered
in the order sent with no gaps.
o Simple commands to open and close the connections, and to send
and receive data on the connections.
o A way to signal and be notified "out-of-band" (such as TCP's
urgent) is available so that some messages can be labeled "more
important" than others.
o Controlled flow of data so that data is not transmitted faster
that the receiver chooses to consume it (on the average).
o Transmission errors are corrected without user notification or
involvement. Complete breakdown on communication is reported
to the user.
The Message-Message Protocol
The protocol used between the distributed modules of the message
delivery system, that is, the MPMs is a small set of commands which
convey requests and replies. These commands are encoded in a highly
structured and rigidly specified format.
2.4. Mechanisms
MPMs are processes which use some communication service. A pair of
MPMs which can communicate reside in a common interprocess
communication environment. A MPM might exist in two (or more)
interprocess communication environments, and such an MPM might act to
relay messages between MPMs in the environments.
Postel [Page 7]
March 1979
Internet Message Protocol
Functional Description
User User
\ /
\ /
\ /
+---------------------------------------------------------+
! \ / !
! +-----+ +-----+ +-----+ !
! ! MPM ! <--Protocol--> ! MPM ! <--Protocol--> ! MPM ! !
! +-----+ +-----+ +-----+ !
! ! / \ ! !
! +-----------------------+ +-----------------------+ !
! !Communication Service A! !Communication Service B! !
! +-----------------------+ +-----------------------+ !
! !
+---------------------------------------------------------+
Message Service with Internal Relaying
Figure 2.
The transfer of data between UIPs and MPMs is conceived of as the
exchange of data structures which encode messages. The transfer of
data between MPMs is also in terms of the transmission of structured
data.
[Page 8] Postel
March 1979
Internet Message Protocol
Functional Description
+-----+ DATA +-----+
USER-->! UIP !-->STRUCTURES-->! MPM !-->other
+-----+ +-----+ +-----+ MPMs
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
+-----+ DATA +-----+
other-->! MPM !-->STRUCTURES-->! UIP !-->USER
MPMs +-----+ +-----+ +-----+
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
Message Flow
Figure 3.
In the following, a message will be described as a structured data
object represented in a particular kind of typed data elements. This
is how a message is presented when transmitted between MPMs or
exchanged between an MPM and a UIP. Internal to a MPM (or a UIP), a
message may be represented in any convenient form. As the following
figure shows, when a message is ready for transmission, it moves from
the processing routines to be encoded in the typed data elements and
then to a data compression routine, and is finally transmitted. On
the receiving side, the message is first decompressed then decoded
from the data element representation to the local representation for
the processing routines.
Postel [Page 9]
March 1979
Internet Message Protocol
Functional Description
+------------------------------------------------+
! !
! processing DATA DATA !
! routines ---> ENCODER ---> COMPRESSOR ---> !
! !
+------------------------------------------------+
Send MPM
+------------------------------------------------+
! !
! DATA DATA processing !
! ---> DECOMPRESSOR ---> DECODER ---> routines !
! !
+------------------------------------------------+
Receive MPM
Detailed View
Figure 4.
[Page 10] Postel
March 1979
Internet Message Protocol
Functional Description
2.5. Relation to Other Protocols
The following diagram illustrates the place of the message protocol in
the protocol hierarchy:
+------+ +-----+ +-------+ +-----+ +-----+
!Telnet! ! FTP ! !Message! !Voice! ... ! ! Application Level
+------+ +-----+ +-------+ +-----+ +-----+
\ ! / ! !
+-----+ +-----+ +-----+
! TCP ! ! RTP ! ... ! ! Host Level
+-----+ +-----+ +-----+
! ! !
+-------------------------------+
! Internet Protocol ! Gateway Level
+-------------------------------+
!
+---------------------------+
! Local Network Protocol ! Network Level
+---------------------------+
!
Protocol Relationships
Figure 5.
The message protocol interfaces on one side to user interface programs
and on the other side to a reliable transport protocol such as TCP.
Postel [Page 11]
March 1979
Internet Message Protocol
[Page 12] Postel
March 1979
Internet Message Protocol
3. DETAILED SPECIFICATION
The presentation of the information in this section is difficult since
everything depends on everything, and since this is a linear media it
has to come in some order. In this attempt, a very brief overview of
the message structure is given, then a radical switch is made to
defining the basic building blocks, and finally using the building
blocks to reach the overall structure again.
3.1. Overview of Message Structure
In general a message is composed of three parts: the identification,
the command, and the document. Each part is in turn composed of
message objects.
The identification part is composed of a transaction number assigned
by the originating MPM, and the internet host number of that MPM.
The command part is composed of an operation type, an operation code,
an argument list, an error list, the destination mailbox, and a stamp.
The stamp is a list of the MPMs that have handled this message.
The document part is composed of a header and a body. The message
delivery system does not depend on the contents of the document part,
but this specification does make some recommendations for the document
header.
The following sections define the representation of a message as a
structured object composed of other objects. Objects in turn are
represented using a set of basic data elements.
3.2. Data Elements
The data elements defined here are similar to the data structure and
encoding used in NSW [18].
Each of the diagrams which follow represent a sequence of octets.
Field boundaries are denoted by the "!" character, octet boundaries by
the "+" character. The diagrams are presented in left to right order.
Each element begins with a one octet code.
Postel [Page 13]
March 1979
Internet Message Protocol
Specification
Code Type Representation
---- ---- --------------
+------+
0 No Operation ! 1 !
+------+
+------+------+------+------+------
1 Padding ! 0 ! octet count ! Data ...
+------+------+------+------+------
+------+------+
2 Boolean ! 2 ! 1/0 !
+------+------+
+------+------+------+
3 Index ! 3 ! Data !
+------+------+------+
+------+------+------+------+------+
4 Integer ! 4 ! Data !
+------+------+------+------+------+
+------+------+------+------+------
5 Bit String ! 5 ! bit count ! Data ...
+------+------+------+------+------
+------+------+------+------+------
6 Text String ! 6 ! octet count ! Data ...
+------+------+------+------+------
+------+------+------+------+------+------+-----
7 List ! 7 ! octet count ! item count ! Data
+------+------+------+------+------+------+-----
+------+------+------+------+------
8 Proplist ! 8 ! octet count ! Data ...
+------+------+------+------+------
[Page 14] Postel
March 1979
Internet Message Protocol
Specification
Element code 0 (NOP) is an empty data element used for padding when it
is necessary. It is ignored.
Element code 1 (PAD) is used to transmit large amounts of data with a
message for test or padding purposes. No action is taken with this
data but the count of dummy octets must be correct to indicate the
next element code.
Element code 2 (BOOLEAN) is a boolean data element which has the value
1 for True and 0 for False.
Element code 3 (INDEX) is a 16-bit unsigned integer datum. Element
code 3 occupies only 3 octets.
Element code 4 (INTEGER) is a signed 32-bit integer datum. This will
always occupy five octets. Representation is two's complement.
Element code 5 (BITSTR) is a bit string element for binary data. The
bit string is padded on the right with zeros to fill out the last
octet if the bit string does not end on an octet boundary. This data
type must have the bit-count in the two octet count field instead of
the number of octets.
Element code 6 (TEXT) is used for the representation of text. Seven
bit ASCII characters are used, right justified in the octet. The high
order bit in the octet is zero.
Element code 7 (LIST) can be used to create structures composed of
other elements. The item-count contains the number of elements which
follow. Any element may be used including List itself. The octet
count specifies the number of octets in the whole list. A null or
empty List, one with no elements, has an item-count of zero (0).
Postel [Page 15]
March 1979
Internet Message Protocol
Specification
Element code 8 (PROPLIST) is the Property-List element. It has the
following form:
+------+------+------+------+------+
! 8 ! octet ! pair !
! ! count ! count!
+------+------+------+------+------+
+------+------+------+---------+---------+
! name ! value ! name ! value !
repeated ! count! count ! ...! ...!
+------+------+------+---------+---------+
The Property-List structure consists of a set of unordered name/value
pairs. The pairs are a one octet name count and a two octet value
count followed by the name and value strings. The counts specify the
length in octets of the name and value strings. Each string has a
length in octets which agrees with its respective count. The count of
octets until the next pair in the property list is 1 + 2 + name count
+ value count octets. The entire Property-List is of course equal in
length to the octet count of the element itself. Immediately
following the octet count for the entire element is a one octet pair
count field which contains the total number of name/value pairs in the
Proplist.
3.3. Message Objects
In the composition of messages we use a set of objects such as
address, or date. These objects are encoded in the basic data
elements. The message objects are built of data elements.
While data elements are typed, message objects are not. This is
because messages are structured to the extent that only one kind of
message object may occur in any position of a message structure.
The following is a list of some of the objects used in messages. The
object descriptions are grouped by the section of the message in which
they normally occur.
[Page 16] Postel
March 1979
Internet Message Protocol
Specification
Identification
Internet Host Number (ihn)
This identifies a host in the internetwork environment. When used
as a part of tid, it identifies the originating host of a message.
The ihn is a 32 bit number, the higher order 8 bits identify the
network, and the lower order 24 bits identify the host on that
network.
INTEGER
Transaction Identifier (tid)
This is the transaction identifier associated with a particular
command. It is a list of the transaction number and the internet
host number of the originating host.
LIST ( tn , ihn )
Transaction Number (tn)
This is a number which is uniquely associated with this
transaction by the originating host. It identifies the
transaction. (A transaction is a message and acknowledgment, this
is discussed in more detail in later sections.) A tn must be
unique for the time which the message (a request or reply)
containing it could be active in the network.
INDEX
Command
Address
This is very similar to Mailbox in that it also is the "address"
of a user. However, Address is intended to contain the minimum
information necessary for delivery, and no more.
PROPLIST ( --- )
Answer
A yes (true) or no (false) answer to a question.
BOOLEAN
Postel [Page 17]
March 1979
Internet Message Protocol
Specification
Arguments
This is the argument to many of the operations. It consists of a
List of different data types. The List will have form and data
relevant with the particular operation.
LIST ( --- )
Command-Type
Gives the type of a command (e.g., request, reply, alarm).
INDEX
Error-List
The error list contains information concerning an error which has
occured. It is a List comprised of the two objects error-class
and error-string.
LIST ( error class, error string )
Error-Class
A code for the class of the error.
INDEX
Error-String
A text string explaining the error.
TEXT
How-Delivered
A comment on the delivery of a messages, for instance a message
could be delivered, forwarded, or turned over to general delivery.
LIST ( TEXT )
[Page 18] Postel
March 1979
Internet Message Protocol
Specification
Mailbox
This is the "address" of a user of the internetwork mail system.
Mailbox contains information such as net, host, location, and
local user-id of the recipient of the message. Some information
contained in Mailbox may not be necessary for delivery.
As an example, when one sends a message to someone for the first
time, he may include many items which are not necessary simply to
insure delivery. However, once he gets a reply to this message,
the reply could contain an Address (as opposed to Mailbox) which
the user will use from then on.
A mailbox is a PROPLIST. A mailbox might contain the following
name-value pairs:
name element description
---- ------- -----------
IA INTEGER internet address
NET TEXT network name
HOST TEXT host name
USER TEXT user name
CITY TEXT city
COUNTRY TEXT country
STATE TEXT state
ZIP TEXT zip code
PHONE TEXT phone number
PROPLIST ( --- )
Operation
This names the operation or procedure to be performed.
TEXT
Options
REGULAR for normal delivery, FORWARD for message forwarding,
GENDEL for general delivery, or other options which may be defined
later.
LIST ( TEXT, ... )
Postel [Page 19]
March 1979
Internet Message Protocol
Specification
Reasons
These could be mailbox does not exist, mailbox full, etc.
LIST ( TEXT )
Stamp
Each MPM that handles the message must add a unique identifier
(ihn, see above) to the list. This will prevent messages from
being sent back and forth through the internet mail system without
eventually either being delivered or returned to the sender.
LIST ( ihn, ihn, ... )
Trail
When a message is sent through the internetwork environment, it
acquires a list of MPMs that have handled the message in "Stamp".
This list is then carried as "Trail" upon reply or acknowledgment
of that message. More simply, requests and replies always have a
"Stamp" and each MPM adds its ihn to this "Stamp." Replies, in
addition, have a "Trail" which is the complete "Stamp" of the
original message.
LIST ( ihn, ihn, ... )
Type
The command type, e.g., request or reply.
INDEX
Document
In this section, we define some objects useful in message document
headers. The ones we use are taken from the current ARPANET message
syntax standard [6,8].
CC
When copies of a message are sent to others in addition to the
addresses in the To object, those to whom the copies are sent will
have their addresses recorded here. CC will be a single TEXT
element.
TEXT
[Page 20] Postel
March 1979
Internet Message Protocol
Specification
Date
The date and time are represented according to the International
Standards Organization (ISO) recommendations [13,14,15]. Taken
together the ISO recommendations 2014, 3307, and 4031 result in
the following representation of the date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
Where yyyy is the 4 digit year, mm is the two digit month, dd is
the two digit day, hh is the two digit hour in 24 hour time, mm is
the two digit minute, ss is the two digit second, and fff is the
decimal fraction of the second. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and
mm minutes.
TEXT
Document-Body
The document body will contain that portion of the message
commonly thought of as the text portion. It will be composed of a
list of elements. This will allow transmission of data other than
pure text if such capabilities are needed. We can, for instance,
envision digital voice communication through the transmission of
BITSTR element, or transmission of graphic data, etc. Information
regarding control of such features could be included in the header
for cooperating sites, or in the body itself but such protocols
would depend upon agreement among those sites involved. It is
expected of course that the majority of messages will contain body
portions comprised of TEXT elements.
LIST ( --- )
Document-Header
The document header contains the memo header presented to the
user. In principle this may be of any style or structure. In
this specification it is recommended that a PROPLIST be used and
that the name-value pairs correspond to the header fields of
RFC733 [6].
PROPLIST ( --- )
Postel [Page 21]
March 1979
Internet Message Protocol
Specification
From
The From is meant to be the name of the author of a document. It
will be one TEXT element.
TEXT
Reply-To
Sometimes it will be desired to direct the replies of a message to
some address other than the From or the Sender. In such a case
the Reply-To object can be used.
TEXT
Sender
The Sender will contain the address of the individual who sent the
message. In some cases this is NOT the same as the author of the
message. Under such a condition, the author should be specified in
the From object. The Sender is a single TEXT element.
TEXT
Subject
The subject of the message.
TEXT
To
To identifies the addressees of the message. The To object is one
TEXT element.
TEXT
[Page 22] Postel
March 1979
Internet Message Protocol
Specification
3.4. Command
This section describes the commands which processes in the internet
message system can use to communicate. Several aspects of the command
structure are based on the NSW Transaction Protocol [19]. The
commands come in pairs, with each request having a corresponding
reply.
A command is a list:
LIST ( mailbox, stamp, type, operation, arguments, error-list )
The arguments are described generally here and more specifically, if
necessary, in the description of each command.
mailbox: PROPLIST
This is the "to" specification of the message. Mailbox takes the
form of a property list of general information, some of which is
the essential information for delivery, and some of which could be
extra information which may be helpful for delivery. Mailbox is
different from address in that address is a very specific list
without extra information.
stamp: LIST ( INTEGER, ... )
This is a list of the MPMs that have handled the message. Each
MPM must add its 32 bit Internet Host Number (ihn) to the LIST.
type: INDEX
type=1 a REQUEST operation.
type=2 a REPLY operation.
type=3 an ALARM operation. (A high priority message.)
type=4 a RESPONSE to an alarm operation.
operation: TEXT
Operation is the name of the operation or procedure to be
performed. This string must be interpreted in an upper/lower case
independent manner.
Postel [Page 23]
March 1979
Internet Message Protocol
Specification
arguments: LIST
This is a list of arguments to the above operation.
error-list: LIST
If message is type 1 or 3 (a request or an alarm):
LIST ( ) (a zero length list)
If message is a type 2 or 4 (a response or response to alarm)
LIST ( error-class, error-string ) indicates what,if any, error
occured
error-class: INDEX
=0: indicates success, no error
=1: partial results returned.
This error class is used when several steps are performed by
one operation and some of them fail.
=2: failure, resources unavailable.
=3: failure, user error.
=4: failure, MPM error. Recoverable.
=5: failure, MPM error. Fatal.
=6: User abort requested
error-string: TEXT
This is a human readable character string describing the error.
Possible errors:
error-string error-class
No errors 0
Command not implemented 2
Syntax error, command unrecognized 3
Syntax error, in arguments 3
Server error, try again later 4
No service available 5
User requested abort 6
[Page 24] Postel
March 1979
Internet Message Protocol
Specification
command: DELIVER
type: 1
function: Sends message to a mailbox
reply: The reply is ACKNOWLEDGE
arguments: LIST ( options )
options: one or more of the following
"REGULAR" regular delivery
"FORWARD" message forwarding
"GENDEL" general delivery
other options which may be defined later
argument structure:
LIST ( LIST ( TEXT, ... ))
Postel [Page 25]
March 1979
Internet Message Protocol
Specification
command: ACKNOWLEDGE
type: 2
function: reply to DELIVER
arguments: LIST ( tid, trail, answer, reasons, how-delivered )
tid: tid of the originating message
trail: the stamp from the deliver command
answer: yes if delivered successfully,
no if error in delivery.
reasons: if the answer is yes, the reason is "ok", if the answer
is no the reason could be one of "no such user", "no such host",
"no such network", "address ambiguous", or a similar response
how-delivered: one or more of the following:
"FORWARD" message was accepted for forwarding
"GENDEL" message was accepted for general delivery
"ACCEPT" message was accepted for normal delivery
other types of delivery may be defined later
argument structure:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ),
LIST ( TEXT ))
[Page 26] Postel
March 1979
Internet Message Protocol
Specification
command: PROBE
type: 1
function: finds out if specified mailbox (specified in mailbox of
the command) exists at a host
reply: the reply is RESPONSE
arguments: LIST ( --none-- )
argument structure:
LIST ( )
Postel [Page 27]
March 1979
Internet Message Protocol
Specification
command: RESPONSE
type: 2
function: reply to PROBE
arguments: LIST ( tid, trail, answer, address OR reasons )
tid: the tid which came from the originating PROBE
trail: the stamp which came from the originating PROBE
answer: Yes if mailbox found, or no for invalid mailbox
if answer is yes the fourth argument is address
if answer is no it is reasons
address: a specific address in the network
reasons: a reason why mailbox is invalid
Possible reasons include:
"Mailbox doesn't exist"
"Mailbox full"
"Mailbox has moved, try this new location", address
address is a new address to try
argument structure:
if answer is yes
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
PROPLIST )
if answer is no
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ))
[Page 28] Postel
March 1979
Internet Message Protocol
Specification
command: CANCEL
type: 3
function: abort request for specified transaction
reply: The reply is CANCELED
arguments: LIST ( tid )
tid of transaction to be cancelled
argument structure:
LIST ( LIST ( INDEX, INTEGER ))
Postel [Page 29]
March 1979
Internet Message Protocol
Specification
command: CANCELED
type: 4
function: reply to CANCEL
arguments: LIST ( tid, trail, answer )
tid: tid of transaction to be cancelled
trail: the stamp of the CANCEL command
answer: yes if the command was canceled, no if not.
argument structure:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN )
[Page 30] Postel
March 1979
Internet Message Protocol
Specification
To summarize again, a command consists of a LIST of the following
objects:
name element
---- -------
mailbox PROPLIST
stamp LIST ( INTEGER, ... )
type INDEX
operation TEXT
arguments LIST ( --- )
error LIST ( INDEX, TEXT )
3.5. Document
The actual document follows the command list. It contains a header
which usually contains such information as From, To, Date, CC, etc.;
and the actual body of the message. The message delivery system does
not depend on the document. The following section should be taken as
a recommendation for common practice, not as a requirement.
Document Header
For the same reason that it is impossible to for see the many forms
that intranet addresses will take, standardizing of document headers
would also be a mistake. The approach we suggest is to lay the
groundwork for a set of basic document header functions and provide
for enough extensibility to allow nets to add whatever header
features they desire. Features added in this fashion, however, may
not be understood by other networks. It is suggested that subset
defined here be implemented by all networks.
This subset is taken from the current ARPANET standard for message
headers in the text oriented computer message system [6,8].
The document header will precede the document body portion of the
message and will consist of a proplist data element. The document
header is meant to be used by individual networks to tailor the
header to suit their individual needs. As an example, consider the
ARPA network. Typically, the receiver's name is taken to be his
network address. It often prints in the document header in just
that form: Frank@SITEX. Such a salutation is unacceptable in some
more formal modes of communication. Some network might choose to
place into header proplist the name-value pair ("SALUTATION:", "Mr.
Frank Hacker"). Upon receipt of the message, the document handling
program would then be able to scan the header proplist looking for
such a pair and so be able to correctly address the recipient by
name instead of by network address. However, other networks or
Postel [Page 31]
March 1979
Internet Message Protocol
Specification
sites within the network may not understand such specific
information. Under such a condition it should be ignored.
The minimum header is a PROPLIST of the following name-value pairs:
Name Value
---- -----
DATE TEXT
FROM TEXT
A normal header is a PROPLIST containing the following name-value
pairs:
Name Value
---- -----
DATE TEXT
SENDER TEXT
FROM TEXT
TO TEXT
CC TEXT
SUBJECT TEXT
Document Body
The Body of the message is just a sequence of data elements which
contains the actual document. Much of the time this will be a
single TEXT element, but for some applications other data elements
may be utilized.
LIST ( --- )
[Page 32] Postel
March 1979
Internet Message Protocol
Specification
3.6. Message Structure
An internet message is composed of three parts. The first is the tid
which identifies the transaction; the second is the Command List; and
the third part is the Document List, which is itself comprised of a
Document-Header and a Document-Body.
When shipped between two MPMs, a message will take the form of a LIST:
Message is:
LIST ( tid, Command-List, Document-List )
It is convenient to batch several messages together shipping them as
a unit from one MPM to another. Such a group of messages is called
a message-bag.
A message-bag will be a LIST of Messages, each Message is of the
form described above.
Thus, a message-bag is:
LIST ( Message1, Message2, ... )
Message Sharing
When messages are batched for delivery, it may 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
parts of the message, much repeated data would be sent if a copy of
the Mail for each recipient were to be shipped in the message-bag.
To avoid this redundancy, messages are assembled in the message-bag
so that actual data appears first and references to it appear later
in the message-bag. Since each message has a unique tid, the
references will indicate the tid of the actual data. In this sense,
all references to copied data may be thought of as pointing earlier
in the message-bag. The data to be retrieved can be thought of as
indexed by tid. Note that the semantics require such references to
point to data already seen.
When a portion is Shared, that portion is determined by its position
within a message, i.e., if the Command list was to be Shared, then
its position within a Message would contain the tid of the message
already seen whose Command list was identical to it. The same is
true of the Document Header and the Document Body. Only a complete
Command, Header, or Body may be Shared, never a partial one.
Postel [Page 33]
March 1979
Internet Message Protocol
Specification
If an encryption scheme is used, that portion of the message which
is encrypted can not be shared. This is due to the fact that
encrypting keys will be specific between two individuals.
Internal Message Organization
The tid
This is the transaction identifier. It is assigned by the
originating MPM.
The Command List
The command-list is a LIST which contains two elements, content
and command.
Content is one item of element type INDEX. If content=0, the item
is not shared and the next element of the LIST is the command. If
content=1 the item is shared. In this case, the second element
will contain the tid of the command to share from. The tid must
be of a prior message in the current message-bag. Other values of
content may be defined later for different data structures.
Thus, command-list is:
LIST ( content, tid ) if content=1
Or,
LIST ( content, command ) if content=0
content is:
INDEX which is 0 if there is no sharing
and is 1 if sharing occurs
tid is:
the tid of the message to be shared from
command is:
LIST ( mailbox, stamp, type, operation, arguments, error-list )
The document-list
The document portion of an internet message is optional and when
present is comprised of a LIST containing two elements:
[Page 34] Postel
March 1979
Internet Message Protocol
Specification
document-list is:
LIST ( header-list, body-list )
While either the header-list or the body-list may be shared, both
elements must appear in the m.
The document-header
The header-list will be a List which will always contain two
elements. The first element will be content to indicate whether
or not the header is to be shared. The second element will either
be the tid of the header to be copied (if content=1) or it will be
the document-header (which is a PROPLIST) containing the actual
header information (if content=0). The tid must point to a
document-header already seen in the message-bag.
The header-list is either:
LIST ( content, tid ) if content=1
Or,
LIST ( content, document-header ) if content=0
document-header is:
PROPLIST which contains header information
The document-body
The body-list will be a LIST of two elements. The first element
will again be content, indicating whether or not the body is to be
shared. If it is shared, the second element will be tid
indicating which body to copy. This tid must be of a message