10/21/83 Mail System Addresses An address identifies an originator or a recipient of a message. A single address refers to one of the following: a Multics mailbox either by pathname or User_id, a Forum meeting, a user (or group of users) on another computer system, an entry in the system's mail table, or a mailing list. Each address has three different representations. The internal representation of an address is used exclusively by the mail system and appears to programs which use the mail system as a PL/I pointer variable. The printed representation of an address is the human readble form of an address which is used when displaying a message or searching a message for a given character string. The control argument representation of an address is the sequence of command/request line arguments and control arguments recognized by the mail system in order to allow a user to specify one or more addresses on a command/request line. List of address types: The following types of addresses are supported by the mail system: user default mailbox address identifies a user's default mailbox by both User_id and pathname. A user's default mailbox mailbox has the pathname -- >udd>Project_id>Person_id>Person_id.mbx and is the mailbox where a user ordinarily receives his incoming mail. logbox address identifies a user's logbox by both User_id and pathname. A user's logbox has the pathname -- >udd>Project_id>Person_id>Person_id.sv.mbx and is one of the mailboxes where a user may store messages for future reference. savebox address identifies a user's savebox by both User_id and pathname. A savebox is any mailbox with a suffix of "sv.mbx". Like the logbox, a user normally stores messages in a savebox for future reference. mailbox address identifies any mailbox by pathname which is not a user's default mailbox, a logbox, or a savebox. forum address identifies any Forum meeting by pathname. foreign address identifies a user (or group of users) on another computer system. A foreign address consists of an arbitrary character string which is the address on the foreign system, the name of the foreign system, and optional explicit and implicit address routes which are used to aid in the delivery of mail to the address. See "Address routes" below for more information. mail table address identifies an entry in the system's mail table by its name or one of its aliases. In addition to its name and aliases, every entry in the mail table includes a mail system address. When mail is sent to a mail table address, it is delivered to the address listed in the mail table for that entry. For more information on the mail table, type: help mail_table.gi mailing list address identifies a mailing list by pathname. A mailing list is an ASCII segment or archive component which contains the printed representations of one or more addresses. When mail is sent to a mailing list, it is delivered to each of the addresses in the list. For more information on mailing lists, type: help mailing_lists.gi named group address identifies a named group of addresses. A named group is distinguished from a mailing list by the fact that the individual addresses which comprise the group appear in the printed representation of the address whereas only the pathname of the mailing list appears in its printed representation. Usually, this type of address is only found in messages which were created on another computer system. invalid address identifies an invalid address. An invalid address will be created by those entrypoints in the mail system which convert printed representations of addresses, etc. into their internal representation if requested by their callers when a character string is found in the printed representation which does not correspond to any of the types of address supported by the mail system. Any attempt to send mail to an invalid address will, of course, be detected as an error. Address names: The address name, which is an optional part of all types of addresses, is a character string which identifies the person who receives mail at a given address. Normally, the address name is the individual's full name; however, in the case of a mailing list or named group, the address name is a global description of the individual addresses within the list. On some non-Multics systems, several persons are allowed to share a single address; in these cases, the system uses the address name to determine for which of these individuals a given message is intended. Address comments: The address comment, which is an optional part of all types of addresses, is a character string with no semantic meaning that may be associated with an address. Although now considered obsolete, the address comment is still supported by the mail system to provide compatibilty with prior releases and with non-Multics systems that still use the address comment in place of the address name. Address routes: As mentioned briefly above, a foreign address may include optional explicit and implicit address routes. An address route defines the path through one or more networks to be used to deliver a piece of mail to a foreign system. An address route is represented as an ordered list of system names. A message is sent by the local system to the first system in the route; that system then sends the message to the second system in the route, and so on until the message arrives at its destination. The mail system will compute the shortest address route for a given foreign address at the time that mail is actually sent to that address. However, this computation may be affected by the explicit and implicit address routes which are part of that foreign address. The explicit route, if present, is the address route which has been specifically requested by a user to be used for the given foreign address. The explicit route is normally used to instruct the mail system how it should deliver mail to a system for which it would not be able to compute an address route. However, if present, an explicit route will always be used by the mail system even when its internal routing algorithms could compute a shorter route to the destination system. The implicit route, if present, is an address route associated with a message that originated on a foreign system. When requested to deliver a message to one of the addresses in the original message (eg: via the read_mail reply request), the mail system will attempt to compute an address route for the address. If the address route computation fails, the mail system will use the implicit route as the route for the address. List of printed representations: The printed representation of an address is the human readable form of that address. It is used by the mail system when displaying a message or searching a message for a given character string. In the following printed representations, braces ({}) actually appear as part of the printed representation and brackets ([]) are used to denote optional parts of a printed representation. The printed representations used by the mail system are: Person_id.Project_id identifies either a user's default mailbox -- >udd>Project_id>Person_id>Person_id.mbx or a user's logbox -- >udd>Project_id>Person_id>Person_id.sv.mbx Any use of this printed representation to create an address will create an address referencing the specified user's default mailbox rather than his logbox to insure that other users will never attempt to send mail directly to his logbox. (By default, only the user can add messages to his logbox). However, when constructing a message for later delivery, the mail system will use the "{logbox}" format described below to represent the user's logbox. This alternate representation allows the user to distinguish between his mailboxes in case he needs to change where his copy of the message will be delivered. {logbox} appears only in the printed representation of messages being prepared for delivery and identifies the user's logbox -- >udd>Project_id>Person_id>Person_id.sv.mbx When the message is actually delivered, the printed representation of this address will be converted to the "Person_id.Project_id" format described above. Person_id.Project_id (STR.sv) identifies a savebox belonging to the specified user. STR is the entryname of the savebox excluding the "sv.mbx" suffix. Any use of this printed representation to create an address will create an address referencing the specified user's default mailbox rather than his savebox to insure that other users will never attempt to send mail directly to his savebox. (By default, only the user can add messages to one of his saveboxes). However, when constructing a message for later delivery, the mail system will use the "{save path}" format described below to represent one of the user's saveboxes. This alternate representation allows the user to distinguish between his mailboxes in case he needs to change where his copy of the message will be delivered. {save path} appears only in the printed representation of a message being prepared for subsequent delivery and identifies a savebox. Path is the absolute pathname of the savebox excluding the "sv.mbx" suffix. When the message is actually delivered, the printed representation of this address will be converted to the "Person_id.Project_id (STR.sv)" format described above. {mbx path} identifies an arbitrary mailbox by pathname. Path is the absolute pathname of the mailbox excluding the "mbx" suffix. {forum path} identifies a Forum meeting by pathname. Path is the absolute pathname of the meeting excluding the "control" suffix. STR at FSystem [address-route] identifies an address on another computer system. STR identifies the user (or group of users) to receive the message and is not interpreted in any way by the local system. FSystem is the name of the foreign system where the address is located. If the optional address-route is not present, FSystem will be the primary name of the foreign system as specified in the local system's network information table (NIT). However, if an address-route is specified, the foreign system name does not have to be known to the local system. See "Printed representation of an address route" below for further information. STR identifies an entry in the system's mail table. STR is the name of the mail table entry. The display_mailing_address command may be used to display the actual address corresponding to this STR. {list path} identifies a mailing list by pathname. Path is the absolute pathname of the mailing list segment or archive component excluding the "mls" suffix. STR: [ADDRs]; identifies a named group address. STR is the name of the group. If present, ADDRs are the printed representations of the addresses which comprise the group and are separated by commas. {invalid STR} identifies and invalid address. STR is the text of the invalid address as it appeared in the original message or address list. Printed representation of an address name: When present, the address name is placed before the printed representation of the address which is then enclosed in angle brackets ("<" and ">"). For example: Site Administrators <{list >udd>ssa>SiteSAs}> Gary M. Palter Printed representation of an address comment: When present, the address comment is enclosed in parentheses and is placed after the printed representation of the address. For example: Palter.Multics (Gary M. Palter) Gary M. Palter Printed representation of an address route: The printed representation of an address route is: [via RelayN ...] via Relay1 where Relay1 is the name of a foreign system in the local system's network information table (NIT) and the remaining names, if any, need not appear in the NIT. Mail directed to an address with this address route will be forwarded to the system identified as Relay1. From there, it will be forwarded to the system identified as Relay2, etc. until it reaches the system identified as RelayN where it will be delivered to the system on which the foreign address actually resides. For example, the printed representation of a foreign address with an address route would be: GMP at EECS.MIT via MC via MIT-MULTICS.ARPA Special characters in printed representations: If a STR, Person_id.Project_id, FSystem, or RelayI in one of the above printed represetnations contains any commas, colons, semi-colons, parentheses, angle brackets (<>), braces ({}), quotes ("), commercial at-signs (@), or whitespace other than single sequences of a space, it must be quoted to avoid ambiguity with other printed representations. Such a string is quoted by surrounding it with quotes and then doubling any quotes found within the string. For example, the string Richard "Rick" Kovalcik, Jr. would be quoted as "Richard ""Rick"" Kovalcik, Jr." If a pathname in one of the above printed representations contains any parentheses, braces ({}), quotes ("), or whitespace other than single sequences of a space, it must be quoted as described above in order to avoid ambiguity. If the text of a comment contains any parentheses, quotes ("), or whitespace other than single sequences of a space, it must be quoted as described above in order to avoid ambiguity. List of control argument representations: The control argument representation of an address is the sequence of command/request line arguments and control arguments recognized by the mail system in order to allow a user to specify one or more mail system addresses on a command/request line. The control argument sequences recognized by the mail system are: -user STR specifies either a user's default mailbox or an entry in the system mail table. See "Notes on the -user address control argument" below for more information. -log specifies the user's logbox and is equivalent to: -mailbox >udd>Project_id>Person_id>Person_id.sv.mbx -save path, -sv path specifies the pathname of a savebox. The suffix "sv.mbx" is added if necessary. -mailbox path, -mbx path specifies the pathname of a mailbox. The suffix "mbx" is added if necessary. -meeting path, -mtg path specifies the pathname of a Forum meeting. The suffix "control" is added if necessary. If the pathname given is just an entryname (ie: no "<" or ">" characters appear in the pathname), the "forum" search path is used to find the meeting. STR -at FSystem {-via RelayN ... -via Relay1} specifies an address on another computer system. See "Notes on the foreign address control argument representation" below for more information. -mailing_list path, -mls path specifies the pathname of a mailing list. The suffix mls is added if necessary. The archive component pathname convention is accepted. For more information, type: help mailing_lists.gi STR is any non-control argument interpreted by the mail system. If STR contains either "<" or ">", it is interpreted as: -mailbox STR otherwise, it is interpreted as: -user STR -name STR, -nm STR must appear immediately following one of the above forms of an address and specifies the name of the address. An address name is usually the full name of the person who receives mail at that address or, for mailing lists, a description of the addresses comprising the mailing list (eg: Site Administrators). -comment STR, -com STR must appear immediately following one of the above forms of an address and specifies a comment to be associated with that address. This control argument is considered obsolete. Notes on the -user address control argument: As listed above, the "-user STR" address is used to specify either a user's default mailbox of an entry in the system mail table. For more information on the mail table, type: help mail_table.gi If the above STR contains exactly one period and no whitespace, it is interpreted as a User_id which specifies a user's default mailbox; otherwise, it is interpreted as the name of an entry in the mail table. For example, -user Sibert.SiteSA is interpreted as a User_id which identifies a default mailbox. On the other hand, -user "Gary M. Palter" -user J.C.Snead are both interpreted as the names of entries in the mail table; the first because it contains whitespace and the second because it contains more than one period. When interpreted as a User_id, the STR may not contain any angle brackets (<>) and must have the form Person_id.Project_id where Person_id may not exceed 28 characters in length and Project_id may not exceed 32 characters in length. In this case, "-user STR" is equivalent to the address -mailbox >udd>Project_id>Person_id>Person_id.mbx When interpreted as the name of a mail table entry, STR may not contain any commas, colons, semi-colons, backslashes (\), parentheses, angle brackets (<>), braces ({}), quotes ("), commercial at-signs (@), or whitespace other than spaces. The query of the mail table is performed in a case insensitive manner. The display_mailing_address command may be used to determine the actual address corresponding to the STR. Notes on the foreign address control argument representation: As listed above, "STR -at FSystem..." specifies an address on another computer system. STR identifies the user (or group of users) to receive the message and is not interpreted in any way by the local system. FSystem is the name of the foreign system where the address is located. If the optional -via control arguments are not present, FSystem must be one of the names of a foreign system in the local system's network information table (NIT). However, if the -via control arguments are specified, the foreign system name does not need to be known to the local system. If the -via control arguments are specified, they identify an explicit route to be used to reach the foreign system. In this case, Relay1 must be one of the names of a foreign system in the local system's NIT. Mail destined for this foreign address will be forwarded to the system identified as Relay1. From there, it will be forwarded to the system identified as Relay2, etc. until it reaches the system identified as RelayN where it will be delivered to the system on which the foreign address actually resides. When the NIT is queried for either FSystem or Relay1, the query will be performed in a case insensitive manner. For example, the address GMP -at OZ -via MC -via mit-multics identifies the address "GMP" on a system named "OZ". In order to send mail to this address, it will be relayed from the local system to the system known as "mit-multics" which must be a system listed in the local NIT. "Mit-multics" will then forward the message to a system named "MC" which will actually deliver the message to its final destination. ----------------------------------------------------------- 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