already seen in the message-bag. If content indicates no sharing,
then the second item is a document-body.
body-list is:
LIST ( content, tid ) if content=1
Or,
LIST ( content, document-body ) if content=0
Postel [Page 35]
March 1979
Internet Message Protocol
Specification
document-body is:
LIST ( items comprising the body ... )
Message Fields
message := ( tid, command-list, document-list )
tid := ( tn, ihn )
command-list := ( content, command )
command := ( mailbox, stamp, type, operation,
arguments, error-list )
document-list := ( header-list, body-list )
header-list := ( content, document-header )
body-list := ( content, document-body )
3.7. MPM Organization
Introduction
The heart of the internet message system is the MPM which is
responsible for routing and delivering message between the networks.
Each network must have at least one MPM. These MPMs are connected
together, and internet mail is always transferred along channels
between them. The system interfaces with the already existent local
message system.
Since the local network 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.
The MPM
Messages in the internet mail system are shipped in "bags," each bag
containing one or more messages. Each bag is addressed to a
specific MPM and contains messages for the hosts on that MPM's
network.
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.
[Page 36] Postel
March 1979
Internet Message Protocol
Specification
Loosely, each MPM can be separated into five 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:
a. Local Host Messages
b. Local Net Messages
c. Foreign Net Messages
3--Local Net Delivery
Delivers local net and local host messages, may call on
conversion program.
4--Foreign Net Router
Creation of new Message-Bags for forwarding to other MPMs,
determines route.
5--Foreign Net Shipper
Activates foreign shipping channels and ships Message-Bag to
foreign MPMs. Performs data compression while shipping bags.
All of these components can be thought of as independent. Of the
five, the Acceptor, the Local-Net Delivery, and the Message-Bag
Processor are fully self-contained and communicate with each other
only through a queue, the Bag-Input Queue. The function of the
Acceptor is to await incoming Message-Bags and to insert them into
the Bag-Input Queue.
That queue is the input to the Message-Bag Processor component 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 a MPM decides to forward a message to another MPM, it must add
its own identification (i.e., its ihn) to the stamp field of the
command. The stamp then becomes a record of the route the message
Postel [Page 37]
March 1979
Internet Message Protocol
Specification
has taken. An MPM should examine the stamp field to see if the
message is in a routing loop. Some commands require the return of
the stamp as a trail in the matching reply command.
All of these queues have as elements complete Message-Bags (some of
which may have been portions of the original Bag).
The Local-Host and Local-Net queues serve as input to the Local-Net
Delivery process. This component is responsible for delivering
messages to its local host and other hosts on its local net to which
it is connected. It must be capable of handling whatever error
conditions the local net might return, including the ability to
retransmit. It may call on 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 one of the
MPMs to which it is connected should receive the Bag.
It then places the Bag along with the routing information into the
Shippable Mail Queue. The Foreign Net Shipper retrieves it from
that queue and transmits it across a channel to the intended foreign
MPM.
The Foreign Net Router should be capable of receiving external input
to its routing information table. This may come from the Foreign
Net Shipper 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 topological
information to determine where to forward any incoming Message-Bag.
Decisions concerning the return of undeliverable Bags are made by
the Router.
It should be stressed here that message delivery should be reliable.
In the event that delivery is impossible, the message should be
returned to the sender along with information regarding the reason
for not delivering it.
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.
[Page 38] Postel
March 1979
Internet Message Protocol
Specification
3.8. 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 weakly 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).
Communication Interface
It is assumed here that the MPM use an underlying communication
system, and TCP [20] has been taken as the model. 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).
Postel [Page 39]
March 1979
Internet Message Protocol
[Page 40] Postel
March 1979
Internet Message Protocol
4. 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@ISIB>
Subject: Meeting Thursday
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie
Dave:
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.
1. message
2. ( tid, command-list, document-list )
3. ( ( tn, ihn ),
( content, command ),
( header-list, body-list ) )
4. ( ( tn, ihn ),
( content,
( mailbox, stamp, type, operation,
arguments, error-list ) ),
( ( content, document-header ),
( content, document-body ) ) )
5. ( ( 37, 167772404 ),
( 0, (
( IA: 167772359, NET: arpa, HOST: rand-unix,
USER: DCrocker ),
( 167772404 ),
1
DELIVER
( ( REGULAR ) ),
( ) ) ),
( ( 0, (
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIB>
Subject: Meeting Thursday
Postel [Page 41]
March 1979
Internet Message Protocol
Examples & Scenarios
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
( 0, ( Dave:
Please mark your calendar for our meeting
Thursday at 3 pm.
--jon. ) ) ) )
6. LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )
[Page 42] Postel
March 1979
Internet Message Protocol
Examples & Scenarios
Example 2: Delivery and Acknowledgment
The following is 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.
+-----------------------------------------------------------------+
! 1 2 !
! sending --> originating --> relay --> destination --> receiving !
! user MPM MPM MPM user !
! !
! 4 3 !
! originating <-- relay <-- destination !
! MPM MPM MPM !
+-----------------------------------------------------------------+
Transmission Path
Figure 6.
Postel [Page 43]
March 1979
Internet Message Protocol
Examples & Scenarios
1. Between the originating MPM and the relay MPM.
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )
The originating MPM sends the message of example 1 to a relay MPM.
[Page 44] Postel
March 1979
Internet Message Protocol
Examples & Scenarios
2. Between the relay MPM and the destination MPM.
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404,
INTEGER=167772246 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )
The relay MPM adds its ihn to the stamp, but otherwise the message
is unchanged.
Postel [Page 45]
March 1979
Internet Message Protocol
Examples & Scenarios
3. Between the destination MPM and the relay MPM.
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359 ),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )
The destination MPM delivers the message to the user's UIP, and
composes an acknowledgment. The acknowledgment is addressed to
the originating MPM. Note that the trail is the stamp of the
incoming message plus the ihn of the destination MPM.
[Page 46] Postel
March 1979
Internet Message Protocol
Examples & Scenarios
4. Between the relay MPM and the originating MPM.
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359
INTEGER=167772246),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )
The relay MPM adds its ihn to the stamp and forwards the
acknowledgment.
Postel [Page 47]
March 1979
Internet Message Protocol
[Page 48] Postel
March 1979
Internet Message Protocol
GLOSSARY
1822
BBN Report 1822, "The Specification of the Interconnection of
a Host and an IMP". The specification of interface between a
host and the ARPANET.
Command List
The part of a message used by the MPMs to determine the
processing action to be taken.
datagram
A logical unit of data, in particular an internet datagram is
the unit of data transfered between the internet module and a
higher level module.
Destination
The destination address, an internet header datagram protocol
field.
Document List
The part of the message created by or delivered to a user.
header
Control information at the beginning of a message, segment,
datagram, packet or block of data.
IMP
The Interface Message Processor, the packet switch of the
ARPANET.
Internet Address
A four octet (32 bit) source or destination address consisting
of a Network field and a Local Address field.
internet datagram
The unit of data exchanged between a pair of internet modules
(includes the internet header).
Local Address
The address of a host within a network. The actual mapping of
an internet local address on to the host addresses in a
network is quite general, allowing for many to one mappings.
Postel [Page 49]
March 1979
Internet Message Protocol
Glossary
message
The unit of information transmitted between users of message
systems. As transmitted between MPMs a message consists of a
Transaction Identifier, a Command List, and a Document List.
module
An implementation, usually in software, of a protocol or other
procedure.
MPM
A Message Processing Module, the process which implements this
internet message protocol.
octet
An eight bit byte.
Rest
The 3 octet (24 bit) local address portion of an Internet
Address.
RTP
Real Time Protocol: A host-to-host protocol for communication
of time critical information.
Source
The source address, an internet header field.
TCP
Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments.
Transaction Identifier
The unique identifier of a message.
Type of Service
An internet datagram protocol header field which indicates the
type (or quality) of service for this internet packet.
UIP
A User Interface Program, a program which presents message
data to a user and accepts message data from a user. A
program which interacts with the user in the composition and
examination of messages.
XNET
A cross-net debugging protocol.
[Page 50] Postel
March 1979
Internet Message Protocol
REFERENCES
[1] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192,
February 1979.
[2] Bhushan, A., K. Progran, R. Tomlinson, and J. White,
"Standardizing Network Mail Headers," RFC561, NIC 18516, 5
September 1973.
[3] Bolt Beranek and Newman, "Specification for the Interconnection of
a Host and an IMP," BBN Technical Report 1822, May 1978 (Revised).
[4] Braaten, O., "Introduction to a Mail Protocol," Norwegian
Computing Center, INWG 180, August 1978.
[5] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[6] Crocker, D., J. Vittal, K. Progran, and D. Henderson, "Standard
for the Format of ARPA Network Text Messages," RFC733, NIC 41952,
21 November 1977.
[7] Crocker, D., E. Szurkowski, and D. Farber, "Components of a
Channel-independent Memo Transmission System," Department of
Electrical Engineering, University of Delaware,, February 1979.
[8] 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.
[9] Harrenstien, K., "Field Addressing," ARPANET Message, SRI
International, October 1977.
[10] Haverty, J., "MSDTP -- Message Services Data Transmission
Protocol," RFC713, NIC 34739, April 1976.
[11] Haverty, J., "Thoughts on Interactions in Distributed Services,"
RFC722, NIC 36806, 16 September 1976.
[12] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed
Specification of an Inter-site Message Protocol," 8 July 1975.
[13] ISO-2014, "Writing of calendar dates in all-numeric form,"
Recommendation 2014, International Organization for
Standardization, 1975.
Postel [Page 51]
March 1979
Internet Message Protocol
References
[14] ISO-3307, "Information Interchange -- Representations of time of
the day," Recommendation 3307, International Organization for
Standardization, 1975.
[15] ISO-4031, "Information Interchange -- Representation of local time
differentials," Recommendation 4031, International Organization
for Standardization, 1978.
[16] Myer, T., and D. Henderson, "Message Transmission Protocol,"
RFC680, NIC 32116, 30 April 1975.
[17] Postel, J. "Internetwork Datagram Protocol, Version 4," USC
Information Sciences Institute, IEN 80, February 1979.
[18] Postel, J. "NSW Data Representation (NSWB8)," IEN 39, May 1978.
[19] Postel, J. "NSW Transaction Protocol (NSWTP)," IEN 38, May 1978.
[20] Postel, J. "Transmission Control Protocol, TCP, Version 4," USC
Information Sciences Institute, IEN 81, February 1979.
[21] Postel, J., "Assigned Numbers," RFC750, NIC 45500,
26 September 1978.
[22] Postel, J., "Message System Transition Plan," JBP 64,
USC-Information Sciences Institute, February 1979.
[23] Rivest, R. L. "A Method for Obtaining Digital Signatures and
Public-Key Cryptosystems" Communications of the ACM, Vol. 21,
Number 2, February 1978.
[24] Shoch, J., "A Note On Inter-Network Naming, Addressing, and
Routing," Xerox Palo Alto Research Center, IEN 19, January 1978.
[25] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW
Working Note 24, Bolt Beranek and Newman, October 1978.
[26] White, J., "A Proposed Mail Protocol," RFC524, NIC 17140, 13 June
1973.
[27] White, J., "Description of a Multi-Host Journal," NIC 23144,
30 May 1974.
[28] White, J., "Journal Subscription Service," NIC 23143, 28 May 1974.
[Page 52] Postel
March 1979
Internet Message Protocol
APPENDICES
A. Encryption
It would be straightforward to add the capability to have the document
portion of messages either wholly or partially encrypted. The
approach is to define an additional basic data element to carry
encrypted data. The data within this element could be composed of
other elements, but that could only be perceived after the data was
decrypted.
+------+------+------+------+-------
9 Encrypt ! 9 ! octet count ! Data ...
+------+------+------+------+--------
Element code 9 (ENCRYPT) is Encrypt. The format is the one octet type
code, the three octet type count, and count octets of data. Use of
this element indicates that the data it contains is encrypted. The
encryption scheme is yet to be decided but will probably be the Public
Key Encryption technique [23] due to the capacity for coded
signatures.
To process this, the user is asked for the appropriate key the first
time an encryption block is seen for a particular message. The
encrypted data is then decrypted. The data thus revealed will be in
the form of complete data type 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.
Postel [Page 53]
March 1979
Internet Message Protocol
Appendices
B. Data Compression
When message-bags are shipped between MPMs the data should be
compressed according to the following scheme:
shipping-unit := compression-type message-bag
compression-type := A one octet compression type indicator.
compression-type value description
---------------------- -----------
0 no compression used
1 basic compression
basic compression
This basic compression procedure is the same as that defined for
use with the ARPANET FTP [8]. Three types of compression-units
may be formed, sequence-units, replication-units, and
filler-units. The data is formed into a series of
compression-units independent of the structure or object and
element boundaries.
sequence-unit
A sequence-unit is a one octet flag and count followed by that
many data octets.
+-+-------+--------+--------+----
!0! n ! n data octets ...
+-+-------+--------+--------+----
The flag and count octet has its high order bit zero and the
remaining bits indicate the count (in the range 0 to 127) of
following data octets.
replication-unit
A replication-unit is a one octet flag and count followed by one
data octet, which is to be replicated count times.
+--+------+--------+
!10! n ! data !
+--+------+--------+
The flag and count octet has its high order two bits equal
one-zero and the remaining six bits indicate the count (in the
range 0 to 63) of number of time to replicate the data octet.
[Page 54] Postel
March 1979
Internet Message Protocol
Appendices
filler-unit
A filler-unit is a one octet flag and count, indicating that a
filler octet is to be inserted count times.
+--+------+
!11! n !
+--+------+
The flag and count octet has its high order two bits equal
one-one and the remaining six bits indicate the count (in the
range 0 to 63) of number of time to insert the filler octet.
The filler octet is zero, the octet with all bits zero.
Postel [Page 55]
March 1979
Internet Message Protocol