5 \section{Introduction} % mtr
6 \tagfigure{0}{\MTS/ model}{mtsmodel}
8 The UCI version of the Rand Message Handling System, \MH/,
10 In the interests of brevity,
11 we dispense with the usual definition of terms,
12 refer the reader to Figure~\mtsmodel,
13 and simply note that \MH/ is not responsible for delivering mail.
15 it interacts with a {\it message transport system}, \MTS/,
17 it sends mail by placing it through a {\it posting slot} to the \MTS/,
18 and it receives mail by retrieving it through a {\it delivery slot} from the
20 Besides these two \MTS/-specific activities,
21 the tasks which \MH/ addresses are:
22 the composition of messages
23 (which may, or may not, be in reference to previously sent messages),
24 the reading of messages,
25 and the organization of messages.
27 \MH/ was originally developed by the Rand Corporation,
28 and initially was proprietary software.
29 The Department of Information and Computer Science at
30 University of California, Irvine,
31 shortly after joining the Computer Science Network (CSnet),
32 acquired a copy of \MH/,
33 and began additional development of the software.
35 the Rand Corporation has declared \MH/ to be in the public domain,
36 and the UCI version of \MH/ has passed through four major releases.
38 Much credit must be given to the initial designers and implementors of \MH/:
39 Bruce Borden, Stockton Gaines, and Norman Shapiro.
40 Although \MH/ has suffered significant development at UCI
41 since Rand's initial release,
42 the fundamental concepts of \MH/'s environs have remained nearly unchanged.
44 the current maintainers of \MH/ gratefully acknowledge the comments of the
45 many sites which have run various releases of \MH/ in the past.
47 \MH/ runs on different versions of the \unix/ operating system
48 (such as 4.2\bsd/~\unix/ and various flavors of v7~\unix/).
50 \MH/ supports four different \MTS/ interfaces:
51 \SendMail/\cite{EAllm83},
52 the standard mailer for 4.2\bsd/ systems;
53 \MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84},
54 the Multi-Channel Memo Distribution Facility developed by the University of
56 which forms the software-backbone for CSnet\cite{DCome83} mail relays service;
58 the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
60 a stand-alone delivery system.
62 The organization of this paper is straight-forward,
63 given space considerations.
65 the \MH/ philosophy of mail handling is presented,
66 along with a description of the environment which the \MH/ user is given to
69 certain advanced features of \MH/ are discussed in more detail.
71 the notion of a {\it draft folder} is introduced,
72 which permits the handling of multiple drafts during composition.
74 message selection facilities are described.
76 two different aspects of \MH/'s power as a software system are discussed:
77 record handling, in which \MH/ facilitates record processing systems;
79 how \MH/ can be employed in a distributed mail environment.
80 This latter section raises questions as to the location of the posting and
82 along with authentication mechanisms.
84 we conclude by discussing areas of future development which \MH/ may endure.
86 Although familiarity with \MH/ is not assumed on the part of the reader,
87 some knowledge of the \unix/ operating system is useful.
88 Appendix~A gives a short synopsis of the \MH/ commands.
90 \section{The \MH/ Philosophy} % mtr
91 Although \MH/ has many traits which tend to differ it from other user agents,
92 the design aspect which fundamentally influences the interface between \MH/
93 and the user is that it is composed of many small
94 programs instead of one very large one.
95 This architecture gives \MH/ much of its strength,
96 since intermediate and advanced users are able to take advantage of this
99 The key to this flexibility is that the \unix/ shell
100 (usually the {\it C} shell or the {\it Bourne} shell),
101 is the user's interface to \MH/.
102 This means that when handling mail,
103 the entire power of the shell is at the user's disposal in addition to the
104 facilities which \MH/ provides.
106 the user may intersperse mail handling commands with other commands in an
108 making use of command handling capabilities that the user's shell provides.
111 rather than storing messages in a complicated data structure
112 within a monolithic file,
113 in \MH/, each message is a \unix/ file,
114 and each folder (an object which holds groups of messages)
115 is a \unix/ directory.
117 the directory and file structure of \unix/ is used directly.
119 any \unix/ file-handling command can be applied to any message.
122 this may not make much sense or may not seem important.
123 From three years of observation, we have seen that
124 as users of \MH/ have become more experienced
125 they have found this capability to be quite attractive.
127 this approach is often quite pleasing to system implementors,
128 because it minimizes the amount of coding to be performed
130 given a modular design,
131 changes to the software system can be maintained easily.
132 Our empirical findings confirm our theoretical expectations regarding the
135 Having described how \MH/ fits into the \unix/ environment,
136 we now discuss the mail handling environment which is available to the \MH/
139 \subsection{The \MH/ Environs} % jns
140 \MH/ provides a complementary environment to the user's shell.
141 While the shell maintains a context related to the user's focus in the file
142 system (a {\it current working directory\/}),
143 mail handling is performed in a separate mail folder context.
144 Operations on mail can therefore be
145 performed entirely without regard to the current file system context,
146 although \MH/ does not prevent the user from making use of that context.
147 Certain mail handling functions do make use of information
148 maintained by the shell.
149 For instance, by setting certain shell parameters,
150 called {\it environment variables},
151 alternate mail handling contexts can be selected.
153 \MH/ conventions often have direct analogs to shell or file system
155 The shell has a current working directory; \MH/ has a current mail folder.
156 When the user begins a session on the system,
157 the user's ``home directory'' is the base context;
158 \MH/'s default base area, the \Mail/ directory,
159 is found under the user's home directory.
160 The user's default shell parameters are set upon beginning a new
161 session from a startup profile
162 (called \file{.profile} for \pgm{sh} users
163 or \file{.cshrc} for \pgm{csh} users);
164 the default parameters for \MH/ commands are taken from a file called
165 \profile/ in the user's home directory.
166 The shell has an {\it environment\/};
167 \MH/ has a \context/ file.
168 Each of the user's directories has files;
169 each of the user's \MH/ folders has messages.
171 These parallels have a basis not only in \MH/'s high level mail
173 but also in the way low level shell and file
174 system conventions have been abstracted to implement \MH/ conventions.
175 Directories are folders; files are messages.
176 The \Mail/ directory forms the root of a virtual file subsystem within
177 which the user operates on mail without disturbing files outside this
178 mail handling domain.
180 \tagfigure{1}{\MH/ File Subsystem\\(directories are shaded)}{MHfiles}
181 \tagdiagram{2}{Elaborated \MH/ Profile}{elab}
182 \subsection{The \MH/ Profile}
183 The \profile/ contains plaintext that describes the user's default mail
185 An example of an elaborated profile is shown in Figure~\elab.
187 Each line in the profile consists of an \MH/ parameter name terminated
188 with a colon (`:') followed by parameter values.
190 ``global'' parameters are listed in the first few lines,
191 with program-specific parameters following.
192 Each \MH/ program examines global parameters as well as any parameter
193 with the same name by which the program was invoked.
195 the \pgm{comp} program, which is used to compose new messages to be sent,
196 examines the entries:
198 {\advance\leftskip by2\parindent
200 The path parameter specifies the name of the \MH/ root directory.
201 This is normally named \Mail/.
204 The editor parameter specifies which text editor is first invoked to create
205 the header information and body of a message draft.
206 In most cases, this editor is the \MH/ default editor, \pgm{prompter}.
209 This parameter specifies a folder within which new message drafts
211 The draft folder mechanism is an advanced feature of \MH/ that is
212 given separate treatment in a later segment of this paper.
215 The program-specific parameter examined by \pgm{comp} lists
216 user-default options.
221 Other programs invoked by \pgm{comp}
222 (e.g. \pgm{prompter} and \pgm{send\/}) would examine their own profile
224 \MH/ programs have reasonable compiled-in defaults and also permit options to
225 be specified on the shell command line with which the programs are invoked.
226 The order of override precedence is: command line options first,
227 \profile/ options second, and compiled-in defaults last.
229 Each program option is prefixed by a dash (`-') following the \unix/
231 Unlike most \unix/-style options,
232 however, the options are words rather than single letters.
233 An option may be abbreviated to an unambiguous prefix.
234 Each \MH/ program has a \switch{help} option that
235 displays a brief summary of the program's available options.
237 \subsection{Folders and Messages}
238 In a typical paper-oriented office,
239 new correspondence arrives and is stacked in an ``in box'',
240 while outgoing correspondence is placed in an ``out box''.
241 Processed material is stored in
242 appropriately labelled folders and filed away for future reference.
243 This state of affairs is modelled in \MH/ with {\it folders}
245 which are simply text files (one message per file) stored
246 under the folder directories.
247 Most of the user's folders are kept under the \Mail/ directory.
249 A folder is given an alphanumeric name permissible within the \unix/ file
251 and each message stored therein is given a numeric name in the range 1..1999.
252 The upper bound on message numbers was
253 selected for efficient access to an internal representation,
254 an array of bits (a ``bit set''),
255 with each bit indicating the presence or
256 absence of a message with a number in the range 1..1999.
257 This internal representation also restricts the order of multiple
258 message reference to an ascending numerical sequence.
259 Other representations have been studied
260 (e.g., an unsorted sparse array of integers),
261 but have been rejected for reasons of efficiency.
262 Folders may contain subfolders,
263 corresponding to \unix/ tree-structured directories.
264 For the sake of completeness,
265 it might be said that ``sub-messages'' exist insofar as message ``digests'',
266 which nest messages inside other messages,
267 are supported by certain advanced \MH/ functions.
269 The current working folder is the default folder selected for almost
271 To select explicitly a folder for mail handling
272 commands entails specifying the name of the folder, prefixing the name
273 with a plus-symbol (`+').
274 An example is: \example refile\ 1\ 2\ 3\ +chron/yr.1984\endexample
275 This command re-files the selected messages
276 (\file{1}, \file{2}, and \file{3} here)
277 from the current working folder to a subfolder under the
278 folder \file{chron} named \file{yr.1984}.
279 To see the folder/subfolder relationship, refer to Figure~\MHfiles.
281 The plus-symbol notation is specific to those folders immediately
282 subordinate to the \Mail/ directory.
283 This is analogous to ``absolute pathnames'' in \unix/---those
284 files whose positions in the file system
285 hierarchy are given starting with the system root,
286 names prefixed with the slash character (`/').
287 To specify folders subordinate to the current working folder,
288 an at-sign (`@') is substituted for (`+').
289 It is permitted to use \unix/ dot notation to specify parent folders.
290 Referring to Figure~\MHfiles,
291 if the current working folder were \eg{+chron/yr.1985},
292 then the command \example folder\ @../yr.1984\endexample
294 selects the subfolder \file{yr.1984} in the parent directory
295 \file{chron}, as the new current working folder.
296 While the current working folder is normally the default, it may be
297 specified explicitly as \eg{@.}.
299 \subsection{The Context File}
300 The \profile/ contains static information about the user's
302 A \context/ file, contained in the \Mail/ directory,
303 contains the current mail handling environment information,
304 which changes as different folders, messages, and named message lists
305 (called {\it message sequences\/}) are selected, created, and updated.
306 This information is retained between invocations of \MH/ commands,
307 and is preserved across system sessions.
309 \tagdiagram{3}{Elaborated Reply Template}{replcomps}
310 \subsection{Templates}
311 The message draft composition functions
312 (\pgm{comp}, \pgm{repl}, \pgm{forw}, and \pgm{dist\/})
313 use certain default header formats,
314 which may be changed by the user through the use of message templates.
315 The exact format of a template may vary among commands.
316 An example of an elaborated template for the reply command \pgm{repl} is
317 shown in Figure~\replcomps.
319 This template specifies how the automatically-generated header for a
320 draft message in reply to a source message is to be formatted.
321 The syntax is capable of directing output of header lines based on the
322 presence or absence of other header lines in the source message.
324 Other kinds of templates are used to specify the display formats of
325 messages, or to specify the way that messages are to be included in
326 other messages. This is similar to the functionality provided by BBN
328 another powerful mail handling system for \tops20/ based systems.
330 \subsection{Explaining All This to New Users}
331 There do exist people who do not like \MH/.%
332 \nfootnote{At UCI, these
333 people are reported to be weeded out at an early stage and quietly taken to the
334 Ministry of Love to be made {\it uncrimethinkful}.}
335 The emerging pattern of complaints from such people indicates that \MH/
336 accentuates their perceptions of the deficiencies of \unix/,
337 to wit, lack of interactivity and lack of easily found help facilities.
339 some feel that the proximity of the mail handling environment to the
340 operating system is a distraction, rather than an asset.
341 There have been some attempts to make \MH/ more accessible to users who prefer
342 menu-oriented or monolithic mail system interfaces.%
343 \nfootnote{For example,
344 \pgm{mhe} from Brian Reid of Stanford University
345 and \pgm{emh} from Marshall Rose
346 are instances of macro packages for James Gosling's \EMACS/ extensible editor,
347 while the \pgm{hm} program from Jim Guyton of the Rand Corporation is a
348 monolithic \MH/ interface.
350 none of these programs is documented in the literature.}
353 users new to \unix/ do not always acclimate to \MH/ easily.
354 The command set is undistinguishably mixed in with all other \unix/
355 utilities, and it is not easy, without aid of a manual,
356 to pick out the necessary commands.
357 \MH/ does not provide any ``hand-holding'' to guide
358 the user through a minimally useful command subset.
360 Another problem is that the initial default user profile is too often sparse,
361 containing only a \eg{Path:} parameter.
362 \MH/ commands will perform adequately without specific information
364 so new users often neglect optionally useful \MH/ capabilities,
365 eventually becoming frustrated with the limited default capabilities,
366 yet unable to determine without researching through the user's manual,
367 the necessary options that would solve their problems.
369 The currently available means for learning how to use \MH/ are:
371 {\advance\leftskip by 2\parindent
373 One-on-one tutoring by knowledgeable \MH/ users,
374 which has so far shown the best results with new users.
377 Consulting the {\it \MH/ Tutorial\/}\cite{MRose84b},
378 or the {\it \MH/ User's Manual\/}\cite{MRose85a}.
381 Using the \pgm{msh} (``\MH/ shell'') program as a training shell to read
383 The \pgm{msh} command is an interactive program that provides some help
384 messages and can list available \MH/ commands.
389 No on-line tutorial materials are presently distributed with the \mh5
390 system, although there are some plans in the works to provide a program
391 to help with setting up the user profile that would also provide
392 operational tips for \MH/ and \unix/.
394 It should be noted that these perceived defects of \MH/ do not affect its
395 utility any more than analogous problems with any operating system
396 will diminish its actual capabilities.
397 Users may quarrel with the means chosen for orchestrating \MH/,
398 but the fact remains that \MH/ is a very
399 useful set of mail handling tools that is flexible,
400 infinitely interoperable with other \unix/ text handling tools,
401 and yet simple enough for new users to grasp once they are given the
403 The fact that better tutorial materials and training do not exist only means
404 that some further work needs to be done in the area of user-education.
406 \section{A Few Advanced Features} % mtr
407 We now consider certain advanced features in \MH/.
408 These features have been chosen to demonstrate some useful capabilities
409 available to the \MH/ user.
410 It should be noted that many capabilities of \MH/,
411 such as shell scripts for extensibility,
413 the personal aliasing facility,
415 are not described here for lack of space.
417 \subsection{Draft Folders} % jns
418 The {\it draft folder} facility provides a method by which several
419 message drafts can be simultaneously composed and maintained until
421 The rationale for this is that partially composed message drafts,
422 perhaps elaborate sets of separate messages,
423 can be incrementally completed,
424 while a folder provides a consistent organization for drafts in progress.
425 This is comparable to similar situations in the ``paper world'' where
426 contracts, business correspondence, and other communications,
427 rather than being created serially with each posted in turn before composing
429 are usually left in various stages of
430 completion before they are eventually mailed.
432 The \eg{Draft-Folder:} parameter value in the \MH/ profile is used to
433 specify a default draft folder,
434 where each draft is given a number and an ``artificial'' date stamp.
435 Provided that the proper header fields have been completed,
436 a \pgm{scan} listing of the draft folder provides a summary of
437 each draft in progress:
438 to whom the message is to be sent,
440 the date of the draft's initial creation and optionally,
441 the current size of the draft in terms of characters.
442 Experienced users of \MH/ may often keep as many as five to ten unfinished
443 drafts in their draft folder.
444 ``Draft clutter'' can be remedied easily with the \pgm{rmm} command.
446 \subsection{Message Selection} % stef
447 \MH/ commands accept {\it message sequence} specifications to specify which
448 \arg{msg} or \arg{msgs} are to be operated upon.
449 Here are some examples:
450 \example scan\ 1\ 3\ 5\ 19\ 185\endexample
451 to get a scan listing of messages 1, 3, 5, 19 and 185.
452 \example scan\ pseq\endexample
453 to get a scan listing of whatever message sequence was given to the previous
454 MH command (in this case 1, 3, 5, 19, and 185).
455 \example show\ first\ last\endexample
456 to get a display of the first and last messages in the folder.
457 The \MH/ sequences named \eg{first} and \eg{last} are system defined pseudo
458 sequences which act like explicit sequences when given to MH commands.
459 Others are \eg{cur}, \eg{next}, \eg{prev},
460 and \eg{all} which respectively specify the ``current'' message,
461 the ``next'' after cur,
462 the ``previous'' message before cur,
463 or ``all'' messages in the current-folder.
464 The \pgm{scan} assumes \eg{all} while show assumes \eg{cur},
465 unless overridden on the command line.
466 Over-ride precedence is: command-line first,
468 and compiled-in default last.
470 Users can define additional sequences for similar use,
471 but must avoid using reserved names.
472 A few optional sequence names have been preempted by \MH/,
473 such as \eg{pseq} to mean the
474 ``sequence used by the previous MH command,''
475 and \eg{unseen} to mean the ``messages not yet seen by the user.''
476 Sometimes these preempted names can be changed by resetting them in the
478 but these facilities are beyond the scope of this discussion.
480 The mark command can be used to set the values for user-defined sequences:
481 \example mark\ 1\ 3\ 5\ -seq\ zzz\\
482 mark\ 4\ 5\ 9\ -seq\ zzz\ -nozero\endexample
483 will create a user-sequence named \eg{zzz} and put the sequence \eg{1 3 5}
485 The \pgm{mark} command assumes that any prior content in an
486 existing user-sequence should be ``zeroed'' before the new sequence value is
488 This can be prevented with a \switch{nozero} switch on the command line,
489 to add \eg{4 5 9} to the original \eg{1 3 5} to yield \eg{1 3 4 5 9}.
490 \example mark\ pseq\ zzz\ -seq\ zzznew\endexample
491 will create a new sequence named \eg{zzznew} and set its value to the combined
492 (inclusive or) of the existing user-sequences in \eg{pseq} and \eg{zzz} for
495 Another more powerful way to set the values of a user-sequence is with
496 the pick command, which provides full string search capabilities:
497 \example pick\ -from\ mrose\ -seq\ yyy\\
498 pick\ -from\ mrose\ -seq\ yyy\ -list\endexample
499 will search though all the \eg{From:} fields in the current folder for the
500 string \eg{mrose} and place the list of ``hits''
501 in the sequence named \eg{yyy}.
502 The \switch{list} switch will cause the resulting list to also be displayed on
504 If no \switch{seq\ name} switch is given,
505 pick will assume \switch{list}
506 and will simply display the resulting list of hits on the user's terminal.
508 This \switch{list} behavior of pick allows users to take advantage of the
509 \unix/ backquoting facility to embed searches in other \MH/ commands.
510 \example scan\ \bq{pick\ -from\ mrose}\endexample
511 will produce a scan listing of \switch{from\ mrose} hits because the
512 \unix/ shell will spawn a process to execute the
513 \eg{pick\ -from\ mrose} segment and return the \switch{list}
514 results as the message sequence to be scanned.
515 \example mark\ pseq\ -seq\ zzz\endexample
516 could then be used to capture the ``previous sequence'' in zzz for later use.
518 One last facility should be mentioned here.
519 It is also possible to negate a sequence to specify a new sequence.
520 The default negation string is \eg{not}.
521 \example scan\ notzzz\\
522 mark\ notzzz\ -seq\ zzznot\endexample
523 will give the user a scan listing of all the messages in the current folder
524 that are not included in the sequence \eg{zzz}.
525 The mark example will of course record the negation of zzz in zzznot.
526 It is a bad idea to use the string \eg{not} as the beginning of any
528 if \eg{not} is defined as the negation string.
529 (Users can choose a different negation string.)
531 From this discussion,
532 it should be clear that \MH/ provides a uniform set of ways to capture
533 and use sequences to augment the user's short- and long-term
534 memory and to manipulate lists of interesting messages.
535 User-sequences are normally stored as RFC822 labeled text lines in a file
537 in the folder with the messages referred to in the sequence.
538 If a user does not have write access to a folder,
539 then the \MH/ \pgm{mark} and \pgm{pick} commands will
540 create a ``private'' sequence in the user's \context/ file.
541 Switches are available to give the user control over
542 the choice of \switch{private} or \switch{public} sequence options.
544 Since user-sequences are stored as ordinary text lines in RFC822 labeled
546 there is no prohibition against someone writing programs to perform
547 any kind of useful manipulation on \MH/ sequences.
548 Boolean operators can be implemented,
549 or complex indexing structures could be developed to serve special purposes.
550 If a DBMS can utilize \unix/ pathnames or \MH/ \arg{+folder} and
552 then the full power of the DBMS might be applied.
553 The intention of \MH/ development teams has always been to leave open the
554 widest possible array of options for later extension.
555 The only restrictions should be the user's ingenuity,
556 programming prowess, and the available machine resources.
557 Unfortunately these resources always seem to be available in
560 \subsection{Distribution Lists} % mtr
561 \MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.%
562 \nfootnote{The UCI BBoards facility can run under either the \MMDF/ or
564 or in a more restricted form under stand-alone \MH/.}
565 This facility permits the efficient distribution of interest group messages
567 to a group of hosts under a single administration,
568 and to the ARPA Internet community.
570 Described simply, an interest group is composed of a number of subscribers
571 with a common interest.
572 These subscribers post mail to a single address, known as a
573 {\it distribution} address (e.g., {\tx MH-Workers@UCI}).
574 From this distribution address, a copy of the message is sent to each
576 Each group has a {\it moderator},
577 which is the person that runs the group.
578 This moderator can usually be reached at a special address,
579 known as a {\it request} address (e.g., {\tx MH-Workers-Request@UCI}).
580 Usually, the responsibilities of the moderator are quite simple,
581 since the mail system handles distribution to subscribers automatically.
582 In some interest groups,
583 instead of each separate message being distributed directly to subscribers,
584 a batch of (related) messages are put into a {\it digest} format by the
585 moderator and then sent to the subscribers.
586 Although this requires more work on the part of the moderator
587 and introduces delays,
588 such groups tend to be better organized.
590 Unfortunately, some problems arise with the scheme outlined above.
591 First, if two users on the same host subscribe to the same interest group,
592 two copies of the message will be delivered.
593 This is wasteful of both processor and disk resources at that host.
596 some groups carry a lot of traffic.
597 Although subscription to a group does indicate interest on the part of a
599 it is usually not interesting to get 50 messages or so delivered to
600 the user's private maildrop each day,
601 interspersed with {\it personal} mail,
602 that is likely to be of a much more important and timely nature.
604 Third, if a subscriber's address in a distribution list
605 becomes ``bad'' somehow and causes failed mail to be returned,
606 the originator of the message is normally notified.
607 It is not uncommon for a large list to have several bogus addresses.
608 This results in the originator being flooded with ``error messages'' from
609 mailers across the Internet stating that a given address on the list was
612 the originator usually does not care if the bogus addresses got a copy
613 of the message or not.
614 The originator is merely interested in posting a message
615 to the group at large.
617 the moderator of the group does care if there are bogus addresses on the list,
618 but ironically does not receive notification.
620 To solve all of these problems,
621 the UCI BBoards facility introduces a new entity into the picture:
622 all interest group mail is handled by a special component of the mail system.
623 The distribution address maps to a special {\it channel} that performs
625 First, if local delivery is to be performed,
626 then a copy of the message is placed in a global maildrop for the interest
627 group with a timestamp and a unique number.
628 Local users can read messages posted for the interest group by reading this
630 Second, if further distribution is to take place,
631 a copy of the message is sent to the distribution address in such a way that
632 if any of the addresses are bogus,
633 failure notices will be returned to the local maintainer of the group
634 address list, rather than the originator of the message.
636 This scheme has several advantages:
637 First, messages delivered to the local host are processed and saved once
638 in a globally accessible area.
639 The UCI BBoards facility supports software which allows a user to query an
640 interest group for new messages and to read and process
641 those messages in the \MH/-style.
642 Second, once a host administrator subscribes to an interest group,
643 each user can join or quit the list's readership without
645 Third, a hierarchical distribution scheme can be constructed to
646 reduce the amount of delivery effort.
647 Fourth, errors are prevented from propagating.
648 When an address on the distribution list goes bad,
649 the list moderator who is immediately responsible for the address is notified.
650 If a local moderator does not exist,
651 then the local PostMaster is notified (not the global group moderator).
653 In addition to solving the problems outlined above,
654 the UCI BBoards facility supports several other capabilities.
655 BBoards may be automatically archived in order to conserve disk space and
656 reduce processing time when reading current items.
658 the archives can be separately maintained on tape for access by interested
661 Special alias files may be generated which allow the \MH/ user to shorten
663 For example, instead of sending to {\tx SF-Lovers@Rutgers},
664 a user of \MH/ usually sends to \eg{SF-Lovers} and the \MH/ aliasing
665 facility automatically makes the appropriate expansion in the headers of the
668 the user need only know the name of an interest group and not its global
671 Finally, the UCI BBoards facility supports {\it private} interest groups
672 using the \unix/ group access mechanism.
673 This allows a group of people on the same or different machines to conduct a
676 The practical upshot of all this is that the UCI BBoards facility automates
677 the vast majority of BBoards handling from the point of view of both the
678 PostMaster and the user.
680 \MH/ provides three programs to deal with interest groups.
681 The \pgm{bbc} program is used to check on the status of one or more groups,
682 and to optionally start an \MH/ shell on those groups which the user is
684 The \pgm{bbl} program can be used to perform manual maintenance on a
685 discussion group beyond the normal automatic capabilities of the UCI BBoards
688 the \pgm{msh} program implements an \MH/ shell for reading BBoards,
689 in which nearly all of the \MH/ commands are implemented in a single program.
691 Observant readers may note that the use of \pgm{msh} is contrary to the \MH/
692 philosophy of using relatively small, single-purposed programs.
694 the authors admit that this is true.
695 In an effort to avoid some problems with shared-access and message naming
696 conventions (which are beyond the scope of this paper),
697 BBoards are kept in maildrop format (monolithic) instead of folders.
698 Some research has gone into overcoming this problem in order to restore
699 \MH/'s purity of purpose,
700 but all solutions proposed to date are either unworkable or require
701 significant recoding of \MH/'s internals.
703 \subsection{Encapsulation} % mtr
705 some interest groups appear in digest form.
706 This means that the messages which appear in such a forum actually
707 encapsulate other messages in their body.
708 It turns out that the generation of a digest is not at all unlike the
709 generation of a draft which forwards one or more messages.
710 In RFC934\cite{MRose85b},
711 a method is proposed to standardize message encapsulation for the ARPA
713 \MH/ uses this method for the generation of digests,
715 and blind-carbon-copies.
717 A key requisite for using an encapsulation technique for digests and
718 forwardings is the ability to later decapsulate the contents.
719 Without this ability,
720 the forwarded messages are of little use to the recipients because they can
721 not be distributed, forwarded, replied-to, searched-for,
722 or otherwise processed as separate individual messages.
723 In the case of a digest,
724 a bursting capability is especially useful.
725 Not only does the ability to burst a digest permit a recipient of the digest
726 to reply to an individual digestified message,
727 but it also allows the recipient to selectively process the other messages
728 encapsulated in the digest.
731 a single digest issue usually contains more than one topic.
732 A subscriber may only be interested in a subset of the topic discussed in a
734 With a bursting capability,
735 the subscriber can burst the digest,
737 and process those messages which are of interest.
738 The others can be ignored,
739 if the user so desires.
741 Note that with proper encapsulation technology,
742 one can argue for the re-distribution of messages simply becoming
743 special cases of message forwarding.
745 the NBS Standard for Mail Interchange\cite{FIPS98}
746 and the recent CCITT draft on Mail Handling Systems standards\cite{X.400}
747 both discourage the re-distribution facility in favor of forwarding
750 \subsection{Encapsulation and Blind-Carbon-Copies} % mtr
751 Many user agents support a blind-carbon-copy facility.
752 \MH/ implements this using a form of encapsulation.
753 It may not be apparent to the reader as to why encapsulation of the original
754 message is a good way to deliver blind-carbon-copies.
755 With a blind-carbon-copy facility,
756 two types of addressees are possible in the draft to be sent:
757 {\it visible} and {\it blind}.
758 The visible recipients are listed as addresses in the \eg{To:} and \eg{cc:}
760 and the blind recipients are listed in the \eg{Bcc:} fields of the draft.
761 The idea behind this facility is that copies of the draft which are
762 delivered to the \eg{To:} and \eg{cc:} recipients should show the visible
765 A major concern with a blind-carbon-copy facility
766 is that blind recipients should be prevented from accidentally replying to the
767 message in such a way that the visible recipients are included as addressees
770 There are several methods to implement this facility.
771 Most rely on posting two drafts with the \MTS/.
772 One draft is destined for visible recipients,
773 and simply lacks the \eg{Bcc:} fields of the original draft.
774 The second draft is destined for the blind recipients.
775 The question then arises as to what form this latter draft posted should take.
777 One approach might be to disable the \eg{To:} and \eg{cc:} fields of the
778 draft sent to the blind recipients
779 (e.g., by prefixing the string \eg{BCC-} to these fields).
781 this is often very confusing to the blind recipients
782 because it differs from what the visible recipients got.
783 Although accidental replies are not possible,
784 it is often difficult to tell that the message received is the result of a
787 The method used by \MH/ is to post two drafts,
788 a visible draft for the visible recipients,
789 and a blind draft for the blind recipients.
790 The visible draft consists of the original draft without any \eg{Bcc:} fields.
791 The blind draft contains the visible message as a forwarded message.
792 The headers for the blind draft contain the minimal RFC822 headers
793 (\eg{From:} and \eg{Date:})
795 if the original draft had a ``Subject:'' field,
796 then this header field is also included.
798 \MH/ alerts the recipient that the message is a blind-carbon-copy by
799 placing this information in the initial encapsulation information in the
800 blind recipient's copy.
801 This scheme prevents inadvertent replies while allowing the recipient
802 full access to an exact copy of what was sent to the visible recipients.
804 \section{\MH/ as a Record Handler} % stef
805 Although message format standards such as RFC822
806 (and its predecessors) were originally devised to facilitate
807 computer processing of interpersonal messages,
808 there is no special reason why the concept should be
809 limited to interpersonal message processing.
810 Messages are just one of a variety of useful record forms that might
811 be created in one place and transfered to another for processing.
813 RFC822 wisely left open the option for higher level applications to use
814 arbitrary header names or field contents by proscribing \MTS/ use
815 of header names beginning with \eg{X-}.
817 \MH/ carries though on this idea by allowing the \pgm{pick} command
818 to accept any arbitrary field name for string searches,
819 so MH users can select on any arbitrary field name without prior definition.
821 since all messages are simply files in \unix/ directories,
822 applications can be developed to apply any programmable process to
823 any selected message.
826 a {\it Time Card Form} might be called up by an \MH/ user with
827 \example comp\ -form\ timecomps\endexample
828 to enter time and attendance information into \eg{X-time$\tdots$:} fields in a
829 draft message record.
830 The \file{timecomps} form would include the address of a
831 supervisor who should validate the information,
832 along with empty fields to be filled in with data.
833 In fancy applications,
834 this might be done with a sophisticated interactive data entry tool
835 which would validate entered information,
836 but this is an open choice within the \MH/ framework.
838 alternative would be to use a received message as the blank form to add a
839 degree of central control over time and attendance reporting forms.
841 Receiving supervisors could simply register approval by using the \MH/
842 \pgm{dist} command to resend subordinates' time cards to higher approval
844 to send them to a time card collection address.
845 The \MH/ \pgm{dist} command automatically inserts ``ReSent'' header fields
846 showing who resent it and the resending date.
848 the MH \pgm{forw} command could be used to transfer a batch of approved time
849 cards to the next processing station.
850 If desired, a new ``approval'' command could be programmed to provide a more
851 trusted authentication, perhaps with encryption of the content.
852 Trusted mail systems, such as \trustedmail/\cite{MRose85c},
853 are becoming available for this purpose.
855 At the final collection destination,
856 an automated User Agent could be programmed to directly load the data into
857 the Time and Attendance DBMS by
858 parsing and decoding the data contained in the \eg{X-time$\tdots$:} fields.
859 It might be noted that while the RFC822 does not restrict the
860 internal forms of messages,
861 it is necessary to conform to the interchange standard if specialized filters
862 for message headers are not to be built to serve as {\it export laundries}
863 (a term originating with Stephen H.~Willson to describe conformance
864 transformations in \Ada/).
866 \subsection{Mapping Between Record Modes (DBMS/MHS)}
867 This time and attendance example suggests that it is possible to define
868 one-to-one mappings between RFC822 fields and DBMS data elements.
869 For every DBMS data element definition,
870 there is a potential corresponding RFC822 transferable equivalent
871 definition which can facilitate mail transfers of record information.
873 a large portion of the definitional work is already done where a Data Base
874 has already been defined.
875 All that remains is to define the RFC822 equivalents.
877 The suggestion that a batch of time cards be forwarded inside a ``cover''
878 message implies that it is possible in the \MH/ framework to recursively
879 bundle messages within messages, and be able to recover the originals for
880 separate processing at a receiving destination.
881 The \MH/ \pgm{burst} command can be applied recursively for this purpose
882 because \MH/ encapsulation uses an unambiguous scheme to delimit messages
883 that are enclosed inside other messages.
885 it should be possible to extract a structured set of records from a DBMS
886 and mail the set to a foreign site for processing, or reinsertion into
888 As long as the DBMS data element definitions
889 correctly correspond to the RFC822 definitions,
890 it is not even necessary
891 for the source and destination DBMS systems to be the same.
893 From this discussion,
894 it is concluded that the \MH/ framework can be useful
895 for building distributed record handling systems where people at widely
896 scattered locations must create and submit record forms for processing
897 at distant locations.
898 This might prove to be especially effective when
899 a mail system is also needed for other communication purposes.
900 A network of sales offices is a good example,
901 where general message service would be used for communications
902 with remote manufacturing and distribution centers,
903 and could also be used for an order entry system.
905 Another example might be for structured communications, as occur in
906 requisition and purchasing systems.
907 Requisitions could be filled in and mailed to approval offices,
908 and resent or forwarded to others for action.
910 the requisitions could flow into other other more suitable
911 processing systems as needed.
912 At the very least, the ability to originate
913 requisitions can be distributed to anyone with access to a mail system
914 that can originate a proper requisition form.
917 \MH/ already supports group discussions with its BBoard facilities
918 which allow for automatic sorting of mail by group address,
919 with shared private or public group access to contributed items.
920 As has been shown to be possible with administrative record systems,
921 there is no obvious limit to the ways that group discussion traffic
922 might be organized into structured collections with indices,
923 annotations, or reference pointers
924 to aid in making conference archives more useful.
925 Indeed, \MH/ tools could even be used to feed discussion items into
926 existing conference systems.
928 \section{Distributed Mail} % mtr
929 Next, we consider how \MH/ might be used in a distributed mail environment.
930 Two schemes are discussed:
931 one in which connectivity is high and connections are relatively ``cheap'',
932 and one in which connectivity is low and connections are ``expensive''.
934 \subsection{The ARPA Internet Environs} % mtr
935 The ARPA Internet community consists of many types of heterogeneous nodes.
936 Some hosts are large mainframe computers,
937 others are personal workstations.
938 All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}.
939 Messages which conform to the Standard for the Format of ARPA Internet Text
940 Messages\cite{DCroc82}
941 are exchanged using the Simple Mail Transfer Protocol\cite{SMTP}.
943 On smaller nodes in the ARPA Internet it is often impractical to maintain
944 a message transport agent.
946 a workstation may not have sufficient resources (cycles, disk space)
947 in order to permit an SMTP server and associated local mail delivery system
948 to be kept resident and continuously running.
950 the workstation could be off-net for extended periods of time.
952 it may be expensive (or impossible) to keep a personal computer
953 interconnected to an IP-style network for long periods of time.
955 the node is lacking the resource known as ``connectivity''.
958 it is often desirable to be able to process mail with \MH/ on these smaller
960 and they often support a user agent to aid the tasks of mail handling.
961 To solve this problem,
962 a network node which can support a message transport entity
963 (known as {\it service} host) offers
964 a maildrop service to these less endowed nodes
965 (known as {\it client} hosts).
966 The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a
967 workstation to dynamically access a maildrop on a service host to pick-up
970 there are three different descriptions of the POP.
971 The first, cited in \cite{JReyn84},
972 was the original description of the protocol,
973 which suffered from certain problems.
975 two alternate descriptions have been developed.
976 The official revision of the POP\cite{MButl85},
977 and the revision of the POP which \MH/ uses
978 (which is documented in an internal memorandum in the \MH/ release).
979 This paper considers the POP in the context of the \MH/ release.}
980 The level of access includes the ability to
981 determine the number of messages in the maildrop and the size of each message,
982 as well as to retrieve and delete individual messages.
983 More sophisticated implementations of the POP server
984 are able to distinguish between the header and body portion of each message,
985 and send $n$ lines of a message to the POP client.
986 This capability is useful in thinly connected environments where conservation
987 of bandwidth is important.
988 By utilizing a more intelligent POP client,
989 a user may generate ``scan~listings'' and dynamically decide which messages
990 are worth taking delivery on.
991 The philosophy of the POP is to put intelligence in the
992 POP clients and not the POP servers.
994 The underlying paradigm in which the POP functions is that of a
995 split-slot/remote-\UA/ model.
996 The client host (such as a workstation) is without a co-resident
997 {\it message transport agent} (\MTA/),
998 and thus makes use of a service host with an \MTA/ to obtain posting (SMTP)
999 and delivery (POP) services.
1000 The entity which supports this type of environment is called a remote-\UA/
1001 since the user agent resides on a different host than its associated message
1004 One very important issue which must be raised at this point is one of
1006 The POP requires that a client identify itself to the server using a
1007 server-specific user-id and a server/user-specific password.
1008 This authentication is required to prevent unauthorized entities from
1009 accessing a maildrop on a POP service host.
1010 It must be emphasized that the POP client is not a ``trusted'' entity of the
1011 \MTS/ in any sense at all.
1014 one would also like to authenticate mail as it is posted on the POP service
1015 host using the SMTP.
1017 in the ARPA Internet community,
1018 no authentication is done with SMTP transactions.
1019 This is considered a shortcoming by those interested in researching the
1020 split-\UA/ model of distributed mail.
1021 The MZnet environment,
1022 discussed in the next section,
1023 has authentication facilities for posting mail.
1025 The current release of \MH/ supports the above model fully:
1026 a POP client program is available to retrieve a maildrop on a POP service
1029 using the SMTP configuration for delivery in \MH/,
1030 a user is able to specify a search-list of service hosts (and networks)
1031 with which to try to post mail.
1032 Using this search-list,
1033 when an \MH/ user posts a draft,
1034 the \pgm{post} program will attempt to establish an SMTP connection
1035 with each host in the list to post the message until it succeeds.
1036 Initial experimentation with the split-\UA/
1037 in a local network environment has proved quite successful.
1039 \subsection{The MZnet Environs} % jns
1041 the MZnet project\cite{EStef84} at the University of California, Irvine
1042 set out to study the problems involved with bringing
1043 Internet-class mail handling facilities to personal computers.
1044 The project used Apple~II computers running the CP/M 2.2 operating system.
1045 Programming was done in a subset of the C language called BDS C.
1046 The transport system was based on the \MMDF/ PhoneNet software,
1047 and implemented a {\it split-slot} arrangement between a personal computer
1049 centralized mail distribution system that performed user
1050 authentication and provided a relatively secure mail transfer channel.
1051 The user agent, CP/MH, was based on \MH/.
1053 A conclusion of the experiment was that small personal computer systems
1054 with dial-up phone connections constrain user agent systems design in
1055 ways that require use of a {\it split-slot} interface between the \UA/
1056 and its supporting \MTA/, and that this interface
1057 best provides the required services if it has error controlled command
1058 and data transfer facilities, with interactive behavior.
1059 Another conclusion indicated that a good design for a user agent in such
1060 a small personal computer
1061 environment could be based on a very modular architecture,
1063 A final conclusion was that session-level authentication of the client \UA/
1064 is required for both posting and delivery.
1066 It should be noted that the MZnet project had a profound influence on the
1067 development of the POP used by \MH/.
1068 A somewhat more detailed discussion of the relations between the two
1069 environments can be found in the POP description contained
1070 in the \MH/ release.
1072 \section{A Final Note} % jns
1073 With the fifth major release of the \MH/ system,
1074 it has become clear that most major increases in functionality can come
1075 only at the expense of either efficiency or portability.
1076 Although there has been great effort to keep \MH/ portable to a number of
1077 \unix/ implementations,%
1078 \nfootnote{As of this writing,
1079 there are approximately 75~sites running \mh5
1080 on five different implementations of \unix/.}
1081 the divergence in process management facilities,
1082 file system enhancements,
1083 and even C~compiler capabilities
1084 has already presented obstacles to some attempts to rehost the \MH/ code.
1086 There has been some discussion of implementing specialized \MH/ daemons
1087 that maintain context information over one or more sessions,
1088 thus decreasing the amount of overhead involved in starting each \MH/ command.
1090 even if such daemons were to be implemented,
1091 they would be very difficult to move to versions of \unix/
1092 without sophisticated process management facilities,
1093 and even then the differences in ``philosophies''
1094 of process management\cite{WJoy83,EOlse84}
1095 would tend to keep such daemons system specific.
1096 A better solution seems to be simply to tune existing code.
1098 \section{Acknowledgements}
1099 The authors would like to thank Norman Z.~Shapiro and
1100 Phyllis Kantar of the Rand Corporation for their invaluable comments during
1101 the preparation of this paper.
1103 \section{Distribution Information}
1104 For information concerning distribution mechanics for the current release of
1105 \MH/, please contact:
1106 $$\displayindent=\leftskip \advance\displayindent by1.5\parindent
1107 \halign{\leftline{#}\cr
1109 Attn: MH Distribution\cr
1110 Department of Information and Computer Science\cr
1111 University of California, Irvine\cr
1112 Irvine, CA 92717\qquad USA\cr