10/10/83 Enhancements to the send_mail command This info segment briefly describes the enhancements made to the send_mail command in various system releases. 10/10/83 List of enhancements in MR10.2: (1) mail table addresses, (2) mailing lists, (3) forum addresses, (4) changes to the qedx request, (5) support of the "blind" recipients list, (6) improved address representations (7) changes to the In-Reply-To field, (8) stricter command line address parsing, and (9) pending removal of the "-no_header" and "-no_message_id" control arguments Mail table addresses: The mail table is a system-wide database which provides a translation between an arbitrary character string and a mail system address. The mail table contains an entry for each person registered on the system using their Person_id (and alias) as the name of the entry in the mail table. Thus, the mail table allows a user to send mail to another user without having to know on which projects that user is registered. A mail table address is accessed via the "-user" address specifier. For more information, type: help mail_table.gi Mailing lists: The send_mail command now supports sending mail to a list of addresses contained in a segment or archive component. This form of address is called a mailing list and is accessed via the "-mailing_list" address specifier. The syntax of this specifier is: -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 detailed information on mailing lists, type: help mailing_lists.gi Forum addresses: The send_mail command can now deliver a message to a forum meeting. This facility is accessed via the new "-meeting" address specifier. The format of this specifier is: -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. Changes to the qedx request: Several important, incompatible changes have been made to send_mail's qedx request. A detailed description of these changes can be obtained within send_mail by typing: help qedx.changes In brief, the following changes have been made -- The write (w) request must now be used to reflect any changes made to the message back to send_mail; the quit (q) request no longer does an automatic update. If the quit request is issued and the message has been modified since it was last written, qedx will now query for permission to exit. If permission is given, any changes made since the last write will be lost. The new quit-force (qf) request may be used to abort unwanted editing of the message without being queried. The read (r) and write (w) requests still accept pathnames and may be used to insert a segment into the message or make a copy in a segment for later use, respectively. However, when used with a pathname, these requests will no longer change the default pathname for buffer 0 (the message). Using either read or write without a pathname will always refer to send_mail's copy of the message. The request line 1,$dr will only restore the original message text to the buffer if the write request has not yet been used. If given after a write request, this request line will restore the message text as saved by the last write request in the buffer. Support of the "blind" recipients list: The send_mail subsystem now provides complete support of the "blind" recipients list through the addition of the new "-bcc" control argument for the send_mail command and remove requests and the addition of the bcc request. When "blind" recipients are specified for a message, they are listed in the bcc field of the message header. When the message is transmitted, this field is not included in the copy of the message sent to the primary and secondary recipients; it is, however, included in the copy of the message sent to the actual "blind" recipients. In addition, the "-log" and "-save" addresses will now be included as "blind" recipients of the message rather than as secondary recipients. Improved address representations: In order to distinguish between the various mailboxes owned by a user (ie: the default mailbox, the logbox, and saveboxes), the send_mail command now uses three different printed representations for these addresses when asked to display or edit the message being prepared for transmission. These formats are: Person_id.Project_id identifies a user's default mailbox -- >udd>Project_id>Person_id>Person_id.mbx {logbox} identifies the user's logbox -- >udd>Project_id>Person_id>Person_id.sv.mbx {save path} identifies one of the user's saveboxes. Path is the absolute pathname of the savebox without the "sv.mbx" suffix. When the message is finally transmitted, however, all of the above printed representations will be replaced by the Person_id.Project format. The use of the above three formats ensures that the user will be able to distinguish between his various mailboxes in case he decides to change the mailbox to which he will send a copy of the outbound message. The use of these new formats allows the "-header" control argument of the qedx and apply requests to finally function properly in relation to these three type of address. In prior releases, all three types of address used the same printed representation and, as a result, send_mail would always convert the editted text back into the address of the user's default mailbox. Changes to the In-Reply-To field: The In-Reply-To field is no longer a simple text field. Instead, it is a rigidly defined data structure which contains references to the messages for which this message is a reply. As a result, several changes have been made to send_mail's handling of this field: The read_mail reply request will now initialize the In-Reply-To field with the appropriate set of references before invoking send_mail. When editing the message with the "-header" option to the qedx and apply requests, send_mail will not include the In-Reply-To field in the text of the header. Any attempt to incorporate an In-Reply-To field into the header during editing will be reported as an error upon exit from the editor. The qedx and apply requests will save the content of the In-Reply-To field before editing commences and restore it upon completion of the request. The in_reply_to request has been changed to no longer accept a text string as the new value for the In-Reply-To field. Instead, in_reply_to now accepts read_mail message specifiers and constructs an In-Reply-To field that contains references to the specified messages. Consequently, the in_reply_to request can now only be used in a send_mail invocation that was created by the read_mail reply request. For example, the following request will change the In-Reply-To field of the message to contain references to all messages in the mailbox being examined by read_mail which were created on 1 July 1983 in_reply_to [list_original -date 7/1/83] Stricter command line address parsing: By default, the send_mail command now returns to its caller immediately upon detecting an invalid address on the command line. An invalid address is either a sequence of control arguments which is not valid or a valid sequence which identifies an non-existant address. For example, the command line send_mail -mailbox -log will fail because there is no pathname following the "-mailbox" control argument. Additionally, the command line send_mail foo.bar would fail if mailbox >udd>bar>foo>foo.mbx did not exist. The "-abort" and "-no_abort" send_mail command line control arguments have been redefined to provide control of send_mail's treatment of invalid command line addresses. In prior releases, these control arguments were used to provide the default state for the send request's treatment of invalid addresses. As of this release, the command line control arguments no longer affect the behavior of the send request. The new definitions of the command line arguments follow: -abort specifies that send_mail should print an error message and return to its caller immediately upon detecting an invalid address. An invalid address either is a sequence of arguments which can not be converted into an address by send_mail (eg: missing arguments, bad pathname syntax) or is a non-existant address (eg: a non-existant mailbox, a foreign address on a host that is not reachable from the local system) (Default) -no_abort specifies that send_mail should print an error message for any invalid addresses that it encounters on the command line but that it should then proceed to prompt for a subject and message text. After the message text is entered, send_mail will enter its request loop to allow the user to correct the lists of recipients before attempting to send the message. Pending removal of the "-no_header" and "-no_message_id" control arguments: As of this release, the "-no_header" and "-no_message_id" control arguments of the send_mail command and send request are being declared obsolete. In this release, these control arguments will be still be accepted but will have no effect on the message that is transmitted as the mail system primitives enforce strict rules on the content of message headers. These control arguments and their opposites ("-header" and "-message_id") will be removed entirely in a future release. 10/06/82 List of enhancements in MR10.1: (1) new defaults and times for filling messages, (2) improved interaction of the -input_file and -request_loop control arguments, (3) improved interaction with read_mail's reply request, (4) request line abbreviation processing, (5) new standard requests, (6) improved self-documentation facilities, and (7) the addition of new request name abbreviations. Changes to message filling: Several changes are made to send_mail's filling of the message. These changes, while incompatible, present a more user-friendly interface and also provide compatibility with filling of transactions in forum. Changes in the default state of filling: The default for terminal input is now "-fill"; the default for file input is left unchanged as "-no_fill". The majority of messages typed by a user on the terminal are simple text. Such messages should be filled automatically for the user so that he does not need to worry about entering overlength lines. When inputting the message from a file, however, the user has probably already preformatted the message and would be upset if it were automatically filled. New times for filling: If enabled, filling now takes place after exiting qedx during initial input rather than before entering qedx. The prior behavior often made qedx requests fail as the message in the editor's buffer was formatted differently from what was on the user's screen. In addition, filling, if enabled, now occurs automatically after execution of any qedx or apply request. Two new control arguments -- -fill (-fi) and -no_fill (-nfi) -- are added to both requests to allow the user to control the automatic filling. Of course, filling, if enabled, still occurs after the user types "." to terminal initial input of the message without entering qedx. Interaction of -input_file and -request_loop: Use of the -input_file control argument now implies the -request_loop control argument. In this way, the user is given the opportunity to fill or otherwise edit the message before sending it. This change also provides compatibility between send_mail and forum in this area. Interaction with read_mail's reply request: Six new requests are added to send_mail which are only available within a send_mail that was created by the read_mail reply request. These new requests, listed below, allow the user to examine or manipulate the original message(s) which he is answering. Additionally, these requests accept read_mail message specifiers to allow the user to possibly exmaine other messages which might be relevant to the reply he is composing. List of requests which interact with reply: print_original, pro prints the messages being answered. print_original_header, prohe prints the message headers of the messages being answered. list_original, lso displays a summary of the messages being answered or returns their message numbers when used as an active request. log_original, logo places a copy of the messages being answered into the user's logbox. logbox. save_original, svo places a copy of the messages being answered into a save mailbox. write_original, wo writes the ASCII representation of the messages being answered to the end of a segment. Request line abbreviation processing: The user can now request that abbreviations be expanded on send_mail request lines. Through the use of three new control arguments -- -abbrev (-ab), -no_abbrev (-nab), and -profile path -- the user can specify whether abbreviation processing is enabled or disabled when entering the subsystem and can also specify the profile to use to look up abbreviation definitions. If expansion is enabled and a profile is not specified, the same profile used at Multics command level will be used within send_mail. A new request, abbrev (ab), is also provided which allows the user to enable or disable abbreviation processing and to change profiles once within send_mail. The use of separate profiles for subsystems and Multics command level is encouraged to avoid problems where command level abbreviations perform unexpectedly within a subsystem and vice-versa. For example, the user may define an "sdm" abbreviation to enter send_mail with expansion enabled using the profile "mail_system.profile" in the home directory as follows: .ab sdm do "send_mail -abbrev -profile [hd]>mail_system &rf1" New standard requests: The following new requests, supplied as part of the subsystem utilities, are now available in send_mail: exec_com, ec executes a segment containing send_mail requests. The full capabilities of the Multics exec_com processors (versions one and two) are available. The send_mail subsystem uses the suffix "sdmec" for its exec_com segments to avoid confusion with exec_com's that are intended for execution at Multics command level. Additionally, send_mail will search for the exec_com using the "mail_system" search list. The default content of this search list is: -working_dir >udd>[user project]>[user name]>[user name].mlsys do if answer are identical to the do, if, and answer commands available at Multics command level except that they execute send_mail request lines rather than Multics command lines. These requests are invaluable in the creation of abbreviations within send_mail. ready, rdy prints a Multics ready message. ready_on, rdn ready_off, rdf control whether a ready message will be printed after the execution of each request line. By default, send_mail does not print ready messages. subsystem_name subsystem_version return the name and version of the current subsystem, respectively. These requsts are invaluable in abbreviations which are shared by multiple subsystem or which must know whether certain features of a subsystem are present. For example, a "print" abbreviation may be defined as follows which specifies "-header" only when in send_mail: .ab print do """print"" [if [e equal [subsystem_name] send_mail] -then -header] &rf1" Improved self-documentation facilities: The "?" request now prints a multi-columnar list of the requests available within send_mail. The list_requests (lr) request is added to send_mail to provide the functionality of the old "?" request. It produces a list of valid requests with a brief summary of each request. Additionally, the list_requests request accepts request name topics and lists those request which match those topics. For example, the request line list_requests list will print the brief summary of the list_help, list_original, and list_requests requests. The help request is extended to accept most control arguments accepted by the Multics help command. In particular, the "-brief" control argument can be used to produce a summary of any send_mail request which includes the request's syntax line, arguments, and control arguments. In addition, the help request is changed to explain how to obtain additional online information when it is invoked with no arguments. New request name abbreviations: The following new abbreviations are now accepted for the listed requests. In addition, abbreviations available in prior releases (shown in parentheses) are still accepted. print (pr): p append: app preface: prf ----------------------------------------------------------- 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