1 10/10/83 Enhancements to the send_mail command
2
3 This info segment briefly describes the enhancements made to the
4 send_mail command in various system releases.
5
6
7 10/10/83 List of enhancements in MR10.2:
8 1 mail table addresses,
9 2 mailing lists,
10 3 forum addresses,
11 4 changes to the qedx request,
12 5 support of the "blind" recipients list,
13 6 improved address representations
14 7 changes to the In-Reply-To field,
15 8 stricter command line address parsing, and
16 9 pending removal of the "-no_header" and "-no_message_id" control
17 arguments
18
19
20 Mail table addresses:
21 The mail table is a system-wide database which provides a translation
22 between an arbitrary character string and a mail system address. The
23 mail table contains an entry for each person registered on the system
24 using their Person_id and alias as the name of the entry in the mail
25 table. Thus, the mail table allows a user to send mail to another user
26 without having to know on which projects that user is registered.
27
28 A mail table address is accessed via the "-user" address specifier.
29 For more information, type:
30 help mail_table.gi
31
32
33 Mailing lists:
34 The send_mail command now supports sending mail to a list of addresses
35 contained in a segment or archive component. This form of address is
36 called a mailing list and is accessed via the "-mailing_list" address
37 specifier. The syntax of this specifier is:
38
39 -mailing_list path, -mls path
40 specifies the pathname of a mailing list. The suffix "mls" is added
41 if necessary. The archive component pathname convention is
42 accepted. For more detailed information on mailing lists, type:
43 help mailing_lists.gi
44
45
46 Forum addresses:
47 The send_mail command can now deliver a message to a forum meeting.
48 This facility is accessed via the new "-meeting" address specifier.
49 The format of this specifier is:
50
51 -meeting path, -mtg path
52 specifies the pathname of a forum meeting. The suffix "control" is
53 added if necessary. If the pathname given is just an entryname ie:
54 no "<" or ">" characters appear in the pathname, the "forum" search
55 path is used to find the meeting.
56
57
58 Changes to the qedx request:
59 Several important, incompatible changes have been made to send_mail's
60 qedx request. A detailed description of these changes can be obtained
61 within send_mail by typing:
62 help qedx.changes
63
64 In brief, the following changes have been made --
65
66 The write w request must now be used to reflect any changes
67 made to the message back to send_mail; the quit q request no longer
68 does an automatic update.
69
70
71 If the quit request is issued and the message has been modified since
72 it was last written, qedx will now query for permission to exit. If
73 permission is given, any changes made since the last write will be
74 lost. The new quit-force qf request may be used to abort unwanted
75 editing of the message without being queried.
76
77 The read r and write w requests still accept pathnames and may be
78 used to insert a segment into the message or make a copy in a segment
79 for later use, respectively. However, when used with a pathname, these
80 requests will no longer change the default pathname for buffer 0 the
81 message. Using either read or write without a pathname will always
82 refer to send_mail's copy of the message.
83
84
85 The request line
86 1,$dr
87 will only restore the original message text to the buffer if the write
88 request has not yet been used. If given after a write request, this
89 request line will restore the message text as saved by the last write
90 request in the buffer.
91
92
93 Support of the "blind" recipients list:
94 The send_mail subsystem now provides complete support of the "blind"
95 recipients list through the addition of the new "-bcc" control argument
96 for the send_mail command and remove requests and the addition of the
97 bcc request.
98
99 When "blind" recipients are specified for a message, they are listed in
100 the bcc field of the message header. When the message is transmitted,
101 this field is not included in the copy of the message sent to the
102 primary and secondary recipients; it is, however, included in the copy
103 of the message sent to the actual "blind" recipients.
104
105 In addition, the "-log" and "-save" addresses will now be included as
106 "blind" recipients of the message rather than as secondary recipients.
107
108
109 Improved address representations:
110 In order to distinguish between the various mailboxes owned by a user
111 ie: the default mailbox the logbox and saveboxes, the send_mail
112 command now uses three different printed representations for these
113 addresses when asked to display or edit the message being prepared for
114 transmission. These formats are:
115
116 Person_id.Project_id
117 identifies a user's default mailbox --
118 >udd>Project_id>Person_id>Person_id.mbx
119
120 logbox
121 identifies the user's logbox --
122 >udd>Project_id>Person_id>Person_id.sv.mbx
123
124 save path
125 identifies one of the user's saveboxes. Path is the absolute
126 pathname of the savebox without the "sv.mbx" suffix.
127
128
129 When the message is finally transmitted, however, all of the above
130 printed representations will be replaced by the Person_id.Project
131 format. The use of the above three formats ensures that the user will
132 be able to distinguish between his various mailboxes in case he decides
133 to change the mailbox to which he will send a copy of the outbound
134 message.
135
136 The use of these new formats allows the "-header" control argument of
137 the qedx and apply requests to finally function properly in relation to
138 these three type of address. In prior releases, all three types of
139 address used the same printed representation and, as a result,
140 send_mail would always convert the editted text back into the address
141 of the user's default mailbox.
142
143
144 Changes to the In-Reply-To field:
145 The In-Reply-To field is no longer a simple text field. Instead, it is
146 a rigidly defined data structure which contains references to the
147 messages for which this message is a reply. As a result, several
148 changes have been made to send_mail's handling of this field:
149
150 The read_mail reply request will now initialize the In-Reply-To field
151 with the appropriate set of references before invoking send_mail.
152
153 When editing the message with the "-header" option to the qedx and
154 apply requests, send_mail will not include the In-Reply-To field in the
155 text of the header. Any attempt to incorporate an In-Reply-To field
156 into the header during editing will be reported as an error upon exit
157 from the editor. The qedx and apply requests will save the content of
158 the In-Reply-To field before editing commences and restore it upon
159 completion of the request.
160
161
162 The in_reply_to request has been changed to no longer accept a text
163 string as the new value for the In-Reply-To field. Instead,
164 in_reply_to now accepts read_mail message specifiers and constructs an
165 In-Reply-To field that contains references to the specified messages.
166 Consequently, the in_reply_to request can now only be used in a
167 send_mail invocation that was created by the read_mail reply request.
168
169 For example, the following request will change the In-Reply-To field of
170 the message to contain references to all messages in the mailbox being
171 examined by read_mail which were created on 1 July 1983
172
173 in_reply_to list_original -date 7/1/83
174
175
176 Stricter command line address parsing:
177 By default, the send_mail command now returns to its caller immediately
178 upon detecting an invalid address on the command line. An invalid
179 address is either a sequence of control arguments which is not valid or
180 a valid sequence which identifies an non-existant address. For
181 example, the command line
182
183 send_mail -mailbox -log
184
185 will fail because there is no pathname following the "-mailbox" control
186 argument. Additionally, the command line
187
188 send_mail foo.bar
189
190 would fail if mailbox >udd>bar>foo>foo.mbx did not exist.
191
192
193 The "-abort" and "-no_abort" send_mail command line control arguments
194 have been redefined to provide control of send_mail's treatment of
195 invalid command line addresses. In prior releases, these control
196 arguments were used to provide the default state for the send request's
197 treatment of invalid addresses. As of this release, the command line
198 control arguments no longer affect the behavior of the send request.
199 The new definitions of the command line arguments follow:
200
201
202 -abort
203 specifies that send_mail should print an error message and return to
204 its caller immediately upon detecting an invalid address. An
205 invalid address either is a sequence of arguments which can not be
206 converted into an address by send_mail eg: missing arguments bad
207 pathname syntax or is a non-existant address eg: a non-existant
208 mailbox a foreign address on a host that is not reachable from the
209 local system Default
210 -no_abort
211 specifies that send_mail should print an error message for any
212 invalid addresses that it encounters on the command line but that it
213 should then proceed to prompt for a subject and message text. After
214 the message text is entered, send_mail will enter its request loop
215 to allow the user to correct the lists of recipients before
216 attempting to send the message.
217
218
219 Pending removal of the "-no_header" and "-no_message_id" control arguments:
220 As of this release, the "-no_header" and "-no_message_id" control
221 arguments of the send_mail command and send request are being declared
222 obsolete. In this release, these control arguments will be still be
223 accepted but will have no effect on the message that is transmitted as
224 the mail system primitives enforce strict rules on the content of
225 message headers. These control arguments and their opposites
226 "-header" and "-message_id" will be removed entirely in a future
227 release.
228
229
230 10/06/82 List of enhancements in MR10.1:
231 1 new defaults and times for filling messages,
232 2 improved interaction of the -input_file and -request_loop
233 control arguments,
234 3 improved interaction with read_mail's reply request,
235 4 request line abbreviation processing,
236 5 new standard requests,
237 6 improved self-documentation facilities, and
238 7 the addition of new request name abbreviations.
239
240
241 Changes to message filling:
242 Several changes are made to send_mail's filling of the message. These
243 changes, while incompatible, present a more user-friendly interface and
244 also provide compatibility with filling of transactions in forum.
245
246
247 Changes in the default state of filling:
248 The default for terminal input is now "-fill"; the default for file
249 input is left unchanged as "-no_fill". The majority of messages typed
250 by a user on the terminal are simple text. Such messages should be
251 filled automatically for the user so that he does not need to worry
252 about entering overlength lines. When inputting the message from a
253 file, however, the user has probably already preformatted the message
254 and would be upset if it were automatically filled.
255
256
257 New times for filling:
258 If enabled, filling now takes place after exiting qedx during initial
259 input rather than before entering qedx. The prior behavior often made
260 qedx requests fail as the message in the editor's buffer was formatted
261 differently from what was on the user's screen.
262
263 In addition, filling, if enabled, now occurs automatically after
264 execution of any qedx or apply request. Two new control arguments --
265 -fill -fi and -no_fill -nfi -- are added to both requests to allow
266 the user to control the automatic filling.
267
268 Of course, filling, if enabled, still occurs after the user types "."
269 to terminal initial input of the message without entering qedx.
270
271
272 Interaction of -input_file and -request_loop:
273 Use of the -input_file control argument now implies the -request_loop
274 control argument. In this way, the user is given the opportunity to
275 fill or otherwise edit the message before sending it. This change also
276 provides compatibility between send_mail and forum in this area.
277
278
279 Interaction with read_mail's reply request:
280 Six new requests are added to send_mail which are only available within
281 a send_mail that was created by the read_mail reply request. These new
282 requests, listed below, allow the user to examine or manipulate the
283 original messages which he is answering. Additionally, these
284 requests accept read_mail message specifiers to allow the user to
285 possibly exmaine other messages which might be relevant to the reply he
286 is composing.
287
288
289 List of requests which interact with reply:
290 print_original, pro
291 prints the messages being answered.
292 print_original_header, prohe
293 prints the message headers of the messages being answered.
294 list_original, lso
295 displays a summary of the messages being answered or returns their
296 message numbers when used as an active request.
297 log_original, logo
298 places a copy of the messages being answered into the user's logbox.
299 logbox.
300 save_original, svo
301 places a copy of the messages being answered into a save mailbox.
302 write_original, wo
303 writes the ASCII representation of the messages being answered to
304 the end of a segment.
305
306
307 Request line abbreviation processing:
308 The user can now request that abbreviations be expanded on send_mail
309 request lines. Through the use of three new control arguments --
310 -abbrev -ab, -no_abbrev -nab, and -profile path -- the user can
311 specify whether abbreviation processing is enabled or disabled when
312 entering the subsystem and can also specify the profile to use to look
313 up abbreviation definitions. If expansion is enabled and a profile is
314 not specified, the same profile used at Multics command level will be
315 used within send_mail.
316
317 A new request, abbrev ab, is also provided which allows the user to
318 enable or disable abbreviation processing and to change profiles once
319 within send_mail.
320
321
322 The use of separate profiles for subsystems and Multics command level
323 is encouraged to avoid problems where command level abbreviations
324 perform unexpectedly within a subsystem and vice-versa.
325
326 For example, the user may define an "sdm" abbreviation to enter
327 send_mail with expansion enabled using the profile
328 "mail_system.profile" in the home directory as follows:
329
330 .ab sdm do "send_mail -abbrev -profile hd>mail_system &rf1"
331
332
333 New standard requests:
334 The following new requests, supplied as part of the subsystem
335 utilities, are now available in send_mail:
336
337 exec_com, ec
338 executes a segment containing send_mail requests. The full
339 capabilities of the Multics exec_com processors versions one and
340 two are available. The send_mail subsystem uses the suffix "sdmec"
341 for its exec_com segments to avoid confusion with exec_com's that
342 are intended for execution at Multics command level. Additionally,
343 send_mail will search for the exec_com using the "mail_system"
344 search list. The default content of this search list is:
345 -working_dir
346 >udd>user project>user name>user name.mlsys
347
348
349 do
350 if
351 answer
352 are identical to the do, if, and answer commands available at
353 Multics command level except that they execute send_mail request
354 lines rather than Multics command lines. These requests are
355 invaluable in the creation of abbreviations within send_mail.
356
357 ready, rdy
358 prints a Multics ready message.
359
360 ready_on, rdn
361 ready_off, rdf
362 control whether a ready message will be printed after the execution
363 of each request line. By default, send_mail does not print ready
364 messages.
365
366
367 subsystem_name
368 subsystem_version
369 return the name and version of the current subsystem, respectively.
370 These requsts are invaluable in abbreviations which are shared by
371 multiple subsystem or which must know whether certain features of a
372 subsystem are present. For example, a "print" abbreviation may be
373 defined as follows which specifies "-header" only when in send_mail:
374 .ab print do """print"" if e equal subsystem_name
375 send_mail -then -header &rf1"
376
377
378 Improved self-documentation facilities:
379 The "?" request now prints a multi-columnar list of the requests
380 available within send_mail.
381
382 The list_requests lr request is added to send_mail to provide the
383 functionality of the old "?" request. It produces a list of valid
384 requests with a brief summary of each request. Additionally, the
385 list_requests request accepts request name topics and lists those
386 request which match those topics. For example, the request line
387
388 list_requests list
389
390 will print the brief summary of the list_help, list_original, and
391 list_requests requests.
392
393
394 The help request is extended to accept most control arguments accepted
395 by the Multics help command. In particular, the "-brief" control
396 argument can be used to produce a summary of any send_mail request
397 which includes the request's syntax line, arguments, and control
398 arguments. In addition, the help request is changed to explain how to
399 obtain additional online information when it is invoked with no
400 arguments.
401
402
403 New request name abbreviations:
404 The following new abbreviations are now accepted for the listed
405 requests. In addition, abbreviations available in prior releases
406 shown in parentheses are still accepted.
407
408 print pr: p
409 append: app
410 preface: prf