12/07/83 Mail System Message Format A message is the basic unit of communication between users. There are two types of message: ordinary and interactive. An interactive message is a message which is displayed immediately on the user's terminal when it is delivered. An ordinary message is a message which is only displayed at the user's explicit request after it has been delivered. Whenever the mail system delivers an ordinary message to a user, it also delivers an interactive message to inform the user that the ordinary message was just delivered. Message structure: The mail system represents a message as a structured object comprised of four parts: an envelope, a header, a redistributions list, and a body. With the exception of the body, each of these parts contains several fields. The message envelope describes when, by whom, and via what route the message was mailed and subsequently delivered. The message header contains the message's subject, author(s), and recipient(s). For a message which is a reply to other messages, the header contains information which identifies those original messages. The header may also contain additional fields which are used by user written application programs. The redistributions list records each time the message was redistributed (forwarded) by one user to another. The information recorded for each redistribution includes the user(s) who requested the redistribution, the date/time it was requested, the recipient(s) of the redistribution, and an optional comment. The message body is the actual content of the message. The body is divided into one or more sections. Each section may have its own distinct structure and formatting instructions. List of message envelope fields: Posted-Date is the date/time that the message was given to the mail system for delivery. This field is only present if the message was not created and posted simultaneously. Sender is the address of the actual user who gave the message to the mail system for delivery. This field is only present if there is more than one author of the message or if the author was not the user who gave the message to the mail system. Route is only present in messages which originated on another computer system and lists the systems through which the message was relayed in order to reach this system. Relayed is only present in messages which originated on another computer system and describes a single relay operation. This field includes the date/time of the relay, the sending and receiving systems, and an optional description of the protocols used. This field may appear in the message more than once. Delivery-Date is the date/time that the mail system delivered this message to the user's mailbox. This field is only present if the message was not posted and delivered simultaneously. Delivery-By is the address of the actual user in whose process the mail system delivered this message to the user's mailbox. This field is only present if the delivery agent was different from the sender. Acknowledge-To is the address of the user who is to receive an acknowledgement when this message is read by a recipient. This field is only present if the message requests an acknowledgement. List of message header fields: With the exception of the Date, From, Access-Class, and Message-ID fields, all fields in the message header are optional. Date is the date/time that the message body was created. From is the list of addresses of the user(s) responsible for the content of the message. These users are also known as the authors of the message. Subject is the subject of the message. Reply-To is the list of addresses of the recipients for any future replies to this message. If this field is not present, replies will be sent to the authors as listed in the From field. To is the list of addresses of the primary recipients of the message. cc is the list of addresses of the secondary recipients of the message. bcc is the list of addresses of the "blind" recipients of the message. The copies of the message delivered to the primary and secondary recipients do not include this list. In-Reply-To is the list of references to the messages for which this message is a reply. Each reference includes the values of the referenced message's Date, From, Subject, and Message-ID fields. Access-Class is the Access Isolation Mechanism (AIM) access class of the message. A user may read the message only if his process authorization is greater than or equal to this access class; a user may delete the message only if his authorization is equal to this access class. Message-ID is the unique identifier associated with the body of the message. If two messages have the same value for this field, they contain the same message body; however, their envelopes, headers, and redistribution lists may differ. List of message redistribution fields: In addition to the fields described in this, each redistribution also has its own envelope which contains the fields described above. For a redistribution, however, the envelope fields are called Redistributed-Posted-Date, Redistributed-Sender, etc. With the exception of the Redistributed-Date, Redistributed-From, and Redistributed-Message-ID fields, all fields in a redistribution are optional. Redistributed-Date is the date/time that the redistribution was requested and the redistribution's comment, if any, was created. Redistributed-From is the list of addresses of the user(s) who requested that the redistribution take place. Redistributed-To is the list of addresses of the recipients of the redistribution. Redistributed-Comment is the text of the comment associated with the redistribution of the message. Redistributed-Message-ID is the unique identifier associated with the redistribution. If two redistributions in multiple copies of a message have the same value for this field, they are the same redistribution. Printed representation of a message: The printed representation of a message is the human readable form of that message. It is used by the mail system when displaying a message. The basic format of the printed representation is --
where is the printed representation of the message envelope, etc. As can be seen from the above, the printed representation of the message body is separated from the other parts of the message by a blank line; the printed representations of the envelope, header, and redistributions list, on the other hand, are contiguous. The user may request that different levels of detail should be used when displaying the contents of the envelope, header, and redistributions list. The message header and redistributions list may be displayed in long, default, or brief form; the message envelope may be displayed only in long or default form. Printed representation of the message envelope: The long form of the printed representation of the message envelope follows: Posted-Date: Sender:
Route: Relayed: from to using with via ID for
; Relayed: ... Delivery-Date: Delivery-By:
Acknowledge-To:
The Route and Relayed fields are only displayed in the long form of the message envelope. The first Relayed field displayed describes the oldest relay operation and the last Relayed field describes the most recent relay operation. The Acknowledge-To field is only displayed if the message requests an acknowledgement. In the long form of the message envelope, all fields except the Route, Relayed, and Acknowledge-To fields are displayed. If the Posted-Date field is not present, the value of the Date field in the message header is used; if the Delivery-Date field is not present, the value of the Posted-Date field (or, if needed, the Date field) is used. If the Sender field is not present, the single address in the From field of the message header is used; if the Delivery-By field is not present, the value of the Sender field (or, if needed, the From field) is used. In the default form of the message envelope, the Posted-Date field is displayed only if its value differs from the Date field of the message header; the Delivery-Date field is displayed only if its value differs from the Posted-Date field. The Sender field is displayed on if its value differs from the From field of the message header; the Delivery-By field is displayed only if its value differs from the Sender field. Printed representation of the message header: The long form of the printed represenation of the message header follows: Date: From: Subject: Reply-To: To: cc: bcc: In-Reply-To: Access-Class: Message-ID: : : ... The optional fields in the message header are not displayed unless they are present in the header. (Ie: the field name will not be displayed without a subsequent field value). The Access-Class field is always displayed in the long form of the header. It is ommitted from the default form if it is equal to the user's process authorization. It is always ommitted from the brief form of the header. The Message-ID field is only displayed in the long form of the header. In the brief form of the message header, the Date and From fields are always displayed. The Subject field is displayed if present. None of the other fields in the header are displayed. However, if the user is not the only recipient of the message, the following psuedo-field is displayed in place of the To, cc, and bcc fields: Recipients: {Yourself and} N others where N is the number of recipients of the message in addition to the user. The string "Yourself and" is displayed only if the user is explicitly mentioned in one of the To, cc, or bcc fields. Printed representation of the redistributions list: The long form of the printed representation of the redistributions list follows: ..... where is the first (oldest) redistribution of the message and is the last (latest) redistribution of the message. The long form of the printed representation of a single redistribution follows: Redistributed-Date: Redistributed-From: Redistributed-To: Redistributed-Comment: Redistributed-Message-ID: where is the printed representation of the redistribution's envelope as described above. However, all field names in the envelope are prefixed with the string "Redistributed-". The redistribution envelope's printed representation is ommitted from the brief form of the redistribution. The optional fields in the redistribution are not displayed unless they are present in the redistribution. (Ie: the field name will not be displayed without a subsequent field value). In the brief form of a redistribution, the Redistributed-To field is replaced by a Redistributed-Recipients psuedo-field as described above for the To, cc, and bcc fields. The Redistributed-Message-ID field is ommitted from the default and brief forms of the redistribution. The entire redistribution is ommitted from the brief form of the redistributions list if it does contain a comment. If the last redistribution is ommitted from the brief form of the redistributions list, the Last-Redistributed psuedo field is displayed in its place. The format of this field is Last-Redistributed: by
Canonical form of a message: The canonical form of a message is a variant of the default form of the printed representation of the message. The canonical form is used by the mail system when storing the message in a mailbox or searching the message for a given character string. The canonical form of a message differs from the default printed representation as follows: In the canonical form, the redistributions list appears before the message envelope; in the default printed representation, it appears after the message header. In the canonical form, the redistributions appear in reverse chronological order (ie: the latest redistribution is first, etc.); in the default printed representation, they are in chronological order. The Message-ID, Route, and Relayed fields are included in the canonical form; they are omitted from the default printed representation. List of field value representations: is the printed representation of a date/time. Its format is DD Month YYYY HH:MM zone For example: 9 April 1983 12:17 edt is the printed representation of a date/time. Its format is DayName, DD Month YYYY HH:MM zone For example: Saturday, 9 April 1983 12:17 edt
is the printed representation of the address in the given field. For a description of these representations, type: help addresses.gi -section printed representations is the printed representation of a list of addresses. Its format is , , ..., is the printed representation of an address route. For a description of this representation, type: help addresses.gi -section printed representations is the printed representation of the text comprising the given field. This representation consists of the acutal text with two exceptions. If the text is more than one line long, each additional line is indented by an amount equal to the indentation of the first line of the text If any line in the text is blank, the string "--" is placed on that line just before the left margin of actual text. For example: Subject: Sample text field that is multiple lines with some lines indented more than others -- and also some blank lines. is the printed representation of a set of message references. The printed representation of a single message reference has the following format: Message of from where is the address name of the first address in the From field of the referenced message. If this address does not have a name, its printed representation is used instead. For example: Message of 1 May 1983 17:49 edt from Gary Palter If the list contains multiple references, they are separated by commas and the second through last references are indented by sufficient whitespace to align them with the first reference. For example: In-Reply-To: Message of 9 April 1983 14:50 edt ..., Message of 1 May 1983 10:17 edt from ... is the printed representation of an AIM access class as returned by the standard system subroutine convert_authorization_$to_string_short. is the printed representation of a unique identifier. Its format is where STR is the actual unique identifier which, if generated by a Multics system, will be the long form of a request ID. (Type: help request_ids.gi for a description of the format of a request ID). If the identifier was generated by a foreign system, that system's name is included in the printed representation in the "at HOST' phrase. The angle brackets (<>) above are actually part of the representation; the braces ({}) are not. is the name of a user-defined field in the message header. is the printed representation of the value of a user-defined field. It will be a , , or . is the name of the sending system for a relay operation. is the name of the receiving system for a relay operation. is the name of the mail transport protocol used for a relay operation. is the name of the communications protocol used for a relay operation. is the name of the communications media used for a relay operation. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved