Customized generic SPECS/build-nmh-cygwin for nmh.
[mmh] / docs / historical / multifarious.txt
1
2
3
4
5                                MH:  A  Multifarious  User  Agent
6
7
8                                               Marshall T. Rose
9
10                                  Member, Research Technical Staff
11
12                           Northrop Research and Technology Centery
13
14
15
16                                              Einar A. Stefferud
17
18                          President, Network Management Associatesz
19
20                     and Visiting Lecturer, University of California, Irvine
21
22
23
24                                                Jerry N. Sweet
25
26                                         Member, Technical Staff
27
28                                         Local Network Systems./
29
30
31
32                                                   Abstract
33
34
35 The UCI version of the Rand Message Handling System (MH) is discussed, including
36
37 important  extensions.  MH  is  a  powerful  user  agent  which  operates  in  the  ARPA
38
39 Internet  and  UUCP  environments.   In  addition  to  the  basic  functions  provided
40
41 by a user agent,  such as reading and sending mail,  MH has several distinguishing
42
43 characteristics  which  give  the  user  additional  message  handling  capabilities.   In
44
45 particular,  MH  provides  mechanisms  for  organizing  messages,  tailoring  its  own
46
47 behavior, and extending its functions.
48
49
50 This  document  describes  MH  from  several  perspectives.   Particular  emphasis  is
51
52 given to:  the MH user environment, advanced features of MH which have proven to
53
54 be particularly useful for sophisticated users of electronic mail,  MH's potential as
55
56 a record manager, and MH as a part of a distributed mail environment.  Although
57
58 MH as been widely used since its creation in 1979, a discussion of its perspectives
59
60 and functionality has not appeared in the open literature.
61
62
63 ________________________________________
64 y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
65
66 Computer mail: MRose% NRTC@USC-ECL
67 z 17301 Drey Lane, Huntington Beach, CA 92647. Telephone: 714/842-3711.
68
69 Computer mail: EStefferud@ICS.UCI.EDU
70 ./ 130 McCormick Avenue, Suite 102, Costa Mesa, CA 92626. Telephone: 714/754-6631.
71
72 Computer mail: JSweet@ICS.UCI.EDU
73 \f
74
75                                MH:  A  Multifarious  User  Agent
76
77
78
79 Introduction
80
81        The UCI version of the Rand Message Handling System, MH, is a user agent.
82
83 In the interests of brevity, we dispense with the usual definition of terms, refer the
84
85 reader to Figure 1, and simply note that MH is not responsible for delivering mail.
86
87 Rather,  it interacts with a message  transport  system,  MTS, at two interfaces:  it
88
89 sends mail by placing it through a posting slot to the MTS, and it receives mail by
90
91 retrieving it through a delivery slot from the MTS. Besides these two MTS-specific
92
93 activities, the tasks which MH addresses are:  the composition of messages (which
94
95 may,  or  may  not,  be  in  reference  to  previously  sent  messages),  the  reading  of
96
97 messages, and the organization of messages.
98
99
100        MH  was  originally  developed  by  the  Rand  Corporation,  and  initially  was
101
102 proprietary  software.   The  Department  of  Information  and  Computer  Science
103
104 at  University  of  California,  Irvine,  shortly  after  joining  the  Computer  Science
105
106 Network  (CSnet),  acquired  a  copy  of  MH,  and  began  additional  development  of
107
108 the software.  Since that time, the Rand Corporation has declared MH to be in the
109
110 public domain, and the UCI version of MH has passed through four major releases.
111
112
113        Much credit must be given to the initial designers and implementors of MH:
114
115 Bruce Borden, Stockton Gaines, and Norman Shapiro.  Although MH has suffered
116
117 significant  development  at  UCI  since  Rand's  initial  release,  the  fundamental
118
119 concepts  of  MH's  environs  have  remained  nearly  unchanged.   In  addition,  the
120
121 current maintainers of MH gratefully acknowledge the comments of the many sites
122
123 which have run various releases of MH in the past.
124
125
126        MH  runs  on  different  versions  of  the  UNIX1  operating  system  (such  as
127
128 4.2bsd  UNIX  and  various  flavors  of  v7  UNIX).  In  addition,  MH  supports  four
129
130 different  MTS  interfaces:   SendMail[EAllm83],  the  standard  mailer  for  4.2bsd
131
132 systems;  MMDF[DCroc79]  and  MMDF-II[DKing84],  the  Multi-Channel  Memo
133
134 Distribution  Facility  developed  by  the  University  of  Delaware  which  forms  the
135
136 software-backbone  for  CSnet[DCome83]  mail  relays  service;  SMTP,  the  ARPA
137
138 Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
139
140
141        The organization of this paper is straight-forward, given space considerations.
142
143 Initially, the MH philosophy of mail handling is presented, along with a description
144
145 of  the  environment  which  the  MH  user  is  given  to  process  mail.  Following  this,
146
147 certain advanced features of MH are discussed in more detail.  In particular,  the
148
149
150 ________________________________________
151 1  UNIX is a trademark of AT&T Bell Laboratories.
152
153
154
155  Copyright fcl1985, North Holland Publishing Company                                                                1
156 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     2
157 ______________________________________________________________________________________________________________________
158
159
160
161                 UA                                                                                UA
162
163
164
165    POSTING                                                                                            RECEIPT
166
167
168
169                                                         MTS
170
171
172
173                MTA                  MTA                  : : :                : : :              MTA
174
175                                                               RELAYING
176
177
178
179                                                     Figure 1
180
181 ___________________________________________________MTS_model__________________________________________________________
182
183
184
185 notion of a draft folder is introduced, which permits the handling of multiple drafts
186
187 during composition.  In addition, message selection facilities are described.  Next,
188
189 two  different  aspects  of  MH's  power  as  a  software  system  are  discussed:  record
190
191 handling, in which MH facilitates record processing systems; and, how MH can be
192
193 employed in a distributed mail environment.  This latter section raises questions
194
195 as  to  the  location  of  the  posting  and  delivery  slots,  along  with  authentication
196
197 mechanisms.  Finally, we conclude by discussing areas of future development which
198
199 MH may endure.
200
201
202        Although  familiarity  with  MH  is  not  assumed  on  the  part  of  the  reader,
203
204 some knowledge of the UNIX operating system is useful.  Appendix A gives a short
205
206 synopsis of the MH commands.
207
208
209
210 The MH Philosophy
211
212        Although MH has many traits which tend to differ it from other user agents,
213
214 the design aspect which fundamentally influences the interface between MH and
215
216 the user is that it is composed of many small programs instead of one very large
217
218 one.   This  architecture  gives  MH  much  of  its  strength,  since  intermediate  and
219
220 advanced users are able to take advantage of this flexibility.
221
222
223        The key to this flexibility is that the UNIX shell (usually the C shell or the
224
225 Bourne shell), is the user's interface to MH. This means that when handling mail,
226
227 the entire power of the shell is at the user's disposal in addition to the facilities
228
229 which  MH  provides.  Hence,  the  user  may  intersperse  mail  handling  commands
230
231 with other commands in an arbitrary fashion, making use of command handling
232
233 capabilities that the user's shell provides.
234 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     3
235
236
237        Furthermore,  rather than storing messages in a complicated data structure
238
239 within a monolithic file, in MH, each message is a UNIX file, and each folder (an
240
241 object which holds groups of messages) is a UNIX directory.  That is, the directory
242
243 and  file  structure  of  UNIX  is  used  directly.  As  a  result,  any  UNIX  file-handling
244
245 command can be applied to any message.
246
247
248        To the novice,  this may not make much sense or may not seem important.
249
250 From three years of observation,  we have seen that as users of MH have become
251
252 more  experienced  they  have  found  this  capability  to  be  quite  attractive.   In
253
254 addition,  this  approach  is  often  quite  pleasing  to  system  implementors,  because
255
256 it minimizes the amount of coding to be performed and, given a modular design,
257
258 changes to the software system can be maintained easily.  Our empirical findings
259
260 confirm our theoretical expectations regarding the MH architecture.
261
262
263        Having described how MH fits into the UNIX environment,  we now discuss
264
265 the mail handling environment which is available to the MH user.
266
267
268 The MH Environs
269
270        MH  provides  a  complementary  environment  to  the  user's  shell.  While  the
271
272 shell maintains a context related to the user's focus in the file system (a current
273
274 working  directory ), mail handling is performed in a separate mail folder context.
275
276 Operations  on  mail  can  therefore  be  performed  entirely  without  regard  to  the
277
278 current file system context, although MH does not prevent the user from making
279
280 use of that context.  Certain mail handling functions do make use of information
281
282 maintained by the shell.  For instance, by setting certain shell parameters, called
283
284 environment variables, alternate mail handling contexts can be selected.
285
286
287        MH conventions often have direct analogs to shell or file system conventions.
288
289 The shell has a current working directory;  MH has a current mail folder.  When
290
291 the user begins a session on the system,  the user's "home directory" is the base
292
293 context; MH's default base area, the Mail directory, is found under the user's home
294
295 directory.  The user's default shell parameters are set upon beginning a new session
296
297 from a startup profile (called .profile   for sh users or .cshrc   for csh users); the default
298
299 parameters for MH commands are taken from a file called .mh_profile      in the user's
300
301 home directory.  The shell has an environment ; MH has a context     file.  Each of the
302
303 user's directories has files; each of the user's MH folders has messages.
304
305
306        These parallels have a basis not only in MH's high level mail handling model,
307
308 but also in the way low level shell and file system conventions have been abstracted
309
310 to implement MH conventions.  Directories are folders; files are messages.  The Mail
311
312 directory forms the root of a virtual file subsystem within which the user operates
313
314 on mail without disturbing files outside this mail handling domain.
315 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     4
316 ______________________________________________________________________________________________________________________
317
318
319
320         $HOME/      (user's home directory)
321
322
323
324     .mh_profile                           Mail
325
326
327
328       context             inbox/           mhl.format          replcomps             drafts/            chron/
329
330
331
332                                1      2     3                               1
333             sequences                                                                 yr.1984/         yr.1985/
334
335
336
337                                                     Figure 2
338
339                                              MH File Subsystem
340
341 __________________________________________(directories_are_shaded)____________________________________________________
342
343
344
345 The MH Profile
346
347        The  .mh_profile      contains  plaintext  that  describes  the  user's  default  mail
348
349 handling parameters.  An example of an elaborated profile is shown in Figure 3.
350
351
352        Each line in the profile consists of an MH parameter name terminated with
353
354 a colon (`:')  followed by parameter values.  In this example, "global" parameters
355
356 are listed in the first few lines, with program-specific parameters following.  Each
357
358 MH program examines global parameters as well as any parameter with the same
359
360 name by which the program was invoked.  For example, the comp program, which
361
362 is used to compose new messages to be sent, examines the entries:
363
364
365
366              Path___:  The path parameter specifies the name of the MH root directory.
367
368                        This is normally named Mail.
369
370
371            Editor____: The  editor  parameter  specifies  which  text  editor  is  first  invoked
372
373                        to create the header information and body of a message draft.  In
374
375                        most cases, this editor is the MH default editor, prompter.
376
377
378    Draft-Folder______: This parameter specifies a folder within which new message drafts
379
380                        are  to  be  created.  The  draft  folder  mechanism  is  an  advanced
381 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     5
382 ______________________________________________________________________________________________________________________
383
384 Path:  Mail
385 Editor:  prompter
386 prompter-next:  emacs
387 Folder-Protect:  700
388 Msg-Protect:  600
389 Previous-Sequence:  pseq
390 Alternate-Mailboxes:  jsweet@uci-icse,  jsweet@uci-750a
391 Draft-Folder:  drafts
392 Sequence-Negation:  not
393 bbc:         -quiet
394 bboards:   system  mh-workers  sf-lovers  whimsey
395 comp:       -form  mycomponents
396 dist:       -annotate  -inplace
397 folder:     -noheader
398 forw:       -annotate  -inplace  -format
399 mhl:         -noclear
400 next:       -noheader
401 prev:       -noheader
402 prompter:  -prepend
403 repl:       -annotate  -inplace  -cc  me
404 send:       -format  -msgid
405 scan:       -noheader  -time
406 show:       -noheader  -format
407 showproc:  mhl
408
409
410                                                     Figure 3
411
412 ___________________________________________Elaborated_MH_Profile______________________________________________________
413
414
415
416                        feature of MH that is given separate treatment in a later segment
417
418                        of this paper.
419
420
421              comp____: The  program-specific  parameter  examined  by  comp  lists  user-
422
423                        default options.
424
425
426
427 Other programs invoked by comp (e.g.  prompter and send ) would examine their
428
429 own  profile  entries  as  well.  MH  programs  have  reasonable  compiled-in  defaults
430
431 and also permit options to be specified on the shell command line with which the
432
433 programs are invoked.  The order of override precedence is:  command line options
434
435 first, .mh_profile      options second, and compiled-in defaults last.
436
437
438        Each program option is prefixed by a dash (`-') following the UNIX convention.
439
440 Unlike most UNIX-style options, however, the options are words rather than single
441
442 letters.   An  option  may  be  abbreviated  to  an  unambiguous  prefix.   Each  MH
443
444 program  has  a  `-help'      option  that  displays  a  brief  summary  of  the  program's
445
446 available options.
447 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     6
448
449
450 Folders and Messages
451
452        In a typical paper-oriented office, new correspondence arrives and is stacked
453
454 in an "in box", while outgoing correspondence is placed in an "out box".  Processed
455
456 material  is  stored  in  appropriately  labelled  folders  and  filed  away  for  future
457
458 reference.  This state of affairs is modelled in MH with folders and messages, which
459
460 are simply text files (one message per file) stored under the folder directories.  Most
461
462 of the user's folders are kept under the Mail directory.
463
464
465        A  folder  is  given  an  alphanumeric  name  permissible  within  the  UNIX  file
466
467 system structure, and each message stored therein is given a numeric name in the
468
469 range  1..1999.  The  upper  bound  on  message  numbers  was  selected  for  efficient
470
471 access to an internal representation,  an array of bits (a "bit set"),  with each bit
472
473 indicating the presence or absence of a message with a number in the range 1..1999.
474
475 This internal representation also restricts the order of multiple message reference
476
477 to  an  ascending  numerical  sequence.   Other  representations  have  been  studied
478
479 (e.g., an unsorted sparse array of integers), but have been rejected for reasons of
480
481 efficiency.  Folders may contain subfolders, corresponding to UNIX tree-structured
482
483 directories.  For  the  sake  of  completeness,  it  might  be  said  that  "sub-messages"
484
485 exist insofar as message "digests", which nest messages inside other messages, are
486
487 supported by certain advanced MH functions.
488
489
490        The current working folder is the default folder selected for almost all MH
491
492 commands.   To  select  explicitly  a  folder  for  mail  handling  commands  entails
493
494 specifying the name of the folder, prefixing the name with a plus-symbol (`+').  An
495
496 example is:
497
498
499            refile 1 2 3 +chron/yr.1984
500
501
502 This command re-files the selected messages (1 ,  2,  and 3  here) from the current
503
504 working folder to a subfolder under the folder chron     named yr.1984    .  To see the
505
506 folder/subfolder relationship, refer to Figure 2.
507
508
509        The plus-symbol notation is specific to those folders immediately subordinate
510
511 to the Mail directory.  This is analogous to "absolute pathnames" in UNIX_those
512
513 files whose positions in the file system hierarchy are given starting with the system
514
515 root, names prefixed with the slash character (`/').  To specify folders subordinate to
516
517 the current working folder, an at-sign (`@') is substituted for (`+').  It is permitted
518
519 to use UNIX dot notation to specify parent folders.  Referring to Figure 2,  if the
520
521 current working folder were ``+chron/yr.1985''             , then the command
522
523
524            folder @../yr.1984
525
526
527 selects  the  subfolder  yr.1984    in  the  parent  directory  chron  ,  as  the  new  current
528
529 working folder.  While the current working folder is normally the default, it may
530
531 be specified explicitly as ``@.''     .
532 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     7
533 ______________________________________________________________________________________________________________________
534
535 To:  <reply-to_from>
536 cc:  <?to_cc_me><to>,<cc>,<me>
537 Subject:  <?subject>Re:  <subject>
538 In-reply-to:  <?date><?message-id>Your  message  of  <date>.
539        <message-id>
540 In-reply-to:  <?date><!message-id>Your  message  of  <date>.
541 Fcc:  <?fcc><fcc>
542 --------
543
544
545                                                     Figure 4
546
547 _______________________________________Elaborated_Reply_Template______________________________________________________
548
549
550
551 The Context File
552
553        The .mh_profile      contains static information about the user's preferences.  A
554
555 context    file,  contained  in  the  Mail  directory,  contains  the  current  mail  handling
556
557 environment information, which changes as different folders, messages, and named
558
559 message lists (called message sequences ) are selected, created, and updated.  This
560
561 information  is  retained  between  invocations  of  MH  commands,  and  is  preserved
562
563 across system sessions.
564
565
566 Templates
567
568        The  message  draft  composition  functions  (comp,  repl,  forw,  and  dist )  use
569
570 certain default header formats, which may be changed by the user through the use
571
572 of message templates.  The exact format of a template may vary among commands.
573
574 An  example  of  an  elaborated  template  for  the  reply  command  repl  is  shown  in
575
576 Figure 4.
577
578
579        This template specifies how the automatically-generated header for a draft
580
581 message in reply to a source message is to be formatted.  The syntax is capable of
582
583 directing output of header lines based on the presence or absence of other header
584
585 lines in the source message.
586
587
588        Other kinds of templates are used to specify the display formats of messages,
589
590 or to specify the way that messages are to be included in other messages.  This is
591
592 similar to the functionality provided by BBN Hermes[HERMES], another powerful
593
594 mail handling system for Tops202  based systems.
595
596
597 Explaining All This to New Users
598
599        There  do  exist  people  who  do  not  like  MH.3  The  emerging  pattern  of
600
601 complaints from such people indicates that MH accentuates their perceptions of
602
603 the deficiencies of UNIX, to wit, lack of interactivity and lack of easily found help
604
605 facilities.  Also,  some  feel  that  the  proximity  of  the  mail  handling  environment
606
607 to the operating system is a distraction,  rather than an asset.  There have been
608
609 ________________________________________
610 2  Tops20 is a trademark of Digital Equipment Corporation.
611 3  At UCI, these people are reported to be weeded out at an early stage and quietly taken to the
612
613 Ministry of Love to be made uncrimethinkful.
614 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     8
615
616
617 some attempts to make MH more accessible to users who prefer menu-oriented or
618
619 monolithic mail system interfaces.4
620
621
622        In  truth,  users  new  to  UNIX  do  not  always  acclimate  to  MH  easily.   The
623
624 command  set  is  undistinguishably  mixed  in  with  all  other  UNIX  utilities,  and  it
625
626 is  not  easy,  without  aid  of  a  manual,  to  pick  out  the  necessary  commands.  MH
627
628 does not provide any "hand-holding" to guide the user through a minimally useful
629
630 command subset.
631
632
633        Another  problem  is  that  the  initial  default  user  profile  is  too  often  sparse,
634
635 containing only a ``Path:''        parameter.  MH commands will perform adequately
636
637 without specific information in the profile,  so new users often neglect optionally
638
639 useful  MH  capabilities,  eventually  becoming  frustrated  with  the  limited  default
640
641 capabilities,  yet  unable  to  determine  without  researching  through  the  user's
642
643 manual, the necessary options that would solve their problems.
644
645
646        The currently available means for learning how to use MH are:
647
648
649
650                     -  One-on-one tutoring by knowledgeable MH users, which has so far
651
652                        shown the best results with new users.
653
654
655                     -  Consulting  the  MH  Tutorial [MRose84b],  or  the  MH  User's
656
657                        Manual [MRose85a].
658
659
660                     -  Using the msh ("MH shell") program as a training shell to read
661
662                        bulletin boards.  The msh command is an interactive program that
663
664                        provides some help messages and can list available MH commands.
665
666
667
668 No  on-line  tutorial  materials  are  presently  distributed  with  the  mh.5  system,
669
670 although  there  are  some  plans  in  the  works  to  provide  a  program  to  help  with
671
672 setting  up  the  user  profile  that  would  also  provide  operational  tips  for  MH  and
673
674 UNIX.
675
676
677        It should be noted that these perceived defects of MH do not affect its utility
678
679 any  more  than  analogous  problems  with  any  operating  system  will  diminish  its
680
681 actual  capabilities.  Users  may  quarrel  with  the  means  chosen  for  orchestrating
682
683 MH, but the fact remains that MH is a very useful set of mail handling tools that
684
685 is  flexible,  infinitely  interoperable  with  other  UNIX  text  handling  tools,  and  yet
686
687 simple enough for new users to grasp once they are given the proper start.  The
688
689 fact that better tutorial materials and training do not exist only means that some
690
691 further work needs to be done in the area of user-education.
692
693
694
695 ________________________________________
696 4  For  example,  mhe  from  Brian  Reid  of  Stanford  University  and  emh  from  Marshall  Rose  are
697
698 instances of macro packages for James Gosling's EMACS extensible editor, while the hm program
699 from Jim Guyton of the Rand Corporation is a monolithic MH interface.  As of this writing, none
700 of these programs is documented in the literature.
701 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     9
702
703
704 A Few Advanced Features
705
706        We now consider certain advanced features in MH. These features have been
707
708 chosen to demonstrate some useful capabilities available to the MH user.  It should
709
710 be noted that many capabilities of MH, such as shell scripts for extensibility, mail
711
712 delivery hooks, the personal aliasing facility, and so forth, are not described here
713
714 for lack of space.
715
716
717 Draft Folders
718
719        The draft folder facility provides a method by which several message drafts can
720
721 be simultaneously composed and maintained until sent.  The rationale for this is that
722
723 partially composed message drafts,  perhaps elaborate sets of separate messages,
724
725 can be incrementally completed, while a folder provides a consistent organization
726
727 for drafts in progress.  This is comparable to similar situations in the "paper world"
728
729 where contracts, business correspondence, and other communications, rather than
730
731 being  created  serially  with  each  posted  in  turn  before  composing  the  next,  are
732
733 usually left in various stages of completion before they are eventually mailed.
734
735
736        The ``Draft-Folder:''             parameter value in the MH profile is used to specify
737
738 a default draft folder, where each draft is given a number and an "artificial" date
739
740 stamp.  Provided that the proper header fields have been completed, a scan listing
741
742 of  the  draft  folder  provides  a  summary  of  each  draft  in  progress:  to  whom  the
743
744 message  is  to  be  sent,  the  subject,  the  date  of  the  draft's  initial  creation  and
745
746 optionally, the current size of the draft in terms of characters.  Experienced users
747
748 of MH may often keep as many as five to ten unfinished drafts in their draft folder.
749
750 "Draft clutter" can be remedied easily with the rmm command.
751
752
753 Message Selection
754
755        MH commands accept message sequence specifications to specify which `msg'
756
757 or `msgs'      are to be operated upon.  Here are some examples:
758
759
760            scan 1 3 5 19 185
761
762
763 to get a scan listing of messages 1, 3, 5, 19 and 185.
764
765
766            scan pseq
767
768
769 to get a scan listing of whatever message sequence was given to the previous MH
770
771 command (in this case 1, 3, 5, 19, and 185).
772
773
774            show first last
775
776
777 to  get  a  display  of  the  first  and  last  messages  in  the  folder.  The  MH  sequences
778
779 named ``first''       and ``last''      are system defined pseudo sequences which act like
780
781 explicit sequences when given to MH commands.  Others are ``cur''     , ``next''      ,
782
783 ``prev''     ,  and  ``all''      which  respectively  specify  the  "current"  message,  the
784
785 "next"  after  cur,  the  "previous"  message  before  cur,  or  "all"  messages  in  the
786 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   10
787
788
789 current-folder.  The  scan  assumes  ``all''      while  show  assumes  ``cur''    ,  unless
790
791 overridden  on  the  command  line.  Over-ride  precedence  is:  command-line  first,
792
793 .mh_profile     second, and compiled-in default last.
794
795
796        Users can define additional sequences for similar use, but must avoid using
797
798 reserved names.  A few optional sequence names have been preempted by MH, such
799
800 as  ``pseq''       to  mean  the  "sequence  used  by  the  previous  MH  command,"  and
801
802 ``unseen''        to mean the "messages not yet seen by the user."  Sometimes these
803
804 preempted names can be changed by resetting them in the user's MH profile, but
805
806 these facilities are beyond the scope of this discussion.
807
808
809        The mark command can be used to set the values for user-defined sequences:
810
811
812            mark 1 3 5 -seq zzz
813
814            mark 4 5 9 -seq zzz -nozero
815
816
817 will create a user-sequence named ``zzz''      and put the sequence ``1  3  5''      in it.
818
819 The mark command assumes that any prior content in an existing user-sequence
820
821 should  be  "zeroed"  before  the  new  sequence  value  is  recorded.   This  can  be
822
823 prevented with a `-nozero'        switch on the command line,  to add ``4  5  9''      to
824
825 the original ``1  3  5''      to yield ``1  3  4  5  9''     .
826
827
828            mark pseq zzz -seq zzznew
829
830
831 will create a new sequence named ``zzznew''         and set its value to the combined
832
833 (inclusive or) of the existing user-sequences in ``pseq''       and ``zzz''      for its value.
834
835
836        Another more powerful way to set the values of a user-sequence is with the
837
838 pick command, which provides full string search capabilities:
839
840
841            pick -from mrose -seq yyy
842
843            pick -from mrose -seq yyy -list
844
845
846 will  search  though  all  the  ``From:''       fields  in  the  current  folder  for  the  string
847
848 ``mrose''       and  place  the  list  of  "hits"  in  the  sequence  named  ``yyy''     .   The
849
850 `-list'      switch  will  cause  the  resulting  list  to  also  be  displayed  on  the  user's
851
852 terminal.  If no `-seq name'         switch is given,  pick will assume `-list'       and will
853
854 simply display the resulting list of hits on the user's terminal.
855
856
857        This `-list'       behavior of pick allows users to take advantage of the UNIX
858
859 backquoting facility to embed searches in other MH commands.
860
861
862            scan `pick -from mrose`
863 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   11
864
865
866 will  produce  a  scan  listing  of  `-from mrose'          hits  because  the  UNIX  shell  will
867
868 spawn a process to execute the ``pick -from mrose''                segment and return the
869
870 `-list'      results as the message sequence to be scanned.
871
872
873            mark pseq -seq zzz
874
875
876 could then be used to capture the "previous sequence" in zzz for later use.
877
878
879        One  last  facility  should  be  mentioned  here.  It  is  also  possible  to  negate  a
880
881 sequence to specify a new sequence.  The default negation string is ``not''     .
882
883
884            scan notzzz
885
886            mark notzzz -seq zzznot
887
888
889 will give the user a scan listing of all the messages in the current folder that are
890
891 not  included  in  the  sequence  ``zzz''    .  The  mark  example  will  of  course  record
892
893 the  negation  of  zzz  in  zzznot.  It  is  a  bad  idea  to  use  the  string  ``not''      as  the
894
895 beginning of any user-sequence name, if ``not''      is defined as the negation string.
896
897 (Users can choose a different negation string.)
898
899
900        From this discussion,  it should be clear that MH provides a uniform set of
901
902 ways  to  capture  and  use  sequences  to  augment  the  user's  short-  and  long-term
903
904 memory  and  to  manipulate  lists  of  interesting  messages.   User-sequences  are
905
906 normally stored as RFC822 labeled text lines in a file (e.g., sequences) in the folder
907
908 with the messages referred to in the sequence.  If a user does not have write access
909
910 to a folder, then the MH mark and pick commands will create a "private" sequence
911
912 in the user's context     file.  Switches are available to give the user control over the
913
914 choice of `-private'        or `-public'        sequence options.
915
916
917        Since user-sequences are stored as ordinary text lines in RFC822 labeled fields,
918
919 there is no prohibition against someone writing programs to perform any kind of
920
921 useful  manipulation  on  MH  sequences.  Boolean  operators  can  be  implemented,
922
923 or complex indexing structures could be developed to serve special purposes.  If a
924
925 DBMS can utilize UNIX pathnames or MH `+folder'        and message names, then
926
927 the full power of the DBMS might be applied.  The intention of MH development
928
929 teams  has  always  been  to  leave  open  the  widest  possible  array  of  options  for
930
931 later extension.  The only restrictions should be the user's ingenuity, programming
932
933 prowess, and the available machine resources.  Unfortunately these resources always
934
935 seem to be available in limited quantities.
936
937
938 Distribution Lists
939
940        MH has a convenient interface to the UCI BBoards facility[MRose84a].5  This
941
942 facility  permits  the  efficient  distribution  of  interest  group  messages  on  a  single
943
944
945
946 ________________________________________
947 5  The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
948
949 form under stand-alone MH.
950 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   12
951
952
953 host, to a group of hosts under a single administration, and to the ARPA Internet
954
955 community.
956
957
958        Described simply, an interest group is composed of a number of subscribers
959
960 with a common interest.  These subscribers post mail to a single address, known
961
962 as a distribution address (e.g., MH-Workers@UCI). From this distribution address,
963
964 a  copy  of  the  message  is  sent  to  each  subscriber.  Each  group  has  a  moderator,
965
966 which is the person that runs the group.  This moderator can usually be reached
967
968 at a special address, known as a request address (e.g., MH-Workers-Request@UCI).
969
970 Usually,  the  responsibilities  of  the  moderator  are  quite  simple,  since  the  mail
971
972 system handles distribution to subscribers automatically.  In some interest groups,
973
974 instead of each separate message being distributed directly to subscribers, a batch
975
976 of (related) messages are put into a digest format by the moderator and then sent
977
978 to the subscribers.  Although this requires more work on the part of the moderator
979
980 and introduces delays, such groups tend to be better organized.
981
982
983        Unfortunately, some problems arise with the scheme outlined above.  First, if
984
985 two users on the same host subscribe to the same interest group, two copies of the
986
987 message will be delivered.  This is wasteful of both processor and disk resources at
988
989 that host.
990
991
992        Second, some groups carry a lot of traffic.  Although subscription to a group
993
994 does indicate interest on the part of a subscriber, it is usually not interesting to get
995
996 50 messages or so delivered to the user's private maildrop each day, interspersed
997
998 with  personal  mail,  that  is  likely  to  be  of  a  much  more  important  and  timely
999
1000 nature.
1001
1002
1003        Third, if a subscriber's address in a distribution list becomes "bad" somehow
1004
1005 and causes failed mail to be returned,  the originator of the message is normally
1006
1007 notified.  It is not uncommon for a large list to have several bogus addresses.  This
1008
1009 results in the originator being flooded with "error messages" from mailers across
1010
1011 the Internet stating that a given address on the list was bad.  Needless to say, the
1012
1013 originator usually does not care if the bogus addresses got a copy of the message
1014
1015 or not.  The originator is merely interested in posting a message to the group at
1016
1017 large.  On the other hand, the moderator of the group does care if there are bogus
1018
1019 addresses on the list, but ironically does not receive notification.
1020
1021
1022        To  solve  all  of  these  problems,  the  UCI  BBoards  facility  introduces  a  new
1023
1024 entity into the picture:  all interest group mail is handled by a special component of
1025
1026 the mail system.  The distribution address maps to a special channel that performs
1027
1028 several  actions.   First,  if  local  delivery  is  to  be  performed,  then  a  copy  of  the
1029
1030 message is placed in a global maildrop for the interest group with a timestamp and
1031
1032 a unique number.  Local users can read messages posted for the interest group by
1033
1034 reading this "public" maildrop.  Second, if further distribution is to take place, a
1035
1036 copy of the message is sent to the distribution address in such a way that if any of
1037 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   13
1038
1039
1040 the addresses are bogus, failure notices will be returned to the local maintainer of
1041
1042 the group address list, rather than the originator of the message.
1043
1044
1045        This  scheme  has  several  advantages:  First,  messages  delivered  to  the  local
1046
1047 host are processed and saved once in a globally accessible area.  The UCI BBoards
1048
1049 facility supports software which allows a user to query an interest group for new
1050
1051 messages and to read and process those messages in the MH-style.  Second, once
1052
1053 a  host  administrator  subscribes  to  an  interest  group,  each  user  can  join  or  quit
1054
1055 the list's readership without contacting anyone.  Third, a hierarchical distribution
1056
1057 scheme can be constructed to reduce the amount of delivery effort.  Fourth, errors
1058
1059 are  prevented  from  propagating.  When  an  address  on  the  distribution  list  goes
1060
1061 bad, the list moderator who is immediately responsible for the address is notified.
1062
1063 If a local moderator does not exist, then the local PostMaster is notified (not the
1064
1065 global group moderator).
1066
1067
1068        In addition to solving the problems outlined above, the UCI BBoards facility
1069
1070 supports  several  other  capabilities.  BBoards  may  be  automatically  archived  in
1071
1072 order  to  conserve  disk  space  and  reduce  processing  time  when  reading  current
1073
1074 items.   Also,  the  archives  can  be  separately  maintained  on  tape  for  access  by
1075
1076 interested researchers.
1077
1078
1079        Special  alias  files  may  be  generated  which  allow  the  MH  user  to  shorten
1080
1081 address type-in.  For example,  instead of sending to SF-Lovers@Rutgers,  a user
1082
1083 of MH usually sends to ``SF-Lovers''           and the MH aliasing facility automatically
1084
1085 makes the appropriate expansion in the headers of the outgoing message.  Hence,
1086
1087 the user need only know the name of an interest group and not its global network
1088
1089 address.
1090
1091
1092        Finally, the UCI BBoards facility supports private interest groups using the
1093
1094 UNIX  group  access  mechanism.   This  allows  a  group  of  people  on  the  same  or
1095
1096 different machines to conduct a private discussion.
1097
1098
1099        The practical upshot of all this is that the UCI BBoards facility automates the
1100
1101 vast majority of BBoards handling from the point of view of both the PostMaster
1102
1103 and the user.
1104
1105
1106        MH provides three programs to deal with interest groups.  The bbc program
1107
1108 is used to check on the status of one or more groups,  and to optionally start an
1109
1110 MH shell on those groups which the user is interested in.  The bbl program can be
1111
1112 used  to  perform  manual  maintenance  on  a  discussion  group  beyond  the  normal
1113
1114 automatic  capabilities  of  the  UCI  BBoards  facility.   Finally,  the  msh  program
1115
1116 implements  an  MH  shell  for  reading  BBoards,  in  which  nearly  all  of  the  MH
1117
1118 commands are implemented in a single program.
1119
1120
1121        Observant  readers  may  note  that  the  use  of  msh  is  contrary  to  the  MH
1122
1123 philosophy of using relatively small, single-purposed programs.  Sadly, the authors
1124 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   14
1125
1126
1127 admit that this is true.  In an effort to avoid some problems with shared-access and
1128
1129 message naming conventions (which are beyond the scope of this paper), BBoards
1130
1131 are  kept  in  maildrop  format  (monolithic)  instead  of  folders.  Some  research  has
1132
1133 gone into overcoming this problem in order to restore MH's purity of purpose, but
1134
1135 all solutions proposed to date are either unworkable or require significant recoding
1136
1137 of MH's internals.
1138
1139
1140 Encapsulation
1141
1142        As  described  above,  some  interest  groups  appear  in  digest  form.   This
1143
1144 means that the messages which appear in such a forum actually encapsulate other
1145
1146 messages  in  their  body.   It  turns  out  that  the  generation  of  a  digest  is  not  at
1147
1148 all  unlike  the  generation  of  a  draft  which  forwards  one  or  more  messages.   In
1149
1150 RFC934[MRose85b],  a method is proposed to standardize message encapsulation
1151
1152 for  the  ARPA  Internet  community.  MH  uses  this  method  for  the  generation  of
1153
1154 digests, forwardings, and blind-carbon-copies.
1155
1156
1157        A  key  requisite  for  using  an  encapsulation  technique  for  digests  and
1158
1159 forwardings is the ability to later decapsulate the contents.  Without this ability,
1160
1161 the forwarded messages are of little use to the recipients because they can not be
1162
1163 distributed, forwarded, replied-to, searched-for, or otherwise processed as separate
1164
1165 individual  messages.  In  the  case  of  a  digest,  a  bursting  capability  is  especially
1166
1167 useful.  Not only does the ability to burst a digest permit a recipient of the digest
1168
1169 to  reply  to  an  individual  digestified  message,  but  it  also  allows  the  recipient  to
1170
1171 selectively process the other messages encapsulated in the digest.
1172
1173
1174        For example,  a single digest issue usually contains more than one topic.  A
1175
1176 subscriber may only be interested in a subset of the topic discussed in a particular
1177
1178 issue.  With  a  bursting  capability,  the  subscriber  can  burst  the  digest,  scan  the
1179
1180 headers,  and  process  those  messages  which  are  of  interest.   The  others  can  be
1181
1182 ignored, if the user so desires.
1183
1184
1185        Note  that  with  proper  encapsulation  technology,  one  can  argue  for  the
1186
1187 re-distribution of messages simply becoming special cases of message forwarding.
1188
1189 For  example,  the  NBS  Standard  for  Mail  Interchange[FIPS98]  and  the  recent
1190
1191 CCITT  draft  on  Mail  Handling  Systems  standards[X.400]  both  discourage  the
1192
1193 re-distribution facility in favor of forwarding by encapsulation.
1194
1195
1196 Encapsulation and Blind-Carbon-Copies
1197
1198        Many user agents support a blind-carbon-copy facility.  MH implements this
1199
1200 using  a  form  of  encapsulation.  It  may  not  be  apparent  to  the  reader  as  to  why
1201
1202 encapsulation of the original message is a good way to deliver blind-carbon-copies.
1203
1204 With a blind-carbon-copy facility, two types of addressees are possible in the draft
1205
1206 to be sent:  visible and blind.  The visible recipients are listed as addresses in the
1207
1208 ``To:''      and ``cc:''       fields,  and the blind recipients are listed in the ``Bcc:''
1209
1210 fields of the draft.  The idea behind this facility is that copies of the draft which are
1211 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   15
1212
1213
1214 delivered to the ``To:''      and ``cc:''      recipients should show the visible recipients
1215
1216 only.
1217
1218
1219        A  major  concern  with  a  blind-carbon-copy  facility  is  that  blind  recipients
1220
1221 should be prevented from accidentally replying to the message in such a way that
1222
1223 the visible recipients are included as addressees in the reply.
1224
1225
1226        There are several methods to implement this facility.  Most rely on posting
1227
1228 two drafts with the MTS. One draft is destined for visible recipients, and simply
1229
1230 lacks the ``Bcc:''       fields of the original draft.  The second draft is destined for the
1231
1232 blind recipients.  The question then arises as to what form this latter draft posted
1233
1234 should take.
1235
1236
1237        One  approach  might  be  to  disable  the  ``To:''      and  ``cc:''      fields  of  the
1238
1239 draft sent to the blind recipients (e.g., by prefixing the string ``BCC-''       to these
1240
1241 fields).  Unfortunately, this is often very confusing to the blind recipients because
1242
1243 it differs from what the visible recipients got.  Although accidental replies are not
1244
1245 possible,  it  is  often  difficult  to  tell  that  the  message  received  is  the  result  of  a
1246
1247 blind-carbon-copy.
1248
1249
1250        The method used by MH is to post two drafts, a visible draft for the visible
1251
1252 recipients,  and  a  blind  draft  for  the  blind  recipients.  The  visible  draft  consists
1253
1254 of  the  original  draft  without  any  ``Bcc:''      fields.  The  blind  draft  contains  the
1255
1256 visible message as a forwarded message.  The headers for the blind draft contain
1257
1258 the  minimal  RFC822  headers  (``From:''        and  ``Date:''      )  and,  if  the  original
1259
1260 draft had a "Subject:"  field, then this header field is also included.  In addition,
1261
1262 MH  alerts  the  recipient  that  the  message  is  a  blind-carbon-copy  by  placing  this
1263
1264 information in the initial encapsulation information in the blind recipient's copy.
1265
1266 This scheme prevents inadvertent replies while allowing the recipient full access to
1267
1268 an exact copy of what was sent to the visible recipients.
1269
1270
1271
1272 MH as a Record Handler
1273
1274        Although message format standards such as RFC822 (and its predecessors)
1275
1276 were originally devised to facilitate computer processing of interpersonal messages,
1277
1278 there  is  no  special  reason  why  the  concept  should  be  limited  to  interpersonal
1279
1280 message processing.  Messages are just one of a variety of useful record forms that
1281
1282 might  be  created  in  one  place  and  transfered  to  another  for  processing.  In  this
1283
1284 regard,  RFC822  wisely  left  open  the  option  for  higher  level  applications  to  use
1285
1286 arbitrary header names or field contents by proscribing MTS use of header names
1287
1288 beginning with ``X-''     .
1289
1290
1291        MH carries though on this idea by allowing the pick command to accept any
1292
1293 arbitrary field name for string searches, so MH users can select on any arbitrary
1294
1295 field name without prior definition.  Beyond this, since all messages are simply files
1296 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   16
1297
1298
1299 in  UNIX  directories,  applications  can  be  developed  to  apply  any  programmable
1300
1301 process to any selected message.
1302
1303
1304        For example, a Time Card Form might be called up by an MH user with
1305
1306
1307            comp -form timecomps
1308
1309
1310 to  enter  time  and  attendance  information  into  ``X-time: : ::''        fields  in  a  draft
1311
1312 message record.  The timecomps        form would include the address of a supervisor
1313
1314 who should validate the information, along with empty fields to be filled in with
1315
1316 data.  In  fancy  applications,  this  might  be  done  with  a  sophisticated  interactive
1317
1318 data entry tool which would validate entered information, but this is an open choice
1319
1320 within the MH framework.  Another alternative would be to use a received message
1321
1322 as  the  blank  form  to  add  a  degree  of  central  control  over  time  and  attendance
1323
1324 reporting forms.
1325
1326
1327        Receiving  supervisors  could  simply  register  approval  by  using  the  MH  dist
1328
1329 command to resend subordinates' time cards to higher approval levels, or to send
1330
1331 them  to  a  time  card  collection  address.   The  MH  dist  command  automatically
1332
1333 inserts  "ReSent"  header  fields  showing  who  resent  it  and  the  resending  date.
1334
1335 Alternatively, the MH forw command could be used to transfer a batch of approved
1336
1337 time cards to the next processing station.  If desired, a new "approval" command
1338
1339 could  be  programmed  to  provide  a  more  trusted  authentication,  perhaps  with
1340
1341 encryption of the content.  Trusted mail systems, such as Trusted Mail6 [MRose85c],
1342
1343 are becoming available for this purpose.
1344
1345
1346        At  the  final  collection  destination,  an  automated  User  Agent  could  be
1347
1348 programmed to directly load the data into the Time and Attendance DBMS by
1349
1350 parsing and decoding the data contained in the ``X-time: : ::''        fields.  It might be
1351
1352 noted that while the RFC822 does not restrict the internal forms of messages, it is
1353
1354 necessary to conform to the interchange standard if specialized filters for message
1355
1356 headers are not to be built to serve as export  laundries (a term originating with
1357
1358 Stephen H. Willson to describe conformance transformations in Ada7 ).
1359
1360
1361 Mapping Between Record Modes (DBMS/MHS)
1362
1363        This time and attendance example suggests that it is possible to define one-to-
1364
1365 one mappings between RFC822 fields and DBMS data elements.  For every DBMS
1366
1367 data  element  definition,  there  is  a  potential  corresponding  RFC822  transferable
1368
1369 equivalent  definition  which  can  facilitate  mail  transfers  of  record  information.
1370
1371 Indeed, a large portion of the definitional work is already done where a Data Base
1372
1373 has already been defined.  All that remains is to define the RFC822 equivalents.
1374
1375
1376
1377 ________________________________________
1378 6  Trusted Mail is a trademark of Trusted Technologies, Incorporated.
1379 7  Ada is a trademark of the Department of Defense (Ada Joint Program Office).
1380 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   17
1381
1382
1383        The  suggestion  that  a  batch  of  time  cards  be  forwarded  inside  a  "cover"
1384
1385 message  implies  that  it  is  possible  in  the  MH  framework  to  recursively  bundle
1386
1387 messages  within  messages,  and  be  able  to  recover  the  originals  for  separate
1388
1389 processing  at  a  receiving  destination.  The  MH  burst  command  can  be  applied
1390
1391 recursively for this purpose because MH encapsulation uses an unambiguous scheme
1392
1393 to delimit messages that are enclosed inside other messages.  Thus,  it should be
1394
1395 possible to extract a structured set of records from a DBMS and mail the set to a
1396
1397 foreign site for processing, or reinsertion into another DBMS. As long as the DBMS
1398
1399 data element definitions correctly correspond to the RFC822 definitions, it is not
1400
1401 even necessary for the source and destination DBMS systems to be the same.
1402
1403
1404        From this discussion,  it is concluded that the MH framework can be useful
1405
1406 for building distributed record handling systems where people at widely scattered
1407
1408 locations must create and submit record forms for processing at distant locations.
1409
1410 This  might  prove  to  be  especially  effective  when  a  mail  system  is  also  needed
1411
1412 for other communication purposes.  A network of sales offices is a good example,
1413
1414 where  general  message  service  would  be  used  for  communications  with  remote
1415
1416 manufacturing and distribution centers, and could also be used for an order entry
1417
1418 system.
1419
1420
1421        Another  example  might  be  for  structured  communications,  as  occur  in
1422
1423 requisition and purchasing systems.  Requisitions could be filled in and mailed to
1424
1425 approval offices, and resent or forwarded to others for action.  At some point, the
1426
1427 requisitions could flow into other other more suitable processing systems as needed.
1428
1429 At the very least, the ability to originate requisitions can be distributed to anyone
1430
1431 with access to a mail system that can originate a proper requisition form.
1432
1433
1434        As a last example, MH already supports group discussions with its BBoard
1435
1436 facilities which allow for automatic sorting of mail by group address, with shared
1437
1438 private  or  public  group  access  to  contributed  items.  As  has  been  shown  to  be
1439
1440 possible with administrative record systems, there is no obvious limit to the ways
1441
1442 that group discussion traffic might be organized into structured collections with
1443
1444 indices,  annotations,  or  reference  pointers  to  aid  in  making  conference  archives
1445
1446 more  useful.  Indeed,  MH  tools  could  even  be  used  to  feed  discussion  items  into
1447
1448 existing conference systems.
1449
1450
1451
1452 Distributed Mail
1453
1454        Next, we consider how MH might be used in a distributed mail environment.
1455
1456 Two  schemes  are  discussed:  one  in  which  connectivity  is  high  and  connections
1457
1458 are relatively "cheap", and one in which connectivity is low and connections are
1459
1460 "expensive".
1461 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   18
1462
1463
1464 The ARPA Internet Environs
1465
1466        The  ARPA  Internet  community  consists  of  many  types  of  heterogeneous
1467
1468 nodes.   Some  hosts  are  large  mainframe  computers,  others  are  personal  work-
1469
1470 stations.   All  communicate  using  the  milstd  TCP/IP  protocol  suite[IP,  TCP].
1471
1472 Messages which conform to the Standard for the Format of ARPA Internet Text
1473
1474 Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
1475
1476
1477        On smaller nodes in the ARPA Internet it is often impractical to maintain
1478
1479 a  message  transport  agent.  For  example,  a  workstation  may  not  have  sufficient
1480
1481 resources (cycles, disk space) in order to permit an SMTP server and associated
1482
1483 local  mail  delivery  system  to  be  kept  resident  and  continuously  running.
1484
1485 Furthermore,  the  workstation  could  be  off-net  for  extended  periods  of  time.
1486
1487 Similarly,  it  may  be  expensive  (or  impossible)  to  keep  a  personal  computer
1488
1489 interconnected to an IP-style network for long periods of time.  In other words, the
1490
1491 node is lacking the resource known as "connectivity".
1492
1493
1494        Despite  this,  it  is  often  desirable  to  be  able  to  process  mail  with  MH  on
1495
1496 these smaller nodes, and they often support a user agent to aid the tasks of mail
1497
1498 handling.  To  solve  this  problem,  a  network  node  which  can  support  a  message
1499
1500 transport  entity  (known  as  service  host)  offers  a  maildrop  service  to  these  less
1501
1502 endowed nodes (known as client hosts).  The Post Office Protocol[JReyn84] (POP)
1503
1504 is intended to permit a workstation to dynamically access a maildrop on a service
1505
1506 host  to  pick-up  mail.8   The  level  of  access  includes  the  ability  to  determine  the
1507
1508 number  of  messages  in  the  maildrop  and  the  size  of  each  message,  as  well  as  to
1509
1510 retrieve and delete individual messages.  More sophisticated implementations of the
1511
1512 POP server are able to distinguish between the header and body portion of each
1513
1514 message, and send n lines of a message to the POP client.  This capability is useful
1515
1516 in thinly connected environments where conservation of bandwidth is important.
1517
1518 By utilizing a more intelligent POP client, a user may generate "scan listings" and
1519
1520 dynamically decide which messages are worth taking delivery on.  The philosophy
1521
1522 of the POP is to put intelligence in the POP clients and not the POP servers.
1523
1524
1525        The  underlying  paradigm  in  which  the  POP  functions  is  that  of  a  split-
1526
1527 slot/remote-UA  model.   The  client  host  (such  as  a  workstation)  is  without  a
1528
1529 co-resident message  transport  agent (MTA), and thus makes use of a service host
1530
1531 with an MTA to obtain posting (SMTP) and delivery (POP) services.  The entity
1532
1533 which supports this type of environment is called a remote-UA since the user agent
1534
1535 resides on a different host than its associated message transport agent.
1536
1537
1538
1539 ________________________________________
1540 8  Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
1541
1542 original description of the protocol, which suffered from certain problems. Since then, two alternate
1543 descriptions have been developed. The official revision of the POP[MButl85], and the revision of the
1544 POP which MH uses (which is documented in an internal memorandum in the MH release).  This
1545 paper considers the POP in the context of the MH release.
1546 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   19
1547
1548
1549        One  very  important  issue  which  must  be  raised  at  this  point  is  one  of
1550
1551 authentication.  The POP requires that a client identify itself to the server using
1552
1553 a server-specific user-id and a server/user-specific password.  This authentication
1554
1555 is required to prevent unauthorized entities from accessing a maildrop on a POP
1556
1557 service host.  It must be emphasized that the POP client is not a "trusted" entity
1558
1559 of the MTS in any sense at all.
1560
1561
1562        Ideally, one would also like to authenticate mail as it is posted on the POP
1563
1564 service  host  using  the  SMTP.  Currently,  in  the  ARPA  Internet  community,  no
1565
1566 authentication is done with SMTP transactions.  This is considered a shortcoming
1567
1568 by  those  interested  in  researching  the  split-UA  model  of  distributed  mail.  The
1569
1570 MZnet environment, discussed in the next section, has authentication facilities for
1571
1572 posting mail.
1573
1574
1575        The  current  release  of  MH  supports  the  above  model  fully:  a  POP  client
1576
1577 program is available to retrieve a maildrop on a POP service host.  In addition,
1578
1579 using  the  SMTP  configuration  for  delivery  in  MH,  a  user  is  able  to  specify  a
1580
1581 search-list of service hosts (and networks) with which to try to post mail.  Using
1582
1583 this  search-list,  when  an  MH  user  posts  a  draft,  the  post  program  will  attempt
1584
1585 to establish an SMTP connection with each host in the list to post the message
1586
1587 until  it  succeeds.   Initial  experimentation  with  the  split-UA  in  a  local  network
1588
1589 environment has proved quite successful.
1590
1591
1592 The MZnet Environs
1593
1594        In 1983,  the MZnet project[EStef84] at the University of California,  Irvine
1595
1596 set out to study the problems involved with bringing Internet-class mail handling
1597
1598 facilities to personal computers.  The project used Apple II computers running the
1599
1600 CP/M 2.2 operating system.  Programming was done in a subset of the C language
1601
1602 called BDS C. The transport system was based on the MMDF PhoneNet software,
1603
1604 and  implemented  a  split-slot  arrangement  between  a  personal  computer  and  a
1605
1606 larger, centralized mail distribution system that performed user authentication and
1607
1608 provided a relatively secure mail transfer channel.  The user agent, CP/MH, was
1609
1610 based on MH.
1611
1612
1613        A  conclusion  of  the  experiment  was  that  small  personal  computer  systems
1614
1615 with dial-up phone connections constrain user agent systems design in ways that
1616
1617 require use of a split-slot interface between the UA and its supporting MTA, and that
1618
1619 this interface best provides the required services if it has error controlled command
1620
1621 and data transfer facilities, with interactive behavior.  Another conclusion indicated
1622
1623 that a good design for a user agent in such a small personal computer environment
1624
1625 could be based on a very modular architecture, such as MH. A final conclusion was
1626
1627 that session-level authentication of the client UA is required for both posting and
1628
1629 delivery.
1630 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   20
1631
1632
1633        It should be noted that the MZnet project had a profound influence on the
1634
1635 development  of  the  POP  used  by  MH.  A  somewhat  more  detailed  discussion  of
1636
1637 the relations between the two environments can be found in the POP description
1638
1639 contained in the MH release.
1640
1641
1642
1643 A Final Note
1644
1645        With the fifth major release of the MH system, it has become clear that most
1646
1647 major increases in functionality can come only at the expense of either efficiency or
1648
1649 portability.  Although there has been great effort to keep MH portable to a number
1650
1651 of  UNIX  implementations,9  the  divergence  in  process  management  facilities,  file
1652
1653 system  enhancements,  and  even  C  compiler  capabilities  has  already  presented
1654
1655 obstacles to some attempts to rehost the MH code.
1656
1657
1658        There  has  been  some  discussion  of  implementing  specialized  MH  daemons
1659
1660 that maintain context information over one or more sessions, thus decreasing the
1661
1662 amount of overhead involved in starting each MH command.  Unfortunately, even
1663
1664 if such daemons were to be implemented, they would be very difficult to move to
1665
1666 versions  of  UNIX  without  sophisticated  process  management  facilities,  and  even
1667
1668 then  the  differences  in  "philosophies"  of  process  management[WJoy83, EOlse84]
1669
1670 would tend to keep such daemons system specific.  A better solution seems to be
1671
1672 simply to tune existing code.
1673
1674
1675
1676 Acknowledgements
1677
1678        The authors would like to thank Norman Z. Shapiro and Phyllis Kantar of
1679
1680 the Rand Corporation for their invaluable comments during the preparation of this
1681
1682 paper.
1683
1684
1685
1686 Distribution Information
1687
1688        For information concerning distribution mechanics for the current release of
1689
1690 MH, please contact:
1691
1692
1693            Support Group
1694
1695            Attn:  MH Distribution
1696
1697            Department of Information and Computer Science
1698
1699            University of California, Irvine
1700
1701            Irvine, CA 92717       USA
1702
1703
1704
1705            714/856-6852
1706
1707
1708
1709 ________________________________________
1710 9  As of this writing, there are approximately 75 sites running mh.5 on five different implementations
1711
1712 of UNIX.
1713 \f
1714
1715                                                  References
1716
1717
1718
1719 [DCome83]        D.  Comer.   The  Computer  Science  Research  Network  CSnet:   A
1720
1721                  History  and  Status  Report.  Communications  of  the  ACM  26,  10
1722
1723                  (October, 1983), 747-753.
1724
1725
1726
1727 [DCroc79]        D.H.  Crocker,  E.S.  Szurkowski,  D.J.  Farber.   An  Internetwork
1728
1729                  Memo  Distribution  Facility  _  MMDF.  Appearing  in  Proceedings,
1730
1731                  Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
1732
1733
1734
1735 [DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
1736
1737                  Messages.  Request  for  Comments  822.  ARPA  Internet  Network
1738
1739                  Information Center (NIC), SRI International (August, 1982).
1740
1741
1742
1743 [DKing84]        D.P.  Kingston,  III.   MMDFII:  A  Technical  Review.  Appearing  in
1744
1745                  Proceedings  Usenix  Summer  '84  Conference,  Salt  Lake  City,  Utah,
1746
1747                  1984, pp. 32-41.
1748
1749
1750
1751 [EAllm83]        E.  Allman.    SENDMAIL  _  An  Internetwork  Mail  Router.
1752
1753                  Britton-Lee, Inc., Berkeley, California (July, 1983).
1754
1755
1756
1757 [EOlse84]        E.W. Olsen.  NetOS Concepts and Facilities. Local Network Systems,
1758
1759                  Inc., Costa Mesa, California (August, 1984).
1760
1761
1762
1763 [EStef84]        E.A. Stefferud, J.N. Sweet, T.P. Domae.  MZnet:  Mail Service for
1764
1765                  Personal Micro-Computer Systems. Appearing in Proceedings, Second
1766
1767                  International Symposium on Computer Message Systems, Nottingham,
1768
1769                  U.K, 1984, pp. 293-302.
1770
1771
1772
1773 [FIPS98]         Specification  for  Message  Format  for  Computer  Based  Message
1774
1775                  Systems. National Bureau of Standards (January, 1983).
1776
1777
1778
1779 [HERMES]         Bolt, Beranek, and Newman.  Hermes User's Manual. for TOPS-20.
1780
1781                  Bolt, Beranek, and Newman, Boston, MA (January, 1979).
1782
1783
1784
1785 [IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
1786
1787                  Appearing in Internet Protocol Transition Workbook, ARPA Internet
1788
1789                  Network Information Center (NIC), SRI International, 1981.
1790
1791
1792
1793 [JReyn84]        J.K.  Reynolds.   Post  Office  Protocol.  Request  for  Comments  918.
1794
1795                  ARPA Internet Network Information Center (NIC), SRI International
1796
1797                  (October, 1984).
1798
1799
1800
1801  Copyright fcl1985, North Holland Publishing Company                                                              21
1802 \f Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   22
1803
1804
1805 [MButl85]        M.  Butler,  J.B.  Postel,  et.  al.   Post  Office  Protocol  -  Version  2.
1806
1807                  Request  for  Comments  937.  ARPA  Internet  Network  Information
1808
1809                  Center (NIC), SRI International (February, 1985).
1810
1811
1812
1813 [MRose84a]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  The  UCI
1814
1815                  BBoards Facility. Department of Computer and Information Sciences,
1816
1817                  University of Delaware (October, 1984).
1818
1819
1820
1821 [MRose84b]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  Tutorial.
1822
1823                  Department  of  Computer  and  Information  Sciences,  University  of
1824
1825                  Delaware (October, 1984).
1826
1827
1828
1829 [MRose85a]       M.T. Rose,  J.L. Romine.  The Rand MH Message Handling System:
1830
1831                  User's Manual. UCI Version. Department of Information and Computer
1832
1833                  Science, University of California, Irvine (January, 1985).
1834
1835
1836
1837 [MRose85b]       M.T.  Rose,  E.A.  Stefferud.    Proposed  Standard  for  Message
1838
1839                  Encapsulation. Request for Comments 934. ARPA Internet Network
1840
1841                  Information Center (NIC), SRI International (January, 1985).
1842
1843
1844
1845 [MRose85c]       M.T. Rose, D.J. Farber, S.T. Walker.  Design of the TTI Prototype
1846
1847                  Trusted Mail Agent. Appearing in Proceedings, Second International
1848
1849                  Symposium on Computer Message Systems, Washington, D.C., 1985
1850
1851                  (to appear).
1852
1853
1854
1855 [SMTP]           Simple  Mail  Transfer  Protocol.  Request  for  Comments  821.  ARPA
1856
1857                  Internet  Network  Information  Center  (NIC),  SRI  International
1858
1859                  (August, 1982).
1860
1861
1862
1863 [TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
1864
1865                  1778).  Appearing  in  Internet  Protocol  Transition  Workbook,  ARPA
1866
1867                  Internet Network Information Center (NIC), SRI International, 1981.
1868
1869
1870
1871 [WJoy83]         W.N.  Joy,  E.  Cooper,  R.S.  Fabry,  S.J.  Leffler,  K.  McKusick,
1872
1873                  D.  Mosher.   4.2bsd  System  Manual.  Technical  Report  Number  5.
1874
1875                  Computer Systems Research Group, University of California, Berkeley.
1876
1877
1878
1879 [X.400]          Message  Handling  Systems:   System  Model-Service  Elements,
1880
1881                  Recommendation  X.400,  International  Telegraph  and  Telephone
1882
1883                  Consultative Committee (CCITT).
1884 \f
1885
1886                                                         Appendix  A
1887
1888                                                      MH  Commands
1889
1890
1891
1892                MH is composed of several UNIX programs, which in theory are fairly simple
1893
1894         and single-purposed.  These commands are functionally grouped below:
1895
1896
1897                                                        Composing_Mail__________
1898
1899      comp:     compose a message
1900
1901                A program to originate a message.  Usually, a special prompting editor front-
1902
1903                end, prompter, is used to fill-in a composition template with the addressees
1904
1905                of the message, subject, and so forth.
1906
1907
1908        dist :  redistribute a message to additional addresses
1909
1910                A program that re-enters a message previously received by the user into the
1911
1912                message transport system.  Only new addresses are added;  the body of the
1913
1914                message is not changed in any way.
1915
1916
1917       forw :   forward messages
1918
1919                A program that encapsulates one or more messages in a new message draft.
1920
1921                In addition, the user may add initial and/or closing comments.
1922
1923
1924        repl :  reply to a message
1925
1926                A program that constructs a reply to a message using a reply template.  The
1927
1928                template mechanism has sufficient generality to permit the user to "program"
1929
1930                the  form  of  the  reply  draft  based  on  the  contents  of  the  message  being
1931
1932                replied-to.
1933
1934
1935       send :   send a message
1936
1937                A  program  that  posts  a  draft  with  the  message  transport  system.   The
1938
1939                send program is usually invoked by one of the four preceding programs, and
1940
1941                performs simple front-end pre-processing prior to invoking the post program.
1942
1943                For  example,  if  invoked  in  push'd  mode,  send  will  immediately  relinquish
1944
1945                control  of  the  user's  terminal  and  post  the  message  in  the  background.  If
1946
1947                the posting fails, send will send back a failure notice to the user.  If the user
1948
1949                had push'd the sending of the draft, then by default the draft being sent is
1950
1951                encapsulated in the failure notice.  This permits easy burst'ing of the failure
1952
1953                notice to retrieve the original draft.  Otherwise, if the posting was successful,
1954
1955                the draft is marked as having been sent.
1956
1957
1958 whatnow :      prompting front-end for send
1959
1960                A program which is called by comp, et.  al., after the initial draft has been
1961
1962
1963
1964          Copyright fcl1985, North Holland Publishing Company                                                              23
1965 \f           Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   24
1966
1967
1968                  generated.  The  MH  user  can  specify  a  different  whatnow  program,  which
1969
1970                  yields considerable extensibility.
1971
1972
1973       whom:      report to whom a message would go
1974
1975                  A program which examines the addresses of the draft and expands all user-
1976
1977                  defined  aliases  contained  therein.  Optionally,  whom  may  actually  interact
1978
1979                  with  the  message  transport  system  to  determine  the  validity  of  the  final
1980
1981                  addresses.  This program is also usually invoked by comp, et. al.
1982
1983
1984                                                            Posting_Mail_______
1985
1986            ali : list mail aliases
1987
1988                  A simple front-end to the MH aliasing mechanism.
1989
1990
1991            ap:   parse addresses 822-style
1992
1993                  A  useful  debugging  tool  for  PostMasters  who  wish  to  examine  how  MH
1994
1995                  interprets an Internet address.
1996
1997
1998     conflict :   search for alias/password conflicts
1999
2000                  Another program used by system administrators to check the consistency of
2001
2002                  MH alias files, and portions of the local message transport agent.
2003
2004
2005 install-mh:      initialize the MH environment
2006
2007                  A program which is automatically executed the first time a user issues an MH
2008
2009                  command.  This program performs once-only initialization of the user's MH
2010
2011                  environment.
2012
2013
2014     mhmail :     send or read mail
2015
2016                  A simple program generally used by other programs to generate messages.
2017
2018                  The mhmail command is similar in purpose to the old BellMail program.
2019
2020
2021          post :  deliver a message
2022
2023                  A  complex  MH  back-end  that  interacts  with  the  local  message  transport
2024
2025                  agent to enter messages through the posting slot.  (See the description of send
2026
2027                  above).
2028
2029
2030                                                            Reading_Mail________
2031
2032           inc:   incorporate new mail
2033
2034                  A program that interacts with the local message transport agent to retrieve
2035
2036                  messages from the user's maildrop.
2037
2038
2039     msgchk :     check for waiting mail
2040
2041                  A program which reports the status of mail waiting in the user's maildrop.
2042
2043
2044         show :   show (list) messages
2045
2046                  A  program  which  lists  messages  to  its  standard  output  (usually  the  user's
2047
2048                  terminal), possibly invoking another program to do the actual listing.  Most
2049
2050                  users  of  MH  have  show  automatically  call  the  mhl  program  to  format  the
2051 \f      Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   25
2052
2053
2054             message.   The  next  and  prev  programs  are  simply  ``show next''          and
2055
2056             ``show prev''          , respectively.
2057
2058
2059     mhl :   produce formatted listings of MH messages
2060
2061             A program which displays a message as directed by a template.  This permits
2062
2063             the user to filter out uninteresting headers and re-arrange other headers to a
2064
2065             particular preference.  In addition to being invoked by show, the mhl program
2066
2067             is optionally also invoked by forw to format each message being forwarded;
2068
2069             invoked  by  repl  to  format  the  body  of  a  message  being  replied-to,  if  that
2070
2071             message is being included in the reply draft; and, invoked by post to format
2072
2073             a message being sent as a blind-carbon-copy.
2074
2075
2076    rmm:     remove messages
2077
2078             A program that removes messages from an MH folder, optionally running a
2079
2080             user-defined program instead of deleting them.  If no program is given,  the
2081
2082             messages are "softly" removed, so they may possibly be recovered later.
2083
2084
2085    scan:    produce a one-line-per-message scan listing
2086
2087             A program that generates a scan listing for messages.  Each line of the listing
2088
2089             contains date, source, subject, and possibly the initial body of the message.
2090
2091
2092                                                     Folder_Handling________
2093
2094  folder :   set/list current folder/message
2095
2096             A program used to list information concerning the current folder, or set the
2097
2098             current folder and/or message.
2099
2100
2101 folders :   list all folders
2102
2103             A program to list information on all folders (actually, just a special case of
2104
2105             the folder command).  Since the MH folder structure may be recursive,  the
2106
2107             user can indicate that folders should recursively examine all folders.
2108
2109
2110    refile:  file message(s) in (an)other folder(s)
2111
2112             A program to move (or copy) messages from a source folder to one or more
2113
2114             destination folders.
2115
2116
2117     rmf :   remove folder
2118
2119             A program that deletes a folder and all messages therein.
2120
2121
2122                                                   Message_Selection_________
2123
2124    anno:    annotate messages
2125
2126             A  program  to  arbitrarily  annotate  messages.   If  the  user  so  desires,  after
2127
2128             distributing,  forwarding,  or  replying-to  a  message,  MH  will  automatically
2129
2130             attach an annotation to the original message indicating the date and addresses.
2131
2132
2133   mark :    mark messages
2134
2135             A program to manipulate user-defined sequences (lists of messages).  Usually,
2136
2137             mark is not employed directly by the MH user.
2138 \f       Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   26
2139
2140
2141      pick :  select messages by content
2142
2143              A  program  to  examine  a  list  of  messages  and  choose  those  which  meet
2144
2145              a  particular  selection  criterion.   The  pick  program  is  often  used  in  UNIX
2146
2147              back-quoted operations to pass message sequences to other MH commands.
2148
2149
2150    sortm:    sort messages
2151
2152              A program to sort a list of messages according to the date given in a particular
2153
2154              field.
2155
2156
2157                                              Distribution_List_Handling____________
2158
2159       bbc:   check on BBoards
2160
2161              A  front-end  to  run  msh  on  a  list  of  distribution  lists  which  the  user  isn't
2162
2163              current on.
2164
2165
2166        bbl : manage a BBoard
2167
2168              A  (depreciated)  program  used  to  manually  manage  the  local  archives  of
2169
2170              a  distribution  list.  These  functions  (archiving,  expunging)  are  performed
2171
2172              automatically by MH.
2173
2174
2175     burst :  explode digests into messages
2176
2177              A  program  used  to  decapsulate  messages  from  ARPA  Internet  digests.  In
2178
2179              addition,  messages  which  have  been  encapsulated  during  forwarding  (i.e.,
2180
2181              with forw ) can also be decapsulated using burst.10
2182
2183
2184      msh:    MH shell (and BBoard reader)
2185
2186              A  monolithic  program  used  to  implement  MH  commands  on  messages
2187
2188              arranged in a single file (maildrop format).  Useful since distribution lists are
2189
2190              kept in this format to minimize consumption of system resources.
2191
2192
2193     pack :   compress a folder into a single file
2194
2195              A program which takes messages stored in MH format and places them in a
2196
2197              single file (using the same format known by msh).
2198
2199
2200                                         Interface_to_the_UNIX_File_System________________
2201
2202 mhpath:      print full pathnames of MH messages and folders
2203
2204              A program which maps MH-style names into the UNIX file naming convention.
2205
2206
2207
2208       ________________________________________
2209      10  Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
2210
2211       so.
2212 \f
2213
2214
2215
2216                                                   Contents
2217
2218
2219
2220                                                                                                               Page
2221
2222 Introduction .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .*
2223  *        1
2224
2225 The MH Philosophy .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        2
2226
2227        The MH Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        3
2228
2229        The MH Profile  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        4
2230
2231        Folders and Messages .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        6
2232
2233        The Context File  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        7
2234
2235        Templates .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
2236  *      7
2237
2238        Explaining All This to New Users .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        7
2239
2240 A Few Advanced Features  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        9
2241
2242        Draft Folders .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    *
2243  *    9
2244
2245        Message Selection .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        9
2246
2247        Distribution Lists  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      11
2248
2249        Encapsulation  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      *
2250  *14
2251
2252        Encapsulation and Blind-Carbon-Copies .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      14
2253
2254 MH as a Record Handler .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      15
2255
2256        Mapping Between Record Modes (DBMS/MHS) .  .  .  .  .  .  .  .  .  .  .  .  .  .      16
2257
2258 Distributed Mail  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    *
2259  *  17
2260
2261        The ARPA Internet Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      18
2262
2263        The MZnet Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      19
2264
2265 A Final Note  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
2266  *    20
2267
2268 Acknowledgements .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      20
2269
2270 Distribution Information .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      20
2271
2272 References .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
2273  *.      21
2274
2275 Appendix A: MH Commands  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      23
2276
2277
2278
2279 ________________________________________
2280 This document (version #1.54) was TEXset April 12, 1990 with DISS.STY v103.
2281
2282
2283
2284                                                                                                                     i