Automated generation of mh-chart.man.
[mmh] / docs / historical / realwork.txt
1
2
3
4
5                                                    MH.5:
6
7                           How  to  process  200  messages  a  day
8
9                            and  still  get  some  real  work  done./
10
11
12                                             Marshall T. Rose
13
14                                 Member, Research Technical Staff
15
16                           Northrop Research and Technology Centery
17
18
19
20                                              John L. Romine
21
22                                      Computing Support Group
23
24                      Department of Information and Computer Science
25
26                                    University of California, Irvinez
27
28
29
30                                                 Abstract
31
32
33         The  UCI  version  of  the  Rand  Message  Handling  System  (MH)  is  dis-
34
35         cussed.  MH is a powerful user agent which operates in the ARPA Internet
36
37         and UUCP environments.  In addition to the usual functions provided
38
39         by similar programs, MH has several distinguishing characteristics which
40
41         give the user additional message handling capability.  In particular, MH
42
43         provides  mechanisms  for  maintaining  an  organized  mail  environment,
44
45         tailoring its behavior, and extending its functions.
46
47
48         This document describes MH from several perspectives.  Particular em-
49
50         phasis is given to:  the MH user environment, advanced features of MH
51
52         which  have  proven  to  be  particularly  useful  for  sophisticated  users  of
53
54         electronic mail, the user interface issues in MH, and the mh.5 distribu-
55
56         tion.  The paper concludes with a summary of the authors' experiences
57
58         with MH, and a discussion of future areas of enhancement.
59
60
61
62 _____________________________________
63 ./ Alternate title: MH: Your Key to Success.
64 y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
65
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.
68
69 Computer mail: J-Romine@USC-ECL, : : :!fucbvax,trwrbg!ucivax!jromine.
70 \f
71
72                                                    MH.5:
73
74                           How  to  process  200  messages  a  day
75
76                              and  still  get  some  real  work  done
77
78
79
80 Introduction
81
82         The UCI version of the Rand Message Handling System, MH, is a software
83
84 system  that  performs  two  functions:  first_,  it  interfaces  a  user  to  a  message
85
86 transport system, so the user may receive and send mail; second___, it permits the
87
88 user to maintain an organized mail environment to facilitate the composition of
89
90 new messages and the reading of old messages.  In short, while not responsible for
91
92 the delivery of messages, MH aids the user in handling mail.
93
94
95         MH  was  originally  developed  by  the  Rand  Corporation,  and  initially  was
96
97 proprietary  software.   The  Department  of  Information  and  Computer  Science
98
99 at  University  of  California,  Irvine,  shortly  after  joining  the  Computer  Science
100
101 Network (CSnet), acquired a copy of MH, and began additional development of
102
103 the software.  Since that time, the Rand Corporation has declared MH to be in the
104
105 public domain, and the UCI version of MH has passed through four major releases.
106
107 The current version, mh.5, is available from U.C. Irvine for a nominal distribution
108
109 fee, or may be retrieved from the University of Delaware via anonymous FTP.
110
111
112         Much credit must be given to the initial designers and implementors of MH:
113
114 Bruce Borden, Stockton Gaines, and Norman Shapiro.  Although MH has suffered
115
116 significant  development  at  UCI  since  Rand's  initial  release,  the  fundamental
117
118 concepts  of  MH's  environs  have  remained  nearly  unchanged.   In  addition,  the
119
120 authors of the current release gratefully acknowledge the comments of the many
121
122 sites which have run various releases of MH in the past.  In particular, the dozen
123
124 or so beta test sites for mh.5 provided tremendous help in stabilizing the current
125
126 release.
127
128
129         MH  runs  on  different  versions  of  the  UNIX1  operating  system  (such  as
130
131 Berkeley  4.2bsd  and  various  flavors  of  v7).   In  addition,  MH  supports  four
132
133 different  message  transport  interfaces:  SendMail[EAllm83],  the  standard  mailer
134
135 for 4.2bsd systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel
136
137 Memo Distribution Facility developed by the University of Delaware which forms
138
139 the software-backbone for CSnet[DCome83] mail relay service; SMTP, the ARPA
140
141 Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
142
143
144
145 _____________________________________
146 1  UNIX is a trademark of AT&T Bell Laboratories.
147
148
149
150                                                        1
151 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              2
152
153
154         This  paper  is  organized  in  a  straight-forward  fashion:  Initially,  the  MH
155
156 philosophy  of  mail  handling  is  presented,  along  with  a  description  of  the
157
158 environment which the MH user is given to process mail.  Following this, certain
159
160 advanced features of MH are discussed in more detail, such as facilities for selecting
161
162 messages, and "advanced" concepts in draft handling.  In addition, user interface
163
164 issues in mail handling are addressed, and the merits of MH's approach is critically
165
166 examined.  Next, the mh.5 distribution package is described.  Finally, we conclude
167
168 by discussing the authors' experience with MH development and introducing areas
169
170 where MH may be further developed.
171
172
173         Although  familiarity  with  MH  is  not  assumed  on  the  part  of  the  reader,
174
175 some knowledge of the UNIX operating system is useful.  Appendix A gives a short
176
177 synopsis of the MH commands.
178
179
180
181 The MH Philosophy
182
183         Although MH has many traits which tend to distinguish it from other systems
184
185 which handle mail, there is a single fundamental design decision which influences
186
187 the interface between MH and the user:  MH differs from most other systems in
188
189 that it is composed of many small programs instead of one very large one.  This
190
191 architecture gives MH much of its strength, since intermediate and advanced users
192
193 are able to take advantage of this flexibility.
194
195
196         The key to this flexibility is that the UNIX shell (usually the C shell or the
197
198 Bourne shell), is the user's interface to MH. This means that when handling mail,
199
200 the entire power of the shell is at the user's disposal, in addition to the facilities
201
202 which MH provides.  Hence,  the user may intersperse mail handling commands
203
204 with other commands in an arbitrary fashion, making use of command handling
205
206 capabilities which the user's shell provides.
207
208
209         Furthermore, rather than storing messages in a complicated data structure
210
211 within a monolithic file, each message in MH is a UNIX file, and each folder (an
212
213 object  which  holds  groups  of  messages)  in  MH  is  a  UNIX  directory.   That  is,
214
215 the directory- and file-structure of UNIX is used directly.  As a result, any UNIX
216
217 file-handling command can be applied to any message.
218
219
220         To the novice, this may not make much sense or may not seem important.
221
222 However,  as  users  of  MH  become  more  experienced,  they  find  this  capability
223
224 attractive.  In addition, this approach is often quite pleasing to system implemen-
225
226 tors,  because  it  minimizes  the  amount  of  coding  to  be  performed,  and  given  a
227
228 modular design, changes to the software system can be maintained easily.  There
229
230 are,  however,  performance penalties to be paid with this scheme.  This issue is
231
232 considered later in the paper.
233
234
235         Having described how MH fits into the UNIX environment, we now discuss
236
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
239
240
241 The MH Environs
242
243         In the $ HOME       directory of each MH user, a file named .mh_profile     contains
244
245 static information about the user's MH environment, and default arguments for
246
247 MH programs.  For the latter case, each line of profile takes the form:
248
249
250            program-name: options
251
252
253 Each MH program consults the user's .mh_profile     for its options.  These options
254
255 are consulted prior to evaluating any command-line arguments, and so provide the
256
257 MH user the capability to customize the defaults for each command.  Futher, by
258
259 using the UNIX link facility, different names can be given to the same command.
260
261 Since each MH command looks in the .mh_profile     for a component with the name
262
263 by  which  it  was  invoked,  it's  possible  to  have  different  defaults  for  the  same
264
265 program.  For example, it is not uncommon to link prompter (a simple prompting
266
267 editor front-end) under the name rapid in the user's bin/   directory, and add to the
268
269 .mh_profile    :
270
271
272            rapid: -prepend -rapid
273
274
275 As a result, when prompter is invoked as rapid, it automatically uses the `-prepend'
276
277 and `-rapid'      options.
278
279
280         The profile component ``Path:''       is the path to the user's MH-directory,
281
282 usually Mail.  In addition to containing the user's folders, the MH-directory also
283
284 contains skeletons and templates used by the MH programs, and the user's context
285
286 file.  This latter file has the same format as the user's .mh_profile    , and contains the
287
288 dynamic, context-dependent information about the user's environment.  Whenever
289
290 MH looks for an MH-specific file, such as a template or skeleton, it first consults
291
292 the user's MH-directory, and then a system-wide library area.
293
294
295         The MH user always has a current folder, which is the folder in which the user
296
297 is currently (or was last) working.  Since any MH program which deals with folders
298
299 implicitly manipulates this information, the name of the current folder is stored in
300
301 the context    component ``Current-Folder:''            .  Every folder has a current message
302
303 known as `cur'   .  These values are the defaults for MH commands which accept
304
305 folder and/or messages arguments.
306
307
308         MH programs make use of a set of envariables which further customize their
309
310 behavior.  The $ MH    envariable, if present, specifies the name of an alternate profile
311
312 for the user.  This allows a user of MH to easily maintain multiple mail-handling
313
314 environments.
315
316
317         In terms of command syntax, most MH commands accept an optional folder
318
319 argument, such as `+outbox'      .  Unlike most UNIX commands, all MH commands
320
321 have  switches  which  are  words,  rather  than  single  letters.   Switches  may  be
322
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  _______________________________________________________________________________________________________________
326
327   1   %  inc
328   2   Incorporating  new  mail  into  inbox...
329   3
330   4       1+  03/16  Rand  MH  System      MH  transcript   <<Here's  the  body  of  a  sample  m
331   5
332   6   %  show
333   7   (Message  inbox:1)
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>
338 12
339 13    Here's  the  body  of  a  sample  message.
340 14    %  repl
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).
345 19    --------
346 20    Thanks  for  the  test.
347 21
348 22    /JLR
349 23    ^D
350 24
351 25    What  now?  send
352 26    %  comp
353 27    To:  MRose@UCI
354 28    cc:
355 29    Subject:  sample  comp
356 30    --------
357 31    Here's  a  sample  compose  for  the  MH  transcript.
358 32
359 33    /JLR
360 34    ^D
361 35
362 36    What  now?  send  -verbose
363 37      --  Posting  for  All  Recipients  --
364 38       --  Local  Recipients  --
365 39       MRose:  address  ok
366 40      --  Recipient  Copies  Posted  --
367 41    Message  Processed
368
369
370                                                   Figure 1
371
372  _____________________________________________An_MH_Session_____________________________________________________
373
374
375
376  a  `-help'     switch,  which  lists  the  syntax  of  the  command  along  with  available
377
378  switches, and the version number of the command.  Most MH commands also take
379
380  a `msg'    or `msgs'     argument which takes the form of a message number (``1''   ), a
381
382  message range (``1-2''     ), a standard sequence name (``cur''     ), or a user-defined
383
384  sequence name (``select''      ).
385 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              5
386
387
388 An MH Transcript
389
390         Figure 1 contains a transcript of a simple MH session.  First, inc is run to
391
392 incorporate the new mail into the user's ``+inbox''       folder.
393
394
395         A  scan  listing  of  the  mail  is  printed  while  it  is  being  incorporated.  (The
396
397 user could run scan explicitly to generate additional scan listings later on.)  The
398
399 scan  listing  gives  the  message  number,  followed  by  the  date,  message  sender,
400
401 and subject.  (If the message originated from the user generating the listing, the
402
403 ``to:''      addressee is displayed instead of the sender.)  If the subject is short, the
404
405 first part of the message body is displayed after the characters ``<<''    .  The plus
406
407 sign (`+') after the message number indicates the current message.
408
409
410         The user show s the message, and decides to repl y.  A reply draft is created
411
412 using  the  headers  of  the  message  being  replied-to,  using  the  default  replcomps
413
414 template.  The  default  editor,  prompter,  is  called  to  edit  the  draft.  When  an
415
416 EOT is typed, prompter exits and the user is left at the What  now?  prompt.  The
417
418 option send is chosen.  Since there were no problems in posting the draft with the
419
420 message transport system, no additional output is produced.  (MH is not verbose
421
422 by default.)
423
424
425         The  user  then  decides  to  compose  a  new  message.  The  default  skeleton,
426
427 components      ,  is  copied  to  the  draft,  and  prompter  is  once  again  called.   After
428
429 entering the addresses, subject, and body, the user then send s the draft   from the
430
431 What  now?  prompt, using ``send -verbose''           , which causes MH to list out the
432
433 message addresses as it submits them to the message transport system.
434
435
436
437 Some MH Features
438
439         We now consider certain advanced features in MH. These features have been
440
441 chosen to demonstrate some useful capabilities available to the MH user.
442
443
444 Message Sequences and Selection
445
446         MH  has  several  built-in  message  sequence  names,  which  may  be  used
447
448 anywhere a `msg'     or `msgs'     argument is expected.  These are:  `cur'   , `next'    ,
449
450 `prev'    , `first'     , `last'    , and `all'   .  Message ranges may also be specified.  For
451
452 example, `all'     is actually `first-last'        , and `+mh last:5'         references the last
453
454 five messages in your `+mh'    folder.  A powerful capability of MH is the ability to use
455
456 not only the pre-defined message sequence names, but also arbitrary user-defined
457
458 message sequence names.
459
460
461         Although all MH programs recognize user-defined sequences when appropriate,
462
463 the  pick  and  mark  commands  can  create  and  modify  user-defined  message
464
465 sequences.  The mark command allows low-level manipulation of sequences, and is
466
467 not particularly interesting in our discussion.
468
469
470         The pick command selects certain messages out of a folder.  The criteria used
471
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
474
475
476         Searching  is  performed  on  either  a  specific  header  in  the  message  (e.g.,
477
478 ``To:''     ), or anywhere within the message.  By default, pick lists out the message
479
480 numbers that matched the selection criteria.  Thus, pick is useful in backquoted
481
482 operations to the shell.  For example, to scan all the messages in the current folder
483
484 from "frated", the MH user issues the command:
485
486
487            scan `pick -from frated`
488
489
490 To  perform  more  complicated  message  selection,  user-defined  sequences  are
491
492 employed.  Supplying a `-sequence name'           argument to pick, will cause it to define
493
494 the sequence `name'     as those messages matched.
495
496
497         Giving  pick  a  list  of  messages  causes  it  to  limit  its  search  to  just  those
498
499 messages.  For example, to find all the messages in the current folder from "frated"
500
501 also dated before friday:
502
503
504            pick -from frated -sequence select
505
506            pick select -before friday -sequence select
507
508
509 With the first pick command, the sequence ``select''        is defined to be all those
510
511 messages from "frated".  In the second command, only those messages already in
512
513 the ``select''       sequence are searched, and the ``select''       sequence is redefined
514
515 to be only those messages which are also dated before friday.  Those messages could
516
517 then be show n with:
518
519
520            show select
521
522
523 When  a  `-sequence name'           argument  is  given  to  pick,  the  default  behavior  _
524
525 listing the message numbers matched _ is inhibited.  To re-enable this behavior,
526
527 the `-list'     option may be given.  As a result, advanced users of MH often put the
528
529 following line in their .mh_profile    :
530
531
532            pick: -sequence select -list
533
534
535 which allows them to easily make use of the `select'      sequence as the messages
536
537 last selected with pick.
538
539
540         Often it is desirable to act upon those messages which are not members of
541
542 a given sequence.  For this purpose, the ``Sequence-Negation:''               profile entry
543
544 is useful.  If the name of a user-defined sequence is prefixed with the value of the
545
546 sequence-negation profile entry, MH commands will operate upon those messages
547
548 which are not members of that sequence.  For example, given a profile entry of:
549
550
551            Sequence-Negation: not
552
553
554 those messages which are not in the `select'      sequence could be scan'd with:
555
556
557            scan notselect
558 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              7
559
560
561         Obviously, some confusion could result if an attempt was made to define a se-
562
563 quence name which began with the sequence-negation string (e.g., ``notselect''        ).
564
565 For this reason, MH users will often use a single character, which their shell doesn't
566
567 interpret, as their sequence-negation string (e.g., up-caret (`^') for C Shell users,
568
569 and exclamation-mark (`!')  for Bourne shell users).
570
571
572         MH also provides a way of automatically remembering the last message list
573
574 given to an MH command.  This facility is implemented by using a profile entry
575
576 called ``Previous-Sequence:''              .
577
578
579 Draft Handling
580
581         After  the  initial  edit  of  a  message  draft,  the  comp,  dist,  forw,  and  repl
582
583 programs give the user a What  now?  prompt.  The valid responses include:  edit to
584
585 re-edit the draft, quit to exit without sending the draft, send to send the draft, and
586
587 push to send the draft in the background.
588
589
590         When the send option is given, the draft is posted with the message transport
591
592 system.  If there problems posting the draft, the What  now?  prompt is re-issued, so
593
594 errors in the draft may be corrected.
595
596
597         Since posting the draft can be slow, the push option allows the MH user to
598
599 send the draft in the background, and return immediately to the shell.  If there are
600
601 problems posting the message, the user will not see the diagnostics produced by
602
603 the message transport system.  For this reason, if push is used instead of send, and
604
605 the message is not successfully posted, MH mails a message to the user containing
606
607 any diagnostics which the message transport system produced along with a copy
608
609 of the message.  Later, the draft may be re-edited by entering ``comp -use''        .
610
611
612         A relatively new feature of MH is the ability to use a folder to store multiple
613
614 drafts.  These drafts are kept in an ordinary MH folder, and may be operated upon
615
616 by MH commands.  To enable this feature, the MH user selects a folder-name for
617
618 the draft-folder, and creates an entry in the .mh_profile    :
619
620
621            Draft-Folder: +foldername
622
623
624 From this point on, when a message is composed, the draft will be created as a
625
626 message in that folder, instead of using the draft   file in the user's MH directory.
627
628 Unfortunately, if posting problems occur on a message which has been push'd, it
629
630 may be difficult to re-edit the draft with ``comp -use''        .  This might be the case
631
632 if the user had started composing another message, while that first draft was being
633
634 posted.  In  that  event,  the  current-message  in  the  draft-folder  would  no  longer
635
636 point to the failed draft.
637
638
639         There is a solution for this problem, however.  By default, push assumes the
640
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
643
644
645 should be forwarded back to the user in the error report which push generates.
646
647 The failed draft may then be extracted with the burst program (discussed later).
648
649
650 BBoards
651
652         MH has a convenient interface to the UCI BBoards facility[MRose84a].2  This
653
654 facility  permits  the  efficient  distribution  of  interest  group  messages  on  a  single
655
656 host, to a group of hosts under a single administration, and to the ARPA Internet
657
658 community.
659
660
661         Although most readers are probably familiar with the concept of an interest
662
663 group in the Internet context, a brief description is now given.  Observant readers
664
665 will notice that the distributed nature of the "network news" (a.k.a. USENET)
666
667 tends to avoid many of the problems described below.
668
669
670         Described simply, an interest group is composed of a number of subscribers
671
672 with a common interest.  These subscribers post mail to a single address, known
673
674 as the distribution address (e.g., MH-Workers@UCI. From this distribution address,
675
676 a copy of the message is sent to each subscriber.  Each group has a moderator,
677
678 who is the person that runs the group.  This moderator can usually be reached at
679
680 a special address, known as the request address (e.g., MH-Workers-Request@UCI).
681
682 Usually,  the  responsibilities  of  the  moderator  are  quite  simple,  since  the  mail
683
684 system handles distribution to subscribers automatically.  In some interest groups,
685
686 instead of each separate message being distributed directly to subscribers, a batch
687
688 of (hopefully related) messages are put into a digest format by the moderator and
689
690 then sent to the subscribers.  (This is similar to a newsletter format.)  Although
691
692 this requires more work on the part of the moderator and introduces delays, such
693
694 groups tend to be better organized.
695
696
697         Unfortunately, some problems arise with the scheme outlined above.  First,
698
699 if two users on the same host subscribe to the same interest group, two copies of
700
701 the message are delivered.  This is wasteful of both processor and disk resources at
702
703 that host.
704
705
706         Second, some groups carry a lot of traffic.  Although subscription to a group
707
708 does indicate interest on the part of a subscriber, it is usually not interesting to get
709
710 50 or so messages delivered each day to the user's private maildrop, interspersed
711
712 with personal mail,  which is likely to be of a much more important and timely
713
714 nature.
715
716
717         Third, if a subscriber's address in a distribution list becomes "bad" somehow
718
719 and causes failed mail to be returned, the originator of the message is normally
720
721 notified.  It is not uncommon for a large list to have several bogus addresses.  This
722
723 results in the originator being flooded with "error messages" from mailers across
724
725
726 _____________________________________
727 2  The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
728
729 form under stand-alone MH.
730 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              9
731
732
733 the Internet stating that a given address on the list was bad.  Needless to say, the
734
735 originator usually does not care if the bogus addresses got a copy of the message
736
737 or not.  The originator is merely interested in posting a message to the group at
738
739 large.  On the other hand, the moderator of the group does care if there are bogus
740
741 addresses on the list, but ironically does not receive notification.
742
743
744         To solve these problems, the UCI BBoards facility introduces a new entity
745
746 into the picture:  a distribution channel.  All interest group mail is handled by the
747
748 special mail system component.  The distribution address for an interest-group
749
750 maps mail for that interest-group to the distribution channel, which then performs
751
752 several actions.  First, if local delivery is to be performed, a copy of the message is
753
754 placed in a global maildrop for the interest group with a timestamp and a unique
755
756 number.  Local users can read messages posted for the interest group by reading
757
758 this "public" maildrop.  Second, if further distribution is to take place, a copy of
759
760 the message is sent to the distribution address in such a way that if any of the
761
762 addresses are bogus, failure notices will be returned to the local maintainer of the
763
764 group address list, rather than the originator of the message.
765
766
767         This scheme has several advantages:  First, messages delivered to the local
768
769 host are processed and saved once in a globally accessible area.  The UCI BBoards
770
771 facility supports software which allows a user to query an interest group for new
772
773 messages and to read and process those messages in the MH-style.  Second, once
774
775 a host administrator subscribes to an interest group, each user may join or quit
776
777 the list's readership without contacting anyone.  Third, a hierarchical distribution
778
779 scheme can be constructed to reduce the amount of delivery effort.  Finally, errors
780
781 are prevented from propagating.  When an address on the distribution list goes
782
783 bad, the list moderator who is responsible for the address is notified.  If a local
784
785 moderator does not exist,  then the local PostMaster is notified (not the global
786
787 group moderator).
788
789
790         In addition to solving the problems outlined above, the UCI BBoards facility
791
792 supports several other capabilities.  BBoards may be automatically archived in
793
794 order  to  conserve  disk  space  and  reduce  processing  time  when  reading  current
795
796 items.   Also,  the  archives  can  be  separately  maintained  on  tape  for  access  by
797
798 interested researchers.
799
800
801         Special  alias  files  may  be  generated  which  allow  the  MH  user  to  shorten
802
803 address entry.  For example, instead of sending to SF-Lovers@Rutgers, a user of
804
805 MH usually sends to ``SF-Lovers''          and the MH aliasing facility automatically
806
807 makes the appropriate expansion in the headers of the outgoing message.  Hence,
808
809 the user need only know the name of an interest group and not its global network
810
811 address.
812 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             10
813
814
815         Finally, the UCI BBoards facility supports private interest groups using the
816
817 UNIX  group  access  mechanism.  This  allows  a  group  of  people  on  the  same  or
818
819 different machines to conduct a private discussion.
820
821
822         The practical upshot of all this is that the UCI BBoards facility automates the
823
824 vast majority of BBoards handling from the point of view of both the PostMaster
825
826 and the user.
827
828
829         MH provides three programs to deal with interest groups.  The bbc program
830
831 is used to check on the status of one or more groups, and to optionally start an
832
833 MH shell on those groups which the user is interested in.  The bbl program can be
834
835 used to manually perform maintenance on a discussion group beyond the normal
836
837 automatic  capabilities  of  the  UCI  BBoards  facility.  Finally,  the  msh  program
838
839 implements  an  MH  shell  for  reading  BBoards,  in  which  nearly  all  of  the  MH
840
841 commands are implemented in a single program.
842
843
844         Observant  readers  may  note  that  the  use  of  msh  is  contrary  to  the  MH
845
846 philosophy of using relatively small, single-purpose programs.  Sadly, the authors
847
848 admit that this is true.  In an effort to minimize use of system resources however,
849
850 BBoards are kept in maildrop format instead of folders.3  Some research has gone
851
852 into overcoming this problem to restore MH's purity of purpose, but all solutions
853
854 proposed  to  date  are  either  unworkable  or  require  significant  recoding  of  MH's
855
856 internals.
857
858
859 Bursting
860
861         Internet interest group mail is often sent out in digest form.  The experienced
862
863 MH user may wish to deal with the digest messages on an individual basis, however.
864
865 The burst program allows the MH user to extract these digest messages, and store
866
867 each as an individual MH message.
868
869
870         Burst will also extract forwarded messages generated by forw (or the forwarded
871
872 message  in  the  error  report  generated  by  push,  as  described  above).  Although
873
874 burst cannot always decapsulate messages encapsulated by sites not running MH,
875
876 it adheres to the proposed standard described in [MRose85b].
877
878
879
880 _____________________________________
881 3  When the message transport system delivers a message to a user it stores it in a single file, called
882
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
888
889
890 Distributed Mail
891
892         The  ARPA  Internet  community  consists  of  many  types  of  heterogeneous
893
894 nodes.  Some  hosts  are  large  mainframe  computers,  others  are  personal  work-
895
896 stations.  All  communicate  using  the  milstd  TCP/IP  protocol  suite[IP, TCP].
897
898 Messages which conform to the Standard for the Format of ARPA Internet Text
899
900 Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
901
902
903         On smaller nodes in the ARPA Internet, it is often impractical to maintain
904
905 a message transport system (e.g., SendMail).  For example, a workstation may not
906
907 have sufficient resources (cycles, disk space) in order to permit an SMTP server
908
909 and associated local mail delivery system to be kept resident and continuously
910
911 running.  Furthermore, the workstation could be off-net for extended periods of
912
913 time.  Similarly, it may be expensive (or impossible) to keep a personal computer
914
915 interconnected to an IP-style network for long periods of time.  In other words, the
916
917 node is lacking the resource known as "connectivity".
918
919
920         Despite  this,  it  is  often  desirable  to  be  able  to  manage  mail  with  MH  on
921
922 these smaller nodes, and they often support a user agent to aid the tasks of mail
923
924 handling.  To solve this problem,  a network node which can support a message
925
926 transport  entity  (known  as  service  host)  offers  a  maildrop  service  to  these  less
927
928 endowed nodes (known as client hosts).  The Post Office Protocol[JReyn84] (POP)
929
930 is intended to permit a workstation to dynamically access a maildrop on a service
931
932 host to pick-up mail.4  The level of access includes the ability to determine the
933
934 number of messages in the maildrop and the size of each message, as well as to
935
936 retrieve and delete individual messages.  More sophisticated implementations of the
937
938 POP server are able to distinguish between the header and body portion of each
939
940 message, and send n lines of a message to the POP client.  This capability is useful
941
942 in thinly connected environments where conservation of bandwidth is important.
943
944 By utilizing a more intelligent POP client, a user may generate "scan listings" and
945
946 decide dynamically which messages are worth taking delivery on.  The philosophy
947
948 of the POP is to put intelligence in the POP clients and not the POP servers.
949
950
951         The current release of MH supports the above model fully.  A POP client
952
953 program is available to retrieve a maildrop from a POP service host.  In addition,
954
955 using  the  SMTP  configuration  for  delivery  in  MH  (either  in  conjunction  with
956
957 SendMail  or  the  MMDF),  a  user  is  able  to  specify  a  search-list  of  service  hosts
958
959 (and/or networks) to try to post mail.  Using this search-list, when an MH user
960
961 posts a draft,  the post program will attempt to establish an SMTP connection
962
963 with  each  host  in  the  search-list  to  post  the  message  until  it  succeeds.  Initial
964
965
966 _____________________________________
967 4  Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
968
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
974
975
976 experimentation  using  the  POP  and  MH  in  a  local  network  environment  has
977
978 proved quite successful.
979
980
981
982 User Interface Issues in MH
983
984         At this point, it is perhaps useful to take a step backwards and examine the
985
986 success and problems of MH's approach to user interfaces.
987
988
989 Creeping Featurism
990
991         A complaint often heard about systems which undergo substantial develop-
992
993 ment by many people over a number of years, is that more and more options are
994
995 introduced which add little to the functionality but greatly increase the amount of
996
997 information a user needs to know in order to get useful work done.  This is usually
998
999 referred to as creeping featurism.
1000
1001
1002         Unfortunately MH, having undergone six years of off-and-on development by
1003
1004 ten or so well-meaning programmers (the present authors included), suffers mightily
1005
1006 from this.  For example, the send command has twenty-five visible switches, and at
1007
1008 least nine hidden switches, for a total of thirty-four.  The poor user who types
1009
1010
1011            send -help
1012
1013
1014 watches the options scroll off the screen (since the `-help'      switch also lists out
1015
1016 four other lines of information).5   The sad part is that all of these switches are
1017
1018 useful in one form or another.
1019
1020
1021         There are a lot of good things to be said for the "one program, one function"
1022
1023 philosophy of system design.  In the MH case, however, each program really does
1024
1025 only  one  mail  handling  activity  (with  a  few  minor  exceptions).   The  options
1026
1027 associated with each command are present to modify the program's behavior to
1028
1029 perform similar, but slightly different tasks.  In further defense of MH, note that
1030
1031 there are 32 MH commands at present, all performing different tasks.
1032
1033
1034         The problem with creeping featurism though, is that while the functionality
1035
1036 of the system increases sub-linearly, the complexity of the system increases linearly.
1037
1038 That is, although the number of switches that a program takes might double, it is
1039
1040 unlikely that the program's functionality or capabilities will double.
1041
1042
1043
1044 _____________________________________
1045 5  Recently, this was fixed by compressing the way in which switches are presented. The solution is
1046
1047 only temporary however, as send will no doubt acquire an endless number of switches in the years
1048 to come.
1049 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             13
1050 _______________________________________________________________________________________________________________
1051
1052 To:
1053 cc:
1054 Bcc:
1055 Fcc:  outbox
1056 Fcc:
1057 Subject:
1058 Reply-To:
1059 --------
1060
1061
1062                                                  Figure 2
1063
1064 ______________________________________________Draft_Skeleton___________________________________________________
1065
1066 _______________________________________________________________________________________________________________
1067
1068 To:  <reply-to_from>
1069 cc:  <?to_cc><to>,<cc>
1070 Fcc:  +outbox
1071 Fcc:  <?fcc><fcc>
1072 Subject:  <?subject>Re:  <subject>
1073 In-reply-to:  <?date><?message-id>Your  message  of  <date>.
1074        <message-id>
1075 In-reply-to:  <?date><!message-id>Your  message  of  <date>.
1076 --------
1077
1078
1079                                                  Figure 3
1080
1081 _____________________________________________Reply_Template____________________________________________________
1082
1083
1084
1085 Templates versus Switches
1086
1087         One  way  to  trim  the  explosion  of  available  options,  while  still  increasing
1088
1089 functionality, is to introduce options with a richer domain.  Hence, instead of using
1090
1091 options which take on or off forms or simple numeric or string values, the possible
1092
1093 values which an option might take on is given a large space.  There are several ways
1094
1095 that this might be accomplished.
1096
1097
1098         The comp,  dist,  and forw programs use draft skeletons (simple form fill-in
1099
1100 files) to construct the general format of the draft being composed.  An example of
1101
1102 a draft skeleton used for composing new messages (by comp) is shown in Figure 2.
1103
1104 The approach is to let the user specify (and later edit) both arbitrary headers of
1105
1106 draft and the body of the draft.  Note while most of the fields are empty, the first
1107
1108 ``Fcc:''       field already contains a value.  By using the simple prompting editor,
1109
1110 prompter, the user can speedily enter the headers of the message.  The prompter
1111
1112 program given the skeleton in Figure 2 would prompt the user for the contents
1113
1114 of each field, except for the second ``fcc:''     , which it would include verbatim.
1115
1116 It would then read the body of the message up to an end-of-file.  Naturally, the
1117
1118 MH user is free to use any editor to edit any part of the draft (headers or body).
1119
1120 This example demonstrates the flexibility achieved by not limiting what headers a
1121
1122 draft may contain (which most mail sending programs do), while still retaining the
1123
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 _______________________________________________________________________________________________________________
1127
1128 From:  <?me>Message  Agent  "<<me>>
1129 To:  <reply-to_from>
1130 Fcc:  +rcvtrip
1131 Fcc:  <?fcc><fcc>
1132 Subject:  <?subject>BEEP!  Re:  <subject>
1133 Subject:  <!subject>BEEP!
1134 In-reply-to:  <?date><?message-id>Your  message  of  <date>.
1135        <message-id>
1136 In-reply-to:  <?date><!message-id>Your  message  of  <date>.
1137 --------
1138
1139
1140       This  is  an  automatic  reply.   Feel  free  to  send  additional  mail,  as  only
1141       this  one  notice  will  be  generated.
1142
1143
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.
1146
1147
1148 /mtr
1149
1150
1151                                                  Figure 4
1152
1153 __________________________________The_tripcomps______Reply_Template____________________________________________
1154
1155
1156
1157         Another  more  interesting  approach  is  used  by  the  repl  command,  which
1158
1159 constructs a draft in reply-to a previously received message.  Instead of adding
1160
1161 switches to indicate which fields of the draft should be derived from the message
1162
1163 being replied-to, and how they should be derived, a single option, the ability to
1164
1165 specify a template, was made available.  An example of a reply template is shown
1166
1167 in Figure 3.  Put simply,  based on the presence of certain fields in the message
1168
1169 being replied-to, and a few switches given by the user, using the reply template,
1170
1171 repl generates the reply draft automatically.
1172
1173
1174         This facility, for example, can be used to generate automatic replies.6  One
1175
1176 function  might  be  to  write  a  rcvtrip  shell  script  which  automatically  answered
1177
1178 messages when mail wasn't being read for a period of time (e.g., while attending a
1179
1180 conference).  An example of a reply template at the heart of such a script is shown
1181
1182 in Figure 4.
1183
1184
1185         Finally, another application might be to utilize the highly useful letter bomb
1186
1187 protocol.7  The important thing to note about this template is that it generates
1188
1189 not only the headers of the reply draft (with a creative ``Reply-to:''         address),
1190
1191 but the body as well.  Hence, the commands
1192
1193
1194            repl -form bombcomps -noedit ; rmm
1195
1196
1197 _____________________________________
1198 6  MH supports the notion of a user-defined mail hook which is invoked each time a user receives
1199
1200 mail.
1201 7  The  authors  wish  to  credit  Ron  Natalie  of  the  Ballistics  Research  Laboratory  in  Aberdeen,
1202
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 _______________________________________________________________________________________________________________
1206
1207 To:  <reply-to_from>
1208 cc:  <?to_cc><to>,<cc>
1209 Fcc:  +outbox
1210 Fcc:  <?fcc><fcc>
1211 Subject:  <?subject>Re:  <subject>
1212 In-reply-to:  <?date><?message-id>Your  message  of  <date>.
1213        <message-id>
1214 In-reply-to:  <?date><!message-id>Your  message  of  <date>.
1215 Reply-To:  /dev/null
1216 --------
1217
1218
1219                                    "
1220                                   *-XXX
1221                                    /    XX
1222                                            X
1223                                               X
1224                                                X
1225                                                X
1226                                                X
1227                                           IIIIIIIII
1228                                           IIIIIIIII
1229                                           IIIIIIIII
1230                                           IIIIIIIII
1231                                           XXXXXXXXX
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
1251                                           XXXXXXXXX
1252
1253
1254                                                  Figure 5
1255
1256 _________________________________The_bombcomps________Reply_Template___________________________________________
1257
1258
1259
1260            What now? push
1261 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             16
1262 _______________________________________________________________________________________________________________
1263
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
1271 :
1272 body:nocomponent,overflowoffset=0
1273
1274
1275                                                  Figure 6
1276
1277 ____________________________________________Display_Template___________________________________________________
1278
1279
1280
1281 are very handy for dealing with disturbing mail in a straight-forward manner.  Of
1282
1283 course, repl could be linked to bomb in the user's bin/   directory and an appropriate
1284
1285 line could be added to the user's MH profile, in order to further shorten type-in.
1286
1287
1288         A variation on the reply template is the display template.  A display template,
1289
1290 as used by the mhl program, contains instructions on how to format a message.  In
1291
1292 addition to being used by show, et. al., the forw program can also use a display
1293
1294 template to format each message being forwarded.  Similarly, although repl uses a
1295
1296 reply template to construct the draft being composed, it also may use a display
1297
1298 template to format the body of the message being replied-to for enclosure in the
1299
1300 reply.  Furthermore, the post program may use a display template to format the
1301
1302 body of a blind-carbon-copy.  An example of a display template used for formatting
1303
1304 forwarded messages is shown in Figure 6.
1305
1306
1307         As with reply templates, display templates can offer a lot of functionality.
1308
1309 For example, the one line display template:
1310
1311
1312            body:nocomponent,overflowtext=,overflowoffset=0,width=10000
1313
1314
1315 can be used to extract the body of a message, while ignoring the headers.  Hence,
1316
1317 if a shar archive arrived in the mail, a convenient way to unpack it, assuming the
1318
1319 above display template was called mhl.body     , would be:
1320
1321
1322            show -form mhl.body _ sh
1323
1324
1325
1326         The biggest win with display templates, of course, is that all those annoying
1327
1328 header lines which mailers everywhere generate can be simply and easily filtered
1329
1330 out.
1331 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             17
1332
1333
1334 Modularity versus Monolithicity
1335
1336         Since MH is a set of programs which perform separate tasks, as opposed to
1337
1338 being a single, monolithic program, the power of the shell is used directly to aid in
1339
1340 mail-handling.  One powerful capability which this design achieves is the ability to
1341
1342 extend the MH command set, by developing shell scripts which use the standard
1343
1344 MH programs to accomplish complicated or specialized tasks.
1345
1346
1347         For  example,  in  the  MH  distribution  there  is  a  shell  script  called  mpick
1348
1349 (shown in Figure 7) which tries to locate all the messages which pertain to a given
1350
1351 discussion, by looking at the ``Message-ID:''           and ``In-reply-to:''           headers,
1352
1353 to find matching message-ids.8
1354
1355
1356         Unfortunately, some parts of MH are somewhat monolithic.  An example of
1357
1358 this is the What  now?  prompt.  There are only a few options at this prompt, and
1359
1360 one cannot give a normal shell command.  Some MH users seem to feel that more
1361
1362 options should be added to the What  now?  prompt, such as an insert-file option.  It
1363
1364 was argued that just about any editor would allow you to insert a file, and another
1365
1366 What  now?  option was not needed.  These users persisted, however, so the problem
1367
1368 was solved, by writing a trivial shell script "editor" (see Figure 8) which could be
1369
1370 invoked by the edit option:
1371
1372
1373            What  now? edit append filename
1374
1375
1376
1377         A better interface at this point is really needed, however.  One possibility is to
1378
1379 simply pass any unrecognized commands on to a shell for interpretation, supplying
1380
1381 the  path  name  of  the  draft  file  as  an  argument.  A  solution  which  shows  more
1382
1383 promise is to give you a sub-shell instead of the What  now?  prompt,  and setup
1384
1385 certain envariables so that the MH commands would act upon the draft   by default.
1386
1387 For example, show with no `msgs'     arguments would show the draft instead of the
1388
1389 current message.  This alternative has recently been implemented and is under
1390
1391 testing.
1392
1393
1394
1395 The MH Distribution
1396
1397         The  mh.5  distribution  is  now  briefly  described,  both  in  terms  of  static
1398
1399 configuration methods and dynamic tailoring.  Appendix B describes the mechanics
1400
1401 of receiving an mh.5 distribution.
1402
1403
1404
1405 _____________________________________
1406 8  Note that the shell scripts included in the MH distribution are written for the Bourne shell, and
1407
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 _______________________________________________________________________________________________________________
1412
1413 :  'mpick  -  relate  messages  /mtr'
1414 PATH=:/bin:/usr/bin:/usr/ucb:/usr/local:/usr/local/lib/mh;  export  PATH
1415 F=""  M=""  S=""
1416
1417
1418 for  A  in  $*
1419 do
1420       case  $A  in
1421            -*)       S="$S  $A"  ;;
1422
1423
1424            +*_@*)   case  $F  in
1425                            "")   F=$A  ;;
1426                            *)    echo  "mpick:  only  one  folder  at  a  time"  1>&2
1427                                   exit  1  ;;
1428                       esac  ;;
1429
1430
1431            *)        M="$M  $A"  ;;
1432       esac
1433 done
1434
1435
1436 S="$S  -sequence  hits  -list  -nozero"
1437
1438
1439 if  mark  $F  all  -add  -sequence  hits;
1440       then  mark  $F  all  -delete  -sequence  hits;
1441       else  exit  1;
1442 fi
1443
1444
1445 for  A  in  $-M-cur"
1446 do
1447       for  C  in  `mhpath  $F  $A`
1448       do
1449            if  [  -r  $C  ];
1450                 then
1451                       I=`mhl  -form  mhl.msgid  $C`;
1452                       case  $I  in
1453                            "")   echo  "no  message-id  in  message  `basename  $C`"  1>&2  ;;
1454                            *)    pick  --in-reply-to  "$I"  $S  ;;
1455                       esac
1456                 else
1457                       echo  "message  $A  doesn't  exist"  1>&2;  exit  1;
1458            fi
1459       done
1460 done
1461
1462
1463 exit  0
1464
1465
1466                                                  Figure 7
1467
1468 ____________________________________________The_mpick_Script___________________________________________________
1469
1470
1471
1472 Configurable MH
1473
1474         The  MH  distribution  currently  runs  on  a  large  number  of  different  UNIX
1475
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 _______________________________________________________________________________________________________________
1479
1480 :  'append  -  stupid  append  editor  for  MH  -  /jlr'
1481 case  $#  in
1482     1_2)  case  $#  in
1483                 1)  F=$1;  echo  -n  "Append  file:  "  1>&2;  read  A  ;;
1484                 2)  F=$2;  A=$1  ;;
1485            esac
1486            cat  $A  <  /dev/null  >>  $F  ;;
1487        *)  echo  "append:  arg  count"  1>&2  ;  exit  1  ;;
1488 esac
1489 exit
1490
1491
1492                                                  Figure 8
1493
1494 ___________________________________________The_append_Editor___________________________________________________
1495
1496 _______________________________________________________________________________________________________________
1497
1498 bin       /usr/local
1499 bboards  on
1500 editor   /usr/local/prompter
1501 etc       /usr/local/lib/mh
1502 mail      /usr/spool/mail
1503 manuals  local
1504 mts       sendmail/smtp
1505 news      off
1506 options  BSD42
1507 options  MHE  NETWORK
1508 options  UCI
1509
1510
1511                                                  Figure 9
1512
1513 ___________________________________Sample_MH_Configuration_File________________________________________________
1514
1515
1516
1517 is specific to a particular target environment is enabled via the C-preprocessor
1518
1519 ``# ifdef''       mechanism, so compilation under different versions of UNIX is trivial.
1520
1521 There are, however, a large number of compile-time options which may vary from
1522
1523 site to site, so an automated configuration method was needed.
1524
1525
1526         The MH-installer must create a configuration file,  which contains a list of
1527
1528 the compile-time options and the values which are desired for them.  Compile-time
1529
1530 options include the installation location for MH, what kind of message transport
1531
1532 system is to be used, and the default editor for the installation.  An example of
1533
1534 such a configuration file is shown in Figure 9.
1535
1536
1537         After creating this file (several examples are included in the distribution), the
1538
1539 installer runs the mhconfig program, which customizes the Makefile    s and some of
1540
1541 the programs, for that site's particular installation.  No hand-editing of any source
1542
1543 code should be necessary, under normal circumstances.
1544 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             20
1545 _______________________________________________________________________________________________________________
1546
1547 mmdfldir:          /usr/spool/mail
1548 mmdflfil:
1549 mmdelim1:          "001"001"001"001"n
1550 mmdelim2:          "001"001"001"001"n
1551 mmailid:           0
1552 lockstyle:        0
1553 lockldir:
1554
1555
1556 hostable:          /usr/local/lib/mh/hosts
1557 servers:           localhost  "01localnet
1558
1559
1560                                                 Figure 10
1561
1562 _______________________________________Sample_MTS_Tailor_File__________________________________________________
1563
1564
1565
1566 Interface to the Message Transport System
1567
1568         MH will run with a number of message transport systems, including SendMail,
1569
1570 MMDF-II, and a small stand-alone system.  One flexible method of posting mail
1571
1572 is through an SMTP connection.  There are a couple of major wins in using this
1573
1574 configuration:  First, none of the MH programs need to know where the interface
1575
1576 programs to the message transport system are located, which makes them easier
1577
1578 to move between systems.  Second, mail can be posted on relay hosts, and the local
1579
1580 host of an MH user may not need a message transport system at all (as alluded to
1581
1582 in the preceeding discussion on the POP).
1583
1584
1585         Those parts of MH which interact with the local message transport agent
1586
1587 read additional tailoring information when they start.9  This information includes
1588
1589 the location of standard and alternate maildrops, maildrop delimiter strings, the
1590
1591 locking  directory  and  locking  style,  and  other  tailoring  information  specific  for
1592
1593 the particular message transport system in use (e.g., the default server search-list
1594
1595 when mail is posted with the SMTP). In most cases, by using a tailor file, each site
1596
1597 running a similar MH configuration is able to simply transfer MH binaries between
1598
1599 hosts.  An example of such a tailor file is shown in Figure 10.
1600
1601
1602         A  continuing  question  which  is  often  raised  is  how  intelligent  should  user
1603
1604 agents (like MH and UCB Mail ) be with respect to the environment in which they
1605
1606 operate.  At present, MH likes to determine the official hostnames for addresses
1607
1608 when posting mail.  Many argue that this is improper or unnecessary behavior
1609
1610 for  a  user  agent,  and  that  the  local  message  transport  agent  should  handle
1611
1612 these  functions.   Unfortunately,  this  implies  that  the  message  transport  agent
1613
1614 should munge headers when mail is posted to remove local host aliases and only
1615
1616 permit address fields with fully-qualified addresses.  Sadly, neither SendMail nor
1617
1618 MMDF-II  really  gets  this  right  (flames  to  /dev/null     please).   The  current  MH
1619
1620 maintainers believe that the resolution of host aliases to official names should be
1621
1622 a well-supported interface with the local message transport agent.  However,  to
1623
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
1627
1628
1629 provide equal time to those who hold opposite views, MH supports a configuration
1630
1631 option called ``DUMB''       which disables MH's attempts to resolve addresses into
1632
1633 fully-qualified strings.
1634
1635
1636
1637 Concluding Remarks
1638
1639         While MH has undergone significant development since the original Rand
1640
1641 release, the authors have tried to keep the fundamental concepts of MH unchanged.
1642
1643 The authors have continually had to battle against well-meaning MH users who
1644
1645 wanted to make MH more like other (less powerful) user agents.  More and more
1646
1647 "features"  were  often  suggested  for  MH,  usually  at  the  expense  of  making  MH
1648
1649 less  general,  and  more  specific.  In  nearly  all  cases,  the  "features"  which  these
1650
1651 users wanted were already present in MH in a slightly different form, or could be
1652
1653 realized by simply writing a short shell script.  A classic example is the repeated
1654
1655 requests  by  one  user  to  have  dist  take  a  list  of  messages  rather  than  a  single
1656
1657 message and distribute each one of them in turn.  A simple shell script which called
1658
1659 dist repeatedly, perhaps with "canned" arguments so the user typed in addressing
1660
1661 information only once, would easily meet this request.
1662
1663
1664         A number of MH comands have a large number of options.  When adding
1665
1666 options, the authors have tried to make the options general, while still accomodating
1667
1668 the  requests  of  specific  users.   An  example  of  a  specific  request  which  was
1669
1670 implemented  as  a  general  feature  is  the  ``Previous-Sequence''              profile  entry
1671
1672 (mentioned above).  If you use this profile entry, every MH command is forced to
1673
1674 write out context    changes, making every command somewhat slower.  Since only a
1675
1676 few users wanted this capability, it was implemented in such a way that users who
1677
1678 didn't want it, didn't have to pay the cost of slowing down every MH command.
1679
1680
1681         MH has a powerful tailoring capability provided by the .mh_profile    .  Using
1682
1683 profile entries, users may customize their own environment without affecting others.
1684
1685 Novice users often take advantage of the MH-tailoring capabilities to try to make
1686
1687 MH work similarly to other user agents they've used.  This has the advantage of
1688
1689 allowing them to quickly begin using MH to handle their mail.  However, since these
1690
1691 novice users don't take advantange of all the capabilities of MH, they frequently
1692
1693 will complain about things they think can't be done with MH, or could be done
1694
1695 "better" some other way.  Fortunately,  as these users become more experienced
1696
1697 with  both  MH  and  UNIX,  they  can  modify  their  environment  to  take  better
1698
1699 advantage of all of MH's capabilities.  Novice MH users who see features lacking
1700
1701 are encouraged to take a better look at what MH can do, instead of trying to make
1702
1703 MH into something it isn't.  This may sound rather inflammatory, but it would
1704
1705 really be a much nicer world for us all if users of software systems would read the
1706
1707 manual prior to asking questions.
1708
1709
1710         For  a  moment,  let's  consider  the  evolution  of  one  MH  feature  which  has
1711
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
1714
1715
1716 mail, the number of messages that could be processed in a given amount of time
1717
1718 increased greatly.  As the volume of messages increased however, it became clear
1719
1720 that  some  MH  operations  were  too  slow,  in  particular  the  interaction  with  the
1721
1722 (slow) message transport system.  To overcome this problem, the push option was
1723
1724 added at the What  now?  prompt.  Originally, this option was hidden from novice
1725
1726 users and did little more than send the message in the background:  any output
1727
1728 generated by the background send process would be printed asyncronously on the
1729
1730 terminal.  If a message failed posting with the message transport system, it would
1731
1732 simply be left in the draft   file.
1733
1734
1735         Gradually, other features were added to push.  Since users wanted to be able
1736
1737 to send more than one draft at a time,  push was changed to optionally rename
1738
1739 the draft file before posting it.  (This is what the hidden `-unique'       option does.)
1740
1741 Having message transport system diagnostics written asyncronously on the user's
1742
1743 terminal was annoying, so push was made to intercept these diagnostics, and mail
1744
1745 the user a report containing them.  Although the diagnostic report mailed back by
1746
1747 push contains the name of the draft which failed, a useful added feature was the
1748
1749 ability to have push include the failed draft as well.  Eventually, the draft-folder
1750
1751 mechanism  was  implemented  to  make  handling  multiple  message  drafts  much
1752
1753 easier.
1754
1755
1756 TODO
1757
1758         There are, no doubt, a number of improvements which could be made to MH.
1759
1760 At the present time, what further development should MH suffer?  Although not
1761
1762 by any means inclusive, here's a list:
1763
1764
1765            1.  Performance Enhancements
1766
1767                Hardware  gets  faster  all  the  time,  but  people  always  complain  that
1768
1769                software is too slow.  Owing to its user interface style, MH is somewhat
1770
1771                slower than monolithic programs like UCB Mail.  It would be nice if MH
1772
1773                could be tuned or accelerated somehow.
1774
1775
1776            2.  Port to System 5
1777
1778                MH  runs  on  4.2bsd  UNIX  and  Version  7  variants.  It  should  not  be
1779
1780                difficult to port MH to a SYS5 environment.  This should significantly
1781
1782                increase the number of hosts on which MH can run.  The authors, lacking
1783
1784                a SYS5 machine (and experience with SYS5) to perform the port, are
1785
1786                actively seeking a System 5 guru to attempt this feat.
1787
1788
1789            3.  Interface to the Network News
1790
1791                Not all sites that run MH are in the ARPA Internet, and as such the
1792
1793                UCI BBoards facility may not be of much use to them.  A good MH
1794
1795                interface to the network news would allow users on hosts with a news
1796
1797                feed to employ the same interface for reading and sending both mail
1798
1799                and news.
1800 \fReprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             23
1801
1802
1803          4.  Programmed Instruction for Beginners
1804
1805              The complexity of MH is often intimidating to new users.  It would be
1806
1807              nice to develop a set of learn lessons for those users who don't like man
1808
1809              pages and non-interactive tutorials.
1810
1811
1812          5.  Message List Expansion
1813
1814              At  present,  when  a  list  of  messages  is  given  to  an  MH  command,  it
1815
1816              expands the list and processes each message in numerical order rather
1817
1818              than the order in which the messages were given (e.g., ``show 2 1''
1819
1820              show s message 1 and then message 2).  It would be nice if MH processed
1821
1822              messages in the order they were given.
1823
1824
1825          6.  Context Changes
1826
1827              In nearly all cases, an MH command does not write out context changes
1828
1829              until it is about to exit successfully.  There is some controversy as to
1830
1831              whether this is the correct behavior in all cases.  Some argue that once
1832
1833              an MH command has fully parsed its argument list, the context should
1834
1835              be updated.
1836 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             24
1837
1838
1839                                                References
1840
1841
1842
1843 [DCome83]        D.  Comer.   The  Computer  Science  Research  Network  CSnet:  A
1844
1845                  History  and  Status  Report.  Communications  of  the  ACM  26,  10
1846
1847                  (October, 1983), 747-753.
1848
1849
1850
1851 [DCroc79]        D.H.  Crocker,  E.S.  Szurkowski,  D.J.  Farber.   An  Internetwork
1852
1853                  Memo  Distribution  Facility  _  MMDF.  Appearing  in  Proceedings,
1854
1855                  Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
1856
1857
1858
1859 [DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
1860
1861                  Messages.  Request  for  Comments  822.  ARPA  Internet  Network
1862
1863                  Information Center (NIC), SRI International (August, 1982).
1864
1865
1866
1867 [DKing84]        D.P.  Kingston,  III.   MMDFII:  A  Technical  Review.  Appearing  in
1868
1869                  Proceedings  Usenix  Summer  '84  Conference,  Salt  Lake  City,  Utah,
1870
1871                  1984, pp. 32-41.
1872
1873
1874
1875 [EAllm83]        E.  Allman.    SENDMAIL  _  An  Internetwork  Mail  Router.
1876
1877                  Britton-Lee, Inc., Berkeley, California (July, 1983).
1878
1879
1880
1881 [IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
1882
1883                  Appearing in Internet Protocol Transition Workbook, ARPA Internet
1884
1885                  Network Information Center (NIC), SRI International, 1981.
1886
1887
1888
1889 [JReyn84]        J.K.  Reynolds.   Post  Office  Protocol.  Request  for  Comments  918.
1890
1891                  ARPA Internet Network Information Center (NIC), SRI International
1892
1893                  (October, 1984).
1894
1895
1896
1897 [MButl85]        M. Butler,  J.B. Postel,  et. al.   Post Office Protocol - Version 2.
1898
1899                  Request  for  Comments  937.  ARPA  Internet  Network  Information
1900
1901                  Center (NIC), SRI International (February, 1985).
1902
1903
1904
1905 [MRose84a]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  The  UCI
1906
1907                  BBoards Facility. Department of Computer and Information Sciences,
1908
1909                  University of Delaware (October, 1984).
1910
1911
1912
1913 [MRose85b]       M.T.  Rose,  E.A.  Stefferud.   Proposed  Standard  for  Message
1914
1915                  Encapsulation. Request for Comments 934. ARPA Internet Network
1916
1917                  Information Center (NIC), SRI International (January, 1985).
1918 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             25
1919
1920
1921 [SMTP]           Simple  Mail  Transfer  Protocol.  Request  for  Comments  821.  ARPA
1922
1923                  Internet  Network  Information  Center  (NIC),  SRI  International
1924
1925                  (August, 1982).
1926
1927
1928
1929 [TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
1930
1931                  1778). Appearing in Internet Protocol Transition Workbook, ARPA
1932
1933                  Internet Network Information Center (NIC), SRI International, 1981.
1934 \f
1935
1936                                                      Appendix  A
1937
1938                                                   MH  Commands
1939
1940
1941
1942                MH is composed of several UNIX programs, which in theory are fairly simple
1943
1944        and single-purposed.  These commands are functionally grouped below:
1945
1946
1947                                                     Composing_Mail_________
1948
1949      comp:     compose a message
1950
1951                A program to originate a message.  Usually, a special prompting editor front-
1952
1953                end, prompter, is used to fill-in a composition template with the addressees
1954
1955                of the message, subject, and so forth.
1956
1957
1958        dist :  redistribute a message to additional addresses
1959
1960                A program that re-enters a message previously received by the user into the
1961
1962                message transport system.  Only new addresses are added; the body of the
1963
1964                message is not changed in any way.
1965
1966
1967       forw :   forward messages
1968
1969                A program that encapsulates one or more messages in a new message draft.
1970
1971                In addition, the user may add initial and/or closing comments.
1972
1973
1974        repl :  reply to a message
1975
1976                A program that constructs a reply to a message using a reply template.  The
1977
1978                template mechanism has sufficient generality to permit the user to "program"
1979
1980                the  form  of  the  reply  draft  based  on  the  contents  of  the  message  being
1981
1982                replied-to.
1983
1984
1985       send :   send a message
1986
1987                A  program  that  posts  a  draft  with  the  message  transport  system.   The
1988
1989                send program is usually invoked by one of the four preceding programs, and
1990
1991                performs simple front-end pre-processing prior to invoking the post program.
1992
1993                For  example,  if  invoked  in  push'd  mode,  send  will  immediately  relinquish
1994
1995                control of the user's terminal and post the message in the background.  If
1996
1997                the posting fails, send will send back a failure notice to the user.  If the user
1998
1999                had push'd the sending of the draft, then by default the draft being sent is
2000
2001                encapsulated in the failure notice.  This permits easy burst'ing of the failure
2002
2003                notice to retrieve the original draft.  Otherwise, if the posting was successful,
2004
2005                the draft is marked as having been sent.
2006
2007
2008 whatnow :      prompting front-end for send
2009
2010                A program which is called by comp, et.  al., after the initial draft has been
2011
2012
2013
2014                                                              26
2015 \f           Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             27
2016
2017
2018                  generated.  The  MH  user  can  specify  a  different  whatnow  program,  which
2019
2020                  yields considerable extensibility.
2021
2022
2023       whom:      report to whom a message would go
2024
2025                  A program which examines the addresses of the draft and expands all user-
2026
2027                  defined aliases contained therein.  Optionally,  whom may actually interact
2028
2029                  with  the  message  transport  system  to  determine  the  validity  of  the  final
2030
2031                  addresses.  This program is also usually invoked by comp, et. al.
2032
2033
2034                                                         Posting_Mail______
2035
2036            ali : list mail aliases
2037
2038                  A simple front-end to the MH aliasing mechanism.
2039
2040
2041            ap:   parse addresses 822-style
2042
2043                  A  useful  debugging  tool  for  PostMasters  who  wish  to  examine  how  MH
2044
2045                  interprets an Internet address.
2046
2047
2048     conflict :   search for alias/password conflicts
2049
2050                  Another program used by system administrators to check the consistency of
2051
2052                  MH alias files, and portions of the local message transport agent.
2053
2054
2055 install-mh:      initialize the MH environment
2056
2057                  A program which is automatically executed the first time a user issues an MH
2058
2059                  command.  This program performs once-only initialization of the user's MH
2060
2061                  environment.
2062
2063
2064     mhmail :     send or read mail
2065
2066                  A simple program generally used by other programs to generate messages.
2067
2068                  The mhmail command is similar in purpose to the old BellMail program.
2069
2070
2071          post :  deliver a message
2072
2073                  A  complex  MH  back-end  that  interacts  with  the  local  message  transport
2074
2075                  agent to enter messages through the posting slot.  (See the description of send
2076
2077                  above).
2078
2079
2080                                                         Reading_Mail_______
2081
2082           inc:   incorporate new mail
2083
2084                  A program that interacts with the local message transport agent to retrieve
2085
2086                  messages from the user's maildrop.
2087
2088
2089     msgchk :     check for waiting mail
2090
2091                  A program which reports the status of mail waiting in the user's maildrop.
2092
2093
2094         show :   show (list) messages
2095
2096                  A program which lists messages to its standard output (usually the user's
2097
2098                  terminal), possibly invoking another program to do the actual listing.  Most
2099
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
2102
2103
2104             message.   The  next  and  prev  programs  are  simply  ``show next''         and
2105
2106             ``show prev''        , respectively.
2107
2108
2109     mhl :   produce formatted listings of MH messages
2110
2111             A program which displays a message as directed by a template.  This permits
2112
2113             the user to filter out uninteresting headers and re-arrange other headers to a
2114
2115             particular preference.  In addition to being invoked by show, the mhl program
2116
2117             is optionally also invoked by forw to format each message being forwarded;
2118
2119             invoked  by  repl  to  format  the  body  of  a  message  being  replied-to,  if  that
2120
2121             message is being included in the reply draft; and, invoked by post to format
2122
2123             a message being sent as a blind-carbon-copy.
2124
2125
2126    rmm:     remove messages
2127
2128             A program that removes messages from an MH folder, optionally running a
2129
2130             user-defined program instead of deleting them.  If no program is given, the
2131
2132             messages are "softly" removed, so they may possibly be recovered later.
2133
2134
2135    scan:    produce a one-line-per-message scan listing
2136
2137             A program that generates a scan listing for messages.  Each line of the listing
2138
2139             contains date, source, subject, and possibly the initial body of the message.
2140
2141
2142                                                  Folder_Handling_______
2143
2144  folder :   set/list current folder/message
2145
2146             A program used to list information concerning the current folder, or set the
2147
2148             current folder and/or message.
2149
2150
2151 folders :   list all folders
2152
2153             A program to list information on all folders (actually, just a special case of
2154
2155             the folder command).  Since the MH folder structure may be recursive, the
2156
2157             user can indicate that folders should recursively examine all folders.
2158
2159
2160    refile:  file message(s) in (an)other folder(s)
2161
2162             A program to move (or copy) messages from a source folder to one or more
2163
2164             destination folders.
2165
2166
2167     rmf :   remove folder
2168
2169             A program that deletes a folder and all messages therein.
2170
2171
2172                                                 Message_Selection_______
2173
2174    anno:    annotate messages
2175
2176             A  program  to  arbitrarily  annotate  messages.  If  the  user  so  desires,  after
2177
2178             distributing,  forwarding,  or  replying-to  a  message,  MH  will  automatically
2179
2180             attach an annotation to the original message indicating the date and addresses.
2181
2182
2183   mark :    mark messages
2184
2185             A program to manipulate user-defined sequences (lists of messages).  Usually,
2186
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
2189
2190
2191      pick :  select messages by content
2192
2193              A  program  to  examine  a  list  of  messages  and  choose  those  which  meet
2194
2195              a  particular  selection  criterion.  The  pick  program  is  often  used  in  UNIX
2196
2197              back-quoted operations to pass message sequences to other MH commands.
2198
2199
2200   sortm:     sort messages
2201
2202              A program to sort a list of messages according to the date given in a particular
2203
2204              field.
2205
2206
2207                                            Distribution_List_Handling__________
2208
2209       bbc:   check on BBoards
2210
2211              A  front-end  to  run  msh  on  a  list  of  distribution  lists  which  the  user  isn't
2212
2213              current on.
2214
2215
2216       bbl :  manage a BBoard
2217
2218              A  (depreciated)  program  used  to  manually  manage  the  local  archives  of
2219
2220              a  distribution  list.  These  functions  (archiving,  expunging)  are  performed
2221
2222              automatically by MH.
2223
2224
2225    burst :   explode digests into messages
2226
2227              A program used to decapsulate messages from ARPA Internet digests.  In
2228
2229              addition,  messages  which  have  been  encapsulated  during  forwarding  (i.e.,
2230
2231              with forw ) can also be decapsulated using burst.10
2232
2233
2234      msh:    MH shell (and BBoard reader)
2235
2236              A  monolithic  program  used  to  implement  MH  commands  on  messages
2237
2238              arranged in a single file (maildrop format).  Useful since distribution lists are
2239
2240              kept in this format to minimize consumption of system resources.
2241
2242
2243     pack :   compress a folder into a single file
2244
2245              A program which takes messages stored in MH format and places them in a
2246
2247              single file (using the same format known by msh).
2248
2249
2250                                       Interface_to_the_UNIX_File_System_____________
2251
2252 mhpath:      print full pathnames of MH messages and folders
2253
2254              A program which maps MH-style names into the UNIX file naming convention.
2255
2256
2257
2258      _____________________________________
2259     10  Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
2260
2261      so.
2262 \f
2263
2264                                               Appendix  B
2265
2266                                      Distribution  Mechanics
2267
2268
2269
2270         The mh.5 distribution is available in two forms:
2271
2272
2273            1.  Anonymous FTP
2274
2275                If  you  can  FTP  to  the  ARPA  Internet,  use  anonymous  FTP  to  the
2276
2277                ARPAnet host UDel-Huey [10.2.0.96] and retrieve the file portal/mh.5-
2278
2279                tar.  This is a tar image of size 2.1 MB (approximately).
2280
2281
2282            2.  9-track tape, 1600 bpi, tar format
2283
2284                Otherwise, you can send $ 50.00 to the address below.  This covers the
2285
2286                cost of a magtape,  handling,  and shipping.  In addition,  you'll get a
2287
2288                laser-printed hard-copy of the MH documentation.  The documentation
2289
2290                includes installation guide, MH Tutorial, MH User's Manual, changes
2291
2292                document (from mh.4 to mh.5), and BBoards Manual.
2293
2294
2295                If you go with this option, be sure to include your USPS address with
2296
2297                your check.  Checks should be made payable to
2298
2299
2300                                  Regents of the University of California
2301
2302
2303                It's also a good idea (though not mandatory) to send a computer mail
2304
2305                message to Bug-MH@UCI when you send your check via USPS to ensure
2306
2307                minimal turn-around time.  The distribution address is:
2308
2309
2310                    Support Group
2311
2312                    Attn:  MH Distribution
2313
2314                    Department of Information and Computer Science
2315
2316                    University of California, Irvine
2317
2318                    Irvine, CA 92717
2319
2320
2321
2322                    714/856-6852
2323
2324
2325
2326                Sadly, if you just want the hard-copies of the documentation, you still
2327
2328                have to pay the $ 50.00.  The tar image has the documentation source
2329
2330                (the man is in ROFF format, but the rest are in TEX format).
2331
2332
2333 In addition,  there is some hope that mh.5,  or a successor,  might be found in a
2334
2335 future 4.x Berkeley distribution.
2336
2337
2338
2339                                                       30
2340 \f  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             31
2341
2342
2343         Although MH is not "supported" per se, it does have a bug reporting address.
2344
2345 Normally, the address Bug-MH@UCI is used to report bugs and bug fixes.  There are
2346
2347 however, two discussion groups which concern themselves with MH:
2348
2349
2350            1.  MH-Users@UCI
2351
2352                A discussion group for the MH user community at large.  Appropriate
2353
2354                topics include:  questions about how to use MH, tips on MH usage, and
2355
2356                exchange of MH shell scripts.  All requests to be added to or deleted
2357
2358                from this list, along with problems, questions and suggestions, should
2359
2360                be sent to MH-Users-Request@UCI.
2361
2362
2363            2.  MH-Workers@UCI
2364
2365                A discussion group for MH maintainers and experts.  Appropriate topics
2366
2367                include:  questions on how to configure MH, tips on MH configuration,
2368
2369                exchange of MH bug reports (and fixes).  All requests to be added to or
2370
2371                deleted from this list, along with problems, questions and suggestions,
2372
2373                should be sent to MH-Workers-Request@UCI.
2374
2375
2376 The ``UCI''      host is also known as ``ucivax''      , so a possible UUCP path might
2377
2378 be : : :!ucbvax!ucivax!bug-mh.
2379
2380
2381         Updates to MH are published on the MH-Workers list in the form of context
2382
2383 diffs, and the appropriate distribution images are updated as well.
2384 \f
2385
2386
2387
2388                                                 Contents
2389
2390
2391
2392                                                                                                          Page
2393
2394 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
2395
2396 The MH Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
2397
2398         The MH Environs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       3
2399
2400         An MH Transcript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
2401
2402 Some MH Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
2403
2404         Message Sequences and Selection  . . . . . . . . . . . . . . . . . . . . . . .       5
2405
2406         Draft Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       7
2407
2408         BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       8
2409
2410         Bursting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
2411
2412         Distributed Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      11
2413
2414 User Interface Issues in MH  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
2415
2416         Creeping Featurism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
2417
2418         Templates versus Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . .      13
2419
2420         Modularity versus Monolithicity . . . . . . . . . . . . . . . . . . . . . . . .      17
2421
2422 The MH Distribution  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      17
2423
2424         Configurable MH  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      18
2425
2426         Interface to the Message Transport System  . . . . . . . . . . . . . . . . .      20
2427
2428 Concluding Remarks  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      21
2429
2430         TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      22
2431
2432 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      24
2433
2434 Appendix A: MH Commands  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      26
2435
2436 Appendix B: Distribution Mechanics. . . . . . . . . . . . . . . . . . . . . . . . .      30
2437
2438
2439
2440 _____________________________________
2441 This document (version #1.43) was TEXset April 12, 1990 with DISS.STY v103.
2442
2443
2444
2445                                                        i