5 MH: A Multifarious User Agent
10 Member, Research Technical Staff
12 Northrop Research and Technology Centery
18 President, Network Management Associatesz
20 and Visiting Lecturer, University of California, Irvine
26 Member, Technical Staff
28 Local Network Systems./
35 The UCI version of the Rand Message Handling System (MH) is discussed, including
37 important extensions. MH is a powerful user agent which operates in the ARPA
39 Internet and UUCP environments. In addition to the basic functions provided
41 by a user agent, such as reading and sending mail, MH has several distinguishing
43 characteristics which give the user additional message handling capabilities. In
45 particular, MH provides mechanisms for organizing messages, tailoring its own
47 behavior, and extending its functions.
50 This document describes MH from several perspectives. Particular emphasis is
52 given to: the MH user environment, advanced features of MH which have proven to
54 be particularly useful for sophisticated users of electronic mail, MH's potential as
56 a record manager, and MH as a part of a distributed mail environment. Although
58 MH as been widely used since its creation in 1979, a discussion of its perspectives
60 and functionality has not appeared in the open literature.
63 ________________________________________
64 y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
66 Computer mail: MRose% NRTC@USC-ECL
67 z 17301 Drey Lane, Huntington Beach, CA 92647. Telephone: 714/842-3711.
69 Computer mail: EStefferud@ICS.UCI.EDU
70 ./ 130 McCormick Avenue, Suite 102, Costa Mesa, CA 92626. Telephone: 714/754-6631.
72 Computer mail: JSweet@ICS.UCI.EDU
75 MH: A Multifarious User Agent
81 The UCI version of the Rand Message Handling System, MH, is a user agent.
83 In the interests of brevity, we dispense with the usual definition of terms, refer the
85 reader to Figure 1, and simply note that MH is not responsible for delivering mail.
87 Rather, it interacts with a message transport system, MTS, at two interfaces: it
89 sends mail by placing it through a posting slot to the MTS, and it receives mail by
91 retrieving it through a delivery slot from the MTS. Besides these two MTS-specific
93 activities, the tasks which MH addresses are: the composition of messages (which
95 may, or may not, be in reference to previously sent messages), the reading of
97 messages, and the organization of messages.
100 MH was originally developed by the Rand Corporation, and initially was
102 proprietary software. The Department of Information and Computer Science
104 at University of California, Irvine, shortly after joining the Computer Science
106 Network (CSnet), acquired a copy of MH, and began additional development of
108 the software. Since that time, the Rand Corporation has declared MH to be in the
110 public domain, and the UCI version of MH has passed through four major releases.
113 Much credit must be given to the initial designers and implementors of MH:
115 Bruce Borden, Stockton Gaines, and Norman Shapiro. Although MH has suffered
117 significant development at UCI since Rand's initial release, the fundamental
119 concepts of MH's environs have remained nearly unchanged. In addition, the
121 current maintainers of MH gratefully acknowledge the comments of the many sites
123 which have run various releases of MH in the past.
126 MH runs on different versions of the UNIX1 operating system (such as
128 4.2bsd UNIX and various flavors of v7 UNIX). In addition, MH supports four
130 different MTS interfaces: SendMail[EAllm83], the standard mailer for 4.2bsd
132 systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel Memo
134 Distribution Facility developed by the University of Delaware which forms the
136 software-backbone for CSnet[DCome83] mail relays service; SMTP, the ARPA
138 Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
141 The organization of this paper is straight-forward, given space considerations.
143 Initially, the MH philosophy of mail handling is presented, along with a description
145 of the environment which the MH user is given to process mail. Following this,
147 certain advanced features of MH are discussed in more detail. In particular, the
150 ________________________________________
151 1 UNIX is a trademark of AT&T Bell Laboratories.
155 Copyright fcl1985, North Holland Publishing Company 1
156 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 2
157 ______________________________________________________________________________________________________________________
173 MTA MTA : : : : : : MTA
181 ___________________________________________________MTS_model__________________________________________________________
185 notion of a draft folder is introduced, which permits the handling of multiple drafts
187 during composition. In addition, message selection facilities are described. Next,
189 two different aspects of MH's power as a software system are discussed: record
191 handling, in which MH facilitates record processing systems; and, how MH can be
193 employed in a distributed mail environment. This latter section raises questions
195 as to the location of the posting and delivery slots, along with authentication
197 mechanisms. Finally, we conclude by discussing areas of future development which
202 Although familiarity with MH is not assumed on the part of the reader,
204 some knowledge of the UNIX operating system is useful. Appendix A gives a short
206 synopsis of the MH commands.
212 Although MH has many traits which tend to differ it from other user agents,
214 the design aspect which fundamentally influences the interface between MH and
216 the user is that it is composed of many small programs instead of one very large
218 one. This architecture gives MH much of its strength, since intermediate and
220 advanced users are able to take advantage of this flexibility.
223 The key to this flexibility is that the UNIX shell (usually the C shell or the
225 Bourne shell), is the user's interface to MH. This means that when handling mail,
227 the entire power of the shell is at the user's disposal in addition to the facilities
229 which MH provides. Hence, the user may intersperse mail handling commands
231 with other commands in an arbitrary fashion, making use of command handling
233 capabilities that the user's shell provides.
234 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 3
237 Furthermore, rather than storing messages in a complicated data structure
239 within a monolithic file, in MH, each message is a UNIX file, and each folder (an
241 object which holds groups of messages) is a UNIX directory. That is, the directory
243 and file structure of UNIX is used directly. As a result, any UNIX file-handling
245 command can be applied to any message.
248 To the novice, this may not make much sense or may not seem important.
250 From three years of observation, we have seen that as users of MH have become
252 more experienced they have found this capability to be quite attractive. In
254 addition, this approach is often quite pleasing to system implementors, because
256 it minimizes the amount of coding to be performed and, given a modular design,
258 changes to the software system can be maintained easily. Our empirical findings
260 confirm our theoretical expectations regarding the MH architecture.
263 Having described how MH fits into the UNIX environment, we now discuss
265 the mail handling environment which is available to the MH user.
270 MH provides a complementary environment to the user's shell. While the
272 shell maintains a context related to the user's focus in the file system (a current
274 working directory ), mail handling is performed in a separate mail folder context.
276 Operations on mail can therefore be performed entirely without regard to the
278 current file system context, although MH does not prevent the user from making
280 use of that context. Certain mail handling functions do make use of information
282 maintained by the shell. For instance, by setting certain shell parameters, called
284 environment variables, alternate mail handling contexts can be selected.
287 MH conventions often have direct analogs to shell or file system conventions.
289 The shell has a current working directory; MH has a current mail folder. When
291 the user begins a session on the system, the user's "home directory" is the base
293 context; MH's default base area, the Mail directory, is found under the user's home
295 directory. The user's default shell parameters are set upon beginning a new session
297 from a startup profile (called .profile for sh users or .cshrc for csh users); the default
299 parameters for MH commands are taken from a file called .mh_profile in the user's
301 home directory. The shell has an environment ; MH has a context file. Each of the
303 user's directories has files; each of the user's MH folders has messages.
306 These parallels have a basis not only in MH's high level mail handling model,
308 but also in the way low level shell and file system conventions have been abstracted
310 to implement MH conventions. Directories are folders; files are messages. The Mail
312 directory forms the root of a virtual file subsystem within which the user operates
314 on mail without disturbing files outside this mail handling domain.
315 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 4
316 ______________________________________________________________________________________________________________________
320 $HOME/ (user's home directory)
328 context inbox/ mhl.format replcomps drafts/ chron/
333 sequences yr.1984/ yr.1985/
341 __________________________________________(directories_are_shaded)____________________________________________________
347 The .mh_profile contains plaintext that describes the user's default mail
349 handling parameters. An example of an elaborated profile is shown in Figure 3.
352 Each line in the profile consists of an MH parameter name terminated with
354 a colon (`:') followed by parameter values. In this example, "global" parameters
356 are listed in the first few lines, with program-specific parameters following. Each
358 MH program examines global parameters as well as any parameter with the same
360 name by which the program was invoked. For example, the comp program, which
362 is used to compose new messages to be sent, examines the entries:
366 Path___: The path parameter specifies the name of the MH root directory.
368 This is normally named Mail.
371 Editor____: The editor parameter specifies which text editor is first invoked
373 to create the header information and body of a message draft. In
375 most cases, this editor is the MH default editor, prompter.
378 Draft-Folder______: This parameter specifies a folder within which new message drafts
380 are to be created. The draft folder mechanism is an advanced
381 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 5
382 ______________________________________________________________________________________________________________________
389 Previous-Sequence: pseq
390 Alternate-Mailboxes: jsweet@uci-icse, jsweet@uci-750a
392 Sequence-Negation: not
394 bboards: system mh-workers sf-lovers whimsey
395 comp: -form mycomponents
396 dist: -annotate -inplace
398 forw: -annotate -inplace -format
403 repl: -annotate -inplace -cc me
405 scan: -noheader -time
406 show: -noheader -format
412 ___________________________________________Elaborated_MH_Profile______________________________________________________
416 feature of MH that is given separate treatment in a later segment
421 comp____: The program-specific parameter examined by comp lists user-
427 Other programs invoked by comp (e.g. prompter and send ) would examine their
429 own profile entries as well. MH programs have reasonable compiled-in defaults
431 and also permit options to be specified on the shell command line with which the
433 programs are invoked. The order of override precedence is: command line options
435 first, .mh_profile options second, and compiled-in defaults last.
438 Each program option is prefixed by a dash (`-') following the UNIX convention.
440 Unlike most UNIX-style options, however, the options are words rather than single
442 letters. An option may be abbreviated to an unambiguous prefix. Each MH
444 program has a `-help' option that displays a brief summary of the program's
447 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 6
452 In a typical paper-oriented office, new correspondence arrives and is stacked
454 in an "in box", while outgoing correspondence is placed in an "out box". Processed
456 material is stored in appropriately labelled folders and filed away for future
458 reference. This state of affairs is modelled in MH with folders and messages, which
460 are simply text files (one message per file) stored under the folder directories. Most
462 of the user's folders are kept under the Mail directory.
465 A folder is given an alphanumeric name permissible within the UNIX file
467 system structure, and each message stored therein is given a numeric name in the
469 range 1..1999. The upper bound on message numbers was selected for efficient
471 access to an internal representation, an array of bits (a "bit set"), with each bit
473 indicating the presence or absence of a message with a number in the range 1..1999.
475 This internal representation also restricts the order of multiple message reference
477 to an ascending numerical sequence. Other representations have been studied
479 (e.g., an unsorted sparse array of integers), but have been rejected for reasons of
481 efficiency. Folders may contain subfolders, corresponding to UNIX tree-structured
483 directories. For the sake of completeness, it might be said that "sub-messages"
485 exist insofar as message "digests", which nest messages inside other messages, are
487 supported by certain advanced MH functions.
490 The current working folder is the default folder selected for almost all MH
492 commands. To select explicitly a folder for mail handling commands entails
494 specifying the name of the folder, prefixing the name with a plus-symbol (`+'). An
499 refile 1 2 3 +chron/yr.1984
502 This command re-files the selected messages (1 , 2, and 3 here) from the current
504 working folder to a subfolder under the folder chron named yr.1984 . To see the
506 folder/subfolder relationship, refer to Figure 2.
509 The plus-symbol notation is specific to those folders immediately subordinate
511 to the Mail directory. This is analogous to "absolute pathnames" in UNIX_those
513 files whose positions in the file system hierarchy are given starting with the system
515 root, names prefixed with the slash character (`/'). To specify folders subordinate to
517 the current working folder, an at-sign (`@') is substituted for (`+'). It is permitted
519 to use UNIX dot notation to specify parent folders. Referring to Figure 2, if the
521 current working folder were ``+chron/yr.1985'' , then the command
527 selects the subfolder yr.1984 in the parent directory chron , as the new current
529 working folder. While the current working folder is normally the default, it may
531 be specified explicitly as ``@.'' .
532 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 7
533 ______________________________________________________________________________________________________________________
536 cc: <?to_cc_me><to>,<cc>,<me>
537 Subject: <?subject>Re: <subject>
538 In-reply-to: <?date><?message-id>Your message of <date>.
540 In-reply-to: <?date><!message-id>Your message of <date>.
547 _______________________________________Elaborated_Reply_Template______________________________________________________
553 The .mh_profile contains static information about the user's preferences. A
555 context file, contained in the Mail directory, contains the current mail handling
557 environment information, which changes as different folders, messages, and named
559 message lists (called message sequences ) are selected, created, and updated. This
561 information is retained between invocations of MH commands, and is preserved
563 across system sessions.
568 The message draft composition functions (comp, repl, forw, and dist ) use
570 certain default header formats, which may be changed by the user through the use
572 of message templates. The exact format of a template may vary among commands.
574 An example of an elaborated template for the reply command repl is shown in
579 This template specifies how the automatically-generated header for a draft
581 message in reply to a source message is to be formatted. The syntax is capable of
583 directing output of header lines based on the presence or absence of other header
585 lines in the source message.
588 Other kinds of templates are used to specify the display formats of messages,
590 or to specify the way that messages are to be included in other messages. This is
592 similar to the functionality provided by BBN Hermes[HERMES], another powerful
594 mail handling system for Tops202 based systems.
597 Explaining All This to New Users
599 There do exist people who do not like MH.3 The emerging pattern of
601 complaints from such people indicates that MH accentuates their perceptions of
603 the deficiencies of UNIX, to wit, lack of interactivity and lack of easily found help
605 facilities. Also, some feel that the proximity of the mail handling environment
607 to the operating system is a distraction, rather than an asset. There have been
609 ________________________________________
610 2 Tops20 is a trademark of Digital Equipment Corporation.
611 3 At UCI, these people are reported to be weeded out at an early stage and quietly taken to the
613 Ministry of Love to be made uncrimethinkful.
614 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 8
617 some attempts to make MH more accessible to users who prefer menu-oriented or
619 monolithic mail system interfaces.4
622 In truth, users new to UNIX do not always acclimate to MH easily. The
624 command set is undistinguishably mixed in with all other UNIX utilities, and it
626 is not easy, without aid of a manual, to pick out the necessary commands. MH
628 does not provide any "hand-holding" to guide the user through a minimally useful
633 Another problem is that the initial default user profile is too often sparse,
635 containing only a ``Path:'' parameter. MH commands will perform adequately
637 without specific information in the profile, so new users often neglect optionally
639 useful MH capabilities, eventually becoming frustrated with the limited default
641 capabilities, yet unable to determine without researching through the user's
643 manual, the necessary options that would solve their problems.
646 The currently available means for learning how to use MH are:
650 - One-on-one tutoring by knowledgeable MH users, which has so far
652 shown the best results with new users.
655 - Consulting the MH Tutorial [MRose84b], or the MH User's
660 - Using the msh ("MH shell") program as a training shell to read
662 bulletin boards. The msh command is an interactive program that
664 provides some help messages and can list available MH commands.
668 No on-line tutorial materials are presently distributed with the mh.5 system,
670 although there are some plans in the works to provide a program to help with
672 setting up the user profile that would also provide operational tips for MH and
677 It should be noted that these perceived defects of MH do not affect its utility
679 any more than analogous problems with any operating system will diminish its
681 actual capabilities. Users may quarrel with the means chosen for orchestrating
683 MH, but the fact remains that MH is a very useful set of mail handling tools that
685 is flexible, infinitely interoperable with other UNIX text handling tools, and yet
687 simple enough for new users to grasp once they are given the proper start. The
689 fact that better tutorial materials and training do not exist only means that some
691 further work needs to be done in the area of user-education.
695 ________________________________________
696 4 For example, mhe from Brian Reid of Stanford University and emh from Marshall Rose are
698 instances of macro packages for James Gosling's EMACS extensible editor, while the hm program
699 from Jim Guyton of the Rand Corporation is a monolithic MH interface. As of this writing, none
700 of these programs is documented in the literature.
701 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 9
704 A Few Advanced Features
706 We now consider certain advanced features in MH. These features have been
708 chosen to demonstrate some useful capabilities available to the MH user. It should
710 be noted that many capabilities of MH, such as shell scripts for extensibility, mail
712 delivery hooks, the personal aliasing facility, and so forth, are not described here
719 The draft folder facility provides a method by which several message drafts can
721 be simultaneously composed and maintained until sent. The rationale for this is that
723 partially composed message drafts, perhaps elaborate sets of separate messages,
725 can be incrementally completed, while a folder provides a consistent organization
727 for drafts in progress. This is comparable to similar situations in the "paper world"
729 where contracts, business correspondence, and other communications, rather than
731 being created serially with each posted in turn before composing the next, are
733 usually left in various stages of completion before they are eventually mailed.
736 The ``Draft-Folder:'' parameter value in the MH profile is used to specify
738 a default draft folder, where each draft is given a number and an "artificial" date
740 stamp. Provided that the proper header fields have been completed, a scan listing
742 of the draft folder provides a summary of each draft in progress: to whom the
744 message is to be sent, the subject, the date of the draft's initial creation and
746 optionally, the current size of the draft in terms of characters. Experienced users
748 of MH may often keep as many as five to ten unfinished drafts in their draft folder.
750 "Draft clutter" can be remedied easily with the rmm command.
755 MH commands accept message sequence specifications to specify which `msg'
757 or `msgs' are to be operated upon. Here are some examples:
763 to get a scan listing of messages 1, 3, 5, 19 and 185.
769 to get a scan listing of whatever message sequence was given to the previous MH
771 command (in this case 1, 3, 5, 19, and 185).
777 to get a display of the first and last messages in the folder. The MH sequences
779 named ``first'' and ``last'' are system defined pseudo sequences which act like
781 explicit sequences when given to MH commands. Others are ``cur'' , ``next'' ,
783 ``prev'' , and ``all'' which respectively specify the "current" message, the
785 "next" after cur, the "previous" message before cur, or "all" messages in the
786 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 10
789 current-folder. The scan assumes ``all'' while show assumes ``cur'' , unless
791 overridden on the command line. Over-ride precedence is: command-line first,
793 .mh_profile second, and compiled-in default last.
796 Users can define additional sequences for similar use, but must avoid using
798 reserved names. A few optional sequence names have been preempted by MH, such
800 as ``pseq'' to mean the "sequence used by the previous MH command," and
802 ``unseen'' to mean the "messages not yet seen by the user." Sometimes these
804 preempted names can be changed by resetting them in the user's MH profile, but
806 these facilities are beyond the scope of this discussion.
809 The mark command can be used to set the values for user-defined sequences:
814 mark 4 5 9 -seq zzz -nozero
817 will create a user-sequence named ``zzz'' and put the sequence ``1 3 5'' in it.
819 The mark command assumes that any prior content in an existing user-sequence
821 should be "zeroed" before the new sequence value is recorded. This can be
823 prevented with a `-nozero' switch on the command line, to add ``4 5 9'' to
825 the original ``1 3 5'' to yield ``1 3 4 5 9'' .
828 mark pseq zzz -seq zzznew
831 will create a new sequence named ``zzznew'' and set its value to the combined
833 (inclusive or) of the existing user-sequences in ``pseq'' and ``zzz'' for its value.
836 Another more powerful way to set the values of a user-sequence is with the
838 pick command, which provides full string search capabilities:
841 pick -from mrose -seq yyy
843 pick -from mrose -seq yyy -list
846 will search though all the ``From:'' fields in the current folder for the string
848 ``mrose'' and place the list of "hits" in the sequence named ``yyy'' . The
850 `-list' switch will cause the resulting list to also be displayed on the user's
852 terminal. If no `-seq name' switch is given, pick will assume `-list' and will
854 simply display the resulting list of hits on the user's terminal.
857 This `-list' behavior of pick allows users to take advantage of the UNIX
859 backquoting facility to embed searches in other MH commands.
862 scan `pick -from mrose`
863 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 11
866 will produce a scan listing of `-from mrose' hits because the UNIX shell will
868 spawn a process to execute the ``pick -from mrose'' segment and return the
870 `-list' results as the message sequence to be scanned.
876 could then be used to capture the "previous sequence" in zzz for later use.
879 One last facility should be mentioned here. It is also possible to negate a
881 sequence to specify a new sequence. The default negation string is ``not'' .
886 mark notzzz -seq zzznot
889 will give the user a scan listing of all the messages in the current folder that are
891 not included in the sequence ``zzz'' . The mark example will of course record
893 the negation of zzz in zzznot. It is a bad idea to use the string ``not'' as the
895 beginning of any user-sequence name, if ``not'' is defined as the negation string.
897 (Users can choose a different negation string.)
900 From this discussion, it should be clear that MH provides a uniform set of
902 ways to capture and use sequences to augment the user's short- and long-term
904 memory and to manipulate lists of interesting messages. User-sequences are
906 normally stored as RFC822 labeled text lines in a file (e.g., sequences) in the folder
908 with the messages referred to in the sequence. If a user does not have write access
910 to a folder, then the MH mark and pick commands will create a "private" sequence
912 in the user's context file. Switches are available to give the user control over the
914 choice of `-private' or `-public' sequence options.
917 Since user-sequences are stored as ordinary text lines in RFC822 labeled fields,
919 there is no prohibition against someone writing programs to perform any kind of
921 useful manipulation on MH sequences. Boolean operators can be implemented,
923 or complex indexing structures could be developed to serve special purposes. If a
925 DBMS can utilize UNIX pathnames or MH `+folder' and message names, then
927 the full power of the DBMS might be applied. The intention of MH development
929 teams has always been to leave open the widest possible array of options for
931 later extension. The only restrictions should be the user's ingenuity, programming
933 prowess, and the available machine resources. Unfortunately these resources always
935 seem to be available in limited quantities.
940 MH has a convenient interface to the UCI BBoards facility[MRose84a].5 This
942 facility permits the efficient distribution of interest group messages on a single
946 ________________________________________
947 5 The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
949 form under stand-alone MH.
950 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 12
953 host, to a group of hosts under a single administration, and to the ARPA Internet
958 Described simply, an interest group is composed of a number of subscribers
960 with a common interest. These subscribers post mail to a single address, known
962 as a distribution address (e.g., MH-Workers@UCI). From this distribution address,
964 a copy of the message is sent to each subscriber. Each group has a moderator,
966 which is the person that runs the group. This moderator can usually be reached
968 at a special address, known as a request address (e.g., MH-Workers-Request@UCI).
970 Usually, the responsibilities of the moderator are quite simple, since the mail
972 system handles distribution to subscribers automatically. In some interest groups,
974 instead of each separate message being distributed directly to subscribers, a batch
976 of (related) messages are put into a digest format by the moderator and then sent
978 to the subscribers. Although this requires more work on the part of the moderator
980 and introduces delays, such groups tend to be better organized.
983 Unfortunately, some problems arise with the scheme outlined above. First, if
985 two users on the same host subscribe to the same interest group, two copies of the
987 message will be delivered. This is wasteful of both processor and disk resources at
992 Second, some groups carry a lot of traffic. Although subscription to a group
994 does indicate interest on the part of a subscriber, it is usually not interesting to get
996 50 messages or so delivered to the user's private maildrop each day, interspersed
998 with personal mail, that is likely to be of a much more important and timely
1003 Third, if a subscriber's address in a distribution list becomes "bad" somehow
1005 and causes failed mail to be returned, the originator of the message is normally
1007 notified. It is not uncommon for a large list to have several bogus addresses. This
1009 results in the originator being flooded with "error messages" from mailers across
1011 the Internet stating that a given address on the list was bad. Needless to say, the
1013 originator usually does not care if the bogus addresses got a copy of the message
1015 or not. The originator is merely interested in posting a message to the group at
1017 large. On the other hand, the moderator of the group does care if there are bogus
1019 addresses on the list, but ironically does not receive notification.
1022 To solve all of these problems, the UCI BBoards facility introduces a new
1024 entity into the picture: all interest group mail is handled by a special component of
1026 the mail system. The distribution address maps to a special channel that performs
1028 several actions. First, if local delivery is to be performed, then a copy of the
1030 message is placed in a global maildrop for the interest group with a timestamp and
1032 a unique number. Local users can read messages posted for the interest group by
1034 reading this "public" maildrop. Second, if further distribution is to take place, a
1036 copy of the message is sent to the distribution address in such a way that if any of
1037 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 13
1040 the addresses are bogus, failure notices will be returned to the local maintainer of
1042 the group address list, rather than the originator of the message.
1045 This scheme has several advantages: First, messages delivered to the local
1047 host are processed and saved once in a globally accessible area. The UCI BBoards
1049 facility supports software which allows a user to query an interest group for new
1051 messages and to read and process those messages in the MH-style. Second, once
1053 a host administrator subscribes to an interest group, each user can join or quit
1055 the list's readership without contacting anyone. Third, a hierarchical distribution
1057 scheme can be constructed to reduce the amount of delivery effort. Fourth, errors
1059 are prevented from propagating. When an address on the distribution list goes
1061 bad, the list moderator who is immediately responsible for the address is notified.
1063 If a local moderator does not exist, then the local PostMaster is notified (not the
1065 global group moderator).
1068 In addition to solving the problems outlined above, the UCI BBoards facility
1070 supports several other capabilities. BBoards may be automatically archived in
1072 order to conserve disk space and reduce processing time when reading current
1074 items. Also, the archives can be separately maintained on tape for access by
1076 interested researchers.
1079 Special alias files may be generated which allow the MH user to shorten
1081 address type-in. For example, instead of sending to SF-Lovers@Rutgers, a user
1083 of MH usually sends to ``SF-Lovers'' and the MH aliasing facility automatically
1085 makes the appropriate expansion in the headers of the outgoing message. Hence,
1087 the user need only know the name of an interest group and not its global network
1092 Finally, the UCI BBoards facility supports private interest groups using the
1094 UNIX group access mechanism. This allows a group of people on the same or
1096 different machines to conduct a private discussion.
1099 The practical upshot of all this is that the UCI BBoards facility automates the
1101 vast majority of BBoards handling from the point of view of both the PostMaster
1106 MH provides three programs to deal with interest groups. The bbc program
1108 is used to check on the status of one or more groups, and to optionally start an
1110 MH shell on those groups which the user is interested in. The bbl program can be
1112 used to perform manual maintenance on a discussion group beyond the normal
1114 automatic capabilities of the UCI BBoards facility. Finally, the msh program
1116 implements an MH shell for reading BBoards, in which nearly all of the MH
1118 commands are implemented in a single program.
1121 Observant readers may note that the use of msh is contrary to the MH
1123 philosophy of using relatively small, single-purposed programs. Sadly, the authors
1124 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 14
1127 admit that this is true. In an effort to avoid some problems with shared-access and
1129 message naming conventions (which are beyond the scope of this paper), BBoards
1131 are kept in maildrop format (monolithic) instead of folders. Some research has
1133 gone into overcoming this problem in order to restore MH's purity of purpose, but
1135 all solutions proposed to date are either unworkable or require significant recoding
1142 As described above, some interest groups appear in digest form. This
1144 means that the messages which appear in such a forum actually encapsulate other
1146 messages in their body. It turns out that the generation of a digest is not at
1148 all unlike the generation of a draft which forwards one or more messages. In
1150 RFC934[MRose85b], a method is proposed to standardize message encapsulation
1152 for the ARPA Internet community. MH uses this method for the generation of
1154 digests, forwardings, and blind-carbon-copies.
1157 A key requisite for using an encapsulation technique for digests and
1159 forwardings is the ability to later decapsulate the contents. Without this ability,
1161 the forwarded messages are of little use to the recipients because they can not be
1163 distributed, forwarded, replied-to, searched-for, or otherwise processed as separate
1165 individual messages. In the case of a digest, a bursting capability is especially
1167 useful. Not only does the ability to burst a digest permit a recipient of the digest
1169 to reply to an individual digestified message, but it also allows the recipient to
1171 selectively process the other messages encapsulated in the digest.
1174 For example, a single digest issue usually contains more than one topic. A
1176 subscriber may only be interested in a subset of the topic discussed in a particular
1178 issue. With a bursting capability, the subscriber can burst the digest, scan the
1180 headers, and process those messages which are of interest. The others can be
1182 ignored, if the user so desires.
1185 Note that with proper encapsulation technology, one can argue for the
1187 re-distribution of messages simply becoming special cases of message forwarding.
1189 For example, the NBS Standard for Mail Interchange[FIPS98] and the recent
1191 CCITT draft on Mail Handling Systems standards[X.400] both discourage the
1193 re-distribution facility in favor of forwarding by encapsulation.
1196 Encapsulation and Blind-Carbon-Copies
1198 Many user agents support a blind-carbon-copy facility. MH implements this
1200 using a form of encapsulation. It may not be apparent to the reader as to why
1202 encapsulation of the original message is a good way to deliver blind-carbon-copies.
1204 With a blind-carbon-copy facility, two types of addressees are possible in the draft
1206 to be sent: visible and blind. The visible recipients are listed as addresses in the
1208 ``To:'' and ``cc:'' fields, and the blind recipients are listed in the ``Bcc:''
1210 fields of the draft. The idea behind this facility is that copies of the draft which are
1211 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 15
1214 delivered to the ``To:'' and ``cc:'' recipients should show the visible recipients
1219 A major concern with a blind-carbon-copy facility is that blind recipients
1221 should be prevented from accidentally replying to the message in such a way that
1223 the visible recipients are included as addressees in the reply.
1226 There are several methods to implement this facility. Most rely on posting
1228 two drafts with the MTS. One draft is destined for visible recipients, and simply
1230 lacks the ``Bcc:'' fields of the original draft. The second draft is destined for the
1232 blind recipients. The question then arises as to what form this latter draft posted
1237 One approach might be to disable the ``To:'' and ``cc:'' fields of the
1239 draft sent to the blind recipients (e.g., by prefixing the string ``BCC-'' to these
1241 fields). Unfortunately, this is often very confusing to the blind recipients because
1243 it differs from what the visible recipients got. Although accidental replies are not
1245 possible, it is often difficult to tell that the message received is the result of a
1250 The method used by MH is to post two drafts, a visible draft for the visible
1252 recipients, and a blind draft for the blind recipients. The visible draft consists
1254 of the original draft without any ``Bcc:'' fields. The blind draft contains the
1256 visible message as a forwarded message. The headers for the blind draft contain
1258 the minimal RFC822 headers (``From:'' and ``Date:'' ) and, if the original
1260 draft had a "Subject:" field, then this header field is also included. In addition,
1262 MH alerts the recipient that the message is a blind-carbon-copy by placing this
1264 information in the initial encapsulation information in the blind recipient's copy.
1266 This scheme prevents inadvertent replies while allowing the recipient full access to
1268 an exact copy of what was sent to the visible recipients.
1272 MH as a Record Handler
1274 Although message format standards such as RFC822 (and its predecessors)
1276 were originally devised to facilitate computer processing of interpersonal messages,
1278 there is no special reason why the concept should be limited to interpersonal
1280 message processing. Messages are just one of a variety of useful record forms that
1282 might be created in one place and transfered to another for processing. In this
1284 regard, RFC822 wisely left open the option for higher level applications to use
1286 arbitrary header names or field contents by proscribing MTS use of header names
1288 beginning with ``X-'' .
1291 MH carries though on this idea by allowing the pick command to accept any
1293 arbitrary field name for string searches, so MH users can select on any arbitrary
1295 field name without prior definition. Beyond this, since all messages are simply files
1296 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 16
1299 in UNIX directories, applications can be developed to apply any programmable
1301 process to any selected message.
1304 For example, a Time Card Form might be called up by an MH user with
1307 comp -form timecomps
1310 to enter time and attendance information into ``X-time: : ::'' fields in a draft
1312 message record. The timecomps form would include the address of a supervisor
1314 who should validate the information, along with empty fields to be filled in with
1316 data. In fancy applications, this might be done with a sophisticated interactive
1318 data entry tool which would validate entered information, but this is an open choice
1320 within the MH framework. Another alternative would be to use a received message
1322 as the blank form to add a degree of central control over time and attendance
1327 Receiving supervisors could simply register approval by using the MH dist
1329 command to resend subordinates' time cards to higher approval levels, or to send
1331 them to a time card collection address. The MH dist command automatically
1333 inserts "ReSent" header fields showing who resent it and the resending date.
1335 Alternatively, the MH forw command could be used to transfer a batch of approved
1337 time cards to the next processing station. If desired, a new "approval" command
1339 could be programmed to provide a more trusted authentication, perhaps with
1341 encryption of the content. Trusted mail systems, such as Trusted Mail6 [MRose85c],
1343 are becoming available for this purpose.
1346 At the final collection destination, an automated User Agent could be
1348 programmed to directly load the data into the Time and Attendance DBMS by
1350 parsing and decoding the data contained in the ``X-time: : ::'' fields. It might be
1352 noted that while the RFC822 does not restrict the internal forms of messages, it is
1354 necessary to conform to the interchange standard if specialized filters for message
1356 headers are not to be built to serve as export laundries (a term originating with
1358 Stephen H. Willson to describe conformance transformations in Ada7 ).
1361 Mapping Between Record Modes (DBMS/MHS)
1363 This time and attendance example suggests that it is possible to define one-to-
1365 one mappings between RFC822 fields and DBMS data elements. For every DBMS
1367 data element definition, there is a potential corresponding RFC822 transferable
1369 equivalent definition which can facilitate mail transfers of record information.
1371 Indeed, a large portion of the definitional work is already done where a Data Base
1373 has already been defined. All that remains is to define the RFC822 equivalents.
1377 ________________________________________
1378 6 Trusted Mail is a trademark of Trusted Technologies, Incorporated.
1379 7 Ada is a trademark of the Department of Defense (Ada Joint Program Office).
1380 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 17
1383 The suggestion that a batch of time cards be forwarded inside a "cover"
1385 message implies that it is possible in the MH framework to recursively bundle
1387 messages within messages, and be able to recover the originals for separate
1389 processing at a receiving destination. The MH burst command can be applied
1391 recursively for this purpose because MH encapsulation uses an unambiguous scheme
1393 to delimit messages that are enclosed inside other messages. Thus, it should be
1395 possible to extract a structured set of records from a DBMS and mail the set to a
1397 foreign site for processing, or reinsertion into another DBMS. As long as the DBMS
1399 data element definitions correctly correspond to the RFC822 definitions, it is not
1401 even necessary for the source and destination DBMS systems to be the same.
1404 From this discussion, it is concluded that the MH framework can be useful
1406 for building distributed record handling systems where people at widely scattered
1408 locations must create and submit record forms for processing at distant locations.
1410 This might prove to be especially effective when a mail system is also needed
1412 for other communication purposes. A network of sales offices is a good example,
1414 where general message service would be used for communications with remote
1416 manufacturing and distribution centers, and could also be used for an order entry
1421 Another example might be for structured communications, as occur in
1423 requisition and purchasing systems. Requisitions could be filled in and mailed to
1425 approval offices, and resent or forwarded to others for action. At some point, the
1427 requisitions could flow into other other more suitable processing systems as needed.
1429 At the very least, the ability to originate requisitions can be distributed to anyone
1431 with access to a mail system that can originate a proper requisition form.
1434 As a last example, MH already supports group discussions with its BBoard
1436 facilities which allow for automatic sorting of mail by group address, with shared
1438 private or public group access to contributed items. As has been shown to be
1440 possible with administrative record systems, there is no obvious limit to the ways
1442 that group discussion traffic might be organized into structured collections with
1444 indices, annotations, or reference pointers to aid in making conference archives
1446 more useful. Indeed, MH tools could even be used to feed discussion items into
1448 existing conference systems.
1454 Next, we consider how MH might be used in a distributed mail environment.
1456 Two schemes are discussed: one in which connectivity is high and connections
1458 are relatively "cheap", and one in which connectivity is low and connections are
1461 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 18
1464 The ARPA Internet Environs
1466 The ARPA Internet community consists of many types of heterogeneous
1468 nodes. Some hosts are large mainframe computers, others are personal work-
1470 stations. All communicate using the milstd TCP/IP protocol suite[IP, TCP].
1472 Messages which conform to the Standard for the Format of ARPA Internet Text
1474 Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
1477 On smaller nodes in the ARPA Internet it is often impractical to maintain
1479 a message transport agent. For example, a workstation may not have sufficient
1481 resources (cycles, disk space) in order to permit an SMTP server and associated
1483 local mail delivery system to be kept resident and continuously running.
1485 Furthermore, the workstation could be off-net for extended periods of time.
1487 Similarly, it may be expensive (or impossible) to keep a personal computer
1489 interconnected to an IP-style network for long periods of time. In other words, the
1491 node is lacking the resource known as "connectivity".
1494 Despite this, it is often desirable to be able to process mail with MH on
1496 these smaller nodes, and they often support a user agent to aid the tasks of mail
1498 handling. To solve this problem, a network node which can support a message
1500 transport entity (known as service host) offers a maildrop service to these less
1502 endowed nodes (known as client hosts). The Post Office Protocol[JReyn84] (POP)
1504 is intended to permit a workstation to dynamically access a maildrop on a service
1506 host to pick-up mail.8 The level of access includes the ability to determine the
1508 number of messages in the maildrop and the size of each message, as well as to
1510 retrieve and delete individual messages. More sophisticated implementations of the
1512 POP server are able to distinguish between the header and body portion of each
1514 message, and send n lines of a message to the POP client. This capability is useful
1516 in thinly connected environments where conservation of bandwidth is important.
1518 By utilizing a more intelligent POP client, a user may generate "scan listings" and
1520 dynamically decide which messages are worth taking delivery on. The philosophy
1522 of the POP is to put intelligence in the POP clients and not the POP servers.
1525 The underlying paradigm in which the POP functions is that of a split-
1527 slot/remote-UA model. The client host (such as a workstation) is without a
1529 co-resident message transport agent (MTA), and thus makes use of a service host
1531 with an MTA to obtain posting (SMTP) and delivery (POP) services. The entity
1533 which supports this type of environment is called a remote-UA since the user agent
1535 resides on a different host than its associated message transport agent.
1539 ________________________________________
1540 8 Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
1542 original description of the protocol, which suffered from certain problems. Since then, two alternate
1543 descriptions have been developed. The official revision of the POP[MButl85], and the revision of the
1544 POP which MH uses (which is documented in an internal memorandum in the MH release). This
1545 paper considers the POP in the context of the MH release.
1546 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 19
1549 One very important issue which must be raised at this point is one of
1551 authentication. The POP requires that a client identify itself to the server using
1553 a server-specific user-id and a server/user-specific password. This authentication
1555 is required to prevent unauthorized entities from accessing a maildrop on a POP
1557 service host. It must be emphasized that the POP client is not a "trusted" entity
1559 of the MTS in any sense at all.
1562 Ideally, one would also like to authenticate mail as it is posted on the POP
1564 service host using the SMTP. Currently, in the ARPA Internet community, no
1566 authentication is done with SMTP transactions. This is considered a shortcoming
1568 by those interested in researching the split-UA model of distributed mail. The
1570 MZnet environment, discussed in the next section, has authentication facilities for
1575 The current release of MH supports the above model fully: a POP client
1577 program is available to retrieve a maildrop on a POP service host. In addition,
1579 using the SMTP configuration for delivery in MH, a user is able to specify a
1581 search-list of service hosts (and networks) with which to try to post mail. Using
1583 this search-list, when an MH user posts a draft, the post program will attempt
1585 to establish an SMTP connection with each host in the list to post the message
1587 until it succeeds. Initial experimentation with the split-UA in a local network
1589 environment has proved quite successful.
1594 In 1983, the MZnet project[EStef84] at the University of California, Irvine
1596 set out to study the problems involved with bringing Internet-class mail handling
1598 facilities to personal computers. The project used Apple II computers running the
1600 CP/M 2.2 operating system. Programming was done in a subset of the C language
1602 called BDS C. The transport system was based on the MMDF PhoneNet software,
1604 and implemented a split-slot arrangement between a personal computer and a
1606 larger, centralized mail distribution system that performed user authentication and
1608 provided a relatively secure mail transfer channel. The user agent, CP/MH, was
1613 A conclusion of the experiment was that small personal computer systems
1615 with dial-up phone connections constrain user agent systems design in ways that
1617 require use of a split-slot interface between the UA and its supporting MTA, and that
1619 this interface best provides the required services if it has error controlled command
1621 and data transfer facilities, with interactive behavior. Another conclusion indicated
1623 that a good design for a user agent in such a small personal computer environment
1625 could be based on a very modular architecture, such as MH. A final conclusion was
1627 that session-level authentication of the client UA is required for both posting and
1630 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 20
1633 It should be noted that the MZnet project had a profound influence on the
1635 development of the POP used by MH. A somewhat more detailed discussion of
1637 the relations between the two environments can be found in the POP description
1639 contained in the MH release.
1645 With the fifth major release of the MH system, it has become clear that most
1647 major increases in functionality can come only at the expense of either efficiency or
1649 portability. Although there has been great effort to keep MH portable to a number
1651 of UNIX implementations,9 the divergence in process management facilities, file
1653 system enhancements, and even C compiler capabilities has already presented
1655 obstacles to some attempts to rehost the MH code.
1658 There has been some discussion of implementing specialized MH daemons
1660 that maintain context information over one or more sessions, thus decreasing the
1662 amount of overhead involved in starting each MH command. Unfortunately, even
1664 if such daemons were to be implemented, they would be very difficult to move to
1666 versions of UNIX without sophisticated process management facilities, and even
1668 then the differences in "philosophies" of process management[WJoy83, EOlse84]
1670 would tend to keep such daemons system specific. A better solution seems to be
1672 simply to tune existing code.
1678 The authors would like to thank Norman Z. Shapiro and Phyllis Kantar of
1680 the Rand Corporation for their invaluable comments during the preparation of this
1686 Distribution Information
1688 For information concerning distribution mechanics for the current release of
1695 Attn: MH Distribution
1697 Department of Information and Computer Science
1699 University of California, Irvine
1701 Irvine, CA 92717 USA
1709 ________________________________________
1710 9 As of this writing, there are approximately 75 sites running mh.5 on five different implementations
1719 [DCome83] D. Comer. The Computer Science Research Network CSnet: A
1721 History and Status Report. Communications of the ACM 26, 10
1723 (October, 1983), 747-753.
1727 [DCroc79] D.H. Crocker, E.S. Szurkowski, D.J. Farber. An Internetwork
1729 Memo Distribution Facility _ MMDF. Appearing in Proceedings,
1731 Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
1735 [DCroc82] D.H. Crocker. Standard for the Format of ARPA Internet Text
1737 Messages. Request for Comments 822. ARPA Internet Network
1739 Information Center (NIC), SRI International (August, 1982).
1743 [DKing84] D.P. Kingston, III. MMDFII: A Technical Review. Appearing in
1745 Proceedings Usenix Summer '84 Conference, Salt Lake City, Utah,
1751 [EAllm83] E. Allman. SENDMAIL _ An Internetwork Mail Router.
1753 Britton-Lee, Inc., Berkeley, California (July, 1983).
1757 [EOlse84] E.W. Olsen. NetOS Concepts and Facilities. Local Network Systems,
1759 Inc., Costa Mesa, California (August, 1984).
1763 [EStef84] E.A. Stefferud, J.N. Sweet, T.P. Domae. MZnet: Mail Service for
1765 Personal Micro-Computer Systems. Appearing in Proceedings, Second
1767 International Symposium on Computer Message Systems, Nottingham,
1769 U.K, 1984, pp. 293-302.
1773 [FIPS98] Specification for Message Format for Computer Based Message
1775 Systems. National Bureau of Standards (January, 1983).
1779 [HERMES] Bolt, Beranek, and Newman. Hermes User's Manual. for TOPS-20.
1781 Bolt, Beranek, and Newman, Boston, MA (January, 1979).
1785 [IP] Internet Protocol. Request for Comments 791 (milstd 1777).
1787 Appearing in Internet Protocol Transition Workbook, ARPA Internet
1789 Network Information Center (NIC), SRI International, 1981.
1793 [JReyn84] J.K. Reynolds. Post Office Protocol. Request for Comments 918.
1795 ARPA Internet Network Information Center (NIC), SRI International
1801 Copyright fcl1985, North Holland Publishing Company 21
1802 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 22
1805 [MButl85] M. Butler, J.B. Postel, et. al. Post Office Protocol - Version 2.
1807 Request for Comments 937. ARPA Internet Network Information
1809 Center (NIC), SRI International (February, 1985).
1813 [MRose84a] M.T. Rose. The Rand MH Message Handling System: The UCI
1815 BBoards Facility. Department of Computer and Information Sciences,
1817 University of Delaware (October, 1984).
1821 [MRose84b] M.T. Rose. The Rand MH Message Handling System: Tutorial.
1823 Department of Computer and Information Sciences, University of
1825 Delaware (October, 1984).
1829 [MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
1831 User's Manual. UCI Version. Department of Information and Computer
1833 Science, University of California, Irvine (January, 1985).
1837 [MRose85b] M.T. Rose, E.A. Stefferud. Proposed Standard for Message
1839 Encapsulation. Request for Comments 934. ARPA Internet Network
1841 Information Center (NIC), SRI International (January, 1985).
1845 [MRose85c] M.T. Rose, D.J. Farber, S.T. Walker. Design of the TTI Prototype
1847 Trusted Mail Agent. Appearing in Proceedings, Second International
1849 Symposium on Computer Message Systems, Washington, D.C., 1985
1855 [SMTP] Simple Mail Transfer Protocol. Request for Comments 821. ARPA
1857 Internet Network Information Center (NIC), SRI International
1863 [TCP] Transmission Control Protocol. Request for Comments 793 (milstd
1865 1778). Appearing in Internet Protocol Transition Workbook, ARPA
1867 Internet Network Information Center (NIC), SRI International, 1981.
1871 [WJoy83] W.N. Joy, E. Cooper, R.S. Fabry, S.J. Leffler, K. McKusick,
1873 D. Mosher. 4.2bsd System Manual. Technical Report Number 5.
1875 Computer Systems Research Group, University of California, Berkeley.
1879 [X.400] Message Handling Systems: System Model-Service Elements,
1881 Recommendation X.400, International Telegraph and Telephone
1883 Consultative Committee (CCITT).
1892 MH is composed of several UNIX programs, which in theory are fairly simple
1894 and single-purposed. These commands are functionally grouped below:
1897 Composing_Mail__________
1899 comp: compose a message
1901 A program to originate a message. Usually, a special prompting editor front-
1903 end, prompter, is used to fill-in a composition template with the addressees
1905 of the message, subject, and so forth.
1908 dist : redistribute a message to additional addresses
1910 A program that re-enters a message previously received by the user into the
1912 message transport system. Only new addresses are added; the body of the
1914 message is not changed in any way.
1917 forw : forward messages
1919 A program that encapsulates one or more messages in a new message draft.
1921 In addition, the user may add initial and/or closing comments.
1924 repl : reply to a message
1926 A program that constructs a reply to a message using a reply template. The
1928 template mechanism has sufficient generality to permit the user to "program"
1930 the form of the reply draft based on the contents of the message being
1935 send : send a message
1937 A program that posts a draft with the message transport system. The
1939 send program is usually invoked by one of the four preceding programs, and
1941 performs simple front-end pre-processing prior to invoking the post program.
1943 For example, if invoked in push'd mode, send will immediately relinquish
1945 control of the user's terminal and post the message in the background. If
1947 the posting fails, send will send back a failure notice to the user. If the user
1949 had push'd the sending of the draft, then by default the draft being sent is
1951 encapsulated in the failure notice. This permits easy burst'ing of the failure
1953 notice to retrieve the original draft. Otherwise, if the posting was successful,
1955 the draft is marked as having been sent.
1958 whatnow : prompting front-end for send
1960 A program which is called by comp, et. al., after the initial draft has been
1964 Copyright fcl1985, North Holland Publishing Company 23
1965 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 24
1968 generated. The MH user can specify a different whatnow program, which
1970 yields considerable extensibility.
1973 whom: report to whom a message would go
1975 A program which examines the addresses of the draft and expands all user-
1977 defined aliases contained therein. Optionally, whom may actually interact
1979 with the message transport system to determine the validity of the final
1981 addresses. This program is also usually invoked by comp, et. al.
1986 ali : list mail aliases
1988 A simple front-end to the MH aliasing mechanism.
1991 ap: parse addresses 822-style
1993 A useful debugging tool for PostMasters who wish to examine how MH
1995 interprets an Internet address.
1998 conflict : search for alias/password conflicts
2000 Another program used by system administrators to check the consistency of
2002 MH alias files, and portions of the local message transport agent.
2005 install-mh: initialize the MH environment
2007 A program which is automatically executed the first time a user issues an MH
2009 command. This program performs once-only initialization of the user's MH
2014 mhmail : send or read mail
2016 A simple program generally used by other programs to generate messages.
2018 The mhmail command is similar in purpose to the old BellMail program.
2021 post : deliver a message
2023 A complex MH back-end that interacts with the local message transport
2025 agent to enter messages through the posting slot. (See the description of send
2030 Reading_Mail________
2032 inc: incorporate new mail
2034 A program that interacts with the local message transport agent to retrieve
2036 messages from the user's maildrop.
2039 msgchk : check for waiting mail
2041 A program which reports the status of mail waiting in the user's maildrop.
2044 show : show (list) messages
2046 A program which lists messages to its standard output (usually the user's
2048 terminal), possibly invoking another program to do the actual listing. Most
2050 users of MH have show automatically call the mhl program to format the
2051 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 25
2054 message. The next and prev programs are simply ``show next'' and
2056 ``show prev'' , respectively.
2059 mhl : produce formatted listings of MH messages
2061 A program which displays a message as directed by a template. This permits
2063 the user to filter out uninteresting headers and re-arrange other headers to a
2065 particular preference. In addition to being invoked by show, the mhl program
2067 is optionally also invoked by forw to format each message being forwarded;
2069 invoked by repl to format the body of a message being replied-to, if that
2071 message is being included in the reply draft; and, invoked by post to format
2073 a message being sent as a blind-carbon-copy.
2076 rmm: remove messages
2078 A program that removes messages from an MH folder, optionally running a
2080 user-defined program instead of deleting them. If no program is given, the
2082 messages are "softly" removed, so they may possibly be recovered later.
2085 scan: produce a one-line-per-message scan listing
2087 A program that generates a scan listing for messages. Each line of the listing
2089 contains date, source, subject, and possibly the initial body of the message.
2092 Folder_Handling________
2094 folder : set/list current folder/message
2096 A program used to list information concerning the current folder, or set the
2098 current folder and/or message.
2101 folders : list all folders
2103 A program to list information on all folders (actually, just a special case of
2105 the folder command). Since the MH folder structure may be recursive, the
2107 user can indicate that folders should recursively examine all folders.
2110 refile: file message(s) in (an)other folder(s)
2112 A program to move (or copy) messages from a source folder to one or more
2114 destination folders.
2119 A program that deletes a folder and all messages therein.
2122 Message_Selection_________
2124 anno: annotate messages
2126 A program to arbitrarily annotate messages. If the user so desires, after
2128 distributing, forwarding, or replying-to a message, MH will automatically
2130 attach an annotation to the original message indicating the date and addresses.
2133 mark : mark messages
2135 A program to manipulate user-defined sequences (lists of messages). Usually,
2137 mark is not employed directly by the MH user.
2138 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985 26
2141 pick : select messages by content
2143 A program to examine a list of messages and choose those which meet
2145 a particular selection criterion. The pick program is often used in UNIX
2147 back-quoted operations to pass message sequences to other MH commands.
2150 sortm: sort messages
2152 A program to sort a list of messages according to the date given in a particular
2157 Distribution_List_Handling____________
2159 bbc: check on BBoards
2161 A front-end to run msh on a list of distribution lists which the user isn't
2166 bbl : manage a BBoard
2168 A (depreciated) program used to manually manage the local archives of
2170 a distribution list. These functions (archiving, expunging) are performed
2172 automatically by MH.
2175 burst : explode digests into messages
2177 A program used to decapsulate messages from ARPA Internet digests. In
2179 addition, messages which have been encapsulated during forwarding (i.e.,
2181 with forw ) can also be decapsulated using burst.10
2184 msh: MH shell (and BBoard reader)
2186 A monolithic program used to implement MH commands on messages
2188 arranged in a single file (maildrop format). Useful since distribution lists are
2190 kept in this format to minimize consumption of system resources.
2193 pack : compress a folder into a single file
2195 A program which takes messages stored in MH format and places them in a
2197 single file (using the same format known by msh).
2200 Interface_to_the_UNIX_File_System________________
2202 mhpath: print full pathnames of MH messages and folders
2204 A program which maps MH-style names into the UNIX file naming convention.
2208 ________________________________________
2209 10 Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
2222 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*
2225 The MH Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2227 The MH Environs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2229 The MH Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2231 Folders and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2233 The Context File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2235 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2238 Explaining All This to New Users . . . . . . . . . . . . . . . . . . . . . . . 7
2240 A Few Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2242 Draft Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2245 Message Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2247 Distribution Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2249 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2252 Encapsulation and Blind-Carbon-Copies . . . . . . . . . . . . . . . . . . . 14
2254 MH as a Record Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2256 Mapping Between Record Modes (DBMS/MHS) . . . . . . . . . . . . . . 16
2258 Distributed Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2261 The ARPA Internet Environs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2263 The MZnet Environs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2265 A Final Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2268 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2270 Distribution Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2272 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2275 Appendix A: MH Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2279 ________________________________________
2280 This document (version #1.54) was TEXset April 12, 1990 with DISS.STY v103.
projects / mmh / blob