7 How to process 200 messages a day
9 and still get some real work done./
14 Member, Research Technical Staff
16 Northrop Research and Technology Centery
22 Computing Support Group
24 Department of Information and Computer Science
26 University of California, Irvinez
33 The UCI version of the Rand Message Handling System (MH) is dis-
35 cussed. MH is a powerful user agent which operates in the ARPA Internet
37 and UUCP environments. In addition to the usual functions provided
39 by similar programs, MH has several distinguishing characteristics which
41 give the user additional message handling capability. In particular, MH
43 provides mechanisms for maintaining an organized mail environment,
45 tailoring its behavior, and extending its functions.
48 This document describes MH from several perspectives. Particular em-
50 phasis is given to: the MH user environment, advanced features of MH
52 which have proven to be particularly useful for sophisticated users of
54 electronic mail, the user interface issues in MH, and the mh.5 distribu-
56 tion. The paper concludes with a summary of the authors' experiences
58 with MH, and a discussion of future areas of enhancement.
62 _____________________________________
63 ./ Alternate title: MH: Your Key to Success.
64 y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
66 Computer mail: MRose% NRTC@USC-ECL, : : :!fucbvax!ucivax,trwrbg!nrtc!mrose.
67 z University of California at Irvine, Irvine, CA 92717. Telephone: 714/856-6852.
69 Computer mail: J-Romine@USC-ECL, : : :!fucbvax,trwrbg!ucivax!jromine.
74 How to process 200 messages a day
76 and still get some real work done
82 The UCI version of the Rand Message Handling System, MH, is a software
84 system that performs two functions: first_, it interfaces a user to a message
86 transport system, so the user may receive and send mail; second___, it permits the
88 user to maintain an organized mail environment to facilitate the composition of
90 new messages and the reading of old messages. In short, while not responsible for
92 the delivery of messages, MH aids the user in handling mail.
95 MH was originally developed by the Rand Corporation, and initially was
97 proprietary software. The Department of Information and Computer Science
99 at University of California, Irvine, shortly after joining the Computer Science
101 Network (CSnet), acquired a copy of MH, and began additional development of
103 the software. Since that time, the Rand Corporation has declared MH to be in the
105 public domain, and the UCI version of MH has passed through four major releases.
107 The current version, mh.5, is available from U.C. Irvine for a nominal distribution
109 fee, or may be retrieved from the University of Delaware via anonymous FTP.
112 Much credit must be given to the initial designers and implementors of MH:
114 Bruce Borden, Stockton Gaines, and Norman Shapiro. Although MH has suffered
116 significant development at UCI since Rand's initial release, the fundamental
118 concepts of MH's environs have remained nearly unchanged. In addition, the
120 authors of the current release gratefully acknowledge the comments of the many
122 sites which have run various releases of MH in the past. In particular, the dozen
124 or so beta test sites for mh.5 provided tremendous help in stabilizing the current
129 MH runs on different versions of the UNIX1 operating system (such as
131 Berkeley 4.2bsd and various flavors of v7). In addition, MH supports four
133 different message transport interfaces: SendMail[EAllm83], the standard mailer
135 for 4.2bsd systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel
137 Memo Distribution Facility developed by the University of Delaware which forms
139 the software-backbone for CSnet[DCome83] mail relay service; SMTP, the ARPA
141 Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
145 _____________________________________
146 1 UNIX is a trademark of AT&T Bell Laboratories.
151 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 2
154 This paper is organized in a straight-forward fashion: Initially, the MH
156 philosophy of mail handling is presented, along with a description of the
158 environment which the MH user is given to process mail. Following this, certain
160 advanced features of MH are discussed in more detail, such as facilities for selecting
162 messages, and "advanced" concepts in draft handling. In addition, user interface
164 issues in mail handling are addressed, and the merits of MH's approach is critically
166 examined. Next, the mh.5 distribution package is described. Finally, we conclude
168 by discussing the authors' experience with MH development and introducing areas
170 where MH may be further developed.
173 Although familiarity with MH is not assumed on the part of the reader,
175 some knowledge of the UNIX operating system is useful. Appendix A gives a short
177 synopsis of the MH commands.
183 Although MH has many traits which tend to distinguish it from other systems
185 which handle mail, there is a single fundamental design decision which influences
187 the interface between MH and the user: MH differs from most other systems in
189 that it is composed of many small programs instead of one very large one. This
191 architecture gives MH much of its strength, since intermediate and advanced users
193 are able to take advantage of this flexibility.
196 The key to this flexibility is that the UNIX shell (usually the C shell or the
198 Bourne shell), is the user's interface to MH. This means that when handling mail,
200 the entire power of the shell is at the user's disposal, in addition to the facilities
202 which MH provides. Hence, the user may intersperse mail handling commands
204 with other commands in an arbitrary fashion, making use of command handling
206 capabilities which the user's shell provides.
209 Furthermore, rather than storing messages in a complicated data structure
211 within a monolithic file, each message in MH is a UNIX file, and each folder (an
213 object which holds groups of messages) in MH is a UNIX directory. That is,
215 the directory- and file-structure of UNIX is used directly. As a result, any UNIX
217 file-handling command can be applied to any message.
220 To the novice, this may not make much sense or may not seem important.
222 However, as users of MH become more experienced, they find this capability
224 attractive. In addition, this approach is often quite pleasing to system implemen-
226 tors, because it minimizes the amount of coding to be performed, and given a
228 modular design, changes to the software system can be maintained easily. There
230 are, however, performance penalties to be paid with this scheme. This issue is
232 considered later in the paper.
235 Having described how MH fits into the UNIX environment, we now discuss
237 the mail handling environment which is available to the MH user.
238 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 3
243 In the $ HOME directory of each MH user, a file named .mh_profile contains
245 static information about the user's MH environment, and default arguments for
247 MH programs. For the latter case, each line of profile takes the form:
250 program-name: options
253 Each MH program consults the user's .mh_profile for its options. These options
255 are consulted prior to evaluating any command-line arguments, and so provide the
257 MH user the capability to customize the defaults for each command. Futher, by
259 using the UNIX link facility, different names can be given to the same command.
261 Since each MH command looks in the .mh_profile for a component with the name
263 by which it was invoked, it's possible to have different defaults for the same
265 program. For example, it is not uncommon to link prompter (a simple prompting
267 editor front-end) under the name rapid in the user's bin/ directory, and add to the
272 rapid: -prepend -rapid
275 As a result, when prompter is invoked as rapid, it automatically uses the `-prepend'
277 and `-rapid' options.
280 The profile component ``Path:'' is the path to the user's MH-directory,
282 usually Mail. In addition to containing the user's folders, the MH-directory also
284 contains skeletons and templates used by the MH programs, and the user's context
286 file. This latter file has the same format as the user's .mh_profile , and contains the
288 dynamic, context-dependent information about the user's environment. Whenever
290 MH looks for an MH-specific file, such as a template or skeleton, it first consults
292 the user's MH-directory, and then a system-wide library area.
295 The MH user always has a current folder, which is the folder in which the user
297 is currently (or was last) working. Since any MH program which deals with folders
299 implicitly manipulates this information, the name of the current folder is stored in
301 the context component ``Current-Folder:'' . Every folder has a current message
303 known as `cur' . These values are the defaults for MH commands which accept
305 folder and/or messages arguments.
308 MH programs make use of a set of envariables which further customize their
310 behavior. The $ MH envariable, if present, specifies the name of an alternate profile
312 for the user. This allows a user of MH to easily maintain multiple mail-handling
317 In terms of command syntax, most MH commands accept an optional folder
319 argument, such as `+outbox' . Unlike most UNIX commands, all MH commands
321 have switches which are words, rather than single letters. Switches may be
323 abbreviated to the least unambiguous prefix. All MH commands also support
324 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 4
325 _______________________________________________________________________________________________________________
328 2 Incorporating new mail into inbox...
330 4 1+ 03/16 Rand MH System MH transcript <<Here's the body of a sample m
334 8 To: jromine@uci-icsa
335 9 Subject: MH transcript
336 10 Date: 16 Mar 85 18:28:59 PST (Sat)
337 11 From: Rand MH System <mh@uci-icsa>
339 13 Here's the body of a sample message.
341 15 To: Rand MH System <mh@uci-icsa>
342 16 cc: jromine@uci-icsa
343 17 Subject: Re: MH transcript
344 18 In-reply-to: Your message of 16 Mar 85 18:28:59 PST (Sat).
346 20 Thanks for the test.
355 29 Subject: sample comp
357 31 Here's a sample compose for the MH transcript.
362 36 What now? send -verbose
363 37 -- Posting for All Recipients --
364 38 -- Local Recipients --
366 40 -- Recipient Copies Posted --
372 _____________________________________________An_MH_Session_____________________________________________________
376 a `-help' switch, which lists the syntax of the command along with available
378 switches, and the version number of the command. Most MH commands also take
380 a `msg' or `msgs' argument which takes the form of a message number (``1'' ), a
382 message range (``1-2'' ), a standard sequence name (``cur'' ), or a user-defined
384 sequence name (``select'' ).
385 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 5
390 Figure 1 contains a transcript of a simple MH session. First, inc is run to
392 incorporate the new mail into the user's ``+inbox'' folder.
395 A scan listing of the mail is printed while it is being incorporated. (The
397 user could run scan explicitly to generate additional scan listings later on.) The
399 scan listing gives the message number, followed by the date, message sender,
401 and subject. (If the message originated from the user generating the listing, the
403 ``to:'' addressee is displayed instead of the sender.) If the subject is short, the
405 first part of the message body is displayed after the characters ``<<'' . The plus
407 sign (`+') after the message number indicates the current message.
410 The user show s the message, and decides to repl y. A reply draft is created
412 using the headers of the message being replied-to, using the default replcomps
414 template. The default editor, prompter, is called to edit the draft. When an
416 EOT is typed, prompter exits and the user is left at the What now? prompt. The
418 option send is chosen. Since there were no problems in posting the draft with the
420 message transport system, no additional output is produced. (MH is not verbose
425 The user then decides to compose a new message. The default skeleton,
427 components , is copied to the draft, and prompter is once again called. After
429 entering the addresses, subject, and body, the user then send s the draft from the
431 What now? prompt, using ``send -verbose'' , which causes MH to list out the
433 message addresses as it submits them to the message transport system.
439 We now consider certain advanced features in MH. These features have been
441 chosen to demonstrate some useful capabilities available to the MH user.
444 Message Sequences and Selection
446 MH has several built-in message sequence names, which may be used
448 anywhere a `msg' or `msgs' argument is expected. These are: `cur' , `next' ,
450 `prev' , `first' , `last' , and `all' . Message ranges may also be specified. For
452 example, `all' is actually `first-last' , and `+mh last:5' references the last
454 five messages in your `+mh' folder. A powerful capability of MH is the ability to use
456 not only the pre-defined message sequence names, but also arbitrary user-defined
458 message sequence names.
461 Although all MH programs recognize user-defined sequences when appropriate,
463 the pick and mark commands can create and modify user-defined message
465 sequences. The mark command allows low-level manipulation of sequences, and is
467 not particularly interesting in our discussion.
470 The pick command selects certain messages out of a folder. The criteria used
472 for selection may be a search string and/or a date range.
473 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 6
476 Searching is performed on either a specific header in the message (e.g.,
478 ``To:'' ), or anywhere within the message. By default, pick lists out the message
480 numbers that matched the selection criteria. Thus, pick is useful in backquoted
482 operations to the shell. For example, to scan all the messages in the current folder
484 from "frated", the MH user issues the command:
487 scan `pick -from frated`
490 To perform more complicated message selection, user-defined sequences are
492 employed. Supplying a `-sequence name' argument to pick, will cause it to define
494 the sequence `name' as those messages matched.
497 Giving pick a list of messages causes it to limit its search to just those
499 messages. For example, to find all the messages in the current folder from "frated"
501 also dated before friday:
504 pick -from frated -sequence select
506 pick select -before friday -sequence select
509 With the first pick command, the sequence ``select'' is defined to be all those
511 messages from "frated". In the second command, only those messages already in
513 the ``select'' sequence are searched, and the ``select'' sequence is redefined
515 to be only those messages which are also dated before friday. Those messages could
523 When a `-sequence name' argument is given to pick, the default behavior _
525 listing the message numbers matched _ is inhibited. To re-enable this behavior,
527 the `-list' option may be given. As a result, advanced users of MH often put the
529 following line in their .mh_profile :
532 pick: -sequence select -list
535 which allows them to easily make use of the `select' sequence as the messages
537 last selected with pick.
540 Often it is desirable to act upon those messages which are not members of
542 a given sequence. For this purpose, the ``Sequence-Negation:'' profile entry
544 is useful. If the name of a user-defined sequence is prefixed with the value of the
546 sequence-negation profile entry, MH commands will operate upon those messages
548 which are not members of that sequence. For example, given a profile entry of:
551 Sequence-Negation: not
554 those messages which are not in the `select' sequence could be scan'd with:
558 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 7
561 Obviously, some confusion could result if an attempt was made to define a se-
563 quence name which began with the sequence-negation string (e.g., ``notselect'' ).
565 For this reason, MH users will often use a single character, which their shell doesn't
567 interpret, as their sequence-negation string (e.g., up-caret (`^') for C Shell users,
569 and exclamation-mark (`!') for Bourne shell users).
572 MH also provides a way of automatically remembering the last message list
574 given to an MH command. This facility is implemented by using a profile entry
576 called ``Previous-Sequence:'' .
581 After the initial edit of a message draft, the comp, dist, forw, and repl
583 programs give the user a What now? prompt. The valid responses include: edit to
585 re-edit the draft, quit to exit without sending the draft, send to send the draft, and
587 push to send the draft in the background.
590 When the send option is given, the draft is posted with the message transport
592 system. If there problems posting the draft, the What now? prompt is re-issued, so
594 errors in the draft may be corrected.
597 Since posting the draft can be slow, the push option allows the MH user to
599 send the draft in the background, and return immediately to the shell. If there are
601 problems posting the message, the user will not see the diagnostics produced by
603 the message transport system. For this reason, if push is used instead of send, and
605 the message is not successfully posted, MH mails a message to the user containing
607 any diagnostics which the message transport system produced along with a copy
609 of the message. Later, the draft may be re-edited by entering ``comp -use'' .
612 A relatively new feature of MH is the ability to use a folder to store multiple
614 drafts. These drafts are kept in an ordinary MH folder, and may be operated upon
616 by MH commands. To enable this feature, the MH user selects a folder-name for
618 the draft-folder, and creates an entry in the .mh_profile :
621 Draft-Folder: +foldername
624 From this point on, when a message is composed, the draft will be created as a
626 message in that folder, instead of using the draft file in the user's MH directory.
628 Unfortunately, if posting problems occur on a message which has been push'd, it
630 may be difficult to re-edit the draft with ``comp -use'' . This might be the case
632 if the user had started composing another message, while that first draft was being
634 posted. In that event, the current-message in the draft-folder would no longer
636 point to the failed draft.
639 There is a solution for this problem, however. By default, push assumes the
641 `-forward' option, which says that if the message draft fails to be posted, it
642 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 8
645 should be forwarded back to the user in the error report which push generates.
647 The failed draft may then be extracted with the burst program (discussed later).
652 MH has a convenient interface to the UCI BBoards facility[MRose84a].2 This
654 facility permits the efficient distribution of interest group messages on a single
656 host, to a group of hosts under a single administration, and to the ARPA Internet
661 Although most readers are probably familiar with the concept of an interest
663 group in the Internet context, a brief description is now given. Observant readers
665 will notice that the distributed nature of the "network news" (a.k.a. USENET)
667 tends to avoid many of the problems described below.
670 Described simply, an interest group is composed of a number of subscribers
672 with a common interest. These subscribers post mail to a single address, known
674 as the distribution address (e.g., MH-Workers@UCI. From this distribution address,
676 a copy of the message is sent to each subscriber. Each group has a moderator,
678 who is the person that runs the group. This moderator can usually be reached at
680 a special address, known as the request address (e.g., MH-Workers-Request@UCI).
682 Usually, the responsibilities of the moderator are quite simple, since the mail
684 system handles distribution to subscribers automatically. In some interest groups,
686 instead of each separate message being distributed directly to subscribers, a batch
688 of (hopefully related) messages are put into a digest format by the moderator and
690 then sent to the subscribers. (This is similar to a newsletter format.) Although
692 this requires more work on the part of the moderator and introduces delays, such
694 groups tend to be better organized.
697 Unfortunately, some problems arise with the scheme outlined above. First,
699 if two users on the same host subscribe to the same interest group, two copies of
701 the message are delivered. This is wasteful of both processor and disk resources at
706 Second, some groups carry a lot of traffic. Although subscription to a group
708 does indicate interest on the part of a subscriber, it is usually not interesting to get
710 50 or so messages delivered each day to the user's private maildrop, interspersed
712 with personal mail, which is likely to be of a much more important and timely
717 Third, if a subscriber's address in a distribution list becomes "bad" somehow
719 and causes failed mail to be returned, the originator of the message is normally
721 notified. It is not uncommon for a large list to have several bogus addresses. This
723 results in the originator being flooded with "error messages" from mailers across
726 _____________________________________
727 2 The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
729 form under stand-alone MH.
730 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 9
733 the Internet stating that a given address on the list was bad. Needless to say, the
735 originator usually does not care if the bogus addresses got a copy of the message
737 or not. The originator is merely interested in posting a message to the group at
739 large. On the other hand, the moderator of the group does care if there are bogus
741 addresses on the list, but ironically does not receive notification.
744 To solve these problems, the UCI BBoards facility introduces a new entity
746 into the picture: a distribution channel. All interest group mail is handled by the
748 special mail system component. The distribution address for an interest-group
750 maps mail for that interest-group to the distribution channel, which then performs
752 several actions. First, if local delivery is to be performed, a copy of the message is
754 placed in a global maildrop for the interest group with a timestamp and a unique
756 number. Local users can read messages posted for the interest group by reading
758 this "public" maildrop. Second, if further distribution is to take place, a copy of
760 the message is sent to the distribution address in such a way that if any of the
762 addresses are bogus, failure notices will be returned to the local maintainer of the
764 group address list, rather than the originator of the message.
767 This scheme has several advantages: First, messages delivered to the local
769 host are processed and saved once in a globally accessible area. The UCI BBoards
771 facility supports software which allows a user to query an interest group for new
773 messages and to read and process those messages in the MH-style. Second, once
775 a host administrator subscribes to an interest group, each user may join or quit
777 the list's readership without contacting anyone. Third, a hierarchical distribution
779 scheme can be constructed to reduce the amount of delivery effort. Finally, errors
781 are prevented from propagating. When an address on the distribution list goes
783 bad, the list moderator who is responsible for the address is notified. If a local
785 moderator does not exist, then the local PostMaster is notified (not the global
790 In addition to solving the problems outlined above, the UCI BBoards facility
792 supports several other capabilities. BBoards may be automatically archived in
794 order to conserve disk space and reduce processing time when reading current
796 items. Also, the archives can be separately maintained on tape for access by
798 interested researchers.
801 Special alias files may be generated which allow the MH user to shorten
803 address entry. For example, instead of sending to SF-Lovers@Rutgers, a user of
805 MH usually sends to ``SF-Lovers'' and the MH aliasing facility automatically
807 makes the appropriate expansion in the headers of the outgoing message. Hence,
809 the user need only know the name of an interest group and not its global network
812 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 10
815 Finally, the UCI BBoards facility supports private interest groups using the
817 UNIX group access mechanism. This allows a group of people on the same or
819 different machines to conduct a private discussion.
822 The practical upshot of all this is that the UCI BBoards facility automates the
824 vast majority of BBoards handling from the point of view of both the PostMaster
829 MH provides three programs to deal with interest groups. The bbc program
831 is used to check on the status of one or more groups, and to optionally start an
833 MH shell on those groups which the user is interested in. The bbl program can be
835 used to manually perform maintenance on a discussion group beyond the normal
837 automatic capabilities of the UCI BBoards facility. Finally, the msh program
839 implements an MH shell for reading BBoards, in which nearly all of the MH
841 commands are implemented in a single program.
844 Observant readers may note that the use of msh is contrary to the MH
846 philosophy of using relatively small, single-purpose programs. Sadly, the authors
848 admit that this is true. In an effort to minimize use of system resources however,
850 BBoards are kept in maildrop format instead of folders.3 Some research has gone
852 into overcoming this problem to restore MH's purity of purpose, but all solutions
854 proposed to date are either unworkable or require significant recoding of MH's
861 Internet interest group mail is often sent out in digest form. The experienced
863 MH user may wish to deal with the digest messages on an individual basis, however.
865 The burst program allows the MH user to extract these digest messages, and store
867 each as an individual MH message.
870 Burst will also extract forwarded messages generated by forw (or the forwarded
872 message in the error report generated by push, as described above). Although
874 burst cannot always decapsulate messages encapsulated by sites not running MH,
876 it adheres to the proposed standard described in [MRose85b].
880 _____________________________________
881 3 When the message transport system delivers a message to a user it stores it in a single file, called
883 a maildrop. Since many messages may be present in a single maildrop, (in theory) there is a unique
884 string acting as a separator between messages in the maildrop. Although this is convenient for
885 storage of messages, it makes retrieval more difficult unless a separate index into the maildrop is
886 kept. This latter approach is taken by the msg program available with MMDF-II and by msh as well.
887 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 11
892 The ARPA Internet community consists of many types of heterogeneous
894 nodes. Some hosts are large mainframe computers, others are personal work-
896 stations. All communicate using the milstd TCP/IP protocol suite[IP, TCP].
898 Messages which conform to the Standard for the Format of ARPA Internet Text
900 Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
903 On smaller nodes in the ARPA Internet, it is often impractical to maintain
905 a message transport system (e.g., SendMail). For example, a workstation may not
907 have sufficient resources (cycles, disk space) in order to permit an SMTP server
909 and associated local mail delivery system to be kept resident and continuously
911 running. Furthermore, the workstation could be off-net for extended periods of
913 time. Similarly, it may be expensive (or impossible) to keep a personal computer
915 interconnected to an IP-style network for long periods of time. In other words, the
917 node is lacking the resource known as "connectivity".
920 Despite this, it is often desirable to be able to manage mail with MH on
922 these smaller nodes, and they often support a user agent to aid the tasks of mail
924 handling. To solve this problem, a network node which can support a message
926 transport entity (known as service host) offers a maildrop service to these less
928 endowed nodes (known as client hosts). The Post Office Protocol[JReyn84] (POP)
930 is intended to permit a workstation to dynamically access a maildrop on a service
932 host to pick-up mail.4 The level of access includes the ability to determine the
934 number of messages in the maildrop and the size of each message, as well as to
936 retrieve and delete individual messages. More sophisticated implementations of the
938 POP server are able to distinguish between the header and body portion of each
940 message, and send n lines of a message to the POP client. This capability is useful
942 in thinly connected environments where conservation of bandwidth is important.
944 By utilizing a more intelligent POP client, a user may generate "scan listings" and
946 decide dynamically which messages are worth taking delivery on. The philosophy
948 of the POP is to put intelligence in the POP clients and not the POP servers.
951 The current release of MH supports the above model fully. A POP client
953 program is available to retrieve a maildrop from a POP service host. In addition,
955 using the SMTP configuration for delivery in MH (either in conjunction with
957 SendMail or the MMDF), a user is able to specify a search-list of service hosts
959 (and/or networks) to try to post mail. Using this search-list, when an MH user
961 posts a draft, the post program will attempt to establish an SMTP connection
963 with each host in the search-list to post the message until it succeeds. Initial
966 _____________________________________
967 4 Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
969 original description of the protocol, which suffered from certain problems. Since then, two alternate
970 descriptions have been developed. The official revision of the POP[MButl85], and the revision of the
971 POP which MH uses (which is documented in an internal memorandum in the MH release). This
972 paper considers the POP in the context of the MH release.
973 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 12
976 experimentation using the POP and MH in a local network environment has
978 proved quite successful.
982 User Interface Issues in MH
984 At this point, it is perhaps useful to take a step backwards and examine the
986 success and problems of MH's approach to user interfaces.
991 A complaint often heard about systems which undergo substantial develop-
993 ment by many people over a number of years, is that more and more options are
995 introduced which add little to the functionality but greatly increase the amount of
997 information a user needs to know in order to get useful work done. This is usually
999 referred to as creeping featurism.
1002 Unfortunately MH, having undergone six years of off-and-on development by
1004 ten or so well-meaning programmers (the present authors included), suffers mightily
1006 from this. For example, the send command has twenty-five visible switches, and at
1008 least nine hidden switches, for a total of thirty-four. The poor user who types
1014 watches the options scroll off the screen (since the `-help' switch also lists out
1016 four other lines of information).5 The sad part is that all of these switches are
1018 useful in one form or another.
1021 There are a lot of good things to be said for the "one program, one function"
1023 philosophy of system design. In the MH case, however, each program really does
1025 only one mail handling activity (with a few minor exceptions). The options
1027 associated with each command are present to modify the program's behavior to
1029 perform similar, but slightly different tasks. In further defense of MH, note that
1031 there are 32 MH commands at present, all performing different tasks.
1034 The problem with creeping featurism though, is that while the functionality
1036 of the system increases sub-linearly, the complexity of the system increases linearly.
1038 That is, although the number of switches that a program takes might double, it is
1040 unlikely that the program's functionality or capabilities will double.
1044 _____________________________________
1045 5 Recently, this was fixed by compressing the way in which switches are presented. The solution is
1047 only temporary however, as send will no doubt acquire an endless number of switches in the years
1049 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 13
1050 _______________________________________________________________________________________________________________
1064 ______________________________________________Draft_Skeleton___________________________________________________
1066 _______________________________________________________________________________________________________________
1069 cc: <?to_cc><to>,<cc>
1072 Subject: <?subject>Re: <subject>
1073 In-reply-to: <?date><?message-id>Your message of <date>.
1075 In-reply-to: <?date><!message-id>Your message of <date>.
1081 _____________________________________________Reply_Template____________________________________________________
1085 Templates versus Switches
1087 One way to trim the explosion of available options, while still increasing
1089 functionality, is to introduce options with a richer domain. Hence, instead of using
1091 options which take on or off forms or simple numeric or string values, the possible
1093 values which an option might take on is given a large space. There are several ways
1095 that this might be accomplished.
1098 The comp, dist, and forw programs use draft skeletons (simple form fill-in
1100 files) to construct the general format of the draft being composed. An example of
1102 a draft skeleton used for composing new messages (by comp) is shown in Figure 2.
1104 The approach is to let the user specify (and later edit) both arbitrary headers of
1106 draft and the body of the draft. Note while most of the fields are empty, the first
1108 ``Fcc:'' field already contains a value. By using the simple prompting editor,
1110 prompter, the user can speedily enter the headers of the message. The prompter
1112 program given the skeleton in Figure 2 would prompt the user for the contents
1114 of each field, except for the second ``fcc:'' , which it would include verbatim.
1116 It would then read the body of the message up to an end-of-file. Naturally, the
1118 MH user is free to use any editor to edit any part of the draft (headers or body).
1120 This example demonstrates the flexibility achieved by not limiting what headers a
1122 draft may contain (which most mail sending programs do), while still retaining the
1124 simplicity of being able to treat the entire message draft as a UNIX file.
1125 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 14
1126 _______________________________________________________________________________________________________________
1128 From: <?me>Message Agent "<<me>>
1132 Subject: <?subject>BEEP! Re: <subject>
1133 Subject: <!subject>BEEP!
1134 In-reply-to: <?date><?message-id>Your message of <date>.
1136 In-reply-to: <?date><!message-id>Your message of <date>.
1140 This is an automatic reply. Feel free to send additional mail, as only
1141 this one notice will be generated.
1144 I am attending the USENIX Summer '85 conference in Portland, Oregon.
1145 I expect to be reading mail again on the 16th of June.
1153 __________________________________The_tripcomps______Reply_Template____________________________________________
1157 Another more interesting approach is used by the repl command, which
1159 constructs a draft in reply-to a previously received message. Instead of adding
1161 switches to indicate which fields of the draft should be derived from the message
1163 being replied-to, and how they should be derived, a single option, the ability to
1165 specify a template, was made available. An example of a reply template is shown
1167 in Figure 3. Put simply, based on the presence of certain fields in the message
1169 being replied-to, and a few switches given by the user, using the reply template,
1171 repl generates the reply draft automatically.
1174 This facility, for example, can be used to generate automatic replies.6 One
1176 function might be to write a rcvtrip shell script which automatically answered
1178 messages when mail wasn't being read for a period of time (e.g., while attending a
1180 conference). An example of a reply template at the heart of such a script is shown
1185 Finally, another application might be to utilize the highly useful letter bomb
1187 protocol.7 The important thing to note about this template is that it generates
1189 not only the headers of the reply draft (with a creative ``Reply-to:'' address),
1191 but the body as well. Hence, the commands
1194 repl -form bombcomps -noedit ; rmm
1197 _____________________________________
1198 6 MH supports the notion of a user-defined mail hook which is invoked each time a user receives
1201 7 The authors wish to credit Ron Natalie of the Ballistics Research Laboratory in Aberdeen,
1203 Maryland for formalizing the use of this protocol in the ARPA Internet community.
1204 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 15
1205 _______________________________________________________________________________________________________________
1208 cc: <?to_cc><to>,<cc>
1211 Subject: <?subject>Re: <subject>
1212 In-reply-to: <?date><?message-id>Your message of <date>.
1214 In-reply-to: <?date><!message-id>Your message of <date>.
1232 XXXXXXXXXXXXXXXXXXXXXXX
1233 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1234 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1235 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1236 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1237 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1238 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1239 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1240 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1241 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1242 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1243 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1244 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1245 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1246 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1247 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1248 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1249 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1250 XXXXXXXXXXXXXXXXXXXXXXX
1256 _________________________________The_bombcomps________Reply_Template___________________________________________
1261 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 16
1262 _______________________________________________________________________________________________________________
1264 width=80,length=0,overflowtext=,overflowoffset=10
1265 Date:leftadjust,compress,compwidth=9
1266 Subject:leftadjust,compress,compwidth=9
1267 From:leftadjust,compress,compwidth=9
1268 To:leftadjust,compress,compwidth=9
1269 cc:leftadjust,compress,compwidth=9
1270 Resent-Note:leftadjust,compwidth=9
1272 body:nocomponent,overflowoffset=0
1277 ____________________________________________Display_Template___________________________________________________
1281 are very handy for dealing with disturbing mail in a straight-forward manner. Of
1283 course, repl could be linked to bomb in the user's bin/ directory and an appropriate
1285 line could be added to the user's MH profile, in order to further shorten type-in.
1288 A variation on the reply template is the display template. A display template,
1290 as used by the mhl program, contains instructions on how to format a message. In
1292 addition to being used by show, et. al., the forw program can also use a display
1294 template to format each message being forwarded. Similarly, although repl uses a
1296 reply template to construct the draft being composed, it also may use a display
1298 template to format the body of the message being replied-to for enclosure in the
1300 reply. Furthermore, the post program may use a display template to format the
1302 body of a blind-carbon-copy. An example of a display template used for formatting
1304 forwarded messages is shown in Figure 6.
1307 As with reply templates, display templates can offer a lot of functionality.
1309 For example, the one line display template:
1312 body:nocomponent,overflowtext=,overflowoffset=0,width=10000
1315 can be used to extract the body of a message, while ignoring the headers. Hence,
1317 if a shar archive arrived in the mail, a convenient way to unpack it, assuming the
1319 above display template was called mhl.body , would be:
1322 show -form mhl.body _ sh
1326 The biggest win with display templates, of course, is that all those annoying
1328 header lines which mailers everywhere generate can be simply and easily filtered
1331 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 17
1334 Modularity versus Monolithicity
1336 Since MH is a set of programs which perform separate tasks, as opposed to
1338 being a single, monolithic program, the power of the shell is used directly to aid in
1340 mail-handling. One powerful capability which this design achieves is the ability to
1342 extend the MH command set, by developing shell scripts which use the standard
1344 MH programs to accomplish complicated or specialized tasks.
1347 For example, in the MH distribution there is a shell script called mpick
1349 (shown in Figure 7) which tries to locate all the messages which pertain to a given
1351 discussion, by looking at the ``Message-ID:'' and ``In-reply-to:'' headers,
1353 to find matching message-ids.8
1356 Unfortunately, some parts of MH are somewhat monolithic. An example of
1358 this is the What now? prompt. There are only a few options at this prompt, and
1360 one cannot give a normal shell command. Some MH users seem to feel that more
1362 options should be added to the What now? prompt, such as an insert-file option. It
1364 was argued that just about any editor would allow you to insert a file, and another
1366 What now? option was not needed. These users persisted, however, so the problem
1368 was solved, by writing a trivial shell script "editor" (see Figure 8) which could be
1370 invoked by the edit option:
1373 What now? edit append filename
1377 A better interface at this point is really needed, however. One possibility is to
1379 simply pass any unrecognized commands on to a shell for interpretation, supplying
1381 the path name of the draft file as an argument. A solution which shows more
1383 promise is to give you a sub-shell instead of the What now? prompt, and setup
1385 certain envariables so that the MH commands would act upon the draft by default.
1387 For example, show with no `msgs' arguments would show the draft instead of the
1389 current message. This alternative has recently been implemented and is under
1397 The mh.5 distribution is now briefly described, both in terms of static
1399 configuration methods and dynamic tailoring. Appendix B describes the mechanics
1401 of receiving an mh.5 distribution.
1405 _____________________________________
1406 8 Note that the shell scripts included in the MH distribution are written for the Bourne shell, and
1408 have a `:' as the first character of the first line, so they will be portable to all versions of UNIX, not
1409 just those which support the Berkeley `# !' enhancement.
1410 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 18
1411 _______________________________________________________________________________________________________________
1413 : 'mpick - relate messages /mtr'
1414 PATH=:/bin:/usr/bin:/usr/ucb:/usr/local:/usr/local/lib/mh; export PATH
1426 *) echo "mpick: only one folder at a time" 1>&2
1436 S="$S -sequence hits -list -nozero"
1439 if mark $F all -add -sequence hits;
1440 then mark $F all -delete -sequence hits;
1447 for C in `mhpath $F $A`
1451 I=`mhl -form mhl.msgid $C`;
1453 "") echo "no message-id in message `basename $C`" 1>&2 ;;
1454 *) pick --in-reply-to "$I" $S ;;
1457 echo "message $A doesn't exist" 1>&2; exit 1;
1468 ____________________________________________The_mpick_Script___________________________________________________
1474 The MH distribution currently runs on a large number of different UNIX
1476 versions, ranging from MicroSoft XENIX to Berkeley 4.2bsd. All the code which
1477 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 19
1478 _______________________________________________________________________________________________________________
1480 : 'append - stupid append editor for MH - /jlr'
1483 1) F=$1; echo -n "Append file: " 1>&2; read A ;;
1486 cat $A < /dev/null >> $F ;;
1487 *) echo "append: arg count" 1>&2 ; exit 1 ;;
1494 ___________________________________________The_append_Editor___________________________________________________
1496 _______________________________________________________________________________________________________________
1500 editor /usr/local/prompter
1501 etc /usr/local/lib/mh
1502 mail /usr/spool/mail
1513 ___________________________________Sample_MH_Configuration_File________________________________________________
1517 is specific to a particular target environment is enabled via the C-preprocessor
1519 ``# ifdef'' mechanism, so compilation under different versions of UNIX is trivial.
1521 There are, however, a large number of compile-time options which may vary from
1523 site to site, so an automated configuration method was needed.
1526 The MH-installer must create a configuration file, which contains a list of
1528 the compile-time options and the values which are desired for them. Compile-time
1530 options include the installation location for MH, what kind of message transport
1532 system is to be used, and the default editor for the installation. An example of
1534 such a configuration file is shown in Figure 9.
1537 After creating this file (several examples are included in the distribution), the
1539 installer runs the mhconfig program, which customizes the Makefile s and some of
1541 the programs, for that site's particular installation. No hand-editing of any source
1543 code should be necessary, under normal circumstances.
1544 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 20
1545 _______________________________________________________________________________________________________________
1547 mmdfldir: /usr/spool/mail
1549 mmdelim1: "001"001"001"001"n
1550 mmdelim2: "001"001"001"001"n
1556 hostable: /usr/local/lib/mh/hosts
1557 servers: localhost "01localnet
1562 _______________________________________Sample_MTS_Tailor_File__________________________________________________
1566 Interface to the Message Transport System
1568 MH will run with a number of message transport systems, including SendMail,
1570 MMDF-II, and a small stand-alone system. One flexible method of posting mail
1572 is through an SMTP connection. There are a couple of major wins in using this
1574 configuration: First, none of the MH programs need to know where the interface
1576 programs to the message transport system are located, which makes them easier
1578 to move between systems. Second, mail can be posted on relay hosts, and the local
1580 host of an MH user may not need a message transport system at all (as alluded to
1582 in the preceeding discussion on the POP).
1585 Those parts of MH which interact with the local message transport agent
1587 read additional tailoring information when they start.9 This information includes
1589 the location of standard and alternate maildrops, maildrop delimiter strings, the
1591 locking directory and locking style, and other tailoring information specific for
1593 the particular message transport system in use (e.g., the default server search-list
1595 when mail is posted with the SMTP). In most cases, by using a tailor file, each site
1597 running a similar MH configuration is able to simply transfer MH binaries between
1599 hosts. An example of such a tailor file is shown in Figure 10.
1602 A continuing question which is often raised is how intelligent should user
1604 agents (like MH and UCB Mail ) be with respect to the environment in which they
1606 operate. At present, MH likes to determine the official hostnames for addresses
1608 when posting mail. Many argue that this is improper or unnecessary behavior
1610 for a user agent, and that the local message transport agent should handle
1612 these functions. Unfortunately, this implies that the message transport agent
1614 should munge headers when mail is posted to remove local host aliases and only
1616 permit address fields with fully-qualified addresses. Sadly, neither SendMail nor
1618 MMDF-II really gets this right (flames to /dev/null please). The current MH
1620 maintainers believe that the resolution of host aliases to official names should be
1622 a well-supported interface with the local message transport agent. However, to
1624 _____________________________________
1625 9 This simple facility is based on a more extensive tailoring capability found in MMDF-II.
1626 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 21
1629 provide equal time to those who hold opposite views, MH supports a configuration
1631 option called ``DUMB'' which disables MH's attempts to resolve addresses into
1633 fully-qualified strings.
1639 While MH has undergone significant development since the original Rand
1641 release, the authors have tried to keep the fundamental concepts of MH unchanged.
1643 The authors have continually had to battle against well-meaning MH users who
1645 wanted to make MH more like other (less powerful) user agents. More and more
1647 "features" were often suggested for MH, usually at the expense of making MH
1649 less general, and more specific. In nearly all cases, the "features" which these
1651 users wanted were already present in MH in a slightly different form, or could be
1653 realized by simply writing a short shell script. A classic example is the repeated
1655 requests by one user to have dist take a list of messages rather than a single
1657 message and distribute each one of them in turn. A simple shell script which called
1659 dist repeatedly, perhaps with "canned" arguments so the user typed in addressing
1661 information only once, would easily meet this request.
1664 A number of MH comands have a large number of options. When adding
1666 options, the authors have tried to make the options general, while still accomodating
1668 the requests of specific users. An example of a specific request which was
1670 implemented as a general feature is the ``Previous-Sequence'' profile entry
1672 (mentioned above). If you use this profile entry, every MH command is forced to
1674 write out context changes, making every command somewhat slower. Since only a
1676 few users wanted this capability, it was implemented in such a way that users who
1678 didn't want it, didn't have to pay the cost of slowing down every MH command.
1681 MH has a powerful tailoring capability provided by the .mh_profile . Using
1683 profile entries, users may customize their own environment without affecting others.
1685 Novice users often take advantage of the MH-tailoring capabilities to try to make
1687 MH work similarly to other user agents they've used. This has the advantage of
1689 allowing them to quickly begin using MH to handle their mail. However, since these
1691 novice users don't take advantange of all the capabilities of MH, they frequently
1693 will complain about things they think can't be done with MH, or could be done
1695 "better" some other way. Fortunately, as these users become more experienced
1697 with both MH and UNIX, they can modify their environment to take better
1699 advantage of all of MH's capabilities. Novice MH users who see features lacking
1701 are encouraged to take a better look at what MH can do, instead of trying to make
1703 MH into something it isn't. This may sound rather inflammatory, but it would
1705 really be a much nicer world for us all if users of software systems would read the
1707 manual prior to asking questions.
1710 For a moment, let's consider the evolution of one MH feature which has
1712 proved itself to be very useful. As users began employing MH to handle their
1713 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 22
1716 mail, the number of messages that could be processed in a given amount of time
1718 increased greatly. As the volume of messages increased however, it became clear
1720 that some MH operations were too slow, in particular the interaction with the
1722 (slow) message transport system. To overcome this problem, the push option was
1724 added at the What now? prompt. Originally, this option was hidden from novice
1726 users and did little more than send the message in the background: any output
1728 generated by the background send process would be printed asyncronously on the
1730 terminal. If a message failed posting with the message transport system, it would
1732 simply be left in the draft file.
1735 Gradually, other features were added to push. Since users wanted to be able
1737 to send more than one draft at a time, push was changed to optionally rename
1739 the draft file before posting it. (This is what the hidden `-unique' option does.)
1741 Having message transport system diagnostics written asyncronously on the user's
1743 terminal was annoying, so push was made to intercept these diagnostics, and mail
1745 the user a report containing them. Although the diagnostic report mailed back by
1747 push contains the name of the draft which failed, a useful added feature was the
1749 ability to have push include the failed draft as well. Eventually, the draft-folder
1751 mechanism was implemented to make handling multiple message drafts much
1758 There are, no doubt, a number of improvements which could be made to MH.
1760 At the present time, what further development should MH suffer? Although not
1762 by any means inclusive, here's a list:
1765 1. Performance Enhancements
1767 Hardware gets faster all the time, but people always complain that
1769 software is too slow. Owing to its user interface style, MH is somewhat
1771 slower than monolithic programs like UCB Mail. It would be nice if MH
1773 could be tuned or accelerated somehow.
1778 MH runs on 4.2bsd UNIX and Version 7 variants. It should not be
1780 difficult to port MH to a SYS5 environment. This should significantly
1782 increase the number of hosts on which MH can run. The authors, lacking
1784 a SYS5 machine (and experience with SYS5) to perform the port, are
1786 actively seeking a System 5 guru to attempt this feat.
1789 3. Interface to the Network News
1791 Not all sites that run MH are in the ARPA Internet, and as such the
1793 UCI BBoards facility may not be of much use to them. A good MH
1795 interface to the network news would allow users on hosts with a news
1797 feed to employ the same interface for reading and sending both mail
1800 \fReprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 23
1803 4. Programmed Instruction for Beginners
1805 The complexity of MH is often intimidating to new users. It would be
1807 nice to develop a set of learn lessons for those users who don't like man
1809 pages and non-interactive tutorials.
1812 5. Message List Expansion
1814 At present, when a list of messages is given to an MH command, it
1816 expands the list and processes each message in numerical order rather
1818 than the order in which the messages were given (e.g., ``show 2 1''
1820 show s message 1 and then message 2). It would be nice if MH processed
1822 messages in the order they were given.
1827 In nearly all cases, an MH command does not write out context changes
1829 until it is about to exit successfully. There is some controversy as to
1831 whether this is the correct behavior in all cases. Some argue that once
1833 an MH command has fully parsed its argument list, the context should
1836 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 24
1843 [DCome83] D. Comer. The Computer Science Research Network CSnet: A
1845 History and Status Report. Communications of the ACM 26, 10
1847 (October, 1983), 747-753.
1851 [DCroc79] D.H. Crocker, E.S. Szurkowski, D.J. Farber. An Internetwork
1853 Memo Distribution Facility _ MMDF. Appearing in Proceedings,
1855 Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
1859 [DCroc82] D.H. Crocker. Standard for the Format of ARPA Internet Text
1861 Messages. Request for Comments 822. ARPA Internet Network
1863 Information Center (NIC), SRI International (August, 1982).
1867 [DKing84] D.P. Kingston, III. MMDFII: A Technical Review. Appearing in
1869 Proceedings Usenix Summer '84 Conference, Salt Lake City, Utah,
1875 [EAllm83] E. Allman. SENDMAIL _ An Internetwork Mail Router.
1877 Britton-Lee, Inc., Berkeley, California (July, 1983).
1881 [IP] Internet Protocol. Request for Comments 791 (milstd 1777).
1883 Appearing in Internet Protocol Transition Workbook, ARPA Internet
1885 Network Information Center (NIC), SRI International, 1981.
1889 [JReyn84] J.K. Reynolds. Post Office Protocol. Request for Comments 918.
1891 ARPA Internet Network Information Center (NIC), SRI International
1897 [MButl85] M. Butler, J.B. Postel, et. al. Post Office Protocol - Version 2.
1899 Request for Comments 937. ARPA Internet Network Information
1901 Center (NIC), SRI International (February, 1985).
1905 [MRose84a] M.T. Rose. The Rand MH Message Handling System: The UCI
1907 BBoards Facility. Department of Computer and Information Sciences,
1909 University of Delaware (October, 1984).
1913 [MRose85b] M.T. Rose, E.A. Stefferud. Proposed Standard for Message
1915 Encapsulation. Request for Comments 934. ARPA Internet Network
1917 Information Center (NIC), SRI International (January, 1985).
1918 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 25
1921 [SMTP] Simple Mail Transfer Protocol. Request for Comments 821. ARPA
1923 Internet Network Information Center (NIC), SRI International
1929 [TCP] Transmission Control Protocol. Request for Comments 793 (milstd
1931 1778). Appearing in Internet Protocol Transition Workbook, ARPA
1933 Internet Network Information Center (NIC), SRI International, 1981.
1942 MH is composed of several UNIX programs, which in theory are fairly simple
1944 and single-purposed. These commands are functionally grouped below:
1947 Composing_Mail_________
1949 comp: compose a message
1951 A program to originate a message. Usually, a special prompting editor front-
1953 end, prompter, is used to fill-in a composition template with the addressees
1955 of the message, subject, and so forth.
1958 dist : redistribute a message to additional addresses
1960 A program that re-enters a message previously received by the user into the
1962 message transport system. Only new addresses are added; the body of the
1964 message is not changed in any way.
1967 forw : forward messages
1969 A program that encapsulates one or more messages in a new message draft.
1971 In addition, the user may add initial and/or closing comments.
1974 repl : reply to a message
1976 A program that constructs a reply to a message using a reply template. The
1978 template mechanism has sufficient generality to permit the user to "program"
1980 the form of the reply draft based on the contents of the message being
1985 send : send a message
1987 A program that posts a draft with the message transport system. The
1989 send program is usually invoked by one of the four preceding programs, and
1991 performs simple front-end pre-processing prior to invoking the post program.
1993 For example, if invoked in push'd mode, send will immediately relinquish
1995 control of the user's terminal and post the message in the background. If
1997 the posting fails, send will send back a failure notice to the user. If the user
1999 had push'd the sending of the draft, then by default the draft being sent is
2001 encapsulated in the failure notice. This permits easy burst'ing of the failure
2003 notice to retrieve the original draft. Otherwise, if the posting was successful,
2005 the draft is marked as having been sent.
2008 whatnow : prompting front-end for send
2010 A program which is called by comp, et. al., after the initial draft has been
2015 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 27
2018 generated. The MH user can specify a different whatnow program, which
2020 yields considerable extensibility.
2023 whom: report to whom a message would go
2025 A program which examines the addresses of the draft and expands all user-
2027 defined aliases contained therein. Optionally, whom may actually interact
2029 with the message transport system to determine the validity of the final
2031 addresses. This program is also usually invoked by comp, et. al.
2036 ali : list mail aliases
2038 A simple front-end to the MH aliasing mechanism.
2041 ap: parse addresses 822-style
2043 A useful debugging tool for PostMasters who wish to examine how MH
2045 interprets an Internet address.
2048 conflict : search for alias/password conflicts
2050 Another program used by system administrators to check the consistency of
2052 MH alias files, and portions of the local message transport agent.
2055 install-mh: initialize the MH environment
2057 A program which is automatically executed the first time a user issues an MH
2059 command. This program performs once-only initialization of the user's MH
2064 mhmail : send or read mail
2066 A simple program generally used by other programs to generate messages.
2068 The mhmail command is similar in purpose to the old BellMail program.
2071 post : deliver a message
2073 A complex MH back-end that interacts with the local message transport
2075 agent to enter messages through the posting slot. (See the description of send
2082 inc: incorporate new mail
2084 A program that interacts with the local message transport agent to retrieve
2086 messages from the user's maildrop.
2089 msgchk : check for waiting mail
2091 A program which reports the status of mail waiting in the user's maildrop.
2094 show : show (list) messages
2096 A program which lists messages to its standard output (usually the user's
2098 terminal), possibly invoking another program to do the actual listing. Most
2100 users of MH have show automatically call the mhl program to format the
2101 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 28
2104 message. The next and prev programs are simply ``show next'' and
2106 ``show prev'' , respectively.
2109 mhl : produce formatted listings of MH messages
2111 A program which displays a message as directed by a template. This permits
2113 the user to filter out uninteresting headers and re-arrange other headers to a
2115 particular preference. In addition to being invoked by show, the mhl program
2117 is optionally also invoked by forw to format each message being forwarded;
2119 invoked by repl to format the body of a message being replied-to, if that
2121 message is being included in the reply draft; and, invoked by post to format
2123 a message being sent as a blind-carbon-copy.
2126 rmm: remove messages
2128 A program that removes messages from an MH folder, optionally running a
2130 user-defined program instead of deleting them. If no program is given, the
2132 messages are "softly" removed, so they may possibly be recovered later.
2135 scan: produce a one-line-per-message scan listing
2137 A program that generates a scan listing for messages. Each line of the listing
2139 contains date, source, subject, and possibly the initial body of the message.
2142 Folder_Handling_______
2144 folder : set/list current folder/message
2146 A program used to list information concerning the current folder, or set the
2148 current folder and/or message.
2151 folders : list all folders
2153 A program to list information on all folders (actually, just a special case of
2155 the folder command). Since the MH folder structure may be recursive, the
2157 user can indicate that folders should recursively examine all folders.
2160 refile: file message(s) in (an)other folder(s)
2162 A program to move (or copy) messages from a source folder to one or more
2164 destination folders.
2169 A program that deletes a folder and all messages therein.
2172 Message_Selection_______
2174 anno: annotate messages
2176 A program to arbitrarily annotate messages. If the user so desires, after
2178 distributing, forwarding, or replying-to a message, MH will automatically
2180 attach an annotation to the original message indicating the date and addresses.
2183 mark : mark messages
2185 A program to manipulate user-defined sequences (lists of messages). Usually,
2187 mark is not employed directly by the MH user.
2188 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 29
2191 pick : select messages by content
2193 A program to examine a list of messages and choose those which meet
2195 a particular selection criterion. The pick program is often used in UNIX
2197 back-quoted operations to pass message sequences to other MH commands.
2200 sortm: sort messages
2202 A program to sort a list of messages according to the date given in a particular
2207 Distribution_List_Handling__________
2209 bbc: check on BBoards
2211 A front-end to run msh on a list of distribution lists which the user isn't
2216 bbl : manage a BBoard
2218 A (depreciated) program used to manually manage the local archives of
2220 a distribution list. These functions (archiving, expunging) are performed
2222 automatically by MH.
2225 burst : explode digests into messages
2227 A program used to decapsulate messages from ARPA Internet digests. In
2229 addition, messages which have been encapsulated during forwarding (i.e.,
2231 with forw ) can also be decapsulated using burst.10
2234 msh: MH shell (and BBoard reader)
2236 A monolithic program used to implement MH commands on messages
2238 arranged in a single file (maildrop format). Useful since distribution lists are
2240 kept in this format to minimize consumption of system resources.
2243 pack : compress a folder into a single file
2245 A program which takes messages stored in MH format and places them in a
2247 single file (using the same format known by msh).
2250 Interface_to_the_UNIX_File_System_____________
2252 mhpath: print full pathnames of MH messages and folders
2254 A program which maps MH-style names into the UNIX file naming convention.
2258 _____________________________________
2259 10 Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
2266 Distribution Mechanics
2270 The mh.5 distribution is available in two forms:
2275 If you can FTP to the ARPA Internet, use anonymous FTP to the
2277 ARPAnet host UDel-Huey [10.2.0.96] and retrieve the file portal/mh.5-
2279 tar. This is a tar image of size 2.1 MB (approximately).
2282 2. 9-track tape, 1600 bpi, tar format
2284 Otherwise, you can send $ 50.00 to the address below. This covers the
2286 cost of a magtape, handling, and shipping. In addition, you'll get a
2288 laser-printed hard-copy of the MH documentation. The documentation
2290 includes installation guide, MH Tutorial, MH User's Manual, changes
2292 document (from mh.4 to mh.5), and BBoards Manual.
2295 If you go with this option, be sure to include your USPS address with
2297 your check. Checks should be made payable to
2300 Regents of the University of California
2303 It's also a good idea (though not mandatory) to send a computer mail
2305 message to Bug-MH@UCI when you send your check via USPS to ensure
2307 minimal turn-around time. The distribution address is:
2312 Attn: MH Distribution
2314 Department of Information and Computer Science
2316 University of California, Irvine
2326 Sadly, if you just want the hard-copies of the documentation, you still
2328 have to pay the $ 50.00. The tar image has the documentation source
2330 (the man is in ROFF format, but the rest are in TEX format).
2333 In addition, there is some hope that mh.5, or a successor, might be found in a
2335 future 4.x Berkeley distribution.
2340 \f Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985 31
2343 Although MH is not "supported" per se, it does have a bug reporting address.
2345 Normally, the address Bug-MH@UCI is used to report bugs and bug fixes. There are
2347 however, two discussion groups which concern themselves with MH:
2352 A discussion group for the MH user community at large. Appropriate
2354 topics include: questions about how to use MH, tips on MH usage, and
2356 exchange of MH shell scripts. All requests to be added to or deleted
2358 from this list, along with problems, questions and suggestions, should
2360 be sent to MH-Users-Request@UCI.
2365 A discussion group for MH maintainers and experts. Appropriate topics
2367 include: questions on how to configure MH, tips on MH configuration,
2369 exchange of MH bug reports (and fixes). All requests to be added to or
2371 deleted from this list, along with problems, questions and suggestions,
2373 should be sent to MH-Workers-Request@UCI.
2376 The ``UCI'' host is also known as ``ucivax'' , so a possible UUCP path might
2378 be : : :!ucbvax!ucivax!bug-mh.
2381 Updates to MH are published on the MH-Workers list in the form of context
2383 diffs, and the appropriate distribution images are updated as well.
2394 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2396 The MH Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2398 The MH Environs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2400 An MH Transcript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2402 Some MH Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2404 Message Sequences and Selection . . . . . . . . . . . . . . . . . . . . . . . 5
2406 Draft Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2408 BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2410 Bursting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2412 Distributed Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2414 User Interface Issues in MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2416 Creeping Featurism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2418 Templates versus Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2420 Modularity versus Monolithicity . . . . . . . . . . . . . . . . . . . . . . . . 17
2422 The MH Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2424 Configurable MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2426 Interface to the Message Transport System . . . . . . . . . . . . . . . . . 20
2428 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2430 TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2432 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2434 Appendix A: MH Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2436 Appendix B: Distribution Mechanics. . . . . . . . . . . . . . . . . . . . . . . . . 30
2440 _____________________________________
2441 This document (version #1.43) was TEXset April 12, 1990 with DISS.STY v103.
projects / mmh / blob