IEN: 113 RFC: 759 INTERNET MESSAGE PROTOCOL Jonathan B. Postel August 1980 Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 August 1980 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. Model of Operation ........................................... 2 1.5. Interfaces ................................................... 4 2. FUNCTIONAL DESCRIPTION ........................................... 5 2.1. Terminology .................................................. 5 2.2. Assumptions ................................................. 5 2.3. General Specification ........................................ 6 2.4. Mechanisms ................................................... 7 2.5. Relation to Other Protocols ................................. 10 3. DETAILED SPECIFICATION .......................................... 13 3.1. Overview of Message Structure ............................... 13 3.2. Message Structure ........................................... 14 3.3. Identification .............................................. 15 3.4. Command ..................................................... 15 3.5. Document .................................................... 19 3.6. Message Objects ............................................. 20 3.7. Data Elements ............................................... 27 4. OTHER ISSUES .................................................... 35 4.1. Accounting and Billing ...................................... 35 4.2. Addressing and Routing ...................................... 36 4.3. Encryption .................................................. 37 5. The MPM: A Possible Architecture ............................... 39 5.1. Interfaces .................................................. 39 5.2. MPM Organization ............................................ 40 6. EXAMPLES & SCENARIOS ............................................ 45 Example 1: Message Format ........................................ 45 Example 2: Delivery and Acknowledgment ........................... 47 Postel [Page i] August 1980 Internet Message Protocol Table Of Contents 7. SPECIFICATION SUMMARY ........................................... 55 7.1. Message Fields .............................................. 55 7.2. Deliver Message ............................................. 58 7.3. Acknowledge Message ......................................... 59 7.4. Probe Message ............................................... 61 7.5. Response Message ............................................ 62 7.6. Cancel Message .............................................. 64 7.7. Canceled Message ............................................ 66 7.8. Data Element Summary ........................................ 68 REFERENCES .......................................................... 69 [Page ii] Postel August 1980 Internet Message Protocol PREFACE This is the second 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 discussions 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, Suzanne Sluizer, Alan Katz, Paul Mockapetris, and Linda Sato. Jon Postel Postel [Page iii] IEN: 113 J. Postel RFC: 759 USC-ISI August 1980 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 delivery 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 delivery system in its own right. This system also provides for the communication of data items beyond the scope of contemporary message systems. Messages can include data objects 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 for the composition of complex data objects and their encoding in machine independent basic data elements. 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 Postel [Page 1] August 1980 Internet Message Protocol Introduction developed in the context of the ARPA work on the interconnection of networks, but it is thought that it has a more general scope. 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 this 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 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 [1,2]. 1.4. Model of Operation This protocol is implemented in a process 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 message it is submitted for transmission by placing it in a data structure read by 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 (or some other method), determines which outgoing link to use. The destination may be another user on the same host, one on another host on a network in common with the same host, or a user in another network. In the first case, another user on this host, the MPM places the message in a data structure read by 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 [Page 2] Postel August 1980 Internet Message Protocol Introduction the routing decision, and discovering the destination is local to it, places the message in the data structure shared with the destination user. 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. An 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. An 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 an MPM which then sends it through the appropriate gateways to (or towards) the MPM in the destination network. Eventually, the message gets to an 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 potentially lead to information loss. 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 discards 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 deferred as long as possible; still, the possibility remains that in some cases it is the only reasonable thing to do. Postel [Page 3] August 1980 Internet Message Protocol Introduction 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 Transmission Control Protocol (TCP) [3]. 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). 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 August 1980 Internet Message Protocol 2. FUNCTIONAL DESCRIPTION This section gives an overview of the Internet Message System and its environment. 2.1. Terminology 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. The basic unit transferred between MPMs is called a message. A message is made up of a transaction identifier (which uniquely identifies the message), a command (which contains the necessary information for delivery), and document. The document may have a header and a body. For a personal letter the document body corresponds to the contents of the letter; the document header corresponds to the date line, greeting, and signature. 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. Some of the information in the command is supplied by the UIP. 2.2. Assumptions The following assumptions are made about the internetwork environment: In general, it is 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. Each MPM is required to know completely only the addressing format of its own network(s). 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 numeric address. Such names and addresses are Postel [Page 5] August 1980 Internet Message Protocol Functional Description registered with a naming authority and may be listed in documents such as Assigned Numbers [4]. Each MPM will have a unique internet address. This feature will enable every MPM to place a unique "handling-stamp" on a message which passes through the MPM enroute 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 \ / UIP UIP \ / --+----------------------------------------+-- 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, 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 via different communication services. [Page 6] Postel August 1980 Internet Message Protocol Functional Description 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 MPMs, though all communication services must meet the service characteristics described below. 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) [3]. 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). All data sent is delivered in order. o Simple commands to open and close the connections, and to send and receive data on the connections. 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 of the sender or receiver. Complete breakdown on communication is reported to the sender or receiver. 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. An MPM might exist in two (or more) interprocess communication environments, and such an MPM might act to relay messages between MPMs. Messages may be held for a time in an MPM; the total path required for delivery need not be available simultaneously. From the time a message is accepted from a UIP by an MPM until it is delivered to a UIP by an MPM and an acknowledgment is returned to the Postel [Page 7] August 1980 Internet Message Protocol Functional Description originating UIP, the message is considered to be active in the message system. User User \ / UIP UIP \ / +---------------------------------------------------------+ | \ / | | +-----+ +-----+ +-----+ | | | MPM | <--Protocol--> | MPM | <--Protocol--> | MPM | | | +-----+ +-----+ +-----+ | | | / \ | | | +-----------------------+ +-----------------------+ | | |Communication Service A| |Communication Service B| | | +-----------------------+ +-----------------------+ | | | +---------------------------------------------------------+ Message Service with Internal Relaying Figure 2. It should be clear that there are two roles an MPM can play, an end-point MPM or a relay MPM. Most MPMs will play both roles. A relay MPM acts to relay messages from one communication environment to another. An end-point MPM acts as a source or destination of messages. The transfer of data between UIPs and MPMs is viewed 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 August 1980 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 an MPM (or a UIP), a message may be represented in any convenient form. Postel [Page 9] August 1980 Internet Message Protocol Functional Description 2.5. Relation to Other Protocols This protocol the benefited from the earlier work on message protocols in the ARPA Network [5,6,7,8,9], and the ideas of others about the design of computer message systems [10,11,12,13,14,15,16,17,18,19,20,21]. Figure 4 illustrates the place of the message protocol in the ARPA internet protocol hierarchy: +------+ +-----+ +-------+ +-----+ +-----+ |Telnet| | FTP | |Message| |Voice| ... | | Application Level +------+ +-----+ +-------+ +-----+ +-----+ \ | / | | +-----+ +-----+ +-----+ | TCP | | RTP | ... | | Host Level +-----+ +-----+ +-----+ | | | +-------------------------------+ | Internet Protocol | Gateway Level +-------------------------------+ | +---------------------------+ | Local Network Protocol | Network Level +---------------------------+ | Protocol Relationships Figure 4. Note that "local network" means an individual or specific network. For example, the ARPANET is a local network. The message protocol interfaces on one side to user interface programs and on the other side to a reliable transport protocol such as TCP. In this internet message system the MPMs communicate directly using the lower level transport protocol. In the old ARPANET system, message transmission was part of the file transfer protocol. [Page 10] Postel August 1980 Internet Message Protocol Functional Description +------+ +-----+ +-------+ |Telnet| | FTP |---|Message| Application Level +------+ +-----+ +-------+ \ / +-----+ +-----+ |Voice|---| NCP | Host Level +-----+ +-----+ | | | Gateway Level | | +----------------+ | ARPA NET | Network Level +----------------+ Old ARPANET Protocols Figure 5. Note that in the old ARPANET protocols one can't send messages (or communicate in any way) to other networks since it has no gateway level or internet protocol [5]. Postel [Page 11] August 1980 Internet Message Protocol [Page 12] Postel August 1980 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 medium it has to come in some order. In this attempt, a brief overview of the message structure is given, the detail of the message is presented in terms of data objects, the various data objects are defined, and finally the representation of the data elements is specified. Several aspects of the message structure are based on the NSW Transaction Protocol [22], and similar (but more general) proposals [23,24]. 3.1. Overview of Message Structure A message is normally composed of three parts: the identification, the command, and the document. Each part is in turn composed of data objects. The identification part is composed of a transaction number assigned by the originating MPM and the MPM identifier. The command part is composed of an operation type, an operation code, the arguments to the operation, error information, the destination mailbox, and a trace. The trace is a list of the MPMs that have handled this message. The document part is a data structure. The message delivery system does not depend on the contents of the document part. A standard for the document part is defined in reference [25]. 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. The basic data elements are defined in section 3.7. In summary, these are exact forms for representing integers, strings, booleans, et cetera. There are also two elements for building data structures: list and property list. Lists are simple lists of elements, including lists. Property lists are lists of pairs of elements, where the first element of each pair names the pair. That is, a property list is a list of pairs. In general, when an object is composed of multiple instances of a simpler object it is represented as a list of the simpler objects. When an object is composed of a variety of simpler objects it is represented as a property list of the simpler objects. In most uses of the property list representation, the presence of pairs in addition to those specifically required is permitted. Postel [Page 13] August 1980 Internet Message Protocol Specification 3.2. Message Structure An internet message is composed of two or three parts. The first is the Identification which identifies the transaction; the second is the Command; and the optional third part is the Document. When shipped between two MPMs, a message will take the form of a property list, with the pairs in this order. MESSAGE is: ( Identification, Command [, Document ] ) 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. MESSAGE-BAG is: ( Message, Message, ... ) The Identification This is the transaction identifier. It is assigned by the originating MPM. The identification is composed of the MPM identifier, and a transaction number unique in that context for this message. The Command The command is composed of a mailbox, an operation code, the arguments to that operation, some error information, and a trace of the route of this message. The command is implemented by a property list which contains pairs, where the names are used to identify the associated argument values. The Document The document portion of an internet message is optional and when present is a data structure as defined in [25]. [Page 14] Postel August 1980 Internet Message Protocol Specification 3.3. Identification Each message must have a unique identifier while it exists in the message delivery system. This is provided by the combination of the unique identifier of the MPM and a unique transaction number chosen for the message by this MPM. IDENTIFICATION is: ( mpm-identifier, transaction-number ) The mpm-identifier is based on the host address of the computer in which the MPM resides. If there is more than one MPM in a host the mpm-identifier must be extended to distinguish between the co-resident MPMs. 3.4. Command This section describes the commands MPMs use to communicate between themselves. The commands come in pairs, with each request having a corresponding reply. COMMAND is: ( mailbox, operation, [arguments,] [error-class, error-string,] trace ) The mailbox is the "To" specification of the message. Mailbox is 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 property list without extra information. The mailbox includes a specification of the user, when a command is addressed to the MPM itself (rather than a user it serves) the special user name "*MPM*" is specified. The operation is the name of the operation or procedure to be performed. The arguments to the operation vary from operation to operation. The error information is composed of a error class code and a character string, and indicates what, if any, error occurred. The error information is normally present only in replies, and not present in requests. Postel [Page 15] August 1980 Internet Message Protocol Specification The trace is a list of the MPMs that have handled the message. Each MPM must add its handling-stamp to the list. [Page 16] Postel August 1980 Internet Message Protocol Specification 3.4.1. Command: DELIVER function: Sends a document to a mailbox. reply: The reply is ACKNOWLEDGE. arguments: type-of-service: one or more of the following: "REGULAR" regular delivery "FORWARD" message forwarding "GENDEL" general delivery "PRIORITY" priority delivery 3.4.2. Command: ACKNOWLEDGE function: Reply to DELIVER. arguments: reference: the identifier of the originating message. address: The address is the final mailbox the message was delivered to. This would be different from the original mailbox if the message was forwarded, and is limited to the essential information needed for delivery. type-of-service: one of the following: "GENDEL" message was accepted for general delivery "REGULAR" message was accepted for normal delivery "PRIORITY" message was accepted for priority delivery error-class: error-string: If the document was delivered successfully, the error information has class 0 and string "ok". Otherwise, the error information has a non-zero class and the string would be one of "no such user", "no such host", "no such network", "address ambiguous", or a similar response. trail: the trace from the DELIVER command. Postel [Page 17] August 1980 Internet Message Protocol Specification 3.4.3. Command: PROBE function: Finds out if specified mailbox (specified in mailbox of the command) exists at a host. reply: The reply is RESPONSE. arguments: none. 3.4.4. Command: RESPONSE function: Reply to PROBE. arguments: reference: the identification of the originating PROBE. address: a specific address. error-class: error-string: If the mailbox was found the error class is 0 and the error string is "OK". If the mailbox has moved and a forwarding address in known the error class is 1 and the error string is "Mailbox moved, see address". Otherwise the error class is greater than 1 and the error string may be one of the following: "Mailbox doesn't exist", "Mailbox full", "Mailbox has moved, try the new location indicated in the address". trail: the trace which came from the originating PROBE. [Page 18] Postel August 1980 Internet Message Protocol Specification 3.4.5. Command: CANCEL function: Abort request for specified transaction. reply: The reply is CANCELED. arguments: reference: identification of transaction to be canceled. 3.4.6. Command: CANCELED function: Reply to CANCEL. arguments: reference: identification of canceled transaction. error-class: error-string: If the command was canceled the error class is 0 and the error string is "OK". Otherwise the error class is positive and the error string may be one of the following: "No such transaction", or any error for an unreachable mailbox. trail: the trace of the CANCEL command. To summarize again, a command generally consists of a property list of the following objects: name value ---- ----- mailbox property list of address information operation name of operation arguments --- error-class numeric class of the error error-string text description of the error trace list ( handling-stamp, ... ) 3.5. Document The actual document follows the command. The message delivery system does not depend on the document, examine it, or use it in any way. The standard for the contents of the document is reference [25]. The document must be the last pair in the message property list. Postel [Page 19] August 1980 Internet Message Protocol Specification 3.6. Message Objects In the composition of messages, we use a set of objects such as mailbox or date. These objects are encoded in basic data elements. Some objects are simple things like integers or character strings, other objects are more complex things built up of lists or property lists. The following is a list of the objects used in messages. The object descriptions are in alphabetical order. Action The type of handling action taken by the MPM when processing a message. One of ORIGIN, RELAY, FORWARD, or DESTINATION. Address Address is intended to contain the minimum information necessary to deliver a message, and no more (compare with mailbox). An address is a property list. An address contains the following pairs: name description ---- ----------- NET network name HOST host name USER user name or: name description ---- ----------- MPM mpm-identifier USER user name Answer A yes (true) or no (false) answer to a question. Arguments Many operations require arguments, which differ from command to command. This "object" is a place holder for the actual arguments when commands are described in a general way. [Page 20] Postel August 1980 Internet Message Protocol Specification City The character string name of a city. Command (mailbox, operation [ ,arguments ] [ ,error-class, error-string ], trace) Country The character string name of a country. Date The date and time are represented according to the International Standards Organization (ISO) recommendations [26,27,28]. 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 four-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. The time is local time and the offset is the difference between local time and Coordinated Universal Time (UTC). To convert from local time to UTC algebraically subtract the offset from the local time. For example, when the time in Los Angeles is 14:25:00-08:00 the UTC is 22:25:00 or when the time in Paris is 11:43:00+01:00 the UTC is 10:43:00 Document The document is the user's composition and is not used by the message delivery system in any way. Postel [Page 21] August 1980 Internet Message Protocol Specification Error-Class A numeric code for the class of the error. The error classes are coded as follows: = 0: indicates success, no error. This is the normal case. = 1: failure, address changed. This error is used when forwarding is possible, but not allowed by the type of service specified. = 2: failure, resources unavailable. These errors are temporary and the command they respond to may work if attempted at a later time. = 3: failure, user error. For example, unknown operation, or bad arguments. = 4: failure, MPM error. Recoverable. These errors are temporary and the command they respond to may work if attempted at a later time. = 5: failure, MPM error. Permanent. These errors are permanent, there is no point in trying the same command again. = 6: Aborted as requested by user. The response to a successfully canceled command. [Page 22] Postel August 1980 Internet Message Protocol Specification Error-String This is a character string describing the error. Possible errors: error-string error-class No errors 0 Ok 0 Mailbox Moved, see address 1 Mailbox Full, try again later 2 Syntax error, operation unrecognized 3 Syntax error, in arguments 3 No Such User 3 No Such Host 3 No Such Network 3 No Such Transaction 3 Mailbox Does Not Exist 3 Ambiguous Address 3 Server error, try again later 4 No service available 5 Command not implemented 5 Aborted as requested by user 6 Handling-Stamp The handling-stamp indicates the MPM, the date (including the time) that a message was processed by an MPM, and the type of handling action taken. ( mpm-identifier, date, action ) Host The character string name of a host. Identification This is the transaction identifier associated with a particular message. It is the transaction number, and the MPM identifier of the originating MPM. ( mpm-identifier, transaction-number ) Postel [Page 23] August 1980 Internet Message Protocol Specification Internet Address This identifies a host in the ARPA internetwork environment. When used as a part of identification, it identifies the originating host of a message. The internet address 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 [2]. For use in the MPMs the internet address is divided into eight bit fields and the value of each field is represented in decimal digits. For example, the ARPANET address of ISIE is 167837748 and is represented as 10,1,0,52. Further, this representation may be extended to include an address within a host, such as the TCP port of the MPM, for example, 10,1,0,52,0,45. Mailbox This is the destination address of a user of the internetwork mail system. Mailbox contains information such as network, host, location, and local user indentifier 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 will contain an Address (as opposed to Mailbox) which may be used from then on. A mailbox is a property list. A mailbox might contain the following pairs: name description ---- ----------- MPM mpm-identifier NET network name HOST host name PORT address of MPM within the host USER user name ORG organization name CITY city STATE state COUNTRY country ZIP zip code PHONE phone number The minimum mail box is an Address. [Page 24] Postel August 1980 Internet Message Protocol Specific