From: David Levine <levinedl@acm.org>
Date: Wed, 29 Feb 2012 04:05:55 +0000 (-0600)
Subject: Added docs/historical/.  See README for where they were found.
X-Git-Url: http://git.marmaro.de/?a=commitdiff_plain;h=9b152e23db633c49c43313a2ef26ebc0951cc874;p=mmh

Added docs/historical/.  See README for where they were found.
---

diff --git a/docs/historical/ADMIN-19910201.txt b/docs/historical/ADMIN-19910201.txt
new file mode 100644
index 0000000..47fde0d
--- /dev/null
+++ b/docs/historical/ADMIN-19910201.txt
@@ -0,0 +1,2729 @@
+
+
+
+
+
+
+
+
+                                  _d_i_s_c_a_r_d _t_h_i_s _p_a_g_e
+
+
+
+
+                                     The RAND _M_H
+                                   Message Handling
+                                       System:
+                                Administrator's Guide
+
+                                     UCI Version
+
+
+                                   February 1, 1991
+                                    6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+99
+
+
+
+
+
+
+
+
+
+
+
+
+                                   _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+9
+
+
+9       _S_c_o_p_e _o_f _t_h_i_s _d_o_c_u_m_e_n_t
+
+            This is the Administrator's Guide to _M_H.  If you don't maintain  an
+       _M_H  system,  don't read this; the information is entirely too technical.
+       If you are a maintainer, then read this guide until you  understand  it,
+       follow the advice it gives, and then forget about the guide.
+
+            Before continuing, I'll point out two facts:
+
+
+
+                 _T_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _a_l_l _t_h_e _i_n_f_o_r_m_a_t_i_o_n
+                               _y_o_u _n_e_e_d _t_o _m_a_i_n_t_a_i_n _M_H.
+
+               _F_u_r_t_h_e_r_m_o_r_e, _t_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _e_v_e_r_y_t_h_i_n_g
+                             _I _k_n_o_w _a_b_o_u_t _m_a_i_n_t_a_i_n_i_n_g _M_H.
+
+
+
+       _M_H, and mailsystems in general, are more complex than most people  real-
+       ize.   A  combination of experience, intuition, and tenacity is required
+       to maintain _M_H properly.  This document can provide only guidelines  for
+       bringing  up  an  _M_H  system  and maintaining it.  There is a sufficient
+       amount of customization possible that not all events or problems can  be
+       forseen.
+
+
+
+9       _S_u_m_m_a_r_y
+
+            During _M_H generation, you specify several  configuration  constants
+       to  the _m_h_c_o_n_f_i_g program.  These directives take into consideration such
+       issues as hardware and operating system dependencies in the source code.
+       They also factor out some major mailsystem administrative decisions that
+       are likely to be made consistantly at sites with  more  than  one  host.
+       The  manual  entry  _m_h-_g_e_n (8)  describes  all  the static configuration
+       directives.
+
+            However,  when  you  install  _M_H  you  may  wish   to   make   some
+       site-specific  or  host-specific  changes  which aren't hardware or even
+       software related.  Rather, they are  administrative  decisions.   That's
+       what  this  guide is for: it describes all of the dynamically tailorable
+       directives.
+
+9
+
+
+
+
+
+
+
+
+
+                                         -2-
+
+
+            Usually,  after  installing   _M_H,   you'll   want   to   edit   the
+       /usr/local/lib/mh/mtstailor  file.   This  file  fine-tunes  the  way _M_H
+       interacts with the message transport  system  (MTS).   Section  2  talks
+       about the MTS interface and MTS tailoring.
+
+            After that, if you're running the UCI BBoards facility, or the  POP
+       facility, you'll need to know how to maintain those systems.  Sections 3
+       and 4 talk about these.
+
+            If for some reason you're not running an MTS that can  handle  both
+       Internet  and _U_U_C_P traffic, you should read-up on mail filtering in Sec-
+       tion 5.  Although this is considered "old technology" now,  the  mechan-
+       isms  described  in Section 5 were really quite useful when first intro-
+       duced way back in 1981.
+
+            Finally, you may want to know how to modify  the  _M_H  source  tree.
+       Section 6 talks (a little bit) about that.
+
+            The last two sections describe a few hidden features in _M_H, and the
+       configuration options that were in effect when this guide was generated.
+
+            After _M_H is installed, you should define the  address  "Bug-MH"  to
+       map to either you or the _P_o_s_t_M_a_s_t_e_r at your site.
+
+            In addition, if you want to tailor  the  behavior  of  _M_H  for  new
+       users,  you  can  create and edit the file /usr/local/lib/mh/mh.profile.
+       When the _i_n_s_t_a_l_l-_m_h program is run for a user, if this file  exists,  it
+       will copy it into the user's .mh_profile file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                 _2. _T_H_E _M_T_S _I_N_T_E_R_F_A_C_E
+
+
+
+9
+            The    file    /usr/local/lib/mh/mtstailor    customizes    certain
+       host-specific  parameters  of  _M_H related primarily to interactions with
+       the  transport  system.   The  parameters  in  this  file  override  the
+       compiled-in  defaults given during _M_H configuration.  Rather than recom-
+       piling _M_H on each host to make minor customizations, it is easier simply
+       to  modify  the  mtstailor file.  All hosts at a given site normally use
+       the same mtstailor file, though this need not be the case.
+
+            It is a good idea to run  the  _c_o_n_f_l_i_c_t (8)  program  each  morning
+       under _c_r_o_n.  The following line usually suffices:
+
+            00 05 * * * /usr/local/lib/mh/conflict -mail PostMaster
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                                    -3-
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -4-                       MH-TAILOR(5)
+
+
+  _N_A_M_E
+       /usr/local/lib/mh/mtstailor - system customization for  MH  message
+  system
+
+  _S_Y_N_O_P_S_I_S
+       any _M_H command that interacts with the MTS
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The file /usr/local/lib/mh/mtstailor defines run-time  options  for
+       those  _M_H  programs  which interact (in some form) with the message
+       transport system.  At present, these (user) programs are: _a_p,  _c_o_n_-
+       _f_l_i_c_t, _i_n_c, _m_s_g_c_h_k, _m_s_h, _p_o_s_t, _r_c_v_d_i_s_t, and _r_c_v_p_a_c_k.
+
+       The options available along with default values and  a  description
+       of their meanings are listed below:
+
+       localname:
+            The host name _M_H considers local.  If not  set,  depending  on
+            the  version  of UNIX you're running, _M_H will query the system
+            for this value (e.g., <whoami.h>,  gethostname,  etc.).   This
+            has  no  equivalent  in the _M_H configuration file.  POP client
+            hosts have this value set to the name of the POP service host.
+
+       systemname:
+            The name of the local host in the _U_U_C_P "domain".  If not  set,
+            depending on the version of UNIX you're running, _M_H will query
+            the system for this value.  This has no equivalent in  the  _M_H
+            configuration file.
+
+       mmdfldir: /usr/spool/mail
+            The directory where maildrops are kept.  If this is empty, the
+            user's  home  directory  is  used.   This overrides the "mail"
+            field in the _M_H configuration file.
+
+       mmdflfil:
+            The name of the maildrop file in the directory where maildrops
+            are  kept.   If  this is empty, the user's login name is used.
+            This overrides the "mail" field in the _M_H configuration file.
+
+       mmdelim1: \001\001\001\001\n
+            The beginning-of-message delimiter for maildrops.
+
+       mmdelim2: \001\001\001\001\n
+            The end-of-message delimiter for maildrops.
+
+       mmailid: 0
+            If non-zero, then  support  for  MMailids  in  /etc/passwd  is
+            enabled.   Basically,  the pw_gecos field in the password file
+            is of the form
+
+                 My Full Name <mailid>
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -5-                       MH-TAILOR(5)
+
+
+            The _M_H internal routines that deal with user  and  full  names
+            will return "mailid" and "My Full Name" respectively.
+
+       lockstyle: 0
+            The locking-discipline to perform.  A value of  "0"  means  to
+            use  _f_l_o_c_k  if  available,  or _l_o_c_k_f if LOCKF was defined when
+            building _M_H.  On non-BSD42 systems, standard _B_e_l_l_M_a_i_l  locking
+            is  used.  A value of "1" means to use _B_e_l_l_M_a_i_l locking always
+            (the name of the lock is based on the file name).  A value  of
+            "2"  means to use _M_M_D_F locking always (the name of the lock is
+            based on device/inode pairs).
+
+       lockldir:
+            The name of the directory for making locks.   If  your  system
+            doesn't  have the _f_l_o_c_k or _l_o_c_k_f syscalls, then this directory
+            is used when creating locks.  If the value is empty, then  the
+            directory of the file to be locked is used.
+
+       maildelivery: /usr/local/lib/mh/maildelivery
+            The name of the system-wide default ._m_a_i_l_d_e_l_i_v_e_r_y  file.   See
+            _m_h_o_o_k (1) for the details.
+
+       everyone: 200
+            The highest user-id which should NOT receive mail addressed to
+            "everyone".
+
+       noshell:
+            If set, then each user-id greater than "everyone" that  has  a
+            login  shell  equivalent to the given value (e.g., "/bin/csh")
+            indicates that mail for "everyone" should not be sent to them.
+            This is useful for handling admin, dummy, and guest logins.
+
+    _M_a_i_l _F_i_l_t_e_r_i_n_g
+
+       These  options  are  only  available  if  you  compiled   _M_H   with
+       "options MF".
+
+       uucpchan: name of _U_U_C_P channel
+            Usually "UUCP".  This has no equivalent in the  _M_H  configura-
+            tion file.
+
+       uucpldir: /usr/spool/mail
+            The name of the directory where _U_U_C_P maildrops are kept.  This
+            has no equivalent in the _M_H configuration file.
+
+       uucplfil:
+            The name of the maildrop file  in  the  directory  where  _U_U_C_P
+            maildrops  are  kept.  If this is empty, the user's login name
+            is used.  This has no equivalent in the _M_H configuration file.
+
+       umincproc: /usr/local/lib/mh/uminc
+            The path to the program that filters _U_U_C_P-style  maildrops  to
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -6-                       MH-TAILOR(5)
+
+
+            _M_M_D_F-style maildrops.
+
+    _S_t_a_n_d-_A_l_o_n_e _D_e_l_i_v_e_r_y
+
+       These options are only available if you compiled _M_H to  use  stand-
+       alone delivery (i.e., "mts: mh").
+
+       mailqdir: /usr/spool/netmail
+            The directory where network mail is queued.
+
+       tmailqdir: /usr/tmp
+            The directory where network mail queue files are built.
+
+       syscpy: 1
+            If ON, unauthorized mail is copied to the overseer.
+
+       overseer: root
+            The user that receives reports of unauthorized mail.
+
+       mailer: root
+            The user acting for the mail system.
+
+       fromtmp: /tmp/rml.f.XXXXXX
+            The _m_k_t_e_m_p template for storing from lines.
+
+       msgtmp: /tmp/rml.m.XXXXXX
+            The _m_k_t_e_m_p template for storing the rest of the message.
+
+       errtmp: /tmp/rml.e.XXXXXX
+            The _m_k_t_e_m_p template for  storing  error  messages  from  other
+            mailers.
+
+       tmpmode: 0600
+            The octal mode which temporary files are set to.
+
+       okhosts: /usr/local/lib/mh/Rmail.OKHosts
+            A file containing a list of hosts that can sent ARPAnet mail.
+
+       okdests: /usr/local/lib/mh/RMail.OKDests
+            A file containing a list of  hosts  that  can  always  receive
+            mail.
+
+    _T_h_e `/_s_m_t_p' _M_T_S _S_u_f_f_i_x
+
+       These options are only  available  if  you  compiled  _M_H  with  the
+       "/smtp" suffix to your "mts:" configuration.
+
+       hostable: /usr/local/lib/mh/hosts
+            The exceptions file for /etc/hosts used by _p_o_s_t to try to find
+            official names.  The format of this file is quite simple:
+
+                 1. Comments are surrounded by sharp (`#') and newline.
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -7-                       MH-TAILOR(5)
+
+
+                 2. Words are surrounded by whitespace.
+                 3. The first word on the line is the official name  of  a
+                 host.
+                 4. All words following the official names are aliases for
+                 that host.
+
+       servers: localhost \01localnet
+            A lists of hosts and networks which to look for  SMTP  servers
+            when posting local mail.  It turns out this is a major win for
+            hosts which don't run an message transport system.  The  value
+            of  "servers"  should  be one or more items.  Each item is the
+            name of either a host or a net (in the  latter  case,  precede
+            the  name  of  the  net by a \01).  This list is searched when
+            looking for a smtp server to post mail.  If a host is present,
+            the SMTP port on that host is tried.  If a net is present, the
+            SMTP port on each host in that net is tried.  Note that if you
+            are  running  with  the BIND code, then any networks specified
+            are ignored (sorry, the interface went away under BIND).
+
+    _S_e_n_d_M_a_i_l
+
+       This option is only available if you compiled _M_H to use _S_e_n_d_M_a_i_l as
+       your delivery agent (i.e., "mts: sendmail").
+
+       sendmail: /usr/lib/sendmail
+            The pathname to the _s_e_n_d_m_a_i_l program.
+
+    _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+       This option is only available if you compiled _M_H with  POP  support
+       enabled (i.e., "pop: on").
+
+       pophost:
+            The name of the default POP service host.  If this is not set,
+            then _M_H looks in the standard maildrop areas for waiting mail,
+            otherwise the named POP service host is consulted.
+
+    _B_B_o_a_r_d_s _D_e_l_i_v_e_r_y
+
+       This  option  is  only  available   if   you   compiled   _M_H   with
+       "bbdelivery: on".
+
+       bbdomain:
+            The local BBoards domain (a UCI hack).
+
+    _B_B_o_a_r_d_s & _T_h_e _P_O_P
+
+       These  options  are  only  available  if  you  compiled   _M_H   with
+       "bboards: pop" and "pop: on".
+
+       popbbhost:
+            The POP service host which also acts as a BBoard server.  This
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -8-                       MH-TAILOR(5)
+
+
+            variable should be set on the POP BBoards client host.
+
+       popbbuser:
+            The guest account on the POP/BB service host.  This should  be
+            a  different  login ID than either the POP user or the BBoards
+            user.  (The user-id "ftp" is highly recommended.)  This  vari-
+            able  should be set on both the POP BBoards client and service
+            hosts.
+
+       popbblist: /usr/local/lib/mh/hosts.popbb
+            A file containing of lists of hosts that are  allowed  to  use
+            the  POP  facility  to access BBoards using the guest account.
+            If this file is not present, then  no  check  is  made.   This
+            variable should be set on the POP BBoards service host.
+
+    _B_B_o_a_r_d_s & _T_h_e _N_N_T_P
+
+       This  option  is  only  available   if   you   compiled   _M_H   with
+       "bboards: nntp" and "pop: on".
+
+       nntphost:
+            The host which  provides  the  NNTP  service.   This  variable
+            should be set on the NNTP BBoards client host.
+
+    _F_i_l_e _L_o_c_k_i_n_g
+
+       A few words on locking: _M_H has a flexible locking system for making
+       locks  on  files.   There are two mtstailor variables you should be
+       aware of "lockstyle" and "lockldir".  The first controls the method
+       of  locking,  the  second  says where lock files should be created.
+       The "lockstyle" variable can take on three  values:  0,  1,  2.   A
+       value  of  0 is useful on BSD42 systems.  If you included the LOCKF
+       option when building _M_H, the _l_o_c_k_f syscall is used,  otherwise  the
+       _f_l_o_c_k syscall is used.  If you're not on a 4.2BSD system, a locking
+       style of 0 is considered the same as locking style 1.
+
+       A value of 1 or 2 specifies that a file  should  be  created  whose
+       existence  means "locked" and whose non-existence means "unlocked".
+       A value of 1 says to construct the lockname by appending ".lock" to
+       the  name of the file being locked.  A value of 2 says to construct
+       the lockname by looking at the device and inode numbers of the file
+       being  locked.   If  the "lockldir" variable is not specified, lock
+       files will be created in the directory where the file being  locked
+       resides.   Otherwise,  lock  files will be created in the directory
+       specified by "lockldir".  Prior to installing _M_H,  you  should  see
+       how locking is done at your site, and set the appropriate values.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-TAILOR(5)                      -9-                       MH-TAILOR(5)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       mh-gen(8), mh-mts(8)
+
+
+  _D_e_f_a_u_l_t_s
+       As listed above
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MTS(8)                         -10-                         MH-MTS(8)
+
+
+  _N_A_M_E
+       mh-mts - the MH interface to the message transport system
+
+  _S_Y_N_O_P_S_I_S
+       SendMail
+
+       MMDF (any release)
+
+       stand-alone
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _M_H can use a wide range of message  transport  systems  to  deliver
+       mail.   Although the _M_H administrator usually doesn't get to choose
+       which MTS to use (since  it's  already  in  place),  this  document
+       briefly describes the interfaces.
+
+       When communicating with _S_e_n_d_M_a_i_l, _M_H always uses the SMTP  to  post
+       mail.   Depending  on the _M_H configuration, _S_e_n_d_M_a_i_l may be invoked
+       directly (via a _f_o_r_k and an _e_x_e_c), or _M_H may open a TCP/IP  connec-
+       tion to the SMTP server on the localhost.
+
+       When communicating with _M_M_D_F, normally _M_H uses the  "mm_"  routines
+       to  post  mail.   However,  depending  on  the _M_H configuration, _M_H
+       instead may open a TCP/IP connection to  the  SMTP  server  on  the
+       localhost.
+
+       When using the stand-alone system (NOT  recommended),  _M_H  delivers
+       local  mail  itself  and queues _U_U_C_P and network mail.  The network
+       mail portion will probably have to be modified to reflect the local
+       host's  tastes,  since there is no well-known practice in this area
+       for all types of UNIX hosts.
+
+       If you are running a UNIX system with TCP/IP networking, then it is
+       felt  that  the best interface is achieved by using either _S_e_n_d_M_a_i_l
+       or _M_M_D_F with the SMTP option.  This gives greater flexibility.   To
+       enable this option you append the /smtp suffix to the mts option in
+       the _M_H configuration.  This yields two primary  advantages:  First,
+       you  don't  have to know where _s_u_b_m_i_t or _S_e_n_d_M_a_i_l live.  This means
+       that _M_H binaries (e.g., _p_o_s_t ) don't have to have this  information
+       hard-coded,  or can run different programs altogether; and, second,
+       you can post mail with the server  on  different  systems,  so  you
+       don't  need either _M_M_D_F or _S_e_n_d_M_a_i_l on your local host.  Big win in
+       conserving cycles and disk space.  Since _M_H supports the notion  of
+       a server search-list in this respect, this approach can be tolerant
+       of faults.  Be sure to set "servers:" as described in  mh-tailor(8)
+       if you use this option.
+
+       There are four disadvantages to using the SMTP option: First,  only
+       UNIX  systems  with TCP/IP are supported.  Second, you need to have
+       an SMTP server running somewhere on any network your local host can
+       reach.   Third, this bypasses any authentication mechanisms in _M_M_D_F
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MTS(8)                         -11-                         MH-MTS(8)
+
+
+       or _S_e_n_d_M_a_i_l.  Fourth, the file  /etc/hosts  is  used  for  hostname
+       lookups  (although  there  is  an  exception file).  In response to
+       these disadvantages though: First, there's got to be an SMTP server
+       somewhere around if you're in the Internet or have a local network.
+       Since the server search-list  is  very  general,  a  wide-range  of
+       options are possible.  Second, SMTP should be fixed to have authen-
+       tication mechanisms in it, like POP.  Third, _M_H won't choke on mail
+       to  hosts  whose  official  names  it can't verify, it'll just plug
+       along (and besides if you enable the  BERK  or  DUMB  configuration
+       options, _M_H ignores the hosts file altogether).
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       _M_M_D_F-_I_I: _A _T_e_c_h_n_i_c_a_l _R_e_v_i_e_w, Proceedings, Usenix Summer '84 Confer-
+       ence
+       _S_E_N_D_M_A_I_L -- _A_n _I_n_t_e_r_n_e_t_w_o_r_k _M_a_i_l _R_o_u_t_e_r
+       mh-tailor(8), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The /usr/local/lib/mh/mtstailor file ignores the information in the
+       _M_M_D_F-_I_I tailoring file.  It should not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                      _3. _B_B_O_A_R_D_S
+
+
+
+9
+            The UCI BBoards facility has two aspects: message reading, and mes-
+       sage  delivery.   The configuration directives applicable to BBoards are
+       "bboards: on/off/pop/nntp" and "bbdelivery: on/off".
+
+
+9       _B_B_o_a_r_d _D_e_l_i_v_e_r_y
+
+            If you enabled BBoards delivery ("bbdelivery:  on")  during  confi-
+       guration,  then  the initial environment for bboards delivery was set-up
+       during installation.  A BBoard called "system" is established, which  is
+       the BBoard for general discussion.
+
+            To add more BBoards,  become  the  "bboards"  user,  and  edit  the
+       /usr/bboards/BBoards  file.   The file support/bboards/Example is a copy
+       of the /usr/bboards/BBoards file that we use at UCI.   When  you  add  a
+       BBoard,  you  don't  have  to  create  the files associated with it, the
+       BBoards delivery system will do that automatically.
+
+            Private BBoards may be created.   To  add  the  fictitious  private
+       BBoard  "hacks",  add  the appropriate entry to the BBoards file, create
+       the empty file /usr/bboards/hacks.mbox (or whatever), change the mode of
+       this file to 0640, and change the group of the file to be the groupid of
+       the people that you want to be able to read it.  Also be sure to add the
+       "bboards"  user  to  this  group (in /etc/group), so the archives can be
+       owned correctly.
+
+            By using the special INVIS  flag  for  a  BBoard,  special  purpose
+       BBoards  may be set-up which are invisible to the _M_H user.  For example,
+       if a site distributes a BBoard both locally to a number of machines  and
+       to a number of distant machines.  It might be useful to have two distri-
+       bution lists: one for all machines on the list, and the other for  local
+       machines  only.  This is actually very simple to do.  For the main list,
+       put the standard entry of information in the /usr/bboards/BBoards  file,
+       with  the  complete distribution list.  For the local machines list, and
+       add a similar entry to the /usr/bboards/BBoards file.   All  the  fields
+       should  be the same except three: the BBoard name should reflect a local
+       designation (e.g., "l-hacks"), the distribution list should contain only
+       machines at the local site, and the flags field should contain the INVIS
+       flag.  Since the two entries share the same primary and  archive  files,
+       messages  sent to either list are read by local users, while only thoses
+       messages sent to the main list are read by all users.
+
+            Two automatic facilities for dealing with BBoards exist:  automatic
+       archiving and automatic aliasing.  The file support/bboards/crontab con-
+       tains some entries that you should add to your /usr/lib/crontab file  to
+       run  the  specified  programs at times that are convenient for you.  The
+
+                                         -12-
+
+
+
+
+
+
+
+
+
+                                         -13-
+
+
+       bboards.daily file is run once a day and generates an alias file for _M_H.
+       By  using  this  file,  users of _M_H can use, for example, "unix-wizards"
+       instead of "unix-wizards@brl-vgr" when they want to send  a  message  to
+       the  "unix-wizards"  discussion  group.   This is a major win, since you
+       just have to know the name of the group,  not  the  address  where  it's
+       located.
+
+            The bboards.weekly file is run once a week and handles old messages
+       (those  received  more than 12 days ago) in the BBoards area.  In short,
+       those BBoards which are marked for automatic archiving will  have  their
+       old messages placed in the /usr/bboards/archive/ area, or have their old
+       messages removed.  Not only does this make BBoards faster to  read,  but
+       it conveniently partitions the new messages from the old messages so you
+       can easily put the old messages on tape and then remove them.  It  turns
+       out that this automatic archiving capability is also a major win.
+
+            At UCI, our policy is to save archived messages on tape (every  two
+       months  or so).  We use a program called _b_b_t_a_r to implement our particu-
+       lar policy.  Since some BBoards are private (see  above),  we  save  the
+       archives  on two tapes: one containing the world-readable archives (this
+       tape is read-only accessible to all users by calling the operator),  and
+       the  other  containing  the  non-world-readable  ones (this tape is kept
+       locked-up somewhere).
+
+
+9       _B_B_o_a_r_d_s _w_i_t_h _t_h_e _P_O_P
+
+            If you configured _M_H with "bboards: pop" and "pop: on", then the _M_H
+       user is allowed to read BBoards on a server machine instead of the local
+       host (thus saving disk space).  For completely transparent behavior, the
+       administrator  may  set  certain  variables in the mtstailor file on the
+       client host.  The variable "popbbhost" indicates the host where  BBoards
+       are kept (it doesn't have to be the POP service host, but this host must
+       run both a POP server and the BBoards system).  The variable "popbbuser"
+       indicates  the  guest  account  on this host for BBoards.  This username
+       should not be either the POP user or  the  BBoards  user.   Usually  the
+       anonymous  FTP  user  (ftp)  is  the best choice.  Finally, the variable
+       "popbblist" indicates the name of a file which contains a list of  hosts
+       (one to a line, official host names only) which should be allowed to use
+       the POP facility to access BBoards via the guest account.  (If the  file
+       is not present, then no check is made.)
+
+            The "popbbuser" variable should be set on both the client and  ser-
+       vice host.  The "popbbhost" variable need be set only on the client host
+       (the  value,  of  course,  is  the  name  of  the  service  host).   The
+       "popbblist" variable need be set only on the service host.
+
+            Finally, on the client host, if a POP service host  is  not  expli-
+       citly given by the user (i.e., "popbbhost" is implicitly used), then _b_b_c
+       will explicitly check the local host prior  to  contacting  the  service
+       host.   This  allows  each  POP  client host to have a few local BBoards
+
+9
+
+
+
+
+
+
+
+
+
+                                         -14-
+
+
+       (e.g., each host could have one called "system"), and then have the  POP
+       service host used for all the rest (a site-wide BBoard might be known as
+       "general").
+
+
+9       _B_B_o_a_r_d_s _w_i_t_h _t_h_e _N_N_T_P
+
+            If you configured _M_H with "bboards: nntp" and "pop: on",  then  the
+       _M_H  user  is  allowed to read the Network News on a server machine using
+       the standard _b_b_c command.   For  completely  transparent  behavior,  the
+       administrator  may  set the "nntphost" variable in the mtstailor file to
+       indicate the host where the Network News is kept.  The "nntphost"  vari-
+       able  should be set only on the client host Finally, on the client host,
+       if an NNTP service host is not  explicitly  given  by  the  user  (i.e.,
+       "nntphost" is implicitly used), then _b_b_c will explicitly check the local
+       host prior to contacting the service host.  This allows each NNTP client
+       host  to have a few local BBoards (e.g., each host could have one called
+       "system"), and then have the NNTP service host used for to read the Net-
+       work News.
+
+            Reading  BBoards  via  the  POP  and  via  the  NNTP  are  mutually
+  exclusive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+
+
+
+
+
+
+
+
+
+  BBOARDS(5)                        -15-                        BBOARDS(5)
+
+
+  _N_A_M_E
+       BBoards - BBoards database
+
+  _S_Y_N_O_P_S_I_S
+       /usr/bboards/BBoards
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The BBoards database contains for each BBoard the following  infor-
+       mation:
+
+       _f_i_e_l_d               _v_a_l_u_e
+       name                the name of the BBoard
+       aliases             local aliases for the BBoard
+                           (separated by commas)
+       primary file        the .mbox file
+       encrypted password  leadership password
+       leaders             local list maintainers (separated by commas)
+                           usernames from the _p_a_s_s_w_d (5) file,
+                           or groupnames preceded by `=' from the
+                           _g_r_o_u_p (5) file
+       network address     the list address
+       request address     the list maintainer's address
+       relay               the host acting as relay for the local domain
+       distribution sites  (separated by commas)
+       flags               special flags (see <bboards.h>)
+
+       This is an ASCII file.  Each field within each  BBoard's  entry  is
+       separated from the next by a colon.  Each BBoard entry is separated
+       from the next by a new-line.  If the password  field  is  null,  no
+       password  is  demanded;  if  it contains a single asterisk, then no
+       password is valid.
+
+       This file resides in the home directory  of  the  login  "bboards".
+       Because  of  the  encrypted passwords, it can and does have general
+       read permission.
+
+  _F_i_l_e_s
+       /usr/bboards/BBoards                BBoards database
+
+
+  _S_e_e _A_l_s_o
+       bbaka(8), bbexp(8), bboards (8), bbtar(8)
+
+
+  _B_u_g_s
+       A binary indexed file format should be available for fast access.
+
+       Appropriate precautions must be taken  to  lock  the  file  against
+       changes  if  it is to be edited with a text editor.  A _v_i_b_b program
+       is needed.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBOARDS(5)                        -16-                        BBOARDS(5)
+
+
+  _N_A_M_E
+       bbaka - generate an alias list for BBoards
+
+  _S_Y_N_O_P_S_I_S
+       /usr/bboards/bbaka [system]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _b_b_a_k_a program reads the BBoards database and  produces  on  its
+       standard output a file suitable for inclusion in either the _M_M_D_F-_I_I
+       aliases file (if the argument `system' is given).  If the  argument
+       is  not  given,  then  _b_b_a_k_a produces on its standard output a file
+       suitable for becoming the /usr/local/lib/mh/BBoardsAliases file.
+
+  _F_i_l_e_s
+       /usr/bboards/BBoards                BBoards database
+       /usr/local/lib/mh/BBoardsAliases    BBoards aliases file for _M_H
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       bboards(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBEXP(8)                          -17-                          BBEXP(8)
+
+
+  _N_A_M_E
+       bbexp - expunge the BBoards area
+
+  _S_Y_N_O_P_S_I_S
+       /usr/bboards/bbexp [-_f_i_r_s_t-_m_e_t_r_i_c] [-_s_e_c_o_n_d-_m_e_t_r_i_c] [bboards ...]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _b_b_e_x_p program reads the  BBoards  database  and  calls  _m_s_h  to
+       archive the named BBoards (or all BBoards if none are specified).
+
+       The first-metric (which defaults to 12) gives the age  in  days  of
+       the  "BB-Posted:" field for messages which should be expunged.  The
+       second-metric (which defaults to 20) gives the age in days  of  the
+       "Date:"  field  for messages which should be expunged.  Any message
+       which meets either metric  will  be  either  archived  or  removed,
+       depending on what the _B_B_o_a_r_d_s (5) file says.
+
+  _F_i_l_e_s
+       /usr/bboards/BBoards                BBoards database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       msh(1), bboards(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBOARDS(8)                        -18-                        BBOARDS(8)
+
+
+  _N_A_M_E
+       bboards - BBoards channel/mailer
+
+  _S_Y_N_O_P_S_I_S
+       /usr/mmdf/chans/bboards fd1 fd2 [y]
+
+       /usr/local/lib/mh/sbboards bboard ...
+
+       /usr/local/lib/mh/sbboards file maildrop directory bboards.bboard
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       For _M_M_D_F, the BBoards channel delivers mail to the BBoards  system.
+       For  _S_e_n_d_M_a_i_l and stand-alone _M_H, the SBBoards mailer performs this
+       task.
+
+       For each address given, these programs consult the _b_b_o_a_r_d_s (5) file
+       to  ascertain  information  about  the BBoard named by the address.
+       The programs then perform local delivery,  if  appropriate.   After
+       that,  with the exception of _s_b_b_o_a_r_d_s running under stand-alone _M_H,
+       the programs perform redistribution, if appropriate.
+
+       For redistribution, the return address is set  to  be  the  request
+       address at the local host, so bad addresses down the line return to
+       the nearest point of  authority.   If  any  failures  occur  during
+       redistribution,  a  mail  message  is  sent  to  the  local request
+       address.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/bboards/BBoards                BBoards database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       bboards(5), bbaka(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBTAR(8)                          -19-                          BBTAR(8)
+
+
+  _N_A_M_E
+       bbtar - generate the names of archive files to be put to tape
+
+  _S_Y_N_O_P_S_I_S
+       /usr/bboards/bbtar [private] [public]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _b_b_t_a_r program reads the BBoards database and  produces  on  its
+       standard  output  the names of BBoards archives which should be put
+       to tape, for direct use in a _t_a_r (1) command.
+
+       If the argument `private' is given, only private BBoards  are  con-
+       sidered.   If  the  argument `public' is given, only public BBoards
+       are considered.  This lets  the  BBoards  administrator  write  two
+       tapes,  one  for  general read-access (the public BBoards), and one
+       for restricted access.  The default is all BBoards
+
+       For example:
+
+            cd archive              # change to the archive directory
+            tar cv `bbtar private`  # save all private BBoard archives
+
+       After the archives have  been  saved  to  tape,  they  are  usually
+       removed.  The archives are then filled again, usually automatically
+       by cron jobs which run _b_b_e_x_p (8).
+
+  _F_i_l_e_s
+       /usr/bboards/BBoards                BBoards database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       bboards(5), bbexp(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                        _4. _P_O_P
+
+
+
+9
+            For POP (Post Office Protocol) client hosts, you need to  edit  the
+       /usr/local/lib/mh/mtstailor  file to know about two hosts: the SMTP ser-
+       vice host and the POP service  host.   Normally,  these  are  the  same.
+       Change  the "localname" field of the mtstailor file of _M_H in the file to
+       be the name of the POP service host.  This makes replies  to  mail  gen-
+       erated  on  the POP client host possible, since _M_H will consider use the
+       hostname of the POP service host as  the  local  hostname  for  outgoing
+       mail.   Also  set  the value of "pophost" to this value.  This tells _i_n_c
+       and _m_s_g_c_h_k to use POP instead of looking  for  mail  locally.   Finally,
+       make  sure  the value of "servers" includes the name of the SMTP service
+       host.  The recommended value for "servers" is:
+
+            servers: SMTP-service-host localhost \01localnet
+
+            If you want more information on the Post Office  Protocol  used  by
+       _M_H,      consult      the      files     support/pop/rfc1081.txt     and
+       support/pop/rfc1082.txt which describe the _M_H version of the POP: POP3.
+
+            For POP service hosts, you need to run  a  daemon,  _p_o_p_d (8).   The
+       daemon should start at multi-user boot time, so adding the lines:
+
+            if [ -f /etc/popd ]; then
+                /etc/popd & echo -n ' pop'                  >/dev/console
+            fi
+
+       to the /etc/rc.local file is sufficient.
+
+            The port assigned to the POP3 protocol is  "110".   For  historical
+       reasons,  many  sites are using port "109" which is the port assigned to
+       the "POP" (ver. 1) protocol.  The configuration option  "POPSERVICE"  is
+       the name of the port number that _M_H POP will try to use, and defaults to
+       the name "pop".
+
+            To generate _M_H to use newer assigned port number, in your _M_H config
+       file, add:
+
+            options POPSERVICE='"pop3"'
+
+       And on both the POP client and service hosts, you  need  to  define  the
+       port that the POP service uses.  Add the line:
+
+            pop3            110/tcp
+
+       to the /etc/services file (if it's not already there).
+
+
+
+9                                         -20-
+
+
+
+
+
+
+
+
+
+                                         -21-
+
+
+            There are two ways to administer POP: In "naive" mode, each user-id
+       in  the  _p_a_s_s_w_d (5) file is considered a POP subscriber.  No changes are
+       required for the mailsystem on the  POP  service  host.   However,  this
+       method  requires  that each POP subscriber have an entry in the password
+       file.  The POP server will fetch the user's mail from wherever maildrops
+       are kept on the POP service host.  This means that if maildrops are kept
+       in the user's home directory, then each POP subscriber must have a  home
+       directory.
+
+            In "smart" mode (enabled via "DPOP" being given as a  configuration
+       option),  the  list  of  POP subscribers and the list of login users are
+       completely separate name spaces.  A separate database (simple file simi-
+       lar  to  the  _B_B_o_a_r_d_s (5) file) is used to record information about each
+       POP subscriber.  Unfortunately, the local mailsystem must be changed  to
+       reflect  this.   This  requires  two changes (both of which are simple):
+       First, the aliasing  mechanism  is  augmented  so  that  POP  subscriber
+       addresses are diverted to a special delivery mechanism.  _M_H comes with a
+       program, _p_o_p_a_k_a (8), which generates the additional  information  to  be
+       put  in the mailsystem's alias file.  Second, a special POP channel (for
+       MMDF-II) or POP mailer (for SendMail) performs the actual delivery (_m_h._6
+       supplies  both).   All  it really does is just place the mail in the POP
+       spool area.
+
+            These two different philosophies are not compatible on the same POP
+       service  host:  one or the other, but not both may be run.  Clever mail-
+       system people will note that the POP mechanism is really a special  case
+       of the more general BBoards mechanism.
+
+            In addition,  there  is  one  user-visible  difference,  which  the
+       administrator  controls  the availability of.  The difference is whether
+       the POP subscriber must supply a password to the POP server:  The  first
+       method  uses  the  standard  ARPA  technique of sending a username and a
+       password.  The appropriate programs (_i_n_c,  _m_s_g_c_h_k,  and  possibly  _b_b_c )
+       will prompt the user for this information.
+
+            The second method (which is enabled via "RPOP"  being  given  as  a
+       configuration  option)  uses  the Berkeley UNIX reserved port method for
+       authentication.  This requires that the two  or  three  mentioned  above
+       programs  be  _s_e_t_u_i_d to root.  (There are no known holes in any of these
+       programs.)
+
+            To add a POP subscriber, for the first method, one  simply  follows
+       the  usual procedures for adding a new user, which eventually results in
+       adding a line to the _p_a_s_s_w_d (5) file; for the second  method,  one  must
+       edit the POP database file (kept in the home directory of the POP user),
+       and then run the _p_o_p_a_k_a program.  The output of this program  is  placed
+       in the aliases file for the transport system (e.g., /usr/lib/aliases for
+       SendMail).
+
+            These two different philosophies are compatible  on  the  same  POP
+       service  host:  to  selectively  disable  RPOP  for  hosts  which aren't
+       trusted, either modify the ._r_h_o_s_t_s file in the case of  POP  subscribers
+
+
+
+
+
+
+
+
+
+
+
+                                         -22-
+
+
+       being  UNIX logins, or zero the contents of network address field of the
+  _p_o_p (5) file for the desired POP subscribers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+  POP(5)                            -23-                            POP(5)
+
+
+  _N_A_M_E
+       POP - POP database of subscribers
+
+  _S_Y_N_O_P_S_I_S
+       /usr/spool/pop/POP
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The POP database has exactly the same  format  as  the  _B_B_o_a_r_d_s (5)
+       database,  although  many  fields are unused.  Currently, only four
+       fields are examined:
+
+       _f_i_e_l_d               _v_a_l_u_e
+       name                the POP subscriber
+       primary file        the maildrop for the POP subscriber
+                           (relative to the POP directory)
+       encrypted password  the POP subscriber's password
+       network address     the remote user allowed to RPOP
+
+       This is an ASCII file.  Each field  within  each  POP  subscriber's
+       entry  is  separated from the next by a colon.  Each POP subscriber
+       is separated from the next by a new-line.  If the password field is
+       null, then no password is valid.
+
+       To add a new POP subscriber, edit the file adding a line such as
+
+            mrose::mrose:::::::0
+
+       Then, use _p_o_p_w_r_d to set the password for the  POP  subscriber.   If
+       you wish to allow POP subscribers to access their maildrops without
+       supplying a password (by using privileged ports), fill-in the  net-
+       work address field, as in:
+
+            mrose::mrose:::mrose@nrtc-isc::::0
+
+       which permits "mrose@nrtc-isc" to access the maildrop for  the  POP
+       subscriber "mrose".  Multiple network addresses may be specified by
+       separating them with commas, as in:
+
+            dave::dave:9X5/m4yWHvhCc::dave@romano.wisc.edu,dave@rsch.wisc.edu::::
+
+       To  disable  a  POP subscriber from _r_e_c_e_i_v_i_n_g mail, set the primary
+       file name to the empty string.  To prevent a  POP  subscriber  from
+       _p_i_c_k_i_n_g-_u_p mail, set the encrypted password to "*" and set the net-
+       work address to the empty string.
+
+       This file resides in home directory of the login "pop".  Because of
+       the  encrypted passwords, it can and does have general read permis-
+       sion.
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POP(5)                            -24-                            POP(5)
+
+
+  _F_i_l_e_s
+       /usr/spool/pop/POP                  POP database
+
+
+  _S_e_e _A_l_s_o
+       bboards(5), pop(8), popaka(8), popd(8), popwrd(8)
+
+
+  _B_u_g_s
+       A binary indexed file format should be available for fast access.
+
+       Appropriate precautions must be taken  to  lock  the  file  against
+       changes  if it is to be edited with a text editor.  A _v_i_p_o_p program
+       is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POP(8)                            -25-                            POP(8)
+
+
+  _N_A_M_E
+       pop - POP channel/mailer
+
+  _S_Y_N_O_P_S_I_S
+       /usr/mmdf/chans/pop fd1 fd2 [y]
+
+       /usr/local/lib/mh/spop POP-subscriber ...
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       For _M_M_D_F-_I_I, the POP channel delivers mail to the  POP  spool  area
+       for  later  retrieval  by  POP subscribers.  For _S_e_n_d_M_a_i_l, the SPOP
+       mailer performs this task.
+
+       For each address given, these programs consult the _p_o_p (5) file  to
+       obtain  information  about the POP-subscriber named by the address.
+       The programs then deliver the message to the  spool  area  for  the
+       POP-subscriber.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/spool/pop/POP                  POP database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       bboards(5), bbaka(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POPAKA(8)                         -26-                         POPAKA(8)
+
+
+  _N_A_M_E
+       popaka - generate POP entries for SendMail or MMDF-II alias file
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/popaka
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _p_o_p_a_k_a program reads the POP database and produces on its stan-
+       dard  output  a  file  suitable  for  inclusion  in the SendMail or
+       _M_M_D_F-_I_I aliases file.  The contents of this file  divert  mail  for
+       POP subscribers to the POP channel.
+
+  _F_i_l_e_s
+       /usr/spool/pop/POP                  POP database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       pop(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POPD(8)                           -27-                           POPD(8)
+
+
+  _N_A_M_E
+       popd - the POP server
+
+  _S_Y_N_O_P_S_I_S
+       /usr/etc/popd [-p portno] (under /etc/rc.local)
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _p_o_p_d server implements the Post Office protocol,  as  described
+       in  RFC1081  and RFC1082.  Basically, the server listens on the TCP
+       port named "pop" for connections and enters the POP upon establish-
+       ing a connection.  The `-p' option overrides the default TCP port.
+
+  _F_i_l_e_s
+       /usr/spool/pop/POP                  POP database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+       _P_o_s_t _O_f_f_i_c_e  _P_r_o_t_o_c_o_l  -  _v_e_r_s_i_o_n  _3:  _E_x_t_e_n_d_e_d  _s_e_r_v_i_c_e  _o_f_f_e_r_i_n_g_s
+       (RFC-1082),
+       pop(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _H_i_s_t_o_r_y
+       For historical reasons, the _M_H POP defaults to using the port named
+       "pop"  (109) instead of its newly assigned port named "pop3" (110).
+       See the POPSERVICE configuration option for more details.
+
+       Previous versions of the server (10/28/84) had the restriction that
+       the  POP  client  may retrieve messages for login users only.  This
+       restriction has been lifted, and  true  POB  support  is  available
+       (sending  mail  to a mailbox on the POP service host which does not
+       map to a user-id in the password file).
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POPWRD(8)                         -28-                         POPWRD(8)
+
+
+  _N_A_M_E
+       popwrd - set password for a POP subscriber
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/popwrd POP-subscriber
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _p_o_p_w_r_d program lets the super-user or the master POP user or  a
+       "leader"  of a POP subscriber change the password field for the POP
+       subscriber in the POP database.  This program is  very  similar  to
+       the _p_a_s_s_w_d (1) program.
+
+       Since only the super-user and the master POP user  may  change  any
+       other  fields of the POP database (using an ordinary editor), it is
+       possible for the system administrator to delegate responsibility to
+       others to manage groups of POP subscribers.
+
+  _F_i_l_e_s
+       /usr/spool/pop/POP                  POP database
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       pop(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       Although _p_o_p_w_r_d does locking against other invocations  of  _p_o_p_w_r_d,
+       editor  locking for the POP database in general is not implemented.
+       A _v_i_p_o_p program is needed.
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                  _5. _M_A_I_L _F_I_L_T_E_R_I_N_G
+
+
+
+9
+            There was a time when users on a UNIX host might have had two mail-
+       drops:  one  from  _M_M_D_F  and the other from _U_U_C_P.  This was really a bad
+       problem since it prevented using a single user-interface on all of  your
+       mail.  Furthermore, if you wanted to send a message to addresses on dif-
+       ferent mailsystems, you couldn't send just one message.   To  solve  all
+       these  problems, the notion of _m_a_i_l _f_i_l_t_e_r_i_n_g was developed that allowed
+       sophisticated munging and relaying between the two pseudo-domains.
+
+            _M_H will perform mail filtering, transparently, if given the MF con-
+       figuration  option.   However,  with  the advent of _S_e_n_d_M_a_i_l and further
+       maturation of _M_M_D_F, _M_H doesn't really need to  do  this  anymore,  since
+       these message transport agents handle it.
+
+            The mail-filtering stuff is too complicated.  It should be simpler,
+  but, protocol translation really _i_s difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                                    -29-
+
+
+
+
+
+
+
+
+
+  MF(1)                             -30-                             MF(1)
+
+
+  _N_A_M_E
+       muinc, musift, uminc, umsift - mail filters
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/muinc
+
+       /usr/local/lib/mh/musift [files ...]
+
+       /usr/local/lib/mh/uminc
+
+       /usr/local/lib/mh/umsift [files ...]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The mail filters are a set of programs that filter  mail  from  one
+       format  to another.  In particular, _U_U_C_P- and _M_M_D_F-style mail files
+       are handled.
+
+       _m_u_i_n_c filters mail from the user's _M_M_D_F maildrop  into  the  user's
+       _U_U_C_P  maildrop;  similarly, _u_m_i_n_c filters mail from the user's _U_U_C_P
+       maildrop into the user's _M_M_D_F maildrop.  These two programs respect
+       each system's maildrop locking protocols.
+
+       _m_u_s_i_f_t filters each file on the command line (or the standard input
+       if  no  arguments are given), and places the result on the standard
+       output in _U_U_C_P format.  The files (or standard input) are  expected
+       to  be  in  _M_M_D_F format.  _u_m_s_i_f_t does the same thing filtering _U_U_C_P
+       formatted files (or input), and places the _M_M_D_F formatted result on
+       the  standard  output.  No locking protocols are used by these pro-
+       grams.
+
+       If the files aren't in the expected format, the mail  filters  will
+       try to recover.  In really bad cases, you may lose big.
+
+  _F_i_l_e_s
+       /usr/spool/mail/                    UUCP spool area for maildrops
+       /usr/spool/mail/$USER               Location of standard maildrop
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _H_e_a_d_e_r _M_u_n_g_i_n_g (aka RFC-886),
+       inc(1)
+
+
+  _D_e_f_a_u_l_t_s
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MF(1)                             -31-                             MF(1)
+
+
+  _C_o_n_t_e_x_t
+
+
+  _B_u_g_s
+       Numerous; protocol translation is very difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RMAIL(8)                          -32-                          RMAIL(8)
+
+
+  _N_A_M_E
+       rmail - UUCP interface to mail
+
+  _S_Y_N_O_P_S_I_S
+       rmail address ...
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_m_a_i_l is intended as a replacement for those systems without  _S_e_n_d_-
+       _M_a_i_l  or  _M_M_D_F.   It  is  normally  invoked by _u_u_x on behalf of the
+       remote _U_U_C_P site.  For each address, it decides where to  send  it:
+       either locally, via another _U_U_C_P link, or via the Internet.
+
+       _R_m_a_i_l implements a crude access control facility by consulting  the
+       files  Rmail.OkHosts  and  Rmail.OkDests  in the /usr/local/lib/mh/
+       directory.  Hosts listed in the former file can  send  messages  to
+       anywhere  they please.  Hosts listed in the latter file can receive
+       messages from anywhere.  Note that a host listed in the first  file
+       is implicitly listed in the second file.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/local/lib/mh/Rmail.OkHosts     list of privileged hosts
+       /usr/local/lib/mh/Rmail.OkDests     list of privileged destinations
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       mf(1)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                    _6. _M_H _H_A_C_K_I_N_G
+
+
+
+9
+            Finally, here's a little information on modifying the  _M_H  sources.
+       A word of advice however:
+
+
+                                        _D_O_N'_T
+
+
+
+       If you really want new _M_H capabilities, write a  shell  script  instead.
+       After all, that's what UNIX is all about, isn't it?
+
+            Here's the organization of the _M_H source tree.
+
+            conf/        configurator tree
+            config/      compiled configuration constants
+            dist/        distributor
+            doc/         manual entries
+            h/           include files
+            miscellany/  various sundries
+            mts/         MTS-specific areas
+                         mh/        standalone delivery
+                         mmdf/      MMDF-I, MMDF-II
+                         sendmail/  SendMail, SMTP
+            papers/      papers about _M_H
+            sbr/         subroutines
+            support/     support programs and files
+                         bboards/   UCI BBoards facility
+                         general/   templates
+                         pop/       POP facility
+            tma/         Trusted Mail Agent (not present in all distributions)
+            uip/         programs
+            zotnet/      MTS-independent areas
+                         bboards/   UCI BBoards facility
+                         mf/        Mail Filtering
+                         mts/       MTS constants
+                         tws/       date routines
+
+
+
+
+
+
+
+
+
+
+
+9                                    -33-
+
+
+
+
+
+
+
+
+
+  MH-HACK(8)                        -34-                        MH-HACK(8)
+
+
+  _N_A_M_E
+       mh-hack - how to hack MH
+
+  _S_Y_N_O_P_S_I_S
+       big hack attack
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       This is a description of how one can modify the _M_H system.  The  _M_H
+       distribution has a lot of complex inter-relations, so before you go
+       modifying any code, you should read this  and  understand  what  is
+       going on.
+
+       ADDING A NEW PROGRAM
+            Suppose you want to create a new _M_H command  called  "pickle".
+            First, create and edit "pickle.c" in the uip/ directory.  Next
+            edit conf/makefiles/uip to include "pickle".   This  file  has
+            directions  at  the  end  of it which explain how it should be
+            modified.  Next, update any documentation  (described  below).
+            At  this  point  you  can  re-configure _M_H.  See _m_h-_g_e_n(_8) for
+            instructions on how to do this (basically, you want  "mhconfig
+            MH").
+
+       ADDING A NEW SUBROUTINE
+            Suppose you want to create a new _M_H routine  called  "pickle".
+            First, create and edit "pickle.c" in the sbr/ directory.  Next
+            edit conf/makefiles/sbr to include "pickle".   This  file  has
+            directions  at  the  end  of it which explain how it should be
+            modified.  You should modify  config/mh.h  to  define  "pickle
+            ();".   Similarly,  sbr/llib-lsbr should be modified for _l_i_n_t.
+            At this point you can re-configure _M_H.
+
+       UPDATING DOCUMENTATION
+            Edit whatever files you want in conf/doc/.  When documenting a
+            new program, such as "pickle", you should create a manual page
+            with the name "pickle.rf".  The file conf/doc/template  has  a
+            manual page template that you can use.  If you are documenting
+            a new program, then you should also update three other  files:
+            The  file  conf/doc/mh.rf  should  be  modified to include the
+            ".NA" section from "pickle.rf".  The file conf/doc/mh-chart.rf
+            should   be   modified  to  include  the  ".SY"  section  from
+            "pickle.rf".  Finally, the file conf/doc/MH.rf should be modi-
+            fied  to  include a ".so pickle.me".  Naturally, none of these
+            changes will be reflected in the configuration until you actu-
+            ally run _m_h_c_o_n_f_i_g.
+
+  _F_i_l_e_s
+       Too numerous to mention.  Honest.
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-HACK(8)                        -35-                        MH-HACK(8)
+
+
+  _S_e_e _A_l_s_o
+       mh-gen(8)
+
+
+  _B_u_g_s
+       Hacking is an art, but most programmers are butchers, not artists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                  _7. _H_I_D_D_E_N _F_E_A_T_U_R_E_S
+
+
+
+9
+            The capabilities discussed here should not be used on a  production
+       basis,  as they are either experimental, are useful for debugging _M_H, or
+       are otherwise not recommended.
+
+
+
+9       _D_e_b_u_g _F_a_c_i_l_i_t_i_e_s
+
+            The _m_a_r_k command has a `-debug' switch which essentially prints out
+       all the internal _M_H data structures for the folder you're looking at.
+
+            The _p_o_s_t command has a `-debug' switch which  does  everything  but
+       actually  post  the  message  for you.  Instead of posting the draft, it
+       sends it to the standard output.  Similarly, _s_e_n_d has a `-debug'  switch
+       which gets passed to _p_o_s_t.
+
+            Some _M_H commands look at envariables to determine debug-mode opera-
+       tion of certain new facilities.  The current list of envariables is:
+
+            MHFDEBUG     OVERHEAD facility
+            MHLDEBUG     mhl
+            MHPDEBUG     pick
+            MHPOPDEBUG   POP transactions
+            MHVDEBUG     window management transactions
+            MHWDEBUG     alternate-mailboxes
+
+
+
+9       _F_o_r_w_a_r_d_i_n_g _M_a_i_l
+
+            The _f_o_r_w and _m_h_l commands have  two  switches,  `-dashmunging'  and
+       `-nodashmunging'  which enable or disable the prepending of `- ' in for-
+       warded messages.  To use `-nodashmunging', you must use  an  _m_h_l  filter
+       file.
+
+
+
+9       _S_e_n_d
+
+            The _s_e_n_d command has two switches, `-unique' and `-nounique', which
+       are  useful  to certain individuals who, for obscure reasons, do not use
+       draft-folders.
+
+            "Distribution Carbon Copy" addresses may be specified in  the  _D_c_c:
+       header.  This header is removed before posting the message,and a copy of
+
+                                         -36-
+
+
+
+
+
+
+
+
+
+                                         -37-
+
+
+       the message is distributed to each listed address.  This could  be  con-
+       sidered a form of Blind Carbon Copy which is best used for sending to an
+       address which would never reply (such as an auto-archiver).
+
+
+
+9       _P_o_s_t_i_n_g _M_a_i_l
+
+            If you're running a version of _M_H which talks directly to  an  _S_M_T_P
+       server  (or  perhaps an advanced _M_M_D_F submit process), there are lots of
+       interesting switches for your amusement which _s_e_n_d and _p_o_s_t understand:
+            -mail         Use the _M_A_I_L command (default)
+            -saml         Use the _S_A_M_L command
+            -send         Use the _S_E_N_D command
+            -soml         Use the _S_O_M_L command
+            -snoop        Watch the _S_M_T_P transaction
+            -client host  Claim to be "host" when posting mail
+            -server host  Post mail with "host"
+
+            The last switch is to be useful when _M_H resides on  small  worksta-
+       tions  (or  PC:s) in a network--they can post their outgoing mail with a
+       local relay, and reduce the load on the local  system.   On  POP  client
+       hosts,  the  `-server host'  switch is defaulted appropriately using the
+       SMTP search-list mechanism.  The _w_h_o_m command understands the last three
+       switches.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                               _8. _C_O_N_F_I_G_U_R_A_T_I_O_N _O_P_T_I_O_N_S
+
+
+
+9
+            This manual was generated with the following configuration  options
+       in effect:
+
+
+       ________________________________________________________________________
+
+                   Generation Date             February 1, 1991
+                   Primary Directory           /usr/local/
+                   Secondary Directory         /usr/local/lib/mh/
+                   Maildrop Location           /usr/spool/mail/$USER
+                   POP Support                 Enabled
+                   BBoards using NNTP          Enabled
+                   Transport System            MMDF-II with SMTP
+       ________________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                                         -38-
+
+
+
+
+
+
+
+
+
+
+
+
+                                       _C_O_N_T_E_N_T_S
+
+
+
+
+       Section
+
+          1.  INTRODUCTION ...............................................    1
+9            Scope of this document .......................................    1
+9            Summary ......................................................    1
+
+          2.  THE MTS INTERFACE ..........................................    3
+               MH-TAILOR .................................................    4
+               MH-MTS ....................................................   10
+
+          3.  BBOARDS ....................................................   12
+9            BBoard Delivery ..............................................   12
+9            BBoards with the POP .........................................   13
+9            BBoards with the NNTP ........................................   14
+               BBOARDS ...................................................   15
+               BBAKA .....................................................   16
+               BBEXP .....................................................   17
+               BBOARDS ...................................................   18
+               BBTAR .....................................................   19
+
+          4.  POP ........................................................   20
+               POP .......................................................   23
+               POP .......................................................   25
+               POPAKA ....................................................   26
+               POPD ......................................................   27
+               POPWRD ....................................................   28
+
+          5.  MAIL FILTERING .............................................   29
+               MF ........................................................   30
+               RMAIL .....................................................   32
+
+          6.  MH HACKING .................................................   33
+               MH-HACK ...................................................   34
+
+          7.  HIDDEN FEATURES ............................................   36
+9            Debug Facilities .............................................   36
+9            Forwarding Mail ..............................................   36
+9            Send .........................................................   36
+9            Posting Mail .................................................   37
+
+          8.  CONFIGURATION OPTIONS ......................................   38
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                               THE RAND MH
+
+9                            MESSAGE HANDLING
+
+9                                 SYSTEM:
+
+9                          ADMINISTRATOR'S GUIDE
+
+
+
+
+
+
+                               UCI Version
+
+
+
+
+
+                            Marshall T. Rose
+
+
+
+
+                             _F_i_r_s_t _E_d_i_t_i_o_n:
+
+                               _M_H _C_l_a_s_s_i_c
+
+            (_N_o_t _t_o _b_e _c_o_n_f_u_s_e_d _w_i_t_h _a _w_e_l_l-_k_n_o_w_n _s_o_f_t _d_r_i_n_k)
+
+
+
+
+
+
+
+                            February 1, 1991
+
+                             6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
diff --git a/docs/historical/ADMIN.pdf b/docs/historical/ADMIN.pdf
new file mode 100644
index 0000000..f716c79
Binary files /dev/null and b/docs/historical/ADMIN.pdf differ
diff --git a/docs/historical/ADMIN.txt b/docs/historical/ADMIN.txt
new file mode 100644
index 0000000..8e4cda8
--- /dev/null
+++ b/docs/historical/ADMIN.txt
@@ -0,0 +1,2904 @@
+
+
+
+
+
+
+
+
+                                            _d_i_s_c_a_r_d _t_h_i_s _p_a_g_e
+
+
+
+
+                                               The RAND _M_H
+                                             Message Handling
+                                                 System:
+                                          Administrator's Guide
+
+                                               UCI Version
+
+
+                                            November 30, 1993
+                                              6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                             _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+
+
+                 _S_c_o_p_e _o_f _t_h_i_s _d_o_c_u_m_e_n_t
+
+                      This is the Administrator's Guide to _M_H.  If you don't maintain  an
+                 _M_H  system,  don't read this; the information is entirely too technical.
+                 If you are a maintainer, then read this guide until you  understand  it,
+                 follow the advice it gives, and then forget about the guide.
+
+                      Before continuing, I'll point out two facts:
+
+
+
+                           _T_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _a_l_l _t_h_e _i_n_f_o_r_m_a_t_i_o_n
+                                         _y_o_u _n_e_e_d _t_o _m_a_i_n_t_a_i_n _M_H.
+
+                         _F_u_r_t_h_e_r_m_o_r_e, _t_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _e_v_e_r_y_t_h_i_n_g
+                                       _I _k_n_o_w _a_b_o_u_t _m_a_i_n_t_a_i_n_i_n_g _M_H.
+
+
+
+                 _M_H, and mailsystems in general, are more complex than most people  real-
+                 ize.   A  combination of experience, intuition, and tenacity is required
+                 to maintain _M_H properly.  This document can provide only guidelines  for
+                 bringing  up  an  _M_H  system  and maintaining it.  There is a sufficient
+                 amount of customization possible that not all events or problems can  be
+                 forseen.
+
+
+
+                 _S_u_m_m_a_r_y
+
+                      During _M_H generation, you specify several  configuration  constants
+                 to  the _m_h_c_o_n_f_i_g program.  These directives take into consideration such
+                 issues as hardware and operating system dependencies in the source code.
+                 They also factor out some major mailsystem administrative decisions that
+                 are likely to be made consistantly at sites with  more  than  one  host.
+                 The  manual  entry  _m_h-_g_e_n (8)  describes  all  the static configuration
+                 directives.
+
+                      However,  when  you  install  _M_H  you  may  wish   to   make   some
+                 site-specific  or  host-specific  changes  which aren't hardware or even
+                 software related.  Rather, they are  administrative  decisions.   That's
+                 what  this  guide is for: it describes all of the dynamically tailorable
+                 directives.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -2-
+
+
+                      Usually,  after  installing   _M_H,   you'll   want   to   edit   the
+                 /usr/local/lib/mh/mtstailor  file.   This  file  fine-tunes  the  way _M_H
+                 interacts with the message transport  system  (MTS).   Section  2  talks
+                 about the MTS interface and MTS tailoring.
+
+                      After that, if you're running the UCI BBoards facility, or the  POP
+                 facility, you'll need to know how to maintain those systems.  Sections 3
+                 and 4 talk about these.
+
+                      If for some reason you're not running an MTS that can  handle  both
+                 Internet  and _U_U_C_P traffic, you should read-up on mail filtering in Sec-
+                 tion 5.  Although this is considered "old technology" now,  the  mechan-
+                 isms  described  in Section 5 were really quite useful when first intro-
+                 duced way back in 1981.
+
+                      Finally, you may want to know how to modify  the  _M_H  source  tree.
+                 Section 6 talks (a little bit) about that.
+
+                      The last two sections describe a few hidden features in _M_H, and the
+                 configuration options that were in effect when this guide was generated.
+
+                      After _M_H is installed, you should define the  address  "Bug-MH"  to
+                 map to either you or the _P_o_s_t_M_a_s_t_e_r at your site.
+
+                      In addition, if you want to tailor  the  behavior  of  _M_H  for  new
+                 users,  you  can  create and edit the file /usr/local/lib/mh/mh.profile.
+                 When the _i_n_s_t_a_l_l-_m_h program is run for a user, if this file  exists,  it
+                 will copy it into the user's .mh_profile file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                           _2. _T_H_E _M_T_S _I_N_T_E_R_F_A_C_E
+
+
+
+
+
+                      The    file    /usr/local/lib/mh/mtstailor    customizes    certain
+                 host-specific  parameters  of  _M_H related primarily to interactions with
+                 the  transport  system.   The  parameters  in  this  file  override  the
+                 compiled-in  defaults given during _M_H configuration.  Rather than recom-
+                 piling _M_H on each host to make minor customizations, it is easier simply
+                 to  modify  the  mtstailor file.  All hosts at a given site normally use
+                 the same mtstailor file, though this need not be the case.
+
+                      It is a good idea to run  the  _c_o_n_f_l_i_c_t (8)  program  each  morning
+                 under _c_r_o_n.  The following line usually suffices:
+
+                      00 05 * * * /usr/local/lib/mh/conflict -mail PostMaster
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                              -3-
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -4-                       MH-TAILOR(5)
+
+
+            _N_A_M_E
+                 mh-tailor, mtstailor - system customization for MH message handler
+
+
+            _S_Y_N_O_P_S_I_S
+                 /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_m_t_s_t_a_i_l_o_r
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The file /usr/local/lib/mh/mtstailor defines run-time  options  for
+                 those  _M_H  programs  which interact (in some form) with the message
+                 transport system.  At present, these (user) programs are: _a_p,  _c_o_n_-
+                 _f_l_i_c_t, _i_n_c, _m_s_g_c_h_k, _m_s_h, _p_o_s_t, _r_c_v_d_i_s_t, and _r_c_v_p_a_c_k.
+
+                 Each option should be given on a  single  line.   Blank  lines  and
+                 lines  which  begin  with  `#'  are ignored.  The options available
+                 along with default values and a description of their  meanings  are
+                 listed below:
+
+                 localname:
+                      The host name _M_H considers local.  If not  set,  depending  on
+                      the  version  of UNIX you're running, _M_H will query the system
+                      for this value (e.g., <whoami.h>,  gethostname,  etc.).   This
+                      has  no  equivalent  in the _M_H configuration file.  POP client
+                      hosts should set this value to the name  of  the  POP  service
+                      host.
+
+                 localdomain:
+                      If this is set, a `.' followed by this string will be appended
+                      to  your  host name.  This might be useful for sites where the
+                      host name returned by the system (e.g.,  <whoami.h>,  gethost-
+                      name,  etc.),  is  not  a "fully qualified domain name" (i.e.,
+                      does not contain a `.').
+
+                 clientname:
+                      The host name _M_H will give in the SMTP HELO  (and  EHLO)  com-
+                      mand,  when posting mail.  If not set, no HELO command will be
+                      given.  Although the HELO command is required by RFC 821, many
+                      SMTP servers do not require it.
+
+                      Early versions of SendMail will fail if the host name given in
+                      the HELO command is the local host; later versions of SendMail
+                      will complain if you omit the HELO command.  If you run  Send-
+                      Mail,  find  out  what  your system expects and set this field
+                      accordingly.
+
+                 systemname:
+                      The name of the local host in the _U_U_C_P "domain".  If not  set,
+                      depending on the version of UNIX you're running, _M_H will query
+                      the system for this value.  This has no equivalent in  the  _M_H
+                      configuration file.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -5-                       MH-TAILOR(5)
+
+
+                 mmdfldir: /usr/spool/mail
+                      The directory where maildrops are kept.  If this is empty, the
+                      user's  home  directory  is  used.   This overrides the "mail"
+                      field in the _M_H configuration file.
+
+                 mmdflfil:
+                      The name of the maildrop file in the directory where maildrops
+                      are  kept.   If  this is empty, the user's login name is used.
+                      This overrides the "mail" field in the _M_H configuration file.
+
+                 mmdelim1: \001\001\001\001\n
+                      The beginning-of-message delimiter for maildrops.
+
+                 mmdelim2: \001\001\001\001\n
+                      The end-of-message delimiter for maildrops.
+
+                 mmailid: 0
+                      If non-zero, then  support  for  MMailids  in  /etc/passwd  is
+                      enabled.   Basically,  the pw_gecos field in the password file
+                      is of the form
+
+                           My Full Name <mailid>
+
+                      The _M_H internal routines that deal with user  and  full  names
+                      will return "mailid" and "My Full Name" respectively.
+
+                 lockstyle: 0
+                      The locking discipline to perform.  A value of  "0"  means  to
+                      use  kernel-level  locking  if available.  (See below for more
+                      details.) On systems compiled  without  kernel-level  locking,
+                      standard  _B_e_l_l_M_a_i_l  locking  is used.  A value of "1" means to
+                      use _B_e_l_l_M_a_i_l locking always (the name of the lock is based  on
+                      the  file  name).   A  value  of "2" means to use _M_M_D_F locking
+                      always (the name of the lock is based on device/inode pairs).
+
+                 lockldir:
+                      The name of the directory for making locks.   If  your  system
+                      isn't configured to use kernel-level locking, then this direc-
+                      tory is used when creating locks.  If the value is empty, then
+                      the directory of the file to be locked is used.
+
+                 maildelivery: /usr/local/lib/mh/maildelivery
+                      The name of the system-wide default ._m_a_i_l_d_e_l_i_v_e_r_y  file.   See
+                      _m_h_o_o_k (1) for the details.
+
+                 everyone: 200
+                      The highest user-id which should NOT receive mail addressed to
+                      "everyone".
+
+                 noshell:
+                      If set, then each user-id greater than "everyone" that  has  a
+                      login  shell  equivalent to the given value (e.g., "/bin/csh")
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -6-                       MH-TAILOR(5)
+
+
+                      indicates that mail for "everyone" should not be sent to them.
+                      This is useful for handling admin, dummy, and guest logins.
+
+              _M_a_i_l _F_i_l_t_e_r_i_n_g
+
+                 These  options  are  only  available  if  you  compiled   _M_H   with
+                 "options MF".
+
+                 uucpchan: name of _U_U_C_P channel
+                      Usually "UUCP".  This has no equivalent in the  _M_H  configura-
+                      tion file.
+
+                 uucpldir: /usr/spool/mail
+                      The name of the directory where _U_U_C_P maildrops are kept.  This
+                      has no equivalent in the _M_H configuration file.
+
+                 uucplfil:
+                      The name of the maildrop file  in  the  directory  where  _U_U_C_P
+                      maildrops  are  kept.  If this is empty, the user's login name
+                      is used.  This has no equivalent in the _M_H configuration file.
+
+                 umincproc: /usr/local/lib/mh/uminc
+                      The path to the program that filters _U_U_C_P-style  maildrops  to
+                      _M_M_D_F-style maildrops.
+
+              _S_t_a_n_d-_A_l_o_n_e _D_e_l_i_v_e_r_y
+
+                 These options are only available if you compiled _M_H to  use  stand-
+                 alone delivery (i.e., "mts: mh").
+
+                 mailqdir: /usr/spool/netmail
+                      The directory where network mail is queued.
+
+                 tmailqdir: /usr/tmp
+                      The directory where network mail queue files are built.
+
+                 syscpy: 1
+                      If ON, unauthorized mail is copied to the overseer.
+
+                 overseer: root
+                      The user that receives reports of unauthorized mail.
+
+                 mailer: root
+                      The user acting for the mail system.
+
+                 fromtmp: /tmp/rml.f.XXXXXX
+                      The _m_k_t_e_m_p template for storing from lines.
+
+                 msgtmp: /tmp/rml.m.XXXXXX
+                      The _m_k_t_e_m_p template for storing the rest of the message.
+
+                 errtmp: /tmp/rml.e.XXXXXX
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -7-                       MH-TAILOR(5)
+
+
+                      The _m_k_t_e_m_p template for  storing  error  messages  from  other
+                      mailers.
+
+                 tmpmode: 0600
+                      The octal mode which temporary files are set to.
+
+                 okhosts: /usr/local/lib/mh/Rmail.OKHosts
+                      A file containing a list of hosts that can send ARPAnet mail.
+
+                 okdests: /usr/local/lib/mh/RMail.OKDests
+                      A file containing a list of  hosts  that  can  always  receive
+                      mail.
+
+              _T_h_e `/_s_m_t_p' _M_T_S _S_u_f_f_i_x
+
+                 These options are only  available  if  you  compiled  _M_H  with  the
+                 "/smtp" suffix to your "mts:" configuration.
+
+                 hostable: /usr/local/lib/mh/hosts
+                      The exceptions file for /etc/hosts used by _p_o_s_t to try to find
+                      official names.  The format of this file is quite simple:
+
+                           1. Comments are surrounded by sharp (`#') and newline.
+                           2. Words are surrounded by white space.
+                           3. The first word on the line is the official name  of  a
+                           host.
+                           4. All words following the official names are aliases for
+                           that host.
+
+                 servers: localhost \01localnet
+                      A lists of hosts and networks which to look for  SMTP  servers
+                      when posting local mail.  It turns out this is a major win for
+                      hosts which don't run an message transport system.  The  value
+                      of  "servers"  should  be one or more items.  Each item is the
+                      name of either a host or a net (in the  latter  case,  precede
+                      the  name  of  the  net by a \01).  This list is searched when
+                      looking for a smtp server to post mail.  If a host is present,
+                      the SMTP port on that host is tried.  If a net is present, the
+                      SMTP port on each host in that net is tried.  Note that if you
+                      are  running  with  the BIND code, then any networks specified
+                      are ignored (sorry, the interface went away under BIND).
+
+              _S_e_n_d_M_a_i_l
+
+                 This option is only available if you compiled _M_H to use _S_e_n_d_M_a_i_l as
+                 your delivery agent (i.e., "mts: sendmail").
+
+                 sendmail: /usr/lib/sendmail
+                      The pathname to the _s_e_n_d_m_a_i_l program.
+
+              _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -8-                       MH-TAILOR(5)
+
+
+                 This option is only available if you compiled _M_H with  POP  support
+                 enabled (i.e., "pop: on").
+
+                 pophost:
+                      The name of the default POP service host.  If this is not set,
+                      then _M_H looks in the standard maildrop areas for waiting mail,
+                      otherwise the named POP service host is consulted.
+
+              _B_B_o_a_r_d_s _D_e_l_i_v_e_r_y
+
+                 This  option  is  only  available   if   you   compiled   _M_H   with
+                 "bbdelivery: on".
+
+                 bbdomain:
+                      The local BBoards domain (a UCI hack).
+
+              _B_B_o_a_r_d_s & _T_h_e _P_O_P
+
+                 These  options  are  only  available  if  you  compiled   _M_H   with
+                 "bboards: pop" and "pop: on".
+
+                 popbbhost:
+                      The POP service host which also acts as a BBoard server.  This
+                      variable should be set on the POP BBoards client host.
+
+                 popbbuser:
+                      The guest account on the POP/BB service host.  This should  be
+                      a  different  login ID than either the POP user or the BBoards
+                      user.  (The user-id "ftp" is highly recommended.)  This  vari-
+                      able  should be set on both the POP BBoards client and service
+                      hosts.
+
+                 popbblist: /usr/local/lib/mh/hosts.popbb
+                      A file containing of lists of hosts that are  allowed  to  use
+                      the  POP  facility  to access BBoards using the guest account.
+                      If this file is not present, then  no  check  is  made.   This
+                      variable should be set on the POP BBoards service host.
+
+              _B_B_o_a_r_d_s & _T_h_e _N_N_T_P
+
+                 This  option  is  only  available   if   you   compiled   _M_H   with
+                 "bboards: nntp" and "pop: on".
+
+                 nntphost:
+                      The host which  provides  the  NNTP  service.   This  variable
+                      should be set on the NNTP BBoards client host.
+
+              _F_i_l_e _L_o_c_k_i_n_g
+
+                 A few words on locking: _M_H has a flexible locking system for making
+                 locks  on  files.   There are two mtstailor variables you should be
+                 aware of "lockstyle" and "lockldir".  The first controls the method
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-TAILOR(5)                      -9-                       MH-TAILOR(5)
+
+
+                 of locking, the second says where lock files should be created.
+
+                 The "lockstyle" variable can take on three  values:  0,  1,  2.   A
+                 value  of 0 is useful on systems with kernel-level locking.  If you
+                 are on a BSD42 system, _M_H assumes you have the _f_l_o_c_k  system  call.
+                 On  other systems: define FLOCK if you want to use the _f_l_o_c_k system
+                 call; define LOCKF if you want to use the  _l_o_c_k_f  system  call;  or
+                 define  FCNTL  if you want to use the _f_c_n_t_l system call for kernel-
+                 level locking.  If you haven't configured _M_H  to  use  kernel-level
+                 locking,  a  locking  style  of 0 is considered the same as locking
+                 style 1.
+
+                 A value of 1 or 2 specifies that a file  should  be  created  whose
+                 existence  means "locked" and whose non-existence means "unlocked".
+                 A value of 1 says to construct the lockname by appending ".lock" to
+                 the  name of the file being locked.  A value of 2 says to construct
+                 the lockname by looking at the device and inode numbers of the file
+                 being  locked.   If  the "lockldir" variable is not specified, lock
+                 files will be created in the directory where the file being  locked
+                 resides.   Otherwise,  lock  files will be created in the directory
+                 specified by "lockldir".  Prior to installing _M_H,  you  should  see
+                 how locking is done at your site, and set the appropriate values.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 mh-gen(8), mh-mts(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 As listed above
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MTS(8)                         -10-                         MH-MTS(8)
+
+
+            _N_A_M_E
+                 mh-mts - the MH interface to the message transport system
+
+            _S_Y_N_O_P_S_I_S
+                 SendMail
+
+                 Zmailer
+
+                 MMDF (any release)
+
+                 stand-alone
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_H can use a wide range of message  transport  systems  to  deliver
+                 mail.   Although the _M_H administrator usually doesn't get to choose
+                 which MTS to use (since  it's  already  in  place),  this  document
+                 briefly describes the interfaces.
+
+                 When communicating with _S_e_n_d_M_a_i_l, _M_H always uses the SMTP  to  post
+                 mail.   Depending  on the _M_H configuration, _S_e_n_d_M_a_i_l may be invoked
+                 directly (via a _f_o_r_k and an _e_x_e_c), or _M_H may open a TCP/IP  connec-
+                 tion to the SMTP server on the localhost.
+
+                 When communicating with _z_m_a_i_l_e_r, the _S_e_n_d_M_a_i_l compatibility program
+                 is  required  to  be  installed  in /usr/lib.  _M_H communicates with
+                 _z_m_a_i_l_e_r  by  using  the  SMTP.   It  does  this  by  invoking   the
+                 /usr/lib/sendmail  compatibility  program  directly, with the `-bs'
+                 option.
+
+                 When communicating with _M_M_D_F, normally _M_H uses the  "mm_"  routines
+                 to  post  mail.   However,  depending  on  the _M_H configuration, _M_H
+                 instead may open a TCP/IP connection to  the  SMTP  server  on  the
+                 localhost.
+
+                 When using the stand-alone system (NOT  recommended),  _M_H  delivers
+                 local  mail  itself  and queues _U_U_C_P and network mail.  The network
+                 mail portion will probably have to be modified to reflect the local
+                 host's  tastes,  since there is no well-known practice in this area
+                 for all types of UNIX hosts.
+
+                 If you are running a UNIX system with TCP/IP networking, then it is
+                 felt  that  the best interface is achieved by using either _S_e_n_d_M_a_i_l
+                 or _M_M_D_F with the SMTP option.  This gives greater flexibility.   To
+                 enable this option you append the /smtp suffix to the mts option in
+                 the _M_H configuration.  This yields two primary  advantages:  First,
+                 you  don't  have to know where _s_u_b_m_i_t or _S_e_n_d_M_a_i_l live.  This means
+                 that _M_H binaries (e.g., _p_o_s_t ) don't have to have this  information
+                 hard-coded,  or can run different programs altogether; and, second,
+                 you can post mail with the server  on  different  systems,  so  you
+                 don't  need either _M_M_D_F or _S_e_n_d_M_a_i_l on your local host.  Big win in
+                 conserving cycles and disk space.  Since _M_H supports the notion  of
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MTS(8)                         -11-                         MH-MTS(8)
+
+
+                 a server search-list in this respect, this approach can be tolerant
+                 of faults.  Be sure to set "servers:" as described in  mh-tailor(8)
+                 if you use this option.
+
+                 There are four disadvantages to using the SMTP option: First,  only
+                 UNIX  systems  with TCP/IP are supported.  Second, you need to have
+                 an SMTP server running somewhere on any network your local host can
+                 reach.   Third, this bypasses any authentication mechanisms in _M_M_D_F
+                 or _S_e_n_d_M_a_i_l.  Fourth, the file  /etc/hosts  is  used  for  hostname
+                 lookups  (although  there  is  an  exception file).  In response to
+                 these disadvantages though: First, there's got to be an SMTP server
+                 somewhere around if you're in the Internet or have a local network.
+                 Since the server search-list  is  very  general,  a  wide-range  of
+                 options are possible.  Second, SMTP should be fixed to have authen-
+                 tication mechanisms in it, like POP.  Third, _M_H won't choke on mail
+                 to  hosts  whose  official  names  it can't verify, it'll just plug
+                 along (and besides if you enable the  BERK  or  DUMB  configuration
+                 options, _M_H ignores the hosts file altogether).
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 _M_M_D_F-_I_I: _A _T_e_c_h_n_i_c_a_l _R_e_v_i_e_w, Proceedings, Usenix Summer '84 Confer-
+                 ence
+                 _S_E_N_D_M_A_I_L -- _A_n _I_n_t_e_r_n_e_t_w_o_r_k _M_a_i_l _R_o_u_t_e_r
+                 mh-tailor(8), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The /usr/local/lib/mh/mtstailor file ignores the information in the
+                 _M_M_D_F-_I_I tailoring file.  It should not.
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                                _3. _B_B_O_A_R_D_S
+
+
+
+
+
+                      The UCI BBoards facility has two aspects: message reading, and mes-
+                 sage  delivery.   The configuration directives applicable to BBoards are
+                 "bboards: on/off/pop/nntp" and "bbdelivery: on/off".
+
+
+                 _B_B_o_a_r_d _D_e_l_i_v_e_r_y
+
+                      If you enabled BBoards delivery ("bbdelivery:  on")  during  confi-
+                 guration,  then  the initial environment for bboards delivery was set-up
+                 during installation.  A BBoard called "system" is established, which  is
+                 the BBoard for general discussion.
+
+                      To add more BBoards,  become  the  "bboards"  user,  and  edit  the
+                 /usr/spool/bboards/BBoards  file.  The file support/bboards/Example is a
+                 copy of the /usr/spool/bboards/BBoards file that we use  at  UCI.   When
+                 you add a BBoard, you don't have to create the files associated with it,
+                 the BBoards delivery system will do that automatically.
+
+                      Private BBoards may be created.   To  add  the  fictitious  private
+                 BBoard  "hacks",  add  the appropriate entry to the BBoards file, create
+                 the empty file /usr/spool/bboards/hacks.mbox (or whatever),  change  the
+                 mode  of  this  file to 0640, and change the group of the file to be the
+                 groupid of the people that you want to be able to read it.  Also be sure
+                 to add the "bboards" user to this group (in /etc/group), so the archives
+                 can be owned correctly.
+
+                      By using the special INVIS  flag  for  a  BBoard,  special  purpose
+                 BBoards  may be set-up which are invisible to the _M_H user.  For example,
+                 if a site distributes a BBoard both locally to a number of machines  and
+                 to a number of distant machines.  It might be useful to have two distri-
+                 bution lists: one for all machines on the list, and the other for  local
+                 machines  only.  This is actually very simple to do.  For the main list,
+                 put the standard entry of information in the  /usr/spool/bboards/BBoards
+                 file, with the complete distribution list.  For the local machines list,
+                 and add a similar entry to the /usr/spool/bboards/BBoards file.  All the
+                 fields should be the same except three: the BBoard name should reflect a
+                 local designation (e.g., "l-hacks"), the distribution list  should  con-
+                 tain only machines at the local site, and the flags field should contain
+                 the INVIS flag.  Since the  two  entries  share  the  same  primary  and
+                 archive  files,  messages  sent  to either list are read by local users,
+                 while only thoses messages sent to the main list are read by all users.
+
+                      Two automatic facilities for dealing with BBoards exist:  automatic
+                 archiving and automatic aliasing.  The file support/bboards/crontab con-
+                 tains some entries that you should add to your /usr/lib/crontab file  to
+                 run  the  specified  programs at times that are convenient for you.  The
+
+                                                   -12-
+
+
+
+
+
+
+
+
+
+                                                   -13-
+
+
+                 bboards.daily file is run once a day and generates an alias file for _M_H.
+                 By  using  this  file,  users of _M_H can use, for example, "unix-wizards"
+                 instead of "unix-wizards@brl-vgr" when they want to send  a  message  to
+                 the  "unix-wizards"  discussion  group.   This is a major win, since you
+                 just have to know the name of the group,  not  the  address  where  it's
+                 located.
+
+                      The bboards.weekly file is run once a week and handles old messages
+                 (those  received  more than 12 days ago) in the BBoards area.  In short,
+                 those BBoards which are marked for automatic archiving will  have  their
+                 old  messages  placed  in  the /usr/spool/bboards/archive/ area, or have
+                 their old messages removed.  Not only does this make BBoards  faster  to
+                 read,  but it conveniently partitions the new messages from the old mes-
+                 sages so you can easily put the old messages on  tape  and  then  remove
+                 them.   It  turns out that this automatic archiving capability is also a
+                 major win.
+
+                      At UCI, our policy is to save archived messages on tape (every  two
+                 months  or so).  We use a program called _b_b_t_a_r to implement our particu-
+                 lar policy.  Since some BBoards are private (see  above),  we  save  the
+                 archives  on two tapes: one containing the world-readable archives (this
+                 tape is read-only accessible to all users by calling the operator),  and
+                 the  other  containing  the  non-world-readable  ones (this tape is kept
+                 locked-up somewhere).
+
+
+                 _B_B_o_a_r_d_s _w_i_t_h _t_h_e _P_O_P
+
+                      If you configured _M_H with "bboards: pop" and "pop: on", then the _M_H
+                 user is allowed to read BBoards on a server machine instead of the local
+                 host (thus saving disk space).  For completely transparent behavior, the
+                 administrator  may  set  certain  variables in the mtstailor file on the
+                 client host.  The variable "popbbhost" indicates the host where  BBoards
+                 are kept (it doesn't have to be the POP service host, but this host must
+                 run both a POP server and the BBoards system).  The variable "popbbuser"
+                 indicates  the  guest  account  on this host for BBoards.  This username
+                 should not be either the POP user or  the  BBoards  user.   Usually  the
+                 anonymous  FTP  user  (ftp)  is  the best choice.  Finally, the variable
+                 "popbblist" indicates the name of a file which contains a list of  hosts
+                 (one to a line, official host names only) which should be allowed to use
+                 the POP facility to access BBoards via the guest account.  (If the  file
+                 is not present, then no check is made.)
+
+                      The "popbbuser" variable should be set on both the client and  ser-
+                 vice host.  The "popbbhost" variable need be set only on the client host
+                 (the  value,  of  course,  is  the  name  of  the  service  host).   The
+                 "popbblist" variable need be set only on the service host.
+
+                      Finally, on the client host, if a POP service host  is  not  expli-
+                 citly given by the user (i.e., "popbbhost" is implicitly used), then _b_b_c
+                 will explicitly check the local host prior  to  contacting  the  service
+                 host.   This  allows  each  POP  client host to have a few local BBoards
+
+
+
+
+
+
+
+
+
+
+
+                                                   -14-
+
+
+                 (e.g., each host could have one called "system"), and then have the  POP
+                 service host used for all the rest (a site-wide BBoard might be known as
+                 "general").
+
+
+                 _B_B_o_a_r_d_s _w_i_t_h _t_h_e _N_N_T_P
+
+                      If you configured _M_H with "bboards: nntp" and "pop: on",  then  the
+                 _M_H  user  is  allowed to read the Network News on a server machine using
+                 the standard _b_b_c command.   For  completely  transparent  behavior,  the
+                 administrator  may  set the "nntphost" variable in the mtstailor file to
+                 indicate the host where the Network News is kept.  The "nntphost"  vari-
+                 able  should be set only on the client host Finally, on the client host,
+                 if an NNTP service host is not  explicitly  given  by  the  user  (i.e.,
+                 "nntphost" is implicitly used), then _b_b_c will explicitly check the local
+                 host prior to contacting the service host.  This allows each NNTP client
+                 host  to have a few local BBoards (e.g., each host could have one called
+                 "system"), and then have the NNTP service host used for to read the Net-
+                 work News.
+
+                      Reading  BBoards  via  the  POP  and  via  the  NNTP  are  mutually
+            exclusive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            BBOARDS(5)                        -15-                        BBOARDS(5)
+
+
+            _N_A_M_E
+                 BBoards - BBoards database
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/spool/bboards/BBoards
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The BBoards database contains for each BBoard the following  infor-
+                 mation:
+
+                 _f_i_e_l_d               _v_a_l_u_e
+                 name                the name of the BBoard
+                 aliases             local aliases for the BBoard
+                                     (separated by commas)
+                 primary file        the .mbox file
+                 encrypted password  leadership password
+                 leaders             local list maintainers (separated by commas)
+                                     usernames from the _p_a_s_s_w_d (5) file,
+                                     or groupnames preceded by `=' from the
+                                     _g_r_o_u_p (5) file
+                 network address     the list address
+                 request address     the list maintainer's address
+                 relay               the host acting as relay for the local domain
+                 distribution sites  (separated by commas)
+                 flags               special flags (see <bboards.h>)
+
+                 This is an ASCII file.  Each field within each  BBoard's  entry  is
+                 separated from the next by a colon.  Each BBoard entry is separated
+                 from the next by a new-line.  If the password  field  is  null,  no
+                 password  is  demanded;  if  it contains a single asterisk, then no
+                 password is valid.
+
+                 This file resides in the home directory  of  the  login  "bboards".
+                 Because  of  the  encrypted passwords, it can and does have general
+                 read permission.
+
+            _F_i_l_e_s
+                 /usr/spool/bboards/BBoards          BBoards database
+
+
+            _S_e_e _A_l_s_o
+                 bbaka(8), bbexp(8), bboards (8), bbtar(8)
+
+
+            _B_u_g_s
+                 A binary indexed file format should be available for fast access.
+
+                 Appropriate precautions must be taken  to  lock  the  file  against
+                 changes  if  it is to be edited with a text editor.  A _v_i_b_b program
+                 is needed.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(5)                        -16-                        BBOARDS(5)
+
+
+            _N_A_M_E
+                 bbaka - generate an alias list for BBoards
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/spool/bboards/bbaka [system]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _b_b_a_k_a program reads the BBoards database and  produces  on  its
+                 standard output a file suitable for inclusion in either the _M_M_D_F-_I_I
+                 aliases file (if the argument `system' is given).  If the  argument
+                 is  not  given,  then  _b_b_a_k_a produces on its standard output a file
+                 suitable for becoming the /usr/local/lib/mh/BBoardsAliases file.
+
+            _F_i_l_e_s
+                 /usr/spool/bboards/BBoards          BBoards database
+                 /usr/local/lib/mh/BBoardsAliases    BBoards aliases file for _M_H
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 bboards(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBEXP(8)                          -17-                          BBEXP(8)
+
+
+            _N_A_M_E
+                 bbexp - expunge the BBoards area
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/spool/bboards/bbexp [-_f_i_r_s_t-_m_e_t_r_i_c] [-_s_e_c_o_n_d-_m_e_t_r_i_c]
+                      [bboards ...]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _b_b_e_x_p program reads the  BBoards  database  and  calls  _m_s_h  to
+                 archive the named BBoards (or all BBoards if none are specified).
+
+                 The first-metric (which defaults to 12) gives the age  in  days  of
+                 the  "BB-Posted:" field for messages which should be expunged.  The
+                 second-metric (which defaults to 20) gives the age in days  of  the
+                 "Date:"  field  for messages which should be expunged.  Any message
+                 which meets either metric  will  be  either  archived  or  removed,
+                 depending on what the _B_B_o_a_r_d_s (5) file says.
+
+            _F_i_l_e_s
+                 /usr/spool/bboards/BBoards          BBoards database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 msh(1), bboards(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(8)                        -18-                        BBOARDS(8)
+
+
+            _N_A_M_E
+                 bboards - BBoards channel/mailer
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/mmdf/chans/bboards fd1 fd2 [y]
+
+                 /usr/local/lib/mh/sbboards bboard ...
+
+                 /usr/local/lib/mh/sbboards file maildrop directory bboards.bboard
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 For _M_M_D_F, the BBoards channel delivers mail to the BBoards  system.
+                 For  _S_e_n_d_M_a_i_l and stand-alone _M_H, the SBBoards mailer performs this
+                 task.
+
+                 For each address given, these programs consult the _b_b_o_a_r_d_s (5) file
+                 to  ascertain  information  about  the BBoard named by the address.
+                 The programs then perform local delivery,  if  appropriate.   After
+                 that,  with the exception of _s_b_b_o_a_r_d_s running under stand-alone _M_H,
+                 the programs perform redistribution, if appropriate.
+
+                 For redistribution, the return address is set  to  be  the  request
+                 address at the local host, so bad addresses down the line return to
+                 the nearest point of  authority.   If  any  failures  occur  during
+                 redistribution,  a  mail  message  is  sent  to  the  local request
+                 address.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/spool/bboards/BBoards          BBoards database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 bboards(5), bbaka(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBTAR(8)                          -19-                          BBTAR(8)
+
+
+            _N_A_M_E
+                 bbtar - generate the names of archive files to be put to tape
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/spool/bboards/bbtar [private] [public]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _b_b_t_a_r program reads the BBoards database and  produces  on  its
+                 standard  output  the names of BBoards archives which should be put
+                 to tape, for direct use in a _t_a_r (1) command.
+
+                 If the argument `private' is given, only private BBoards  are  con-
+                 sidered.   If  the  argument `public' is given, only public BBoards
+                 are considered.  This lets  the  BBoards  administrator  write  two
+                 tapes,  one  for  general read-access (the public BBoards), and one
+                 for restricted access.  The default is all BBoards
+
+                 For example:
+
+                      cd archive              # change to the archive directory
+                      tar cv `bbtar private`  # save all private BBoard archives
+
+                 After the archives have  been  saved  to  tape,  they  are  usually
+                 removed.  The archives are then filled again, usually automatically
+                 by cron jobs which run _b_b_e_x_p (8).
+
+            _F_i_l_e_s
+                 /usr/spool/bboards/BBoards          BBoards database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 bboards(5), bbexp(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  _4. _P_O_P
+
+
+
+
+
+                      For POP (Post Office Protocol) client hosts, you need to  edit  the
+                 /usr/local/lib/mh/mtstailor  file to know about two hosts: the SMTP ser-
+                 vice host and the POP service  host.   Normally,  these  are  the  same.
+                 Change  the "localname" field of the mtstailor file of _M_H in the file to
+                 be the name of the POP service host.  This makes replies  to  mail  gen-
+                 erated  on  the POP client host possible, since _M_H will consider use the
+                 hostname of the POP service host as  the  local  hostname  for  outgoing
+                 mail.   Also  set  the value of "pophost" to this value.  This tells _i_n_c
+                 and _m_s_g_c_h_k to use POP instead of looking  for  mail  locally.   Finally,
+                 make  sure  the value of "servers" includes the name of the SMTP service
+                 host.  The recommended value for "servers" is:
+
+                      servers: SMTP-service-host localhost \01localnet
+
+                      If you want more information on the Post Office  Protocol  used  by
+                 _M_H,      consult      the      files     support/pop/rfc1081.txt     and
+                 support/pop/rfc1082.txt which describe the _M_H version of the POP: POP3.
+
+                      For POP service hosts, you need to run  a  daemon,  _p_o_p_d (8).   The
+                 daemon should start at multi-user boot time, so adding the lines:
+
+                      if [ -f /etc/popd ]; then
+                          /etc/popd & echo -n ' pop'                  >/dev/console
+                      fi
+
+                 to the /etc/rc.local file is sufficient.
+
+                      The port assigned to the POP3 protocol is  "110".   For  historical
+                 reasons,  many  sites are using port "109" which is the port assigned to
+                 the "POP" (version 1 and 2) protocol.  The configuration option "POPSER-
+                 VICE"  is  the  name of the port number that _M_H POP will try to use, and
+                 defaults to the name "pop".
+
+                      To generate _M_H to use newer assigned port number, in your _M_H config
+                 file, add:
+
+                      options POPSERVICE='"pop3"'
+
+                 And on both the POP client and service hosts, you  need  to  define  the
+                 port that the POP service uses.  Add the line:
+
+                      pop3            110/tcp
+
+                 to the /etc/services file (if it's not already there).
+
+
+
+                                                   -20-
+
+
+
+
+
+
+
+
+
+                                                   -21-
+
+
+                      There are two ways to administer POP: In "naive" mode, each user-id
+                 in  the  _p_a_s_s_w_d (5) file is considered a POP subscriber.  No changes are
+                 required for the mailsystem on the  POP  service  host.   However,  this
+                 method  requires  that each POP subscriber have an entry in the password
+                 file.  The POP server will fetch the user's mail from wherever maildrops
+                 are kept on the POP service host.  This means that if maildrops are kept
+                 in the user's home directory, then each POP subscriber must have a  home
+                 directory.
+
+                      In "smart" mode (enabled via "DPOP" being given as a  configuration
+                 option),  the  list  of  POP subscribers and the list of login users are
+                 completely separate name spaces.  A separate database (simple file simi-
+                 lar  to  the  _B_B_o_a_r_d_s (5) file) is used to record information about each
+                 POP subscriber.  Unfortunately, the local mailsystem must be changed  to
+                 reflect  this.   This  requires  two changes (both of which are simple):
+                 First, the aliasing  mechanism  is  augmented  so  that  POP  subscriber
+                 addresses are diverted to a special delivery mechanism.  _M_H comes with a
+                 program, _p_o_p_a_k_a (8), which generates the additional  information  to  be
+                 put  in the mailsystem's alias file.  Second, a special POP channel (for
+                 MMDF-II) or POP mailer (for SendMail) performs the actual delivery (_m_h._6
+                 supplies  both).   All  it really does is just place the mail in the POP
+                 spool area.
+
+                      These two different philosophies are not compatible on the same POP
+                 service  host:  one or the other, but not both may be run.  Clever mail-
+                 system people will note that the POP mechanism is really a special  case
+                 of the more general BBoards mechanism.
+
+                      In addition,  there  is  one  user-visible  difference,  which  the
+                 administrator  controls  the availability of.  The difference is whether
+                 the POP subscriber must supply a password to the POP server:  The  first
+                 method  uses  the  standard  ARPA  technique of sending a username and a
+                 password.  The appropriate programs (_i_n_c,  _m_s_g_c_h_k,  and  possibly  _b_b_c )
+                 will prompt the user for this information.
+
+                      The second method (which is enabled via "RPOP"  being  given  as  a
+                 configuration  option)  uses  the Berkeley UNIX reserved port method for
+                 authentication.  This requires that the two  or  three  mentioned  above
+                 programs  be  _s_e_t_u_i_d to root.  (There are no known holes in any of these
+                 programs.)
+
+                      To add a POP subscriber, for the first method, one  simply  follows
+                 the  usual procedures for adding a new user, which eventually results in
+                 adding a line to the _p_a_s_s_w_d (5) file; for the second  method,  one  must
+                 edit the POP database file (kept in the home directory of the POP user),
+                 and then run the _p_o_p_a_k_a program.  The output of this program  is  placed
+                 in the aliases file for the transport system (e.g., /usr/lib/aliases for
+                 SendMail).
+
+                      Authentication for POP subscribers differs  depending  on  the  two
+                 methods.   When  the user supplies a password for the POP session: under
+                 the first method, the contents of the  password  field  for  the  user's
+
+
+
+
+
+
+
+
+
+
+
+                                                   -22-
+
+
+                 entry  in the _p_a_s_s_w_d (5) is consulted; under the second method, the con-
+                 tents of the password field for the subscriber's entry  in  the  _p_o_p (5)
+                 file is consulted.  (To set this field, the _p_o_p_w_r_d (8) program is used.)
+
+                      If you are allowing  RPOP,  under  the  first  method,  the  user's
+                 ._r_h_o_s_t_s  file is consulted; under the second method, the contents of the
+                 network address field for the subscriber's entry in the _p_o_p (5) file  is
+                 consulted.
+
+                      In addition, a third authentication scheme is available.  When  the
+                 APOP configuration option is given, e.g.,
+
+                      options APOP='"/etc/pop.auth"'
+
+                 In this case, the server also allows a client to  supply  authentication
+                 credentials  to  provide for origin authentication and reply protection,
+                 but which do not involve sending a password in the clear over  the  net-
+                 work.  A POP authorization DB, having as its name the value of APOP con-
+                 figuration option, is used to keep track of this information.  This file
+                 is  created  and  manipulated  by the _p_o_p_a_u_t_h (8) program.  Because this
+                 file contains secret information, it must be  protected  mode  0600  and
+                 owned  by  the  super-user.  Hence, your first step after installing the
+                 software is to issue
+
+                      # popauth -init
+
+            which creates and initalizes the POP authorization DB.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            POP(5)                            -23-                            POP(5)
+
+
+            _N_A_M_E
+                 POP - POP database of subscribers
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/spool/pop/POP
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The POP database has exactly the same  format  as  the  _B_B_o_a_r_d_s (5)
+                 database,  although  many  fields are unused.  Currently, only four
+                 fields are examined:
+
+                 _f_i_e_l_d               _v_a_l_u_e
+                 name                the POP subscriber
+                 primary file        the maildrop for the POP subscriber
+                                     (relative to the POP directory)
+                 encrypted password  the POP subscriber's password
+                 network address     the remote user allowed to RPOP
+
+                 This is an ASCII file.  Each field  within  each  POP  subscriber's
+                 entry  is  separated from the next by a colon.  Each POP subscriber
+                 is separated from the next by a new-line.  If the password field is
+                 null, then no password is valid.
+
+                 To add a new POP subscriber, edit the file adding a line such as
+
+                      mrose::mrose:::::::0
+
+                 Then, use _p_o_p_w_r_d to set the password for the  POP  subscriber.   If
+                 you wish to allow POP subscribers to access their maildrops without
+                 supplying a password (by using privileged ports), fill-in the  net-
+                 work address field, as in:
+
+                      mrose::mrose:::mrose@nrtc-isc::::0
+
+                 which permits "mrose@nrtc-isc" to access the maildrop for  the  POP
+                 subscriber "mrose".  Multiple network addresses may be specified by
+                 separating them with commas, as in:
+
+                      dave::dave:9X5/m4yWHvhCc::dave@romano.wisc.edu,dave@rsch.wisc.edu::::
+
+                 To  disable  a  POP subscriber from _r_e_c_e_i_v_i_n_g mail, set the primary
+                 file name to the empty string.  To prevent a  POP  subscriber  from
+                 _p_i_c_k_i_n_g-_u_p mail, set the encrypted password to "*" and set the net-
+                 work address to the empty string.
+
+                 This file resides in home directory of the login "pop".  Because of
+                 the  encrypted passwords, it can and does have general read permis-
+                 sion.
+
+            _F_i_l_e_s
+                 /usr/spool/pop/POP                  POP database
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POP(5)                            -24-                            POP(5)
+
+
+            _S_e_e _A_l_s_o
+                 bboards(5), pop(8), popaka(8), popd(8), popwrd(8)
+
+
+            _B_u_g_s
+                 A binary indexed file format should be available for fast access.
+
+                 Appropriate precautions must be taken  to  lock  the  file  against
+                 changes  if it is to be edited with a text editor.  A _v_i_p_o_p program
+                 is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POP(8)                            -25-                            POP(8)
+
+
+            _N_A_M_E
+                 pop - POP channel/mailer
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/mmdf/chans/pop fd1 fd2 [y]
+
+                 /usr/local/lib/mh/spop POP-subscriber ...
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 For _M_M_D_F-_I_I, the POP channel delivers mail to the  POP  spool  area
+                 for  later  retrieval  by  POP subscribers.  For _S_e_n_d_M_a_i_l, the SPOP
+                 mailer performs this task.
+
+                 For each address given, these programs consult the _p_o_p (5) file  to
+                 obtain  information  about the POP-subscriber named by the address.
+                 The programs then deliver the message to the  spool  area  for  the
+                 POP-subscriber.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/spool/pop/POP                  POP database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 bboards(5), bbaka(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POPAKA(8)                         -26-                         POPAKA(8)
+
+
+            _N_A_M_E
+                 popaka - generate POP entries for SendMail or MMDF-II alias file
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/popaka
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _p_o_p_a_k_a program reads the POP database and produces on its stan-
+                 dard  output  a  file  suitable  for  inclusion  in the SendMail or
+                 _M_M_D_F-_I_I aliases file.  The contents of this file  divert  mail  for
+                 POP subscribers to the POP channel.
+
+            _F_i_l_e_s
+                 /usr/spool/pop/POP                  POP database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 pop(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POPAUTH(8)                        -27-                        POPAUTH(8)
+
+
+            _N_A_M_E
+                 popauth - manipulate POP authorization DB
+
+            _S_Y_N_O_P_S_I_S
+                 popauth [-init] [-list] [-user name] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _p_o_p_a_u_t_h program allows a POP-subscriber to  change  the  secret
+                 value  used to generate their authentication credentials.  In addi-
+                 tion, the super-user or master POP user may  use  this  program  to
+                 either  initialize the database or to print public information from
+                 it.  _p_o_p_a_u_t_h is useful only when the APOP configuration  option  is
+                 defined.   (This  configuration  option defines the name of the POP
+                 authorization DB.)
+
+                 Under normal usage, _p_o_p_a_u_t_h prompts for a new secret, just like the
+                 _p_a_s_s_w_d  program.   It then updates the POP authorization DB accord-
+                 ingly.
+
+                 With the `-init' switch, the super-user  or  master  POP  user  can
+                 create a new (or zero the existing) POP authorization DB.
+
+                 With the `-list' switch, the super-user  or  master  POP  user  can
+                 print  out  public  information  about the named subscriber (or all
+                 subscribers).
+
+            _F_i_l_e_s
+                 /etc/pop.auth.*                     POP authorization DB
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 popd(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POPD(8)                           -28-                           POPD(8)
+
+
+            _N_A_M_E
+                 popd - the POP server
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/etc/popd [-p portno] (under /etc/rc.local)
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _p_o_p_d server implements the Post Office Protocol (version 3), as
+                 described in RFC1081 and RFC1082.  Basically, the server listens on
+                 the TCP port named "pop" for connections and enters  the  POP  upon
+                 establishing  a  connection.  The `-p' option overrides the default
+                 TCP port.  If the POP2 configuration option is  defined,  then  the
+                 server also implements version 2 of the protocol.  If the APOP con-
+                 figuration option is defined,  then  the  server  supports  a  non-
+                 standard  mechanism for identity-establishment in which authentica-
+                 tion credentials are used to provide for origin authentication  and
+                 reply  protection,  but  which do not involve sending a password in
+                 the clear over the network.  See _p_o_p_a_u_t_h(8) for more details.
+
+            _F_i_l_e_s
+                 /usr/spool/pop/POP                  POP database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+                 _P_o_s_t _O_f_f_i_c_e  _P_r_o_t_o_c_o_l  -  _v_e_r_s_i_o_n  _3:  _E_x_t_e_n_d_e_d  _s_e_r_v_i_c_e  _o_f_f_e_r_i_n_g_s
+                 (RFC-1082),
+                 pop(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POPD(8)                           -29-                           POPD(8)
+
+
+            _H_i_s_t_o_r_y
+                 For historical reasons, the _M_H POP defaults to using the port named
+                 "pop"  (109) instead of its newly assigned port named "pop3" (110).
+                 See the POPSERVICE configuration option for more details.
+
+                 Previous versions of the server (10/28/84) had the restriction that
+                 the  POP  client  may retrieve messages for login users only.  This
+                 restriction has been lifted, and  true  POB  support  is  available
+                 (sending  mail  to a mailbox on the POP service host which does not
+                 map to a user-id in the password file).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POPWRD(8)                         -30-                         POPWRD(8)
+
+
+            _N_A_M_E
+                 popwrd - set password for a POP subscriber
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/popwrd POP-subscriber
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _p_o_p_w_r_d program lets the super-user or the master POP user or  a
+                 "leader"  of a POP subscriber change the password field for the POP
+                 subscriber in the POP database.  This program is  very  similar  to
+                 the _p_a_s_s_w_d (1) program.
+
+                 Since only the super-user and the master POP user  may  change  any
+                 other  fields of the POP database (using an ordinary editor), it is
+                 possible for the system administrator to delegate responsibility to
+                 others to manage groups of POP subscribers.
+
+            _F_i_l_e_s
+                 /usr/spool/pop/POP                  POP database
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 pop(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 Although _p_o_p_w_r_d does locking against other invocations  of  _p_o_p_w_r_d,
+                 editor  locking for the POP database in general is not implemented.
+                 A _v_i_p_o_p program is needed.
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                            _5. _M_A_I_L _F_I_L_T_E_R_I_N_G
+
+
+
+
+
+                      There was a time when users on a UNIX host might have had two mail-
+                 drops:  one  from  _M_M_D_F  and the other from _U_U_C_P.  This was really a bad
+                 problem since it prevented using a single user-interface on all of  your
+                 mail.  Furthermore, if you wanted to send a message to addresses on dif-
+                 ferent mailsystems, you couldn't send just one message.   To  solve  all
+                 these  problems, the notion of _m_a_i_l _f_i_l_t_e_r_i_n_g was developed that allowed
+                 sophisticated munging and relaying between the two pseudo-domains.
+
+                      _M_H will perform mail filtering, transparently, if given the MF con-
+                 figuration  option.   However,  with  the advent of _S_e_n_d_M_a_i_l and further
+                 maturation of _M_M_D_F, _M_H doesn't really need to  do  this  anymore,  since
+                 these message transport agents handle it.
+
+                      The mail-filtering stuff is too complicated.  It should be simpler,
+            but, protocol translation really _i_s difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                              -31-
+
+
+
+
+
+
+
+
+
+            MF(1)                             -32-                             MF(1)
+
+
+            _N_A_M_E
+                 muinc, musift, uminc, umsift - mail filters
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/muinc
+
+                 /usr/local/lib/mh/musift [files ...]
+
+                 /usr/local/lib/mh/uminc
+
+                 /usr/local/lib/mh/umsift [files ...]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The mail filters are a set of programs that filter  mail  from  one
+                 format  to another.  In particular, _U_U_C_P- and _M_M_D_F-style mail files
+                 are handled.
+
+                 _m_u_i_n_c filters mail from the user's _M_M_D_F maildrop  into  the  user's
+                 _U_U_C_P  maildrop;  similarly, _u_m_i_n_c filters mail from the user's _U_U_C_P
+                 maildrop into the user's _M_M_D_F maildrop.  These two programs respect
+                 each system's maildrop locking protocols.
+
+                 _m_u_s_i_f_t filters each file on the command line (or the standard input
+                 if  no  arguments are given), and places the result on the standard
+                 output in _U_U_C_P format.  The files (or standard input) are  expected
+                 to  be  in  _M_M_D_F format.  _u_m_s_i_f_t does the same thing filtering _U_U_C_P
+                 formatted files (or input), and places the _M_M_D_F formatted result on
+                 the  standard  output.  No locking protocols are used by these pro-
+                 grams.
+
+                 If the files aren't in the expected format, the mail  filters  will
+                 try to recover.  In really bad cases, you may lose big.
+
+            _F_i_l_e_s
+                 /usr/spool/mail/                    UUCP spool area for maildrops
+                 /usr/spool/mail/$USER               Location of standard maildrop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _H_e_a_d_e_r _M_u_n_g_i_n_g (aka RFC-886),
+                 inc(1)
+
+
+            _D_e_f_a_u_l_t_s
+
+
+            _C_o_n_t_e_x_t
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MF(1)                             -33-                             MF(1)
+
+
+            _B_u_g_s
+                 Numerous; protocol translation is very difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMAIL(8)                          -34-                          RMAIL(8)
+
+
+            _N_A_M_E
+                 rmail - UUCP interface to mail
+
+            _S_Y_N_O_P_S_I_S
+                 rmail address ...
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_m_a_i_l is intended as a replacement for those systems without  _S_e_n_d_-
+                 _M_a_i_l  or  _M_M_D_F.   It  is  normally  invoked by _u_u_x on behalf of the
+                 remote _U_U_C_P site.  For each address, it decides where to  send  it:
+                 either locally, via another _U_U_C_P link, or via the Internet.
+
+                 _R_m_a_i_l implements a crude access control facility by consulting  the
+                 files  Rmail.OkHosts  and  Rmail.OkDests  in the /usr/local/lib/mh/
+                 directory.  Hosts listed in the former file can  send  messages  to
+                 anywhere  they please.  Hosts listed in the latter file can receive
+                 messages from anywhere.  Note that a host listed in the first  file
+                 is implicitly listed in the second file.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/local/lib/mh/Rmail.OkHosts     list of privileged hosts
+                 /usr/local/lib/mh/Rmail.OkDests     list of privileged destinations
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 mf(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                              _6. _M_H _H_A_C_K_I_N_G
+
+
+
+
+
+                      Finally, here's a little information on modifying the  _M_H  sources.
+                 A word of advice however:
+
+
+                                                  _D_O_N'_T
+
+
+
+                 If you really want new _M_H capabilities, write a  shell  script  instead.
+                 After all, that's what UNIX is all about, isn't it?
+
+                      Here's the organization of the _M_H source tree.
+
+                      conf/        configurator tree
+                      config/      compiled configuration constants
+                      dist/        distributor
+                      doc/         manual entries
+                      h/           include files
+                      miscellany/  various sundries
+                      mts/         MTS-specific areas
+                                   mh/        standalone delivery
+                                   mmdf/      MMDF-I, MMDF-II
+                                   sendmail/  SendMail, SMTP
+                      papers/      papers about _M_H
+                      sbr/         subroutines
+                      support/     support programs and files
+                                   bboards/   UCI BBoards facility
+                                   general/   templates
+                                   pop/       POP facility
+                      tma/         Trusted Mail Agent (not present in all distributions)
+                      uip/         programs
+                      zotnet/      MTS-independent areas
+                                   bboards/   UCI BBoards facility
+                                   mf/        Mail Filtering
+                                   mts/       MTS constants
+                                   tws/       date routines
+
+
+
+
+
+
+
+
+
+
+
+                                              -35-
+
+
+
+
+
+
+
+
+
+            MH-HACK(8)                        -36-                        MH-HACK(8)
+
+
+            _N_A_M_E
+                 mh-hack - how to hack MH
+
+            _S_Y_N_O_P_S_I_S
+                 big hack attack
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 This is a description of how one can modify the _M_H system.  The  _M_H
+                 distribution has a lot of complex inter-relations, so before you go
+                 modifying any code, you should read this  and  understand  what  is
+                 going on.
+
+                 ADDING A NEW PROGRAM
+                      Suppose you want to create a new _M_H command  called  "pickle".
+                      First, create and edit "pickle.c" in the uip/ directory.  Next
+                      edit conf/makefiles/uip to include "pickle".   This  file  has
+                      directions  at  the  end  of it which explain how it should be
+                      modified.  Next, update any documentation  (described  below).
+                      At  this  point  you  can  re-configure _M_H.  See _m_h-_g_e_n(_8) for
+                      instructions on how to do this (basically, you want  "mhconfig
+                      MH").
+
+                 ADDING A NEW SUBROUTINE
+                      Suppose you want to create a new _M_H routine  called  "pickle".
+                      First, create and edit "pickle.c" in the sbr/ directory.  Next
+                      edit conf/makefiles/sbr to include "pickle".   This  file  has
+                      directions  at  the  end  of it which explain how it should be
+                      modified.  You should modify  config/mh.h  to  define  "pickle
+                      ();".   Similarly,  sbr/llib-lsbr should be modified for _l_i_n_t.
+                      At this point you can re-configure _M_H.
+
+                 UPDATING DOCUMENTATION
+                      Edit whatever files you want in conf/doc/.  When documenting a
+                      new program, such as "pickle", you should create a manual page
+                      with the name "pickle.rf".  The file conf/doc/template  has  a
+                      manual page template that you can use.  If you are documenting
+                      a new program, then you should also update three other  files:
+                      The  file  conf/doc/mh.rf  should  be  modified to include the
+                      ".NA" section from "pickle.rf".  The file conf/doc/mh-chart.rf
+                      should   be   modified  to  include  the  ".SY"  section  from
+                      "pickle.rf".  Finally, the file conf/doc/MH.rf should be modi-
+                      fied  to  include a ".so pickle.me".  Naturally, none of these
+                      changes will be reflected in the configuration until you actu-
+                      ally run _m_h_c_o_n_f_i_g.
+
+            _F_i_l_e_s
+                 Too numerous to mention.  Honest.
+
+
+            _S_e_e _A_l_s_o
+                 mh-gen(8)
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-HACK(8)                        -37-                        MH-HACK(8)
+
+
+            _B_u_g_s
+                 Hacking is an art, but most programmers are butchers, not artists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                            _7. _H_I_D_D_E_N _F_E_A_T_U_R_E_S
+
+
+
+
+
+                      The capabilities discussed here should not be used on a  production
+                 basis,  as they are either experimental, are useful for debugging _M_H, or
+                 are otherwise not recommended.
+
+
+
+                 _D_e_b_u_g _F_a_c_i_l_i_t_i_e_s
+
+                      The _m_a_r_k command has a `-debug' switch which essentially prints out
+                 all the internal _M_H data structures for the folder you're looking at.
+
+                      The _p_o_s_t command has a `-debug' switch which  does  everything  but
+                 actually  post  the  message  for you.  Instead of posting the draft, it
+                 sends it to the standard output.  Similarly, _s_e_n_d has a `-debug'  switch
+                 which gets passed to _p_o_s_t.
+
+                      Some _M_H commands look at envariables to determine debug-mode opera-
+                 tion of certain new facilities.  The current list of envariables is:
+
+                      MHFDEBUG     OVERHEAD facility
+                      MHLDEBUG     mhl
+                      MHPDEBUG     pick
+                      MHPOPDEBUG   POP transactions
+                      MHVDEBUG     window management transactions
+                      MHWDEBUG     alternate-mailboxes
+
+
+
+                 _F_o_r_w_a_r_d_i_n_g _M_a_i_l
+
+                      The _f_o_r_w and _m_h_l commands have  two  switches,  `-dashmunging'  and
+                 `-nodashmunging'  which enable or disable the prepending of `- ' in for-
+                 warded messages.  To use `-nodashmunging', you must use  an  _m_h_l  filter
+                 file.
+
+
+
+                 _S_e_n_d
+
+                      The _s_e_n_d command has two switches, `-unique' and `-nounique', which
+                 are  useful  to certain individuals who, for obscure reasons, do not use
+                 draft-folders.
+
+                      "Distribution Carbon Copy" addresses may be specified in  the  _D_c_c:
+                 header.  This header is removed before posting the message,and a copy of
+                 the message is distributed  to  each  listed  address.   This  could  be
+
+                                                   -38-
+
+
+
+
+
+
+
+
+
+                                                   -39-
+
+
+                 considered a form of Blind Carbon Copy which is best used for sending to
+                 an address which would never reply (such as an auto-archiver).
+
+
+
+                 _P_o_s_t_i_n_g _M_a_i_l
+
+                      If you're running a version of _M_H which talks directly to  an  _S_M_T_P
+                 server  (or  perhaps an advanced _M_M_D_F submit process), there are lots of
+                 interesting switches for your amusement which _s_e_n_d and _p_o_s_t understand:
+                      -mail         Use the _M_A_I_L command (default)
+                      -saml         Use the _S_A_M_L command
+                      -send         Use the _S_E_N_D command
+                      -soml         Use the _S_O_M_L command
+                      -snoop        Watch the _S_M_T_P transaction
+                      -client host  Claim to be "host" when posting mail
+                      -server host  Post mail with "host"
+
+                      The last switch is to be useful when _M_H resides on  small  worksta-
+                 tions  (or  PC:s) in a network--they can post their outgoing mail with a
+                 local relay, and reduce the load on the local  system.   On  POP  client
+                 hosts,  the  `-server host'  switch is defaulted appropriately using the
+                 SMTP search-list mechanism.  The _w_h_o_m command understands the last three
+                 switches.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         _8. _C_O_N_F_I_G_U_R_A_T_I_O_N _O_P_T_I_O_N_S
+
+
+
+
+
+                      This manual was generated with the following configuration  options
+                 in effect:
+
+
+                 ________________________________________________________________________
+
+                             Generation Date             November 30, 1993
+                             Primary Directory           /usr/local/
+                             Secondary Directory         /usr/local/lib/mh/
+                             Maildrop Location           /usr/spool/mail/$USER
+                             Transport System            SendMail
+                 ________________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -40-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _C_O_N_T_E_N_T_S
+
+
+
+
+                 Section
+
+                    1.  INTRODUCTION ...............................................    1
+                      Scope of this document .......................................    1
+                      Summary ......................................................    1
+
+                    2.  THE MTS INTERFACE ..........................................    3
+                         MH-TAILOR .................................................    4
+                         MH-MTS ....................................................   10
+
+                    3.  BBOARDS ....................................................   12
+                      BBoard Delivery ..............................................   12
+                      BBoards with the POP .........................................   13
+                      BBoards with the NNTP ........................................   14
+                         BBOARDS ...................................................   15
+                         BBAKA .....................................................   16
+                         BBEXP .....................................................   17
+                         BBOARDS ...................................................   18
+                         BBTAR .....................................................   19
+
+                    4.  POP ........................................................   20
+                         POP .......................................................   23
+                         POP .......................................................   25
+                         POPAKA ....................................................   26
+                         POPAUTH ...................................................   27
+                         POPD ......................................................   28
+                         POPWRD ....................................................   30
+
+                    5.  MAIL FILTERING .............................................   31
+                         MF ........................................................   32
+                         RMAIL .....................................................   34
+
+                    6.  MH HACKING .................................................   35
+                         MH-HACK ...................................................   36
+
+                    7.  HIDDEN FEATURES ............................................   38
+                      Debug Facilities .............................................   38
+                      Forwarding Mail ..............................................   38
+                      Send .........................................................   38
+                      Posting Mail .................................................   39
+
+                    8.  CONFIGURATION OPTIONS ......................................   40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         THE RAND MH
+
+
+                                      MESSAGE HANDLING
+
+
+                                           SYSTEM:
+
+
+                                    ADMINISTRATOR'S GUIDE
+
+
+
+
+
+
+                                         UCI Version
+
+
+
+
+
+                                      Marshall T. Rose
+
+
+
+
+                                       _F_i_r_s_t _E_d_i_t_i_o_n:
+
+                                         _M_H _C_l_a_s_s_i_c
+
+                      (_N_o_t _t_o _b_e _c_o_n_f_u_s_e_d _w_i_t_h _a _w_e_l_l-_k_n_o_w_n _s_o_f_t _d_r_i_n_k)
+
+
+
+
+
+
+
+                                      November 30, 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                        6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/MH-19910201.txt b/docs/historical/MH-19910201.txt
new file mode 100644
index 0000000..28701cb
--- /dev/null
+++ b/docs/historical/MH-19910201.txt
@@ -0,0 +1,11145 @@
+
+
+
+
+
+
+
+
+                                  _d_i_s_c_a_r_d _t_h_i_s _p_a_g_e
+
+
+
+
+                                     The RAND _M_H
+                               Message Handling System:
+                                    User's Manual
+
+                                     UCI Version
+
+
+                                   February 1, 1991
+                                    6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+99
+
+
+
+
+
+
+
+
+
+
+
+
+                                   _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+9
+            Although people can travel cross-country in  hours  and  can  reach
+       others by telephone in seconds, communications still depend heavily upon
+       paper, most of which is distributed through the mails.
+
+            There are several major reasons for this  continued  dependence  on
+       written  documents.   First,  a  written  document  may be proofread and
+       corrected prior to its distribution, giving the author complete  control
+       over  his  words.   Thus,  a written document is better than a telephone
+       conversation in this respect.  Second, a carefully written  document  is
+       far  less  likely to be misinterpreted or poorly translated than a phone
+       conversation.  Third, a  signature  offers  reasonable  verification  of
+       authorship, which cannot be provided with media such as telegrams.
+
+            However, the need for fast____,  accurate,  and  reproducible  document
+       distribution is obvious.  One solution in widespread use is the telefax.
+       Another that is rapidly gaining popularity is  electronic  mail.   Elec-
+       tronic  mail is similar to telefax in that the data to be sent are digi-
+       tized, transmitted via phone lines, and turned back into a  document  at
+       the  receiver.   The  advantage of electronic mail is in its compression
+       factor.  Whereas a telefax must scan a page in very fine lines and  send
+       all  of the black and white information, electronic mail assigns charac-
+       ters fixed codes which can be transmitted as a few bits of  information.
+       Telefax  presently  has the advantage of being able to transmit an arbi-
+       trary page, including pictures, but electronic mail is beginning to deal
+       with  this  problem.   Electronic mail also integrates well with current
+       directions  in  office  automation,  allowing  documents  prepared  with
+       sophisticated  equipment  at  one  site  to  be  quickly transferred and
+       printed at another site.
+
+            Currently, most electronic mail is intraorganizational,  with  mail
+       transfer  remaining within one computer.  As computer networking becomes
+       more common, however, it is becoming more feasible to  communicate  with
+       anyone whose computer can be linked to your own via a network.
+
+            The pioneering efforts on general-purpose electronic mail  were  by
+       organizations using the DoD ARPAnet[1].  The capability to send messages
+       between computers existed before the ARPAnet was developed, but  it  was
+       used  only in limited ways.  With the advent of the ARPAnet, tools began
+       to be developed which made it convenient for  individuals  or  organiza-
+       tions  to distribute messages over broad geographic areas, using diverse
+       computer facilities.  The interest and activity in message  systems  has
+       now  reached  such proportions that steps have been taken within the DoD
+       to coordinate and unify the development  of  military  message  systems.
+       The  use  of electronic mail is expected to increase dramatically in the
+       next few years.  The utility of such systems in the command and  control
+       and  intelligence environments is clear, and applications in these areas
+
+9
+
+
+
+
+
+
+
+
+
+                                         -2-
+
+
+       will probably lead the way.  As the costs for sending and handling elec-
+       tronic messages continue their rapid decrease, such uses can be expected
+       to spread rapidly into other areas and, of course, will not  be  limited
+       to the DoD.
+
+            A message system provides tools that  help  users  (individuals  or
+       organizations)  deal  with  messages  in various ways.  Messages must be
+       composed, sent, received, stored, retrieved, forwarded, and replied  to.
+       Today's  best  interactive  computer  systems provide a variety of word-
+       processing and information handling capabilities.  The message  handling
+       facilities  should be well integrated with the rest of the system, so as
+       to be a graceful extension of overall system capability.
+
+            The message system described in this report, _M_H, provides  most  of
+       the  features that can be found in other message systems and also incor-
+       porates some new ones.  It has been built on the UNIX time-sharing  sys-
+       tem[2],  a  popular  operating  system  for the DEC PDP-11[1] and VAX-11
+       classes of computers.  A "secure" operating system similar  to  UNIX  is
+       currently being developed[3], and that system will also run _M_H.
+
+            This report provides a complete description  of  _M_H  and  thus  may
+       serve  as  a  user's  manual,  although  parts  of the report will be of
+       interest to non-users as well.  Sections  2  and  3,  the  Overview  and
+       Tutorial,  present  the key ideas of _M_H and will give those not familiar
+       with message systems an idea of what such systems are like.
+
+            _M_H consists of a set of commands which use some special  files  and
+       conventions.   The final section is divided into three parts.  The first
+       part covers the information a user needs to know in addition to the com-
+       mands.   Then, each of the _M_H commands is described in detail.  Finally,
+       other obscure details are revealed.  A summary of the commands is  given
+       in  Appendix A, and the syntax of message sequences is given in Appendix
+       B.
+
+            A novel approach has been taken in the design of  _M_H.   Instead  of
+       creating  a large subsystem that appears as a single command to the user
+       (such as MS[4]), _M_H is a collection of separate commands which  are  run
+       as  separate  programs.   The file and directory system of UNIX are used
+       directly.  Messages are stored as individual files (datasets), and  col-
+       lections  of them are grouped into directories.  In contrast, most other
+       message systems store messages in a complicated data structure within  a
+       monolithic file.  With the _M_H approach, UNIX commands can be interleaved
+       with commands invoking the  functions  of  the  message  handler.   Con-
+       versely, existing UNIX commands can be used in connection with messages.
+       For example, all the usual UNIX editing, text-formatting,  and  printing
+       facilities  can  be applied directly to individual messages.  MH, there-
+       fore, consists of a relatively  small  amount  of  new  code;  it  makes
+
+
+9          [1] PDP and VAX are trademarks of Digital Equipment Corporation.
+
+
+9
+
+
+
+
+
+
+
+
+
+                                         -3-
+
+
+       extensive use of other UNIX software to provide the  capabilities  found
+       in other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                     _2. _O_V_E_R_V_I_E_W
+
+
+
+9
+            There are three main aspects  of  _M_H :   the   way   messages   are
+       stored  (the  message  database),  the user's profile (which directs how
+       certain actions of the message handler take place), and the commands for
+       dealing with messages.
+
+            Under _M_H, each message is stored as a separate file.   A  user  can
+       take  any  action  with a message that he could with an ordinary file in
+       UNIX.  A UNIX directory in which messages are stored is called a folder.
+       Each  folder  contains  some  standard  entries  to support the message-
+       handling functions.  The messages in  a  folder  have  numerical  names.
+       These  folders (directories) are entries in a particular directory path,
+       described in the user profile, through which _M_H can find  message  fold-
+       ers.   Using  the UNIX "link" facility, it is possible for one copy of a
+       message to be "filed" in more than one folder, providing a message index
+       facility.   Also, using the UNIX tree-structured file system, it is pos-
+       sible to have a folder within a folder,  nested  arbitrarily  deep,  and
+       have the full power of the _M_H commands available.
+
+            Each user of _M_H has a user profile, a file in  his  $HOME  (initial
+       login)  directory  called  ._m_h__p_r_o_f_i_l_e.   This  profile contains several
+       pieces of information used by the _M_H commands: a path name to the direc-
+       tory  that  contains  the  message folders and parameters that tailor _M_H
+       commands to the individual user's requirements.  There is  also  another
+       file,  called  the  user  context, which contains information concerning
+       which folder the user last referenced (the "current" folder).   It  also
+       contains most of the necessary state information concerning how the user
+       is dealing with his messages, enabling _M_H to be implemented as a set  of
+       individual  UNIX commands, in contrast to the usual approach of a monol-
+       ithic subsystem.
+
+            In _M_H, incoming mail is appended to the end of a file in  a  system
+       spooling  area  for  the user.  This area is called the mail drop direc-
+       tory, and the file is called the user's mail drop.   Normally  when  the
+       user  logins  in, s/he is informed of new mail (or the _M_H program _m_s_g_c_h_k
+       may be run).  The user adds the new messages to his/her collection of _M_H
+       messages  by  invoking  the  command _i_n_c.  The _i_n_c (incorporate) command
+       adds the new messages to a folder called "inbox", assigning  them  names
+       which  are  consecutive  integers starting with the next highest integer
+       available in inbox.  _i_n_c also produces a _s_c_a_n summary  of  the  messages
+       thus  incorporated.   A  folder can be compacted into a single file, for
+       easy storage, by using the  _p_a_c_k_f  command.   Also,  messages  within  a
+       folder can be sorted by date and time with the _s_o_r_t_m command.
+
+
+            There are four commands for examining the  messages  in  a  folder:
+       _s_h_o_w,  _p_r_e_v,  _n_e_x_t,  and _s_c_a_n.  The _s_h_o_w command displays a message in a
+
+9                                         -4-
+
+
+
+
+
+
+
+
+
+                                         -5-
+
+
+       folder, _p_r_e_v displays the message preceding  the  current  message,  and
+       _n_e_x_t  displays  the  message following the current message.  _M_H lets the
+       user choose the program that displays individual  messages.   A  special
+       program,  _m_h_l,  can  be used to display messages according to the user's
+       preferences.  The _s_c_a_n command summarizes the messages in a folder, nor-
+       mally  producing  one line per message, showing who the message is from,
+       the date, the subject, etc.
+
+            The user may move a message from one folder  to  another  with  the
+       command  _r_e_f_i_l_e.   Messages may be removed from a folder by means of the
+       command _r_m_m.  In addition, a user may query what the current  folder  is
+       and may specify that a new folder become the current folder, through the
+       command _f_o_l_d_e_r.  All folders may be summarized with the _f_o_l_d_e_r_s command.
+       A  message  folder (or subfolder) may be removed by means of the command
+       _r_m_f.
+
+            A set of messages based on content may be selected by  use  of  the
+       command  _p_i_c_k.   This  command searches through messages in a folder and
+       selects those that match a given set of criteria.   These  messages  are
+       then  bound  to  a  "sequence" name for use with other _M_H commands.  The
+       _m_a_r_k command manipulates these sequences.
+
+            There are five commands enabling the user to  create  new  messages
+       and  send them: _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l, and _s_e_n_d.  The _c_o_m_p command pro-
+       vides the facility for the user to compose a new message; _d_i_s_t redistri-
+       butes  mail  to  additional addressees; _f_o_r_w enables the user to forward
+       messages; and _r_e_p_l facilitates the generation of a reply to an  incoming
+       message.   The  last three commands may optionally annotate the original
+       message.  Messages may be arbitrarily annotated with the  _a_n_n_o  command.
+       Once  a  draft has been constructed by one of the four above composition
+       programs, a user-specifiable program is run to query the user as to  the
+       disposition of the draft prior to sending.  _M_H provides the simple _w_h_a_t_-
+       _n_o_w program to start users off.  If a message is not  sent  directly  by
+       one  of these commands, it may be sent at a later time using the command
+       _s_e_n_d.  _M_H allows the use of any UNIX editor when  composing  a  message.
+       For rapid entry, a special editor, _p_r_o_m_p_t_e_r, is provided.  For programs,
+       a special mail-sending program, _m_h_m_a_i_l, is provided.
+
+            _M_H supports a personal aliasing  facility  which  gives  users  the
+       capability  to  considerably  shorten  address typein and use meaningful
+       names for addresses.  The _a_l_i program can be used to query _M_H as to  the
+       expansion of a list of aliases.  After composing a message, but prior to
+       sending, the _w_h_o_m command can be used to determine exactly who a message
+       would go to.
+
+            _M_H provides a natural interface for telling the  user's  shell  the
+       names  of  _M_H  messages  and  folders.  The _m_h_p_a_t_h program achieves this
+       capability.
+
+            Finally, _M_H supports the UCI BBoards facility.  _b_b_c can be used  to
+       query  the  status  of a group of BBoards, while _m_s_h can be used to read
+       them.  The _b_u_r_s_t command can be used to "shred" digests of messages into
+
+
+
+
+
+
+
+
+
+
+
+                                         -6-
+
+
+       individual messages.
+
+            All of the elements summarized above are described in  more  detail
+       in  the  following sections.  Many of the normal facilities of UNIX pro-
+       vide additional capabilities for dealing with messages in various  ways.
+       For  example,  it  is  possible  to  print  messages on the line-printer
+       without requiring any additional code within _M_H .  Using  standard  UNIX
+       facilities, any terminal output can be redirected to a file for repeated
+       or future viewing.  In general, the flexibility and capabilities of  the
+       UNIX  interface  with the user are preserved as a result of the integra-
+       tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                     _3. _T_U_T_O_R_I_A_L
+
+
+
+9
+            This tutorial provides a brief introduction to the _M_H commands.  It
+       should  be sufficient to allow the user to read his mail, do some simple
+       manipulations of it, and create and send messages.
+
+            A message has two major pieces:  the header and the body.  The body
+       consists  of the text of the message (whatever you care to type in).  It
+       follows the header and is separated from it by an empty line.  (When you
+       compose  a  message, the form that appears on your terminal shows a line
+       of dashes after the header.  This is for convenience and is replaced  by
+       an  empty  line  when  the  message is sent.)  The header is composed of
+       several components, including the subject of the message and the  person
+       to whom it is addressed.  Each component starts with a name and a colon;
+       components must not start with a blank.  The text of the  component  may
+       take  more  than  one line, but each continuation line must start with a
+       blank.  Messages typically have "To:", "cc:", and "Subject:" components.
+       When  composing  a  message, you should include the "To:" and "Subject:"
+       components; the "cc:" (for people you want to send  copies  to)  is  not
+       necessary.
+
+            The basic _M_H commands are _i_n_c, _s_c_a_n, _s_h_o_w, _n_e_x_t, _p_r_e_v,  _r_m_m,  _c_o_m_p,
+       and _r_e_p_l.  These are described below.
+
+       _i_n_c
+
+            When you get the message "You have mail",  type  the  command  _i_n_c.
+       You will get a "scan listing" such as:
+
+            7+   7/13  Cas      revival of measurement work
+            8   10/ 9  Norm     NBS people and publications
+            9   11/26  To:norm  question <<Are there any functions
+
+            This shows the messages you received since the last time  you  exe-
+       cuted  this  command (_i_n_c adds these new messages to your inbox folder).
+       You can see this list again, plus a list of any other messages you have,
+       by using the _s_c_a_n command.
+
+       _s_c_a_n
+
+            The scan listing shows the message number, followed by the date and
+       the  sender.   (If  you  are the sender, the addressee in the "To:" com-
+       ponent is displayed.  You may send yourself a message by including  your
+       name  among  the "To:" or "cc:" addressees.) It also shows the message's
+       subject; if the subject is short, the first part of the body of the mes-
+       sage is included after the characters <<.
+
+
+
+9                                         -7-
+
+
+
+
+
+
+
+
+
+                                         -8-
+
+
+       _s_h_o_w
+
+            This command shows the current message, that is, the first  one  of
+       the  new messages after an _i_n_c.  If the message is not specified by name
+       (number), it is generally the last message referred to by an _M_H command.
+       For example,
+
+
+            _s_h_o_w 5      will show message 5.
+
+
+            You can use the show command to copy a message or print a message.
+
+
+            _s_h_o_w > _x    will copy the message to file x.
+            _s_h_o_w | _l_p_r  will print the message, using the _l_p_r command.
+            _n_e_x_t        will show the message that follows the current message.
+            _p_r_e_v        will show the message previous to the current message.
+            _r_m_m         will remove the current message.
+            _r_m_m _3       will remove message 3.
+
+
+       _c_o_m_p
+
+            The _c_o_m_p command puts you in the editor to write or edit a message.
+       Fill  in or delete the "To:", "cc:", and "Subject:" fields, as appropri-
+       ate, and type the body of the message.  Then exit normally from the edi-
+       tor.   You will be asked "What now?".  Type a carriage return to see the
+       options.  Typing send will cause the message to  be  sent;  typing  quit
+       will cause an exit from _c_o_m_p, with the message draft saved.
+
+            If you quit without sending the message, it will be saved in a file
+       called  <name>/Mail/draft  (where  <name> is your $HOME directory).  You
+       can resume editing the message later with "comp -use"; or you  can  send
+       the message later, using the _s_e_n_d command.
+
+       _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+            This command uses a different editor and is  useful  for  preparing
+       "quick  and  dirty"  messages.  It prompts you for each component of the
+       header.  Type the information for that component,  or  type  a  carriage
+       return to omit the component.  After that, type the body of the message.
+       Backspacing is the only form of editing allowed with this editor.   When
+       the  body is complete, type a carriage return followed by <EOT> (usually
+       <CTRL-D>).  This completes the initial preparation of the message;  from
+       then on, use the same procedures as with _c_o_m_p (above).
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+                                         -9-
+
+
+       _r_e_p_l
+       _r_e_p_l n
+
+            This command makes up an initial message form with a header that is
+       appropriate  for  replying  to  an  existing message.  The message being
+       answered is the current message if no message number is mentioned, or  n
+       if a number is specified.  After the header is completed, you can finish
+       the message as in _c_o_m_p (above).
+
+            This is enough information to get you going using  _M_H.   There  are
+       more commands, and the commands described here have more features.  Sub-
+       sequent sections explain _M_H in complete detail.   The  system  is  quite
+       powerful  if you want to use its sophisticated features, but the forego-
+       ing commands suffice for sending and receiving messages.
+
+            There are numerous additional capabilities you may wish to explore.
+       For  example, the _p_i_c_k command will select a subset of messages based on
+       specified criteria such as sender and/or subject.   Groups  of  messages
+       may  be  designated, as described in Sec. IV, under Message Naming.  The
+       file ._m_h__p_r_o_f_i_l_e can be used to tailor your use of the message system to
+       your needs and preferences, as described in Sec. IV, under The User Pro-
+       file.  In general, you may  learn  additional  features  of  the  system
+       selectively,  according  to  your requirements, by studying the relevant
+       sections of this manual.  There is no need to learn all the  details  of
+       the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                               _4. _D_E_T_A_I_L_E_D _D_E_S_C_R_I_P_T_I_O_N
+
+
+
+9
+            This section describes the _M_H system in detail, including the  com-
+       ponents  of  the  user  profile, the conventions for message naming, and
+       some of the other _M_H conventions.  Readers who  are  generally  familiar
+       with  computer  systems  will  be  able  to  follow the principal ideas,
+       although some details may be meaningful  only  to  those  familiar  with
+       UNIX.
+
+
+9       _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+            The first time an _M_H command is issued by a new  user,  the  system
+       prompts for a "Path" and creates an _M_H "profile".
+
+            Each _M_H user has a profile which contains tailoring information for
+       each  individual  program.   Other  profile  entries control the _M_H path
+       (where folders and special files are kept), folder and  message  protec-
+       tions,  editor  selection,  and  default  arguments for each _M_H program.
+       Each user of _M_H also has a context file  which  contains  current  state
+       information for the _M_H package (the location of the context file is kept
+       in the user's _M_H directory, or may be named in the user profile).   When
+       a  folder  becomes the current folder, it is recorded in the user's con-
+       text.  (Other state information is kept in the  context  file,  see  the
+       manual  entry for _m_h-_p_r_o_f_i_l_e (5) for more details.) In general, the term
+       "profile entry" refer to entries in either the profile or context  file.
+       Users of _M_H needn't worry about the distinction, _M_H handles these things
+       automatically.
+
+            The _M_H profile is stored in the  file  ._m_h__p_r_o_f_i_l_e  in  the  user's
+       $HOME directory[1].  It has the format of a message  without  any  body.
+       That is, each profile entry is on one line, with a keyword followed by a
+       colon (:) followed by text particular to the keyword.
+       =>   _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t _h_a_v_e _b_l_a_n_k _l_i_n_e_s.
+       The keywords may have any combination of upper and lower case.  (See the
+       information of _m_h-_m_a_i_l later on in this manual for a description of mes-
+       sage formats.)
+
+            For the average _M_H user, the only profile entry  of  importance  is
+       "Path".   Path  specifies  a  directory  in which _M_H folders and certain
+       files such as "draft" are found.  The argument to this keyword must be a
+       legal  UNIX  path that names an existing directory.  If this path is not
+
+
+9          [1] By defining the envariable $MH, you can specify an alternate pro-
+       file to be used by _M_H commands.
+
+
+9                                         -10-
+
+
+
+
+
+
+
+
+
+                                         -11-
+
+
+       absolute (i.e., does not begin with a / ), it will be presumed to  start
+       from  the  user's  $HOME  directory.   All folder and message references
+       within _M_H will relate to this path unless full path names are used.
+
+            Message protection defaults to 644, and folder protection  to  711.
+       These  may  be  changed  by  profile  entries "Msg-Protect" and "Folder-
+       Protect", respectively.  The argument to  these  keywords  is  an  octal
+       number which is used as the UNIX file mode[2].
+
+            When an _M_H program starts running, it looks through the user's pro-
+       file for an entry with a keyword matching the program's name.  For exam-
+       ple, when _c_o_m_p is run, it looks for a "comp" profile entry.  If  one  is
+       found,  the text of the profile entry is used as the default switch set-
+       ting until all defaults are overridden by explicit  switches  passed  to
+       the     program     as    arguments.     Thus    the    profile    entry
+       "comp: -form standard.list"  would  direct  _c_o_m_p   to   use   the   file
+       "standard.list"  as the message skeleton.  If an explicit form switch is
+       given to the _c_o_m_p command, it will override the switch obtained from the
+       profile.
+
+            In UNIX, a program may exist under several names, either by linking
+       or  aliasing.   The actual invocation name is used by an _M_H program when
+       scanning for its profile defaults[3].  Thus, each _M_H  program  may  have
+       several  names by which it can be invoked, and each name may have a dif-
+       ferent set of default switches.  For example, if _c_o_m_p is invoked by  the
+       name  _i_c_o_m_p, the profile entry "icomp" will control the default switches
+       for this invocation of the  _c_o_m_p  program.   This  provides  a  powerful
+       definitional facility for commonly used switch settings.
+
+            The default editor for editing within _c_o_m_p, _r_e_p_l, _f_o_r_w,  and  _d_i_s_t,
+       is  usually  _p_r_o_m_p_t_e_r, but might be something else at your site, such as
+       /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e.  A different editor may be used by specifying the
+       profile  entry  "Editor:  ".  The argument to "Editor" is the name of an
+       executable program or shell command file which  can  be  found  via  the
+       user's  $PATH defined search path, excluding the current directory.  The
+       "Editor:"  profile  specification  may  in  turn  be  overridden  by   a
+       `-editor <editor>'  profile  switch associated with _c_o_m_p, _r_e_p_l, _f_o_r_w, or
+       _d_i_s_t.  Finally, an explicit editor switch specified with  any  of  these
+       four commands will have ultimate precedence.
+
+
+
+9          [2] See _c_h_m_o_d (1) in the _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+          [3] Unfortunately, the shell does not preserve  aliasing  information
+       when  calling  a program, hence if a program is invoked by an alias dif-
+       ferent than its name, the program will examine  the  profile  entry  for
+       it's name, not the alias that the user invoked it as.  The correct solu-
+       tion is to create a (soft) link in your $_H_O_M_E/_b_i_n directory  to  the  _M_H
+       program  of  your choice.  By giving this link a different name, you can
+       use an alternate set of defaults for the command.
+
+
+9
+
+
+
+
+
+
+
+
+
+                                         -12-
+
+
+            During message composition, more than one editor may be used.   For
+       example,  one  editor  (such  as _p_r_o_m_p_t_e_r ) may be used initially, and a
+       second editor may be invoked later to revise the message being  composed
+       (see  the discussion of _c_o_m_p in Section 5 for details).  A profile entry
+       "<lasteditor>-next: <editor>" specifies the name of  the  editor  to  be
+       used  after  a  particular  editor.  Thus "comp: -e prompter" causes the
+       initial text  to  be  collected  by  _p_r_o_m_p_t_e_r,  and  the  profile  entry
+       "prompter-next: ed"  names  ed  as the editor to be invoked for the next
+       round of editing.
+
+            Some of the _M_H commands, such as _s_h_o_w, can be used on message fold-
+       ers owned by others, if those folders are readable.  However, you cannot
+       write in someone else's folder.  All the _M_H command actions not  requir-
+       ing write permission may be used with a "read-only" folder.
+
+            Table 1 lists examples of some of  the  currently  defined  profile
+       entries, typical arguments, and the programs that reference the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+                                         -13-
+
+
+                                       Table 1
+9                                  PROFILE COMPONENTS
+                ______________________________________________________
+
+                                             _M_H Programs that
+                Keyword and Argument          use Component9______________________________________________________
+9                Path: Mail                   All
+                Current-Folder: inbox        Most
+                Editor: /usr/ucb/ex          _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                Msg-Protect: 644             _i_n_c
+                Folder-Protect: 711          _i_n_c, _p_i_c_k, _r_e_f_i_l_e
+                <program>: default switches  All
+                prompter-next: ed            _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                ______________________________________________________
+
+
+            Path should______ be present.  Current-Folder is maintained automatically
+       by many _M_H commands (see the Context sections of the individual commands
+       in Sec. IV).  All other entries are optional, defaulting to  the  values
+       described above.
+
+
+9       _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+            Messages may be referred to explicitly or implicitly when using  _M_H
+       commands.   A formal syntax of message names is given in Appendix B, but
+       the following description should be sufficient for most _M_H users.   Some
+       details  of  message  naming  that  apply  only  to certain commands are
+       included in the description of those commands.
+
+            Most of the _M_H commands accept arguments  specifying  one  or  more
+       folders,  and  one  or more messages to operate on.  The use of the word
+       "msg" as an argument to a command means that exactly  one  message  name
+       may  be  specified.   A  message name may be a number, such as 1, 33, or
+       234, or it may be one of the  "reserved"  message  names:  first,  last,
+       prev,  next,  and  cur.   (As a shorthand, a period (.) is equivalent to
+       cur.) The meanings of these names are straightforward:  "first"  is  the
+       first  message  in the folder; "last" is the last message in the folder;
+       "prev" is the message  numerically  previous  to  the  current  message;
+       "next"  is  the message numerically following the current message; "cur"
+       (or ".") is the current message in the folder.  In addition, _M_H supports
+       user-defined-sequences; see the description of the _m_a_r_k command for more
+       information.
+
+            The default in commands that take a "msg" argument is always "cur".
+
+            The word "msgs" indicates that several messages may  be  specified.
+       Such  a specification consists of several message designations separated
+       by spaces.  A message designation is either a message name or a  message
+       range.   A  message  range is a specification of the form name1-name2 or
+
+
+
+
+
+
+
+
+
+
+
+                                         -14-
+
+
+       name1:n, where name1 and name2 are message names and n  is  an  integer.
+       The  first  form  designates  all  the  messages  from  name1  to  name2
+       inclusive; this must be a non-empty range.  The second form specifies up
+       to  n messages, starting with name1 if name1 is a number, or first, cur,
+       or next, and ending with name1 if name1 is last or prev.  This interpre-
+       tation  of  n  is  overridden if n is preceded by a plus sign or a minus
+       sign; +n always means up to n  messages  starting  with  name1,  and  -n
+       always  means  up  to n messages ending with name1.  Repeated specifica-
+       tions of the same message have the same effect as a single specification
+       of the message.  Examples of specifications are:
+
+
+           1 5 7-11 22
+           first 6 8 next
+           first-10
+           last:5
+
+
+            The message name "all" is a shorthand for "first-last",  indicating
+       all of the messages in the folder.
+
+            In commands that accept "msgs" arguments, the default is either cur
+       or all, depending on which makes more sense.
+
+            In all of the _M_H commands, a plus sign preceding an argument  indi-
+       cates  a folder name.  Thus, "+inbox" is the name of the user's standard
+       inbox.  If an explicit folder argument is given to  an  _M_H  command,  it
+       will  become the current folder (that is, the "Current-Folder:" entry in
+       the user's profile will be changed to this folder).  In the case of  the
+       _r_e_f_i_l_e  command,  which  can  have multiple output folders, a new source
+       folder  (other  than  the  default  current  folder)  is  specified   by
+       `-src +folder'.
+
+
+9       _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+            One very powerful feature of _M_H is that  the  _M_H  commands  may  be
+       issued  from any current directory, and the proper path to the appropri-
+       ate folder(s) will be taken from the user's profile.  If the _M_H path  is
+       not  appropriate for a specific folder or file, the automatic prepending
+       of the _M_H path can be avoided by beginning a folder or file name with /,
+       or  with  ./  or  ../ component.  Thus any specific absolute path may be
+       specified along with any path relative to the current working directory.
+
+            Arguments to the various programs may be given in any  order,  with
+       the exception of a few switches whose arguments must follow immediately,
+       such as `-src +folder' for _r_e_f_i_l_e.
+
+            Whenever an _M_H command prompts the user, the valid options will  be
+       listed  in  response to a <RETURN>.  (The first of the listed options is
+       the default if end-of-file is encountered, such as from a command file.)
+
+9
+
+
+
+
+
+
+
+
+
+                                         -15-
+
+
+       A  valid  response  is  any  _u_n_i_q_u_e  abbreviation  of  one of the listed
+       options.
+
+            Standard UNIX documentation conventions are used in this report  to
+       describe  _M_H  command  syntax.  Arguments enclosed in brackets ([ ]) are
+       optional; exactly one of the arguments enclosed within braces ({ }) must
+       be specified, and all other arguments are required.  The use of ellipsis
+       dots (...) indicates zero or more repetitions of the previous item.  For
+       example,  "+folder  ..." would indicate that one or more "+folder" argu-
+       ments is required and "[+folder ...]" indicates that 0 or more "+folder"
+       arguments may be given.
+
+            _M_H departs from UNIX standards by using switches  that  consist  of
+       more  than  one  character,  e.g. `-header'.  To minimize typing, only a
+       unique abbreviation of a switch need  be  typed;  thus,  for  `-header',
+       `-hea'  is probably sufficient, depending on the other switches the com-
+       mand accepts.  Each _M_H program accepts the switch `-help' (which must be
+       spelled  out  fully)  and  produces  a  syntax description and a list of
+       switches.  In the list of switches, parentheses indicate required  char-
+       acters.   For  example,  all  `-help' switches will appear as "-(help)",
+       indicating that no abbreviation is accepted.  Furthermore,  the  `-help'
+       switch tells the version of the _M_H program you invoked.
+
+            Many _M_H switches have both on and off forms, such as `-format'  and
+       `-noformat'.  In many of the descriptions which follow, only one form is
+       defined; the other form, often used to nullify profile switch  settings,
+       is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+                                         -16-
+
+
+       _M_H _C_O_M_M_A_N_D_S
+
+            The _M_H package comprises several programs:
+
+            ali (1)        - list mail aliases
+            anno (1)       - annotate messages
+            bbc (1)        - check on BBoards
+            bboards (1)    - the UCI BBoards facility
+            burst (1)      - explode digests into messages
+            comp (1)       - compose a message
+            dist (1)       - redistribute a message to additional addresses
+            folder (1)     - set/list current folder/message
+            folders (1)    - list all folders
+            forw (1)       - forward messages
+            inc (1)        - incorporate new mail
+            mark (1)       - mark messages
+            mhl (1)        - produce formatted listings of MH messages
+            mhmail (1)     - send or read mail
+            mhook (1)      - MH receive-mail hooks
+            mhpath (1)     - print full pathnames of MH messages and folders
+            msgchk (1)     - check for messages
+            msh (1)        - MH shell (and BBoard reader)
+            next (1)       - show the next message
+            packf (1)      - compress a folder into a single file
+            pick (1)       - select messages by content
+            prev (1)       - show the previous message
+            prompter (1)   - prompting editor front end
+            rcvstore (1)   - incorporate new mail asynchronously
+            refile (1)     - file messages in other folders
+            repl (1)       - reply to a message
+            rmf (1)        - remove folder
+            rmm (1)        - remove messages
+            scan (1)       - produce a one line per message scan listing
+            send (1)       - send a message
+            show (1)       - show (list) messages
+            sortm (1)      - sort messages
+            vmh (1)        - visual front-end to MH
+            whatnow (1)    - prompting front-end for send
+            whom (1)       - report to whom a message would go
+
+
+            These programs are described below.  The form of  the  descriptions
+  conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+  ALI(1)                            -17-                            ALI(1)
+
+
+  _N_A_M_E
+       ali - list mail aliases
+
+  _S_Y_N_O_P_S_I_S
+       ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+            [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _A_l_i searches the named mail alias  files  for  each  of  the  given
+       _a_l_i_a_s_e_s.   It  creates  a  list of addresses for those _a_l_i_a_s_e_s, and
+       writes that list on standard output.   If  the  `-list'  option  is
+       specified,  each address appears on a separate line; otherwise, the
+       addresses are separated by commas and printed on as  few  lines  as
+       possible.
+
+       The `-user' option directs _a_l_i to  perform  its  processing  in  an
+       inverted  fashion: instead of listing the addresses that each given
+       alias expands to, _a_l_i will list the aliases  that  expand  to  each
+       given  address.   If the `-normalize' switch is given, _a_l_i will try
+       to track down the official hostname of the address.
+
+       The file specified by the profile entry "Aliasfile:" and any  addi-
+       tional  alias  files given by the `-alias aliasfile' switch will be
+       read.  Each _a_l_i_a_s is processed as described in _m_h-_a_l_i_a_s (5).
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /etc/passwd                         List of users
+       /etc/group                          List of groups
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Aliasfile:           For a default alias file
+
+
+  _S_e_e _A_l_s_o
+       mh-alias(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `-alias /usr/local/lib/mh/MailAliases'
+       `-nolist'
+       `-nonormalize'
+       `-nouser'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  ALI(1)                            -18-                            ALI(1)
+
+
+  _B_u_g_s
+       The `-user' option with `-nonormalize' is not entirely accurate, as
+       it  does  not replace local nicknames for hosts with their official
+       site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  ANNO(1)                           -19-                           ANNO(1)
+
+
+  _N_A_M_E
+       anno - annotate messages
+
+  _S_Y_N_O_P_S_I_S
+       anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+            [-date] [-nodate] [-text body] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _A_n_n_o annotates the specified messages in the named folder using the
+       field  and body.  Annotation is optionally performed by _d_i_s_t, _f_o_r_w,
+       and _r_e_p_l, to keep track of your distribution of, forwarding of, and
+       replies  to  a  message.   By using _a_n_n_o, you can perform arbitrary
+       annotations of your own.  Each message selected will  be  annotated
+       with the lines
+
+           field: date
+           field: body
+
+       The `-nodate' switch inhibits the date annotation, leaving only the
+       body  annotation.   The  `-inplace'  switch causes annotation to be
+       done in place in order to preserve links to the annotated message.
+
+       The field specified should be a valid 822-style message field name,
+       which  means  that  it  should consist of alphanumerics (or dashes)
+       only.  The body specified is arbitrary text.
+
+       If a `-component field' is not specified when _a_n_n_o is invoked, _a_n_n_o
+       will prompt the user for the name of field for the annotation.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       dist (1), forw (1), repl (1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to cur
+       `-noinplace'
+       `-date'
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  ANNO(1)                           -20-                           ANNO(1)
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The first
+       message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBC(1)                            -21-                            BBC(1)
+
+
+  _N_A_M_E
+       bbc - check on BBoards
+
+  _S_Y_N_O_P_S_I_S
+       bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+            [-archive] [-noarchive] [-protocol] [-noprotocol]
+            [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+            [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+            [-host host] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _b_b_c is a BBoard reading/checking program  that  interfaces  to  the
+       BBoard channel.
+
+       The _b_b_c program has three action switches which direct  its  opera-
+       tion:
+
+       The `-read' switch invokes the _m_s_h program on  the  named  _B_B_o_a_r_d_s.
+       If  you  also  specify the `-archive' switch, then  _b_b_c will invoke
+       the _m_s_h program on the  archives  of  the  named  _B_B_o_a_r_d_s.   If  no
+       _B_B_o_a_r_d_s   are   given  on  the  command  line,  and  you  specified
+       `-archive', _b_b_c will not read your  `bboards'  profile  entry,  but
+       will read the archives of the "system" _B_B_o_a_r_d instead.
+
+       The `-check' switch types out  status  information  for  the  named
+       _B_B_o_a_r_d_s.   _b_b_c  can  print one of several messages depending on the
+       status of both the BBoard and the user's reading  habits.  As  with
+       each  of these messages, the number given is the item number of the
+       last item placed in the BBoard.  This number (which  is  marked  in
+       the  messages  as the "BBoard-Id") is ever increasing.  Hence, when
+       _b_b_c says "n items", it really means that the highest  BBoard-Id  is
+       "n".   There  may,  or may not actually be "n" items in the BBoard.
+       Some common messages are:
+
+            BBoard -- n items unseen
+                 This message tells how many items the user  has  not  yet
+                 seen.  When invoked with the `-quiet' switch, this is the
+                 only informative line that _b_b_c will possibly print out.
+
+            BBoard -- empty
+                 The BBoard is empty.
+
+            BBoard -- n items (none seen)
+                 The BBoard has items in it, but the user hasn't seen any.
+
+            BBoard -- n items (all seen)
+                 The BBoard is non-empty, and the user has seen everything
+                 in it.
+
+            BBoard -- n items seen out of m
+                 The BBoard has at most m-n items that the  user  has  not
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBC(1)                            -22-                            BBC(1)
+
+
+                 seen.
+
+       The `-topics' switch directs _b_b_c to print  three  items  about  the
+       named _B_B_o_a_r_d_s: it's official name, the number of items present, and
+       the date and time of the last update.  If  no  _B_B_o_a_r_d_s  are  named,
+       then  all  BBoards  are listed.  If the `-verbose' switch is given,
+       more information is output.
+
+       The `-quiet' switch specifies that  _b_b_c  should  be  silent  if  no
+       _B_B_o_a_r_d_s  are  found  with  new  information.  The `-verbose' switch
+       specifies that _b_b_c is to consider you to be interested  in  _B_B_o_a_r_d_s
+       that you've already seen everything in.
+
+       To override the default _m_s_h_p_r_o_c and  the  profile  entry,  use  the
+       `-mshproc program' switch.  Any arguments not understood by _b_b_c are
+       passed to this program.  The `-protocol' switch tells _b_b_c that your
+       _m_s_h_p_r_o_c  knows  about  the  special _b_b_c protocol for reporting back
+       information.  _m_s_h (1), the default _m_s_h_p_r_o_c, knows all about this.
+
+       The `-file BBoardsfile' switch tells  _b_b_c  to  use  a  non-standard
+       _B_B_o_a_r_d_s  file  when  performing  its  calculations.  Similarly, the
+       `-user BBoardsuser' switch tells _b_b_c to use  a  non-standard  user-
+       name.   Both  of  these  switches  are  useful  for debugging a new
+       _B_B_o_a_r_d_s or _P_O_P file.
+
+       If the local host is configured as an NNTP BBoards  client,  or  if
+       the `-host host' switch is given, then _b_b_c will query the NNTP ser-
+       vice host as to the  status  of  the  BBoards.   For  NNTP  BBoards
+       clients, the `-user user' and the `-rpop' switches are ignored.
+
+       The  `-rcfile rcfile'  switch  overrides  the  use  of  ._b_b_r_c   for
+       user-specific  BBoards  information.   If  the  value  given to the
+       switch is not absolute, (i.e., does not begin with a / ),  it  will
+       be  presumed  to start from the current working directory.  If this
+       switch is not given (or the `-norcfile' switch is given), then  _b_b_c
+       consults  the envariable $MHBBRC, and honors it similarly.  If this
+       envariable is not set, then the file  ._b_b_r_c  in  the  user's  $HOME
+       directory is used.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       $HOME/.bbrc                         BBoard information
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       bboards:             To specify interesting BBoards
+       mshproc:             Program to read a given BBoard
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBC(1)                            -23-                            BBC(1)
+
+
+  _S_e_e _A_l_s_o
+       bbl(1), bboards(1), msh(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-read'
+       `-noarchive'
+       `-protocol'
+       `bboards' defaults to "system"
+       `-file /usr/bboards/BBoards'
+       `-user bboards'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The `-user' switch takes effect only if  followed  by  the  `-file'
+       switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBOARDS(1)                        -24-                        BBOARDS(1)
+
+
+  _N_A_M_E
+       bboards - the UCI BBoards facility
+
+  _S_Y_N_O_P_S_I_S
+       bbc [-check] [-read] bboards ...  [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The home directory of _b_b_o_a_r_d_s is where the BBoard system  is  kept.
+       This documentation describes some of the nuances of the BBoard sys-
+       tem.
+
+       BBoards, BBoard-IDs
+            A BBoard is just a file containing a group of messages  relat-
+            ing  to the same topic.  These files live in the ~bboards home
+            directory.  Each message in a BBoard file has  in  its  header
+            the  line  "BBoard-Id:  n",  where "n" is an ascending decimal
+            number.  This id-number  is  unique  for  each  message  in  a
+            BBoards  file.   It  should  NOT  be confused with the message
+            number of a message, which can change as messages are  removed
+            from the BBoard.
+
+       BBoard Handling
+            To read BBoards, use the _b_b_c and _m_s_h programs.  The  _m_s_h  com-
+            mand  is  a  monolithic  program  which contains all the func-
+            tionality of _M_H in a single program.  The `-check'  switch  to
+            _b_b_c  lets  you check on the status of BBoards, and the `-read'
+            switch tells _b_b_c to invoke _m_s_h to read those BBoards.
+
+       Creating a BBoard
+            Both public, and private BBoards are supported.   Contact  the
+            mail  address  _P_o_s_t_M_a_s_t_e_r  if  you'd  like  to  have  a BBoard
+            created.
+
+       BBoard addresses
+            Each BBoard has associated with it 4 addresses, these are (for
+            the ficticious BBoard called ``hacks''):
+              hacks : The Internet wide distribution list.
+              dist-hacks : The local BBoard.
+              hacks-request : The people responsible for the BBoard at the
+                   Internet level.
+              local-hacks-request : The people responsible for the  BBoard
+                   locally.
+
+  _F_i_l_e_s
+      $HOME/.mh_profile                   The user profile
+      $HOME/.bbrc                         BBoard information
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BBOARDS(1)                        -25-                        BBOARDS(1)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       bboards:             To specify interesting BBoards
+       mshproc:             Program to read a given BBoard
+
+
+  _S_e_e _A_l_s_o
+      bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+  _D_e_f_a_u_l_t_s
+       The default bboard is "system"
+
+
+  _C_o_n_t_e_x_t
+      None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BURST(1)                          -26-                          BURST(1)
+
+
+  _N_A_M_E
+       burst - explode digests into messages
+
+  _S_Y_N_O_P_S_I_S
+       burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+            [-verbose] [-noverbose] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _B_u_r_s_t considers the specified messages in the named  folder  to  be
+       Internet digests, and explodes them in that folder.
+
+       If `-inplace' is given, each digest is replaced by  the  "table  of
+       contents"  for  the digest (the original digest is removed).  _B_u_r_s_t
+       then renumbers all of the messages  following  the  digest  in  the
+       folder  to  make room for each of the messages contained within the
+       digest.  These messages are placed immediately after the digest.
+
+       If `-noinplace' is given, each digest is  preserved,  no  table  of
+       contents  is produced, and the messages contained within the digest
+       are placed at the end of the folder.  Other messages are  not  tam-
+       pered with in any way.
+
+       The `-quiet' switch directs _b_u_r_s_t to be silent about reporting mes-
+       sages that are not in digest format.
+
+       The `-verbose' switch directs _b_u_r_s_t to tell the  user  the  general
+       actions that it is taking to explode the digest.
+
+       It turns out that _b_u_r_s_t works equally well  on  forwarded  messages
+       and  blind-carbon-copies  as on Internet digests, provided that the
+       former two were generated by _f_o_r_w or _s_e_n_d.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Msg-Protect:         To set mode when creating a new message
+
+
+  _S_e_e _A_l_s_o
+       _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+       inc(1), msh(1), pack(1)
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  BURST(1)                          -27-                          BURST(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to cur
+       `-noinplace'
+       `-noquiet'
+       `-noverbose'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  If  `-in-
+       place'  is  given, then the first message burst becomes the current
+       message.  This leaves the context ready for a _s_h_o_w of the table  of
+       contents  of the digest, and a _n_e_x_t to see the first message of the
+       digest.  If `-noinplace' is given, then the first message extracted
+       from  the  first  digest  burst  becomes the current message.  This
+       leaves the context in a similar, but not identical,  state  to  the
+       context achieved when using `-inplace'.
+
+
+  _B_u_g_s
+       The _b_u_r_s_t program enforces a limit on the number of messages  which
+       may be _b_u_r_s_t from a single message.  This number is on the order of
+       1000 messages.  There is usually no limit on the number of messages
+       which may reside in the folder after the _b_u_r_s_ting.
+
+       Although _b_u_r_s_t uses a sophisticated algorithm  to  determine  where
+       one  encapsulated message ends and another begins, not all digesti-
+       fying programs  use  an  encapsulation  algorithm.   In  degenerate
+       cases, this usually results in _b_u_r_s_t finding an encapsulation boun-
+       dary prematurely and splitting a single encapsulated  message  into
+       two or more messages.  These erroneous digestifying programs should
+       be fixed.
+
+       Furthermore, any text which appears  after  the  last  encapsulated
+       message  is not placed in a seperate message by _b_u_r_s_t.  In the case
+       of digestified messages, this text is usally  an  "End  of  digest"
+       string.   As  a result of this possibly un-friendly behavior on the
+       part of _b_u_r_s_t, note that when the `-inplace' option is  used,  this
+       trailing  information  is lost.  In practice, this is not a problem
+       since correspondents usually place remarks in  text  prior  to  the
+       first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  COMP(1)                           -28-                           COMP(1)
+
+
+  _N_A_M_E
+       comp - compose a message
+
+  _S_Y_N_O_P_S_I_S
+       comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+            [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+            [-form formfile] [-use] [-nouse] [-whatnowproc program]
+            [-nowhatnowproc] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _C_o_m_p is used to create a new message to be  mailed.   It  copies  a
+       message form to the draft being composed and then invokes an editor
+       on the draft (unless `-noedit' is given, in which case the  initial
+       edit is suppressed).
+
+       The default message form contains the following elements:
+
+            To:
+            cc:
+            Subject:
+            --------
+
+       If the file named "components" exists in the user's  MH  directory,
+       it  will  be  used  instead  of  this  form.  The file specified by
+       `-form formfile' will be used if given.  You may  also  start  _c_o_m_p
+       using the contents of an existing message as the form.  If you sup-
+       ply either a `+folder' or `msg' argument, that message will be used
+       as  the  form.   You  may  not supply both a `-form formfile' and a
+       `+folder' or `msg' argument.  The line of dashes or  a  blank  line
+       must be left between the header and the body of the message for the
+       message to be identified properly when it is sent  (see  _s_e_n_d (1)).
+       The  switch  `-use'  directs  _c_o_m_p  to  continue editing an already
+       started message.  That is, if a _c_o_m_p (or _d_i_s_t, _r_e_p_l, or  _f_o_r_w )  is
+       terminated without sending the draft, the draft can be edited again
+       via "comp -use".
+
+       If the draft already exists, _c_o_m_p will ask you as to  the  disposi-
+       tion  of  the  draft.  A reply of quit will abort _c_o_m_p, leaving the
+       draft intact; replace will replace  the  existing  draft  with  the
+       appropriate  form;  list  will  display the draft; use will use the
+       draft for further composition; and  refile +folder  will  file  the
+       draft  in  the  given  folder,  and  give  you a new draft with the
+       appropriate form.  (The `+folder' argument to refile is required.)
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       The `-file file' switch says to use the named file as  the  message
+       draft.
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  COMP(1)                           -29-                           COMP(1)
+
+
+       The `-editor editor' switch indicates the editor  to  use  for  the
+       initial  edit.   Upon exiting from the editor, _c_o_m_p will invoke the
+       _w_h_a_t_n_o_w program.  See _w_h_a_t_n_o_w (1) for  a  discussion  of  available
+       options.   The invocation of this program can be inhibited by using
+       the `-nowhatnowproc' switch.  (In truth of fact, it is the  _w_h_a_t_n_o_w
+       program  which  starts  the  initial edit.  Hence, `-nowhatnowproc'
+       will prevent any edit from occurring.)
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/components        The message skeleton
+       or <mh-dir>/components              Rather than the standard skeleton
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/draft                      The draft file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Draft-Folder:        To find the default draft-folder
+       Editor:              To override the default editor
+       Msg-Protect:         To  set  mode  when  creating  a  new  message
+       (draft)
+       fileproc:            Program to refile the message
+       whatnowproc:         Program to ask the "What now?" questions
+
+
+  _S_e_e _A_l_s_o
+       dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msg' defaults to the current message
+       `-nodraftfolder'
+       `-nouse'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p uses a  built-in  _w_h_a_t_n_o_w,  it
+       does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+       your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _c_o_m_p  won't  run
+       it.
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  DIST(1)                           -30-                           DIST(1)
+
+
+  _N_A_M_E
+       dist - redistribute a message to additional addresses
+
+  _S_Y_N_O_P_S_I_S
+       dist [+folder] [msg] [-annotate] [-noannotate]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-form formfile] [-inplace]
+            [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _D_i_s_t is similar to _f_o_r_w.  It prepares  the  specified  message  for
+       redistribution to addresses that (presumably) are not on the origi-
+       nal address list.
+
+       The default message form contains the following elements:
+
+            Resent-To:
+            Resent-cc:
+
+       If the file named "distcomps" exists in the user's MH directory, it
+       will be used instead of this form.  In either case, the file speci-
+       fied by `-form formfile' will be used if given.  The form used will
+       be prepended to the message being resent.
+
+       If the draft already exists, _d_i_s_t will ask you as to  the  disposi-
+       tion  of  the  draft.  A reply of quit will abort _d_i_s_t, leaving the
+       draft intact; replace will replace the existing draft with a  blank
+       skeleton; and list will display the draft.
+
+       Only   those   addresses   in   "Resent-To:",   "Resent-cc:",   and
+       "Resent-Bcc:"  will  be sent.  Also, a "Resent-Fcc: folder" will be
+       honored (see _s_e_n_d (1)).  Note that with _d_i_s_t, the draft should con-
+       tain  only  "Resent-xxx:"  fields and no body.  The headers and the
+       body of the original message are copied to the draft when the  mes-
+       sage  is sent.  Use care in constructing the headers for the redis-
+       tribution.
+
+       If the `-annotate' switch is given, the  message being  distributed
+       will be annotated with the lines:
+
+            Resent: date
+            Resent: addrs
+
+       where each address list contains as many lines as  required.   This
+       annotation  will  be done only if the message is sent directly from
+       _d_i_s_t.  If the message is not  sent  immediately  from  _d_i_s_t,  "comp
+       -use"  may be used to re-edit and send the constructed message, but
+       the annotations won't take place.   The  '-inplace'  switch  causes
+       annotation  to  be  done in place in order to preserve links to the
+       annotated message.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  DIST(1)                           -31-                           DIST(1)
+
+
+       See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+       switches.   Note that while in the editor, the message being resent
+       is available through a link named "@" (assuming the  default  _w_h_a_t_-
+       _n_o_w_p_r_o_c ).   In  addition,  the  actual  pathname of the message is
+       stored in the envariable $editalt, and the pathname of  the  folder
+       containing the message is stored in the envariable $mhfolder.
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       Upon exiting from the editor, _d_i_s_t will invoke the _w_h_a_t_n_o_w program.
+       See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+       tion of this program can be inhibited by using the `-nowhatnowproc'
+       switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+       the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+       from occurring.)
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/distcomps         The message skeleton
+       or <mh-dir>/distcomps               Rather than the standard skeleton
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/draft                      The draft file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Draft-Folder:        To find the default draft-folder
+       Editor:              To override the default editor
+       fileproc:            Program to refile the message
+       whatnowproc:         Program to ask the "What now?" questions
+
+
+  _S_e_e _A_l_s_o
+       comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msg' defaults to cur
+       `-noannotate'
+       `-nodraftfolder'
+       `-noinplace'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The  mes-
+       sage distributed will become the current message.
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  DIST(1)                           -32-                           DIST(1)
+
+
+  _H_i_s_t_o_r_y
+       _D_i_s_t originally used headers of the form "Distribute-xxx:"  instead
+       of "Resent-xxx:".  In order to conform with the ARPA Internet stan-
+       dard, RFC-822, the "Resent-xxx:"  form  is  now  used.   _D_i_s_t  will
+       recognize  "Distribute-xxx:" type headers and automatically convert
+       them to "Resent-xxx:".
+
+
+  _B_u_g_s
+       _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check the message  being  distributed  for
+       adherence  to the transport standard, but _p_o_s_t called by _s_e_n_d does.
+       The _p_o_s_t program will balk (and rightly  so)  at  poorly  formatted
+       messages, and _d_i_s_t won't correct things for you.
+
+       If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _d_i_s_t uses a  built-in  _w_h_a_t_n_o_w,  it
+       does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+       your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _d_i_s_t  won't  run
+       it.
+
+       If your current working directory is not writable, the  link  named
+       "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FOLDER(1)                         -33-                         FOLDER(1)
+
+
+  _N_A_M_E
+       folder, folders - set/list current folder/message
+
+  _S_Y_N_O_P_S_I_S
+       folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+            [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+            [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+            [-pop] [-help]
+
+       folders
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       Since the _M_H environment is the shell, it is easy to lose track  of
+       the current folder from day to day.
+
+       When _f_o_l_d_e_r is given the `-print' switch (the default), the current
+       folder  and/or  message  may  be set, or all folders may be listed.
+       When a `+folder' argument is given,  this  corresponds  to  a  "cd"
+       operation  in the _C_S_h_e_l_l; when no `+folder' argument is given, this
+       corresponds roughly to a "pwd" operation in the _C_S_h_e_l_l.
+
+       _F_o_l_d_e_r will list the current folder, the number of messages in  it,
+       the  range  of  the  messages  (low-high),  and the current message
+       within the folder, and will flag extra files  if  they  exist.   An
+       example of the output is:
+
+       inbox+            has  16 messages (  3- 22); cur=  5.
+
+       If a `+folder' and/or `msg' are specified,  they  will  become  the
+       current  folder  and/or  message.  Specifying `-all' will produce a
+       line for each folder in the user's MH directory, sorted  alphabeti-
+       cally.   These folders are preceded by the read-only folders, which
+       occur as "atr-cur-" entries in the user's _M_H context.  For example,
+
+       Folder               # of messages ( range )  cur msg (other files)
+       /fsd/rs/m/tacc    has  35 messages (  1- 35); cur= 23.
+       /rnd/phyl/Mail/EP has  82 messages (  1-108); cur= 82.
+       ff                has  no messages.
+       inbox+            has  16 messages (  3- 22); cur=  5.
+       mh                has  76 messages (  1- 76); cur= 70.
+       notes             has   2 messages (  1-  2); cur=  1.
+       ucom              has 124 messages (  1-124); cur=  6; (others).
+                 TOTAL=      339 messages in 7 folders
+
+       The "+" after inbox indicates that it is the current  folder.   The
+       "(others)"  indicates that the folder `ucom' has files which aren't
+       messages.  These files may either be  sub-folders,  or  files  that
+       don't belong under the MH file naming scheme.
+
+       The header is output if either an `-all' or a `-header'  switch  is
+       specified;  it  is  suppressed  by `-noheader'.  Also, if _f_o_l_d_e_r is
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FOLDER(1)                         -34-                         FOLDER(1)
+
+
+       invoked by a name ending  with  "s"  (e.g.,  _f_o_l_d_e_r_s ),  `-all'  is
+       assumed.  A `-total' switch will produce only the summary line.
+
+       If a `+folder' and/or `msg' is given along with the `-all'  switch,
+       _f_o_l_d_e_r  will, in addition to setting the current folder and/or mes-
+       sage, list the top-level  folders  for  the  current  folder  (with
+       `-norecurse')  or  list all folders under the current folder recur-
+       sively (with `-recurse').
+
+       If `-fast' is given, only the folder name (or names in the case  of
+       `-all')  will  be listed.  (This is faster because the folders need
+       not be read.)
+
+       The `-pack' switch will compress the message  names  in  a  folder,
+       removing holes in message numbering.
+
+       The `-recurse' switch will list each folder  recursively.   Use  of
+       this  option  effectively  defeats  the  speed  enhancement  of the
+       `-fast' option, since each folder must be searched for  subfolders.
+       Nevertheless, the combination of these options is useful.
+
+       If the specified (or default) folder doesn't exist, the  user  will
+       be  queried as to whether the folder should be created.  When stan-
+       dard input is not a tty, the folder is created without  any  query.
+       (This is the easy way to create an empty folder for use later.)
+
+       The `-push' switch directs _f_o_l_d_e_r to push the current  folder  onto
+       the  _f_o_l_d_e_r-_s_t_a_c_k,  and  make  the  `+folder'  argument the current
+       folder.  If `+folder' is not given, the current folder and the  top
+       of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged.  This corresponds to the "pushd"
+       operation in the _C_S_h_e_l_l.
+
+       The `-pop'  switch  directs  _f_o_l_d_e_r  to  discard  the  top  of  the
+       _f_o_l_d_e_r-_s_t_a_c_k,  after  setting the current folder to that value.  No
+       `+folder' argument is allowed.   This  corresponds  to  the  "popd"
+       operation  in the _C_S_h_e_l_l.  The `-push' switch and the `-pop' switch
+       are mutually exclusive: the last occurrence of either one overrides
+       any previous occurrence of the other.
+
+       The `-list' switch directs _f_o_l_d_e_r  to  list  the  contents  of  the
+       _f_o_l_d_e_r-_s_t_a_c_k.   No `+folder' argument is allowed.  After a success-
+       ful  `-push'  or  `-pop',  the  `-list'  action  is  taken.    This
+       corresponds to the "dirs" operation in the _C_S_h_e_l_l.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FOLDER(1)                         -35-                         FOLDER(1)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Folder-Protect:      To set mode when creating a new folder
+       Folder-Stack:        To determine the folder stack
+       lsproc:              Program to list the contents of a folder
+
+
+  _S_e_e _A_l_s_o
+       refile(1), mhpath(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msg' defaults to none
+       `-nofast'
+       `-noheader'
+       `-nototal'
+       `-nopack'
+       `-norecurse'
+       `-print' is the default if no `-list', `-push', or `-pop' is specified
+
+
+  _C_o_n_t_e_x_t
+       If `+folder' and/or `msg' are given, they will become  the  current
+       folder and/or message.
+
+
+  _H_i_s_t_o_r_y
+       In previous versions of _M_H, the `-fast'  switch  prevented  context
+       changes  from  occurring for the current folder.  This is no longer
+       the case: if `+folder' is given, then _f_o_l_d_e_r will always change the
+       current folder to that.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FORW(1)                           -36-                           FORW(1)
+
+
+  _N_A_M_E
+       forw - forward messages
+
+  _S_Y_N_O_P_S_I_S
+       forw [+folder] [msgs] [-annotate] [-noannotate]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-filter filterfile]
+            [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+            [-whatnowproc program] [-nowhatnowproc] [-help]
+
+       forw [+folder] [msgs] [-digest list] [-issue number]
+            [-volume number] [other switches for _f_o_r_w] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _F_o_r_w may be used to prepare a message  containing  other  messages.
+       It   constructs  the  new  message  from  the  components  file  or
+       `-form formfile'  (see  _c_o_m_p ),  with  a  body  composed   of   the
+       message(s)  to  be forwarded.  An editor is invoked as in _c_o_m_p, and
+       after editing is complete, the user is prompted before the  message
+       is sent.
+
+       The default message form contains the following elements:
+
+            To:
+            cc:
+            Subject:
+            --------
+
+       If the file named "forwcomps" exists in the user's MH directory, it
+       will be used instead of this form.  In either case, the file speci-
+       fied by `-form formfile' will be used if given.
+
+       If the draft already exists, _f_o_r_w will ask you as to  the  disposi-
+       tion  of  the  draft.  A reply of quit will abort _f_o_r_w, leaving the
+       draft intact; replace will replace the existing draft with a  blank
+       skeleton; and list will display the draft.
+
+       If the `-annotate' switch is given, each  message  being  forwarded
+       will be annotated with the lines
+
+            Forwarded: date
+            Forwarded: addrs
+
+       where each address list contains as many lines as  required.   This
+       annotation  will  be done only if the message is sent directly from
+       _f_o_r_w.   If  the  message  is  not  sent  immediately   from   _f_o_r_w,
+       "comp -use"  may  be  used to re-edit and send the constructed mes-
+       sage, but the annotations won't take place.  The '-inplace'  switch
+       causes annotation to be done in place in order to preserve links to
+       the annotated message.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FORW(1)                           -37-                           FORW(1)
+
+
+       See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+       switches.
+
+       Although _f_o_r_w uses the `-form formfile' switch to direct it how  to
+       construct  the  beginning  of  the draft, the `-filter filterfile',
+       `-format', and `-noformat' switches direct _f_o_r_w as to how each for-
+       warded  message  should  be formatted in the body of the draft.  If
+       `-noformat' is specified, then each  forwarded  message  is  output
+       exactly  as  it  appears.   If `-format' or `-filter filterfile' is
+       specified, then each forwarded message is  filtered  (re-formatted)
+       prior  to  being  output to the body of the draft.  The filter file
+       for _f_o_r_w should be a standard form  file  for  _m_h_l,  as  _f_o_r_w  will
+       invoke  _m_h_l  to format the forwarded messages.  The default message
+       filter (what you get with `-format') is:
+
+            width=80,overflowtext=,overflowoffset=10
+            leftadjust,compress,compwidth=9
+            Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+            From:
+            To:
+            cc:
+            Subject:
+            :
+            body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+       If the file named "mhl.forward" exists in the user's MH  directory,
+       it  will  be  used  instead of this form.  In either case, the file
+       specified by `-filter filterfile' will be used if given.   To  sum-
+       marize:  `-noformat' will reproduce each forwarded message exactly,
+       `-format' will use _m_h_l and a default filterfile, "mhl.forward",  to
+       format  each  forwarded  message, and `-filter filterfile' will use
+       the named filterfile to format each forwarded message with _m_h_l.
+
+       Each forwarded message is separated with an encapsulation delimiter
+       and  dashes  in  the first column of the forwarded messages will be
+       prepended with `- ' so that when received, the message is  suitable
+       for  bursting  by  _b_u_r_s_t (1).   This  follows  the Internet RFC-934
+       guidelines.
+
+       For users of  _p_r_o_m_p_t_e_r (1),  by  specifying  prompter's  `-prepend'
+       switch  in  the  .mh_profile  file,  any commentary text is entered
+       before the forwarded messages.  (A major win!)
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       Upon exiting from the editor, _f_o_r_w will invoke the _w_h_a_t_n_o_w program.
+       See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+       tion of this program can be inhibited by using the `-nowhatnowproc'
+       switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FORW(1)                           -38-                           FORW(1)
+
+
+       the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+       from occurring.)
+
+       The `-digest list', `-issue number', and `-volume number'  switches
+       implement  a  digest  facility  for  _M_H.  Specifying these switches
+       enables and/or overloads the following escapes:
+
+       _T_y_p_e       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+       _c_o_m_p_o_n_e_n_t  _d_i_g_e_s_t  string   Argument to `-digest'
+       _f_u_n_c_t_i_o_n   _c_u_r     integer  Argument to `-volume'
+       _f_u_n_c_t_i_o_n   _m_s_g     integer  Argument to `-issue'
+
+       Consult the Advanced Features section of the _M_H User's  Manual  for
+       more information on making digests.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/forwcomps         The message skeleton
+       or <mh-dir>/forwcomps               Rather than the standard skeleton
+       /usr/local/lib/mh/digestcomps       The message skeleton if `-digest' is given
+       or <mh-dir>/digestcomps             Rather than the standard skeleton
+       /usr/local/lib/mh/mhl.forward       The message filter
+       or <mh-dir>/mhl.forward             Rather than the standard filter
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/draft                      The draft file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Draft-Folder:        To find the default draft-folder
+       Editor:              To override the default editor
+       Msg-Protect:         To  set  mode  when  creating  a  new  message
+       (draft)
+       fileproc:            Program to refile the message
+       mhlproc:             Program to filter messages being forwarded
+       whatnowproc:         Program to ask the "What now?" questions
+
+
+  _S_e_e _A_l_s_o
+       _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+       comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to cur
+       `-noannotate'
+       `-nodraftfolder'
+       `-noformat'
+       `-noinplace'
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  FORW(1)                           -39-                           FORW(1)
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The first
+       message forwarded will become the current message.
+
+
+  _B_u_g_s
+       If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _f_o_r_w uses a  built-in  _w_h_a_t_n_o_w,  it
+       does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+       your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _f_o_r_w  won't  run
+       it.
+
+       When _f_o_r_w is told to annotate the messages it forwards, it  doesn't
+       actually  annotate  them  until the draft is successfully sent.  If
+       from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h instead of _s_e_n_d,  it's  possible  to
+       confuse   _f_o_r_w   by   re-ordering   the   file   (e.g.,   by  using
+       `folder -pack') before the message is successfully sent.  _D_i_s_t  and
+       _r_e_p_l don't have this problem.
+
+       To avoid prepending the leading dash characters in  forwarded  mes-
+       sages,  there  is  a  `-nodashmunging'  option.   See  the  "Hidden
+       Features" section of the _M_H _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  INC(1)                            -40-                            INC(1)
+
+
+  _N_A_M_E
+       inc - incorporate new mail
+
+  _S_Y_N_O_P_S_I_S
+       inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+            [-nochangecur] [-form formatfile] [-format string]
+            [-file name] [-silent] [-nosilent] [-truncate] [-notruncate]
+            [-width columns] [-host host] [-user user] [-pack file]
+            [-nopack] [-rpop] [-norpop] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _I_n_c incorporates mail from the user's incoming mail drop into an _M_H
+       folder.   If `+folder' isn't specified, the folder named "inbox" in
+       the user's _M_H directory will  be  used.   The  new  messages  being
+       incorporated  are  assigned  numbers starting with the next highest
+       number in the folder.  If the specified (or default) folder doesn't
+       exist, the user will be queried prior to its creation.  As the mes-
+       sages are processed, a _s_c_a_n listing of the new mail is produced.
+
+       If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+       be  used as the protection on the newly created messages, otherwise
+       the _M_H default of 0644 will be used.  During all operations on mes-
+       sages,  this  initially  assigned  protection will be preserved for
+       each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+       individual   message,   and   its   protection  will  be  preserved
+       thereafter.
+
+       If the  switch  `-audit audit-file'  is  specified  (usually  as  a
+       default  switch in the profile), then _i_n_c will append a header line
+       and a line per message to the end of the specified audit-file  with
+       the format:
+
+            <<inc>> date
+                 <scan line for first message>
+                 <scan line for second message>
+                           <etc.>
+
+       This is useful for keeping track of volume and source  of  incoming
+       mail.   Eventually,  _r_e_p_l,  _f_o_r_w,  _c_o_m_p,  and _d_i_s_t may also produce
+       audits to this (or another) file, perhaps with "Message-Id:" infor-
+       mation  to keep an exact correspondence history.  "Audit-file" will
+       be in the user's MH directory unless a full path is specified.
+
+       _I_n_c will incorporate even improperly formatted  messages  into  the
+       user's  MH  folder,  inserting  a blank line prior to the offending
+       component and printing a comment identifying the bad message.
+
+       In all cases, the user's mail  drop  will  be  zeroed,  unless  the
+       `-notruncate' switch is given.
+
+       If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  INC(1)                            -41-                            INC(1)
+
+
+       then  _i_n_c  will add each of the newly incorporated messages to each
+       sequence named by the  profile  entry.   This  is  similar  to  the
+       "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+       which take `msgs' or `msg' arguments.  Note that _i_n_c will not  zero
+       each sequence prior to adding messages.
+
+       The interpretation of the `-form formatfile', `-format string', and
+       `-width columns' switches is the same as in _s_c_a_n (1).
+
+       By using the `-file name' switch, one can direct _i_n_c to incorporate
+       messages from a file other than the user's maildrop.  Note that the
+       name file will NOT be zeroed,  unless  the  `-truncate'  switch  is
+       given.
+
+       If the envariable $MAILDROP is set, then _i_n_c uses it as  the  loca-
+       tion  of  the  user's  maildrop  instead  of  the  default  (the `-
+       file name' switch still overrides this, however).  If this  envari-
+       able is not set, then _i_n_c will consult the profile entry "MailDrop"
+       for this information.  If the value found is not absolute, then  it
+       is  interpreted  relative to the user's _M_H directory.  If the value
+       is not found, then _i_n_c will look in the  standard  system  location
+       for the user's maildrop.
+
+       The `-silent' switch directs _i_n_c to be quiet and not ask any  ques-
+       tions at all.  This is useful for putting _i_n_c in the background and
+       going on to other things.
+
+       If the local host  is  configured  as  a  POP  client,  or  if  the
+       `-host host'  switch  is given, then _i_n_c will query the POP service
+       host as to the status of mail waiting.  The `-user user' switch may
+       be  given  to  specify  the  name of the POP subscriber you wish to
+       check mail for on the POP service host.  The  `-rpop'  switch  uses
+       the  UNIX  _r_P_O_P  (authentication done via trusted connections).  In
+       contrast, the `-norpop' switch uses the ARPA _P_O_P (in which case _i_n_c
+       will prompt for a password).
+
+       If _i_n_c uses POP, then the `-pack file' switch  is  considered.   If
+       given,  then  _i_n_c simply uses the POP to _p_a_c_k_f (1) the user's mail-
+       drop from the POP service host to the named file.  This  switch  is
+       provided  for those users who prefer to use _m_s_h to read their mail-
+       drops.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/spool/mail/$USER               Location of mail drop
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  INC(1)                            -42-                            INC(1)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Alternate-Mailboxes: To determine the user's mailboxes
+       Folder-Protect:      To set mode when creating a new folder
+       Msg-Protect:         To set mode when creating a  new  message  and
+       audit-file
+       Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+  _S_e_e _A_l_s_o
+       _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+       mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to "inbox"
+       `-noaudit'
+       `-changecur'
+       `-format' defaulted as described above
+       `-nosilent'
+       `-truncate' if `-file name' not given, `-notruncate' otherwise
+       `-width' defaulted to the width of the terminal
+       `-nopack'
+       `-rpop'
+
+
+  _C_o_n_t_e_x_t
+       The folder into which messages are being incorporated  will  become
+       the current folder.  The first message incorporated will become the
+       current message, unless the  `-nochangecur'  option  is  specified.
+       This leaves the context ready for a _s_h_o_w of the first new message.
+
+
+  _B_u_g_s
+       The argument to the `-format' switch must be interpreted as a  sin-
+       gle  token by the shell that invokes _i_n_c.  Therefore, one must usu-
+       ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MARK(1)                           -43-                           MARK(1)
+
+
+  _N_A_M_E
+       mark - mark messages
+
+  _S_Y_N_O_P_S_I_S
+       mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+            [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _m_a_r_k command manipulates message sequences by adding or  delet-
+       ing  message  numbers from folder-specific message sequences, or by
+       listing those sequences and messages.  A message sequence is a key-
+       word,  just  like  one  of  the  "reserved"  message names, such as
+       "first" or "next".  Unlike the "reserved" message names, which have
+       a fixed semantics on a per-folder basis, the semantics of a message
+       sequence may be defined, modified, and removed by the  user.   Mes-
+       sage  sequences are folder-specific, e.g., the sequence name "seen"
+       in the context of folder "+inbox" need not have any relation  what-
+       soever  to the sequence of the same name in a folder of a different
+       name.
+
+       Three action switches direct the operation of _m_a_r_k.  These switches
+       are  mutually  exclusive:  the last occurrence of any of them over-
+       rides any previous occurrence of the other two.
+
+       The `-add' switch tells _m_a_r_k to add messages  to  sequences  or  to
+       create   a   new   sequence.   For  each  sequence  named  via  the
+       `-sequence name' argument (which must occur at least once) the mes-
+       sages  named  via  `msgs' (which defaults to "cur" if no `msgs' are
+       given), are added to the sequence.  The messages to be  added  need
+       not  be  absent from the sequence.  If the `-zero' switch is speci-
+       fied, the sequence will be emptied prior to  adding  the  messages.
+       Hence,  `-add -zero' means that each sequence should be initialized
+       to the indicated messages, while  `-add -nozero'  means  that  each
+       sequence should be appended to by the indicated messages.
+
+       The `-delete' switch tells _m_a_r_k to delete messages from  sequences,
+       and  is  the  dual of `-add'.  For each of the named sequences, the
+       named messages are removed from the sequence.  These messages  need
+       not  be  already present in the sequence.  If the `-zero' switch is
+       specified, then all messages in the  folder  are  appended  to  the
+       sequence  prior  to  removing the messages.  Hence, `-delete -zero'
+       means that each sequence should contain all messages  except  those
+       indicated,  while  `-delete -nozero'  means that only the indicated
+       messages should be removed from each sequence.   As  expected,  the
+       command   `mark -sequence seen -delete all'  deletes  the  sequence
+       "seen" from the current folder.
+
+       When creating (or modifying) a sequence, the `-public' switch indi-
+       cates that the sequence should be made readable for other _M_H users.
+       In contrast, the `-nopublic' switch  indicates  that  the  sequence
+       should be private to the user's _M_H environment.
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MARK(1)                           -44-                           MARK(1)
+
+
+       The `-list' switch tells _m_a_r_k to list both  the  sequences  defined
+       for  the  folder  and the messages associated with those sequences.
+       _M_a_r_k will list each sequence named via `-sequence name' (or all  of
+       them  if  `-sequence' isn't used), and the messages associated with
+       that sequence.  The `-zero' switch does not affect the operation of
+       `-list'.
+
+       The current restrictions on sequences are:
+
+         The name used to denote a message sequence  must  consist  of  an
+         alphabetic  character followed by zero or more alphanumeric char-
+         acters, and can not be one of the "reserved" message names (e.g.,
+         "first", "cur", and so forth).
+
+         Only a certain number of sequences may be  defined  for  a  given
+         folder.  This number is usually limited to 10.
+
+         Message ranges with user-defined sequence names are restricted to
+         the  form  "name:n"  or "name:-n", and refer to the first or last
+         `n' messages of the sequence `name', respectively.  Constructs of
+         the form "name1-name2" are forbidden.
+
+  _F_i_l_e_s
+      $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+      pick (1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `-add' if `-sequence' is specified, `-list' otherwise
+       `msgs' defaults to cur (or all if `-list' is specified)
+       `-nopublic' if the folder is read-only, `-public' otherwise
+       `-nozero'
+
+
+  _C_o_n_t_e_x_t
+      If a folder is given, it will become the current folder.
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHL(1)                            -45-                            MHL(1)
+
+
+  _N_A_M_E
+       mhl - produce formatted listings of MH messages
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+            [-folder +folder] [-form formfile] [-length lines]
+            [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+            [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _M_h_l is a formatted message listing program.  It can be  used  as  a
+       replacement  for  _m_o_r_e (1)  (the default _s_h_o_w_p_r_o_c ).  As with _m_o_r_e,
+       each of the messages specified as arguments (or the standard input)
+       will  be  output.   If more than one message file is specified, the
+       user will be prompted prior to each one, and a  <RETURN>  or  <EOT>
+       will  begin  the  output,  with  <RETURN>  clearing  the screen (if
+       appropriate), and <EOT> (usually  CTRL-D)  suppressing  the  screen
+       clear.  An <INTERRUPT> (usually CTRL-C) will abort the current mes-
+       sage output, prompting for the next message (if there is one),  and
+       a  <QUIT> (usually CTRL-\) will terminate the program (without core
+       dump).
+
+       The `-bell' option tells _m_h_l to ring the terminal's bell at the end
+       of  each  page,  while  the  `-clear' option tells _m_h_l to clear the
+       scree at the end of each page (or output a formfeed after each mes-
+       sage).   Both  of  these  switches (and their inverse counterparts)
+       take effect only if the  profile  entry  _m_o_r_e_p_r_o_c  is  defined  but
+       empty,  and _m_h_l is outputting to a terminal.  If the _m_o_r_e_p_r_o_c entry
+       is defined and non-empty, and _m_h_l is outputting to a terminal, then
+       _m_h_l  will  cause the _m_o_r_e_p_r_o_c to be placed between the terminal and
+       _m_h_l and the switches are ignored.   Furthermore,  if  the  `-clear'
+       switch is used and _m_h_l'_s output is directed to a terminal, then _m_h_l
+       will consult the $TERM and $TERMCAP envariables  to  determine  the
+       user's  terminal type in order to find out how to clear the screen.
+       If the `-clear' switch is used and _m_h_l'_s output is not directed  to
+       a  terminal (e.g., a pipe or a file), then _m_h_l will send a formfeed
+       after each message.
+
+       To override the default _m_o_r_e_p_r_o_c and the  profile  entry,  use  the
+       `-moreproc program'  switch.   Note  that  _m_h_l  will  never start a
+       _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+       The `-length length' and `-width width'  switches  set  the  screen
+       length  and width, respectively.  These default to the values indi-
+       cated by $TERMCAP, if appropriate, otherwise they default to 40 and
+       80, respectively.
+
+       The default format file used by _m_h_l is called _m_h_l._f_o_r_m_a_t (which  is
+       first  searched  for in the user's _M_H directory, and then sought in
+       the /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h directory), this can be changed by using  the
+       `-form formatfile' switch.
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHL(1)                            -46-                            MHL(1)
+
+
+       Finally, the `-folder +folder' switch  sets  the  _M_H  folder  name,
+       which  is  used  for the "messagename:" field described below.  The
+       envariable $mhfolder is consulted  for  the  default  value,  which
+       _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize appropriately.
+
+       _M_h_l operates in two phases: 1) read and parse the format file,  and
+       2)  process  each  message  (file).   During  phase  1, an internal
+       description of the format is produced as  a  structured  list.   In
+       phase  2,  this list is walked for each message, outputting message
+       information under the format constraints from the format file.
+
+       The "mhl.format" form file contains information controlling  screen
+       clearing,  screen size, wrap-around control, transparent text, com-
+       ponent ordering, and component formatting.  Also, a  list  of  com-
+       ponents  to ignore may be specified, and a couple of "special" com-
+       ponents are defined to provide added functionality.  Message output
+       will be in the order specified by the order in the format file.
+
+       Each line of mhl.format has one of the formats:
+
+            ;comment
+            :cleartext
+            variable[,variable...]
+            component:[variable,...]
+
+       A line beginning with a `;' is a comment, and is ignored.   A  line
+       beginning with a `:' is clear text, and is output exactly as is.  A
+       line containing only a `:' produces a blank line in the output.   A
+       line  beginning with "component:" defines the format for the speci-
+       fied component, and finally,  remaining  lines  define  the  global
+       environment.
+
+       For example, the line:
+
+            width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+       defines the screen size to be 80 columns by 40 rows, specifies that
+       the screen should be cleared prior to each page, that the  overflow
+       indentation  is  5,  and  that overflow text should be flagged with
+       "***".
+
+       Following are all of the current variables and their arguments.  If
+       they  follow a component, they apply only to that component, other-
+       wise, their affect is global.  Since the  whole  format  is  parsed
+       before  any output processing, the last global switch setting for a
+       variable applies to the whole message if that variable is used in a
+       global context (i.e., bell, clearscreen, width, length).
+
+            _v_a_r_i_a_b_l_e       _t_y_p_e       _s_e_m_a_n_t_i_c_s
+            width          integer    screen width or component width
+            length         integer    screen length or component length
+            offset         integer    positions to indent "component: "
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHL(1)                            -47-                            MHL(1)
+
+
+            overflowtext   string     text to use at the beginning of an
+                                      overflow line
+            overflowoffset integer    positions to indent overflow lines
+            compwidth      integer    positions to indent component text
+                                      after the first line is output
+            uppercase      flag       output text of this component in all
+                                      upper case
+            nouppercase    flag       don't uppercase
+            clearscreen    flag/G     clear the screen prior to each page
+            noclearscreen  flag/G     don't clearscreen
+            bell           flag/G     ring the bell at the end of each page
+            nobell         flag/G     don't bell
+            component      string/L   name to use instead of "component" for
+                                      this component
+            nocomponent    flag       don't output "component: " for this
+                                      component
+            center         flag       center component on line (works for
+                                      one-line components only)
+            nocenter       flag       don't center
+            leftadjust     flag       strip off leading whitespace on each
+                                      line of text
+            noleftadjust   flag       don't leftadjust
+            compress       flag       change newlines in text to spaces
+            nocompress     flag       don't compress
+            split          flag       don't combine multiple fields into a single field
+            nosplit        flag       combine multiple fields into a single field
+            formatfield    string     format string for this component (see below)
+            addrfield      flag       field contains addresses
+            datefield      flag       field contains dates
+
+       To specify the value of integer-valued and string-valued variables,
+       follow   their   name   with   an   equals-sign   and   the  value.
+       Integer-valued  variables   are   given   decimal   values,   while
+       string-valued  variables  are  given  arbirtray  text  bracketed by
+       double-quotes.  If a value is suffixed by "/G" or  "/L",  then  its
+       value  is  useful  in  a global-only or local-only context (respec-
+       tively).
+
+       A line of the form:
+
+           ignores=component,...
+
+       specifies a list of components which are never output.
+
+       The component  "MessageName"  (case-insensitive)  will  output  the
+       actual  message name (file name) preceded by the folder name if one
+       is specified or found in the environment.  The format is  identical
+       to that produced by the `-header' option to _s_h_o_w.
+
+       The component "Extras" will output all of  the  components  of  the
+       message  which were not matched by explicit components, or included
+       in the ignore list.  If this component is not specified, an  ignore
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHL(1)                            -48-                            MHL(1)
+
+
+       list  is  not  needed  since  all  non-specified components will be
+       ignored.
+
+       If "nocomponent" is NOT specified, then the component name will  be
+       output as it appears in the format file.
+
+       The default format is:
+
+            : -- using template mhl.format --
+            overflowtext="***",overflowoffset=5
+            leftadjust,compwidth=9
+            ignores=msgid,message-id,received
+            Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+            To:
+            cc:
+            :
+            From:
+            Subject:
+            :
+            extras:nocomponent
+            :
+            body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+       The  variable  "formatfield"  specifies  a   format   string   (see
+       _m_h-_f_o_r_m_a_t (5)).   The  flag  variables  "addrfield" and "datefield"
+       (which are mutually exclusive), tell _m_h_l to interpret  the  escapes
+       in the format string as either addresses or dates, respectively.
+
+       By default, _m_h_l does not apply any formatting string to fields con-
+       taining  address  or  dates  (see  _m_h-_m_a_i_l (5)  for a list of these
+       fields).  Note that this results in faster operation since _m_h_l must
+       parse both addresses and dates in order to apply a format string to
+       them.  If desired, _m_h_l can be given a  default  format  string  for
+       either  address  or  date  fields (but not both).  To do this, on a
+       global line specify: either the flag addrfield or datefield,  along
+       with the apropriate formatfield variable string.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mhl.format        The message template
+       or <mh-dir>/mhl.format              Rather than the standard template
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       moreproc:            Program to use as interactive front-end
+
+
+  _S_e_e _A_l_s_o
+       show(1), ap(8), dp(8)
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHL(1)                            -49-                            MHL(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-bell'
+       `-noclear'
+       `-length 40'
+       `-width 80'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       There should be some way to pass `bell' and `clear' information  to
+       the front-end.
+
+       On hosts where _M_H was configured  with  the  BERK  option,  address
+       parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHMAIL(1)                         -50-                         MHMAIL(1)
+
+
+  _N_A_M_E
+       mhmail - send or read mail
+
+  _S_Y_N_O_P_S_I_S
+       mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+            [-subject subject]] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _M_H_m_a_i_l is intended as a replacement for the standard Bell mail pro-
+       gram  (_b_e_l_l_m_a_i_l (1)),  compatible  with  _M_H.   When invoked without
+       arguments, it simply invokes _i_n_c (1) to  incorporate  new  messages
+       from  the  user's maildrop.  When one or more users is specified, a
+       message is read from the standard input and spooled to a  temporary
+       file.   _M_H_m_a_i_l then invokes _p_o_s_t (8) with the name of the temporary
+       file as its argument to deliver the message to the specified user.
+
+       The `-subject subject' switch can be used to specify the "Subject:"
+       field  of  the  message.   The  `-body text'  switch can be used to
+       specify the text of the message; if it is specified, then the stan-
+       dard input is not read.  Normally, addresses appearing as arguments
+       are put in the "To:" field.  If  the  `-cc'  switch  is  used,  all
+       addresses following it are placed in the "cc:" field.
+
+       By using `-from addr', you can specify the "From:"  header  of  the
+       draft.    Naturally,   _p_o_s_t   will  fill-in  the  "Sender:"  header
+       correctly.
+
+       This program is intended for the use of programs  such  as  _a_t (1),
+       which  expect  to  send  mail automatically to various users.  Nor-
+       mally, real people (as opposed to the "unreal" ones) will prefer to
+       use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+  _F_i_l_e_s
+       /usr/local/inc                      Program to incorporate a maildrop into a folder
+       /usr/local/lib/mh/post              Program to deliver a message
+       /tmp/mhmail*                        Temporary copy of message
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       inc(1), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHMAIL(1)                         -51-                         MHMAIL(1)
+
+
+  _C_o_n_t_e_x_t
+       If _i_n_c is invoked, then _i_n_c's context changes occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHOOK(1)                          -52-                          MHOOK(1)
+
+
+  _N_A_M_E
+       mhook - MH receive-mail hooks
+
+  _S_Y_N_O_P_S_I_S
+       $HOME/.maildelivery
+
+       /usr/local/lib/mh/rcvdist [-form formfile] [switches for _p_o_s_t_p_r_o_c]
+            address ...  [-help]
+
+       /usr/local/lib/mh/rcvpack file [-help]
+
+       /usr/local/lib/mh/rcvtty [command] [-form formatfile]
+            [-format string] [-bell] [-nobell] [-newline] [-nonewline]
+            [-biff] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       A receive-mail hook is a program that is run whenever you receive a
+       mail message.  You do NOT invoke the hook yourself, rather the hook
+       is invoked on your behalf by _M_M_D_F.
+
+       The ._m_a_i_l_d_e_l_i_v_e_r_y file, which is an ordinary ASCII  file,  controls
+       how  local  delivery  is performed.  This file is read by the local
+       channel.  See _m_a_i_l_d_e_l_i_v_e_r_y (5) for the details.
+
+       Four programs are currently standardly available,  _r_c_v_d_i_s_t  (redis-
+       tribute  incoming messages to additional recipients), _r_c_v_p_a_c_k (save
+       incoming messages in a _p_a_c_k_f'd file), and _r_c_v_t_t_y  (notify  user  of
+       incoming  messages).  The fourth program, _r_c_v_s_t_o_r_e (1) is described
+       separately.  They all reside in the /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/ directory.
+
+       The _r_c_v_d_i_s_t program will resend a copy of the message to all of the
+       addresses  listed  on  its command line.  It uses the format string
+       facility described in _m_h-_f_o_r_m_a_t (5).
+
+       The _r_c_v_p_a_c_k program will append a copy of the message to  the  file
+       listed  on  its  command  line.  Its use is obsoleted by the ._m_a_i_l_-
+       _d_e_l_i_v_e_r_y.
+
+       The _r_c_v_t_t_y program executes the named file with the message as  its
+       standard input, and writes the resulting output on your terminal.
+
+       If no file is specified,  or  is  bogus,  etc.,  then  _r_c_v_t_t_y  will
+       instead    write    a    one-line   scan   listing.    Either   the
+       `-form formatfile' or `-format string' option may be used to  over-
+       ride  the  default output format (see _m_h-_f_o_r_m_a_t (5)).  A newline is
+       output before the message output, and the  terminal  bell  is  rung
+       after  the  output.   The  `-nonewline'  and `-nobell' options will
+       inhibit these functions.
+
+       Normally, _r_c_v_t_t_y obeys write permission  as  granted  by  _m_e_s_g (1).
+       With  the  `-biff' option, _r_c_v_t_t_y will obey the notification status
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHOOK(1)                          -53-                          MHOOK(1)
+
+
+       set by _b_i_f_f (1).  If the terminal access daemon (TTYD) is available
+       on  your system, then _r_c_v_t_t_y will give its output to the daemon for
+       output instead of writing on the user's terminal.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       $HOME/.maildelivery                 The file controlling local delivery
+       /usr/local/lib/mh/maildelivery      Rather than the standard file
+
+
+  _S_e_e _A_l_s_o
+       rcvstore (1), maildelivery(5), mh-format(5)
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       Only two return codes are meaningful, others should be.
+
+       Versions of _M_M_D_F with the _m_a_i_l_d_e_l_i_v_e_r_y  mechanism  aren't  entirely
+       backwards-compatible   with  earlier  versions.   If  you  have  an
+       old-style hook, the best you can do is to have  a  one-line  ._m_a_i_l-
+       _d_e_l_i_v_e_r_y file:
+
+        default - pipe A "bin/rcvmail $(address) $(info) $(sender)"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHPATH(1)                         -54-                         MHPATH(1)
+
+
+  _N_A_M_E
+       mhpath - print full pathnames of MH messages and folders
+
+  _S_Y_N_O_P_S_I_S
+       mhpath [+folder] [msgs] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _M_h_p_a_t_h expands and sorts the message list  `msgs'  and  writes  the
+       full  pathnames of the messages to the standard output separated by
+       newlines.  If no `msgs' are specified, _m_h_p_a_t_h  outputs  the  folder
+       pathname  instead.   If  the  only argument is `+', your MH _P_a_t_h is
+       output; this can be useful is shell scripts.
+
+       Contrasted with other MH commands, a message argument to _m_h_p_a_t_h may
+       often  be intended for _w_r_i_t_i_n_g.  Because of this: 1) the name "new"
+       has been added to _m_h_p_a_t_h's list of reserved message names (the oth-
+       ers  are  "first",  "last", "prev", "next", "cur", and "all").  The
+       new message is equivalent to the message after the last message  in
+       a  folder  (and equivalent to 1 in a folder without messages).  The
+       "new" message may not be used as  part  of  a  message  range.   2)
+       Within a message list, the following designations may refer to mes-
+       sages that do not exist: a single numeric message name, the  single
+       message  name "cur", and (obviously) the single message name "new".
+       All other message designations must refer to at least one  existing
+       message.  3) An empty folder is not in itself an error.
+
+       Message numbers greater than the  highest  existing  message  in  a
+       folder  as  part  of a range designation are replaced with the next
+       free message number.
+
+       Examples: The current folder foo contains messages 3 5 6.   Cur  is
+       4.
+
+            % mhpath
+            /r/phyl/Mail/foo
+
+            % mhpath all
+            /r/phyl/Mail/foo/3
+            /r/phyl/Mail/foo/5
+            /r/phyl/Mail/foo/6
+
+            % mhpath 2001
+            /r/phyl/Mail/foo/7
+
+            % mhpath 1-2001
+            /r/phyl/Mail/foo/3
+            /r/phyl/Mail/foo/5
+            /r/phyl/Mail/foo/6
+
+            % mhpath new
+            /r/phyl/Mail/foo/7
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHPATH(1)                         -55-                         MHPATH(1)
+
+
+            % mhpath last new
+            /r/phyl/Mail/foo/6
+            /r/phyl/Mail/foo/7
+
+            % mhpath last-new
+            bad message list "last-new".
+
+            % mhpath cur
+            /r/phyl/Mail/foo/4
+
+            % mhpath 1-2
+            no messages in range "1-2".
+
+            % mhpath first:2
+            /r/phyl/Mail/foo/3
+            /r/phyl/Mail/foo/5
+
+            % mhpath 1 2
+            /r/phyl/Mail/foo/1
+            /r/phyl/Mail/foo/2
+
+       _M_H_p_a_t_h is also useful in back-quoted operations:
+
+            % cd `mhpath +inbox`
+
+            % echo `mhpath +`
+            /r/phyl/Mail
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       folder(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to none
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MHPATH(1)                         -56-                         MHPATH(1)
+
+
+  _B_u_g_s
+       Like all MH commands, _m_h_p_a_t_h expands and sorts  [msgs].   So  don't
+       expect
+
+            mv `mhpath 501 500`
+
+       to move 501 to 500.  Quite the reverse.  But
+
+            mv `mhpath 501` `mhpath 500`
+
+       will do the trick.
+
+       Out of range message 0 is treated far more severely than large  out
+       of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSGCHK(1)                         -57-                         MSGCHK(1)
+
+
+  _N_A_M_E
+       msgchk - check for messages
+
+  _S_Y_N_O_P_S_I_S
+       msgchk [-date] [-nodate] [-notify all/mail/nomail]
+            [-nonotify all/mail/nomail] [-host host] [-user user] [-rpop]
+            [-norpop] [users ...] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       The _m_s_g_c_h_k program checks all known mail drops for mail waiting for
+       you.  For those drops which have mail for you, _m_s_g_c_h_k will indicate
+       if it believes that you have seen the mail in question before.
+
+       The `-notify type' switch indicates under what circumstances _m_s_g_c_h_k
+       should  produce a message.  The default is `-notify all' which says
+       that _m_s_g_c_h_k should always report the status of the users  maildrop.
+       Other  values  for  `type'  include  `mail'  which says that _m_s_g_c_h_k
+       should report the status of waiting mail; and, `nomail' which  says
+       that  _m_s_g_c_h_k  should  report  the  status  of empty maildrops.  The
+       `-nonotify type' switch has the inverted sense, so  `-nonotify all'
+       directs  _m_s_g_c_h_k  to  never report the status of maildrops.  This is
+       useful if the  user  wishes  to  check  _m_s_g_c_h_k's  exit  status.   A
+       non-zero  exit  status  indicates  that mail was not waiting for at
+       least one of the indicated users.
+
+       If _m_s_g_c_h_k produces output, then the `-date' switch  directs  _m_s_g_c_h_k
+       to  print  out  the  last date mail was read, if this can be deter-
+       mined.
+
+       If the local host  is  configured  as  a  POP  client,  or  if  the
+       `-host host'  switch  is  given,  _m_s_g_c_h_k will query the POP service
+       host as to the status of mail waiting.  The `-user user' switch may
+       be  given  to  specify  the  name of the POP subscriber you wish to
+       check mail for on the POP service host.  The  `-rpop'  switch  uses
+       the  UNIX  _r_P_O_P  (authentication done via trusted connections).  In
+       contrast, the `-norpop' switch uses the ARPA  _P_O_P  (in  which  case
+       _m_s_g_c_h_k will prompt for a password).
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/spool/mail/$USER               Location of mail drop
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSGCHK(1)                         -58-                         MSGCHK(1)
+
+
+  _S_e_e _A_l_s_o
+       _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+       inc(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `user' defaults to the current user
+       `-date'
+       `-notify all'
+       `-rpop'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSH(1)                            -59-                            MSH(1)
+
+
+  _N_A_M_E
+       msh - MH shell (and BBoard reader)
+
+  _S_Y_N_O_P_S_I_S
+       msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+            [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _m_s_h is an interactive program that implements a subset of the  nor-
+       mal _M_H commands operating on a single file in _p_a_c_k_f'd format.  That
+       is, _m_s_h is used to read a file that contains a number of  messages,
+       as  opposed  to the standard _M_H style of reading a number of files,
+       each file being a separate message in a folder.  _m_s_h's chief advan-
+       tage is that the normal _M_H style does not allow a file to have more
+       than one message in it.  Hence, _m_s_h is ideal for  reading  _B_B_o_a_r_d_s,
+       as  these  files are delivered by the transport system in this for-
+       mat.  In addition, _m_s_h can be used on other files, such as  message
+       archives  which  have been _p_a_c_ked (see _p_a_c_k_f (1)).  Finally, _m_s_h is
+       an excellent _M_H tutor.  As the only commands available to the  user
+       are  _M_H  commands,  this  allows _M_H beginners to concentrate on how
+       commands to _M_H are formed and (more or less) what they mean.
+
+       When invoked, _m_s_h reads the named file, and enters a command  loop.
+       The  user  may type most of the normal _M_H commands.  The syntax and
+       semantics of these commands typed to _m_s_h are identical to their  _M_H
+       counterparts.   In  cases  where  the nature of _m_s_h would be incon-
+       sistent (e.g., specifying a `+folder' with some commands), _m_s_h will
+       duly inform the user.  The commands that _m_s_h currently supports (in
+       some slightly modified or restricted forms) are:
+
+            ali
+            burst
+            comp
+            dist
+            folder
+            forw
+            inc
+            mark
+            mhmail
+            msgchk
+            next
+            packf
+            pick
+            prev
+            refile
+            repl
+            rmm
+            scan
+            send
+            show
+            sortm
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSH(1)                            -60-                            MSH(1)
+
+
+            whatnow
+            whom
+
+       In addition, _m_s_h has a "help" command which gives a brief overview.
+       To  terminate  _m_s_h, type CTRL-D, or use the "quit" command.  If _m_s_h
+       is being invoked from _b_b_c, then typing CTRL-D will also tell _b_b_c to
+       exit as well, while using the "quit" command will return control to
+       _b_b_c, and _b_b_c will continue examining the list of BBoards that it is
+       scanning.
+
+       If the file is writable and has been modified,  then  using  "quit"
+       will query the user if the file should be updated.
+
+       The `-prompt string' switch sets the prompting string for _m_s_h.
+
+       You may wish to use an alternate _M_H profile for the  commands  that
+       _m_s_h  executes; see _m_h-_p_r_o_f_i_l_e (5) for details about the $MH envari-
+       able.
+
+       When invoked from _b_b_c, two special features are enabled: First, the
+       `-scan' switch directs _m_s_h to do a `scan unseen' on start-up if new
+       items are present in the BBoard.  This feature is  best  used  from
+       _b_b_c,  which  correctly sets the stage.  Second, the _m_a_r_k command in
+       _m_s_h acts specially when you are reading a BBoard,  since  _m_s_h  will
+       consult the sequence "unseen" in determining what messages you have
+       actually read.  When _m_s_h exits, it reports this information to _b_b_c.
+       In  addition,  if  you give the _m_a_r_k command with no arguments, _m_s_h
+       will interpret  it  as  `mark -sequence unseen -delete -nozero all'
+       Hence,  to discard all of the messages in the current BBoard you're
+       reading, just use the _m_a_r_k command with no arguments.
+
+       Normally, the "exit" command is identical to the "quit" command  in
+       _m_s_h.   When  run  under _b_b_c however, "exit" directs _m_s_h to mark all
+       messages as seen and then "quit".  For speedy type-in, this command
+       is often abbreviated as just "e".
+
+       When invoked from _v_m_h, another  special  feature  is  enabled:  The
+       `topcur' switch directs _m_s_h to have the current message "track" the
+       top line of the _v_m_h scan window.  Normally,  _m_s_h  has  the  current
+       message  "track" the center of the window (under `-notopcur', which
+       is the default).
+
+       _m_s_h supports an output redirection facility.  Commands may be  fol-
+       lowed by one of
+
+            > _f_i_l_e     write output to _f_i_l_e
+            >> _f_i_l_e    append output to _f_i_l_e
+            | _c_o_m_m_a_n_d  pipe output to UNIX _c_o_m_m_a_n_d
+
+       If _f_i_l_e starts with a `~' (tilde), then a _c_s_h-like expansion  takes
+       place.  Note that _c_o_m_m_a_n_d is interpreted by _s_h (1).  Also note that
+       _m_s_h does NOT support history substitutions, variable substitutions,
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSH(1)                            -61-                            MSH(1)
+
+
+       or alias substitutions.
+
+       When parsing commands to the left of any  redirection  symbol,  _m_s_h
+       will honor `\' (back-slash) as the quote next-character symbol, and
+       `"' (double-quote)  as  quote-word  delimiters.   All  other  input
+       tokens are separated by whitespace (spaces and tabs).
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /usr/local/lib/mh/mtstailor         tailor file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Msg-Protect:         To set mode when creating a new `file'
+       fileproc:            Program to file messages
+       showproc:            Program to show messages
+
+
+  _S_e_e _A_l_s_o
+       bbc(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `file' defaults to "./msgbox"
+       `-prompt (msh) '
+       `-noscan'
+       `-notopcur'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MSH(1)                            -62-                            MSH(1)
+
+
+  _B_u_g_s
+       The argument to the `-prompt' switch must be interpreted as a  sin-
+       gle  token by the shell that invokes _m_s_h.  Therefore, one must usu-
+       ally place the argument to this switch inside double-quotes.
+
+       There is a strict limit of messages  per  file  in  _p_a_c_k_f'd  format
+       which _m_s_h can handle.  Usually, this limit is 1000 messages.
+
+       Please remember that _m_s_h is not the _C_S_h_e_l_l, and that a lot  of  the
+       nice facilities provided by the latter are not present in the form-
+       er.
+
+       In particular, _m_s_h does not understand back-quoting,  so  the  only
+       effective  way  to  use  _p_i_c_k  inside  _m_s_h  is  to  always  use the
+       `-seq select' switch.  Clever users of _M_H will put the line
+
+            pick: -seq select -list
+
+       in their .mh_profile file so that _p_i_c_k works equally well from both
+       the shell and _m_s_h.
+
+       _s_o_r_t_m always uses "-noverbose" and if "-textfield field"  is  used,
+       "-limit 0".
+
+       The _m_s_h program inherits most (if not all) of the bugs from the  _M_H
+       commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  NEXT(1)                           -63-                           NEXT(1)
+
+
+  _N_A_M_E
+       next - show the next message
+
+  _S_Y_N_O_P_S_I_S
+       next [+folder] [-header] [-noheader] [-showproc program]
+            [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _N_e_x_t performs a _s_h_o_w on the  next  message  in  the  specified  (or
+       current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+       gram _s_h_o_w_p_r_o_c, which is called to list the message.   This  command
+       is  almost  exactly  equivalent to "show next".  Consult the manual
+       entry for _s_h_o_w (1) for all the details.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       showproc:            Program to show the message
+
+
+  _S_e_e _A_l_s_o
+       show(1), prev(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `-header'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is specified, it will become the current  folder.   The
+       message that is shown (i.e., the next message in sequence) will be-
+       come the current message.
+
+
+  _B_u_g_s
+       _n_e_x_t is really a link to the _s_h_o_w program.  As  a  result,  if  you
+       make  a  link  to  _n_e_x_t and that link is not called _n_e_x_t, your link
+       will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+       profile-entry  for the link to your _M_H profile and add the argument
+       _n_e_x_t to the entry.
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PACKF(1)                          -64-                          PACKF(1)
+
+
+  _N_A_M_E
+       packf - compress a folder into a single file
+
+  _S_Y_N_O_P_S_I_S
+       packf [+folder] [msgs] [-file name] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _P_a_c_k_f takes messages from a folder and  copies  them  to  a  single
+       file.  Each message in the file is separated by four CTRL-A's and a
+       newline (identical to the way messages are stored in your receiving
+       mail drop).  Messages packed can be unpacked using _i_n_c.
+
+       If the _n_a_m_e given to the `-file name' switch exists, then the  mes-
+       sages  specified will be appended to the end of the file, otherwise
+       the file will be created and the messages appended.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Msg-Protect:         To set mode when creating a new `file'
+
+
+  _S_e_e _A_l_s_o
+       inc(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to all
+       `-file ./msgbox'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The first
+       message packed will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PICK(1)                           -65-                           PICK(1)
+
+
+  _N_A_M_E
+       pick - select messages by content
+
+  _S_Y_N_O_P_S_I_S
+       pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+            [-lbrace ... -rbrace] [--component pattern] [-after date]
+            [-before date] [-datefield field] [-sequence name ...]
+            [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+            [-help]
+
+       typically:
+            scan `pick -from jones`
+            pick -to holloway -sequence select
+            show `pick -before friday`
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _P_i_c_k searches messages within a folder for the specified  contents,
+       and then identifies those messages.  Two types of search primitives
+       are available: pattern matching and date constraint operations.
+
+       A modified _g_r_e_p(1) is used to perform the  matching,  so  the  full
+       regular  expression  (see _e_d(1)) facility is available within `pat-
+       tern'.  With `-search', `pattern' is used directly,  and  with  the
+       others, the grep pattern constructed is:
+
+            "component[ \t]*:.*pattern"
+
+       This means that the pattern specified for a `-search' will be found
+       everywhere in the message, including the header and the body, while
+       the other pattern matching  requests  are  limited  to  the  single
+       specified component.  The expression
+
+            `--component pattern'
+
+       is a shorthand for specifying
+
+            `-search "component[ \t]*:.*pattern" '
+
+       It is used to pick a component which is not one  of  "To:",  "cc:",
+       "Date:",     "From:",     or    "Subject:".     An    example    is
+       `pick --reply-to pooh'.
+
+       Pattern matching is performed on  a  per-line  basis.   Within  the
+       header  of the message, each component is treated as one long line,
+       but in the body, each line is separate.  Lower-case letters in  the
+       search  pattern  will  match either lower or upper case in the mes-
+       sage, while upper case will match only upper case.
+
+       Note that since the `-date' switch is a pattern matching  operation
+       (as  described  above), to find messages sent on a certain date the
+       pattern string must match the text of  the  "Date:"  field  of  the
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PICK(1)                           -66-                           PICK(1)
+
+
+       message.
+
+       Independent of  any  pattern  matching  operations  requested,  the
+       switches `-after date' or `-before date' may also be used to intro-
+       duce date/time contraints on all of the messages.  By default,  the
+       "Date:"  field  is  consulted,  but  if another date yielding field
+       (such as "BB-Posted:" or  "Delivery-Date:")  should  be  used,  the
+       `-datefield field' switch may be used.
+
+       With `-before' and `-after', _p_i_c_k  will  actually  parse  the  date
+       fields in each of the messages specified in `msgs' and compare them
+       to the date/time specified.  If `-after' is given, then only  those
+       messages  whose  "Date:"  field  value is chronologically after the
+       date specified will be considered.  The `-before' switch  specifies
+       the complimentary action.
+
+       Both the `-after' and `-before' switches take legal 822-style  date
+       specifications  as  arguments.   _P_i_c_k  will default certain missing
+       fields so that the entire date need not be specified.  These fields
+       are  (in  order  of defaulting): timezone, time and timezone, date,
+       date and timezone.  All defaults are taken from the  current  date,
+       time, and timezone.
+
+       In addition to 822-style dates, _p_i_c_k will also recognize any of the
+       days  of  the week ("sunday", "monday", and so on), and the special
+       dates "today", "yesterday" (24 hours ago), and "tomorrow" (24 hours
+       from  now).   All  days of the week are judged to refer to a day in
+       the past (e.g.,  telling  _p_i_c_k  "saturday"  on  a  "tuesday"  means
+       "last saturday" not "this saturday").
+
+       Finally, in addition to these  special  specifications,  _p_i_c_k  will
+       also  honor a specification of the form "-dd", which means "dd days
+       ago".
+
+       _P_i_c_k supports complex boolean operations on  the  searching  primi-
+       tives  with  the  `-and',  `-or', `-not', and `-lbrace ... -rbrace'
+       switches.  For example,
+
+            pick -after yesterday -and -lbrace -from freida -or -from fear -rbrace
+
+       identifies messages recently sent by "frieda" or "fear".
+
+       The matching primitives take precedence  over  the  `-not'  switch,
+       which in turn takes precedence over `-and' which in turn takes pre-
+       cedence over  `-or'.   To  override  the  default  precedence,  the
+       `-lbrace'  and `-rbrace' switches are provided, which act just like
+       opening and closing parentheses in logical expressions.
+
+       Once the search has been performed, if the `-list' switch is given,
+       the  message  numbers  of  the selected messages are written to the
+       standard output separated by newlines.  This  is  _e_x_t_r_e_m_e_l_y  useful
+       for quickly generating arguments for other _M_H programs by using the
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PICK(1)                           -67-                           PICK(1)
+
+
+       "backquoting" syntax of the shell.  For example, the command
+
+            scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+       says to _s_c_a_n those messages in the indicated folder which meet  the
+       appropriate criterion.  Note that since _p_i_c_k 's context changes are
+       written out prior to _s_c_a_n 's invocation,  you  need  not  give  the
+       folder argument to _s_c_a_n as well.
+
+       Regardless of the operation of the `-list' switch,  the  `-sequence
+       name' switch may be given once for each sequence the user wishes to
+       define.  For each sequence named, that sequence will be defined  to
+       mean exactly those messages selected by _p_i_c_k.  For example,
+
+            pick -from frated -seq fred
+
+       defines a new message sequence for the current folder called "fred"
+       which contains exactly those messages that were selected.
+
+       Note that whenever _p_i_c_k processes  a  `-sequence name'  switch,  it
+       sets `-nolist'.
+
+       By default, _p_i_c_k will zero the sequence  before  adding  it.   This
+       action  can be disabled with the `-nozero' switch, which means that
+       the messages selected by _p_i_c_k will be added to the sequence, if  it
+       already  exists,  and  any messages already a part of that sequence
+       will remain so.
+
+       The `-public' and `-nopublic' switches are used by _p_i_c_k in the same
+       way _m_a_r_k uses them.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       mark(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to all
+       `-datefield date'
+       `-nopublic' if the folder is read-only, `-public' otherwise
+       `-zero'
+       `-list' is the default if no `-sequence', `-nolist' otherwise
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PICK(1)                           -68-                           PICK(1)
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.
+
+
+  _H_i_s_t_o_r_y
+       In previous versions of _M_H, the _p_i_c_k command would _s_h_o_w,  _s_c_a_n,  or
+       _r_e_f_i_l_e  the  selected  messages.   This was rather "inverted logic"
+       from the UNIX point of view, so _p_i_c_k  was  changed  to  define  se-
+       quences  and  output  those  sequences.  Hence, _p_i_c_k can be used to
+       generate the arguments for all other _M_H commands, instead of giving
+       _p_i_c_k endless switches for invoking those commands itself.
+
+       Also, previous versions of _p_i_c_k balked  if  you  didn't  specify  a
+       search  string or a date/time constraint.  The current version does
+       not, and merely matches the messages you specify.   This  lets  you
+       type something like:
+
+            show `pick last:20 -seq fear`
+
+       instead of typing
+
+            mark -add -nozero -seq fear last:20
+            show fear
+
+       Finally, timezones used to be ignored when  comparing  dates:  they
+       aren't any more.
+
+
+  _B_u_g_s
+       The argument to the `-after' and `-before' switches must be  inter-
+       preted  as  a  single token by the shell that invokes _p_i_c_k.  There-
+       fore, one must usually place the argument  to  this  switch  inside
+       double-quotes.  Furthermore, any occurance of `-datefield' must oc-
+       cur prior to the `-after' or `-before' switch it applies to.
+
+       If _p_i_c_k is used in a back-quoted operation, such as
+
+            scan `pick -from jones`
+
+       and _p_i_c_k fails (e.g., no messages are from "jones"), then the shell
+       will still run the outer command (e.g., "scan").  Since no messages
+       were matched, _p_i_c_k produced no output, and the  argument  given  to
+       the outer command as a result of backquoting _p_i_c_k is empty.  In the
+       case of _M_H programs, the outer command now acts as if  the  default
+       `msg'  or `msgs' should be used (e.g., "all" in the case of _s_c_a_n ).
+       To prevent this unexpected behavior, if `-list' was given,  and  if
+       its  standard  output  is  not a tty, then _p_i_c_k outputs the illegal
+       message number "0" when it fails.  This lets the outer command fail
+       gracefully as well.
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PREV(1)                           -69-                           PREV(1)
+
+
+  _N_A_M_E
+       prev - show the previous message
+
+  _S_Y_N_O_P_S_I_S
+       prev [+folder] [-header] [-noheader] [-showproc program]
+            [-noshowproc] [-switches for _s_h_o_w_p_r_o_c] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _P_r_e_v performs a _s_h_o_w on the previous message in the  specified  (or
+       current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+       gram named by _s_h_o_w_p_r_o_c, which is called to list the message.   This
+       command  is  almost exactly equivalent to "show prev".  Consult the
+       manual entry for _s_h_o_w (1) for all the details.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       showproc:            Program to show the message
+
+
+  _S_e_e _A_l_s_o
+       show(1), next(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `-header'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is specified, it will become the current  folder.   The
+       message that is shown (i.e., the previous message in sequence) will
+       become the current message.
+
+
+  _B_u_g_s
+       _p_r_e_v is really a link to the _s_h_o_w program.  As  a  result,  if  you
+       make  a  link  to  _p_r_e_v and that link is not called _p_r_e_v, your link
+       will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+       profile-entry  for the link to your _M_H profile and add the argument
+       _p_r_e_v to the entry.
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PROMPTER(1)                       -70-                       PROMPTER(1)
+
+
+  _N_A_M_E
+       prompter - prompting editor front-end
+
+  _S_Y_N_O_P_S_I_S
+       prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+            [-norapid] [-doteof] [-nodoteof] file [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       This program is normally not invoked directly by  users  but  takes
+       the  place  of  an  editor  and  acts  as  an editor front-end.  It
+       operates on an 822-style message draft skeleton specified by  file,
+       normally provided by _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l.
+
+       _P_r_o_m_p_t_e_r is an editor which allows rapid composition  of  messages.
+       It  is particularly useful to network and low-speed (less than 2400
+       baud) users of _M_H.  It is an _M_H program in that it can have its own
+       profile  entry with switches, but it is not invoked directly by the
+       user.  The commands _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l invoke  _p_r_o_m_p_t_e_r  as
+       an  editor,  either when invoked with `-editor prompter', or by the
+       profile  entry  "Editor: prompter",  or  when  given  the   command
+       `edit prompter' at "What now?" level.
+
+       For each empty component _p_r_o_m_p_t_e_r finds in the draft, the  user  is
+       prompted  for a response; A <RETURN> will cause the whole component
+       to be left out.  Otherwise, a `\' preceding a  <RETURN>  will  con-
+       tinue  the  response  on the next line, allowing for multiline com-
+       ponents.  Continuation lines must begin with a space or tab.
+
+       Each non-empty component is copied to the draft  and  displayed  on
+       the terminal.
+
+       The start of the message body is denoted by a blank line or a  line
+       of dashes.  If the body is non-empty, the prompt, which isn't writ-
+       ten to the file, is
+
+           "--------Enter additional text",
+
+       or (if `-prepend' was given)
+
+           "--------Enter initial text".
+
+       Message-body typing is  terminated  with  an  end-of-file  (usually
+       CTRL-D).   With  the  `-doteof'  switch,  a period on a line all by
+       itself also  signifies  end-of-file.   At  this  point  control  is
+       returned  to  the  calling  program,  where the user is asked "What
+       now?".  See _w_h_a_t_n_o_w for the valid options to this query.
+
+       By using the `-prepend' switch, the user can  add  type-in  to  the
+       beginning of the message body and have the rest of the body follow.
+       This is useful for the _f_o_r_w command.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PROMPTER(1)                       -71-                       PROMPTER(1)
+
+
+       By using the `-rapid' switch, if the draft already contains text in
+       the message-body, it is not displayed on the user's terminal.  This
+       is useful for low-speed terminals.
+
+       The line editing characters for kill and erase may be specified  by
+       the  user via the arguments `-kill chr' and `-erase chr', where chr
+       may be a character; or `\nnn', where "nnn" is the octal  value  for
+       the character.
+
+       An interrupt (usually CTRL-C) during component  typing  will  abort
+       _p_r_o_m_p_t_e_r  and  the _M_H command that invoked it.  An interrupt during
+       message-body typing is equivalent to CTRL-D,  for  historical  rea-
+       sons.  This means that _p_r_o_m_p_t_e_r should finish up and exit.
+
+       The first non-flag argument to _p_r_o_m_p_t_e_r is taken as the name of the
+       draft file, and subsequent non-flag arguments are ignored.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /tmp/prompter*                      Temporary copy of message
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       prompter-next:       To name the editor to be  used  on  exit  from
+       _p_r_o_m_p_t_e_r
+       Msg-Protect:         To set mode when creating a new draft
+
+
+  _S_e_e _A_l_s_o
+       comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-prepend'
+       `-norapid'
+       `-nodoteof'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+  _H_e_l_p_f_u_l _H_i_n_t_s
+
+       The  `-rapid'  option  is  particularly  useful  with   _f_o_r_w,   and
+       `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+       The user may wish to link _p_r_o_m_p_t_e_r under several names (e.g.,  "ra-
+       pid")  and  give  appropriate switches in the profile entries under
+       these names (e.g., "rapid:  -rapid").   This  facilitates  invoking
+       prompter  differently for different _M_H commands (e.g., "forw: -edi-
+       tor rapid").
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  PROMPTER(1)                       -72-                       PROMPTER(1)
+
+
+  _B_u_g_s
+       _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will lose if  you  edit  files  with
+       nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RCVSTORE(1)                       -73-                       RCVSTORE(1)
+
+
+  _N_A_M_E
+       rcvstore - incorporate new mail asynchronously
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+            [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+            [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_c_v_s_t_o_r_e incorporates a message from the standard input into an  _M_H
+       folder.   If `+folder' isn't specified, the folder named "inbox" in
+       the user's _M_H directory will be  used  instead.   The  new  message
+       being  incorporated  is  assigned  the  next  highest number in the
+       folder.  If the specified (or default) folder doesn't  exist,  then
+       it  will be created if the `-create' option is specified, otherwise
+       _r_c_v_s_t_o_r_e will exit.
+
+       If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+       be  used as the protection on the newly created messages, otherwise
+       the _M_H default of 0644 will be used.  During all operations on mes-
+       sages,  this  initially  assigned  protection will be preserved for
+       each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+       individual   message,   and   its   protection  will  be  preserved
+       thereafter.
+
+       _R_c_v_s_t_o_r_e will incorporate anything except zero length messages into
+       the user's MH folder.
+
+       If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+       then  _r_c_v_s_t_o_r_e  will  add  the  newly  incorporated message to each
+       sequence named by the  profile  entry.   This  is  similar  to  the
+       "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+       which take `msgs' or `msg' arguments.  Note that _r_c_v_s_t_o_r_e will  not
+       zero each sequence prior to adding messages.
+
+       Furthermore, the incoming messages may  be  added  to  user-defined
+       sequences  as  they  arrive  by  appropriate use of the `-sequence'
+       option.  As with _p_i_c_k, use of the `-zero'  and  `-nozero'  switches
+       can  also  be used to zero old sequences or not.  Similarly, use of
+       the `-public' and `-nopublic switches may be used  to  force  addi-
+       tions to public and private sequences.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RCVSTORE(1)                       -74-                       RCVSTORE(1)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Folder-Protect:      To set mode when creating a new folder
+       Msg-Protect:         To set mode when creating a new message
+       Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+  _S_e_e _A_l_s_o
+       inc(1), pick(1), mh-mail(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to "inbox"
+       `-create'
+       `-nopublic' if the folder is read-only, `-public' otherwise
+       `-nozero'
+
+
+  _C_o_n_t_e_x_t
+       No context changes will be attempted, with  the  exception  of  se-
+       quence manipulation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REFILE(1)                         -75-                         REFILE(1)
+
+
+  _N_A_M_E
+       refile - file message in other folders
+
+  _S_Y_N_O_P_S_I_S
+       refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+            [-src +folder] [-file file] [-rmmproc program] [-normmproc]
+            +folder ...  [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_e_f_i_l_e moves (_m_v (1)) or links  (_l_n (1))  messages  from  a  source
+       folder  into  one  or  more destination folders.  If you think of a
+       message as a sheet of paper, this operation is  not  unlike  filing
+       the  sheet  of  paper  (or copies) in file cabinet folders.  When a
+       message is filed, it is linked into the  destination  folder(s)  if
+       possible,  and  is  copied  otherwise.   As long as the destination
+       folders are all on the same file  system,  multiple  filing  causes
+       little  storage  overhead.   This  facility  provides a good way to
+       cross-file or multiply-index messages.  For example, if  a  message
+       is received from Jones about the ARPA Map Project, the command
+
+            refile cur +jones +Map
+
+       would allow the message to be found in either of  the  two  folders
+       `jones' or `Map'.
+
+       The option `-file file' directs _r_e_f_i_l_e to use the specified file as
+       the  source  message  to  be  filed,  rather  than a message from a
+       folder.  Note that the file should be a validly formatted  message,
+       just like any other _M_H message.  It should NOT be in mail drop for-
+       mat (to convert a file in mail drop format to a folder of  _M_H  mes-
+       sages, see _i_n_c (1)).
+
+       If a destination folder doesn't exist, _r_e_f_i_l_e will ask if you  want
+       to create it.  A negative response will abort the file operation.
+
+       The option `-link' preserves the source folder copy of the  message
+       (i.e.,  it  does  a  _l_n(1) rather than a _m_v(1)), whereas, `-nolink'
+       deletes the filed messages from the source folder.  Normally,  when
+       a  message  is filed, it is assigned the next highest number avail-
+       able in each of the destination folders.  Use  of  the  `-preserve'
+       switch  will override this message renaming, but name conflicts may
+       occur, so use this switch cautiously.
+
+       If `-link' is not specified (or `-nolink' is specified), the  filed
+       messages  will  be removed from the source folder, by renaming them
+       with a site-dependent prefix (usually a comma).
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REFILE(1)                         -76-                         REFILE(1)
+
+
+       If the user has a profile component such as
+
+               rmmproc:        /bin/rm
+
+       then _r_e_f_i_l_e will instead call the named program to delete the  mes-
+       sage files.  The user may specify `-rmmproc program' on the command
+       line to override  this  profile  specification.   The  `-normmproc'
+       option  forces  the message files to be deleted by renaming them as
+       described above.
+
+       The `-draft' switch tells _r_e_f_i_l_e to file the <mh-dir>/draft.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Folder-Protect:      To set mode when creating a new folder
+       rmmproc:             Program to delete the message
+
+
+  _S_e_e _A_l_s_o
+       folder(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-src +folder' defaults to the current folder
+       `msgs' defaults to cur
+       `-nolink'
+       `-nopreserve'
+
+
+  _C_o_n_t_e_x_t
+       If `-src +folder' is given, it will become the current folder.   If
+       neither  `-link' nor `all' is specified, the current message in the
+       source folder will be set to the last message specified; otherwise,
+       the current message won't be changed.
+
+       If the Previous-Sequence profile entry is set, in addition  to  de-
+       fining the named sequences from the source folder, _r_e_f_i_l_e will also
+       define  those  sequences  for   the   destination   folders.    See
+       _m_h-_p_r_o_f_i_l_e (1) for information concerning the previous sequence.
+
+
+  _B_u_g_s
+       Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+       must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+       create an infinte loop.
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REPL(1)                           -77-                           REPL(1)
+
+
+  _N_A_M_E
+       repl - reply to a message
+
+  _S_Y_N_O_P_S_I_S
+       repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+            [-nocc all/to/cc/me] [-draftfolder +folder]
+            [-draftmessage msg] [-nodraftfolder] [-editor editor]
+            [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+            [-inplace] [-noinplace] [-query] [-noquery] [-width columns]
+            [-whatnowproc program] [-nowhatnowproc] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_e_p_l aids a user in producing a reply to an existing message.  _R_e_p_l
+       uses  a  reply  template to guide its actions when constructing the
+       message draft of the reply.  In its simplest form  (with  no  argu-
+       ments),  it  will  set  up  a message-form skeleton in reply to the
+       current message in the  current  folder,  and  invoke  the  whatnow
+       shell.   The  default  reply template will direct _r_e_p_l to construct
+       the composed message as follows:
+
+            To: <Reply-To> or <From>
+            cc: <cc>, <To>, and yourself
+            Subject: Re: <Subject>
+            In-reply-to: Your message of <Date>.
+                         <Message-Id>
+
+       where field names enclosed in angle  brackets  (< >)  indicate  the
+       contents  of the named field from the message to which the reply is
+       being made.  A  reply  template  is  simply  a  format  file.   See
+       _m_h-_f_o_r_m_a_t (5) for the details.
+
+       The `-cc type' switch takes an argument which  specifies  who  gets
+       placed  on  the "cc:" list of the reply.  The `-query' switch modi-
+       fies the action of `-cc type' switch by interactively asking you if
+       each  address  that normally would be placed in the "To:" and "cc:"
+       list  should  actually  be  sent  a  copy.   (This  is  useful  for
+       special-purpose  replies.)  Note that the position of the `-cc' and
+       `-nocc' switches, like all other switches which take a positive and
+       negative form, is important.
+
+       Lines beginning with the fields "To:", "cc:", and  "Bcc:"  will  be
+       standardized  and  have  duplicate addresses removed.  In addition,
+       the `-width columns' switch will guide _r_e_p_l's formatting  of  these
+       fields.
+
+       If the file named "replcomps" exists in the user's MH directory, it
+       will be used instead of the default form.  In either case, the file
+       specified by `-form formfile' will be used if given.
+
+       If the draft already exists, _r_e_p_l will ask you as to  the  disposi-
+       tion  of  the  draft.  A reply of quit will abort _r_e_p_l, leaving the
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REPL(1)                           -78-                           REPL(1)
+
+
+       draft intact; replace will replace the existing draft with a  blank
+       skeleton; and list will display the draft.
+
+       See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+       switches.  Note that while in the editor, the message being replied
+       to is available through a link  named  "@"  (assuming  the  default
+       _w_h_a_t_n_o_w_p_r_o_c ).   In addition, the actual pathname of the message is
+       stored in the envariable $editalt, and the pathname of  the  folder
+       containing the message is stored in the envariable $mhfolder.
+
+       Although _r_e_p_l uses the `-form formfile' switch to direct it how  to
+       construct  the  beginning  of  the  draft, the `-filter filterfile'
+       switch directs _r_e_p_l as to how the message being  replied-to  should
+       be  formatted in the body of the draft.  If `-filter' is not speci-
+       fied, then the message being replied-to is not included in the body
+       of  the draft.  If `-filter filterfile' is specified, then the mes-
+       sage being replied-to is filtered  (re-formatted)  prior  to  being
+       output  to  the body of the draft.  The filter file for _r_e_p_l should
+       be a standard form file for _m_h_l, as _r_e_p_l will invoke _m_h_l to  format
+       the  message  being replied-to.  There is no default message filter
+       (`-filter' must be followed by a file name).  A filter file that is
+       commonly used is:
+
+            :
+            body:nocomponent,compwidth=9,offset=9
+
+       which says to output a blank line and then the body of the  message
+       being replied-to, indented by one tab-stop.  Another format popular
+       on USENET is:
+
+            message-id:nocomponent,formatfield=\
+            "In message %{text}you write:"
+            body:component=">",overflowtext=">",overflowoffset=0
+
+       Which cites the Message-ID of the  message  being  replied-to,  and
+       then outputs each line of the body prefaced with the ">" character.
+
+       If the `-annotate' switch is given, the  message  being  replied-to
+       will be annotated with the lines
+
+            Replied: date
+            Replied: addrs
+
+       where the address list contains one line for each  addressee.   The
+       annotation  will  be done only if the message is sent directly from
+       _r_e_p_l.   If  the  message  is  not  sent  immediately   from   _r_e_p_l,
+       "comp -use"  may  be  used to re-edit and send the constructed mes-
+       sage, but the annotations won't take place.  The `-inplace'  switch
+       causes annotation to be done in place in order to preserve links to
+       the annotated message.
+
+       The `-fcc +folder' switch can be used to  automatically  specify  a
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REPL(1)                           -79-                           REPL(1)
+
+
+       folder  to  receive Fcc:s.  More than one folder, each preceeded by
+       `-fcc' can be named.
+
+       In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _r_e_p_l also recog-
+       nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+       _f_c_c     string   Any folders specified with `-fcc folder'
+
+       To avoid reiteration, _r_e_p_l strips any leading `Re: '  strings  from
+       the _s_u_b_j_e_c_t component.
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       Upon exiting from the editor, _r_e_p_l will invoke the _w_h_a_t_n_o_w program.
+       See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+       tion of this program can be inhibited by using the `-nowhatnowproc'
+       switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+       the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+       from occurring.)
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/replcomps         The reply template
+       or <mh-dir>/replcomps               Rather than the standard template
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/draft                      The draft file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Alternate-Mailboxes: To determine the user's mailboxes
+       Current-Folder:      To find the default current folder
+       Draft-Folder:        To find the default draft-folder
+       Editor:              To override the default editor
+       Msg-Protect:         To  set  mode  when  creating  a  new  message
+       (draft)
+       fileproc:            Program to refile the message
+       mhlproc:             Program to filter message being replied-to
+       whatnowproc:         Program to ask the "What now?" questions
+
+
+  _S_e_e _A_l_s_o
+       comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  REPL(1)                           -80-                           REPL(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msg' defaults to cur
+       `-nocc all' at ATHENA sites, `-cc all' otherwise
+       `-noannotate'
+       `-nodraftfolder'
+       `-noinplace'
+       `-noquery'
+       `-width 72'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The  mes-
+       sage replied-to will become the current message.
+
+
+  _H_i_s_t_o_r_y
+       Prior to using the format string  mechanism,  `-noformat'  used  to
+       cause  address  headers to be output as-is.  Now all address fields
+       are formatted using Internet standard guidelines.
+
+
+  _B_u_g_s
+       If any addresses occur in the reply template, addresses in the tem-
+       plate that do not contain hosts are defaulted incorrectly.  Instead
+       of using the localhost for the  default,  _r_e_p_l  uses  the  sender's
+       host.   Moral of the story: if you're going to include addresses in
+       a reply template, include the host portion of the address.
+
+       The `-width columns' switch is only  used  to  do  address-folding;
+       other headers are not line-wrapped.
+
+       If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _r_e_p_l uses a  built-in  _w_h_a_t_n_o_w,  it
+       does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+       your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _r_e_p_l  won't  run
+       it.
+
+       If your current working directory is not writable, the  link  named
+       "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RMF(1)                            -81-                            RMF(1)
+
+
+  _N_A_M_E
+       rmf - remove folder
+
+  _S_Y_N_O_P_S_I_S
+       rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_m_f removes all of the messages (files) within  the  specified  (or
+       default)  folder,  and  then removes the folder (directory) itself.
+       If there are any files within the folder which are not  a  part  of
+       _M_H,  they  will  _n_o_t be removed, and an error will be produced.  If
+       the folder is given explicitly or the  `-nointeractive'  option  is
+       given,  then the folder will be removed without confirmation.  Oth-
+       erwise, the user will be asked for confirmation.  If _r_m_f can't find
+       the  current  folder,  for  some  reason,  the folder to be removed
+       defaults to `+inbox' with confirmation.
+
+       _R_m_f irreversibly deletes messages that don't have other  links,  so
+       use it with caution.
+
+       If the folder being removed is a subfolder, the parent folder  will
+       become  the new current folder, and _r_m_f will produce a message tel-
+       ling the user this has happened.  This provides an  easy  mechanism
+       for selecting a set of messages, operating on the list, then remov-
+       ing the list and returning to the current  folder  from  which  the
+       list was extracted.
+
+       _R_m_f of a read-only folder will delete the private sequence and  cur
+       information  (i.e.,  "atr-_s_e_q-_f_o_l_d_e_r"  entries)  from  the  profile
+       without affecting the folder itself.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       rmm(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder, usually with confirmation
+       `-interactive' if +folder' not given, `-nointeractive' otherwise
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RMF(1)                            -82-                            RMF(1)
+
+
+  _C_o_n_t_e_x_t
+       _R_m_f will set the current folder to the parent folder if a subfolder
+       is  removed; or if the current folder is removed, it will make "in-
+       box" current.  Otherwise, it doesn't change the current  folder  or
+       message.
+
+
+  _B_u_g_s
+       Although intuitively one would suspect that _r_m_f works  recursively,
+       it  does  not.   Hence if you have a sub-folder within a folder, in
+       order to _r_m_f the parent, you must first _r_m_f each of the children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RMM(1)                            -83-                            RMM(1)
+
+
+  _N_A_M_E
+       rmm - remove messages
+
+  _S_Y_N_O_P_S_I_S
+       rmm [+folder] [msgs] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _R_m_m removes the specified messages by renaming  the  message  files
+       with preceding commas.  Many sites consider files that start with a
+       comma to be a temporary backup, and arrange for _c_r_o_n (8) to  remove
+       such files once a day.
+
+       If the user has a profile component such as
+
+               rmmproc:        /bin/rm
+
+       then instead of simply renaming the message file, _r_m_m will call the
+       named program to delete the file.  Note that at most installations,
+       _c_r_o_n (8) is told to remove files that begin with  a  comma  once  a
+       night.
+
+       Some users of csh prefer the following:
+
+               alias rmm 'refile +d'
+
+       where folder +d is a folder for deleted messages, and
+
+               alias mexp 'rm `mhpath +d all`'
+
+       is used to "expunge" deleted messages.
+
+       The current message is not changed by _r_m_m, so a _n_e_x_t  will  advance
+       to the next message in the folder as expected.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       rmmproc:             Program to delete the message
+
+
+  _S_e_e _A_l_s_o
+       rmf(1)
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  RMM(1)                            -84-                            RMM(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to cur
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.
+
+  _H_e_l_p_f_u_l _H_i_n_t_s
+
+       If you're not a csh user, and you  have  an  _r_m_m_p_r_o_c  script  which
+       _r_e_f_i_l_es messages, be sure you use something like:
+
+            mv `mhpath msgs` `mhpath new +folder`
+
+       Other work-arounds are possible, such as:
+
+            cd `mhpath +`
+            MH=/dev/null MHCONTEXT=/dev/null refile $* +folder
+
+
+  _B_u_g_s
+       Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+       must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+       create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SCAN(1)                           -85-                           SCAN(1)
+
+
+  _N_A_M_E
+       scan - produce a one line per message scan listing
+
+  _S_Y_N_O_P_S_I_S
+       scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+            [-format string] [-header] [-noheader] [-width columns]
+            [-reverse] [-noreverse] [-file filename] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _S_c_a_n produces a one-line-per-message listing of the specified  mes-
+       sages.   Each  _s_c_a_n  line  contains  the message number (name), the
+       date, the "From:" field, the "Subject" field, and, if room  allows,
+       some of the body of the message.  For example:
+
+            15+  7/ 5  Dcrocker  nned  <<Last week I asked some of
+            16 - 7/ 5  dcrocker  message id format  <<I recommend
+            18   7/ 6  Obrien    Re: Exit status from mkdir
+            19   7/ 7  Obrien    "scan" listing format in MH
+
+       The `+' on message 15 indicates that it  is  the  current  message.
+       The  `-'  on  message  16 indicates that it has been replied to, as
+       indicated by a "Replied:"  component  produced  by  an  `-annotate'
+       switch to the _r_e_p_l command.
+
+       If there is sufficient room left on the _s_c_a_n line  after  the  sub-
+       ject,  the line will be filled with text from the body, preceded by
+       <<, and terminated by >> if the body is sufficiently  short.   _S_c_a_n
+       actually  reads  each  of the specified messages and parses them to
+       extract the desired fields.  During parsing, appropriate error mes-
+       sages  will  be  produced  if there are format errors in any of the
+       messages.
+
+       The `-header' switch produces a header line prior to the _s_c_a_n list-
+       ing.   Currently,  the  name of the folder and the current date and
+       time are output (see the HISTORY section for more information).
+
+       If the `-clear' switch is used and _s_c_a_n'_s output is directed  to  a
+       terminal, then _s_c_a_n will consult the $TERM and $TERMCAP envariables
+       to determine your terminal type in order to find out how  to  clear
+       the  screen  prior  to exiting.  If the `-clear' switch is used and
+       _s_c_a_n'_s output is not directed to a terminal  (e.g.,  a  pipe  or  a
+       file), then _s_c_a_n will send a formfeed prior to exiting.
+
+       For example, the command:
+
+            (scan -clear -header; show all -show pr -f) | lpr
+
+       produces a scan listing  of  the  current  folder,  followed  by  a
+       formfeed,  followed  by  a formatted listing of all messages in the
+       folder, one per page.  Omitting `-show pr -f' will cause  the  mes-
+       sages  to  be  concatenated, separated by a one-line header and two
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SCAN(1)                           -86-                           SCAN(1)
+
+
+       blank lines.
+
+       If _s_c_a_n encounters a message without a "Date:" field,  rather  than
+       leaving  that  portion  of  the  scan  listing  blank,  the date is
+       filled-in with the last write date of the message,  and  post-fixed
+       with  a  `*'.   This  is  particularly  handy  for scanning a _d_r_a_f_t
+       _f_o_l_d_e_r, as message drafts usually aren't allowed to have  dates  in
+       them.
+
+       To override the output format used by _s_c_a_n, the `-format string' or
+       `-format file'  switches  are used.  This permits individual fields
+       of the scan listing to be extracted with ease.  The string is  sim-
+       ply  a  format  string  and  the file is simply a format file.  See
+       _m_h-_f_o_r_m_a_t (5) for the details.
+
+       In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _s_c_a_n also recog-
+       nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+       body    string   the (compressed) first part of the body
+
+       Also, if no date header was present in the  message,  the  _f_u_n_c_t_i_o_n
+       escapes  which operate on {_d_a_t_e} will return values for the date of
+       last modification of the message file itself.
+
+
+       _s_c_a_n will update the _M_H context prior to starting the  listing,  so
+       interrupting  a  long  _s_c_a_n  listing preserves the new context.  _M_H
+       purists hate this idea.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Alternate-Mailboxes: To determine the user's mailboxes
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       inc(1), pick(1), show(1), mh-format(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the folder current
+       `msgs' defaults to all
+       `-format' defaulted as described above
+       `-noheader'
+       `-width' defaulted to the width of the terminal
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SCAN(1)                           -87-                           SCAN(1)
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.
+
+
+  _H_i_s_t_o_r_y
+       Prior to using the format string mechanism, `-header' used to  gen-
+       erate a heading saying what each column in the listing was.  Format
+       strings prevent this from happening.
+
+
+  _B_u_g_s
+       The argument to the `-format' switch must be interpreted as a  sin-
+       gle token by the shell that invokes _s_c_a_n.  Therefore, one must usu-
+       ally place the argument to this switch inside double-quotes.
+       The value of each _c_o_m_p_o_n_e_n_t escape is set by _s_c_a_n to  the  contents
+       of  the first message header _s_c_a_n encounters with the corresponding
+       component name; any following headers with the same component  name
+       are ignored.
+
+       The switch `-reverse', makes _s_c_a_n list the messages in reverse ord-
+       er; this should be considered a bug.
+
+       The `-file filename' switch allows the user to obtain a _s_c_a_n  list-
+       ing of a maildrop file as produced by _p_a_c_k_f.  This listing includes
+       every message in the file.  The user should use _m_s_h for more selec-
+       tive  processing  of the file.  `-reverse' is ignored with this op-
+       tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SEND(1)                           -88-                           SEND(1)
+
+
+  _N_A_M_E
+       send - send a message
+
+  _S_Y_N_O_P_S_I_S
+       send [-alias aliasfile] [-draft] [-draftfolder +folder]
+            [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+            [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+            [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+            [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _S_e_n_d will cause each of the specified files to  be  delivered  (via
+       _p_o_s_t (8))  to each of the destinations in the "To:", "cc:", "Bcc:",
+       and "Fcc:" fields of the message.  If  _s_e_n_d  is  re-distributing  a
+       message,  as invoked from _d_i_s_t, then the corresponding "Resent-xxx"
+       fields are examined instead.
+
+       If `-push' is specified, _s_e_n_d will detach itself  from  the  user's
+       terminal and perform its actions in the background.  If _p_u_s_h 'd and
+       the draft can't be sent, then the `-forward' switch says that draft
+       should be forwarded with the failure notice sent to the user.  This
+       differs from putting _s_e_n_d in the background because the  output  is
+       trapped and analyzed by _M_H.
+
+       If `-verbose' is specified, _s_e_n_d  will  indicate  the  interactions
+       occurring  with the transport system, prior to actual delivery.  If
+       `-watch' is specified _s_e_n_d will monitor the delivery of  local  and
+       network  mail.   Hence, by specifying both switches, a large detail
+       of information can be gathered about each  step  of  the  message's
+       entry into the transport system.
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       _S_e_n_d with no _f_i_l_e argument will query  whether  the  draft  is  the
+       intended  file, whereas `-draft' will suppress this question.  Once
+       the transport system has successfully accepted custody of the  mes-
+       sage,  the  file will be renamed with a leading comma, which allows
+       it to be retrieved until the next draft message is sent.  If  there
+       are errors in the formatting of the message, _s_e_n_d will abort with a
+       (hopefully) helpful error message.
+
+       If a "Bcc:" field is encountered, its addresses will  be  used  for
+       delivery,  and  the  "Bcc:"  field will be removed from the message
+       sent to sighted recipients.  The blind recipients will  receive  an
+       entirely  new  message  with a minimal set of headers.  Included in
+       the body of the message will be a copy of the message sent  to  the
+       sighted  recipients.   If  `-filter filterfile'  is specified, then
+       this copy is filtered (re-formatted) prior to  being  sent  to  the
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SEND(1)                           -89-                           SEND(1)
+
+
+       blind recipients.
+
+       Prior to sending the message, the  fields  "From: user@local",  and
+       "Date: now" will be appended to the headers in the message.  If the
+       envariable $SIGNATURE is set, then its value is used as  your  per-
+       sonal  name  when constructing the "From:" line of the message.  If
+       this envariable is not set, then  _s_e_n_d  will  consult  the  profile
+       entry "Signature" for this information.  On hosts where _M_H was con-
+       figured with the UCI option, if $SIGNATURE is not set and the "Sig-
+       nature"   profile   entry   is   not   present,   then   the   file
+       $HOME/.signature is consulted.  If `-msgid' is  specified,  then  a
+       "Message-ID:" field will also be added to the message.
+
+       If _s_e_n_d is re-distributing a message (when invoked by _d_i_s_t ),  then
+       "Resent-"  will  be  prepended  to  each  of these fields: "From:",
+       "Date:", and "Message-ID:".  If  the  message  already  contains  a
+       "From:"  field,  then a "Sender: user@local" field will be added as
+       well.  (An already existing "Sender:" field is an error!)
+
+       By using the `-format' switch, each of the entries in the "To:" and
+       "cc:" fields will be replaced with "standard" format entries.  This
+       standard format is designed to be usable  by  all  of  the  message
+       handlers  on  the various systems around the Internet.  If `-nofor-
+       mat' is given, then headers are output exactly as  they  appear  in
+       the message draft.
+
+       If an "Fcc: folder" is encountered, the message will be  copied  to
+       the  specified folder for the sender in the format in which it will
+       appear to any non-Bcc receivers of the message.  That is,  it  will
+       have the appended fields and field reformatting.  The "Fcc:" fields
+       will be removed from all outgoing copies of the message.
+
+       By using the `-width columns' switch, the user can direct  _s_e_n_d  as
+       to how long it should make header lines containing addresses.
+
+       The file specified by the profile entry "Aliasfile:" and any  addi-
+       tional  alias  files given by the `-alias aliasfile' switch will be
+       read (more than one file,  each   preceeded  by  `-alias',  can  be
+       named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Draft-Folder:        To find the default draft-folder
+       Aliasfile:           For a default alias file
+       Signature:           To determine the user's mail signature
+       mailproc:            Program to post failure notices
+       postproc:            Program to post the message
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SEND(1)                           -90-                           SEND(1)
+
+
+  _S_e_e _A_l_s_o
+       comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       `file' defaults to <mh-dir>/draft
+       `-alias /usr/local/lib/mh/MailAliases'
+       `-nodraftfolder'
+       `-nofilter'
+       `-format'
+       `-forward'
+       `-nomsgid'
+       `-nopush'
+       `-noverbose'
+       `-nowatch'
+       `-width 72'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SHOW(1)                           -91-                           SHOW(1)
+
+
+  _N_A_M_E
+       show - show (list) messages
+
+  _S_Y_N_O_P_S_I_S
+       show [+folder] [msgs] [-draft] [-header] [-noheader]
+            [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+            [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _S_h_o_w lists each of the specified messages to  the  standard  output
+       (typically,  the  terminal).   Typically,  the  messages are listed
+       exactly as they are, with no reformatting.  A program named by  the
+       _s_h_o_w_p_r_o_c  profile  component  is invoked to do the listing, and any
+       switches not recognized by _s_h_o_w are passed along to  that  program.
+       The  default program is known as _m_o_r_e (1).  To override the default
+       and the _s_h_o_w_p_r_o_c profile  component,  use  the  `-showproc program'
+       switch.   For  example, `-show pr' will cause the _p_r (1) program to
+       list the messages.  The _M_H command _m_h_l can be used as a _s_h_o_w_p_r_o_c to
+       show  messages in a more uniform format.  Normally, this program is
+       specified as the _s_h_o_w_p_r_o_c is the user's .mh_profile.   See  _m_h_l (1)
+       for  the  details.   If  the  `-noshowproc'  option  is  specified,
+       `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+       The `-header' switch tells _s_h_o_w to display a  one-line  description
+       of  the  message being shown.  This description includes the folder
+       and the message number.
+
+       If no `msgs' are specified, the current message is used.   If  more
+       than  one  message  is  specified,  _m_o_r_e will prompt for a <RETURN>
+       prior to listing each message.  _m_o_r_e will list each message, a page
+       at  a  time.   When  the end of page is reached, _m_o_r_e will ring the
+       bell and wait for a <SPACE> or <RETURN>.  If a <RETURN> is entered,
+       _m_o_r_e  will print the next line, whereas <SPACE> will print the next
+       screenful.  To exit _m_o_r_e, type "q".
+
+       If the standard output is not a terminal, no queries are made,  and
+       each file is listed with a one-line header and two lines of separa-
+       tion.
+
+       "show -draft" will list the file <mh-dir>/draft if it exists.
+
+       If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+       then _s_h_o_w will remove each of the messages shown from each sequence
+       named  by  the   profile   entry.    This   is   similar   to   the
+       "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+       which take `msgs' or `msg' arguments.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SHOW(1)                           -92-                           SHOW(1)
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+       Unseen-Sequence:     To name sequences denoting unseen messages
+       showproc:            Program to show messages
+
+
+  _S_e_e _A_l_s_o
+       mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to cur
+       `-header'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current folder.  The  last
+       message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SHOW(1)                           -93-                           SHOW(1)
+
+
+  _B_u_g_s
+       The `-header' switch doesn't work when `msgs' expands to more  than
+       one  message.   If the _s_h_o_w_p_r_o_c is _m_h_l, then is problem can be cir-
+       cumvented by referencing the "messagename" field in the _m_h_l  format
+       file.
+
+       _S_h_o_w updates the user's context before showing the message.   Hence
+       _s_h_o_w  will  mark messages as seen prior to the user actually seeing
+       them.  This is generally not a problem, unless the user  relies  on
+       the  "unseen"  messages  mechanism, and interrupts _s_h_o_w while it is
+       showing "unseen" messages.
+
+       If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w uses a built-in _m_h_l: it does not  ac-
+       tually  run  the  _m_h_l  program.   Hence,  if  you  define  your own
+       _s_h_o_w_p_r_o_c, don't call it _m_h_l since _s_h_o_w won't run it.
+
+       If _m_o_r_e (1) is your showproc (the default), then avoid running _s_h_o_w
+       in  the  background  with only its standard output piped to another
+       process, as in
+
+            show | imprint &
+
+       Due to a bug in _m_o_r_e, show will go into a "tty  input"  state.   To
+       avoid  this  problem,  re-direct  _s_h_o_w's diagnostic output as well.
+       For users of _c_s_h:
+
+            show |& imprint &
+
+       For users of _s_h:
+
+            show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SORTM(1)                          -94-                          SORTM(1)
+
+
+  _N_A_M_E
+       sortm - sort messages
+
+  _S_Y_N_O_P_S_I_S
+       sortm [+folder] [msgs] [-datefield field] [-textfield field]
+            [-notextfield] [-limit days] [-nolimit] [-verbose]
+            [-noverbose] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _S_o_r_t_m sorts the specified messages in the named folder according to
+       the chronological order of the "Date:" field of each message.
+
+       The `-verbose' switch directs _s_o_r_t_m to tell the  user  the  general
+       actions that it is taking to place the folder in sorted order.
+
+       The `-datefield field' switch tells _s_o_r_t_m the name of the field  to
+       use  when  making  the  date comparison.  If the user has a special
+       field in each message, such as  "BB-Posted:"  or  "Delivery-Date:",
+       then  the  `-datefield'  switch  can  be used to direct _s_o_r_t_m which
+       field to examine.
+
+       The `-textfield field' switch causes _s_o_r_t_m to sort messages by  the
+       specified  text  field.   If  this  field is "subject", any leading
+       "re:" is stripped off.  In any case, all characters except  letters
+       and  numbers  are  stripped  and  the  resulting strings are sorted
+       datefield-major, textfield-minor, using  a  case  insensitive  com-
+       parison.
+
+       With `-textfield field', if `-limit days'  is  specified,  messages
+       with  similar textfields that are dated within `days' of each other
+       appear together.  Specifying `-nolimit' makes the  limit  infinity.
+       With   `-limit  0',  the  sort  is  instead  made  textfield-major,
+       date-minor.
+
+       For example, to order a folder by date-major, subject-minor, use:
+
+            sortm -textfield subject +folder
+
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Current-Folder:      To find the default current folder
+
+
+  _S_e_e _A_l_s_o
+       folder (1)
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  SORTM(1)                          -95-                          SORTM(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `+folder' defaults to the current folder
+       `msgs' defaults to all
+       `-datefield date'
+       `-notextfield'
+       `-noverbose'
+       `-nolimit'
+
+
+  _C_o_n_t_e_x_t
+       If a folder is given, it will become the current  folder.   If  the
+       current  message  is  moved,  _s_o_r_t_m  will  preserve  its  status as
+       current.
+
+
+  _H_i_s_t_o_r_y
+       Timezones used to be ignored when comparing dates: they aren't  any
+       more.
+
+       Messages which were in the folder, but  not  specified  by  `msgs',
+       used  to  be  moved to the end of the folder; now such messages are
+       left untouched.
+
+       Previously, _s_o_r_t_m would try to fill any gaps in a folder within the
+       range  of  messages  it  sorted.  To improve performance, _s_o_r_t_m now
+       minimizes the number of message  moves.   To  pack  a  folder,  use
+       "_f_o_l_d_e_r -_p_a_c_k" instead.
+
+
+  _B_u_g_s
+       If _s_o_r_t_m encounters a message without a date-field, or if the  mes-
+       sage  has a date-field that _s_o_r_t_m cannot parse, then _s_o_r_t_m attempts
+       to keep the message in the same relative position.  This  does  not
+       always  work.  For instance, if the first message encountered lacks
+       a date which can be parsed, then it will usually be placed  at  the
+       end of the messages being sorted.
+
+       When _s_o_r_t_m complains about a message which it can't temporally ord-
+       er,  it  complains  about  the message number _p_r_i_o_r to sorting.  It
+       should indicate what the message number will be _a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  VMH(1)                            -96-                            VMH(1)
+
+
+  _N_A_M_E
+       vmh - visual front-end to MH
+
+  _S_Y_N_O_P_S_I_S
+       vmh [-prompt string] [-vmhproc program] [-novmhproc]
+            [switches for _v_m_h_p_r_o_c] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _v_m_h is a program which implements the server side of the _M_H  window
+       management  protocol  and  uses  _c_u_r_s_e_s (3)  routines to maintain a
+       split-screen interface to any program which implements  the  client
+       side  of the protocol.  This latter program, called the _v_m_h_p_r_o_c, is
+       specified using the `-vmhproc program' switch.
+
+       The upshot of all this is that one can run _m_s_h on a display  termi-
+       nal and get a nice visual interface.  To do this, for example, just
+       add the line
+
+            mshproc: vmh
+
+       to your .mh_profile.  (This takes advantage of the fact that _m_s_h is
+       the default _v_m_h_p_r_o_c for _v_m_h.)
+
+       In order to facilitate things, if the `-novmhproc' switch is given,
+       and  _v_m_h  can't  run  on  the  user's  terminal, the _v_m_h_p_r_o_c is run
+       directly without the window management protocol.
+
+       After initializing the protocol, _v_m_h prompts the user for a command
+       to  be  given to the client.  Usually, this results in output being
+       sent to one or more windows.  If a output to a window  would  cause
+       it  to  scroll, _v_m_h prompts the user for instructions, roughly per-
+       mitting the capabilities of _l_e_s_s or  _m_o_r_e  (e.g.,  the  ability  to
+       scroll backwards and forwards):
+
+            SPACE      advance to the next windowful
+            RETURN  *  advance to the next line
+            y       *  retreat to the previous line
+            d       *  advance to the next ten lines
+            u       *  retreat to the previous ten lines
+            g       *  go to an arbitrary line
+                       (preceed g with the line number)
+            G       *  go to the end of the window
+                       (if a line number is given, this acts like `g')
+            CTRL-L     refresh the entire screen
+            h          print a help message
+            q          abort the window
+
+       (A `*' indicates that a numeric prefix is meaningful for this  com-
+       mand.)
+
+       Note that if a command resulted in more than one window's worth  of
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  VMH(1)                            -97-                            VMH(1)
+
+
+       information  being  displayed,  and  you allow the command which is
+       generating information for the window to gracefully  finish  (i.e.,
+       you  don't  use  the `q' command to abort information being sent to
+       the window), then _v_m_h will give you one last change to  peruse  the
+       window.   This  is  useful for scrolling back and forth.  Just type
+       `q' when you're done.
+
+       To abnormally terminate _v_m_h (without core dump), use  <QUIT>  (usu-
+       ally  CTRL-\).   For instance, this does the "right" thing with _b_b_c
+       and _m_s_h.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+
+
+  _S_e_e _A_l_s_o
+       msh(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-prompt (vmh) '
+       `-vmhproc msh'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The argument to the `-prompt' switch must be interpreted as a  sin-
+       gle  token by the shell that invokes _v_m_h.  Therefore, one must usu-
+       ally place the argument to this switch inside double-quotes.
+
+       At present, there is no way to pass signals (e.g., interrupt, quit)
+       to the client.  However, generating QUIT when _v_m_h is reading a com-
+       mand from the terminal is sufficient to tell the client to go  away
+       quickly.
+
+       Acts strangely (loses peer or botches  window  management  protocol
+       with peer) on random occasions.
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  WHATNOW(1)                        -98-                        WHATNOW(1)
+
+
+  _N_A_M_E
+       whatnow - prompting front-end for send
+
+  _S_Y_N_O_P_S_I_S
+       whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _W_h_a_t_n_o_w is the default program that  queries  the  user  about  the
+       disposition  of a composed draft.  It is normally invoked by one of
+       _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l after the initial edit.
+
+       When started, the editor is started on the draft (unless  `-noedit'
+       is  given,  in  which  case the initial edit is suppressed).  Then,
+       _w_h_a_t_n_o_w repetitively prompts the user with "What now?" and awaits a
+       response.  The valid responses are:
+
+       display         to list the message being distributed/replied-to on
+                       the terminal
+       edit            to re-edit using the same editor that was used on the
+                       preceding round unless a profile entry
+                       "<lasteditor>-next: <editor>" names an alternate editor
+       edit <editor>   to invoke <editor> for further editing
+       list            to list the draft on the terminal
+       push            to send the message in the background
+       quit            to terminate the session and preserve the draft
+       quit -delete    to terminate, then delete the draft
+       refile +folder  to refile the draft into the given folder
+       send            to send the message
+       send -watch     to cause the delivery process to be monitored
+       whom            to list the addresses that the message will go to
+       whom -check     to list the addresses and verify that they are
+                       acceptable to the transport service
+
+       For the edit response, any valid switch to  the  editor  is  valid.
+       Similarly,  for  the  send  and whom responses, any valid switch to
+       _s_e_n_d (1) and _w_h_o_m (1) commands, respectively, are valid.   For  the
+       push  response,  any  valid  switch  to  _s_e_n_d (1) is valid (as this
+       merely invokes _s_e_n_d with  the  `-push'  option).   For  the  _r_e_f_i_l_e
+       response,  any  valid  switch  to  the  _f_i_l_e_p_r_o_c is valid.  For the
+       display and list responses, any valid  argument  to  the  _l_p_r_o_c  is
+       valid.   If any non-switch arguments are present, then the pathname
+       of the draft will be excluded from the argument list given  to  the
+       _l_p_r_o_c (this is useful for listing another _M_H message).
+
+       See _m_h-_p_r_o_f_i_l_e (5) for further information about  how  editors  are
+       used  by MH.  It also discusses how complex envariables can be used
+       to direct _w_h_a_t_n_o_w's actions.
+
+       The `-prompt string' switch sets the prompting string for _w_h_a_t_n_o_w.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  WHATNOW(1)                        -99-                        WHATNOW(1)
+
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/draft                      The draft file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Draft-Folder:        To find the default draft-folder
+       Editor:              To override the default editor
+       <lasteditor>-next:   To name an editor to be used after  exit  from
+       <lasteditor>
+       fileproc:            Program to refile the message
+       lproc:               Program to list the contents of a message
+       sendproc:            Program to use to send the message
+       whomproc:            Program to determine who a message would go to
+
+
+  _S_e_e _A_l_s_o
+       send(1), whom(1)
+
+
+  _D_e_f_a_u_l_t_s
+       `-prompt "What Now? "'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The argument to the `-prompt' switch must be interpreted as a  sin-
+       gle  token  by the shell that invokes _w_h_a_t_n_o_w.  Therefore, one must
+       usually place the argument to this switch inside double-quotes.
+
+       If the initial edit fails, _w_h_a_t_n_o_w deletes your draft (by  renaming
+       it  with  a  leading  comma); failure of a later edit preverves the
+       draft.
+
+       If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p, _d_i_s_t, _f_o_r_w, and  _r_e_p_l  use  a
+       built-in  _w_h_a_t_n_o_w,  and  do  not  actually run the _w_h_a_t_n_o_w program.
+       Hence, if you define your own _w_h_a_t_n_o_w_p_r_o_c, don't  call  it  _w_h_a_t_n_o_w
+       since it won't be run.
+
+       If _s_e_n_d_p_r_o_c is _s_e_n_d, then _w_h_a_t_n_o_w uses a built-in _s_e_n_d, it does not
+       actually  run  the  _s_e_n_d  program.   Hence,  if you define your own
+       _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since _w_h_a_t_n_o_w won't run it.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  WHATNOW(1)                       -100-                        WHATNOW(1)
+
+
+  _N_A_M_E
+       whom - report to whom a message would go
+
+  _S_Y_N_O_P_S_I_S
+       whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [file] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _W_h_o_m is used to expand the headers of  a  message  into  a  set  of
+       addresses  and  optionally verify that those addresses are deliver-
+       able at that time (if `-check' is given).
+
+       The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+       the _M_H draft folder facility.  This is an advanced (and highly use-
+       ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+       manual for more information.
+
+       The file specified by the profile entry "Aliasfile:" and any  addi-
+       tional  alias  files given by the `-alias aliasfile' switch will be
+       read (more than one file,  each   preceeded  by  `-alias',  can  be
+       named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To determine the user's MH directory
+       Draft-Folder:        To find the default draft-folder
+       Aliasfile:           For a default alias file
+       postproc:            Program to post the message
+
+
+  _S_e_e _A_l_s_o
+       mh-alias(5), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       `file' defaults to <mh-dir>/draft
+       `-nocheck'
+       `-alias /usr/local/lib/mh/MailAliases'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  WHOM(1)                          -101-                           WHOM(1)
+
+
+  _B_u_g_s
+       With the `-check' option, _w_h_o_m makes no  guarantees  that  the  ad-
+       dresses  listed  as being ok are really deliverable, rather, an ad-
+       dress being listed as ok means that at the time that _w_h_o_m  was  run
+       the address was thought to be deliverable by the transport service.
+       For local addresses, this is absolute; for  network  addresses,  it
+       means  that the host is known; for uucp addresses, it (often) means
+       that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+                                        -102-
+
+
+       _M_O_R_E _D_E_T_A_I_L_S
+
+            This section describes some of the more intense points  of  the  _M_H
+       system,  by  expanding  on  topics  previously  discussed.   The  format
+       presented conforms to the standard form  for  the  description  of  UNIX
+  documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+  MH-ALIAS(5)                      -103-                       MH-ALIAS(5)
+
+
+  _N_A_M_E
+       mh-alias - alias file for MH message system
+
+  _S_Y_N_O_P_S_I_S
+       any _M_H command
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       This describes both _M_H personal alias files and the (primary) alias
+       file for mail delivery, the file
+
+               /usr/local/lib/mh/MailAliases
+
+       It does not describe aliases files used by  the  message  transport
+       system.  Each line of the alias file has the format:
+
+               alias : address-group
+       or
+               alias ; address-group
+       or
+               < alias-file
+       or
+               ; comment
+
+       where:
+
+               address-group  :=  address-list
+                              |   "<" file
+                              |   "=" UNIX-group
+                              |   "+" UNIX-group
+                              |   "*"
+
+               address-list   :=  address
+                              |   address-list, address
+
+       Continuation lines in alias files end with `\' followed by the new-
+       line character.
+
+       Alias-file and file are UNIX file names.   UNIX-group  is  a  group
+       name  (or  number)  from  /_e_t_c/_g_r_o_u_p.   An  address  is  a "simple"
+       Internet-style address.  Througout  this  file,  case  is  ignored,
+       except for alias-file names.
+
+       If the line starts with a `<', then the file named after the `<' is
+       read  for more alias definitions.  The reading is done recursively,
+       so a `<' may occur in the beginning  of  an  alias  file  with  the
+       expected results.
+
+       If the address-group starts with a `<', then the file  named  after
+       the  `<' is read and its contents are added to the address-list for
+       the alias.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-ALIAS(5)                      -104-                       MH-ALIAS(5)
+
+
+       If the address-group starts with an `=', then the  file  /_e_t_c/_g_r_o_u_p
+       is  consulted  for  the UNIX-group named after the `='.  Each login
+       name  occurring  as  a  member  of  the  group  is  added  to   the
+       address-list for the alias.
+
+       In contrast, if the address-group starts with a `+', then the  file
+       /_e_t_c/_g_r_o_u_p is consulted to determine the group-id of the UNIX-group
+       named after the `+'.  Each login name occurring in the  /_e_t_c/_p_a_s_s_w_d
+       file  whose  group-id  is  indicated  by this group is added to the
+       address-list for the alias.
+
+       If the address-group is simply `*', then the  file  /_e_t_c/_p_a_s_s_w_d  is
+       consulted and all login names with a userid greater than some magic
+       number (usually 200) are added to the address-list for the alias.
+
+       In match, a trailing * on an alias will match just  about  anything
+       appropriate.  (See example below.)
+
+       An approximation of the way aliases are resolved at posting time is
+       (it's not really done this way):
+
+            1) Build a list of  all  addresses  from  the  message  to  be
+            delivered, eliminating duplicate addresses.
+
+            2) If this draft originated on the local host, then for  those
+            addresses  in the message that have no host specified, perform
+            alias resolution.
+
+            3) For each line in the alias file,  compare  "alias"  against
+            all of the existing addresses.  If a match, remove the matched
+            "alias" from the address list, and add each new address in the
+            address-group  to the address list if it is not already on the
+            list.  The alias itself is  not  usually  output,  rather  the
+            address-group  that  the  alias maps to is output instead.  If
+            "alias" is terminated with a `;' instead of a `:',  then  both
+            the  "alias" and the address are output in the correct format.
+            (This makes replies possible since  _M_H  aliases  and  personal
+            aliases are unknown to the mail transport system.)
+
+       Since the alias file is read line by line, forward references work,
+       but  backward  references  are  not  recognized,  thus, there is no
+       recursion.
+
+       Example:
+            </usr/local/lib/mh/BBoardAliases
+            sgroup: fred, fear, freida
+            fred: frated@UCI
+            UNIX-committee: <unix.aliases
+            staff: =staff
+            wheels: +wheel
+            everyone: *
+            news.*: news
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-ALIAS(5)                      -105-                       MH-ALIAS(5)
+
+
+       The first line says that more aliases should  immediately  be  read
+       from  the  file  /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_B_B_o_a_r_d_A_l_i_a_s_e_s.   Following this,
+       "fred" is defined as an alias for  "frated@UCI",  and  "sgroup"  is
+       defined  as  an alias for the three names "frated@UCI", "fear", and
+       "freida".  Next, the definition of  "UNIX-committee"  is  given  by
+       reading the file _u_n_i_x._a_l_i_a_s_e_s in the users _M_H directory, "staff" is
+       defined as all users who are listed as members of the group "staff"
+       in  the /_e_t_c/_g_r_o_u_p file, and "wheels" is defined as all users whose
+       group-id  in  /_e_t_c/_p_a_s_s_w_d  is  equivalent  to  the  "wheel"  group.
+       Finally,  "everyone"  is  defined  as  all  users with a user-id in
+       /_e_t_c/_p_a_s_s_w_d  greater  than  200,  and  all  aliases  of  the   form
+       "news.<anything>" are defined to be "news".
+
+       The key thing to understand about aliasing in _M_H is that aliases in
+       _M_H  alias  files  are expanded into the headers of messages posted.
+       This aliasing occurs first, at posting time, without the  knowledge
+       of  the  message  transport  system.  In contrast, once the message
+       transport system is given  a  message  to  deliver  to  a  list  of
+       addresses, for each address that appears to be local, a system-wide
+       alias file is consulted.  These aliases are NOT expanded  into  the
+       headers of messages delivered.
+
+  _H_e_l_p_f_u_l _H_i_n_t_s
+
+       To use aliasing in _M_H quickly, do the following:
+
+            First, in your ._m_h__p_r_o_f_i_l_e, choose a  name  for  your  primary
+            alias file, say "aliases", and add the line:
+
+                 Aliasfile: aliases
+
+            Second, create the file "aliases" in your _M_H directory.
+
+            Third,  start  adding  aliases  to  your  "aliases"  file   as
+            appropriate.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/MailAliases       Primary alias file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Aliasfile:           For a default alias file
+
+
+  _S_e_e _A_l_s_o
+       ali(1), send(1), whom(1), group(5), passwd(5), conflict(8), post(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-ALIAS(5)                      -106-                       MH-ALIAS(5)
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _H_i_s_t_o_r_y
+       In previous releases of _M_H, only  a  single,  system-wide  mh-alias
+       file  was  supported.  Now that _M_H uses _M_M_D_F as a transport system,
+       the system-wide aliasing facility can  be  more  consistently  con-
+       trolled  by  the  latter.   This  means  that  at  most  sites, the
+       system-wide mh-alias file will  be  empty  (or  trivial  at  best).
+       Hence,  the semantics of mh-alias were extended to support personal
+       alias files.  Users of _M_H no longer need to bother mail-system  ad-
+       ministrators for keeping information in the system-wide alias file,
+       as each _M_H user can create/modify/remove aliases at will  from  any
+       number of personal files.
+
+
+  _B_u_g_s
+       Although  the  forward-referencing  semantics  of  _m_h-_a_l_i_a_s   files
+       prevent  recursion,  the  "< alias-file"  command  may defeat this.
+       Since the number of file descriptors is finite (and very  limited),
+       such  infinite recursion will terminate with a meaningless diagnos-
+       tic when all the fds are used up.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -107-                      MH-FORMAT(5)
+
+
+  _N_A_M_E
+       mh-format - format file for MH message system
+
+  _S_Y_N_O_P_S_I_S
+       some _M_H commands
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       Several _M_H commands utilize either a _f_o_r_m_a_t string or a _f_o_r_m_a_t file
+       during their execution.  For example, _s_c_a_n (1) uses a format string
+       which directs it how to generate the scan listing for each message;
+       _r_e_p_l (1)  uses  a  format file which directs it how to generate the
+       reply to a message, and so on.
+
+       Format strings are designed to be efficiently parsed  by  _M_H  which
+       means  they  are  not  necessarily  simple to write and understand.
+       This means that novice, casual, or even advanced users of _M_H should
+       not  have  to deal with them.  Some canned scan listing formats are
+       in  /usr/local/lib/mh/scan.time,  /usr/local/lib/mh/scan.size,  and
+       /usr/local/lib/mh/scan.timely.  Look in /usr/local/lib/mh for other
+       _s_c_a_n and _r_e_p_l format files which may  have  been  written  at  your
+       site.
+
+       It suffices to have your local _M_H expert actually write new  format
+       commands or modify existing ones.  This manual section explains how
+       to do that.   Note:  familiarity  with  the  C  _p_r_i_n_t_f  routine  is
+       assumed.
+
+       A format string consists  of  ordinary  text,  and  special  multi-
+       character _e_s_c_a_p_e sequences which begin with `%'.  When specifying a
+       format string, the usual C backslash characters are honored:  `\b',
+       `\f', `\n', `\r', and `\t'.  Continuation lines in format files end
+       with `\' followed by the newline character.  There are three  types
+       of  _e_s_c_a_p_e  sequences:  header _c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and,
+       flow _c_o_n_t_r_o_l.
+
+       A _c_o_m_p_o_n_e_n_t escape is specified as `%{_c_o_m_p_o_n_e_n_t}', and  exists  for
+       each  header  found  in  the  message being processed.  For example
+       `%{date}' refers to the "Date:" field of the  appropriate  message.
+       All  component  escapes  have  a string value.  Normally, component
+       values are compressed by converting any control characters (tab and
+       newline  included)  to spaces, then eliding any leading or multiple
+       spaces.  However, commands may give  different  interpretations  to
+       some  component  escapes; be sure to refer to each command's manual
+       entry for complete details.
+
+       A _f_u_n_c_t_i_o_n escape is specified as `%(_f_u_n_c_t_i_o_n)'.  All functions are
+       built-in, and most have a string or numeric value.
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -108-                      MH-FORMAT(5)
+
+
+    _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+       A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|', or  `%>'.  These  are
+       combined into the conditional execution construct:
+
+               %<condition
+                       _f_o_r_m_a_t _t_e_x_t _1
+               %?condition2
+                       _f_o_r_m_a_t _t_e_x_t _2
+               %?condition3
+                       _f_o_r_m_a_t _t_e_x_t _3
+               ...
+               %|
+                       _f_o_r_m_a_t _t_e_x_t _N
+               %>
+
+       Extra white space is shown here only for clarity.  These constructs
+       may   be   nested   without   ambiguity.    They   form  a  general
+       if-elseif-else-endif block where only one of the _f_o_r_m_a_t  _t_e_x_t  seg-
+       ments is interpreted.
+
+       The `%<'  and  `%?'  control  escapes  causes  a  condition  to  be
+       evaluated.  This condition may be either a _c_o_m_p_o_n_e_n_t or a _f_u_n_c_t_i_o_n.
+       The four constructs have the following syntax:
+
+               %<{component}
+               %<(function)
+               %?{component}
+               %?(function)
+
+       These control escapes test whether the function or component  value
+       is   non-zero  (for  integer-valued  escapes),  or  non-empty  (for
+       string-valued escapes).
+
+       If this test evaulates true, then the format text up  to  the  next
+       corresponding control escape (one of `%|', `%?', or `%>') is inter-
+       preted normally.  Next, all format text  up  to  the  corresponding
+       `%>'  control  escape (if any) is skipped.  The `%>' control escape
+       is not interpreted; normal interpretation resumes  after  the  `%>'
+       escape.
+
+       If the test evaluates false, however, then the format  text  up  to
+       the next corresponding control escape (again, one of `%|', `%?', or
+       `%>') is skipped, instead of being  interpreted.   If  the  control
+       escape  encountered  was  `%?',  then the condition associated with
+       that control escape is evaluated, and interpretation proceeds after
+       that  test  as described in the previous paragraph.  If the control
+       escape encountered was  `%|',  then  the  format  text  up  to  the
+       corresponding  `%>'  escape is interpreted normally.  As above, the
+       `%>' escape is not interpreted and  normal  interpretation  resumes
+       after the `%>' escape.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -109-                      MH-FORMAT(5)
+
+
+       The `%?' control escape and its following format text is  optional,
+       and  may  be  included zero or more times.  The `%|' control escape
+       and its following format text is also optional, and may be included
+       zero or one times.
+
+
+    _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+       Most functions expect an argument of a particular type:
+
+       _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n            _E_x_a_m_p_l_e _S_y_n_t_a_x
+       literal  A literal number,      %(_f_u_n_c 1234)
+                or string              %(_f_u_n_c text string)
+       comp     Any header component   %(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+       date     A date component       %(_f_u_n_c{_d_a_t_e})
+       addr     An address component   %(_f_u_n_c{_f_r_o_m})
+       expr     An optional component, %(_f_u_n_c(_f_u_n_c_2))
+                function or control,   %(_f_u_n_c %<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+                perhaps nested         %(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+       The types _d_a_t_e and _a_d_d_r have the same syntax as _c_o_m_p,  but  require
+       that  the  header  component  be  a date string, or address string,
+       respectively.
+
+       All arguments except those of type _e_x_p_r are required.  For the _e_x_p_r
+       argument  type,  the  leading `%' must be omitted for component and
+       function escape arguments, and must  be  present  (with  a  leading
+       space) for control escape arguments.
+
+       The evaluation of format strings is based on a simple machine  with
+       an  integer  register  _n_u_m, and a text string register _s_t_r.  When a
+       function escape is processed, if it accepts an optional _e_x_p_r  argu-
+       ment which is not present, it reads the current value of either _n_u_m
+       or _s_t_r as appropriate.
+
+
+    _R_e_t_u_r_n _v_a_l_u_e_s
+
+       Component escapes write the value of their message header  in  _s_t_r.
+       Function  escapes  write  their  return  value in _n_u_m for functions
+       returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n  values,  and  in  _s_t_r  for  functions
+       returning string values.  (The _b_o_o_l_e_a_n type is a subset of integers
+       with usual values 0=false and 1=true.)
+
+       All component escapes, and those function escapes which  return  an
+       _i_n_t_e_g_e_r  or  _s_t_r_i_n_g  value, pass this value back to their caller in
+       addition to setting _s_t_r or _n_u_m.  These escapes will print out  this
+       value  unless  called  as  part  of  an  argument to another escape
+       sequence.  Function escapes which return a _b_o_o_l_e_a_n  value  do  pass
+       this  value  back  to  their  caller,  but will never print out the
+       value.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -110-                      MH-FORMAT(5)
+
+
+       _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+       msg                 integer  message number
+       cur                 integer  message is current
+       size                integer  size of message
+       strlen              integer  length of _s_t_r
+       width               integer  output buffer size in bytes
+       charleft            integer  bytes left in output buffer
+       timenow             integer  seconds since the UNIX epoch
+       me                  string   the user's mailbox
+       eq         literal  boolean  _n_u_m == _a_r_g
+       ne         literal  boolean  _n_u_m != _a_r_g
+       gt         literal  boolean  _n_u_m > _a_r_g
+       match      literal  boolean  _s_t_r contains _a_r_g
+       amatch     literal  boolean  _s_t_r starts with _a_r_g
+       plus       literal  integer  _a_r_g plus _n_u_m
+       minus      literal  integer  _a_r_g minus _n_u_m
+       divide     literal  integer  _n_u_m divided by _a_r_g
+       num        literal  integer  Set _n_u_m to _a_r_g
+       lit        literal  string   Set _s_t_r to _a_r_g
+       nonzero    expr     boolean  _n_u_m is non-zero
+       zero       expr     boolean  _n_u_m is zero
+       null       expr     boolean  _s_t_r is empty
+       nonnull    expr     boolean  _s_t_r is non-empty
+       void       expr              Set _s_t_r or _n_u_m
+       comp       comp     string   Set _s_t_r to component text
+       compval    comp     integer  _n_u_m set to "atoi(_s_t_r)"
+       trim       expr              trim trailing white-space from _s_t_r
+       putstr     expr              print _s_t_r
+       putstrf    expr              print _s_t_r in a fixed width
+       putnum     expr              print _n_u_m
+       putnumf    expr              print _n_u_m in a fixed width
+
+       These functions require a date component as an argument:
+
+       _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+       sec        date     integer  seconds of the minute
+       min        date     integer  minutes of the hour
+       hour       date     integer  hours of the day (0-23)
+       wday       date     integer  day of the week (Sun=0)
+       day        date     string   day of the week (abbrev.)
+       weekday    date     string   day of the week
+       sday       date     integer  day of the week known?
+                                    (0=implicit,-1=unknown)
+       mday       date     integer  day of the month
+       yday       date     integer  day of the year
+       mon        date     integer  month of the year
+       month      date     string   month of the year (abbrev.)
+       lmonth     date     string   month of the year
+       year       date     integer  year of the century
+       zone       date     integer  timezone in hours
+       tzone      date     string   timezone string
+       szone      date     integer  timezone explicit?
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -111-                      MH-FORMAT(5)
+
+
+                                    (0=implicit,-1=unknown)
+       date2local date              coerce date to local timezone
+       date2gmt   date              coerce date to GMT
+       dst        date     integer  daylight savings in effect?
+       clock      date     integer  seconds since the UNIX epoch
+       rclock     date     integer  seconds prior to current time
+       tws        date     string   official 822 rendering
+       pretty     date     string   user-friendly rendering
+       nodate     date     integer  _s_t_r not a date string
+
+       These functions require an address component as  an  argument.  The
+       return  value of functions noted with `*' pertain only to the first
+       address present in the header component.
+
+       _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+       proper     addr     string   official 822 rendering
+       friendly   addr     string   user-friendly rendering
+       addr       addr     string   mbox@host or host!mbox rendering*
+       pers       addr     string   the personal name*
+       note       addr     string   commentary text*
+       mbox       addr     string   the local mailbox*
+       mymbox     addr     integer  the user's addresses? (0=no,1=yes)
+       host       addr     string   the host domain*
+       nohost     addr     integer  no host was present*
+       type       addr     integer  host type* (0=local,1=network,
+                                    -1=uucp,2=unknown)
+       path       addr     string   any leading host route*
+       ingrp      addr     integer  address was inside a group*
+       gname      addr     string   name of group*
+       formataddr expr              append _a_r_g to _s_t_r as a
+                                    (comma separated) address list
+       putaddr    literal           print _s_t_r address list with
+                                    _a_r_g as optional label;
+                                    get line width from _n_u_m
+
+       When escapes are nested, evaluation  is  done  from  inner-most  to
+       outer-most.   The  outer-most escape must begin with `%'; the inner
+       escapes must not.  For example,
+
+            %<(mymbox{from}) To: %{to}%>
+
+       writes the value of the header component "From:" to _s_t_r; then (_m_y_m_-
+       _b_o_x)  reads  _s_t_r  and  writes  its  result to _n_u_m; then the control
+       escape evaluates _n_u_m.  If _n_u_m is non-zero, the  string  "To:  "  is
+       printed followed by the value of the header component "To:".
+
+       A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is in order.  In general,  it
+       checks each of the addresses in the header component "_c_o_m_p" against
+       the user's mailbox name and any  _A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s.   It  returns
+       true  if  any address matches, however, it also returns true if the
+       "_c_o_m_p" header is not present in the message.  If needed, the (_n_u_l_l)
+       function can be used to explicitly test for this condition.
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -112-                      MH-FORMAT(5)
+
+
+       When a function or component escape is interpreted and  the  result
+       will  be immediately printed, an optional field width can be speci-
+       fied to print the field in exactly a given  number  of  characters.
+       For  example,  a  numeric escape like %4(_s_i_z_e) will print at most 4
+       digits of the message size; overflow will be indicated by a `?'  in
+       the first position (like `?234').  A string escape like %4(_m_e) will
+       print the first 4 characters and truncate at the end. Short  fields
+       are  padded  at  the  right  with  the  fill character (normally, a
+       blank).  If the field width argument begins with  a  leading  zero,
+       then the fill character is set to a zero.
+
+       As above, the functions (_p_u_t_n_u_m_f) and (_p_u_t_s_t_r_f) print their  result
+       in  exactly  the  number  of  characters specified by their leading
+       field width argument. For example,  %06(_p_u_t_n_u_m_f(_s_i_z_e))  will  print
+       the message size in a field six characters wide filled with leading
+       zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print the "From:"  header  component
+       in  fourteen  characters with trailing spaces added as needed.  For
+       _p_u_t_s_t_r_f, using a negative value for the field width  causes  right-
+       justification  of  the string within the field, with padding on the
+       left up to the field width.  The functions  (_p_u_t_n_u_m)  and  (_p_u_t_s_t_r)
+       print  their  result  in the minimum number of characters required,
+       and ignore any leading field width argument.
+
+       The available output width is kept in  an  internal  register;  any
+       output past this width will be truncated.
+
+       With all this in mind, here's the default format string  for  _s_c_a_n.
+       It's  been  divided into several pieces for readability.  The first
+       part is:
+
+            %4(putnumf(msg))%<(cur)+%| %>%<{replied}-%| %>
+
+       which says that the  message  number  should  be  printed  in  four
+       digits,  if  the  message  is the current message then a `+' else a
+       space should be printed, and if a "Replied:" field is present  then
+       a `-' else a space should be printed.  Next:
+
+            %02(putnumf(mon{date}))/%02(putnumf(mday{date}))
+
+       the month  and  date  are  printed  in  two  digits  (zero  filled)
+       separated by a slash.  Next,
+
+            %<{date} %|*>
+
+       If a "Date:" field was present, then a space is printed,  otherwise
+       a `*'.  Next,
+
+            %<(mymbox{from})To:%14(putstrf(friendly{to}))
+
+       if the message is  from  me,  print  `To:'  followed  by  a  "user-
+       friendly"  rendering of the first address in the "To:" field.  Con-
+       tinuing,
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -113-                      MH-FORMAT(5)
+
+
+            %|%17(putstrf(friendly{from}))%>
+
+       if the message isn't from me, then the print the "From:" address is
+       printed.  And finally,
+
+            %{subject}%<{body}<<%{body}%>
+
+       the subject and initial body (if any) are printed.
+
+       For a more complicated example, next consider the default _r_e_p_l_c_o_m_p_s
+       format file.
+
+            %(lit)%(formataddr %<{reply-to}%|
+
+       This clears _s_t_r and formats the "Reply-To:" header if present.   If
+       not present, the else clause is executed:
+
+            %<{from}%|%<{sender}%|%<{return-path}%>%>%>%>)\
+
+       This formats the "From:",  "Sender:"  and  "Return-Path:"  headers,
+       stopping as soon as one of them is present.  Next:
+
+            %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+       If the _f_o_r_m_a_t_a_d_d_r result is non-null, it is printed as  an  address
+       (with  line folding if needed) in a field _w_i_d_t_h wide with a leading
+       label of "To: ".
+
+            %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+       _s_t_r is cleared, and the "To:" and "Cc:"  headers,  along  with  the
+       user's  address  (depending  on  what  was specified with the "-cc"
+       switch to _r_e_p_l) are formatted.
+
+            %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+       If the result is non-null, it is printed as above  with  a  leading
+       label of "cc: ".
+
+            %<{fcc}Fcc: %{fcc}\n%>\
+
+       If a "-fcc folder" switch was given to _r_e_p_l (see _r_e_p_l (1) for  more
+       details about %{_f_c_c}), an "Fcc:" header is output.
+
+            %<{subject}Subject: Re: %{subject}\n%>\
+
+       If a subject component was present, a  suitable  reply  subject  is
+       output.
+
+            %<{date}In-reply-to: Your message of "\
+            %<(nodate{date})%{date}%|%(tws{date})%>."%<{message-id}
+                         %{message-id}%>\n%>\
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -114-                      MH-FORMAT(5)
+
+
+            --------
+
+       If a date component was present, an "In-Reply-To:" header is output
+       with the preface "Your message of ".  If the date was parseable, it
+       is output in official format, otherwise it is  output  as-is.   The
+       message-id is included if present.  As with all plain-text, the row
+       of dashes are output as-is.
+
+       This last part is a good example for  a  little  more  elaboration.
+       Here's that part again in pseudo-code:
+
+            if (comp_exists(date))  then
+                 print ("In-reply-to: Your message of \"")
+                 if (not_date_string(date.value) then
+                      print (date.value)
+                 else
+                      print (rfc822(date.value))
+                 endif
+                 print ("\"")
+                 if (comp_exists(message-id)) then
+                      print ("\n\t")
+                      print (message-id.value)
+                 endif
+                 print ("\n")
+            endif
+
+       Although this seems complicated, in point of fact, this  method  is
+       flexible  enough to extract individual fields and print them in any
+       format the user desires.
+
+  _F_i_l_e_s
+       None
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       scan(1), repl(1), ap(8), dp(8)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-FORMAT(5)                     -115-                      MH-FORMAT(5)
+
+
+  _H_i_s_t_o_r_y
+       This software was contributed for MH 6.3.  Prior  to  this,  output
+       format  specifications  were much easier to write, but considerably
+       less flexible.
+
+
+  _B_u_g_s
+       On hosts where _M_H was configured  with  the  BERK  option,  address
+       parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MAIL(5)                       -116-                        MH-MAIL(5)
+
+
+  _N_A_M_E
+       mh-mail - message format for MH message system
+
+  _S_Y_N_O_P_S_I_S
+       any _M_H command
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _M_H processes messages in a particular format.  It should  be  noted
+       that  although  neither  Bell  nor Berkeley mailers produce message
+       files in the format that _M_H prefers, _M_H can read message  files  in
+       that antiquated format.
+
+       Each user possesses a mail drop box which  initially  receives  all
+       messages  processed  by _p_o_s_t (8).  _I_n_c (1) will read from that drop
+       box and incorporate the new messages found there  into  the  user's
+       own  mail folders (typically `+inbox').  The mail drop box consists
+       of one or more messages.  To facilitate the separation of messages,
+       each  message begins and ends with a line consisting of nothing but
+       four CTRL-A (octal 001) characters.
+
+       Messages are expected to consist of lines of  text.   Graphics  and
+       binary data are not handled.  No data compression is accepted.  All
+       text is clear ASCII 7-bit data.
+
+       The general "memo" framework of RFC-822 is used.   A  message  con-
+       sists of a block of information in a rigid format, followed by gen-
+       eral text with no specified format.  The  rigidly  formatted  first
+       part of a message is called the header, and the free-format portion
+       is called the body.  The header must always exist, but the body  is
+       optional.   These  parts  are separated by an empty line, i.e., two
+       consecutive newline characters.  Within _M_H, the header and body may
+       be separated by a line consisting of dashes:
+
+            To:
+            cc:
+            Subject:
+            --------
+
+       The header is composed of one or more header  items.   Each  header
+       item  can  be  viewed as a single logical line of ASCII characters.
+       If the text of a header item extends across several real lines, the
+       continuation lines are indicated by leading spaces or tabs.
+
+       Each header item is called a component and is composed of a keyword
+       or  name,  along  with  associated text.  The keyword begins at the
+       left margin, may NOT contain spaces or  tabs,  may  not  exceed  63
+       characters  (as specified by RFC-822), and is terminated by a colon
+       (`:').  Certain components (as identified by their  keywords)  must
+       follow rigidly defined formats in their text portions.
+
+       The  text  for  most  formatted  components  (e.g.,   "Date:"   and
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MAIL(5)                       -117-                        MH-MAIL(5)
+
+
+       "Message-Id:") is produced automatically.  The only ones entered by
+       the user are address fields such as "To:",  "cc:",  etc.   Internet
+       addresses  are  assigned mailbox names and host computer specifica-
+       tions.  The rough format is "local@domain", such  as  "MH@UCI",  or
+       "MH@UCI-ICSA.ARPA".  Multiple addresses are separated by commas.  A
+       missing host/domain is assumed to be the local host/domain.
+
+       As mentioned above, a blank line (or a line of dashes) signals that
+       all  following text up to the end of the file is the body.  No for-
+       matting is expected or enforced within the body.
+
+       Following is a list of header components that are considered  mean-
+       ingful to various MH programs.
+       Date:
+            Added by _p_o_s_t (8), contains date and  time  of  the  message's
+            entry into the transport system.
+
+       From:
+            Added by _p_o_s_t (8), contains  the  address  of  the  author  or
+            authors  (may  be  more  than  one  if  a  "Sender:"  field is
+            present).  Replies are typically directed to addresses in  the
+            "Reply-To:"  or  "From:"  field  (the former has precedence if
+            present).
+
+       Sender:
+            Added by _p_o_s_t (8) in the event that the message already has  a
+            "From:"  line.   This  line contains the address of the actual
+            sender.  Replies are never sent to addresses in the  "Sender:"
+            field.
+
+       To:
+            Contains addresses of primary recipients.
+
+       cc:
+            Contains addresses of secondary recipients.
+
+       Bcc:
+            Still more recipients.  However, the "Bcc:" line is not copied
+            onto  the  message  as  delivered, so these recipients are not
+            listed.  _M_H uses an encapsulation method for blind copies, see
+            _s_e_n_d (1).
+
+       Fcc:
+            Causes _p_o_s_t (8) to copy the message into the specified  folder
+            for  the  sender, if the message was successfully given to the
+            transport system.
+
+       Message-ID:
+            A unique message identifier added by _p_o_s_t (8) if the  `-msgid'
+            flag is set.
+
+       Subject:
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MAIL(5)                       -118-                        MH-MAIL(5)
+
+
+            Sender's commentary.  It is displayed by _s_c_a_n (1).
+
+       In-Reply-To:
+            A commentary line added by _r_e_p_l (1) when replying  to  a  mes-
+            sage.
+
+       Resent-Date:
+            Added when redistributing a message by _p_o_s_t (8).
+
+       Resent-From:
+            Added when redistributing a message by _p_o_s_t (8).
+
+       Resent-To:
+            New recipients for a message resent by _d_i_s_t (1).
+
+       Resent-cc:
+            Still more recipients.  See "cc:" and "Resent-To:".
+
+       Resent-Bcc:
+            Even more recipients.  See "Bcc:" and "Resent-To:".
+
+       Resent-Fcc:
+            Copy  resent  message  into  a   folder.    See   "Fcc:"   and
+            "Resent-To:".
+
+       Resent-Message-Id:
+            A unique identifier glued on by _p_o_s_t (8) if the `-msgid'  flag
+            is set.  See "Message-Id:" and "Resent-To:".
+
+       Resent:
+            Annotation for _d_i_s_t (1) under the `-annotate' option.
+
+       Forwarded:
+            Annotation for _f_o_r_w (1) under the `-annotate' option.
+
+       Replied:
+            Annotation for _r_e_p_l (1) under the `-annotate' option.
+
+
+  _F_i_l_e_s
+       /usr/spool/mail/$USER               Location of mail drop
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+       RFC-822)
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-MAIL(5)                       -119-                        MH-MAIL(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -120-                     MH-PROFILE(5)
+
+
+  _N_A_M_E
+        .mh_profile - user customization for MH message system
+
+  _S_Y_N_O_P_S_I_S
+       any _M_H command
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       Each user of _M_H is expected to have a file named ._m_h__p_r_o_f_i_l_e in his
+       or her home directory.  This file contains a set of user parameters
+       used by some or all of the _M_H family of programs.  Each line of the
+       file is of the format
+
+           _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t: _v_a_l_u_e
+
+       The  possible  profile  components  are  exemplified  below.   Only
+       `Path:'  is  mandatory.  The others are optional; some have default
+       values if they are not present.  In the notation used below,  (pro-
+       file,  default)  indicates  whether  the information is kept in the
+       user's _M_H profile or _M_H context, and  indicates  what  the  default
+       value is.
+
+       Path: Mail
+                 Locates _M_H transactions in directory  "Mail".   (profile,
+                 no default)
+
+       context: context
+                 Declares the location of the _M_H  context  file,  see  the
+                 HISTORY     section     below.      (profile,    default:
+                 <mh-dir>/context)
+
+       Current-Folder: inbox
+                 Keeps  track  of  the  current  open  folder.   (context,
+                 default: +inbox)
+
+       Previous-Sequence: pseq
+                 Names the sequences which should be defined as the `msgs'
+                 or  `msg' argument given to the program.  If not present,
+                 or empty, no sequences are defined.  Otherwise, for  each
+                 name  given,  the  sequence is first zero'd and then each
+                 message is added to the sequence.  (profile, no default)
+
+       Sequence-Negation: not
+                 Defines the string which, when  prefixed  to  a  sequence
+                 name,  negates that sequence.  Hence, "notseen" means all
+                 those messages that are not  a  member  of  the  sequence
+                 "seen".  (profile, no default)
+
+       Unseen-Sequence: unseen
+                 Names the sequences which should be defined as those mes-
+                 sages recently incorporated by _i_n_c.  _S_h_o_w knows to remove
+                 messages from this sequence once it thinks they have been
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -121-                     MH-PROFILE(5)
+
+
+                 seen.   If  not  present,  or  empty,  no  sequences  are
+                 defined.  Otherwise, for each name given, the sequence is
+                 first  zero'd  and  then  each  message  is  added to the
+                 sequence.  (profile, no default)
+
+       mh-sequences: .mh_sequences
+                 The name of the file in each folder which defines  public
+                 sequences.  To disable the use of public sequences, leave
+                 the  value  portion  of  this  entry  blank.    (profile,
+                 default: .mh_sequences)
+
+       atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+                 Keeps track of the private sequence  called  _s_e_q  in  the
+                 specified folder.  (context, no default)
+
+       Editor: /usr/ucb/ex
+                 Defines  editor  to  be  used  by   _c_o_m_p (1),   _d_i_s_t (1),
+                 _f_o_r_w (1), and _r_e_p_l (1).  (profile, default: prompter)
+
+       Msg-Protect: 644
+                 Defines octal protection bits  for  message  files.   See
+                 _c_h_m_o_d (1)  for an explanation of the octal number.  (pro-
+                 file, default: 0644)
+
+       Folder-Protect: 711
+                 Defines protection bits for  folder  directories.   (pro-
+                 file, default: 0711)
+
+       _p_r_o_g_r_a_m: default switches
+                 Sets default switches to be used whenever the mh  program
+                 _p_r_o_g_r_a_m  is invoked.  For example, one could override the
+                 _E_d_i_t_o_r: profile component when replying  to  messages  by
+                 adding a component such as:
+                         repl: -editor /bin/ed
+                 (profile, no defaults)
+
+       _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+                 Names "nexteditor" to be the default editor  after  using
+                 "lasteditor".   This takes effect at "What now?" level in
+                 _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l.  After editing the draft with
+                 "lasteditor",  the  default editor is set to be "nextedi-
+                 tor".  If the user types "edit" without any arguments  to
+                 "What  now?",  then  "nexteditor"  is used.  (profile, no
+                 default)
+
+       bboards: system
+                 Tells _b_b_c which BBoards you are interested in.  (profile,
+                 default: system)
+
+       Folder-Stack: _f_o_l_d_e_r_s
+                 The contents of the folder-stack for the _f_o_l_d_e_r  command.
+                 (context, no default)
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -122-                     MH-PROFILE(5)
+
+
+       mhe:
+                 If present, tells _i_n_c to  compose  an  _M_H_E  auditfile  in
+                 addition  to  its other tasks.  _M_H_E is Brian Reid's _E_m_a_c_s
+                 front-end for _M_H.  An early version is supplied with  the
+                 _m_h._6 distribution.  (profile, no default)
+
+  Alternate-Mailboxes: mh@uci-750a, bug-mh*
+                 Tells _r_e_p_l and _s_c_a_n which addresses are really yours.  In
+                 this  way,  _r_e_p_l knows which addresses should be included
+                 in the reply, and _s_c_a_n knows if the message  really  ori-
+                 ginated  from  you.   Addresses  must  be  separated by a
+                 comma, and the hostnames listed should be the  "official"
+                 hostnames  for the mailboxes you indicate, as local nick-
+                 names for hosts are not replaced with their official site
+                 names.   For  each  address, if a host is not given, then
+                 that address on any host is considered  to  be  you.   In
+                 addition,  an asterisk (`*') may appear at either or both
+                 ends of the mailbox and host to indicate wild-card match-
+                 ing.  (profile, default: your user-id)
+
+       Aliasfile: aliases
+                 Indicates a default aliases file for _a_l_i, _w_h_o_m, and _s_e_n_d.
+                 This  may  be  used  instead of the `-alias file' switch.
+                 (profile, no default)
+
+       Draft-Folder: drafts
+                 Indicates a default draft folder for  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+                 and _r_e_p_l.  (profile, no default)
+
+       digest-issue-_l_i_s_t: 1
+                 Tells _f_o_r_w the last issue of the last volume sent for the
+                 digest _l_i_s_t.  (context, no default)
+
+       digest-volume-_l_i_s_t: 1
+                 Tells _f_o_r_w the last volume  sent  for  the  digest  _l_i_s_t.
+                 (context, no default)
+
+       MailDrop: .mail
+                 Tells _i_n_c your maildrop, if different from  the  default.
+                 This  is  superceded  by the $MAILDROP envariable.  (pro-
+                 file, default: /usr/spool/mail/$USER)
+
+       Signature: RAND MH System (agent: Marshall Rose)
+                 Tells _s_e_n_d your mail signature.  This  is  superceded  by
+                 the $SIGNATURE envariable.  On hosts where _M_H was config-
+                 ured with the UCI option, if $SIGNATURE is  not  set  and
+                 this   profile   entry   is   not   present,   the   file
+                 $HOME/.signature is consulted.  Your  signature  will  be
+                 added  to the address _s_e_n_d puts in the "From:" header; do
+                 not include an address in the signature text.   (profile,
+                 no default)
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -123-                     MH-PROFILE(5)
+
+
+       The following profile elements are  used  whenever  an  _M_H  program
+       invokes  some  other program such as _m_o_r_e (1).  The ._m_h__p_r_o_f_i_l_e can
+       be used to select alternate  programs  if  the  user  wishes.   The
+       default values are given in the examples.
+
+            fileproc:     /usr/local/refile
+            incproc:      /usr/local/inc
+            installproc:  /usr/local/lib/mh/install-mh
+            lproc:        /usr/ucb/more
+            mailproc:     /usr/local/mhmail
+            mhlproc:      /usr/local/lib/mh/mhl
+            moreproc:     /usr/ucb/more
+            mshproc:      /usr/local/msh
+            packproc:     /usr/local/packf
+            postproc:     /usr/local/lib/mh/post
+            rmmproc:      none
+            rmfproc:      /usr/local/rmf
+            sendproc:     /usr/local/send
+            showproc:     /usr/ucb/more
+            whatnowproc:  /usr/local/whatnow
+            whomproc:     /usr/local/whom
+
+       If you define the envariable $MH, you can specify a  profile  other
+       than ._m_h__p_r_o_f_i_l_e to be read by the _M_H programs that you invoke.  If
+       the value of $MH is not absolute, (i.e., does not begin with a / ),
+       it  will  be  presumed to start from the current working directory.
+       This is one of the very few exceptions  in  _M_H  where  non-absolute
+       pathnames are not considered relative to the user's _M_H directory.
+
+       Similarly, if you define the envariable $MHCONTEXT, you can specify
+       a  context  other than the normal context file (as specified in the
+       _M_H profile).  As always, unless the value of  $MHCONTEXT  is  abso-
+       lute, it will be presumed to start from your _M_H directory.
+
+       _M_H programs also support other envariables:
+
+       $MAILDROP : tells _i_n_c the default maildrop
+            This supercedes the "MailDrop:" profile entry.
+
+       $SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail signature
+            This supercedes the "Signature:" profile entry.
+
+       $HOME : tells all _M_H programs your home directory
+
+       $SHELL : tells _b_b_l the default shell to run
+
+       $TERM : tells _M_H your terminal type
+            The $TERMCAP envariable is  also  consulted.   In  particular,
+            these  tells  _s_c_a_n and _m_h_l how to clear your terminal, and how
+            many columns wide your terminal is.  They also  tell  _m_h_l  how
+            many lines long your terminal screen is.
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -124-                     MH-PROFILE(5)
+
+
+       $editalt : the alternate message
+            This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+            peruse  the message being distributed or replied-to.  The mes-
+            sage is also available  through  a  link  called  "@"  in  the
+            current  directory  if  your current working directory and the
+            folder the message lives in are on the same UNIX filesystem.
+
+       $mhdraft : the path to the working draft
+            This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l to  tell  the  _w_h_a_t_-
+            _n_o_w_p_r_o_c  which  file  to  ask "What now?" questions about.  In
+            addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l set $mhfolder  if  appropriate.
+            Further,  _d_i_s_t  and _r_e_p_l set $mhaltmsg to tell the _w_h_a_t_n_o_w_p_r_o_c
+            about an alternate message associated with the draft (the mes-
+            sage  being  distributed or replied-to), and _d_i_s_t sets $mhdist
+            to tell the _w_h_a_t_n_o_w_p_r_o_c that message re-distribution is occur-
+            ring.   Also,  $mheditor  is  set  to tell the _w_h_a_t_n_o_w_p_r_o_c the
+            user's choice of  editor  (unless  overridden  by  `-noedit').
+            Similarly, $mhuse may be set by _c_o_m_p.  Finally, $mhmessages is
+            set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if annotations are to occur (along
+            with  $mhannotate,  and  $mhinplace).   It's  amazing  all the
+            information that has to get passed via envariables to make the
+            "What now?" interface look squeaky clean to the _M_H user, isn't
+            it?  The reason for all this is that the _M_H  user  can  select
+            _a_n_y  program as the _w_h_a_t_n_o_w_p_r_o_c, including one of the standard
+            shells.  As a result, it's not possible  to  pass  information
+            via an argument list.
+            If the WHATNOW option was set during  _M_H  configuration  (type
+            `-help'  to an _M_H command to find out), and if this envariable
+            is set, if the commands _r_e_f_i_l_e, _s_e_n_d, _s_h_o_w, or  _w_h_o_m  are  not
+            given  any  `msgs'  arguments, then they will default to using
+            the file indicated by $mhdraft.  This is  useful  for  getting
+            the default behavior supplied by the default _w_h_a_t_n_o_w_p_r_o_c.
+
+       $mhfolder : the folder containing the alternate message
+            This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+            peruse  other  messages  in the current folder besides the one
+            being distributed or replied-to.  The $mhfolder envariable  is
+            also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t for use by _m_h_l.
+
+       $MHBBRC :
+            If you define  the  envariable  $MHBBRC,  you  can  specify  a
+            BBoards  information  file other than ._b_b_r_c to be read by _b_b_c.
+            If the value of $MHBBRC is not absolute, (i.e., does not begin
+            with  a  / ),  it  will  be presumed to start from the current
+            working directory.
+
+       $MHFD :
+            If the OVERHEAD option was set during _M_H  configuration  (type
+            `-help' to an _M_H command to find out), then if this envariable
+            is set, _M_H considers it to be the number of a  file-descriptor
+            which  is  opened, read-only to the _M_H profile.  Similarly, if
+            the envariable $MHCONTEXTFD is set, this is the  number  of  a
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -125-                     MH-PROFILE(5)
+
+
+            file-descriptor  which  is opened read-only to the _M_H context.
+            This feature of _M_H is experimental, and  is  used  to  examine
+            possible  speed  improvements for _M_H startup.  Note that these
+            envariables must be set and non-empty to enable this  feature.
+            However,  if OVERHEAD is enabled during _M_H configuration, then
+            when _M_H programs call other _M_H programs, this scheme is  used.
+            These file-descriptors are not closed throughout the execution
+            of the _M_H program, so children may  take  advantage  of  this.
+            This approach is thought to be completely safe and does result
+            in some performance enhancements.
+
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       or $MH                              Rather than the standard profile
+       <mh-dir>/context                    The user context
+       or $CONTEXT                         Rather than the standard context
+       <folder>/.mh_sequences              Public sequences for <folder>
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       All
+
+
+  _S_e_e _A_l_s_o
+       mh(1), environ(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -126-                     MH-PROFILE(5)
+
+
+  _H_i_s_t_o_r_y
+       In previous versions of _M_H, the current-message value of a writable
+       folder  was  kept  in a file called "cur" in the folder itself.  In
+       _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the current-message values for  all
+       folders, regardless of their writability.
+
+       In all versions of _M_H since _m_h._4,  the  ._m_h__p_r_o_f_i_l_e  contains  only
+       static  information, which _M_H programs will NOT update.  Changes in
+       context are made to the _c_o_n_t_e_x_t file kept in the users MH  _d_i_r_e_c_t_o-
+       _r_y.  This includes, but is not limited to: the "Current-Folder" en-
+       try and all private sequence information.  Public sequence informa-
+       tion is kept in a file called ._m_h__s_e_q_u_e_n_c_e_s in each folder.
+
+       To convert from the format used in releases of _M_H prior to the for-
+       mat used in the _m_h._4 release, _i_n_s_t_a_l_l-_m_h should be invoked with the
+       `-compat' switch.  This generally happens automatically on _M_H  sys-
+       tems generated with the "COMPAT" option during _M_H configuration.
+
+       The ._m_h__p_r_o_f_i_l_e may override the  path  of  the  _c_o_n_t_e_x_t  file,  by
+       specifying  a "context" entry (this must be in lower-case).  If the
+       entry is not absolute (does not start with a / ), then it is inter-
+       preted  relative  to the user's _M_H directory.  As a result, you can
+       actually have more than one set of private sequences by using  dif-
+       ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-PROFILE(5)                    -127-                     MH-PROFILE(5)
+
+
+  _B_u_g_s
+       The shell quoting conventions are not available in the .mh_profile.
+       Each token is separated by whitespace.
+
+       There is some question as to  what  kind  of  arguments  should  be
+       placed  in  the  profile  as  options.  In order to provide a clear
+       answer, recall command line semantics of all _M_H programs: conflict-
+       ing  switches  (e.g., `-header and `-noheader') may occur more than
+       one time on the command line, with the last switch  taking  effect.
+       Other  arguments, such as message sequences, filenames and folders,
+       are always remembered on the invocation line and are not superseded
+       by  following  arguments  of  the  same type.  Hence, it is safe to
+       place only switches (and their arguments) in the profile.
+
+       If one finds that an _M_H program is being invoked  again  and  again
+       with  the same arguments, and those arguments aren't switches, then
+       there are a few possible solutions to this problem.  The  first  is
+       to  create a (soft) link in your $_H_O_M_E/_b_i_n directory to the _M_H pro-
+       gram of your choice.  By giving this link a different name, you can
+       create  a new entry in your profile and use an alternate set of de-
+       faults for the _M_H command.  Similarly, you  could  create  a  small
+       shell script which called the _M_H program of your choice with an al-
+       ternate set of invocation line switches (using links and an  alter-
+       nate profile entry is preferable to this solution).
+
+       Finally, the _c_s_h user could create an alias for the command of  the
+       form:
+
+            alias cmd 'cmd arg1 arg2 ...'
+
+       In this way, the user can avoid lengthy type-in to the  shell,  and
+       still  give  _M_H commands safely.  (Recall that some _M_H commands in-
+       voke others, and that in all cases, the profile  is  read,  meaning
+       that aliases are disregarded beyond an initial command invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-SEQUENCE(5)                   -128-                    MH-SEQUENCE(5)
+
+
+  _N_A_M_E
+       mh-sequence - sequence specification for MH message system
+
+  _S_Y_N_O_P_S_I_S
+       most _M_H commands
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       Most _M_H commands accept a  `msg'  or  `msgs'  specification,  where
+       `msg'  indicates  one message and `msgs' indicates one or more mes-
+       sages.  To designate a message,  you  may  use  either  its  number
+       (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+            _N_a_m_e      _D_e_s_c_r_i_p_t_i_o_n
+            first     the first message in the folder
+            last      the last message in the folder
+            cur       the most recently accessed message
+            prev      the message numerically preceding "cur"
+            next      the message numerically following "cur"
+
+       In commands that take a `msg' argument, the default is "cur".  As a
+       shorthand, "." is equivalent to "cur".
+
+       For example: In a folder containing five messages numbered  5,  10,
+       94,  177  and 325, "first" is 5 and "last" is 325.  If "cur" is 94,
+       then "prev" is 10 and "next" is 177.
+
+       The word `msgs' indicates that one or more messages may  be  speci-
+       fied.   Such a specification consists of one message designation or
+       of several message designations separated  by  spaces.   A  message
+       designation  consists either of a message name as defined above, or
+       a message range.
+
+       A message range is specified as "name1-name2"  or  "name:n",  where
+       `name',  `name1'  and  `name2'  are  message  names,  and `n' is an
+       integer.
+
+       The specification "name1-name2" designates  all  currently-existing
+       messages from `name1' to `name2' inclusive.  The message name "all"
+       is a shorthand for the message range "first-last".
+
+       The specification "name:n" designates up to  `n'  messages.   These
+       messages  start with `name' if `name' is a message number or one of
+       the reserved names "first" "cur", or "next", The messages end  with
+       `name'  if  `name'  is "prev" or "last".  The interpretation of `n'
+       may be overridden by preceding `n' with a plus or minus sign;  `+n'
+       always  means  up  to  `n'  messages starting with `name', and `-n'
+       always means up to `n' messages ending with `name'.
+
+       In commands which accept a `msgs' argument, the default  is  either
+       "cur"  or  "all",  depending  on  which makes more sense.  Repeated
+       specifications of the same message have the same effect as a single
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-SEQUENCE(5)                   -129-                    MH-SEQUENCE(5)
+
+
+       specification of the message.
+
+
+    _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e_s
+
+       In addition to the "reserved"  (pre-defined)  message  names  given
+       above,  _M_H  supports  user-defined  sequence  names.   User-defined
+       sequences allow the _M_H user a tremendous amount of power in dealing
+       with  groups of messages in the same folder by allowing the user to
+       bind a group of messages to a meaningful symbolic name.
+
+       The name used to denote a  message  sequence  must  consist  of  an
+       alphabetic  character followed by zero or more alphanumeric charac-
+       ters, and can not be one of the  "reserved"  message  names  above.
+       After  defining  a  sequence, it can be used wherever an _M_H command
+       expects a `msg' or `msgs' argument.
+
+       Some  forms  of  message  ranges  are  allowed  with   user-defined
+       sequences.   The  specification "name:n" may be used, and it desig-
+       nates up to the first `n' messages (or last `n' messages for  `-n')
+       which are elements of the user-defined sequence `name'.
+
+       The specifications "name:next" and "name:prev" may  also  be  used,
+       and  they  designate  the next or previous message (relative to the
+       current message) which is an element of the  user-defined  sequence
+       `name'.   The  specificaitions  "name:first"  and  "name:last"  are
+       equivalent to "name:1" and "name:-1", respectively.  The specifica-
+       tion  "name:cur" is not allowed (use just "cur" instead).  The syn-
+       tax of these message range specifcations is subject  to  change  in
+       the future.
+
+       User-defined sequence names are specific to each folder.  They  are
+       defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+    _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+       There are two varieties of sequences: _p_u_b_l_i_c sequences and  _p_r_i_v_a_t_e
+       sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H
+       user that can read that folder and are kept  in  the  .mh_sequences
+       file  in  the folder.  _P_r_i_v_a_t_e sequences are accessible only to the
+       _M_H user that defined those sequences and are kept in the user's  _M_H
+       context file.  By default, _p_i_c_k and _m_a_r_k create _p_u_b_l_i_c sequences if
+       the folder for which the sequences are being defined is writable by
+       the  _M_H  user.  Otherwise, _p_r_i_v_a_t_e sequences are created.  This can
+       be overridden with the `-public' and `-private' switches to _m_a_r_k.
+
+
+    _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+       _M_H provides the ability to select all messages not  elements  of  a
+       user-defined  sequence.   To  do  this,  the user should define the
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-SEQUENCE(5)                   -130-                    MH-SEQUENCE(5)
+
+
+       entry "Sequence-Negation" in the _M_H profile file; its value may  be
+       any  string.  This string is then used to preface an existing user-
+       defined sequence name.  This specification  then  refers  to  those
+       messages not elements of the specified sequence name.  For example,
+       if the profile entry is:
+
+            Sequence-Negation: not
+
+       then anytime an _M_H command is given "notfoo" as a `msg'  or  `msgs'
+       argument, it would substitute all messages that are not elements of
+       the sequence "foo".
+
+       Obviously, the user should beware of defining sequences with  names
+       that begin with the value of the "Sequence-Negation" profile entry.
+
+
+    _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+       _M_H provides the ability to remember the `msgs'  or  `msg'  argument
+       last  given to an _M_H command.  The entry "Previous-Sequence" should
+       be defined in the _M_H profile; its value should be a  sequence  name
+       or  multiple  sequence names separated by spaces.  If this entry is
+       defined, when when an _M_H  command  finishes,  it  will  define  the
+       sequence(s)  named  in the value of this entry to be those messages
+       that were specified to the command.  Hence, a profile entry of
+
+            Previous-Sequence: pseq
+
+       directs any _M_H command that accepts a `msg' or `msgs'  argument  to
+       define the sequence "pseq" as those messages when it finishes.
+
+       Note:  there  can  be  a   performance   penalty   in   using   the
+       "Previous-Sequence"  facility.  If it is used, all _M_H programs have
+       to write the sequence information to the .mh_sequences file for the
+       folder  each  time  they  run.   If the "Previous-Sequence" profile
+       entry is not included,  only  _p_i_c_k  and  _m_a_r_k  will  write  to  the
+       .mh_sequences file.
+
+
+    _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+       Finally, some users like to indicate messages which have  not  been
+       previously seen by them.  Both _i_n_c and _s_h_o_w honor the profile entry
+       "Unseen-Sequence" to support this  activity.   This  entry  in  the
+       .mh_profile  should  be  defined  as  one  or  more  sequence names
+       separated by spaces.  If there is a value for "Unseen-Sequence"  in
+       the profile, then whenever _i_n_c places new messages in a folder, the
+       new messages will also be added to the  sequence(s)  named  in  the
+       value of this entry.  Hence, a profile entry of
+
+            Unseen-Sequence: unseen
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  MH-SEQUENCE(5)                   -131-                    MH-SEQUENCE(5)
+
+
+       directs _i_n_c to add new messages to the sequence  "unseen".   Unlike
+       the  behavior of the "Previous-Sequence" entry in the profile, how-
+       ever, the sequence(s) will not be zeroed by _i_n_c.
+
+       Similarly, whenever _s_h_o_w (or _n_e_x_t or _p_r_e_v) displays a message, that
+       message   will   be   removed  from  any  sequences  named  by  the
+       "Unseen-Sequence" entry in the profile.
+
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       <mh-dir>/context                    The user context
+       <folder>/.mh_sequences              Public sequences for <folder>
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Sequence-Negation:   To designate messages not in a sequence
+       Previous-Sequence:   The last message specification given
+       Unseen-Sequence:     Those messages not yet seen by the user
+
+
+  _S_e_e _A_l_s_o
+       mh(1), mark(1), pick(1), mh-profile(5)
+
+
+  _D_e_f_a_u_l_t_s
+       None
+
+
+  _C_o_n_t_e_x_t
+       All
+
+
+  _B_u_g_s
+       User-defined sequences are stored in the .mh_sequences  file  as  a
+       series  of  message specifications separated by spaces.  If a user-
+       defined sequence contains too many  individual  message  specifica-
+       tions,  that line in the file may become too long for _M_H to handle.
+       This will generate the error message ".mh_sequences is poorly  for-
+       matted".   You'll  have  to edit the file by hand to remove the of-
+       fending line.
+
+       This can happen to users who define the  "Previous-Sequence"  entry
+       in  the  _M_H profile and have a folder containing many messages with
+       gaps in the numbering.  A workaround for large folders is to minim-
+       ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  AP(8)                            -132-                             AP(8)
+
+
+  _N_A_M_E
+       ap - parse addresses 822-style
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/ap [-form formatfile] [-format string]
+            [-normalize] [-nonormalize] [-width columns] addrs ...
+            [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _A_p is a program that parses addresses according to the ARPA  Inter-
+       net  standard.   It also understands many non-standard formats.  It
+       is useful for seeing how _M_H will interpret an address.
+
+       The _a_p program treats each argument as one or more  addresses,  and
+       prints  those  addresses out in the official 822-format.  Hence, it
+       is usually best to enclose each argument in double-quotes  for  the
+       shell.
+
+       To override the output format used by _a_p, the  `-format string'  or
+       `-format file'  switches  are used.  This permits individual fields
+       of the address to be extracted with ease.  The string is  simply  a
+       format   stringand   thefile   is   simply   a  format  file.   See
+       _m_h-_f_o_r_m_a_t (5) for the details.
+
+       In addition to the standard escapes, _a_p also recognizes the follow-
+       ing additional escape:
+
+       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+       error   string   A diagnostic if the parse failed
+
+       If the `-normalize' switch is given, _a_p will try to track down  the
+       official hostname of the address.
+
+       Here is the default format string used by _a_p:
+
+            %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+       which says that if an error was detected, print the error,  a  `:',
+       and  the address in error.  Otherwise, output the 822-proper format
+       of the address.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+       /usr/local/lib/mh/mtstailor         tailor file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  AP(8)                            -133-                             AP(8)
+
+
+  _S_e_e _A_l_s_o
+       dp(8),
+       _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+       RFC-822)
+
+
+  _D_e_f_a_u_l_t_s
+       `-format' defaults as described above
+       `-normalize'
+       `-width' defaults to the width of the terminal
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The argument to the `-format' switch must be interpreted as a  sin-
+       gle token by the shell that invokes _a_p.  Therefore, one must usual-
+       ly place the argument to this switch inside double-quotes.
+
+       On hosts where _M_H was configured  with  the  BERK  option,  address
+       parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  CONFLICT(8)                      -134-                       CONFLICT(8)
+
+
+  _N_A_M_E
+       conflict - search for alias/password conflicts
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/conflict [-mail name] [-search directory]
+            [aliasfiles...] [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _C_o_n_f_l_i_c_t is a program that checks to see if the  interface  between
+       _M_H and transport system is in good shape
+
+       _C_o_n_f_l_i_c_t also checks for maildrops in /usr/spool/mail which do  not
+       belong  to  a  valid user.  It assumes that no user name will start
+       with `.', and thus ignores files  in  /usr/spool/mail  which  begin
+       with  `.'.   It also checks for entries in the _g_r_o_u_p (5) file which
+       do not belong to a valid user, and for users  who  do  not  have  a
+       valid  group  number.   In  addition duplicate users and groups are
+       noted.
+
+       If the `-mail name' switch is used, then the results will  be  sent
+       to  the  specified  _n_a_m_e.   Otherwise,  the results are sent to the
+       standard output.
+
+       The `-search directory' switch can be used  to  search  directories
+       other  than /usr/spool/mail and to report anomalies in those direc-
+       tories.  The `-search directory' switch can appear  more  than  one
+       time in an invocation to _c_o_n_f_l_i_c_t.
+
+       _C_o_n_f_l_i_c_t should be run under  _c_r_o_n (8), or whenever system account-
+       ing takes place.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       /etc/passwd                         List of users
+       /etc/group                          List of groups
+       /usr/local/mhmail                   Program to send mail
+       /usr/spool/mail/                    Directory of mail drop
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       mh-alias(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `aliasfiles' defaults to /usr/local/lib/mh/MailAliases
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  CONFLICT(8)                      -135-                       CONFLICT(8)
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  DP(8)                            -136-                             DP(8)
+
+
+  _N_A_M_E
+       dp - parse dates 822-style
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/dp [-form formatfile] [-format string]
+            [-width columns] dates ...  [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _D_p is a program that parses dates according to  the  ARPA  Internet
+       standard.   It  also understands many non-standard formats, such as
+       those  produced  by  TOPS-20  sites  and  some  UNIX  sites   using
+       _c_t_i_m_e (3).  It is useful for seeing how _M_H will interpret a date.
+
+       The _d_p program treats each argument as a single  date,  and  prints
+       the date out in the official 822-format.  Hence, it is usually best
+       to enclose each argument in double-quotes for the shell.
+
+       To override the output format used by _d_p, the  `-format string'  or
+       `-format file'  switches  are used.  This permits individual fields
+       of the address to be extracted with ease.  The string is  simply  a
+       format   stringand   thefile   is   simply   a  format  file.   See
+       _m_h-_f_o_r_m_a_t (5) for the details.
+
+       Here is the default format string used by _d_p:
+
+            %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+       which says that if an error was detected, print the error,  a  `:',
+       and  the date in error.  Otherwise, output the 822-proper format of
+       the date.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       None
+
+
+  _S_e_e _A_l_s_o
+       ap(8)
+       _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+       RFC-822)
+
+
+  _D_e_f_a_u_l_t_s
+       `-format' default as described above
+       `-width' default to the width of the terminal
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  DP(8)                            -137-                             DP(8)
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       The argument to the `-format' switch must be interpreted as a  sin-
+       gle token by the shell that invokes _d_p.  Therefore, one must usual-
+       ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  INSTALL-MH(8)                    -138-                     INSTALL-MH(8)
+
+
+  _N_A_M_E
+       install-mh - initialize the MH environment
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       When a user runs any _M_H program for the  first  time,  the  program
+       will  invoke _i_n_s_t_a_l_l-_m_h (with the `-auto' switch) to query the user
+       for the initial _M_H environment.  The user does NOT invoke this pro-
+       gram  directly.   The  user  is asked for the name of the directory
+       that will be designated as the user's _M_H directory.  If this direc-
+       tory  does  not  exist,  the user is asked if it should be created.
+       Normally, this directory should be under the user's home directory,
+       and  has  the  default name of Mail/.  After _i_n_s_t_a_l_l-_m_h has written
+       the initial .mh_profile for the user, control returns to the origi-
+       nal _M_H program.
+
+       As with all  _M_H  commands,  _i_n_s_t_a_l_l-_m_h  first  consults  the  $HOME
+       envariable to determine the user's home directory.  If $HOME is not
+       set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+       When converting from _m_h._3  to  _m_h._4,  _i_n_s_t_a_l_l-_m_h  is  automatically
+       invoked with the `-compat' switch.
+
+  _F_i_l_e_s
+       $HOME/.mh_profile                   The user profile
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       Path:                To set the user's MH directory
+
+
+  _C_o_n_t_e_x_t
+       With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POST(8)                          -139-                           POST(8)
+
+
+  _N_A_M_E
+       post - deliver a message
+
+  _S_Y_N_O_P_S_I_S
+       /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+            [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+            [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+            file [-help]
+
+  _D_E_S_C_R_I_P_T_I_O_N
+
+       _P_o_s_t is the program called by _s_e_n_d (1) to deliver  the  message  in
+       _f_i_l_e  to  local  and  remote  users.  In fact, all of the functions
+       attributed to _s_e_n_d on its manual page are performed by  _p_o_s_t,  with
+       _s_e_n_d  acting as a relatively simple preprocessor.  Thus, it is _p_o_s_t
+       which parses the various header fields,  appends  From:  and  Date:
+       lines, and interacts with the _M_M_D_F transport system.  _P_o_s_t will not
+       normally be called directly by the user.
+
+       _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:",  and  "Resent-xxx:"
+       header  lines  of  the specified message for destination addresses,
+       checks these addresses for validity, and formats them so as to con-
+       form  to  ARPAnet  Internet  Message  Format  protocol,  unless the
+       `-noformat' flag is set.  This will normally cause "@_l_o_c_a_l-_s_i_t_e" to
+       be appended to each local destination address, as well as any local
+       return addresses. The `-width columns' switch can be used to  indi-
+       cate  the  preferred  length  of the header components that contain
+       addresses.
+
+       If a "Bcc:" field is encountered, its addresses will  be  used  for
+       delivery,  and  the  "Bcc:"  field will be removed from the message
+       sent to sighted recipients.  The blind recipients will  receive  an
+       entirely  new  message  with a minimal set of headers.  Included in
+       the body of the message will be a copy of the message sent  to  the
+       sighted  recipients.   If  `-filter filterfile'  is specified, then
+       this copy is filtered (re-formatted) prior to  being  sent  to  the
+       blind recipients.
+
+       The `-alias aliasfile' switch can be used to specify  a  file  that
+       post  should  take  aliases from.  More than one file can be speci-
+       fied, each being preceded with `-alias'.  In any event, the primary
+       alias file is read first.
+
+       The   `-msgid'   switch   indicates   that   a   "Message-ID:"   or
+       "Resent-Message-ID:" field should be added to the header.
+
+       The `-verbose' switch indicates that the user should be informed of
+       each step of the posting/filing process.
+
+       The `-watch' switch indicates that the user would like to watch the
+       transport  system's handling of the message (e.g., local and "fast"
+       delivery).
+
+  [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+  POST(8)                          -140-                           POST(8)
+
+
+       _P_o_s_t consults the envariable $SIGNATURE to determine  the  sender's
+       personal name in constructing the "From:" line of the message.
+
+  _F_i_l_e_s
+       /usr/local/lib/mh/mtstailor         tailor file
+       /usr/local/refile                   Program to process Fcc:s
+       /usr/local/lib/mh/mhl               Program to process Bcc:s
+       /usr/local/lib/mh/MailAliases       Primary alias file
+
+
+  _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+       _p_o_s_t does NOT consult the user's .mh_profile
+
+
+  _S_e_e _A_l_s_o
+       _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+       RFC-822),
+       mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+  _D_e_f_a_u_l_t_s
+       `-alias /usr/local/lib/mh/MailAliases'
+       `-format'
+       `-nomsgid'
+       `-noverbose'
+       `-width 72'
+       `-nofilter'
+
+
+  _C_o_n_t_e_x_t
+       None
+
+
+  _B_u_g_s
+       "Reply-To:" fields are allowed to have groups in them according  to
+       the 822 specification, but _p_o_s_t won't let you use them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9       [mh.6]                           MH.6.7                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                _5. _R_E_P_O_R_T_I_N_G _P_R_O_B_L_E_M_S
+
+
+
+9
+            If problems are encountered with an _M_H program, the problems should
+       be  reported  to the local maintainers of _M_H.  When doing this, the name
+       of the program should be reported, along with  the  version  information
+       for  the  program.   To  find out what version of an _M_H program is being
+       run, invoke the program with the `-help' switch.  In addition to listing
+       the  syntax of the command, the program will list information pertaining
+       to its version.  This information includes the version of _M_H,  the  host
+       it was generated on, and the date the program was loaded.  A second line
+       of information, found on versions of _M_H after #5.380 include  _M_H  confi-
+       guration options.  For example,
+
+            version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov  6  01:13:53  PST
+            1985
+            options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII] [SMTP] [POP]
+
+       The `6.1 #1[UCI]' indicates that the program is from the UCI  _m_h._6  ver-
+       sion  of  _M_H.   The  program was generated on the host `nrtc-gremlin' on
+       `Wed Nov  6 01:13:53 PST 1985'.  It's usually a good idea  to  send  the
+       output of the `-help' switch along with your report.
+
+       If there is no local _M_H maintainer, try the  address  Bug-MH.   If  that
+       fails, use the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                                        -141-
+
+
+
+
+
+
+
+
+
+
+
+
+                                 _6. _A_D_V_A_N_C_E_D _F_E_A_T_U_R_E_S
+
+
+
+9
+            This section describes some  features  of  _M_H  that  were  included
+       strictly for advanced _M_H users.  These capabilities permit _M_H to exhibit
+       more powerful behavior for the seasoned _M_H users.
+
+
+9       _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+            User-defined sequences allow the _M_H user  a  tremendous  amount  of
+       power  in dealing with groups of messages in the same folder by allowing
+       the user to bind a group of messages to a meaningful symbolic name.  The
+       user  may choose any name for a message sequence, as long as it consists
+       of alphanumeric characters and does not conflict with  the  standard  _M_H
+       reserved message names (e.g., "first", etc).  After defining a sequence,
+       it can be used wherever an _M_H command expects a `msg'  or  `msgs'  argu-
+       ment.
+
+            A restricted form of message ranges are allowed  with  user-defined
+       sequences.  The  form  "name:n",  specifies up to the first `n' messages
+       which are part of the user-defined sequence `name'.  A leading plus sign
+       is  allowed on `n', but is ignored.  The interpretation of n is overrid-
+       den if n is preceded by a minus sign; `-n' always means up to  the  last
+       `n' messages which are part of the sequence `name'.
+
+            Although all _M_H commands expand user-defined sequences as appropri-
+       ate, there are two commands that allow the user to define and manipulate
+       them: _p_i_c_k and _m_a_r_k.
+
+       _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+            Most users of _M_H will use user-defined sequences only with the _p_i_c_k
+       command.  By giving the `-sequence name' switch to _p_i_c_k (which can occur
+       more than once on the command line), each sequence named is  defined  as
+       those  messages  which _p_i_c_k matched according the the selection criteria
+       it was given.  Hence,
+
+            pick -from frated -seq fred
+
+       finds all those messages in the current folder which were from "frated",
+       creates  a  sequence  called "fred", and then adds them to the sequence.
+       The user could then invoke
+
+            scan fred
+
+       to get a _s_c_a_n listing of those messages.  Note  that  by  default,  _p_i_c_k
+       creates  the named sequences before it adds the selected messages to the
+       sequence.  Hence, if the named sequence already existed, the sequence is
+
+                                        -142-
+
+
+
+
+
+
+
+
+
+                                        -143-
+
+
+       destroyed  prior  to  being  re-defined (nothing happens to the messages
+       that were a part of this sequence, they simply cease to  be  members  of
+       that  sequence).   By  using  the `-nozero' switch, this behavior can be
+       inhibited, as in
+
+            pick -from frated -seq sgroup
+            pick -from fear -seq sgroup -nozero
+            pick -from freida -seq sgroup -nozero
+
+       finds all those messages in the current folder which were from "frated",
+       "fear", or "freida", and defines the sequence called "sgroup" as exactly
+       those messages.  These operations amounted to an "inclusive-or" of three
+       selection  criteria, using _p_i_c_k, one can also generate the "and" of some
+       selection criteria as well:
+
+            pick -from frated -seq fred
+            pick -before friday -seq fred fred
+
+       This example defines the sequence called "fred" as  exactly  those  mes-
+       sages from "frated" that were dated prior to "friday".[1]
+
+            _P_i_c_k is normally used as a back-quoted command, for example,
+
+            scan `pick -from postmaster`
+
+       Now suppose that the user decides that another command should be issued,
+       using   exactly   those   messages.    Since,   _p_i_c_k   wasn't   given  a
+       `-sequence name' argument in this example, the user would end-up  typing
+       the entire back-quoted command again.  A simpler way is to add a default
+       sequence name to the .mh_profile.  For example,
+
+            pick: -seq select -list
+
+       will tell _p_i_c_k to always define the sequence "select" whenever it's run.
+       The  `-list'  is necessary since the `-sequence name' switch sets `-nol-
+       ist' whenever the former is  encountered.   Hence,  this  profile  entry
+
+
+9          [1]  Of  course, it is much easier to simply use the built-in boolean
+       operation of _p_i_c_k to get the desired results:
+
+            pick -from frated -or -from fear -or -from freida -seq sgroup
+
+       and
+
+            pick -from frated -and -before friday -seq fred
+
+       do exactly the same thing as the five commands listed above.  Hence, the
+       `-nozero'  option  to  _p_i_c_k  is  only  useful to manipulate existing se-
+       quences.
+
+
+9
+
+
+
+
+
+
+
+
+
+                                        -144-
+
+
+       makes _p_i_c_k define the "select" sequence and otherwise behave exactly  as
+       if there was no profile entry at all.
+
+       _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+            The _m_a_r_k command lets the user perform  low-level  manipulation  of
+       sequences,  and  also  provides  a  well-needed  debug  facility  to the
+       implementors/developers/maintainers  of  _M_H  (the  _M_H-hacks).   In   the
+       future,  a user-friendly "front-end" for _m_a_r_k will probably be developed
+       to give the _M_H user a way to take better  advantage  of  the  underlying
+       facilities.
+
+       _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+            There are two kinds of sequences:  _p_u_b_l_i_c  sequences,  and  _p_r_i_v_a_t_e
+       sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H user
+       that can read that folder and are kept in the .mh_sequences file in  the
+       folder.   _P_r_i_v_a_t_e  sequences  are  accessible  only  to the _M_H user that
+       defined those sequences and are kept in the user's _M_H context file.   By
+       default,  _p_i_c_k  (and  _m_a_r_k )  create  _p_u_b_l_i_c sequences if the folder for
+       which the sequences are being defined is writable by the _M_H user.   Oth-
+       erwise,  _p_r_i_v_a_t_e sequences are created.  This can be overridden with the
+       `-public' and `-private' switches.
+
+       _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+            In addition to telling an _M_H command to use  the  messages  in  the
+       sequence "seen", as in
+
+            refile seen +old
+
+       it would be useful to be easily able to tell an _M_H command  to  use  all
+       messages  _e_x_c_e_p_t  those in the sequence.  One way of doing this would be
+       to use _m_a_r_k and define the sequence explicitly, as in
+
+            mark -delete -zero seen -seq notseen
+
+       which, owing to _m_a_r_k 's cryptic interpretation of `-delete' and `-zero',
+       defines  the  sequence  "notseen" to be all messages not in the sequence
+       "seen".  Naturally, anytime the sequence "seen"  is  changed,  "notseen"
+       will  have  to be updated.  Another way to achieve this is to define the
+       entry "Sequence-Negation:" in the .mh_profile.  If the entry was
+
+            Sequence-Negation: not
+
+       then anytime an _M_H command was given "notseen"  as  a  `msg'  or  `msgs'
+       argument,  it would substitute all messages that are not a member of the
+       sequence "seen".  That is,
+
+            refile notseen +new
+
+       does just that.  The value of  the  "Sequence-Negation:"  entry  in  the
+
+
+
+
+
+
+
+
+
+
+
+                                        -145-
+
+
+       profile  can be any string.  Hence, experienced users of _M_H do not use a
+       word, but rather a special character which their shell does  not  inter-
+       pret  (users  of  the  _C_S_h_e_l_l  use a single caret or circumflex (usually
+       shift-6), while users of the  Bourne  shell  use  an  exclamation-mark).
+       This is because there is nothing to prevent a user of _M_H from defining a
+       sequence with this string as its prefix, if the  string  is  nothing  by
+       letters and digits.  Obviously, this could lead to confusing behavior if
+       the "Sequence-Negation:" entry leads _M_H to believe  that  two  sequences
+       are opposites by virtue of their names differing by the prefix string.
+
+       _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+            Many times users find themselves issuing a series  of  commands  on
+       the  same  sequences  of messages.  If the user first defined these mes-
+       sages as a sequence, then considerable typing may be saved.  If the user
+       doesn't  have  this  foresight,  _M_H  provides  a  handy way of having _M_H
+       remember the `msgs' or `msg' argument last given to an _M_H  command.   If
+       the  entry "Previous-Sequence:" is defined in the .mh_profile, then when
+       the command finishes, it will define the sequence(s) named in the  value
+       of  this  entry  as  being  exactly  those messages that were specified.
+       Hence, a profile entry of
+
+            Previous-Sequence: pseq
+
+       directs any _M_H command that accepts a `msg' or `msgs' argument to define
+       the  sequence  "pseq" as those messages when it finishes.  More than one
+       sequence name may be placed in this entry, separated with  spaces.   The
+       one  disadvantage of this approach is that the _M_H progams have to update
+       the sequence information for the folder each  time  they  run  (although
+       most  programs read this information, usually only _p_i_c_k and _m_a_r_k have to
+       write this information out).
+
+       _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+            Finally, some users like to distinguish between messages which have
+       been  previously seen by them.  Both _i_n_c and _s_h_o_w honorthe profile entry
+       "Unseen-Sequence" to support this activity.   Whenever  _i_n_c  places  new
+       messages  in  a folder, if the entry "Unseen-Sequence" is defined in the
+       .mh_profile, then when the command finishes, _i_n_c will add the  new  mes-
+       sages  to  the  sequence(s)  named in the value of this entry.  Hence, a
+       profile entry of
+
+            Unseen-Sequence:  unseen
+
+       directs _i_n_c to add new messages to the sequence  "unseen".   Unlike  the
+       behavior  of  the  "Previous-Sequence" entry in the profile however, the
+       sequence(s) will not be zero'd.
+
+            Similarly, whenever _s_h_o_w (or _n_e_x_t or  _p_r_e_v )  displays  a  message,
+       they   remove   those   messages   from   any  sequences  named  by  the
+       "Unseen-Sequence" entry in the profile.
+9
+9
+
+
+
+
+
+
+
+
+
+                                        -146-
+
+
+       _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+            There are a number of interesting advanced facilities for the  com-
+       position of outgoing mail.
+
+
+       _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+            The  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,  and  _r_e_p_l  commands  have  two  switches,
+       `-draftfolder +folder'        and        `-draftmessage msg'.         If
+       `-draftfolder +folder' is used, these commands are directed to construct
+       a  draft  message in the indicated folder.  (The "Draft-Folder:" profile
+       entry may be used to declare a default draft folder for use  with  _c_o_m_p,
+       _d_i_s_t, _f_o_r_w, and _r_e_p_l) If `-draftmessage msg' is not used, it defaults to
+       `new' (unless the user invokes _c_o_m_p  with  `-use',  in  which  case  the
+       default  is  `cur').   Hence, the user may have several message composi-
+       tions in progress simultaneously.  Now, all of the _M_H tools  are  avail-
+       able  on  each of the user's message drafts (e.g., _s_h_o_w, _s_c_a_n, _p_i_c_k, and
+       so on).  If the folder does not exist, the user is asked if it should be
+       created (just like with _r_e_f_i_l_e ).  Also, the last draft message the user
+       was composing is known as `cur' in the draft folder.
+
+            Furthermore, the _s_e_n_d command has these switches as  well.   Hence,
+       from  the shell, the user can send off whatever drafts desired using the
+       standard _M_H `msgs' convention with `-draftmessage msgs'.  If  no  `msgs'
+       are given, it defaults to `cur'.
+
+            In addition, all five  programs  have  a  `-nodraftfolder'  switch,
+       which undoes the last occurrence of `-draftfolder folder' (useful if the
+       latter occurs in the user's _M_H profile).
+
+            If the user does not give the `-draftfolder +folder'  switch,  then
+       all  these  commands act ``normally''.  Note that the `-draft' switch to
+       _s_e_n_d and _s_h_o_w still refers to the file called `draft' in the  user's  _M_H
+       directory.   In  the interests of economy of expression, when using _c_o_m_p
+       or _s_e_n_d, the user needn't prefix the draft `msg' or `msgs' with `-draft-
+       message'.   Both  of these commands accept a `file' or `files' argument,
+       and they will, if given `-draftfolder +folder' treat these arguments  as
+       `msg' or `msgs'.[2] Hence,
+
+            send -draftf +drafts first
+
+       is the same as
+
+            send -draftf +drafts -draftm first
+
+
+
+9          [2]  This may appear to be inconsistent, at first, but it saves a lot
+       of typing.
+
+
+9
+
+
+
+
+
+
+
+
+
+                                        -147-
+
+
+            To make all this a bit more clear, here are some  examples.   Let's
+       assume that the following entries are in the _M_H profile:
+
+            Draft-Folder: +drafts
+            sendf: -draftfolder +drafts
+
+       Furthermore, let's assume that the program _s_e_n_d_f is a (symbolic) link in
+       the user's $HOME/bin/ directory to _s_e_n_d.  Then, any of the commands
+
+            comp
+            dist
+            forw
+            repl
+
+       constructs the message draft in the `draft' folder using the `new'  mes-
+       sage  number.   Furthermore, they each define `cur' in this folder to be
+       that message draft.  If the user were to use the _q_u_i_t  option  at  `What
+       now?'  level, then later on, if no other draft composition was done, the
+       draft could be sent with simply
+
+            sendf
+
+       Or, if more editing was required, the draft could be edited with
+
+            comp -use
+
+       Instead, if other drafts had been composed in the meantime, so that this
+       message  draft  was no longer known as `cur' in the `draft' folder, then
+       the user could _s_c_a_n the folder to see which message draft in the  folder
+       should be used for editing or sending.  Clever users could even employ a
+       back-quoted _p_i_c_k to do the work:
+
+            comp -use `pick +drafts -to bug-mh`
+
+       or
+
+            sendf `pick +drafts -to bug-mh`
+
+       Note that in the _c_o_m_p example, the output from _p_i_c_k must  resolve  to  a
+       single  message  draft (it makes no sense to talk about composing two or
+       more drafts with one invocation of _c_o_m_p ).  In  contrast,  in  the  _s_e_n_d
+       example,  as  many  message  drafts  as  desired  can appear, since _s_e_n_d
+       doesn't mind sending more than one draft at a time.
+
+            Note that the argument `-draftfolder +folder' is  not  included  in
+       the  profile  entry  for  _s_e_n_d,  since  when  _c_o_m_p, et. al., invoke _s_e_n_d
+       directly, they supply _s_e_n_d with the UNIX pathname of the message  draft,
+       and  not  a `draftmessage msg' argument.  As far as _s_e_n_d is concerned, a
+       _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+            It is important to realize that _M_H treats the draft folder  like  a
+       standard  _M_H  folder  in nearly all respects.  There are two exceptions:
+
+
+
+
+
+
+
+
+
+
+
+                                        -148-
+
+
+       first_____, under no circumstancs will the `-draftfolder folder' switch cause
+       the named folder to become the current folder.[3] Second______, although  con-
+       ceptually _s_e_n_d deletes the `msgs' named in the draft folder, it does not
+       call `delete-prog' to perform the deletion.
+
+
+       _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e _D_r_a_f_t _E_x_i_s_t_s
+
+            When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands are  invoked  and  the
+       draft  you indicated already exists, these programs will prompt the user
+       for a reponse directing the program's action.  The prompt is
+
+            Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+            Disposition?
+
+       The appropriate responses and their meanings are: replace_______:  deletes  the
+       draft  and starts afresh; list____: lists the draft; refile______: files the draft
+       into a folder and starts afresh; and, quit____: leaves the draft intact  and
+       exits.   In addition, if you specified `-draftfolder folder' to the com-
+       mand, then one other response will be accepted: new___: finds a new  draft,
+       just  as  if `-draftmessage new' had been given.  Finally, the _c_o_m_p com-
+       mand will accept one more response: use___: re-uses the draft, just  as  if
+       `-use' had been given.
+
+
+       _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+            The _p_u_s_h option to the "What now?" query in the _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+       and  _r_e_p_l  commands,  directs the command to _s_e_n_d the draft in a special
+       detached fashion, with all normal output discarded.  If _p_u_s_h is used and
+       the  draft  can not be sent, then _M_H will send the user a message, indi-
+       cating the name of the draft file, and an explanation of the failure.
+
+            The user can also invoke _s_e_n_d  from  the  shell  with  the  `-push'
+       switch, which makes _s_e_n_d act like it had been _p_u_s_h 'd by one of the com-
+       position commands.
+
+            By using _p_u_s_h, the user can free the  shell  to  do  other  things,
+       because  it appears to the shell that the _M_H command has finished.  As a
+       result the shell will immediately prompt for  another  command,  despite
+       the  fact  that  the  command is really still running.  Note that if the
+
+
+9          [3]  Obviously,  if  the folder appeared in the context of a standard
+       `+folder' argument to an _M_H program, as in
+
+            scan +drafts
+
+       it might become the current folder, depending on the context changes  of
+       the _M_H program in question.
+
+
+9
+
+
+
+
+
+
+
+
+
+                                        -149-
+
+
+       user indicates that annotations are to be performed (with `-annotate' to
+       _d_i_s_t,  _f_o_r_w,  or _r_e_p_l), the annotations will be performed after the mes-
+       sage has been successfully sent.  This action will appear to occur asyn-
+       chronously.   Obviously,  if one of the messages that is to be annotated
+       is removed before the draft has been successfully  sent,  then  when  _M_H
+       tries  to  make the annotations, it won't be able to do so.  In previous
+       versions of _M_H, this resulted in an error message mysteriously appearing
+       on  the  user's  terminal.   In _m_h._5 and later versions, in this special
+       circumstance, no error will be generated.
+
+            If send is _p_u_s_h 'd, then the `-forward' switch  is  examined  if  a
+       failure notice is generated.  If given, then the draft is forwarded with
+       the failure notice sent to the user.  This allows  rapid  _b_u_r_s_t 'ing  of
+       the failure notice to retrieve the unsent draft.
+
+
+       _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+            By default, the message composition programs call a program  called
+       _w_h_a_t_n_o_w  before  the initial draft composition.  The _M_H user can specify
+       any program for this.  Following is some information about  the  default
+       "What  now?" level.  More detailed information can be found in the _w_h_a_t_-
+       _n_o_w (1) manual entry.
+
+            When using the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands at  "What  now?"
+       level,  the _e_d_i_t, _l_i_s_t, _h_e_a_d_e_r_s, _r_e_f_i_l_e, and (for the _d_i_s_t and _r_e_p_l com-
+       mands) the _d_i_s_p_l_a_y options will pass on any additional  arguments  given
+       them to whatever program they invoke.
+
+            In _m_h._1 (the original RAND _M_H ) and _m_h._2 (the first UCI version  of
+       _M_H ),  _M_H  used a complicated heuristic to determine if the draft should
+       be deleted or preserved after an unsuccessful edit.   In  _m_h._3,  _M_H  was
+       changed to preserve the draft always, since _c_o_m_p, et. al., could usually
+       look at a draft, apply another set of heuristics, and decide if  it  was
+       important  or  not.   With the notion of a _d_r_a_f_t _f_o_l_d_e_r, in which one by
+       default gets a `new' message draft, the edit deletion/preservation algo-
+       rithm  was re-implemented, to keep the draft folder from being cluttered
+       with aborted edits.
+
+            Also, note that by default, if the  draft  cannot  be  successfully
+       sent,  these  commands  return  to "What now?" level.  But, when _p_u_s_h is
+       used, this does not happen (obviously).  Hence, if these  commands  were
+       expected  to  annotate  any messages, this will have to be done by hand,
+       later on, with the _a_n_n_o command.
+
+            Finally, if the `-delete' switch is not given to the  _q_u_i_t  option,
+       then these commands will inform the user of the name of the unsent draft
+       file.
+
+
+       _D_i_g_e_s_t_s
+9
+9
+
+
+
+
+
+
+
+
+
+                                        -150-
+
+
+            The _f_o_r_w command has the beginnings  of  a  digestifying  facility,
+       with the `-digest list', `-issue number', and `-volume number' switches.
+
+       If _f_o_r_w is given "list" to the `-digest' switch as the name of the  dis-
+       cussion  group,  and  the `-issue number' switch is not given, then _f_o_r_w
+       looks for an entry in the user's _M_H context  called  "_d_i_g_e_s_t-issue-list"
+       and  increments its value to use as the issue number.  Similarly, if the
+       `-volume number'  switch   is   not   given,   then   _f_o_r_w   looks   for
+       "_d_i_g_e_s_t-volume-list"  (but  does  not increment its value) to use as the
+       volume number.
+
+       Having calculated the name of  the  digest  and  the  volume  and  issue
+       numbers, _f_o_r_w will now process the components file using the same format
+       string mechanism used by _r_e_p_l.  The current `%'-escapes are:
+
+       _e_s_c_a_p_e  _t_y_p_e     _s_u_b_s_t_i_t_u_t_i_o_n
+       digest  string   digest name
+       msg     integer  issue number
+       cur     integer  volume number
+
+       In addition, to capture the current date, any of the escapes  valid  for
+       _d_p (8) are also valid for _f_o_r_w.
+
+       The default components file used by _f_o_r_w when in digest mode is:
+
+            From:     %{digest}-Request
+            To:       %{digest} Distribution: dist-%{digest};
+            Subject:  %{digest} Digest V%(cur) #%(msg)
+            Reply-To: %{digest}
+            --------
+            %{digest} Digest        %(weekday{date}), %2(mday{date}) %(month{date}) 19%02(year{date})
+                            Volume %(cur) : Issue %(msg)
+
+            Today's Topics:
+
+       Hence, when the `-digest' switch is present, the  first  step  taken  by
+       _f_o_r_w  is  to  expand the format strings in the component file.  The next
+       step is to compose the draft using  the  standard  digest  encapsulation
+       algorithm  (even  putting an "End of list Digest" trailer in the draft).
+       Once the draft is composed by _f_o_r_w, _f_o_r_w writes out the volume and issue
+       profile entries for the digest, and then invokes the editor.
+
+       Naturally,   when   composing   the   draft,   _f_o_r_w   will   honor   the
+       `-filter filterfile'  switch,  which is given to _m_h_l to filter each mes-
+       sage being forwarded prior to encapsulation in the draft.  A good filter
+       file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+                                        -151-
+
+
+            width=80,overflowoffset=10
+            leftadjust,compress,compwidth=9
+            Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+            From:
+            Subject:
+            :
+            body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+9       _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+            There are two  interesting  facilities  for  manipulating  folders:
+       relative folder addressing, which allows a user to shorten the typing of
+       long folder names; and the folder-stack, which permits a user to keep  a
+       stack of current folders.
+
+
+       _R_e_l_a_t_i_v_e _F_o_l_d_e_r _A_d_d_r_e_s_s_i_n_g
+
+            By default, when `+folder' is given, and the  folder  name  is  not
+       absolute  (does not start with /, ./, or ../), then the UNIX pathname of
+       the folder is interpreted relative to the user's _M_H directory.  Although
+       this  mechanism  works  fine  for  top-level folders and their immediate
+       sub-folders, once the depth of the sub-folder  tree  grows,  it  becomes
+       rather unwieldly:
+
+            scan +mh/mh.4/draft/flames
+
+       is a lot of typing.  _M_H can't do anything  if  the  current  folder  was
+       "+inbox", but if the current folder was, say, "+mh/mh.4/draft", _M_H has a
+       short-hand notation to reference a sub-folder  of  the  current  folder.
+       Using  the  `@folder'  notation,  the  _M_H user can direct any _M_H program
+       which expects a `+folder' argument to look for the  folder  relative  to
+       the  current  folder  instead of the user's _M_H directory.  Hence, if the
+       current folder _w_a_s "+mh/mh.4/draft", then
+
+            scan @flames
+
+       would do the trick handily.  In addition,  if  the  current  folder  _w_a_s
+       "+mh/mh.4/draft",
+
+            scan @../pick
+
+       would scan the folder "+mh/mh.4/pick", since, in the  UNIX  fashion,  it
+       references the folder "pick" which is a sub-folder of the folder that is
+       the parent of the current folder.  Since most advanced _M_H users seem  to
+       exhibit a large degree of locality in referencing folders when they pro-
+       cess mail, this convention should receive a wide range of uses.
+
+
+
+9
+
+
+
+
+
+
+
+
+
+                                        -152-
+
+
+       _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+            The _f_o_l_d_e_r-_s_t_a_c_k mechanism in _M_H gives the _M_H user a facility simi-
+       lar to the _C_S_h_e_l_l 's directory-stack.  Simply put,
+
+            folder -push +foo
+
+       makes "foo" the current folder, saving the folder  that  was  previously
+       the current folder on the _f_o_l_d_e_r-_s_t_a_c_k.  As expected,
+
+            folder -pop
+
+       takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and makes it the current folder.  Each
+       of  these switches lists the _f_o_l_d_e_r-_s_t_a_c_k when they execute.  It is sim-
+       ple to write a _p_u_s_h_f command as a shell script.  It's one line:
+
+            exec folder -push $@
+
+       Probably a better way is to link  _f_o_l_d_e_r  to  the  $HOME/bin/  directory
+       under the name of _p_u_s_h_f and then add the entry
+
+            pushf: -push
+
+       to the .mh_profile.
+
+            The manual page for _f_o_l_d_e_r discusses the analogy between the _C_S_h_e_l_l
+       directory stack commands and the switches in _f_o_l_d_e_r which manipulate the
+       _f_o_l_d_e_r-_s_t_a_c_k.  The _f_o_l_d_e_r command uses the context entry `Folder-Stack:'
+       to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                      Appendix A
+                                   _C_O_M_M_A_N_D _S_U_M_M_A_R_Y
+
+
+
+9       ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+            [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+       anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+            [-date] [-nodate] [-text body] [-help]
+
+       bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+            [-archive] [-noarchive] [-protocol] [-noprotocol]
+            [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+            [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+            [-host host] [-help]
+
+       burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+            [-verbose] [-noverbose] [-help]
+
+       comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+            [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+            [-form formfile] [-use] [-nouse] [-whatnowproc program]
+            [-nowhatnowproc] [-help]
+
+       dist [+folder] [msg] [-annotate] [-noannotate]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-form formfile] [-inplace]
+            [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+       folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+            [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+            [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+            [-pop] [-help]
+
+       folders
+
+       forw [+folder] [msgs] [-annotate] [-noannotate]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-filter filterfile]
+            [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+            [-whatnowproc program] [-nowhatnowproc] [-help]
+
+       forw [+folder] [msgs] [-digest list] [-issue number]
+            [-volume number] [other switches for _f_o_r_w] [-help]
+
+
+
+
+
+
+
+9                                   -153-
+
+
+
+
+
+
+
+
+
+
+
+
+       inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+            [-nochangecur] [-file name] [-form formatfile]
+            [-format string] [-silent] [-nosilent] [-truncate]
+            [-notruncate] [-width columns] [-host host] [-user user]
+            [-pack file] [-nopack] [-rpop] [-norpop] [-help]
+
+       mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+            [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+       /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+            [-folder +folder] [-form formfile] [-length lines]
+            [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+            [-help]
+
+       mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+            [-subject subject]] [-help]
+
+       mhpath [+folder] [msgs] [-help]
+
+       msgchk [-date] [-nodate] [-notify all/mail/nomail]
+            [-nonotify all/mail/nomail] [-host host] [-user user] [-rpop]
+            [-norpop] [users ...] [-help]
+
+       msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+            [-help]
+
+       next [+folder] [-header] [-noheader] [-showproc program]
+            [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+       packf [+folder] [msgs] [-file name] [-help]
+
+       pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+            [-lbrace ... -rbrace] [--component pattern] [-after date]
+            [-before date] [-datefield field] [-sequence name ...]
+            [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+            [-help]
+
+       prev [+folder] [-header] [-noheader] [-showproc program]
+            [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+       prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+            [-norapid] [-doteof] [-nodoteof] file [-help]
+
+       /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+            [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+            [-help]
+
+
+
+
+
+9
+9                                   -154-
+
+
+
+
+
+
+
+
+
+
+
+
+       refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+            [-src +folder] [-file file] +folder ...  [-help]
+
+       repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+            [-nocc all/to/cc/me] [-draftfolder +folder]
+            [-draftmessage msg] [-nodraftfolder] [-editor editor]
+            [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+            [-inplace] [-noinplace] [-query] [-noquery]
+            [-whatnowproc program] [-nowhatnowproc] [-width columns]
+            [-help]
+
+       rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+       rmm [+folder] [msgs] [-help]
+
+       scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+            [-format string] [-header] [-noheader] [-width columns]
+            [-reverse] [-noreverse] [-file filename] [-help]
+
+       send [-alias aliasfile] [-draft] [-draftfolder +folder]
+            [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+            [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+            [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+            [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+       show [+folder] [msgs] [-draft] [-header] [-noheader]
+            [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+            [-help]
+
+       sortm [+folder] [msgs] [-datefield field] [-textfield field]
+            [-notextfield] [-limit days] [-nolimit] [-verbose]
+            [-noverbose] [-help]
+
+       vmh [-prompt string] [-vmhproc program] [-novmhproc]
+            [switches for _v_m_h_p_r_o_c] [-help]
+
+       whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+       whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+            [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+            [file] [-help]
+
+       /usr/local/lib/mh/ap [-form formatfile] [-format string]
+            [-normalize] [-nonormalize] [-width columns] addrs ...
+            [-help]
+
+
+
+
+
+9
+9                                   -155-
+
+
+
+
+
+
+
+
+
+
+
+
+       /usr/local/lib/mh/conflict [-mail name] [-search directory]
+            [aliasfiles ...] [-help]
+
+       /usr/local/lib/mh/dp [-form formatfile] [-format string]
+            [-width columns] dates ...  [-help]
+
+       /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+       /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+            [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+            [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+            file [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9                                        -156-
+
+
+
+
+
+
+
+
+
+
+
+
+                                      Appendix B
+                                   _M_E_S_S_A_G_E _N_A_M_E _B_N_F
+
+
+
+9
+                 msgs                  :=  msgspec                |
+                                           msgs msgspec
+
+                 msgspec               :=  msg                    |
+                                           msg-range              |
+                                           msg-sequence           |
+                                           user-defined-sequence
+
+                 msg                   :=  msg-name               |
+                                           <number>
+
+                 msg-name              :=  "first"                |
+                                           "last"                 |
+                                           "cur"                  |
+                                           "."                    |
+                                           "next"                 |
+                                           "prev"
+
+                 msg-range             :=  msg"-"msg              |
+                                           "all"
+
+                 msg-sequence          :=  msg":"signed-number
+
+                 signed-number         :=  "+"<number>            |
+                                           "-"<number>            |
+                                           <number>
+
+                 user-defined-sequence :=  <alpha>                |
+                                           <alpha><alphanumeric>*
+
+
+       Where <number> is a decimal number greater than zero.
+
+       Msg-range specifies all of the messages in the given range and must  not
+       be empty.
+
+       Msg-sequence specifies up to <number> of messages, beginning with  "msg"
+       (in the case of first, cur, next, or <number>), or ending with "msg" (in
+       the case of prev or last).  +<number> forces "starting  with  msg",  and
+       -<number> forces "ending with number".  In all cases, "msg" must exist.
+
+       User-defined sequences are defined and manipulated  with  the  _p_i_c_k  and
+       _m_a_r_k commands.
+
+
+
+9                                        -157-
+
+
+
+
+
+
+
+
+
+
+
+
+                                      _R_E_F_E_R_E_N_C_E_S
+
+
+
+       1.  Crocker, D. H., J. J. Vittal, K. T. Pogran,  and  D.  A.  Henderson,
+           Jr.,  "Standard  for  the  Format  of  ARPA  Network Text Messages,"
+           _R_F_C_7_3_3, November 1977.
+
+       2.  Thompson, K., and D. M. Ritchie,  "The  UNIX  Time-sharing  System,"
+           _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+       3.  McCauley, E. J., and P. J. Drongowski, "KSOS-The Design of a  Secure
+           Operating  System,"  _A_F_I_P_S _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, National Computer
+           Conference, Vol. 48, 1979, pp. 345-353.
+
+       4.  Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d _F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l _M_e_s_-
+           _s_a_g_e _S_y_s_t_e_m, The RAND Corporation, R-2134-ARPA, December 1977.
+
+       5.  Thompson, K., and D. M. Ritchie, _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th  ed.,
+           Western  Electric  Company,  May 1975 (available only to UNIX licen-
+           sees).
+
+       6. Crocker, D. H., "Standard for the Format of ARPA Internet  Text  Mes-
+           sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9                                        -158-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9                                         -i-
+
+
+
+
+
+
+
+
+
+
+
+
+                                      _R_E_A_D _T_H_I_S
+
+
+
+
+            Although the _M_H system was originally developed by  the  RAND  Cor-
+       poration,  and is now in the public domain, the RAND Corporation assumes
+       no responsibility for _M_H or this particular version of _M_H.
+
+            In addition, the Regents of the University of California issue  the
+       following disclaimer in regard to the UCI version of _M_H:
+
+            "Although each program has been tested by its contributor, no  war-
+            ranty,  express  or  implied,  is  made  by  the contributor or the
+            University of California, as to the accuracy and functioning of the
+            program and related program material, nor shall the fact of distri-
+            bution constitute any  such  warranty,  and  no  responsibility  is
+            assumed  by the contributor or the University of California in con-
+            nection herewith."
+
+            This version of _M_H is in the public domain, and as such, there  are
+       no  real  restrictions on its use.  The _M_H source code and documentation
+       have no licensing restrictions whatsoever.  As a courtesy,  the  authors
+       ask only that you provide appropriate credit to the RAND Corporation and
+       the University of California for having developed the software.
+
+            _M_H is a software package that is supported neither by the RAND Cor-
+       poration nor the University of California.  However, since we do use the
+       software ourselves and plan to continue using (and  improving)  _M_H,  bug
+       reports and their associated fixes should be reported back to us so that
+       we may include them in future releases.  The  current  computer  mailbox
+       for   _M_H   is   Bug-MH@ICS.UCI.EDU   (in   the   ARPA   Internet),   and
+       ...!ucbvax!ucivax!bug-mh (UUCP).  Presently, there are two Internet dis-
+       cussion   groups,   MH-Users@ICS.UCI.EDU   and   MH-Workers@ICS.UCI.EDU.
+       MH-Workers is for people discussing code changes to _M_H.  MH-Users is for
+       general  discussion  about  how to use _M_H.  MH-Users is bi-directionally
+       gatewayed into USENET as comp.mail.mh.
+
+       _H_O_W _T_O _G_E_T _M_H
+
+            Since you probably already have _M_H, you may not need to  read  this
+       unless  you  suspect you have an old version.  There are two ways to get
+       the latest release:
+
+            1.  If you can FTP to the  ARPA  Internet,  use  anonymous  FTP  to
+       ics.uci.edu  [128.195.1.1]  and  retrieve  the file pub/mh/mh-6.7.tar.Z.
+       This is a tar  image  after  being  run  through  the  compress  program
+       (approximately  1.5MB).   There  should  also  be  a README file in that
+       directory which tells what the current release of _M_H is, and how to  get
+       updates.
+
+9
+9                                         -i-
+
+
+
+
+
+
+
+
+
+                                         -ii-
+
+
+            This tar file is also available on louie.udel.edu [128.175.1.3]  in
+       portal/mh-6.7.tar.Z.   You  may  also find MH on various other hosts; to
+       make sure you get the latest version and don't waste your time re-fixing
+       bugs, it's best to get it from either ics.uci.edu or louie.udel.edu.
+
+            2.  You can send $75 US to the address below.  This covers the cost
+       of  a  6250  BPI  9-track magtape, handling, and shipping.  In addition,
+       you'll get a laser-printed hard-copy of the entire MH documentation set.
+       Be  sure  to  include your USPS address with your check.  Checks must be
+       drawn on U.S. funds and should be made payable to:
+
+                 Regents of the University of California
+
+       The distribution address is:
+
+                 Computing Support Group
+                 Attn: MH distribution
+                 Department of Information and Computer Science
+                 University of California, Irvine
+                 Irvine, CA  92717
+
+                 714/856-7554
+
+            If you just want the hard-copies of the  documentation,  you  still
+       have  to  pay  the $75.  The tar image has the documentation source (the
+       manual is in roff format, but the rest are in TeX  format).   Postscript
+       formatted  versions  of  the TeX papers are available, as are crude tty-
+       conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                       _F_O_R_E_W_O_R_D
+
+
+
+
+            This document describes the RAND _M_H Message Handling  System.   Its
+       primary  purpose  is  to  serve as a user's manual.  It has been heavily
+       based on a previous version of the manual,  prepared  by  Bruce  Borden,
+       Stockton Gaines, and Norman Shapiro.
+
+            _M_H is a particularly novel system, and thus it is often more  prone
+       to  change  than  other  pieces  of  production software.  As such, some
+       specific points in this manual may not be correct in the future.  In all
+       cases,  the  on-line  sections  of  this  manual,  available through the
+       UNIX[1] _m_a_n command, should present the most current information.
+
+            When reading this document as a user's manual, certain sections are
+       more  interesting than others.  The Preface and Summary are not particu-
+       larly interesting to those interested in learning _M_H.  The  Introduction
+       is slightly more interesting, as it touches upon the organization of the
+       remainder of this document.  The most useful sections are the  Overview,
+       Tutorial,  and Detailed Description.  The Overview should be read by all
+       _M_H users, regardless of their expertise (beginning, novice, advanced, or
+       hacker).   The  Tutorial  should  be read by all beginning and novice _M_H
+       users, as it presents a nice description of the _M_H system.  The Detailed
+       Description  should  be  read by the day-to-day user of _M_H, as it spells
+       out all of the realities of the _M_H system.  The Advanced  Features  sec-
+       tion discusses some powerful _M_H capabilities for advanced users.  Appen-
+       dix A is particularly useful for novices, as it summarizes  the  invoca-
+       tion syntax of all the _M_H commands.
+
+            There are also several other documents which may be useful to  you:
+       _T_h_e  _R_A_N_D  _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is a tutorial for
+       _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I _B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+       describes  the  BBoards handling under _M_H; _M_H._5: _H_o_w _t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+       _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l _g_e_t _s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which  was  presented  at
+       the  1985  Summer  Usenix Conference and Exhibition in Portland, Oregon;
+       _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r _A_g_e_n_t, which has been accepted  for  publication
+       by  Computer  Networks;  _M_Z_n_e_t: _M_a_i_l _S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l _M_i_c_r_o-_C_o_m_p_u_t_e_r
+       _S_y_s_t_e_m_s, which was presented at the  First  International  Symposium  on
+       Computer  Message  Systems  in  Nottingham, U.K.; and, _D_e_s_i_g_n _o_f _t_h_e _T_T_I
+       _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d _M_a_i_l _A_g_e_n_t, which describes  a  proprietary  "trusted"
+       mail  system  built on _M_H.  There are also documents, mostly specific to
+       U.C. Irvine which you may find interesting: _M_H _f_o_r _B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+       _M_M _U_s_e_r_s.  All of these documents exist in the _m_h._6 distribution sent to
+       your site.  There's also a document, _C_h_a_n_g_e_s _t_o _t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+       _d_l_i_n_g  _S_y_s_t_e_m:  _M_H._6,  which  describes  user-visible changes made to _M_H
+
+
+9          [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+9                                        -iii-
+
+
+
+
+
+
+
+
+
+                                         -iv-
+
+
+       since the last major release.
+
+            This manual is very large, as it describes a large, powerful system
+       in gruesome detail.  The important thing to remember is:
+
+
+                                    _D_O_N'_T _P_A_N_I_C[_2]
+
+
+       As explained in the tutorial, you really need to know only 5 commands to
+       handle most of your mail.
+
+            Very advanced users may wish to consult _T_h_e _R_A_N_D  _M_H  _M_e_s_s_a_g_e  _H_a_n_-
+       _d_l_i_n_g  _S_y_s_t_e_m:  _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also present in the _m_h._6
+       distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9          [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+                                   _A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+            The _M_H system described herein is based on  the  original  RAND  _M_H
+       system.   It  has  been  extensively  developed (perhaps too much so) by
+       Marshall T. Rose and John L. Romine at  the  University  of  California,
+       Irvine.  Einar A. Stefferud, Jerry N. Sweet, and Terry P. Domae provided
+       numerous suggestions to improve the UCI version of  _M_H.   Of  course,  a
+       large  number  of  people have helped _M_H along.  The list of ``_M_H immor-
+       tals'' is too long to list here.  However, Van Jacobson deserves a  spe-
+       cial  acknowledgement for his tireless work in improving the performance
+       of _M_H.  Some programs have been speeded-up by a factor of 10 or 20.  All
+       of  users  of  _M_H,  everywhere,  owe  a special thanks to Van.  For this
+       release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes and other changes.  A handful
+       of  courageous  _M_H-_W_o_r_k_e_r_s volunteered to beta-test these changes; their
+       help is particularly appreciated.
+
+            This manual is based on the original _M_H manual written at  RAND  by
+       Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9                                         -v-
+
+
+
+
+
+
+
+
+
+
+
+
+                                       _P_R_E_F_A_C_E
+
+
+
+
+            This report describes a system for dealing with messages  transmit-
+       ted  on  a  computer.  Such messages might originate with other users of
+       the same computer or might come from an outside source through a network
+       to  which the user's computer is connected.  Such computer-based message
+       systems are becoming increasingly widely used, both within  and  outside
+       the Department of Defense.
+
+            The message handling system _M_H was developed for two reasons.   One
+       was  to  investigate some research ideas concerning how a message system
+       might take advantage  of  the  architecture  of  the  UNIX  time-sharing
+       operating  system  for Digital Equipment Corporation PDP-11 and VAX com-
+       puters, and the special features of UNIX's command-level interface  with
+       the  user  (the  "shell").  The other reason was to provide a better and
+       more adaptable base than that of conventional designs on which to  build
+       a  command and control message system.  The effort has succeeded in both
+       regards, although this report mainly describes the message system itself
+       and how it fits in with UNIX.
+
+            The present report  should  be  of  interest  to  three  groups  of
+       readers.   First, it is a complete reference manual for the users of _M_H.
+       Second, it should be of interest to those who have a  general  knowledge
+       of  computer-based message systems, both in civilian and military appli-
+       cations.  Finally, it should be of interest to  those  who  build  large
+       subsystems  that  interface  with  users,  since  it  illustrates  a new
+       approach to such interfaces.
+
+            The original _M_H system was developed  by  Bruce  Borden,  using  an
+       approach  suggested  by  Stockton  Gaines  and Norman Shapiro.  Valuable
+       assistance was provided by Phyllis Kantar in the  later  stages  of  the
+       system's  implementation.   Several  colleagues contributed to the ideas
+       included in this system, particularly Robert Anderson and David Crocker.
+       In  addition,  valuable  experience  in  message systems, and a valuable
+       source of ideas, was available to us in the form of a  previous  message
+       system for UNIX called MS, designed at RAND by David Crocker.
+
+            This report was originally prepared as part  of  the  RAND  project
+       entitled "Data Automation Research", sponsored by Project AIR FORCE.
+
+
+
+
+
+
+
+
+
+9
+9                                         -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+                                       _S_U_M_M_A_R_Y
+
+
+
+
+            Electronic communication of text messages is becoming  commonplace.
+       Computer-based  message systems-software packages that provide tools for
+       dealing with messages-are used in many contexts.  In particular, message
+       systems  are  becoming increasingly important in command and control and
+       intelligence applications.
+
+            This report describes a message handling system  called  _M_H.   This
+       system  provides  the  user with tools to compose, send, receive, store,
+       retrieve, forward, and reply to messages.  _M_H has been built on the UNIX
+       time-sharing  system,  a  popular operating system developed for the DEC
+       PDP-11 and VAX classes of computers.
+
+            A complete description of _M_H is given for users of the system.  For
+       those who do not intend to use the system, this description gives a gen-
+       eral idea of what a message system is like.  The  system  involves  some
+       new ideas about how large subsystems can be constructed.
+
+            The interesting and unusual features of _M_H include  the  following:
+       The  user command interface to _M_H is the UNIX "shell" (the standard UNIX
+       command interpreter).  Each separable  component  of  message  handling,
+       such  as  message composition or message display, is a separate command.
+       Each program is driven from and  updates  a  private  user  environment,
+       which  is  stored  as  a file between program invocations.  This private
+       environment also contains information  to  "custom  tailor"  _M_H  to  the
+       individual's  tastes.   _M_H  stores each message as a separate file under
+       UNIX, and it utilizes the tree-structured UNIX file system  to  organize
+       groups  of  files  within separate directories or "folders".  All of the
+       UNIX facilities for dealing with files and directories, such  as  renam-
+       ing,  copying, deleting, cataloging, off-line printing, etc., are appli-
+       cable to messages and directories of messages (folders).   Thus,  impor-
+       tant capabilities needed in a message system are available in _M_H without
+       the need (often seen in other message systems) for code that  duplicates
+       the facilities of the supporting operating system.  It also allows users
+       familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9                                        -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+                                       _C_O_N_T_E_N_T_S
+
+
+
+
+       READ THIS .........................................................    i
+
+       FOREWORD ..........................................................  iii
+
+       ACKNOWLEDGMENTS ...................................................    v
+
+       PREFACE ...........................................................   vi
+
+       SUMMARY ...........................................................  vii
+
+       Section
+
+          1.  INTRODUCTION ...............................................    1
+
+          2.  OVERVIEW ...................................................    4
+
+          3.  TUTORIAL ...................................................    7
+
+          4.  DETAILED DESCRIPTION .......................................   10
+9            THE USER PROFILE .............................................   10
+9            MESSAGE NAMING ...............................................   13
+9            OTHER MH CONVENTIONS .........................................   14
+9            MH COMMANDS ..................................................   16
+               ALI .......................................................   17
+               ANNO ......................................................   19
+               BBC .......................................................   21
+               BBOARDS ...................................................   24
+               BURST .....................................................   26
+               COMP ......................................................   28
+               DIST ......................................................   30
+               FOLDER ....................................................   33
+               FORW ......................................................   36
+               INC .......................................................   40
+               MARK ......................................................   43
+               MHL .......................................................   45
+               MHMAIL ....................................................   50
+               MHOOK .....................................................   52
+               MHPATH ....................................................   54
+               MSGCHK ....................................................   57
+               MSH .......................................................   59
+               NEXT ......................................................   63
+               PACKF .....................................................   64
+               PICK ......................................................   65
+               PREV ......................................................   69
+               PROMPTER ..................................................   70
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+               RCVSTORE ..................................................   73
+               REFILE ....................................................   75
+               REPL ......................................................   77
+               RMF .......................................................   81
+               RMM .......................................................   83
+               SCAN ......................................................   85
+               SEND ......................................................   88
+               SHOW ......................................................   91
+               SORTM .....................................................   94
+               VMH .......................................................   96
+               WHATNOW ...................................................   98
+               WHOM ......................................................  100
+9            MORE DETAILS .................................................  102
+               MH-ALIAS ..................................................  103
+               MH-FORMAT .................................................  107
+               MH-MAIL ...................................................  116
+               MH-PROFILE ................................................  120
+               MH-SEQUENCE ...............................................  128
+               AP ........................................................  132
+               CONFLICT ..................................................  134
+               DP ........................................................  136
+               INSTALL-MH ................................................  138
+               POST ......................................................  139
+
+          5.  REPORTING PROBLEMS .........................................  141
+
+          6.  ADVANCED FEATURES ..........................................  142
+9            USER-DEFINED SEQUENCES .......................................  142
+               Pick and User-Defined Sequences ...........................  142
+               Mark and User-Defined Sequences ...........................  144
+               Public and Private User-Defined Sequences .................  144
+               Sequence Negation .........................................  144
+               The Previous Sequence .....................................  145
+               The Unseen Sequence .......................................  145
+9            COMPOSITION OF MAIL ..........................................  146
+               The Draft Folder ..........................................  146
+               What Happens if the Draft Exists ..........................  148
+               The Push Option at What now? Level ........................  148
+               Options at What now? Level ................................  149
+               Digests ...................................................  150
+9            FOLDER HANDLING ..............................................  151
+               Relative Folder Addressing ................................  151
+               The Folder-Stack ..........................................  152
+
+       Appendix
+          A.  Command Summary ............................................  153
+          B.  Message Name BNF ...........................................  157
+
+       REFERENCES ........................................................  158
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9                               THE RAND MH
+
+9                            MESSAGE HANDLING
+
+9                                 SYSTEM:
+
+9                              USER'S MANUAL
+
+
+
+
+
+
+                               UCI Version
+
+
+
+
+
+                            Marshall T. Rose
+
+                             John L. Romine
+
+
+
+
+                     Based on the original manual by
+
+                       Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+                            February 1, 1991
+
+                             6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
diff --git a/docs/historical/MH-19921214.pdf b/docs/historical/MH-19921214.pdf
new file mode 100644
index 0000000..431c46b
Binary files /dev/null and b/docs/historical/MH-19921214.pdf differ
diff --git a/docs/historical/MH-19921214.txt b/docs/historical/MH-19921214.txt
new file mode 100644
index 0000000..2ee97f5
--- /dev/null
+++ b/docs/historical/MH-19921214.txt
@@ -0,0 +1,13134 @@
+
+
+
+
+
+
+
+
+                                            _d_i_s_c_a_r_d _t_h_i_s _p_a_g_e
+
+
+
+
+                                               The RAND _M_H
+                                         Message Handling System:
+                                              User's Manual
+
+                                               UCI Version
+
+
+                                            December 14, 1992
+                                               6.6 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                             _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+                      Although people can travel cross-country in  hours  and  can  reach
+                 others by telephone in seconds, communications still depend heavily upon
+                 paper, most of which is distributed through the mails.
+
+                      There are several major reasons for this  continued  dependence  on
+                 written  documents.   First,  a  written  document  may be proofread and
+                 corrected prior to its distribution, giving the author complete  control
+                 over  his  words.   Thus,  a written document is better than a telephone
+                 conversation in this respect.  Second, a carefully written  document  is
+                 far  less  likely to be misinterpreted or poorly translated than a phone
+                 conversation.  Third, a  signature  offers  reasonable  verification  of
+                 authorship, which cannot be provided with media such as telegrams.
+
+                      However, the need for fast____,  accurate,  and  reproducible  document
+                 distribution is obvious.  One solution in widespread use is the telefax.
+                 Another that is rapidly gaining popularity is  electronic  mail.   Elec-
+                 tronic  mail is similar to telefax in that the data to be sent are digi-
+                 tized, transmitted via phone lines, and turned back into a  document  at
+                 the  receiver.   The  advantage of electronic mail is in its compression
+                 factor.  Whereas a telefax must scan a page in very fine lines and  send
+                 all  of the black and white information, electronic mail assigns charac-
+                 ters fixed codes which can be transmitted as a few bits of  information.
+                 Telefax  presently  has the advantage of being able to transmit an arbi-
+                 trary page, including pictures, but electronic mail is beginning to deal
+                 with  this  problem.   Electronic mail also integrates well with current
+                 directions  in  office  automation,  allowing  documents  prepared  with
+                 sophisticated  equipment  at  one  site  to  be  quickly transferred and
+                 printed at another site.
+
+                      Currently, most electronic mail is intraorganizational,  with  mail
+                 transfer  remaining within one computer.  As computer networking becomes
+                 more common, however, it is becoming more feasible to  communicate  with
+                 anyone whose computer can be linked to your own via a network.
+
+                      The pioneering efforts on general-purpose electronic mail  were  by
+                 organizations using the DoD ARPAnet[1].  The capability to send messages
+                 between computers existed before the ARPAnet was developed, but  it  was
+                 used  only in limited ways.  With the advent of the ARPAnet, tools began
+                 to be developed which made it convenient for  individuals  or  organiza-
+                 tions  to distribute messages over broad geographic areas, using diverse
+                 computer facilities.  The interest and activity in message  systems  has
+                 now  reached  such proportions that steps have been taken within the DoD
+                 to coordinate and unify the development  of  military  message  systems.
+                 The  use  of electronic mail is expected to increase dramatically in the
+                 next few years.  The utility of such systems in the command and  control
+                 and  intelligence environments is clear, and applications in these areas
+
+
+
+
+
+
+
+
+
+
+
+                                                   -2-
+
+
+                 will probably lead the way.  As the costs for sending and handling elec-
+                 tronic messages continue their rapid decrease, such uses can be expected
+                 to spread rapidly into other areas and, of course, will not  be  limited
+                 to the DoD.
+
+                      A message system provides tools that  help  users  (individuals  or
+                 organizations)  deal  with  messages  in various ways.  Messages must be
+                 composed, sent, received, stored, retrieved, forwarded, and replied  to.
+                 Today's  best  interactive  computer  systems provide a variety of word-
+                 processing and information handling capabilities.  The message  handling
+                 facilities  should be well integrated with the rest of the system, so as
+                 to be a graceful extension of overall system capability.
+
+                      The message system described in this report, _M_H, provides  most  of
+                 the  features that can be found in other message systems and also incor-
+                 porates some new ones.  It has been built on the UNIX time-sharing  sys-
+                 tem[2],  a  popular  operating  system  for the DEC PDP-11[1] and VAX-11
+                 classes of computers.  A "secure" operating system similar  to  UNIX  is
+                 currently being developed[3], and that system will also run _M_H.
+
+                      This report provides a complete description  of  _M_H  and  thus  may
+                 serve  as  a  user's  manual,  although  parts  of the report will be of
+                 interest to non-users as well.  Sections  2  and  3,  the  Overview  and
+                 Tutorial,  present  the key ideas of _M_H and will give those not familiar
+                 with message systems an idea of what such systems are like.
+
+                      _M_H consists of a set of commands which use some special  files  and
+                 conventions.   The final section is divided into three parts.  The first
+                 part covers the information a user needs to know in addition to the com-
+                 mands.   Then, each of the _M_H commands is described in detail.  Finally,
+                 other obscure details are revealed.  A summary of the commands is  given
+                 in  Appendix A, and the syntax of message sequences is given in Appendix
+                 B.
+
+                      A novel approach has been taken in the design of  _M_H.   Instead  of
+                 creating  a large subsystem that appears as a single command to the user
+                 (such as MS[4]), _M_H is a collection of separate commands which  are  run
+                 as  separate  programs.   The file and directory system of UNIX are used
+                 directly.  Messages are stored as individual files (datasets), and  col-
+                 lections  of them are grouped into directories.  In contrast, most other
+                 message systems store messages in a complicated data structure within  a
+                 monolithic file.  With the _M_H approach, UNIX commands can be interleaved
+                 with commands invoking the  functions  of  the  message  handler.   Con-
+                 versely, existing UNIX commands can be used in connection with messages.
+                 For example, all the usual UNIX editing, text-formatting,  and  printing
+                 facilities  can  be applied directly to individual messages.  MH, there-
+                 fore, consists of a relatively small amount of new code; it makes exten-
+                 sive  use  of  other  UNIX software to provide the capabilities found in
+
+
+                    [1] PDP and VAX are trademarks of Digital Equipment Corporation.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -3-
+
+
+                 other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                               _2. _O_V_E_R_V_I_E_W
+
+
+
+
+
+                      There are three main aspects  of  _M_H :   the   way   messages   are
+                 stored  (the  message  database),  the user's profile (which directs how
+                 certain actions of the message handler take place), and the commands for
+                 dealing with messages.
+
+                      Under _M_H, each message is stored as a separate file.   A  user  can
+                 take  any  action  with a message that he could with an ordinary file in
+                 UNIX.  A UNIX directory in which messages are stored is called a folder.
+                 Each  folder  contains  some  standard  entries  to support the message-
+                 handling functions.  The messages in  a  folder  have  numerical  names.
+                 These  folders (directories) are entries in a particular directory path,
+                 described in the user profile, through which _M_H can find  message  fold-
+                 ers.   Using  the UNIX "link" facility, it is possible for one copy of a
+                 message to be "filed" in more than one folder, providing a message index
+                 facility.   Also, using the UNIX tree-structured file system, it is pos-
+                 sible to have a folder within a folder,  nested  arbitrarily  deep,  and
+                 have the full power of the _M_H commands available.
+
+                      Each user of _M_H has a user profile, a file in  his  $HOME  (initial
+                 login)  directory  called  ._m_h__p_r_o_f_i_l_e.   This  profile contains several
+                 pieces of information used by the _M_H commands: a path name to the direc-
+                 tory  that  contains  the  message folders and parameters that tailor _M_H
+                 commands to the individual user's requirements.  There is  also  another
+                 file,  called  the  user  context, which contains information concerning
+                 which folder the user last referenced (the "current" folder).   It  also
+                 contains most of the necessary state information concerning how the user
+                 is dealing with his messages, enabling _M_H to be implemented as a set  of
+                 individual  UNIX commands, in contrast to the usual approach of a monol-
+                 ithic subsystem.
+
+                      In _M_H, incoming mail is appended to the end of a file in  a  system
+                 spooling  area  for  the user.  This area is called the mail drop direc-
+                 tory, and the file is called the user's mail drop.   Normally  when  the
+                 user  logins  in, s/he is informed of new mail (or the _M_H program _m_s_g_c_h_k
+                 may be run).  The user adds the new messages to his/her collection of _M_H
+                 messages  by  invoking  the  command _i_n_c.  The _i_n_c (incorporate) command
+                 adds the new messages to a folder called "inbox", assigning  them  names
+                 which  are  consecutive  integers starting with the next highest integer
+                 available in inbox.  _i_n_c also produces a _s_c_a_n summary  of  the  messages
+                 thus  incorporated.   A  folder can be compacted into a single file, for
+                 easy storage, by using the  _p_a_c_k_f  command.   Also,  messages  within  a
+                 folder can be sorted by date and time with the _s_o_r_t_m command.
+
+
+                      There are four commands for examining the  messages  in  a  folder:
+                 _s_h_o_w,  _p_r_e_v,  _n_e_x_t,  and _s_c_a_n.  The _s_h_o_w command displays a message in a
+
+                                                   -4-
+
+
+
+
+
+
+
+
+
+                                                   -5-
+
+
+                 folder, _p_r_e_v displays the message preceding  the  current  message,  and
+                 _n_e_x_t  displays  the  message following the current message.  _M_H lets the
+                 user choose the program that displays individual  messages.   A  special
+                 program,  _m_h_l,  can  be used to display messages according to the user's
+                 preferences.  The _s_c_a_n command summarizes the messages in a folder, nor-
+                 mally  producing  one line per message, showing who the message is from,
+                 the date, the subject, etc.
+
+                      The user may move a message from one folder  to  another  with  the
+                 command  _r_e_f_i_l_e.   Messages may be removed from a folder by means of the
+                 command _r_m_m.  In addition, a user may query what the current  folder  is
+                 and may specify that a new folder become the current folder, through the
+                 command _f_o_l_d_e_r.  All folders may be summarized with the _f_o_l_d_e_r_s command.
+                 A  message  folder (or subfolder) may be removed by means of the command
+                 _r_m_f.
+
+                      A set of messages based on content may be selected by  use  of  the
+                 command  _p_i_c_k.   This  command searches through messages in a folder and
+                 selects those that match a given set of criteria.   These  messages  are
+                 then  bound  to  a  "sequence" name for use with other _M_H commands.  The
+                 _m_a_r_k command manipulates these sequences.
+
+                      There are five commands enabling the user to  create  new  messages
+                 and  send them: _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l, and _s_e_n_d.  The _c_o_m_p command pro-
+                 vides the facility for the user to compose a new message; _d_i_s_t redistri-
+                 butes  mail  to  additional addressees; _f_o_r_w enables the user to forward
+                 messages; and _r_e_p_l facilitates the generation of a reply to an  incoming
+                 message.   The  last three commands may optionally annotate the original
+                 message.  Messages may be arbitrarily annotated with the  _a_n_n_o  command.
+                 Once  a  draft has been constructed by one of the four above composition
+                 programs, a user-specifiable program is run to query the user as to  the
+                 disposition of the draft prior to sending.  _M_H provides the simple _w_h_a_t_-
+                 _n_o_w program to start users off.  If a message is not  sent  directly  by
+                 one  of these commands, it may be sent at a later time using the command
+                 _s_e_n_d.  _M_H allows the use of any UNIX editor when  composing  a  message.
+                 For rapid entry, a special editor, _p_r_o_m_p_t_e_r, is provided.  For programs,
+                 a special mail-sending program, _m_h_m_a_i_l, is provided.
+
+                      _M_H supports a personal aliasing  facility  which  gives  users  the
+                 capability  to  considerably  shorten  address typein and use meaningful
+                 names for addresses.  The _a_l_i program can be used to query _M_H as to  the
+                 expansion of a list of aliases.  After composing a message, but prior to
+                 sending, the _w_h_o_m command can be used to determine exactly who a message
+                 would go to.
+
+                      _M_H provides a natural interface for telling the  user's  shell  the
+                 names  of  _M_H  messages  and  folders.  The _m_h_p_a_t_h program achieves this
+                 capability.
+
+                      Finally, _M_H supports the UCI BBoards facility.  _b_b_c can be used  to
+                 query  the  status  of a group of BBoards, while _m_s_h can be used to read
+                 them.  The _b_u_r_s_t command can be used to "shred" digests of messages into
+
+
+
+
+
+
+
+
+
+
+
+                                                   -6-
+
+
+                 individual messages.
+
+                      All of the elements summarized above are described in  more  detail
+                 in  the  following sections.  Many of the normal facilities of UNIX pro-
+                 vide additional capabilities for dealing with messages in various  ways.
+                 For  example,  it  is  possible  to  print  messages on the line-printer
+                 without requiring any additional code within _M_H .  Using  standard  UNIX
+                 facilities, any terminal output can be redirected to a file for repeated
+                 or future viewing.  In general, the flexibility and capabilities of  the
+                 UNIX  interface  with the user are preserved as a result of the integra-
+                 tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                               _3. _T_U_T_O_R_I_A_L
+
+
+
+
+
+                      This tutorial provides a brief introduction to the _M_H commands.  It
+                 should  be sufficient to allow the user to read his mail, do some simple
+                 manipulations of it, and create and send messages.
+
+                      A message has two major pieces:  the header and the body.  The body
+                 consists  of the text of the message (whatever you care to type in).  It
+                 follows the header and is separated from it by an empty line.  (When you
+                 compose  a  message, the form that appears on your terminal shows a line
+                 of dashes after the header.  This is for convenience and is replaced  by
+                 an  empty  line  when  the  message is sent.)  The header is composed of
+                 several components, including the subject of the message and the  person
+                 to whom it is addressed.  Each component starts with a name and a colon;
+                 components must not start with a blank.  The text of the  component  may
+                 take  more  than  one line, but each continuation line must start with a
+                 blank.  Messages typically have "To:", "cc:", and "Subject:" components.
+                 When  composing  a  message, you should include the "To:" and "Subject:"
+                 components; the "cc:" (for people you want to send  copies  to)  is  not
+                 necessary.
+
+                      The basic _M_H commands are _i_n_c, _s_c_a_n, _s_h_o_w, _n_e_x_t, _p_r_e_v,  _r_m_m,  _c_o_m_p,
+                 and _r_e_p_l.  These are described below.
+
+                 _i_n_c
+
+                      When you get the message "You have mail",  type  the  command  _i_n_c.
+                 You will get a "scan listing" such as:
+
+                      7+   7/13  Cas      revival of measurement work
+                      8   10/ 9  Norm     NBS people and publications
+                      9   11/26  To:norm  question <<Are there any functions
+
+                      This shows the messages you received since the last time  you  exe-
+                 cuted  this  command (_i_n_c adds these new messages to your inbox folder).
+                 You can see this list again, plus a list of any other messages you have,
+                 by using the _s_c_a_n command.
+
+                 _s_c_a_n
+
+                      The scan listing shows the message number, followed by the date and
+                 the  sender.   (If  you  are the sender, the addressee in the "To:" com-
+                 ponent is displayed.  You may send yourself a message by including  your
+                 name  among  the "To:" or "cc:" addressees.) It also shows the message's
+                 subject; if the subject is short, the first part of the body of the mes-
+                 sage is included after the characters <<.
+
+
+
+                                                   -7-
+
+
+
+
+
+
+
+
+
+                                                   -8-
+
+
+                 _s_h_o_w
+
+                      This command shows the current message, that is, the first  one  of
+                 the  new messages after an _i_n_c.  If the message is not specified by name
+                 (number), it is generally the last message referred to by an _M_H command.
+                 For example,
+
+
+                      _s_h_o_w 5      will show message 5.
+
+
+                      You can use the show command to copy a message or print a message.
+
+
+                      _s_h_o_w > _x    will copy the message to file x.
+                      _s_h_o_w | _l_p_r  will print the message, using the _l_p_r command.
+                      _n_e_x_t        will show the message that follows the current message.
+                      _p_r_e_v        will show the message previous to the current message.
+                      _r_m_m         will remove the current message.
+                      _r_m_m _3       will remove message 3.
+
+
+                 _c_o_m_p
+
+                      The _c_o_m_p command puts you in the editor to write or edit a message.
+                 Fill  in or delete the "To:", "cc:", and "Subject:" fields, as appropri-
+                 ate, and type the body of the message.  Then exit normally from the edi-
+                 tor.   You will be asked "What now?".  Type a carriage return to see the
+                 options.  Typing send will cause the message to  be  sent;  typing  quit
+                 will cause an exit from _c_o_m_p, with the message draft saved.
+
+                      If you quit without sending the message, it will be saved in a file
+                 called  <name>/Mail/draft  (where  <name> is your $HOME directory).  You
+                 can resume editing the message later with "comp -use"; or you  can  send
+                 the message later, using the _s_e_n_d command.
+
+                 _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+                      This command uses a different editor and is  useful  for  preparing
+                 "quick  and  dirty"  messages.  It prompts you for each component of the
+                 header.  Type the information for that component,  or  type  a  carriage
+                 return to omit the component.  After that, type the body of the message.
+                 Backspacing is the only form of editing allowed with this editor.   When
+                 the  body is complete, type a carriage return followed by <EOT> (usually
+                 <CTRL-D>).  This completes the initial preparation of the message;  from
+                 then on, use the same procedures as with _c_o_m_p (above).
+
+                 _r_e_p_l
+                 _r_e_p_l n
+
+                      This command makes up an initial message form with a header that is
+                 appropriate  for  replying  to  an  existing message.  The message being
+
+
+
+
+
+
+
+
+
+
+
+                                                   -9-
+
+
+                 answered is the current message if no message number is mentioned, or  n
+                 if a number is specified.  After the header is completed, you can finish
+                 the message as in _c_o_m_p (above).
+
+                      This is enough information to get you going using  _M_H.   There  are
+                 more commands, and the commands described here have more features.  Sub-
+                 sequent sections explain _M_H in complete detail.   The  system  is  quite
+                 powerful  if you want to use its sophisticated features, but the forego-
+                 ing commands suffice for sending and receiving messages.
+
+                      There are numerous additional capabilities you may wish to explore.
+                 For  example, the _p_i_c_k command will select a subset of messages based on
+                 specified criteria such as sender and/or subject.   Groups  of  messages
+                 may  be  designated, as described in Sec. IV, under Message Naming.  The
+                 file ._m_h__p_r_o_f_i_l_e can be used to tailor your use of the message system to
+                 your needs and preferences, as described in Sec. IV, under The User Pro-
+                 file.  In general, you may  learn  additional  features  of  the  system
+                 selectively,  according  to  your requirements, by studying the relevant
+                 sections of this manual.  There is no need to learn all the  details  of
+                 the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         _4. _D_E_T_A_I_L_E_D _D_E_S_C_R_I_P_T_I_O_N
+
+
+
+
+
+                      This section describes the _M_H system in detail, including the  com-
+                 ponents  of  the  user  profile, the conventions for message naming, and
+                 some of the other _M_H conventions.  Readers who  are  generally  familiar
+                 with  computer  systems  will  be  able  to  follow the principal ideas,
+                 although some details may be meaningful  only  to  those  familiar  with
+                 UNIX.
+
+
+                 _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+                      The first time an _M_H command is issued by a new  user,  the  system
+                 prompts for a "Path" and creates an _M_H "profile".
+
+                      Each _M_H user has a profile which contains tailoring information for
+                 each  individual  program.   Other  profile  entries control the _M_H path
+                 (where folders and special files are kept), folder and  message  protec-
+                 tions,  editor  selection,  and  default  arguments for each _M_H program.
+                 Each user of _M_H also has a context file  which  contains  current  state
+                 information for the _M_H package (the location of the context file is kept
+                 in the user's _M_H directory, or may be named in the user profile).   When
+                 a  folder  becomes the current folder, it is recorded in the user's con-
+                 text.  (Other state information is kept in the  context  file,  see  the
+                 manual  entry for _m_h-_p_r_o_f_i_l_e (5) for more details.) In general, the term
+                 "profile entry" refer to entries in either the profile or context  file.
+                 Users of _M_H needn't worry about the distinction, _M_H handles these things
+                 automatically.
+
+                      The _M_H profile is stored in the  file  ._m_h__p_r_o_f_i_l_e  in  the  user's
+                 $HOME directory[1].  It has the format of a message  without  any  body.
+                 That is, each profile entry is on one line, with a keyword followed by a
+                 colon (:) followed by text particular to the keyword.
+                 =>   _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t _h_a_v_e _b_l_a_n_k _l_i_n_e_s.
+                 The keywords may have any combination of upper and lower case.  (See the
+                 information of _m_h-_m_a_i_l later on in this manual for a description of mes-
+                 sage formats.)
+
+                      For the average _M_H user, the only profile entry  of  importance  is
+                 "Path".   Path  specifies  a  directory  in which _M_H folders and certain
+                 files such as "draft" are found.  The argument to this keyword must be a
+                 legal  UNIX  path that names an existing directory.  If this path is not
+                 absolute (i.e., does not begin with a / ), it will be presumed to  start
+
+
+                    [1] By defining the envariable $MH, you can specify an alternate pro-
+                 file to be used by _M_H commands.
+
+
+                                                   -10-
+
+
+
+
+
+
+
+
+
+                                                   -11-
+
+
+                 from the user's $HOME directory.   All  folder  and  message  references
+                 within _M_H will relate to this path unless full path names are used.
+
+                      Message protection defaults to 644, and folder protection  to  711.
+                 These  may  be  changed  by  profile  entries "Msg-Protect" and "Folder-
+                 Protect", respectively.  The argument to  these  keywords  is  an  octal
+                 number which is used as the UNIX file mode[2].
+
+                      When an _M_H program starts running, it looks through the user's pro-
+                 file for an entry with a keyword matching the program's name.  For exam-
+                 ple, when _c_o_m_p is run, it looks for a "comp" profile entry.  If  one  is
+                 found,  the text of the profile entry is used as the default switch set-
+                 ting until all defaults are overridden by explicit  switches  passed  to
+                 the     program     as    arguments.     Thus    the    profile    entry
+                 "comp: -form standard.list"  would  direct  _c_o_m_p   to   use   the   file
+                 "standard.list"  as the message skeleton.  If an explicit form switch is
+                 given to the _c_o_m_p command, it will override the switch obtained from the
+                 profile.
+
+                      In UNIX, a program may exist under several names, either by linking
+                 or  aliasing.   The actual invocation name is used by an _M_H program when
+                 scanning for its profile defaults[3].  Thus, each _M_H  program  may  have
+                 several  names by which it can be invoked, and each name may have a dif-
+                 ferent set of default switches.  For example, if _c_o_m_p is invoked by  the
+                 name  _i_c_o_m_p, the profile entry "icomp" will control the default switches
+                 for this invocation of the  _c_o_m_p  program.   This  provides  a  powerful
+                 definitional facility for commonly used switch settings.
+
+                      The default editor for editing within _c_o_m_p, _r_e_p_l, _f_o_r_w,  and  _d_i_s_t,
+                 is  usually  _p_r_o_m_p_t_e_r, but might be something else at your site, such as
+                 /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e.  A different editor may be used by specifying the
+                 profile  entry  "Editor:  ".  The argument to "Editor" is the name of an
+                 executable program or shell command file which  can  be  found  via  the
+                 user's  $PATH defined search path, excluding the current directory.  The
+                 "Editor:"  profile  specification  may  in  turn  be  overridden  by   a
+                 `-editor <editor>'  profile  switch associated with _c_o_m_p, _r_e_p_l, _f_o_r_w, or
+                 _d_i_s_t.  Finally, an explicit editor switch specified with  any  of  these
+                 four commands will have ultimate precedence.
+
+                      During message composition, more than one editor may be used.   For
+                 example,  one  editor  (such  as _p_r_o_m_p_t_e_r ) may be used initially, and a
+
+
+                    [2] See _c_h_m_o_d (1) in the _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+                    [3] Unfortunately, the shell does not preserve  aliasing  information
+                 when  calling  a program, hence if a program is invoked by an alias dif-
+                 ferent than its name, the program will examine  the  profile  entry  for
+                 it's name, not the alias that the user invoked it as.  The correct solu-
+                 tion is to create a (soft) link in your $_H_O_M_E/_b_i_n directory  to  the  _M_H
+                 program  of  your choice.  By giving this link a different name, you can
+                 use an alternate set of defaults for the command.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -12-
+
+
+                 second editor may be invoked later to revise the message being  composed
+                 (see  the discussion of _c_o_m_p in Section 5 for details).  A profile entry
+                 "<lasteditor>-next: <editor>" specifies the name of  the  editor  to  be
+                 used  after  a  particular  editor.  Thus "comp: -e prompter" causes the
+                 initial text  to  be  collected  by  _p_r_o_m_p_t_e_r,  and  the  profile  entry
+                 "prompter-next: ed"  names  ed  as the editor to be invoked for the next
+                 round of editing.
+
+                      Some of the _M_H commands, such as _s_h_o_w, can be used on message fold-
+                 ers owned by others, if those folders are readable.  However, you cannot
+                 write in someone else's folder.  All the _M_H command actions not  requir-
+                 ing write permission may be used with a "read-only" folder.
+
+                      Table 1 lists examples of some of  the  currently  defined  profile
+                 entries, typical arguments, and the programs that reference the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -13-
+
+
+                                                 Table 1
+
+                                            PROFILE COMPONENTS
+                          ______________________________________________________
+
+                                                       _M_H Programs that
+                          Keyword and Argument          use Component______________________________________________________
+
+                          Path: Mail                   All
+                          Current-Folder: inbox        Most
+                          Editor: /usr/ucb/ex          _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                          Inbox: inbox                 _i_n_c, _r_m_f
+                          Msg-Protect: 644             _i_n_c
+                          Folder-Protect: 711          _i_n_c, _p_i_c_k, _r_e_f_i_l_e
+                          <program>: default switches  All
+                          prompter-next: ed            _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                          ______________________________________________________
+
+
+                      Path should______ be present.  Current-Folder is maintained automatically
+                 by many _M_H commands (see the Context sections of the individual commands
+                 in Sec. IV).  All other entries are optional, defaulting to  the  values
+                 described above.
+
+
+                 _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+                      Messages may be referred to explicitly or implicitly when using  _M_H
+                 commands.   A formal syntax of message names is given in Appendix B, but
+                 the following description should be sufficient for most _M_H users.   Some
+                 details  of  message  naming  that  apply  only  to certain commands are
+                 included in the description of those commands.
+
+                      Most of the _M_H commands accept arguments  specifying  one  or  more
+                 folders,  and  one  or more messages to operate on.  The use of the word
+                 "msg" as an argument to a command means that exactly  one  message  name
+                 may  be  specified.   A  message name may be a number, such as 1, 33, or
+                 234, or it may be one of the  "reserved"  message  names:  first,  last,
+                 prev,  next,  and  cur.   (As a shorthand, a period (.) is equivalent to
+                 cur.) The meanings of these names are straightforward:  "first"  is  the
+                 first  message  in the folder; "last" is the last message in the folder;
+                 "prev" is the message  numerically  previous  to  the  current  message;
+                 "next"  is  the message numerically following the current message; "cur"
+                 (or ".") is the current message in the folder.  In addition, _M_H supports
+                 user-defined-sequences; see the description of the _m_a_r_k command for more
+                 information.
+
+                      The default in commands that take a "msg" argument is always "cur".
+
+                      The word "msgs" indicates that several messages may  be  specified.
+                 Such  a specification consists of several message designations separated
+                 by spaces.  A message designation is either a message name or a  message
+
+
+
+
+
+
+
+
+
+
+
+                                                   -14-
+
+
+                 range.   A  message  range is a specification of the form name1-name2 or
+                 name1:n, where name1 and name2 are message names and n  is  an  integer.
+                 The  first  form  designates  all  the  messages  from  name1  to  name2
+                 inclusive; this must be a non-empty range.  The second form specifies up
+                 to  n messages, starting with name1 if name1 is a number, or first, cur,
+                 or next, and ending with name1 if name1 is last or prev.  This interpre-
+                 tation  of  n  is  overridden if n is preceded by a plus sign or a minus
+                 sign; +n always means up to n  messages  starting  with  name1,  and  -n
+                 always  means  up  to n messages ending with name1.  Repeated specifica-
+                 tions of the same message have the same effect as a single specification
+                 of the message.  Examples of specifications are:
+
+
+                     1 5 7-11 22
+                     first 6 8 next
+                     first-10
+                     last:5
+
+
+                      The message name "all" is a shorthand for "first-last",  indicating
+                 all of the messages in the folder.
+
+                      In commands that accept "msgs" arguments, the default is either cur
+                 or all, depending on which makes more sense.
+
+                      In all of the _M_H commands, a plus sign preceding an argument  indi-
+                 cates  a folder name.  Thus, "+inbox" is the name of the user's standard
+                 inbox.  If an explicit folder argument is given to  an  _M_H  command,  it
+                 will  become the current folder (that is, the "Current-Folder:" entry in
+                 the user's profile will be changed to this folder).  In the case of  the
+                 _r_e_f_i_l_e  command,  which  can  have multiple output folders, a new source
+                 folder  (other  than  the  default  current  folder)  is  specified   by
+                 `-src +folder'.
+
+
+                 _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+                      One very powerful feature of _M_H is that  the  _M_H  commands  may  be
+                 issued  from any current directory, and the proper path to the appropri-
+                 ate folder(s) will be taken from the user's profile.  If the _M_H path  is
+                 not  appropriate for a specific folder or file, the automatic prepending
+                 of the _M_H path can be avoided by beginning a folder or file name with /,
+                 or  with  ./  or  ../ component.  Thus any specific absolute path may be
+                 specified along with any path relative to the current working directory.
+
+                      Arguments to the various programs may be given in any  order,  with
+                 the exception of a few switches whose arguments must follow immediately,
+                 such as `-src +folder' for _r_e_f_i_l_e.
+
+                      Whenever an _M_H command prompts the user, the valid options will  be
+                 listed  in  response to a <RETURN>.  (The first of the listed options is
+                 the default if end-of-file is encountered, such as from a command file.)
+
+
+
+
+
+
+
+
+
+
+
+                                                   -15-
+
+
+                 A  valid  response  is  any  _u_n_i_q_u_e  abbreviation  of  one of the listed
+                 options.
+
+                      Standard UNIX documentation conventions are used in this report  to
+                 describe  _M_H  command  syntax.  Arguments enclosed in brackets ([ ]) are
+                 optional; exactly one of the arguments enclosed within braces ({ }) must
+                 be specified, and all other arguments are required.  The use of ellipsis
+                 dots (...) indicates zero or more repetitions of the previous item.  For
+                 example,  "+folder  ..." would indicate that one or more "+folder" argu-
+                 ments is required and "[+folder ...]" indicates that 0 or more "+folder"
+                 arguments may be given.
+
+                      _M_H departs from UNIX standards by using switches  that  consist  of
+                 more  than  one  character,  e.g. `-header'.  To minimize typing, only a
+                 unique abbreviation of a switch need  be  typed;  thus,  for  `-header',
+                 `-hea'  is probably sufficient, depending on the other switches the com-
+                 mand accepts.  Each _M_H program accepts the switch `-help' (which must be
+                 spelled  out  fully)  and  produces  a  syntax description and a list of
+                 switches.  In the list of switches, parentheses indicate required  char-
+                 acters.   For  example,  all  `-help' switches will appear as "-(help)",
+                 indicating that no abbreviation is accepted.  Furthermore,  the  `-help'
+                 switch tells the version of the _M_H program you invoked.
+
+                      Many _M_H switches have both on and off forms, such as `-format'  and
+                 `-noformat'.  In many of the descriptions which follow, only one form is
+                 defined; the other form, often used to nullify profile switch  settings,
+                 is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -16-
+
+
+                 _M_H _C_O_M_M_A_N_D_S
+
+                      The _M_H package comprises several programs:
+
+                      ali (1)        - list mail aliases
+                      anno (1)       - annotate messages
+                      bbc (1)        - check on BBoards
+                      bboards (1)    - the UCI BBoards facility
+                      burst (1)      - explode digests into messages
+                      comp (1)       - compose a message
+                      dist (1)       - redistribute a message to additional addresses
+                      folder (1)     - set/list current folder/message
+                      folders (1)    - list all folders
+                      forw (1)       - forward messages
+                      inc (1)        - incorporate new mail
+                      mark (1)       - mark messages
+                      mhl (1)        - produce formatted listings of MH messages
+                      mhmail (1)     - send or read mail
+                      mhook (1)      - MH receive-mail hooks
+                      mhparam (1)    - print MH profile components
+                      mhpath (1)     - print full pathnames of MH messages and folders
+                      msgchk (1)     - check for messages
+                      msh (1)        - MH shell (and BBoard reader)
+                      next (1)       - show the next message
+                      packf (1)      - compress a folder into a single file
+                      pick (1)       - select messages by content
+                      prev (1)       - show the previous message
+                      prompter (1)   - prompting editor front end
+                      rcvstore (1)   - incorporate new mail asynchronously
+                      refile (1)     - file messages in other folders
+                      repl (1)       - reply to a message
+                      rmf (1)        - remove folder
+                      rmm (1)        - remove messages
+                      scan (1)       - produce a one line per message scan listing
+                      send (1)       - send a message
+                      show (1)       - show (list) messages
+                      slocal (1)     - special local mail delivery
+                      sortm (1)      - sort messages
+                      vmh (1)        - visual front-end to MH
+                      whatnow (1)    - prompting front-end for send
+                      whom (1)       - report to whom a message would go
+
+
+                      These programs are described below.  The form of  the  descriptions
+            conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            ALI(1)                            -17-                            ALI(1)
+
+
+            _N_A_M_E
+                 ali - list mail aliases
+
+            _S_Y_N_O_P_S_I_S
+                 ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+                      [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_l_i searches the named mail alias  files  for  each  of  the  given
+                 _a_l_i_a_s_e_s.   It  creates  a  list of addresses for those _a_l_i_a_s_e_s, and
+                 writes that list on standard output.   If  the  `-list'  option  is
+                 specified,  each address appears on a separate line; otherwise, the
+                 addresses are separated by commas and printed on as  few  lines  as
+                 possible.
+
+                 The `-user' option directs _a_l_i to  perform  its  processing  in  an
+                 inverted  fashion: instead of listing the addresses that each given
+                 alias expands to, _a_l_i will list the aliases  that  expand  to  each
+                 given  address.   If the `-normalize' switch is given, _a_l_i will try
+                 to track down the official hostname of the address.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read.  Each _a_l_i_a_s is processed as described in _m_h-_a_l_i_a_s (5).
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /etc/passwd                          List of users
+                 /etc/group                           List of groups
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Aliasfile:           For a default alias file
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-alias /usr/bs/mh-6.8/lib/MailAliases'
+                 `-nolist'
+                 `-nonormalize'
+                 `-nouser'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ALI(1)                            -18-                            ALI(1)
+
+
+            _B_u_g_s
+                 The `-user' option with `-nonormalize' is not entirely accurate, as
+                 it  does  not replace local nicknames for hosts with their official
+                 site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ANNO(1)                           -19-                           ANNO(1)
+
+
+            _N_A_M_E
+                 anno - annotate messages
+
+            _S_Y_N_O_P_S_I_S
+                 anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+                      [-date] [-nodate] [-text body] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_n_n_o annotates the specified messages in the named folder using the
+                 field  and body.  Annotation is optionally performed by _d_i_s_t, _f_o_r_w,
+                 and _r_e_p_l, to keep track of your distribution of, forwarding of, and
+                 replies  to  a  message.   By using _a_n_n_o, you can perform arbitrary
+                 annotations of your own.  Each message selected will  be  annotated
+                 with the lines
+
+                     field: date
+                     field: body
+
+                 The `-nodate' switch inhibits the date annotation, leaving only the
+                 body  annotation.   The  `-inplace'  switch causes annotation to be
+                 done in place in order to preserve links to the annotated message.
+
+                 The field specified should be a valid 822-style message field name,
+                 which  means  that  it  should consist of alphanumerics (or dashes)
+                 only.  The body specified is arbitrary text.
+
+                 If a `-component field' is not specified when _a_n_n_o is invoked, _a_n_n_o
+                 will prompt the user for the name of field for the annotation.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 dist (1), forw (1), repl (1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noinplace'
+                 `-date'
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ANNO(1)                           -20-                           ANNO(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -21-                            BBC(1)
+
+
+            _N_A_M_E
+                 bbc - check on BBoards
+
+            _S_Y_N_O_P_S_I_S
+                 bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+                      [-archive] [-noarchive] [-protocol] [-noprotocol]
+                      [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+                      [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+                      [-host host] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _b_b_c is a BBoard reading/checking program  that  interfaces  to  the
+                 BBoard channel.
+
+                 The _b_b_c program has three action switches which direct  its  opera-
+                 tion:
+
+                 The `-read' switch invokes the _m_s_h program on  the  named  _B_B_o_a_r_d_s.
+                 If  you  also  specify the `-archive' switch, then  _b_b_c will invoke
+                 the _m_s_h program on the  archives  of  the  named  _B_B_o_a_r_d_s.   If  no
+                 _B_B_o_a_r_d_s   are   given  on  the  command  line,  and  you  specified
+                 `-archive', _b_b_c will not read your  `bboards'  profile  entry,  but
+                 will read the archives of the "system" _B_B_o_a_r_d instead.
+
+                 The `-check' switch types out  status  information  for  the  named
+                 _B_B_o_a_r_d_s.   _b_b_c  can  print one of several messages depending on the
+                 status of both the BBoard and the user's reading  habits.  As  with
+                 each  of these messages, the number given is the item number of the
+                 last item placed in the BBoard.  This number (which  is  marked  in
+                 the  messages  as the "BBoard-Id") is ever increasing.  Hence, when
+                 _b_b_c says "n items", it really means that the highest  BBoard-Id  is
+                 "n".   There  may,  or may not actually be "n" items in the BBoard.
+                 Some common messages are:
+
+                      BBoard -- n items unseen
+                           This message tells how many items the user  has  not  yet
+                           seen.  When invoked with the `-quiet' switch, this is the
+                           only informative line that _b_b_c will possibly print out.
+
+                      BBoard -- empty
+                           The BBoard is empty.
+
+                      BBoard -- n items (none seen)
+                           The BBoard has items in it, but the user hasn't seen any.
+
+                      BBoard -- n items (all seen)
+                           The BBoard is non-empty, and the user has seen everything
+                           in it.
+
+                      BBoard -- n items seen out of m
+                           The BBoard has at most m-n items that the  user  has  not
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -22-                            BBC(1)
+
+
+                           seen.
+
+                 The `-topics' switch directs _b_b_c to print  three  items  about  the
+                 named _B_B_o_a_r_d_s: it's official name, the number of items present, and
+                 the date and time of the last update.  If  no  _B_B_o_a_r_d_s  are  named,
+                 then  all  BBoards  are listed.  If the `-verbose' switch is given,
+                 more information is output.
+
+                 The `-quiet' switch specifies that  _b_b_c  should  be  silent  if  no
+                 _B_B_o_a_r_d_s  are  found  with  new  information.  The `-verbose' switch
+                 specifies that _b_b_c is to consider you to be interested  in  _B_B_o_a_r_d_s
+                 that you've already seen everything in.
+
+                 To override the default _m_s_h_p_r_o_c and  the  profile  entry,  use  the
+                 `-mshproc program' switch.  Any arguments not understood by _b_b_c are
+                 passed to this program.  The `-protocol' switch tells _b_b_c that your
+                 _m_s_h_p_r_o_c  knows  about  the  special _b_b_c protocol for reporting back
+                 information.  _m_s_h (1), the default _m_s_h_p_r_o_c, knows all about this.
+
+                 The `-file BBoardsfile' switch tells  _b_b_c  to  use  a  non-standard
+                 _B_B_o_a_r_d_s  file  when  performing  its  calculations.  Similarly, the
+                 `-user BBoardsuser' switch tells _b_b_c to use  a  non-standard  user-
+                 name.   Both  of  these  switches  are  useful  for debugging a new
+                 _B_B_o_a_r_d_s or _P_O_P file.
+
+                 If the local host is configured as an NNTP BBoards  client,  or  if
+                 the `-host host' switch is given, then _b_b_c will query the NNTP ser-
+                 vice host as to the  status  of  the  BBoards.   For  NNTP  BBoards
+                 clients, the `-user user' and the `-rpop' switches are ignored.
+
+                 The ._b_b_r_c file in the user's $HOME directory is used to keep  track
+                 of what messages have been read.  The `-rcfile rcfile' switch over-
+                 rides the use of ._b_b_r_c for this purpose.  If the value given to the
+                 switch  is  not absolute, (i.e., does not begin with a / ), it will
+                 be presumed to start from the current working directory.   If  this
+                 switch  is not given (or the `-norcfile' switch is given), then _b_b_c
+                 consults the envariable $MHBBRC, and honors it similarly.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 $HOME/.bbrc                          BBoard "current" message information
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 bboards:             To specify interesting BBoards
+                 mshproc:             Program to read a given BBoard
+
+
+            _S_e_e _A_l_s_o
+                 bbl(1), bboards(1), msh(1)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -23-                            BBC(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-read'
+                 `-noarchive'
+                 `-protocol'
+                 `bboards' defaults to "system"
+                 `-file /usr/bs/mh-6.8/bboards/BBoards'
+                 `-user bboards'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The `-user' switch takes effect only if  followed  by  the  `-file'
+                 switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(1)                        -24-                        BBOARDS(1)
+
+
+            _N_A_M_E
+                 bboards - the UCI BBoards facility
+
+            _S_Y_N_O_P_S_I_S
+                 bbc [-check] [-read] bboards ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The home directory of _b_b_o_a_r_d_s is where the BBoard system  is  kept.
+                 This documentation describes some of the nuances of the BBoard sys-
+                 tem.
+
+                 BBoards, BBoard-IDs
+                      A BBoard is just a file containing a group of messages  relat-
+                      ing  to the same topic.  These files live in the ~bboards home
+                      directory.  Each message in a BBoard file has  in  its  header
+                      the  line  "BBoard-Id:  n",  where "n" is an ascending decimal
+                      number.  This id-number  is  unique  for  each  message  in  a
+                      BBoards  file.   It  should  NOT  be confused with the message
+                      number of a message, which can change as messages are  removed
+                      from the BBoard.
+
+                 BBoard Handling
+                      To read BBoards, use the _b_b_c and _m_s_h programs.  The  _m_s_h  com-
+                      mand  is  a  monolithic  program  which contains all the func-
+                      tionality of _M_H in a single program.  The `-check'  switch  to
+                      _b_b_c  lets  you check on the status of BBoards, and the `-read'
+                      switch tells _b_b_c to invoke _m_s_h to read those BBoards.
+
+                 Creating a BBoard
+                      Both public, and private BBoards are supported.   Contact  the
+                      mail  address  _P_o_s_t_M_a_s_t_e_r  if  you'd  like  to  have  a BBoard
+                      created.
+
+                 BBoard addresses
+                      Each BBoard has associated with it 4 addresses, these are (for
+                      the ficticious BBoard called ``hacks''):
+                        hacks : The Internet wide distribution list.
+                        dist-hacks : The local BBoard.
+                        hacks-request : The people responsible for the BBoard at the
+                             Internet level.
+                        local-hacks-request : The people responsible for the  BBoard
+                             locally.
+
+            _F_i_l_e_s
+                $HOME/.mh_profile                    The user profile
+                $HOME/.bbrc                          BBoard information
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(1)                        -25-                        BBOARDS(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 bboards:             To specify interesting BBoards
+                 mshproc:             Program to read a given BBoard
+
+
+            _S_e_e _A_l_s_o
+                bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 The default bboard is "system"
+
+
+            _C_o_n_t_e_x_t
+                None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BURST(1)                          -26-                          BURST(1)
+
+
+            _N_A_M_E
+                 burst - explode digests into messages
+
+            _S_Y_N_O_P_S_I_S
+                 burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+                      [-verbose] [-noverbose] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _B_u_r_s_t considers the specified messages in the named  folder  to  be
+                 Internet digests, and explodes them in that folder.
+
+                 If `-inplace' is given, each digest is replaced by  the  "table  of
+                 contents"  for  the digest (the original digest is removed).  _B_u_r_s_t
+                 then renumbers all of the messages  following  the  digest  in  the
+                 folder  to  make room for each of the messages contained within the
+                 digest.  These messages are placed immediately after the digest.
+
+                 If `-noinplace' is given, each digest is  preserved,  no  table  of
+                 contents  is produced, and the messages contained within the digest
+                 are placed at the end of the folder.  Other messages are  not  tam-
+                 pered with in any way.
+
+                 The `-quiet' switch directs _b_u_r_s_t to be silent about reporting mes-
+                 sages that are not in digest format.
+
+                 The `-verbose' switch directs _b_u_r_s_t to tell the  user  the  general
+                 actions that it is taking to explode the digest.
+
+                 It turns out that _b_u_r_s_t works equally well  on  forwarded  messages
+                 and  blind-carbon-copies  as on Internet digests, provided that the
+                 former two were generated by _f_o_r_w or _s_e_n_d.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Msg-Protect:         To set mode when creating a new message
+
+
+            _S_e_e _A_l_s_o
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+                 inc(1), msh(1), pack(1)
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BURST(1)                          -27-                          BURST(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noinplace'
+                 `-noquiet'
+                 `-noverbose'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  If  `-in-
+                 place'  is  given, then the first message burst becomes the current
+                 message.  This leaves the context ready for a _s_h_o_w of the table  of
+                 contents  of the digest, and a _n_e_x_t to see the first message of the
+                 digest.  If `-noinplace' is given, then the first message extracted
+                 from  the  first  digest  burst  becomes the current message.  This
+                 leaves the context in a similar, but not identical,  state  to  the
+                 context achieved when using `-inplace'.
+
+
+            _B_u_g_s
+                 The _b_u_r_s_t program enforces a limit on the number of messages  which
+                 may be _b_u_r_s_t from a single message.  This number is on the order of
+                 1000 messages.  There is usually no limit on the number of messages
+                 which may reside in the folder after the _b_u_r_s_ting.
+
+                 Although _b_u_r_s_t uses a sophisticated algorithm  to  determine  where
+                 one  encapsulated message ends and another begins, not all digesti-
+                 fying programs  use  an  encapsulation  algorithm.   In  degenerate
+                 cases, this usually results in _b_u_r_s_t finding an encapsulation boun-
+                 dary prematurely and splitting a single encapsulated  message  into
+                 two or more messages.  These erroneous digestifying programs should
+                 be fixed.
+
+                 Furthermore, any text which appears  after  the  last  encapsulated
+                 message  is not placed in a seperate message by _b_u_r_s_t.  In the case
+                 of digestified messages, this text is usally  an  "End  of  digest"
+                 string.   As  a result of this possibly un-friendly behavior on the
+                 part of _b_u_r_s_t, note that when the `-inplace' option is  used,  this
+                 trailing  information  is lost.  In practice, this is not a problem
+                 since correspondents usually place remarks in  text  prior  to  the
+                 first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            COMP(1)                           -28-                           COMP(1)
+
+
+            _N_A_M_E
+                 comp - compose a message
+
+            _S_Y_N_O_P_S_I_S
+                 comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+                      [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+                      [-form formfile] [-use] [-nouse] [-whatnowproc program]
+                      [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _C_o_m_p is used to create a new message to be  mailed.   It  copies  a
+                 message form to the draft being composed and then invokes an editor
+                 on the draft (unless `-noedit' is given, in which case the  initial
+                 edit is suppressed).
+
+                 The default message form contains the following elements:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 If the file named "components" exists in the user's  MH  directory,
+                 it  will  be  used  instead  of  this  form.  The file specified by
+                 `-form formfile' will be used if given.  You may  also  start  _c_o_m_p
+                 using the contents of an existing message as the form.  If you sup-
+                 ply either a `+folder' or `msg' argument, that message will be used
+                 as  the  form.   You  may  not supply both a `-form formfile' and a
+                 `+folder' or `msg' argument.  The line of dashes or  a  blank  line
+                 must be left between the header and the body of the message for the
+                 message to be identified properly when it is sent  (see  _s_e_n_d (1)).
+                 The  switch  `-use'  directs  _c_o_m_p  to  continue editing an already
+                 started message.  That is, if a _c_o_m_p (or _d_i_s_t, _r_e_p_l, or  _f_o_r_w )  is
+                 terminated without sending the draft, the draft can be edited again
+                 via "comp -use".
+
+                 If the draft already exists, _c_o_m_p will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _c_o_m_p, leaving the
+                 draft intact; replace will replace  the  existing  draft  with  the
+                 appropriate  form;  list  will  display the draft; use will use the
+                 draft for further composition; and  refile +folder  will  file  the
+                 draft  in  the  given  folder,  and  give  you a new draft with the
+                 appropriate form.  (The `+folder' argument to refile is required.)
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 The `-file file' switch says to use the named file as  the  message
+                 draft.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            COMP(1)                           -29-                           COMP(1)
+
+
+                 The `-editor editor' switch indicates the editor  to  use  for  the
+                 initial  edit.   Upon exiting from the editor, _c_o_m_p will invoke the
+                 _w_h_a_t_n_o_w program.  See _w_h_a_t_n_o_w (1) for  a  discussion  of  available
+                 options.   The invocation of this program can be inhibited by using
+                 the `-nowhatnowproc' switch.  (In truth of fact, it is the  _w_h_a_t_n_o_w
+                 program  which  starts  the  initial edit.  Hence, `-nowhatnowproc'
+                 will prevent any edit from occurring.)
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/components        The message skeleton
+                 or <mh-dir>/components               Rather than the standard skeleton
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/draft                       The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to the current message
+                 `-nodraftfolder'
+                 `-nouse'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _c_o_m_p  won't  run
+                 it.
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -30-                           DIST(1)
+
+
+            _N_A_M_E
+                 dist - redistribute a message to additional addresses
+
+            _S_Y_N_O_P_S_I_S
+                 dist [+folder] [msg] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-form formfile] [-inplace]
+                      [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _D_i_s_t is similar to _f_o_r_w.  It prepares  the  specified  message  for
+                 redistribution to addresses that (presumably) are not on the origi-
+                 nal address list.
+
+                 The default message form contains the following elements:
+
+                      Resent-To:
+                      Resent-cc:
+
+                 If the file named "distcomps" exists in the user's MH directory, it
+                 will be used instead of this form.  In either case, the file speci-
+                 fied by `-form formfile' will be used if given.  The form used will
+                 be prepended to the message being resent.
+
+                 If the draft already exists, _d_i_s_t will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _d_i_s_t, leaving the
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 Only   those   addresses   in   "Resent-To:",   "Resent-cc:",   and
+                 "Resent-Bcc:"  will  be sent.  Also, a "Resent-Fcc: folder" will be
+                 honored (see _s_e_n_d (1)).  Note that with _d_i_s_t, the draft should con-
+                 tain  only  "Resent-xxx:"  fields and no body.  The headers and the
+                 body of the original message are copied to the draft when the  mes-
+                 sage  is sent.  Use care in constructing the headers for the redis-
+                 tribution.
+
+                 If the `-annotate' switch is given, the  message being  distributed
+                 will be annotated with the lines:
+
+                      Resent: date
+                      Resent: addrs
+
+                 where each address list contains as many lines as  required.   This
+                 annotation  will  be done only if the message is sent directly from
+                 _d_i_s_t.  If the message is not  sent  immediately  from  _d_i_s_t,  "comp
+                 -use"  may be used to re-edit and send the constructed message, but
+                 the annotations won't take place.   The  '-inplace'  switch  causes
+                 annotation  to  be  done in place in order to preserve links to the
+                 annotated message.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -31-                           DIST(1)
+
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.   Note that while in the editor, the message being resent
+                 is available through a link named "@" (assuming the  default  _w_h_a_t_-
+                 _n_o_w_p_r_o_c ).   In  addition,  the  actual  pathname of the message is
+                 stored in the envariable $editalt, and the pathname of  the  folder
+                 containing the message is stored in the envariable $mhfolder.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _d_i_s_t will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/distcomps         The message skeleton
+                 or <mh-dir>/distcomps                Rather than the standard skeleton
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/draft                       The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 fileproc:            Program to refile the message
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to cur
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noinplace'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  mes-
+                 sage distributed will become the current message.
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -32-                           DIST(1)
+
+
+            _H_i_s_t_o_r_y
+                 _D_i_s_t originally used headers of the form "Distribute-xxx:"  instead
+                 of "Resent-xxx:".  In order to conform with the ARPA Internet stan-
+                 dard, RFC-822, the "Resent-xxx:"  form  is  now  used.   _D_i_s_t  will
+                 recognize  "Distribute-xxx:" type headers and automatically convert
+                 them to "Resent-xxx:".
+
+
+            _B_u_g_s
+                 _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check the message  being  distributed  for
+                 adherence  to the transport standard, but _p_o_s_t called by _s_e_n_d does.
+                 The _p_o_s_t program will balk (and rightly  so)  at  poorly  formatted
+                 messages, and _d_i_s_t won't correct things for you.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _d_i_s_t uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _d_i_s_t  won't  run
+                 it.
+
+                 If your current working directory is not writable, the  link  named
+                 "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -33-                         FOLDER(1)
+
+
+            _N_A_M_E
+                 folder, folders - set/list current folder/message
+
+            _S_Y_N_O_P_S_I_S
+                 folder [+folder] [msg] [-all] [-print] [-fast] [-nofast] [-header]
+                      [-noheader] [-recurse] [-norecurse] [-total] [-nototal]
+                      [-list] [-nolist] [-push] [-pop] [-pack] [-nopack] [-verbose]
+                      [-noverbose] [-help]
+
+                 folders
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Since the _M_H environment is the shell, it is easy to lose track  of
+                 the  current  folder  from  day  to  day.  When _f_o_l_d_e_r is given the
+                 `-print' switch (the default), _f_o_l_d_e_r will list the current folder,
+                 the number of messages in it, the range of the messages (low-high),
+                 and the current message within the  folder,  and  will  flag  extra
+                 files if they exist.  An example of this summary is:
+
+                 inbox+            has  16 messages (  3- 22); cur=  5.
+
+                 If a `+folder' and/or `msg' are specified,  they  will  become  the
+                 current  folder  and/or  message.   If  the  specified (or default)
+                 folder doesn't exist, the user will be queried as  to  whether  the
+                 folder  should  be  created.  When standard input is not a tty, the
+                 folder is created without any query.  (This  is  the  easy  way  to
+                 create an empty folder for use later.)
+
+                 By comparison, when a `+folder' argument is given, this corresponds
+                 to  a  "cd"  operation  in the _s_h_e_l_l; when no `+folder' argument is
+                 given, this corresponds roughly to a "pwd" operation in the _s_h_e_l_l.
+
+
+
+              _M_u_l_t_i_p_l_e _F_o_l_d_e_r_s
+
+                 Specifying `-all' will produce a summary line  for  each  top-level
+                 folder  in  the  user's  MH  directory, sorted alphabetically.  (If
+                 _f_o_l_d_e_r is invoked by a  name  ending  with  "s"  (e.g.,  _f_o_l_d_e_r_s ),
+                 `-all'  is  assumed).   Specifying `-recurse' with `-all' will also
+                 produce a line for all sub-folders.  These folders are all preceded
+                 by  the read-only folders, which occur as "atr-cur-" entries in the
+                 user's _M_H context.  For example,
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -34-                         FOLDER(1)
+
+
+                 Folder               # of messages ( range )  cur msg (other files)
+                 /fsd/rs/m/tacc    has  35 messages (  1- 35); cur= 23.
+                 /rnd/phyl/Mail/EP has  82 messages (  1-108); cur= 82.
+                 ff                has  no messages.
+                 inbox+            has  16 messages (  3- 22); cur=  5.
+                 mh                has  76 messages (  1- 76); cur= 70.
+                 notes             has   2 messages (  1-  2); cur=  1.
+                 ucom              has 124 messages (  1-124); cur=  6; (others).
+                           TOTAL=      339 messages in 7 folders
+
+                 The "+" after inbox indicates that it is the current  folder.   The
+                 "(others)"  indicates that the folder `ucom' has files which aren't
+                 messages.  These files may either be  sub-folders,  or  files  that
+                 don't belong under the MH file naming scheme.
+
+                 The header is output if either a `-all' or a  `-header'  switch  is
+                 specified; it is suppressed by `-noheader'.  A `-total' switch will
+                 produce only the summary line.
+
+                 If `-fast' is given, only the folder name (or names in the case  of
+                 `-all')  will  be listed.  (This is faster because the folders need
+                 not be read.)
+
+                 If a `+folder' is given along with the `-all' switch, _f_o_l_d_e_r  will,
+                 in addition to setting the current folder, list the top-level fold-
+                 ers for the current folder (with `-norecurse')  or  list  all  sub-
+                 folders under the current folder recursively (with `-recurse').  In
+                 this case, if a `msg' is also supplied, it will become the  current
+                 message of `+folder'.
+
+                 The `-recurse' switch lists each folder recursively, so use of this
+                 option  effectively  defeats  the  speed enhancement of the `-fast'
+                 option,  since  each  folder  must  be  searched  for   subfolders.
+                 Nevertheless, the combination of these options is useful.
+
+
+              _C_o_m_p_a_c_t_i_n_g _a _F_o_l_d_e_r
+
+                 The `-pack' switch will compress the message names  in  the  desig-
+                 nated folders, removing holes in message numbering.  The `-verbose'
+                 switch directs _f_o_l_d_e_r to tell the user the general actions that  it
+                 is taking to compress the folder.
+
+
+              _T_h_e _F_o_l_d_e_r _S_t_a_c_k
+
+                 The `-push' switch directs _f_o_l_d_e_r to push the current  folder  onto
+                 the  _f_o_l_d_e_r-_s_t_a_c_k,  and  make  the  `+folder'  argument the current
+                 folder.  If `+folder' is not given, the current folder and the  top
+                 of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged.  This corresponds to the "pushd"
+                 operation in the _C_S_h_e_l_l.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -35-                         FOLDER(1)
+
+
+                 The `-pop'  switch  directs  _f_o_l_d_e_r  to  discard  the  top  of  the
+                 _f_o_l_d_e_r-_s_t_a_c_k,  after  setting the current folder to that value.  No
+                 `+folder' argument is allowed.   This  corresponds  to  the  "popd"
+                 operation  in the _C_S_h_e_l_l.  The `-push' switch and the `-pop' switch
+                 are mutually exclusive: the last occurrence of either one overrides
+                 any  previous occurrence of the other.  Both of these switches also
+                 set `-list' by default.
+
+                 The `-list' switch directs _f_o_l_d_e_r  to  list  the  contents  of  the
+                 _f_o_l_d_e_r-_s_t_a_c_k.   No `+folder' argument is allowed.  After a success-
+                 ful `-push' or `-pop', the `-list' action is taken, unless a `-nol-
+                 ist'  switch follows them on the command line.  This corresponds to
+                 the "dirs" operation in  the  _C_S_h_e_l_l.   The  `-push',  `-pop',  and
+                 `-list' switches turn off `-print'.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Folder-Protect:      To set mode when creating a new folder
+                 Folder-Stack:        To determine the folder stack
+
+
+            _S_e_e _A_l_s_o
+                 refile(1), mhpath(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to none
+                 `-nofast'
+                 `-noheader'
+                 `-nototal'
+                 `-nopack'
+                 `-norecurse'
+                 `-noverbose'
+                 `-print' is the default if no `-list', `-push', or `-pop' is specified
+                 `-list' is the default if `-push', or `-pop' is specified
+
+
+            _C_o_n_t_e_x_t
+                 If `+folder' and/or `msg' are given, they will become  the  current
+                 folder and/or message.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -36-                         FOLDER(1)
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the `-fast'  switch  prevented  context
+                 changes  from  occurring for the current folder.  This is no longer
+                 the case: if `+folder' is given, then _f_o_l_d_e_r will always change the
+                 current folder to that.
+
+
+            _B_u_g_s
+                 `-all' forces `-header'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -37-                           FORW(1)
+
+
+            _N_A_M_E
+                 forw - forward messages
+
+            _S_Y_N_O_P_S_I_S
+                 forw [+folder] [msgs] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-filter filterfile]
+                      [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+                      [-mime] [-nomime] [-whatnowproc program] [-nowhatnowproc]
+                      [-help]
+
+                 forw [+folder] [msgs] [-digest list] [-issue number]
+                      [-volume number] [other switches for _f_o_r_w] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _F_o_r_w may be used to prepare a message  containing  other  messages.
+                 It   constructs  the  new  message  from  the  components  file  or
+                 `-form formfile'  (see  _c_o_m_p ),  with  a  body  composed   of   the
+                 message(s)  to  be forwarded.  An editor is invoked as in _c_o_m_p, and
+                 after editing is complete, the user is prompted before the  message
+                 is sent.
+
+                 The default message form contains the following elements:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 If the file named "forwcomps" exists in the user's MH directory, it
+                 will be used instead of this form.  In either case, the file speci-
+                 fied by `-form formfile' will be used if given.
+
+                 If the draft already exists, _f_o_r_w will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _f_o_r_w, leaving the
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 If the `-annotate' switch is given, each  message  being  forwarded
+                 will be annotated with the lines
+
+                      Forwarded: date
+                      Forwarded: addrs
+
+                 where each address list contains as many lines as  required.   This
+                 annotation  will  be done only if the message is sent directly from
+                 _f_o_r_w.   If  the  message  is  not  sent  immediately   from   _f_o_r_w,
+                 "comp -use"  may  be  used to re-edit and send the constructed mes-
+                 sage, but the annotations won't take place.  The '-inplace'  switch
+                 causes annotation to be done in place in order to preserve links to
+                 the annotated message.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -38-                           FORW(1)
+
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.
+
+                 Although _f_o_r_w uses the `-form formfile' switch to direct it how  to
+                 construct  the  beginning  of  the draft, the `-filter filterfile',
+                 `-format', and `-noformat' switches direct _f_o_r_w as to how each for-
+                 warded  message  should  be formatted in the body of the draft.  If
+                 `-noformat' is specified, then each  forwarded  message  is  output
+                 exactly  as  it  appears.   If `-format' or `-filter filterfile' is
+                 specified, then each forwarded message is  filtered  (re-formatted)
+                 prior  to  being  output to the body of the draft.  The filter file
+                 for _f_o_r_w should be a standard form  file  for  _m_h_l,  as  _f_o_r_w  will
+                 invoke  _m_h_l  to format the forwarded messages.  The default message
+                 filter (what you get with `-format') is:
+
+                      width=80,overflowtext=,overflowoffset=10
+                      leftadjust,compress,compwidth=9
+                      Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+                      From:
+                      To:
+                      cc:
+                      Subject:
+                      :
+                      body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+                 If the file named "mhl.forward" exists in the user's MH  directory,
+                 it  will  be  used  instead of this form.  In either case, the file
+                 specified by `-filter filterfile' will be used if given.   To  sum-
+                 marize:  `-noformat' will reproduce each forwarded message exactly,
+                 `-format' will use _m_h_l and a default filterfile, "mhl.forward",  to
+                 format  each  forwarded  message, and `-filter filterfile' will use
+                 the named filterfile to format each forwarded message with _m_h_l.
+
+                 Each forwarded message is separated with an encapsulation delimiter
+                 and  dashes  in  the first column of the forwarded messages will be
+                 prepended with `- ' so that when received, the message is  suitable
+                 for  bursting  by  _b_u_r_s_t (1).   This  follows  the Internet RFC-934
+                 guidelines.
+
+                 For users of  _p_r_o_m_p_t_e_r (1),  by  specifying  prompter's  `-prepend'
+                 switch  in  the  .mh_profile  file,  any commentary text is entered
+                 before the forwarded messages.  (A major win!)
+
+                 To use the  MIME  rules  for  encapsulation,  specify  the  `-mime'
+                 switch.   This  directs  _f_o_r_w  to generate an _m_h_n composition file.
+                 Note that MH will not invoke _m_h_n  automatically,  unless  you   add
+                 this line to your .mh_profile file:
+
+                      automhnproc: mhn
+
+                 Otherwise, you must specifically give the command
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -39-                           FORW(1)
+
+
+                      What now? edit mhn
+
+                 prior to sending the draft.
+
+                 To automate this somewhat, create a link to _p_r_o_m_p_t_e_r  called  _r_a_p_i_d
+                 and put these lines in your .mh_profile file:
+
+                      forw: -editor rapid -mime
+                      rapid: -rapid
+                      rapid-next: mhn
+
+                 Then, you can simply do:
+
+                      _f_o_r_w _m_s_g_s
+                      To: _m_a_i_l_b_o_x
+                      cc:
+                      Subject: _w_h_a_t_e_v_e_r
+
+                      --------Enter initial text
+
+                      _b_l_a_h, _b_l_a_h, _b_l_a_h.
+                      <CTRL-D>
+                      --------
+
+                      What now? _e_d_i_t
+                      What now? _s_e_n_d
+
+                 The _e_d_i_t command invokes _m_h_n automatically.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _f_o_r_w will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+                 The `-digest list', `-issue number', and `-volume number'  switches
+                 implement  a  digest  facility  for  _M_H.  Specifying these switches
+                 enables and/or overloads the following escapes:
+
+                 _T_y_p_e       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 _c_o_m_p_o_n_e_n_t  _d_i_g_e_s_t  string   Argument to `-digest'
+                 _f_u_n_c_t_i_o_n   _c_u_r     integer  Argument to `-volume'
+                 _f_u_n_c_t_i_o_n   _m_s_g     integer  Argument to `-issue'
+
+                 Consult the Advanced Features section of the _M_H User's  Manual  for
+                 more information on making digests.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -40-                           FORW(1)
+
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/forwcomps         The message skeleton
+                 or <mh-dir>/forwcomps                Rather than the standard skeleton
+                 /usr/bs/mh-6.8/lib/digestcomps       The message skeleton if `-digest' is given
+                 or <mh-dir>/digestcomps              Rather than the standard skeleton
+                 /usr/bs/mh-6.8/lib/mhl.forward       The message filter
+                 or <mh-dir>/mhl.forward              Rather than the standard filter
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/draft                       The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 mhlproc:             Program to filter messages being forwarded
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+                 comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noformat'
+                 `-noinplace'
+                 `-nomime'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message forwarded will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -41-                           FORW(1)
+
+
+            _B_u_g_s
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _f_o_r_w uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _f_o_r_w  won't  run
+                 it.
+
+                 When _f_o_r_w is told to annotate the messages it forwards, it  doesn't
+                 actually  annotate  them  until the draft is successfully sent.  If
+                 from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h instead of _s_e_n_d,  it's  possible  to
+                 confuse   _f_o_r_w   by   re-ordering   the   file   (e.g.,   by  using
+                 `folder -pack') before the message is successfully sent.  _D_i_s_t  and
+                 _r_e_p_l don't have this problem.
+
+                 To avoid prepending the leading dash characters in  forwarded  mes-
+                 sages,  there  is  a  `-nodashmunging'  option.   See  the  "Hidden
+                 Features" section of the _M_H _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -42-                            INC(1)
+
+
+            _N_A_M_E
+                 inc - incorporate new mail
+
+            _S_Y_N_O_P_S_I_S
+                 inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+                      [-nochangecur] [-form formatfile] [-format string]
+                      [-file name] [-silent] [-nosilent] [-truncate] [-notruncate]
+                      [-width columns] [-host host] [-user user] [-apop] [-noapop]
+                      [-rpop] [-norpop] [-pack file] [-nopack] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _I_n_c incorporates mail from the user's incoming mail drop into an _M_H
+                 folder.   If  `+folder'  isn't specified, a folder in the user's _M_H
+                 directory will be used, either that specified by the "Inbox:" entry
+                 in  the  user's profile, or the folder named "inbox".  The new mes-
+                 sages being incorporated are assigned  numbers  starting  with  the
+                 next  highest  number in the folder.  If the specified (or default)
+                 folder doesn't exist, the user will be queried prior to  its  crea-
+                 tion.   As  the  messages  are processed, a _s_c_a_n listing of the new
+                 mail is produced.
+
+                 If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+                 be  used as the protection on the newly created messages, otherwise
+                 the _M_H default of 0644 will be used.  During all operations on mes-
+                 sages,  this  initially  assigned  protection will be preserved for
+                 each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+                 individual   message,   and   its   protection  will  be  preserved
+                 thereafter.
+
+                 If the  switch  `-audit audit-file'  is  specified  (usually  as  a
+                 default  switch in the profile), then _i_n_c will append a header line
+                 and a line per message to the end of the specified audit-file  with
+                 the format:
+
+                      <<inc>> date
+                           <scan line for first message>
+                           <scan line for second message>
+                                     <etc.>
+
+                 This is useful for keeping track of volume and source  of  incoming
+                 mail.   Eventually,  _r_e_p_l,  _f_o_r_w,  _c_o_m_p,  and _d_i_s_t may also produce
+                 audits to this (or another) file, perhaps with "Message-Id:" infor-
+                 mation  to keep an exact correspondence history.  "Audit-file" will
+                 be in the user's MH directory unless a full path is specified.
+
+                 _I_n_c will incorporate even improperly formatted  messages  into  the
+                 user's  MH  folder,  inserting  a blank line prior to the offending
+                 component and printing a comment identifying the bad message.
+
+                 In all cases, the user's mail  drop  will  be  zeroed,  unless  the
+                 `-notruncate' switch is given.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -43-                            INC(1)
+
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+                 then  _i_n_c  will add each of the newly incorporated messages to each
+                 sequence named by the  profile  entry.   This  is  similar  to  the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.  Note that _i_n_c will not  zero
+                 each sequence prior to adding messages.
+
+                 The interpretation of the `-form formatfile', `-format string', and
+                 `-width columns' switches is the same as in _s_c_a_n (1).
+
+                 By using the `-file name' switch, one can direct _i_n_c to incorporate
+                 messages from a file other than the user's maildrop.  Note that the
+                 name file will NOT be zeroed,  unless  the  `-truncate'  switch  is
+                 given.
+
+                 If the envariable $MAILDROP is set, then _i_n_c uses it as  the  loca-
+                 tion  of  the  user's  maildrop  instead  of  the  default  (the `-
+                 file name' switch still overrides this, however).  If this  envari-
+                 able is not set, then _i_n_c will consult the profile entry "MailDrop"
+                 for this information.  If the value found is not absolute, then  it
+                 is  interpreted  relative to the user's _M_H directory.  If the value
+                 is not found, then _i_n_c will look in the  standard  system  location
+                 for the user's maildrop.
+
+                 The `-silent' switch directs _i_n_c to be quiet and not ask any  ques-
+                 tions at all.  This is useful for putting _i_n_c in the background and
+                 going on to other things.
+
+                 If the local host  is  configured  as  a  POP  client,  or  if  the
+                 `-host host'  switch  is given, then _i_n_c will query the POP service
+                 host as to the status of mail waiting.  If the `-user user'  switch
+                 is  not  given,  then  the current username is used.  Normally, _i_n_c
+                 will prompt for a password to use.  However, if the `-apop'  switch
+                 is  given,  _i_n_c will generate authentication credentials to provide
+                 for origin authentication and replay protection, but which  do  not
+                 involve  sending  a password in the clear over the network.  Other-
+                 wise, if the `-rpop' switch is given, then _i_n_c will try  to  use  a
+                 "trusted" connection (ala the BSD r-commands).
+
+                 If _i_n_c uses POP, then the `-pack file' switch  is  considered.   If
+                 given,  then  _i_n_c simply uses the POP to _p_a_c_k_f (1) the user's mail-
+                 drop from the POP service host to the named file.  This  switch  is
+                 provided  for those users who prefer to use _m_s_h to read their mail-
+                 drops.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+                 /usr/spool/mail/$USER                Location of mail drop
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -44-                            INC(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Inbox:               To determine the inbox, default "inbox"
+                 Folder-Protect:      To set mode when creating a new folder
+                 Msg-Protect:         To set mode when creating a  new  message  and
+                 audit-file
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+            _S_e_e _A_l_s_o
+                 _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+                 mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaulted by "Inbox" above
+                 `-noaudit'
+                 `-changecur'
+                 `-format' defaulted as described above
+                 `-nosilent'
+                 `-truncate' if `-file name' not given, `-notruncate' otherwise
+                 `-width' defaulted to the width of the terminal
+                 `-nopack'
+                 `-rpop'
+
+
+            _C_o_n_t_e_x_t
+                 The folder into which messages are being incorporated  will  become
+                 the current folder.  The first message incorporated will become the
+                 current message, unless the  `-nochangecur'  option  is  specified.
+                 This leaves the context ready for a _s_h_o_w of the first new message.
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _i_n_c.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -45-                           MARK(1)
+
+
+            _N_A_M_E
+                 mark - mark messages
+
+            _S_Y_N_O_P_S_I_S
+                 mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+                      [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _m_a_r_k command manipulates message sequences by adding or  delet-
+                 ing  message  numbers from folder-specific message sequences, or by
+                 listing those sequences and messages.  A message sequence is a key-
+                 word,  just  like  one  of  the  "reserved"  message names, such as
+                 "first" or "next".  Unlike the "reserved" message names, which have
+                 a fixed semantics on a per-folder basis, the semantics of a message
+                 sequence may be defined, modified, and removed by the  user.   Mes-
+                 sage  sequences are folder-specific, e.g., the sequence name "seen"
+                 in the context of folder "+inbox" need not have any relation  what-
+                 soever  to the sequence of the same name in a folder of a different
+                 name.
+
+                 Three action switches direct the operation of _m_a_r_k.  These switches
+                 are  mutually  exclusive:  the last occurrence of any of them over-
+                 rides any previous occurrence of the other two.
+
+                 The `-add' switch tells _m_a_r_k to add messages  to  sequences  or  to
+                 create   a   new   sequence.   For  each  sequence  named  via  the
+                 `-sequence name' argument (which must occur at least once) the mes-
+                 sages  named  via  `msgs' (which defaults to "cur" if no `msgs' are
+                 given), are added to the sequence.  The messages to be  added  need
+                 not  be  absent from the sequence.  If the `-zero' switch is speci-
+                 fied, the sequence will be emptied prior to  adding  the  messages.
+                 Hence,  `-add -zero' means that each sequence should be initialized
+                 to the indicated messages, while  `-add -nozero'  means  that  each
+                 sequence should be appended to by the indicated messages.
+
+                 The `-delete' switch tells _m_a_r_k to delete messages from  sequences,
+                 and  is  the  dual of `-add'.  For each of the named sequences, the
+                 named messages are removed from the sequence.  These messages  need
+                 not  be  already present in the sequence.  If the `-zero' switch is
+                 specified, then all messages in the  folder  are  appended  to  the
+                 sequence  prior  to  removing the messages.  Hence, `-delete -zero'
+                 means that each sequence should contain all messages  except  those
+                 indicated,  while  `-delete -nozero'  means that only the indicated
+                 messages should be removed from each sequence.   As  expected,  the
+                 command   `mark -sequence seen -delete all'  deletes  the  sequence
+                 "seen" from the current folder.
+
+                 When creating (or modifying) a sequence, the `-public' switch indi-
+                 cates that the sequence should be made readable for other _M_H users.
+                 In contrast, the `-nopublic' switch  indicates  that  the  sequence
+                 should be private to the user's _M_H environment.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -46-                           MARK(1)
+
+
+                 The `-list' switch tells _m_a_r_k to list both  the  sequences  defined
+                 for  the  folder  and the messages associated with those sequences.
+                 _M_a_r_k will list the name of each sequence given by  `-sequence name'
+                 and  the  messages  associated  with that sequence.  If `-sequence'
+                 isn't used, all sequences will be listed,  with  private  sequences
+                 being  so indicated.  The `-zero' switch does not affect the opera-
+                 tion of `-list'.
+
+                 The current restrictions on sequences are:
+
+                   The name used to denote a message sequence  must  consist  of  an
+                   alphabetic  character followed by zero or more alphanumeric char-
+                   acters, and can not be one of the "reserved" message names (e.g.,
+                   "first", "cur", and so forth).
+
+                   Only a certain number of sequences may be  defined  for  a  given
+                   folder.   This  number is usually limited to 26 (10 on small sys-
+                   tems).
+
+                   Message ranges with user-defined sequence names are restricted to
+                   the  form  "name:n"  or "name:-n", and refer to the first or last
+                   `n' messages of the sequence `name', respectively.  Constructs of
+                   the form "name1-name2" are forbidden.
+
+            _F_i_l_e_s
+                $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                pick (1), mh-sequence (5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-add' if `-sequence' is specified, `-list' otherwise
+                 `msgs' defaults to cur (or all if `-list' is specified)
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-nozero'
+
+
+            _C_o_n_t_e_x_t
+                If a folder is given, it will become the current folder.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 Use "pick sequence -list" to enumerate the messages in  a  sequence
+                 (such as for use by a shell script).
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -47-                           MARK(1)
+
+
+            _N_A_M_E
+                 mhl - produce formatted listings of MH messages
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/mhl [-bell] [-nobell] [-clear] [-noclear]
+                      [-folder +folder] [-form formfile] [-length lines]
+                      [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_l is a formatted message listing program.  It can be  used  as  a
+                 replacement  for  _m_o_r_e (1)  (the default _s_h_o_w_p_r_o_c ).  As with _m_o_r_e,
+                 each of the messages specified as arguments (or the standard input)
+                 will  be  output.   If more than one message file is specified, the
+                 user will be prompted prior to each one, and a  <RETURN>  or  <EOT>
+                 will  begin  the  output,  with  <RETURN>  clearing  the screen (if
+                 appropriate), and <EOT> (usually  CTRL-D)  suppressing  the  screen
+                 clear.  An <INTERRUPT> (usually CTRL-C) will abort the current mes-
+                 sage output, prompting for the next message (if there is one),  and
+                 a  <QUIT> (usually CTRL-\) will terminate the program (without core
+                 dump).
+
+                 The `-bell' option tells _m_h_l to ring the terminal's bell at the end
+                 of  each  page,  while  the  `-clear' option tells _m_h_l to clear the
+                 scree at the end of each page (or output a formfeed after each mes-
+                 sage).   Both  of  these  switches (and their inverse counterparts)
+                 take effect only if the  profile  entry  _m_o_r_e_p_r_o_c  is  defined  but
+                 empty,  and _m_h_l is outputting to a terminal.  If the _m_o_r_e_p_r_o_c entry
+                 is defined and non-empty, and _m_h_l is outputting to a terminal, then
+                 _m_h_l  will  cause the _m_o_r_e_p_r_o_c to be placed between the terminal and
+                 _m_h_l and the switches are ignored.   Furthermore,  if  the  `-clear'
+                 switch is used and _m_h_l'_s output is directed to a terminal, then _m_h_l
+                 will consult the $TERM and $TERMCAP envariables  to  determine  the
+                 user's  terminal type in order to find out how to clear the screen.
+                 If the `-clear' switch is used and _m_h_l'_s output is not directed  to
+                 a  terminal (e.g., a pipe or a file), then _m_h_l will send a formfeed
+                 after each message.
+
+                 To override the default _m_o_r_e_p_r_o_c and the  profile  entry,  use  the
+                 `-moreproc program'  switch.   Note  that  _m_h_l  will  never start a
+                 _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+                 The `-length length' and `-width width'  switches  set  the  screen
+                 length  and width, respectively.  These default to the values indi-
+                 cated by $TERMCAP, if appropriate, otherwise they default to 40 and
+                 80, respectively.
+
+                 The default format file used by _m_h_l is called _m_h_l._f_o_r_m_a_t (which  is
+                 first  searched  for in the user's _M_H directory, and then sought in
+                 the /_u_s_r/_b_s/_m_h-_6._8/_l_i_b directory), this can be changed by using the
+                 `-form formatfile' switch.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -48-                            MHL(1)
+
+
+                 Finally, the `-folder +folder' switch  sets  the  _M_H  folder  name,
+                 which  is  used  for the "messagename:" field described below.  The
+                 envariable $mhfolder is consulted  for  the  default  value,  which
+                 _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize appropriately.
+
+                 _M_h_l operates in two phases: 1) read and parse the format file,  and
+                 2)  process  each  message  (file).   During  phase  1, an internal
+                 description of the format is produced as  a  structured  list.   In
+                 phase  2,  this list is walked for each message, outputting message
+                 information under the format constraints from the format file.
+
+                 The "mhl.format" form file contains information controlling  screen
+                 clearing,  screen size, wrap-around control, transparent text, com-
+                 ponent ordering, and component formatting.  Also, a  list  of  com-
+                 ponents  to ignore may be specified, and a couple of "special" com-
+                 ponents are defined to provide added functionality.  Message output
+                 will be in the order specified by the order in the format file.
+
+                 Each line of mhl.format has one of the formats:
+
+                      ;comment
+                      :cleartext
+                      variable[,variable...]
+                      component:[variable,...]
+
+                 A line beginning with a `;' is a comment, and is ignored.   A  line
+                 beginning with a `:' is clear text, and is output exactly as is.  A
+                 line containing only a `:' produces a blank line in the output.   A
+                 line  beginning with "component:" defines the format for the speci-
+                 fied component, and finally,  remaining  lines  define  the  global
+                 environment.
+
+                 For example, the line:
+
+                      width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+                 defines the screen size to be 80 columns by 40 rows, specifies that
+                 the screen should be cleared prior to each page, that the  overflow
+                 indentation  is  5,  and  that overflow text should be flagged with
+                 "***".
+
+                 Following are all of the current variables and their arguments.  If
+                 they  follow a component, they apply only to that component, other-
+                 wise, their affect is global.  Since the  whole  format  is  parsed
+                 before  any output processing, the last global switch setting for a
+                 variable applies to the whole message if that variable is used in a
+                 global context (i.e., bell, clearscreen, width, length).
+
+                      _v_a_r_i_a_b_l_e       _t_y_p_e       _s_e_m_a_n_t_i_c_s
+                      width          integer    screen width or component width
+                      length         integer    screen length or component length
+                      offset         integer    positions to indent "component: "
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -49-                            MHL(1)
+
+
+                      overflowtext   string     text to use at the beginning of an
+                                                overflow line
+                      overflowoffset integer    positions to indent overflow lines
+                      compwidth      integer    positions to indent component text
+                                                after the first line is output
+                      uppercase      flag       output text of this component in all
+                                                upper case
+                      nouppercase    flag       don't uppercase
+                      clearscreen    flag/G     clear the screen prior to each page
+                      noclearscreen  flag/G     don't clearscreen
+                      bell           flag/G     ring the bell at the end of each page
+                      nobell         flag/G     don't bell
+                      component      string/L   name to use instead of "component" for
+                                                this component
+                      nocomponent    flag       don't output "component: " for this
+                                                component
+                      center         flag       center component on line (works for
+                                                one-line components only)
+                      nocenter       flag       don't center
+                      leftadjust     flag       strip off leading whitespace on each
+                                                line of text
+                      noleftadjust   flag       don't leftadjust
+                      compress       flag       change newlines in text to spaces
+                      nocompress     flag       don't compress
+                      split          flag       don't combine multiple fields into a single field
+                      nosplit        flag       combine multiple fields into a single field
+                      newline        flag       print newline at end of components (default)
+                      nonewline      flag       don't print newline at end of components
+                      formatfield    string     format string for this component (see below)
+                      addrfield      flag       field contains addresses
+                      datefield      flag       field contains dates
+
+                 To specify the value of integer-valued and string-valued variables,
+                 follow   their   name   with   an   equals-sign   and   the  value.
+                 Integer-valued  variables   are   given   decimal   values,   while
+                 string-valued  variables  are  given  arbitrary  text  bracketed by
+                 double-quotes.  If a value is suffixed by "/G" or  "/L",  then  its
+                 value  is  useful  in  a global-only or local-only context (respec-
+                 tively).
+
+                 A line of the form:
+
+                     ignores=component,...
+
+                 specifies a list of components which are never output.
+
+                 The component  "MessageName"  (case-insensitive)  will  output  the
+                 actual  message name (file name) preceded by the folder name if one
+                 is specified or found in the environment.  The format is  identical
+                 to that produced by the `-header' option to _s_h_o_w.
+
+                 The component "Extras" will output all of  the  components  of  the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -50-                            MHL(1)
+
+
+                 message  which were not matched by explicit components, or included
+                 in the ignore list.  If this component is not specified, an  ignore
+                 list  is  not  needed  since  all  non-specified components will be
+                 ignored.
+
+                 If "nocomponent" is NOT specified, then the component name will  be
+                 output as it appears in the format file.
+
+                 The default format is:
+
+                      : -- using template mhl.format --
+                      overflowtext="***",overflowoffset=5
+                      leftadjust,compwidth=9
+                      ignores=msgid,message-id,received
+                      Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+                      To:
+                      cc:
+                      :
+                      From:
+                      Subject:
+                      :
+                      extras:nocomponent
+                      :
+                      body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+                 The  variable  "formatfield"  specifies  a   format   string   (see
+                 _m_h-_f_o_r_m_a_t (5)).   The  flag  variables  "addrfield" and "datefield"
+                 (which are mutually exclusive), tell _m_h_l to interpret  the  escapes
+                 in the format string as either addresses or dates, respectively.
+
+                 By default, _m_h_l does not apply any formatting string to fields con-
+                 taining  address  or  dates  (see  _m_h-_m_a_i_l (5)  for a list of these
+                 fields).  Note that this results in faster operation since _m_h_l must
+                 parse both addresses and dates in order to apply a format string to
+                 them.  If desired, _m_h_l can be given a  default  format  string  for
+                 either  address  or  date  fields (but not both).  To do this, on a
+                 global line specify: either the flag addrfield or datefield,  along
+                 with the apropriate formatfield variable string.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/mhl.format        The message template
+                 or <mh-dir>/mhl.format               Rather than the standard template
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 moreproc:            Program to use as interactive front-end
+
+
+            _S_e_e _A_l_s_o
+                 show(1), ap(8), dp(8)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -51-                            MHL(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-bell'
+                 `-noclear'
+                 `-length 40'
+                 `-width 80'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 There should be some way to pass `bell' and `clear' information  to
+                 the front-end.
+
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+                 The "nonewline" option interacts badly with "compress" and "split".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHMAIL(1)                         -52-                         MHMAIL(1)
+
+
+            _N_A_M_E
+                 mhmail - send or read mail
+
+            _S_Y_N_O_P_S_I_S
+                 mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+                      [-subject subject]] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_H_m_a_i_l is intended as a replacement for the standard Bell mail pro-
+                 gram  (_b_e_l_l_m_a_i_l (1)),  compatible  with  _M_H.   When invoked without
+                 arguments, it simply invokes _i_n_c (1) to  incorporate  new  messages
+                 from  the  user's maildrop.  When one or more users is specified, a
+                 message is read from the standard input and spooled to a  temporary
+                 file.   _M_H_m_a_i_l then invokes _p_o_s_t (8) with the name of the temporary
+                 file as its argument to deliver the message to the specified user.
+
+                 The `-subject subject' switch can be used to specify the "Subject:"
+                 field  of  the  message.   The  `-body text'  switch can be used to
+                 specify the text of the message; if it is specified, then the stan-
+                 dard input is not read.  Normally, addresses appearing as arguments
+                 are put in the "To:" field.  If  the  `-cc'  switch  is  used,  all
+                 addresses following it are placed in the "cc:" field.
+
+                 By using `-from addr', you can specify the "From:"  header  of  the
+                 draft.    Naturally,   _p_o_s_t   will  fill-in  the  "Sender:"  header
+                 correctly.
+
+                 This program is intended for the use of programs  such  as  _a_t (1),
+                 which  expect  to  send  mail automatically to various users.  Nor-
+                 mally, real people (as opposed to the "unreal" ones) will prefer to
+                 use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/bin/inc               Program to incorporate a maildrop into a folder
+                 /usr/bs/mh-6.8/lib/post              Program to deliver a message
+                 /tmp/mhmail*                         Temporary copy of message
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHMAIL(1)                         -53-                         MHMAIL(1)
+
+
+            _C_o_n_t_e_x_t
+                 If _i_n_c is invoked, then _i_n_c's context changes occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -54-                            MHN(1)
+
+
+            _N_A_M_E
+                 mhn - multi-media MH
+
+            _S_Y_N_O_P_S_I_S
+                 mhn [+folder] [msgs] [-part number]... [-type content]...
+                      [-list [-headers] [-noheaders]
+                             [-realsize] [-norealsize]] [-nolist]
+                      [-show [-serialonly] [-noserialonly]]
+                             [-form formfile]] [-noshow]
+                      [-store [-auto] [-noauto]] [-nostore]
+                      [-verbose] [-noverbose] [-rfc934mode] [-norfc934mode]
+                      [-ebcdicsafe] [-noebcdicsafe]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _m_h_n command manipulates multi-media messages  as  specified  in
+                 RFC 1341.
+
+                 Three action switches direct the operation of _m_h_n, namely  `-list',
+                 `-show',  and  `-store'.   Any  of  these switches may be used con-
+                 currently.  Normally these action switches will operate on the con-
+                 tent  of each of the named messages.  However, by using the `-part'
+                 and `-type' switches, the scope of the operation can be focused  on
+                 particular subparts (of a multipart content) and/or particular con-
+                 tent types.
+
+                 A part specification consists of a series of numbers  separated  by
+                 dots.   For example, in a multipart content containing three parts,
+                 these would be named as 1, 2, and 3, respectively.  If part  2  was
+                 also a multipart content containing two parts, these would be named
+                 as 2.1 and 2.2, respectively.  Note  that  the  `-part'  switch  is
+                 effective  for  only messages containing a multipart content.  If a
+                 message has some other kind of content, or if the  part  is  itself
+                 another  multipart content, the `-part' switch will not prevent the
+                 content from being acted upon.
+
+                 A content specification consists of a content type and  a  subtype.
+                 The  initial  list  of "standard" content types and subtypes can be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -55-                            MHN(1)
+
+
+                 found in RFC 1341.  A list of commonly  used  contents  is  briefly
+                 reproduced here:
+
+                      Type         Subtypes
+                      ----         --------
+                      text         plain, richtext
+                      multipart    mixed, alternative, digest, parallel
+                      message      rfc822, partial, external-body
+                      application  octet-stream, oda, postscript
+                      image        jpeg, gif, x-pbm, x-pgm, x-ppm, x-xwd
+                      audio        basic
+                      video        mpeg
+
+                 Subtypes are mandatory.  To specify a content,  regardless  of  its
+                 subtype,  just  use  the  name  of  the content, e.g., "audio".  To
+                 specify a specific subtype, separate the two with  a  slash,  e.g.,
+                 "audio/basic".   Note  that  regardless  of the values given to the
+                 `-type' switch, a multipart content is always acted upon.   Further
+                 note that if the `-type' switch is used, and it is desirable to act
+                 on a message/external-body content, then the `-type' switch must be
+                 used twice: once for message/external-body and once for the content
+                 externally referenced.
+
+
+              _L_i_s_t_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+                 The `-list' switch tells _m_h_n to list the table of contents  associ-
+                 ated with the named messages.  The `-headers' switch indicates that
+                 a one-line banner should  be  displayed  above  the  listing.   The
+                 `-realsize'  switch  tells  _m_h_n  to evaluate the "native" (decoded)
+                 format of each content prior to listing.  This provides an accurate
+                 count at the expense of a small delay.
+
+
+              _S_h_o_w_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+                 The `-show' switch tells _m_h_n to display the contents of  the  named
+                 messages.   The  headers  of  the  message  are  displayed with the
+                 _m_h_l_p_r_o_c, using format file _m_h_l._h_e_a_d_e_r_s.  (The choice of format file
+                 can be overridden by the `-form formfile' switch.)
+
+                 _m_h_n will look for information in the user's  profile  to  determine
+                 how  the  different  contents  should be displayed.  This is accom-
+                 plished by consulting a display  string,  and  executing  it  under
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -56-                            MHN(1)
+
+
+                 /bin/sh,  with  the standard input set to the content.  The display
+                 string may contain these escapes:
+
+                      %a  additional arguments
+                      %e  exclusive execution
+                      %f  filename containing content
+                      %F  %e, %f, and stdin is terminal not content
+                      %l  display listing prior to displaying content
+                      %p  %l, and ask for confirmation
+                      %s  subtype
+
+                 For those display strings containing the e- or F-escape,  _m_h_n  will
+                 execute  at  most  one of these at any given time.  Although the F-
+                 escape expands to be the filename containing the  content,  the  e-
+                 escape has no expansion as far as the shell is concerned.
+
+                 When the p-escape prompts for confirmation,  typing  INTR  (usually
+                 control-C)  will  tell  _m_h_n  not to display that content.  Further,
+                 when _m_h_n is display a content, typing QUIT (usually control-\) will
+                 tell _m_h_n to wrap things up immediately.
+
+                 First, _m_h_n will look for an entry of the form:
+
+                      mhn-show-<type>/<subtype>
+
+                 to determine the command to use to display the  content.   If  this
+                 isn't found, _m_h_n will look for an entry of the form:
+
+                      mhn-show-<type>
+
+                 to determine the display command.  If this isn't found, _m_h_n has two
+                 default values:
+
+                      mhn-show-text/plain: %pmoreproc '%F'
+                      mhn-show-message/rfc822: %pshow -file '%F'
+
+                 If neither apply, _m_h_n will check  to  see  if  the  message  has  a
+                 application/octet-stream content with parameter "type=tar".  If so,
+                 _m_h_n will use an appropriate command.  If not, _m_h_n will complain.
+
+                 Example entries might be:
+
+                      mhn-show-audio/basic: raw2audio 2>/dev/null | play
+                      mhn-show-image: xv '%f'
+                      mhn-show-application/PostScript: lpr -Pps
+
+                 Note that when using the f- or F-escape, it's a good  idea  to  use
+                 single-quotes  around  the escape.  This prevents misinterpretation
+                 by the shell of any funny characters that might be present  in  the
+                 filename.
+
+                 Because the text content might be in  a  non-ASCII  character  set,
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -57-                            MHN(1)
+
+
+                 when  _m_h_n  encounters  a  "charset"  parameter for this content, it
+                 checks to see whether the environment variable $MM_CHARSET  is  set
+                 and  whether the value of this environment variable is equal to the
+                 value of the charset parameter.  If not, then _m_h_n will look for  an
+                 entry of the form:
+
+                      mhn-charset-<charset>
+
+                 which should contain a command creating an  environment  to  render
+                 the  character set.  This command string should containing a single
+                 "%s", which will be filled-in with the command to display the  con-
+                 tent.
+
+                 An example entry might be:
+
+                      mhn-charset-iso-8859-1: xterm  -fn  '-*-*-medium-r-normal-*-*-
+                      120-*-*-c-*-iso8859-*' -e %s
+
+                 Note that many pagination programs strip off  the  high-order  bit.
+                 However, newer releases of the _l_e_s_s program have modest support for
+                 single-octet character sets.  The source to _l_e_s_s version 177, which
+                 has   such   support,   is  found  in  the  MH  source  tree  under
+                 miscellany/less-177.  In order to view messages  sent  in  the  ISO
+                 8859/1  character  set  using  _l_e_s_s, put these lines in your .login
+                 file:
+
+                      setenv LESSCHARSET latin1
+                      setenv LESS "-f"
+
+                 The first line tells _l_e_s_s to use 8859/1  definition  for  determing
+                 whether  a  character  is  "normal",  "control",  or "binary".  The
+                 second line tells _l_e_s_s not to warn you if it encounters a file that
+                 has  non-ASCII  characters.   Then, simply set the moreproc profile
+                 entry to _l_e_s_s, and it will get called  automatically.   (To  handle
+                 other  single-octet  character  sets,  look  at the _l_e_s_s (1) manual
+                 entry for information about the LESSCHARDEF environment variable.)
+
+                 Finally, _m_h_n will process each message serially -- it  won't  start
+                 showing the next message until all the commands executed to display
+                 the current message have terminated.  In the case  of  a  multipart
+                 content, the content contains advice indicating if the parts should
+                 be displayed serially or in parallel.  Because this may cause  con-
+                 fusion,  particularly  on  uni-window  displays,  the `-serialonly'
+                 switch can be given to tell _m_h_n to never display parts in parallel.
+
+
+              _S_t_o_r_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+                 The `-store' switch tells _m_h_n to store the contents  of  the  named
+                 messages  in  "native" (decoded) format.  Two things must be deter-
+                 mined: the directory to  store  the  content,  and  the  filenames.
+                 Files are written in the directory given by the mhn-storage profile
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -58-                            MHN(1)
+
+
+                 entry, e.g.,
+
+                      mhn-storage: /tmp
+
+                 If this entry isn't present, the current working directory is used.
+
+                 _m_h_n will look for information in the user's  profile  to  determine
+                 how  the  different  contents  should  be stored.  This is achieved
+                 through the use of a formatting string,  which  may  contain  these
+                 escapes:
+
+                      %m  message number
+                      %P  .part
+                      %p  part
+                      %s  subtype
+
+                 If the content isn't part of a multipart content, the p-escapes are
+                 ignored.   Note  that  if  the  formatting string starts with a "+"
+                 character, then these escapes  are  ignored,  and  the  content  is
+                 stored in the named folder.  (A formatting string consisting solely
+                 of a "+" character indicates the current folder.) Further,  a  for-
+                 matting  string  consisting solely of a "-" character indicates the
+                 standard-output.
+
+                 First, _m_h_n will look for an entry of the form:
+
+                      mhn-store-<type>/<subtype>
+
+                 to determine the formatting string.  If this isn't found, _m_h_n  will
+                 look for an entry of the form:
+
+                      mhn-store-<type>
+
+                 to determine the formatting string.  If this isn't found, _m_h_n  will
+                 check to see if the content is application/octet-stream with param-
+                 eter "type=tar".  If so, _m_h_n will choose an  appropriate  filename.
+                 If the content is not application/octet-stream, then _m_h_n will check
+                 to see if the content is a message.  If so, _m_h_n will use the  value
+                 "+".  If not, _m_h_n will use the value "%m%P.%s".
+
+                 Note that if the formatting string starts with a '/', then  content
+                 will  be stored in the full path given (rather than using the value
+                 of mhn-storage or the current working directory.) Similarly, if the
+                 formatting  string  starts with a '|', then _m_h_n will execute a com-
+                 mand which should ultimately store the content.  Note  that  before
+                 executing  the  command,  _m_h_n will change to the appropriate direc-
+                 tory.  Also note that if the formatting string starts with  a  '|',
+                 then  _m_h_n  will also honor the a-escape when processing the format-
+                 ting string.
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -59-                            MHN(1)
+
+
+                 Example entries might be:
+
+                      mhn-store-text: %m%P.txt
+                      mhn-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
+                      mhn-store-application/PostScript: %m%P.ps
+
+                 Further, note that when asked to store a content containing a  par-
+                 tial  message,  _m_h_n will try to locate all of the portions and com-
+                 bine them accordingly.  Thus, if someone's sent you  a  message  in
+                 several parts, you might put them all in their own folder and do:
+
+                      mhn all -store
+
+                 This will store exactly one message,  containing  the  sum  of  the
+                 parts.   Note  that  if  _m_h_n  can not locate each part, it will not
+                 store anything.
+
+                 Finally, if the `-auto' switch is given and  the  content  contains
+                 information indicating the filename the content should be stored as
+                 (and if the filename doesn't begin with a '/'), then  the  filename
+                 from the content will be used instead.
+
+
+              _E_x_t_e_r_n_a_l _A_c_c_e_s_s
+
+                 For contents of  type  message/external-body,  _m_h_n  supports  these
+                 access-types:
+
+                      afs
+                      anon-ftp
+                      ftp
+                      local-file
+                      mail-server
+
+                 If your system supports a SOCKETs interface  to  TCP/IP,  then  _m_h_n
+                 will  use  a built-in FTP client.  Otherwise, _m_h_n will look for the
+                 mhn-access-ftp profile entry, e.g.,
+
+                      mhn-access-ftp: myftp.sh
+
+                 to  determine  the  pathname  of  a  program  to  perform  the  FTP
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -60-                            MHN(1)
+
+
+                 retrieval.  This program is invoked with these arguments:
+
+                      domain name of FTP-site
+                      username
+                      password
+                      remote directory
+                      remote filename
+                      local filename
+                      "ascii" or "binary"
+
+                 The program should terminate with a zero-valued exit-status if  the
+                 retrieval is success.
+
+
+              _T_h_e _C_o_n_t_e_n_t _C_a_c_h_e
+
+                 When _m_h_n encounters an external content containing a  "Content-ID:"
+                 field,  and  if  the content allows caching, then _m_h_n looks for the
+                 profile entry mhn-cache to determine if the content should be  read
+                 from/written to a cache.  Any content written to the cache will, by
+                 default, be world-readable.  (To prevent this, use a directory name
+                 with  the desired read and execute permissions.) The mhn-cache pro-
+                 file entry names the directory used for caching, e.g.,
+
+                      mhn-cache: /tmp
+
+                 might be used if you didn't care that the  cache  got  wiped  after
+                 each reboot of the system.
+
+
+              _C_o_m_p_o_s_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+                 The _m_h_n program can also be used as a simple editor to aid in  com-
+                 posing  multi-media  messages.   When invoked by a _w_h_a_t_n_o_w program,
+                 _m_h_n will expect the body of the draft to be formatted  as  an  "_m_h_n
+                 composition file."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -61-                            MHN(1)
+
+
+                 The syntax of this is straight-forward:
+
+                         body         ::=     1*(content | EOL)
+
+                         content      ::=     directive | plaintext
+
+                         directive    ::=     "#" type "/" subtype
+                                                  0*(";" attribute "=" value)
+                                                  [ "(" comment ")" ]
+                                                  [ "[" description "]" ]
+                                                  [ filename ]
+                                                  EOL
+
+                                            | "#@" type "/" subtype
+                                                  0*(";" attribute "=" value)
+                                                  [ "(" comment ")" ]
+                                                  [ "[" description "]" ]
+                                                  external-parameters
+                                                  EOL
+
+                                            | "#forw"
+                                                  [ "[" description "]" ]
+                                                  [ "+"folder ] [ 0*msg ]
+                                                  EOL
+
+                                            | "#begin"
+                                                    [ "[" description "]" ]
+                                                    [   "alternative"
+                                                      | "parallel"    ]
+                                                    EOL
+                                                  1*body
+                                              "#end" EOL
+
+                         plaintext    ::=     [ "Content-Description:"
+                                                    description EOL EOL ]
+                                                  1*line
+                                              [ "#" EOL ]
+
+                                            | "#<" type "/" subtype
+                                                  0*(";" attribute "=" value)
+                                                  [ "(" comment ")" ]
+                                                  [ "[" description "]" ]
+                                                  EOL
+                                                  1*line
+                                              [ "#" EOL ]
+
+                         line         ::=     "##" text EOL
+                                              -- interpreted as "#"text EOL
+                                            | text EOL
+
+                 Basically, the body contains one or more contents.  A content  con-
+                 sists  of  either  a  directive,  indicated with a "#" as the first
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -62-                            MHN(1)
+
+
+                 character of a line; or, plaintext (one or  more  lines  of  text).
+                 The  continuation  character,  "\",  may  be used to enter a single
+                 directive on more than one line, e.g.,
+
+                      #@application/octet-stream; \
+                          type=tar; \
+                          conversions=x-compress
+
+                 There are four kinds of directives: "type" directives,  which  name
+                 the  type  and  subtype of the content; "external-type" directives,
+                 which also name the type and subtype of  the  content;  the  "forw"
+                 directive,  which is used to forward a digest of messages; and, the
+                 "begin" directive, which is used to create a multipart content.
+
+                 For the type directives, the user may optionally specify  the  name
+                 of  a  file  containing  the contents in "native" (decoded) format.
+                 (If the filename starts with the "|" character, then this  gives  a
+                 command whose output is captured accordingly.) If a filename is not
+                 given, _m_h_n will look for  information  in  the  user's  profile  to
+                 determine  how  the different contents should be composed.  This is
+                 accomplished by consulting a composition string, and  executing  it
+                 under  /bin/sh,  with  the standard output set to the content.  The
+                 composition string may contain these escapes:
+
+                      %a  additional arguments
+                      %f  filename containing content
+                      %F  %f, and stdout is not re-directed
+                      %s  subtype
+
+                 First, _m_h_n will look for an entry of the form:
+
+                      mhn-compose-<type>/<subtype>
+
+                 to determine the command to use to compose the  content.   If  this
+                 isn't found, _m_h_n will look for an entry of the form:
+
+                      mhn-compose-<type>
+
+                 to determine the composition command.  If  this  isn't  found,  _m_h_n
+                 will complain.
+
+                 An example entry might be:
+
+                      mhn-compose-audio/basic: record | raw2audio -F
+
+                 Because commands like these will vary,  depending  on  the  display
+                 environment  used for login, composition strings for different con-
+                 tents should probably be put in the  file  specified  by  the  $MHN
+                 environment variable, instead of directly in your user profile.
+
+                 The external-type directives are used to provide a reference  to  a
+                 content, rather than enclosing the contents itself.  Hence, instead
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -63-                            MHN(1)
+
+
+                 of providing a filename as  with  the  type  directives,  external-
+                 parameters  are  supplied.   These look like regular parameters, so
+                 they must be separated accordingly, e.g.,
+
+                      #@application/octet-stream; \
+                          type=tar; \
+                          conversions=x-compress [] \
+                          access-type=anon-ftp; \
+                          name="mh-mime.tar.Z"; \
+                          directory="mrose/mh-mime"; \
+                          site="ftp.ics.uci.edu"
+
+                 By specifying "[]", an empty description string is given,  and  the
+                 start  of  the external-parameters is identified.  These parameters
+                 are of the form:
+
+                      access-type=  usually _a_n_o_n-_f_t_p or _m_a_i_l-_s_e_r_v_e_r
+                      name=         filename
+                      directory=    directoryname (optional)
+                      site=         hostname
+                      mode=         usually _a_s_c_i_i or _i_m_a_g_e (optional)
+                      server=       mailbox
+                      body=         command to send for retrieval
+
+
+                 For the forw directive, the user may optionally specify the name of
+                 the  folder and which messages are to be forwarded.  if a folder is
+                 not given, it defaults to the current folder.  Similarly, if a mes-
+                 sage  is not given, it defaults to the current message.  Hence, the
+                 forw directive is similar to the _f_o_r_w (1) command, except that  the
+                 former  uses  the  MIME  rules  for encapsulation rather than those
+                 specified in RFC 934.  Usage of the `-rfc934mode' switch  indicates
+                 whether  _m_h_n  should  attempt to utilize the encapsulation rules in
+                 such a way as to appear that RFC 934 is being used.  If given, then
+                 RFC  934-compliant  user-agents should be able to burst the message
+                 on reception -- providing that the messages being  encapsulated  do
+                 not contain encapsulated messages themselves.  The drawback of this
+                 approach is that the encapsulations are  generated  by  placing  an
+                 extra newline at the end of the body of each message.
+
+                 For the begin directive, the user must specify at least one content
+                 between the begin and end pairs.
+
+                 For all of these directives, the user may include a brief  descrip-
+                 tion  of  the content between the "[" character and the "]" charac-
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -64-                            MHN(1)
+
+
+                 ter.  Putting this all together, here is a brief example of what  a
+                 user's components file might look like:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+                      #audio/basic [Flint phone]  \
+                          |raw2audio -F < /home/mrose/lib/multi-media/flint.au
+                      #image/gif   [MTR's photo] \
+                                          /home/mrose/lib/multi-media/mrose.gif
+
+                 For a later example, we'll call this components file _m_h_n_c_o_m_p_s.
+
+                 As noted earlier, in  addition  to  directives,  plaintext  can  be
+                 present.   Plaintext is gathered, until a directive is found or the
+                 draft is exhausted, and this is made to form a  text  content.   If
+                 the plaintext must contain a "#" at the beginning of a line, simply
+                 double it, e.g.,
+
+                      ##when sent, this line will start with only one #
+
+                 If you want to end the plaintext prior to  a  directive,  e.g.,  to
+                 have two plaintext contents adjacent, simply insert a line contain-
+                 ing a single "#" character, e.g.,
+
+                      this is the first content
+                      #
+                      and this is the second
+
+                 Finally, if the plaintext starts with a line of the form:
+
+                      Content-Description: text
+
+                 then this will be used to describe  the  plaintext  content.   NOTE
+                 WELL:  you  must follow this line with a blank line before starting
+                 your text.
+
+                 By default, plaintext is captured as a text/plain content.  You can
+                 override  this  by  starting  the plaintext with "#<" followed by a
+                 content-type specification, e.g.,
+
+                      #<text/richtext
+                      this content will be tagged as text/richtext
+                      #
+                      and this content will be tagged as text/plain
+
+                 Note that if you use the "#<"  plaintext-form,  then  the  content-
+                 description  must  be on the same line which identifies the content
+                 type of the plaintext.
+
+                 If _m_h_n is successful, it renames the original draft to  start  with
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -65-                            MHN(1)
+
+
+                 the "," character and end with the string ".orig", e.g., if you are
+                 editing the file "draft", it  will  be  renamed  to  ",draft.orig".
+                 This allows you to easily recover the _m_h_n composition file.
+
+
+              _A_u_t_o_m_a_t_i_c _C_o_m_p_o_s_i_t_i_o_n
+
+                 Note that MH will not invoke _m_h_n automatically, unless you add this
+                 line to your .mh_profile file:
+
+                      automhnproc: mhn
+
+                 Otherwise, you must specifically give the command
+
+                      What now? edit mhn
+
+                 prior to sending the draft.
+
+                 You can easily tailor MH to help you remember to do this.   Suppose
+                 you have these lines in your profile:
+
+                      mcomp:          -editor mprompter -form mhncomps
+                      mprompter:      -noprepend -norapid
+                      mprompter-next: mhn
+
+                 where _m_c_o_m_p is a link to _c_o_m_p (1),  and  _m_p_r_o_m_p_t_e_r  is  a  link  to
+                 _p_r_o_m_p_t_e_r (1).  Then to send a message using the _m_h_n_c_o_m_p_s components
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -66-                            MHN(1)
+
+
+                 file above, the sequence is:
+
+                      % mcomp
+                      To: user@host
+                      cc:
+                      Subject: multi-media message
+                      --------
+                      #audio/basic [Flint phone]  \
+                          |raw2audio -F < /home/mrose/lib/multi-media/flint.au
+                      #image/gif   [MTR's photo] \
+                                          /home/mrose/lib/multi-media/mrose.gif
+
+                      --------Enter additional text
+
+                      This message contains three contents.
+                      <CTRL-D>
+                      --------
+
+                      What now? edit (this invokes _m_h_n)
+
+                      What now? send
+
+                 You have to remember to type the additional edit  command,  but  it
+                 should be fairly obvious from the interaction.
+
+                 Finally, you should consider adding this line to your profile:
+
+                      lproc: show
+
+                 This way, if you decide to list after invoking _m_h_n as your  editor,
+                 the command
+
+                      What now? list
+
+                 will work as you expect.
+
+
+              _S_e_n_d_i_n_g _F_i_l_e_s _v_i_a _M_a_i_l
+
+                 When you want to send a bunch of files to someone, you can run  the
+                 _v_i_a_m_a_i_l shell script, which is similar the tarmail command:
+
+                      /usr/bs/mh-6.8/lib/viamail mailpath "subject" files ...
+
+                 _v_i_a_m_a_i_l will archive the directories/files you name  with  _t_a_r (1),
+                 and  then  mail  the  compressed archive to the `mailpath' with the
+                 given `subject'.  The archive will be automatically split  up  into
+                 as many messages as necessary in order to get past most mailers.
+
+                 Sometimes you want _v_i_a_m_a_i_l to pause after posting  a  partial  mes-
+                 sage.   This  is usually the case when you are running _s_e_n_d_m_a_i_l and
+                 expect to generate  a  lot  of  partial  messages.   If  the  first
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -67-                            MHN(1)
+
+
+                 argument  given  to  _v_i_a_m_a_i_l  starts with a dash, then it is inter-
+                 preted as the number of seconds to pause in between postings, e.g.,
+
+                      /usr/bs/mh-6.8/lib/viamail -300 mailpath "subject" files ...
+
+                 will pause 5 minutes in between each posting.
+
+                 When these messages are received, invoke _m_h_n once, with the list of
+                 messages,  and  the  `-store'  command.   The _m_h_n program will then
+                 store exactly one message containing the archive.  You can then use
+                 `-show'  to  find out what's inside; possibly  followed by `-store'
+                 to  write  the  archive  to  a  file  where  you  can  subsequently
+                 uncompress and untar it, e.g.,
+
+                      % mhn -list all
+                       msg part  type/subtype             size description
+                         1       message/partial           47K part 1 of 4
+                         2       message/partial           47K part 2 of 4
+                         3       message/partial           47K part 3 of 4
+                         4       message/partial           18K part 4 of 4
+                      % mhn -store all
+                      % mhn -list -verbose last
+                       msg part  type/subtype             size description
+                         5       application/octet-stream 118K
+                                   (extract with uncompress | tar xvpf -)
+                                   type=tar
+                                   conversions=x-compress
+                      % mhn -show last
+                       msg part  type/subtype             size description
+                         5       application/octet-stream 118K
+                      -- headers of message, followed by _t_a_r listing appears here
+                      % mhn -store last
+                      % uncompress < 5.tar.Z | tar xvpf -
+
+                 Alternately, by using the `-auto' switch, _m_h_n will automatically do
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -68-                            MHN(1)
+
+
+                 the extraction for you, e.g.,
+
+                      % mhn -list all
+                       msg part  type/subtype             size description
+                         1       message/partial           47K part 1 of 4
+                         2       message/partial           47K part 2 of 4
+                         3       message/partial           47K part 3 of 4
+                         4       message/partial           18K part 4 of 4
+                      % mhn -store all
+                      % mhn -list -verbose last
+                       msg part  type/subtype             size description
+                         5       application/octet-stream 118K
+                                   (extract with uncompress | tar xvpf -)
+                                   type=tar
+                                   conversions=x-compress
+                      % mhn -show last
+                       msg part  type/subtype             size description
+                         5       application/octet-stream 118K
+                      -- headers of message, followed by _t_a_r listing appears here
+                      % mhn -store -auto last
+                      -- _t_a_r listing appears here as files are extracted
+
+                 As the second _t_a_r listing is generated, the files are extracted.  A
+                 prudent  user  will never put `-auto' in the .mh_profile file.  The
+                 correct procedure is to first use `-show', to find out what will be
+                 extracted.   Then  _m_h_n can be invoked with  `-store' and `-auto' to
+                 perform the extraction.
+
+
+              _U_s_e_r _E_n_v_i_r_o_n_m_e_n_t
+
+                 Because the display environment in which _m_h_n operates may vary  for
+                 a  user,  _m_h_n  will  look  for  the  environment variable $MHN.  If
+                 present, this specifies the name  of  an  additional  user  profile
+                 which  should  be read.  Hence, when a user logs in on a particular
+                 display device, this environment variable should be set to refer to
+                 a  file containing definitions useful for the display device.  Nor-
+                 mally, only entries of the form
+
+                      mhn-show-<type>/<subtype>
+                      mhn-show-<type>
+
+                 need be present.  Finally, _m_h_n will attempt to  consult  one  other
+                 additional user profile, e.g.,
+
+                      /usr/bs/mh-6.8/lib/mhn_defaults
+
+                 which is created automatically during MH installation.
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHN(1)                            -69-                            MHN(1)
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 $MHN                                 Additional profile entries
+                 /usr/bs/mh-6.8/lib/mhn_defaults      System-default profile entries
+                 /usr/bs/mh-6.8/lib/mhl.headers       The headers template
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 mhlproc:             Default program to display message headers
+                 mhn-access-ftp:      Program to retrieve contents via FTP
+                 mhn-cache            Directory to store cached external contents
+                 mhn-charset-<charset>Template for environment to  render  character
+                 sets
+                 mhn-compose-<type>*  Template for composing contents
+                 mhn-show-<type>*     Template for displaying contents
+                 mhn-storage          Directory to store contents
+                 mhn-store-<type>*    Template for storing contents
+                 moreproc:            Default program to display text/plain content
+
+
+            _S_e_e _A_l_s_o
+                 mhl(1)
+                 _M_I_M_E: _M_e_c_h_a_n_i_s_m_s _f_o_r _S_p_e_c_i_f_y_i_n_g _a_n_d _D_e_s_c_r_i_b_i_n_g _t_h_e _F_o_r_m_a_t _o_f _I_n_t_e_r-
+                 _n_e_t _M_e_s_s_a_g_e _B_o_d_i_e_s (RFC 1341),
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (RFC 934).
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-noauto'
+                 `-noebcdicsafe'
+                 `-form mhl.headers'
+                 `-headers'
+                 `-realsize'
+                 `-rfc934mode'
+                 `-noserialonly'
+                 `-show'
+                 `-noverbose'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  last
+                 message selected will become the current message.
+
+
+            _B_u_g_s
+                 Partial messages contained  within  a  multipart  content  are  not
+                 reassembled with the `-store' switch.
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHOOK(1)                          -70-                          MHOOK(1)
+
+
+            _N_A_M_E
+                 mhook, rcvdist, rcvpack, rcvtty  - MH receive-mail hooks
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/rcvdist [-form formfile] [switches for _p_o_s_t_p_r_o_c]
+                      address ...  [-help]
+
+                 /usr/bs/mh-6.8/lib/rcvpack file [-help]
+
+                 /usr/bs/mh-6.8/lib/rcvtty [command] [-form formatfile]
+                      [-format string] [-bell] [-nobell] [-newline] [-nonewline]
+                      [-biff] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 A receive-mail hook is a program that is run whenever you receive a
+                 mail message.  You do NOT invoke the hook yourself, rather the hook
+                 is invoked on your behalf by your system's Message Transport Agent.
+                 See _s_l_o_c_a_l (1) for details on how to activate receive-mail hooks on
+                 your system.
+
+                 Four programs are  currently  available  as  part  of  _M_H,  _r_c_v_d_i_s_t
+                 (redistribute  incoming messages to additional recipients), _r_c_v_p_a_c_k
+                 (save incoming messages in a _p_a_c_k_f'd file), and _r_c_v_t_t_y (notify user
+                 of   incoming  messages).   The  fourth  program,  _r_c_v_s_t_o_r_e (1)  is
+                 described separately.  They all reside in  the  /_u_s_r/_b_s/_m_h-_6._8/_l_i_b/
+                 directory.
+
+                 The _r_c_v_d_i_s_t program will resend a copy of the message to all of the
+                 addresses  listed  on  its command line.  It uses the format string
+                 facility described in _m_h-_f_o_r_m_a_t (5).
+
+                 The _r_c_v_p_a_c_k program will append a copy of the message to  the  file
+                 listed  on  its  command  line.  Its use is obsoleted by the "file"
+                 action of _s_l_o_c_a_l.
+
+                 The _r_c_v_t_t_y program executes the named file with the message as  its
+                 standard input, and writes the resulting output on your terminal.
+
+                 If no file is specified,  or  is  bogus,  etc.,  then  _r_c_v_t_t_y  will
+                 instead    write    a    one-line   scan   listing.    Either   the
+                 `-form formatfile' or `-format string' option may be used to  over-
+                 ride  the  default output format (see _m_h-_f_o_r_m_a_t (5)).  A newline is
+                 output before the message output, and the  terminal  bell  is  rung
+                 after  the  output.   The  `-nonewline'  and `-nobell' options will
+                 inhibit these functions.
+
+                 In addition to the  standard  _m_h-_f_o_r_m_a_t (5)  escapes,  _r_c_v_t_t_y  also
+                 recognizes the following additional _c_o_m_p_o_n_e_n_t escapes:
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHOOK(1)                          -71-                          MHOOK(1)
+
+
+                 _E_s_c_a_p_e    _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 body      string   the (compressed) first part of the body
+                 dtimenow  date     the current date
+                 folder    string   the name of the current folder
+
+                 Normally, _r_c_v_t_t_y obeys write permission  as  granted  by  _m_e_s_g (1).
+                 With  the  `-biff' option, _r_c_v_t_t_y will obey the notification status
+                 set by _b_i_f_f (1) instead.  If the terminal access daemon  (TTYD)  is
+                 available  on  your system, then _r_c_v_t_t_y will give its output to the
+                 daemon for output instead of writing on the user's terminal.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+                 $HOME/.maildelivery                  The file controlling local delivery
+                 /usr/bs/mh-6.8/lib/maildelivery      Rather than the standard file
+
+
+            _S_e_e _A_l_s_o
+                 rcvstore (1), mh-format(5), slocal(1)
+
+
+            _B_u_g_s
+                 Only two return codes are meaningful, others should be.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPARAM(1)                        -72-                        MHPARAM(1)
+
+
+            _N_A_M_E
+                 mhparam - print MH profile components
+
+            _S_Y_N_O_P_S_I_S
+                 mhparam [components] [-all] [-component] [-nocomponent] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_p_a_r_a_m writes the value of the specified profile component to  the
+                 standard output separated by newlines.  If the profile component is
+                 not present, the default value (or nothing if there is no  default)
+                 is printed.
+
+                 If more than one component is specified in the  `components'  list,
+                 the  component  value is preceded by the component name.  If `-com-
+                 ponent' is specified, the component name  is  displayed  even  when
+                 only  one  component is specified.  If `-nocomponent' is specified,
+                 the component name is not displayed even when more  than  one  com-
+                 ponent is specified.
+
+                 If `-all' is specified,  all  components  if  the  MH  profile  are
+                 displayed and other arguments are ignored.
+
+                 Examples:
+
+                      % mhparam path
+                      Mail
+
+                      % mhparam mhlproc
+                      /usr/bs/mh-6.8/lib/mhl
+
+                      % mhparam -component path
+                      Path:       Mail
+
+                      % mhparam AliasFile rmmproc
+                      AliasFile:  aliases
+                      rmmproc:    rmmproc
+
+                      % mhparam -nocomponent AliasFile rmmproc
+                      aliases
+                      rmmproc
+
+                 _M_h_p_a_r_a_m is also useful in back-quoted operations:
+
+                      % fgrep cornell.edu `mhpath +`/`mhparam aliasfile`
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPARAM(1)                        -73-                        MHPARAM(1)
+
+
+            _S_e_e _A_l_s_o
+                 mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-nocomponent' if only one component is specified
+                 `-component' if more than one component is specified
+                 `components' defaults to none
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -74-                         MHPATH(1)
+
+
+            _N_A_M_E
+                 mhpath - print full pathnames of MH messages and folders
+
+            _S_Y_N_O_P_S_I_S
+                 mhpath [+folder] [msgs] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_p_a_t_h expands and sorts the message list  `msgs'  and  writes  the
+                 full  pathnames of the messages to the standard output separated by
+                 newlines.  If no `msgs' are specified, _m_h_p_a_t_h  outputs  the  folder
+                 pathname  instead.   If  the  only argument is `+', your MH _P_a_t_h is
+                 output; this can be useful is shell scripts.
+
+                 Contrasted with other MH commands, a message argument to _m_h_p_a_t_h may
+                 often be intended for _w_r_i_t_i_n_g.  Because of this:
+
+                 1) the name "new" has been added to _m_h_p_a_t_h's list of reserved  mes-
+                 sage  names (the others are "first", "last", "prev", "next", "cur",
+                 and "all").  The new message is equivalent to the message after the
+                 last  message  in a folder (and equivalent to 1 in a folder without
+                 messages).  The "new" message may not be used as part of a  message
+                 range.
+
+                 2) Within a message list, the following designations may  refer  to
+                 messages that do not exist: a single numeric message name, the sin-
+                 gle message name "cur", and (obviously)  the  single  message  name
+                 "new".   All  other message designations must refer to at least one
+                 existing message.
+
+                 3) An empty folder is not in itself an error.
+
+                 Message numbers greater than the  highest  existing  message  in  a
+                 folder  as  part  of a range designation are replaced with the next
+                 free message number.
+
+                 Examples: The current folder foo contains messages 3 5 6.   Cur  is
+                 4.
+
+                      % mhpath
+                      /r/phyl/Mail/foo
+
+                      % mhpath all
+                      /r/phyl/Mail/foo/3
+                      /r/phyl/Mail/foo/5
+                      /r/phyl/Mail/foo/6
+
+                      % mhpath 2001
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath 1-2001
+                      /r/phyl/Mail/foo/3
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -75-                         MHPATH(1)
+
+
+                      /r/phyl/Mail/foo/5
+                      /r/phyl/Mail/foo/6
+
+                      % mhpath new
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath last new
+                      /r/phyl/Mail/foo/6
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath last-new
+                      bad message list "last-new".
+
+                      % mhpath cur
+                      /r/phyl/Mail/foo/4
+
+                      % mhpath 1-2
+                      no messages in range "1-2".
+
+                      % mhpath first:2
+                      /r/phyl/Mail/foo/3
+                      /r/phyl/Mail/foo/5
+
+                      % mhpath 1 2
+                      /r/phyl/Mail/foo/1
+                      /r/phyl/Mail/foo/2
+
+                 _M_H_p_a_t_h is also useful in back-quoted operations:
+
+                      % cd `mhpath +inbox`
+
+                      % echo `mhpath +`
+                      /r/phyl/Mail
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 folder(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to none
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -76-                         MHPATH(1)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 Like all MH commands, _m_h_p_a_t_h expands and sorts  [msgs].   So  don't
+                 expect
+
+                      mv `mhpath 501 500`
+
+                 to move 501 to 500.  Quite the reverse.  But
+
+                      mv `mhpath 501` `mhpath 500`
+
+                 will do the trick.
+
+                 Out of range message 0 is treated far more severely than large  out
+                 of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSGCHK(1)                         -77-                         MSGCHK(1)
+
+
+            _N_A_M_E
+                 msgchk - check for messages
+
+            _S_Y_N_O_P_S_I_S
+                 msgchk [-date] [-nodate] [-notify all/mail/nomail]
+                      [-nonotify all/mail/nomail] [-host host] [-user user] [-apop]
+                      [-noapop] [-rpop] [-norpop] [users ...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _m_s_g_c_h_k program checks all known mail drops for mail waiting for
+                 you.  For those drops which have mail for you, _m_s_g_c_h_k will indicate
+                 if it believes that you have seen the mail in question before.
+
+                 The `-notify type' switch indicates under what circumstances _m_s_g_c_h_k
+                 should  produce a message.  The default is `-notify all' which says
+                 that _m_s_g_c_h_k should always report the status of the users  maildrop.
+                 Other  values  for  `type'  include  `mail'  which says that _m_s_g_c_h_k
+                 should report the status of waiting mail; and, `nomail' which  says
+                 that  _m_s_g_c_h_k  should  report  the  status  of empty maildrops.  The
+                 `-nonotify type' switch has the inverted sense, so  `-nonotify all'
+                 directs  _m_s_g_c_h_k  to  never report the status of maildrops.  This is
+                 useful if the  user  wishes  to  check  _m_s_g_c_h_k's  exit  status.   A
+                 non-zero  exit  status  indicates  that mail was not waiting for at
+                 least one of the indicated users.
+
+                 If _m_s_g_c_h_k produces output, then the `-date' switch  directs  _m_s_g_c_h_k
+                 to  print  out  the  last date mail was read, if this can be deter-
+                 mined.
+
+                 If the local host  is  configured  as  a  POP  client,  or  if  the
+                 `-host host'  switch  is  given,  _m_s_g_c_h_k will query the POP service
+                 host as to the status of mail waiting.  If the `-user user'  switch
+                 is  not given, then the current username is used.  Normally, _m_s_g_c_h_k
+                 will prompt for a password to use.  However, if the `-apop'  switch
+                 is  given,  _m_s_g_c_h_k will generate authentication credentials to pro-
+                 vide for origin authentication and replay protection, but which  do
+                 not involve sending a password in the clear over the network.  Oth-
+                 erwise, if the `-rpop' switch is given, then _m_s_g_c_h_k will try to use
+                 a "trusted" connection (ala the BSD r-commands).
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+                 /usr/spool/mail/$USER                Location of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSGCHK(1)                         -78-                         MSGCHK(1)
+
+
+            _S_e_e _A_l_s_o
+                 _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081),
+                 inc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `user' defaults to the current user
+                 `-date'
+                 `-notify all'
+                 `-rpop'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -79-                            MSH(1)
+
+
+            _N_A_M_E
+                 msh - MH shell (and BBoard reader)
+
+            _S_Y_N_O_P_S_I_S
+                 msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _m_s_h is an interactive program that implements a subset of the  nor-
+                 mal _M_H commands operating on a single file in _p_a_c_k_f'd format.  That
+                 is, _m_s_h is used to read a file that contains a number of  messages,
+                 as  opposed  to the standard _M_H style of reading a number of files,
+                 each file being a separate message in a folder.  _m_s_h's chief advan-
+                 tage is that the normal _M_H style does not allow a file to have more
+                 than one message in it.  Hence, _m_s_h is ideal for  reading  _B_B_o_a_r_d_s,
+                 as  these  files are delivered by the transport system in this for-
+                 mat.  In addition, _m_s_h can be used on other files, such as  message
+                 archives  which  have been _p_a_c_ked (see _p_a_c_k_f (1)).  Finally, _m_s_h is
+                 an excellent _M_H tutor.  As the only commands available to the  user
+                 are  _M_H  commands,  this  allows _M_H beginners to concentrate on how
+                 commands to _M_H are formed and (more or less) what they mean.
+
+                 When invoked, _m_s_h reads the named file, and enters a command  loop.
+                 The  user  may type most of the normal _M_H commands.  The syntax and
+                 semantics of these commands typed to _m_s_h are identical to their  _M_H
+                 counterparts.   In  cases  where  the nature of _m_s_h would be incon-
+                 sistent (e.g., specifying a `+folder' with some commands), _m_s_h will
+                 duly inform the user.  The commands that _m_s_h currently supports (in
+                 some slightly modified or restricted forms) are:
+
+                      ali
+                      burst
+                      comp
+                      dist
+                      folder
+                      forw
+                      inc
+                      mark
+                      mhmail
+                      mhn
+                      msgchk
+                      next
+                      packf
+                      pick
+                      prev
+                      refile
+                      repl
+                      rmm
+                      scan
+                      send
+                      show
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -80-                            MSH(1)
+
+
+                      sortm
+                      whatnow
+                      whom
+
+                 In addition, _m_s_h has a "help" command which gives a brief overview.
+                 To  terminate  _m_s_h, type CTRL-D, or use the "quit" command.  If _m_s_h
+                 is being invoked from _b_b_c, then typing CTRL-D will also tell _b_b_c to
+                 exit as well, while using the "quit" command will return control to
+                 _b_b_c, and _b_b_c will continue examining the list of BBoards that it is
+                 scanning.
+
+                 If the file is writable and has been modified,  then  using  "quit"
+                 will query the user if the file should be updated.
+
+                 The `-prompt string' switch sets the prompting string for _m_s_h.
+
+                 You may wish to use an alternate _M_H profile for the  commands  that
+                 _m_s_h  executes; see _m_h-_p_r_o_f_i_l_e (5) for details about the $MH envari-
+                 able.
+
+                 When invoked from _b_b_c, two special features are enabled: First, the
+                 `-scan' switch directs _m_s_h to do a `scan unseen' on start-up if new
+                 items are present in the BBoard.  This feature is  best  used  from
+                 _b_b_c,  which  correctly sets the stage.  Second, the _m_a_r_k command in
+                 _m_s_h acts specially when you are reading a BBoard,  since  _m_s_h  will
+                 consult the sequence "unseen" in determining what messages you have
+                 actually read.  When _m_s_h exits, it reports this information to _b_b_c.
+                 In  addition,  if  you give the _m_a_r_k command with no arguments, _m_s_h
+                 will interpret  it  as  `mark -sequence unseen -delete -nozero all'
+                 Hence,  to discard all of the messages in the current BBoard you're
+                 reading, just use the _m_a_r_k command with no arguments.
+
+                 Normally, the "exit" command is identical to the "quit" command  in
+                 _m_s_h.   When  run  under _b_b_c however, "exit" directs _m_s_h to mark all
+                 messages as seen and then "quit".  For speedy type-in, this command
+                 is often abbreviated as just "e".
+
+                 When invoked from _v_m_h, another  special  feature  is  enabled:  The
+                 `topcur' switch directs _m_s_h to have the current message "track" the
+                 top line of the _v_m_h scan window.  Normally,  _m_s_h  has  the  current
+                 message  "track" the center of the window (under `-notopcur', which
+                 is the default).
+
+                 _m_s_h supports an output redirection facility.  Commands may be  fol-
+                 lowed by one of
+
+                      > _f_i_l_e     write output to _f_i_l_e
+                      >> _f_i_l_e    append output to _f_i_l_e
+                      | _c_o_m_m_a_n_d  pipe output to UNIX _c_o_m_m_a_n_d
+
+                 If _f_i_l_e starts with a `~' (tilde), then a _c_s_h-like expansion  takes
+                 place.  Note that _c_o_m_m_a_n_d is interpreted by _s_h (1).  Also note that
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -81-                            MSH(1)
+
+
+                 _m_s_h does NOT support history substitutions, variable substitutions,
+                 or alias substitutions.
+
+                 When parsing commands to the left of any  redirection  symbol,  _m_s_h
+                 will honor `\' (back-slash) as the quote next-character symbol, and
+                 `"' (double-quote)  as  quote-word  delimiters.   All  other  input
+                 tokens are separated by whitespace (spaces and tabs).
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Msg-Protect:         To set mode when creating a new `file'
+                 fileproc:            Program to file messages
+                 showproc:            Program to show messages
+
+
+            _S_e_e _A_l_s_o
+                 bbc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to "./msgbox"
+                 `-prompt (msh) '
+                 `-noscan'
+                 `-notopcur'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -82-                            MSH(1)
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _m_s_h.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+                 There is a strict limit of messages  per  file  in  _p_a_c_k_f'd  format
+                 which _m_s_h can handle.  Usually, this limit is 1000 messages.
+
+                 Please remember that _m_s_h is not the _C_S_h_e_l_l, and that a lot  of  the
+                 nice facilities provided by the latter are not present in the form-
+                 er.
+
+                 In particular, _m_s_h does not understand back-quoting,  so  the  only
+                 effective  way  to  use  _p_i_c_k  inside  _m_s_h  is  to  always  use the
+                 `-seq select' switch.  Clever users of _M_H will put the line
+
+                      pick: -seq select -list
+
+                 in their .mh_profile file so that _p_i_c_k works equally well from both
+                 the shell and _m_s_h.
+
+                 _s_o_r_t_m always uses "-noverbose" and if "-textfield field"  is  used,
+                 "-limit 0".
+
+                 The _m_s_h program inherits most (if not all) of the bugs from the  _M_H
+                 commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            NEXT(1)                           -83-                           NEXT(1)
+
+
+            _N_A_M_E
+                 next - show the next message
+
+            _S_Y_N_O_P_S_I_S
+                 next [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _N_e_x_t performs a _s_h_o_w on the  next  message  in  the  specified  (or
+                 current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+                 gram _s_h_o_w_p_r_o_c, which is called to list the message.   This  command
+                 is  almost  exactly  equivalent to "show next".  Consult the manual
+                 entry for _s_h_o_w (1) for all the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 showproc:            Program to show the message
+
+
+            _S_e_e _A_l_s_o
+                 show(1), prev(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is specified, it will become the current  folder.   The
+                 message that is shown (i.e., the next message in sequence) will be-
+                 come the current message.
+
+
+            _B_u_g_s
+                 _n_e_x_t is really a link to the _s_h_o_w program.  As  a  result,  if  you
+                 make  a  link  to  _n_e_x_t and that link is not called _n_e_x_t, your link
+                 will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+                 profile-entry  for the link to your _M_H profile and add the argument
+                 _n_e_x_t to the entry.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PACKF(1)                          -84-                          PACKF(1)
+
+
+            _N_A_M_E
+                 packf - compress an MH folder into a single file
+
+            _S_Y_N_O_P_S_I_S
+                 packf [+folder] [msgs] [-file name] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_a_c_k_f takes messages from a folder and  copies  them  to  a  single
+                 file.  Each message in the file is separated by four CTRL-A's and a
+                 newline (identical to the way messages are stored in your receiving
+                 mail drop).  Messages packed can be unpacked using _i_n_c.
+
+                 If the _n_a_m_e given to the `-file name' switch exists, then the  mes-
+                 sages  specified will be appended to the end of the file, otherwise
+                 the file will be created and the messages appended.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 .msgbox.map                          A binary index of the file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Msg-Protect:         To set mode when creating a new `file'
+
+
+            _S_e_e _A_l_s_o
+                 inc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-file ./msgbox'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message packed will become the current message.
+
+
+            _B_u_g_s
+                 _P_a_c_k_f doesn't handle the old  UUCP-style  "mbox"  format  (used  by
+                 _S_e_n_d_M_a_i_l).   To  pack  messages  into  this  format, use the script
+                 /_u_s_r/_b_s/_m_h-_6._8/_l_i_b/_p_a_c_k_m_b_o_x.  Note that _p_a_c_k_m_b_o_x does not take  the
+                 `-file' option of _p_a_c_k_f, and instead writes its output on _s_t_d_o_u_t.
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -85-                           PICK(1)
+
+
+            _N_A_M_E
+                 pick - select messages by content
+
+            _S_Y_N_O_P_S_I_S
+                 pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+                      [-lbrace ... -rbrace] [--component pattern] [-cc pattern]
+                      [-date pattern] [-from pattern] [-search pattern]
+                      [-subject pattern] [-to pattern] [-after date] [-before date]
+                      [-datefield field] [-sequence name ...] [-public] [-nopublic]
+                      [-zero] [-nozero] [-list] [-nolist] [-help]
+
+                 typically:
+                      scan `pick -from jones`
+                      pick -to holloway -sequence select
+                      show `pick -before friday`
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_i_c_k searches messages within a folder for the specified  contents,
+                 and then identifies those messages.  Two types of search primitives
+                 are available: pattern matching and date constraint operations.
+
+                 A modified _g_r_e_p(1) is used to perform the  matching,  so  the  full
+                 regular  expression  (see _e_d(1)) facility is available within `pat-
+                 tern'.  With `-search', `pattern' is used directly,  and  with  the
+                 others, the grep pattern constructed is:
+
+                      "component[ \t]*:.*pattern"
+
+                 This means that the pattern specified for a `-search' will be found
+                 everywhere in the message, including the header and the body, while
+                 the other pattern matching  requests  are  limited  to  the  single
+                 specified component.  The expression
+
+                      `--component pattern'
+
+                 is a shorthand for specifying
+
+                      `-search "component[ \t]*:.*pattern" '
+
+                 It is used to pick a component which is not one  of  "To:",  "cc:",
+                 "Date:",     "From:",     or    "Subject:".     An    example    is
+                 `pick --reply-to pooh'.
+
+                 Pattern matching is performed on  a  per-line  basis.   Within  the
+                 header  of the message, each component is treated as one long line,
+                 but in the body, each line is separate.  Lower-case letters in  the
+                 search  pattern  will  match either lower or upper case in the mes-
+                 sage, while upper case will match only upper case.
+
+                 Note that since the `-date' switch is a pattern matching  operation
+                 (as  described  above), to find messages sent on a certain date the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -86-                           PICK(1)
+
+
+                 pattern string must match the text of the "Date:" field of the mes-
+                 sage.
+
+                 Independent of  any  pattern  matching  operations  requested,  the
+                 switches `-after date' or `-before date' may also be used to intro-
+                 duce date/time contraints on all of the messages.  By default,  the
+                 "Date:"  field  is  consulted,  but  if another date yielding field
+                 (such as "BB-Posted:" or  "Delivery-Date:")  should  be  used,  the
+                 `-datefield field' switch may be used.
+
+                 With `-before' and `-after', _p_i_c_k  will  actually  parse  the  date
+                 fields in each of the messages specified in `msgs' and compare them
+                 to the date/time specified.  If `-after' is given, then only  those
+                 messages  whose  "Date:"  field  value is chronologically after the
+                 date specified will be considered.  The `-before' switch  specifies
+                 the complimentary action.
+
+                 Both the `-after' and `-before' switches take legal 822-style  date
+                 specifications  as  arguments.   _P_i_c_k  will default certain missing
+                 fields so that the entire date need not be specified.  These fields
+                 are  (in  order  of defaulting): timezone, time and timezone, date,
+                 date and timezone.  All defaults are taken from the  current  date,
+                 time, and timezone.
+
+                 In addition to 822-style dates, _p_i_c_k will also recognize any of the
+                 days  of  the week ("sunday", "monday", and so on), and the special
+                 dates "today", "yesterday" (24 hours ago), and "tomorrow" (24 hours
+                 from  now).   All  days of the week are judged to refer to a day in
+                 the past (e.g.,  telling  _p_i_c_k  "saturday"  on  a  "tuesday"  means
+                 "last saturday" not "this saturday").
+
+                 Finally, in addition to these  special  specifications,  _p_i_c_k  will
+                 also  honor a specification of the form "-dd", which means "dd days
+                 ago".
+
+                 _P_i_c_k supports complex boolean operations on  the  searching  primi-
+                 tives  with  the  `-and',  `-or', `-not', and `-lbrace ... -rbrace'
+                 switches.  For example,
+
+                      pick -after yesterday -and
+                           -lbrace -from freida -or -from fear -rbrace
+
+                 identifies messages recently sent by "frieda" or "fear".
+
+                 The matching primitives take precedence  over  the  `-not'  switch,
+                 which in turn takes precedence over `-and' which in turn takes pre-
+                 cedence over  `-or'.   To  override  the  default  precedence,  the
+                 `-lbrace'  and `-rbrace' switches are provided, which act just like
+                 opening and closing parentheses in logical expressions.
+
+                 If no search criteria are given, all the messages specified on  the
+                 command line are selected (this defaults to "all").
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -87-                           PICK(1)
+
+
+                 Once the search has been performed, if the `-list' switch is given,
+                 the  message  numbers  of  the selected messages are written to the
+                 standard output separated by newlines.  This  is  _e_x_t_r_e_m_e_l_y  useful
+                 for quickly generating arguments for other _M_H programs by using the
+                 "backquoting" syntax of the shell.  For example, the command
+
+                      scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+                 says to _s_c_a_n those messages in the indicated folder which meet  the
+                 appropriate criterion.  Note that since _p_i_c_k 's context changes are
+                 written out prior to _s_c_a_n 's invocation,  you  need  not  give  the
+                 folder argument to _s_c_a_n as well.
+
+                 Regardless of the operation of the `-list' switch,  the  `-sequence
+                 name' switch may be given once for each sequence the user wishes to
+                 define.  For each sequence named, that sequence will be defined  to
+                 mean exactly those messages selected by _p_i_c_k.  For example,
+
+                      pick -from frated -seq fred
+
+                 defines a new message sequence for the current folder called "fred"
+                 which contains exactly those messages that were selected.
+
+                 Note that whenever _p_i_c_k processes  a  `-sequence name'  switch,  it
+                 sets `-nolist'.
+
+                 By default, _p_i_c_k will zero the sequence  before  adding  it.   This
+                 action  can be disabled with the `-nozero' switch, which means that
+                 the messages selected by _p_i_c_k will be added to the sequence, if  it
+                 already  exists,  and  any messages already a part of that sequence
+                 will remain so.
+
+                 The `-public' and `-nopublic' switches are used by _p_i_c_k in the same
+                 way _m_a_r_k uses them.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 mark(1)
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -88-                           PICK(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-datefield date'
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-zero'
+                 `-list' is the default if no `-sequence', `-nolist' otherwise
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the _p_i_c_k command would _s_h_o_w,  _s_c_a_n,  or
+                 _r_e_f_i_l_e  the  selected  messages.   This was rather "inverted logic"
+                 from the UNIX point of view, so _p_i_c_k  was  changed  to  define  se-
+                 quences  and  output  those  sequences.  Hence, _p_i_c_k can be used to
+                 generate the arguments for all other _M_H commands, instead of giving
+                 _p_i_c_k endless switches for invoking those commands itself.
+
+                 Also, previous versions of _p_i_c_k balked  if  you  didn't  specify  a
+                 search  string or a date/time constraint.  The current version does
+                 not, and merely matches the messages you specify.   This  lets  you
+                 type something like:
+
+                      show `pick last:20 -seq fear`
+
+                 instead of typing
+
+                      mark -add -nozero -seq fear last:20
+                      show fear
+
+                 Finally, timezones used to be ignored when  comparing  dates:  they
+                 aren't any more.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 Use "pick sequence -list" to enumerate the messages in  a  sequence
+                 (such as for use by a shell script).
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -89-                           PICK(1)
+
+
+            _B_u_g_s
+                 The argument to the `-after' and `-before' switches must be  inter-
+                 preted  as  a  single token by the shell that invokes _p_i_c_k.  There-
+                 fore, one must usually place the argument  to  this  switch  inside
+                 double-quotes.  Furthermore, any occurance of `-datefield' must oc-
+                 cur prior to the `-after' or `-before' switch it applies to.
+
+                 If _p_i_c_k is used in a back-quoted operation, such as
+
+                      scan `pick -from jones`
+
+                 and _p_i_c_k selects no messages (e.g., no messages are from  "jones"),
+                 then  the  shell  will  still run the outer command (e.g., "scan").
+                 Since no messages were matched, _p_i_c_k produced no  output,  and  the
+                 argument given to the outer command as a result of backquoting _p_i_c_k
+                 is empty.  In the case of _M_H programs, the outer command  now  acts
+                 as  if  the  default `msg' or `msgs' should be used (e.g., "all" in
+                 the case of  _s_c_a_n ).   To  prevent  this  unexpected  behavior,  if
+                 `-list'  was  given,  and if its standard output is not a tty, then
+                 _p_i_c_k outputs the illegal message number "0" when  it  fails.   This
+                 lets the outer command fail gracefully as well.
+
+                 The pattern syntax "[l-r]" is not  supported;  each  letter  to  be
+                 matched must be included within the square brackets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PREV(1)                           -90-                           PREV(1)
+
+
+            _N_A_M_E
+                 prev - show the previous message
+
+            _S_Y_N_O_P_S_I_S
+                 prev [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [-switches for _s_h_o_w_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_r_e_v performs a _s_h_o_w on the previous message in the  specified  (or
+                 current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+                 gram named by _s_h_o_w_p_r_o_c, which is called to list the message.   This
+                 command  is  almost exactly equivalent to "show prev".  Consult the
+                 manual entry for _s_h_o_w (1) for all the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 showproc:            Program to show the message
+
+
+            _S_e_e _A_l_s_o
+                 show(1), next(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is specified, it will become the current  folder.   The
+                 message that is shown (i.e., the previous message in sequence) will
+                 become the current message.
+
+
+            _B_u_g_s
+                 _p_r_e_v is really a link to the _s_h_o_w program.  As  a  result,  if  you
+                 make  a  link  to  _p_r_e_v and that link is not called _p_r_e_v, your link
+                 will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+                 profile-entry  for the link to your _M_H profile and add the argument
+                 _p_r_e_v to the entry.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -91-                       PROMPTER(1)
+
+
+            _N_A_M_E
+                 prompter - prompting editor front-end for MH
+
+            _S_Y_N_O_P_S_I_S
+                 prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+                      [-norapid] [-doteof] [-nodoteof] file [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 This program is normally not invoked directly by  users  but  takes
+                 the  place  of  an  editor  and  acts  as  an editor front-end.  It
+                 operates on an 822-style message draft skeleton specified by  file,
+                 normally provided by _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l.
+
+                 _P_r_o_m_p_t_e_r is an editor which allows rapid composition  of  messages.
+                 It  is particularly useful to network and low-speed (less than 2400
+                 baud) users of _M_H.  It is an _M_H program in that it can have its own
+                 profile  entry with switches, but it is not invoked directly by the
+                 user.  The commands _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l invoke  _p_r_o_m_p_t_e_r  as
+                 an  editor,  either when invoked with `-editor prompter', or by the
+                 profile  entry  "Editor: prompter",  or  when  given  the   command
+                 `edit prompter' at "What now?" level.
+
+                 For each empty component _p_r_o_m_p_t_e_r finds in the draft, the  user  is
+                 prompted  for a response; A <RETURN> will cause the whole component
+                 to be left out.  Otherwise, a `\' preceding a  <RETURN>  will  con-
+                 tinue  the  response  on the next line, allowing for multiline com-
+                 ponents.  Continuation lines must begin with a space or tab.
+
+                 Each non-empty component is copied to the draft  and  displayed  on
+                 the terminal.
+
+                 The start of the message body is denoted by a blank line or a  line
+                 of dashes.  If the body is non-empty, the prompt, which isn't writ-
+                 ten to the file, is
+
+                     "--------Enter additional text",
+
+                 or (if `-prepend' was given)
+
+                     "--------Enter initial text".
+
+                 Message-body typing is  terminated  with  an  end-of-file  (usually
+                 CTRL-D).   With  the  `-doteof'  switch,  a period on a line all by
+                 itself also  signifies  end-of-file.   At  this  point  control  is
+                 returned  to  the  calling  program,  where the user is asked "What
+                 now?".  See _w_h_a_t_n_o_w for the valid options to this query.
+
+                 By using the `-prepend' switch, the user can  add  type-in  to  the
+                 beginning of the message body and have the rest of the body follow.
+                 This is useful for the _f_o_r_w command.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -92-                       PROMPTER(1)
+
+
+                 By using the `-rapid' switch, if the draft already contains text in
+                 the message-body, it is not displayed on the user's terminal.  This
+                 is useful for low-speed terminals.
+
+                 The line editing characters for kill and erase may be specified  by
+                 the  user via the arguments `-kill chr' and `-erase chr', where chr
+                 may be a character; or `\nnn', where "nnn" is the octal  value  for
+                 the character.
+
+                 An interrupt (usually CTRL-C) during component  typing  will  abort
+                 _p_r_o_m_p_t_e_r  and  the _M_H command that invoked it.  An interrupt during
+                 message-body typing is equivalent to CTRL-D,  for  historical  rea-
+                 sons.  This means that _p_r_o_m_p_t_e_r should finish up and exit.
+
+                 The first non-flag argument to _p_r_o_m_p_t_e_r is taken as the name of the
+                 draft file, and subsequent non-flag arguments are ignored.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /tmp/prompter*                       Temporary copy of message
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 prompter-next:       To name the editor to be  used  on  exit  from
+                 _p_r_o_m_p_t_e_r
+                 Msg-Protect:         To set mode when creating a new draft
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prepend'
+                 `-norapid'
+                 `-nodoteof'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 The  `-rapid'  option  is  particularly  useful  with   _f_o_r_w,   and
+                 `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+                 The user may wish to link _p_r_o_m_p_t_e_r under several names (e.g.,  "ra-
+                 pid")  and  give  appropriate switches in the profile entries under
+                 these names (e.g., "rapid:  -rapid").   This  facilitates  invoking
+                 prompter  differently for different _M_H commands (e.g., "forw: -edi-
+                 tor rapid").
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -93-                       PROMPTER(1)
+
+
+            _B_u_g_s
+                 _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will lose if  you  edit  files  with
+                 nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RCVSTORE(1)                       -94-                       RCVSTORE(1)
+
+
+            _N_A_M_E
+                 rcvstore - incorporate new mail asynchronously
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/rcvstore [+folder] [-create] [-nocreate]
+                      [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_c_v_s_t_o_r_e incorporates a message from the standard input into an  _M_H
+                 folder.   If  `+folder'  isn't specified, a folder in the user's _M_H
+                 directory will be used, either that specified by the "Inbox:" entry
+                 in  the  user's profile, or the folder named "inbox".  The new mes-
+                 sage being incorporated is assigned the next highest number in  the
+                 folder.   If  the specified (or default) folder doesn't exist, then
+                 it will be created if the `-create' option is specified,  otherwise
+                 _r_c_v_s_t_o_r_e will exit.
+
+                 If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+                 be  used as the protection on the newly created messages, otherwise
+                 the _M_H default of 0644 will be used.  During all operations on mes-
+                 sages,  this  initially  assigned  protection will be preserved for
+                 each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+                 individual   message,   and   its   protection  will  be  preserved
+                 thereafter.
+
+                 _R_c_v_s_t_o_r_e will incorporate anything except zero length messages into
+                 the user's MH folder.
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+                 then  _r_c_v_s_t_o_r_e  will  add  the  newly  incorporated message to each
+                 sequence named by the  profile  entry.   This  is  similar  to  the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.  Note that _r_c_v_s_t_o_r_e will  not
+                 zero each sequence prior to adding messages.
+
+                 Furthermore, the incoming messages may  be  added  to  user-defined
+                 sequences  as  they  arrive  by  appropriate use of the `-sequence'
+                 option.  As with _p_i_c_k, use of the `-zero'  and  `-nozero'  switches
+                 can  also  be used to zero old sequences or not.  Similarly, use of
+                 the `-public' and `-nopublic switches may be used  to  force  addi-
+                 tions to public and private sequences.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RCVSTORE(1)                       -95-                       RCVSTORE(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Folder-Protect:      To set mode when creating a new folder
+                 Inbox:               To find the default inbox
+                 Msg-Protect:         To set mode when creating a new message
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), pick(1), mh-mail(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to "inbox"
+                 `-create'
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-nozero'
+
+
+            _C_o_n_t_e_x_t
+                 No context changes will be attempted, with  the  exception  of  se-
+                 quence manipulation.
+
+
+            _B_u_g_s
+                 If you use the "Unseen-Sequence" profile entry, _r_c_v_s_t_o_r_e could  try
+                 to update the context while another _M_H process is also trying to do
+                 so.  This can cause the context  to  become  corrupted.   To  avoid
+                 this,  do not use _r_c_v_s_t_o_r_e if you use the "Unseen-Sequence" profile
+                 entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REFILE(1)                         -96-                         REFILE(1)
+
+
+            _N_A_M_E
+                 refile - file message in other folders
+
+            _S_Y_N_O_P_S_I_S
+                 refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+                      [-src +folder] [-file file] [-rmmproc program] [-normmproc]
+                      +folder ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_e_f_i_l_e moves (_m_v (1)) or links  (_l_n (1))  messages  from  a  source
+                 folder  into  one  or  more destination folders.  If you think of a
+                 message as a sheet of paper, this operation is  not  unlike  filing
+                 the  sheet  of  paper  (or copies) in file cabinet folders.  When a
+                 message is filed, it is linked into the  destination  folder(s)  if
+                 possible,  and  is  copied  otherwise.   As long as the destination
+                 folders are all on the same file  system,  multiple  filing  causes
+                 little  storage  overhead.   This  facility  provides a good way to
+                 cross-file or multiply-index messages.  For example, if  a  message
+                 is received from Jones about the ARPA Map Project, the command
+
+                      refile cur +jones +Map
+
+                 would allow the message to be found in either of  the  two  folders
+                 `jones' or `Map'.
+
+                 The option `-file file' directs _r_e_f_i_l_e to use the specified file as
+                 the  source  message  to  be  filed,  rather  than a message from a
+                 folder.  Note that the file should be a validly formatted  message,
+                 just like any other _M_H message.  It should NOT be in mail drop for-
+                 mat (to convert a file in mail drop format to a folder of  _M_H  mes-
+                 sages, see _i_n_c (1)).
+
+                 If a destination folder doesn't exist, _r_e_f_i_l_e will ask if you  want
+                 to  create  it.  A negative response will abort the file operation.
+                 If the standard input for _r_e_f_i_l_e is _n_o_t a tty, then _r_e_f_i_l_e will not
+                 ask  any  questions  and  will  proceed as if the user's answer was
+                 "yes" for all questions.
+
+                 The option `-link' preserves the source folder copy of the  message
+                 (i.e.,  it  does  a  _l_n(1) rather than a _m_v(1)), whereas, `-nolink'
+                 deletes the filed messages from the source folder.  Normally,  when
+                 a  message  is filed, it is assigned the next highest number avail-
+                 able in each of the destination folders.  Use  of  the  `-preserve'
+                 switch  will override this message renaming, but name conflicts may
+                 occur, so use this switch cautiously.
+
+                 If `-link' is not specified (or `-nolink' is specified), the  filed
+                 messages  will  be removed from the source folder, by renaming them
+                 with a site-dependent prefix (usually a comma).
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REFILE(1)                         -97-                         REFILE(1)
+
+
+                 If the user has a profile component such as
+
+                         rmmproc:        /bin/rm
+
+                 then _r_e_f_i_l_e will instead call the named program to delete the  mes-
+                 sage files.  The user may specify `-rmmproc program' on the command
+                 line to override  this  profile  specification.   The  `-normmproc'
+                 option  forces  the message files to be deleted by renaming them as
+                 described above.
+
+                 The `-draft' switch tells _r_e_f_i_l_e to file the <mh-dir>/draft.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Folder-Protect:      To set mode when creating a new folder
+                 rmmproc:             Program to delete the message
+
+
+            _S_e_e _A_l_s_o
+                 folder(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-src +folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-nolink'
+                 `-nopreserve'
+
+
+            _C_o_n_t_e_x_t
+                 If `-src +folder' is given, it will become the current folder.   If
+                 neither  `-link' nor `all' is specified, the current message in the
+                 source folder will be set to the last message specified; otherwise,
+                 the current message won't be changed.
+
+                 If the Previous-Sequence profile entry is set, in addition  to  de-
+                 fining the named sequences from the source folder, _r_e_f_i_l_e will also
+                 define  those  sequences  for   the   destination   folders.    See
+                 _m_h-_s_e_q_u_e_n_c_e (5) for information concerning the previous sequence.
+
+
+            _B_u_g_s
+                 Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+                 must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+                 create an infinte loop.
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -98-                           REPL(1)
+
+
+            _N_A_M_E
+                 repl - reply to a message
+
+            _S_Y_N_O_P_S_I_S
+                 repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+                      [-nocc all/to/cc/me] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-editor editor]
+                      [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+                      [-inplace] [-noinplace] [-query] [-noquery] [-width columns]
+                      [-whatnowproc program] [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_e_p_l aids a user in producing a reply to an existing message.  _R_e_p_l
+                 uses  a  reply  template to guide its actions when constructing the
+                 message draft of the reply.  In its simplest form  (with  no  argu-
+                 ments),  it  will  set  up  a message-form skeleton in reply to the
+                 current message in the  current  folder,  and  invoke  the  whatnow
+                 shell.   The  default  reply template will direct _r_e_p_l to construct
+                 the composed message as follows:
+
+                      To: <Reply-To> or <From>
+                      cc: <cc>, <To>, and yourself
+                      Subject: Re: <Subject>
+                      In-reply-to: Your message of <Date>.
+                                   <Message-Id>
+
+                 where field names enclosed in angle  brackets  (< >)  indicate  the
+                 contents  of the named field from the message to which the reply is
+                 being made.  A  reply  template  is  simply  a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 The `-cc type' switch takes an argument which  specifies  who  gets
+                 placed  on  the "cc:" list of the reply.  The `-query' switch modi-
+                 fies the action of `-cc type' switch by interactively asking you if
+                 each  address  that normally would be placed in the "To:" and "cc:"
+                 list  should  actually  be  sent  a  copy.   (This  is  useful  for
+                 special-purpose  replies.)  Note that the position of the `-cc' and
+                 `-nocc' switches, like all other switches which take a positive and
+                 negative form, is important.
+
+                 Lines beginning with the fields "To:", "cc:", and  "Bcc:"  will  be
+                 standardized  and  have  duplicate addresses removed.  In addition,
+                 the `-width columns' switch will guide _r_e_p_l's formatting  of  these
+                 fields.
+
+                 If the file named "replcomps" exists in the user's MH directory, it
+                 will be used instead of the default form.  In either case, the file
+                 specified by `-form formfile' will be used if given.
+
+                 If the draft already exists, _r_e_p_l will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _r_e_p_l, leaving the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -99-                           REPL(1)
+
+
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.  Note that while in the editor, the message being replied
+                 to is available through a link  named  "@"  (assuming  the  default
+                 _w_h_a_t_n_o_w_p_r_o_c ).   In addition, the actual pathname of the message is
+                 stored in the envariable $editalt, and the pathname of  the  folder
+                 containing the message is stored in the envariable $mhfolder.
+
+                 Although _r_e_p_l uses the `-form formfile' switch to direct it how  to
+                 construct  the  beginning  of  the  draft, the `-filter filterfile'
+                 switch directs _r_e_p_l as to how the message being  replied-to  should
+                 be  formatted in the body of the draft.  If `-filter' is not speci-
+                 fied, then the message being replied-to is not included in the body
+                 of  the draft.  If `-filter filterfile' is specified, then the mes-
+                 sage being replied-to is filtered  (re-formatted)  prior  to  being
+                 output  to  the body of the draft.  The filter file for _r_e_p_l should
+                 be a standard form file for _m_h_l, as _r_e_p_l will invoke _m_h_l to  format
+                 the  message  being replied-to.  There is no default message filter
+                 (`-filter' must be followed by a file name).  A filter file that is
+                 commonly used is:
+
+                      :
+                      body:nocomponent,compwidth=9,offset=9
+
+                 which says to output a blank line and then the body of the  message
+                 being replied-to, indented by one tab-stop.  Another format popular
+                 on USENET is:
+
+
+                      message-id:nocomponent,nonewline,\
+                      formatfield="In message %{text}, "
+                      from:nocomponent,formatfield="%(friendly{text}) writes:"
+                      body:component=">",overflowtext=">",overflowoffset=0
+
+                 Which  cites  the  Message-ID  and  author  of  the  message  being
+                 replied-to,  and  then  outputs each line of the body prefaced with
+                 the ">" character.
+
+                 If the `-annotate' switch is given, the  message  being  replied-to
+                 will be annotated with the lines
+
+                      Replied: date
+                      Replied: addrs
+
+                 where the address list contains one line for each  addressee.   The
+                 annotation  will  be done only if the message is sent directly from
+                 _r_e_p_l.   If  the  message  is  not  sent  immediately   from   _r_e_p_l,
+                 "comp -use"  may  be  used to re-edit and send the constructed mes-
+                 sage, but the annotations won't take place.  The `-inplace'  switch
+                 causes annotation to be done in place in order to preserve links to
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                          -100-                           REPL(1)
+
+
+                 the annotated message.
+
+                 The `-fcc +folder' switch can be used to  automatically  specify  a
+                 folder  to  receive Fcc:s.  More than one folder, each preceeded by
+                 `-fcc' can be named.
+
+                 In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _r_e_p_l also recog-
+                 nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+                 _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 _f_c_c     string   Any folders specified with `-fcc folder'
+
+                 To avoid reiteration, _r_e_p_l strips any leading `Re: '  strings  from
+                 the _s_u_b_j_e_c_t component.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _r_e_p_l will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/replcomps         The reply template
+                 or <mh-dir>/replcomps                Rather than the standard template
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/draft                       The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 mhlproc:             Program to filter message being replied-to
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                          -101-                           REPL(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to cur
+                 `-nocc all' at ATHENA sites, `-cc all' otherwise
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noinplace'
+                 `-noquery'
+                 `-width 72'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  mes-
+                 sage replied-to will become the current message.
+
+
+            _H_i_s_t_o_r_y
+                 Prior to using the format string  mechanism,  `-noformat'  used  to
+                 cause  address  headers to be output as-is.  Now all address fields
+                 are formatted using Internet standard guidelines.
+
+
+            _B_u_g_s
+                 If any addresses occur in the reply template, addresses in the tem-
+                 plate that do not contain hosts are defaulted incorrectly.  Instead
+                 of using the localhost for the  default,  _r_e_p_l  uses  the  sender's
+                 host.   Moral of the story: if you're going to include addresses in
+                 a reply template, include the host portion of the address.
+
+                 The `-width columns' switch is only  used  to  do  address-folding;
+                 other headers are not line-wrapped.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _r_e_p_l uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _r_e_p_l  won't  run
+                 it.
+
+                 If your current working directory is not writable, the  link  named
+                 "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMF(1)                           -102-                            RMF(1)
+
+
+            _N_A_M_E
+                 rmf - remove an MH folder
+
+            _S_Y_N_O_P_S_I_S
+                 rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_m_f removes all of the messages (files) within  the  specified  (or
+                 default)  folder,  and  then removes the folder (directory) itself.
+                 If there are any files within the folder which are not  a  part  of
+                 _M_H,  they  will  _n_o_t be removed, and an error will be produced.  If
+                 the folder is given explicitly or the  `-nointeractive'  option  is
+                 given,  then the folder will be removed without confirmation.  Oth-
+                 erwise, the user will be asked for confirmation.  If _r_m_f can't find
+                 the  current  folder,  for  some  reason,  the folder to be removed
+                 defaults to `+inbox' (unless overridden  by  user's  profile  entry
+                 "Inbox") with confirmation.
+
+                 _R_m_f irreversibly deletes messages that don't have other  links,  so
+                 use it with caution.
+
+                 If the folder being removed is a subfolder, the parent folder  will
+                 become  the new current folder, and _r_m_f will produce a message tel-
+                 ling the user this has happened.  This provides an  easy  mechanism
+                 for selecting a set of messages, operating on the list, then remov-
+                 ing the list and returning to the current  folder  from  which  the
+                 list was extracted.
+
+                 _R_m_f of a read-only folder will delete the private sequence and  cur
+                 information  (i.e.,  "atr-_s_e_q-_f_o_l_d_e_r"  entries)  from  the  profile
+                 without affecting the folder itself.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Inbox:               To find the default inbox
+
+
+            _S_e_e _A_l_s_o
+                 rmm(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder, usually with confirmation
+                 `-interactive' if +folder' not given, `-nointeractive' otherwise
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMF(1)                           -103-                            RMF(1)
+
+
+            _C_o_n_t_e_x_t
+                 _R_m_f will set the current folder to the parent folder if a subfolder
+                 is  removed; or if the current folder is removed, it will make "in-
+                 box" current.  Otherwise, it doesn't change the current  folder  or
+                 message.
+
+
+            _B_u_g_s
+                 Although intuitively one would suspect that _r_m_f works  recursively,
+                 it  does  not.   Hence if you have a sub-folder within a folder, in
+                 order to _r_m_f the parent, you must first _r_m_f each of the children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMM(1)                           -104-                            RMM(1)
+
+
+            _N_A_M_E
+                 rmm - remove messages
+
+            _S_Y_N_O_P_S_I_S
+                 rmm [+folder] [msgs] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_m_m removes the specified messages by renaming  the  message  files
+                 with preceding commas.  Many sites consider files that start with a
+                 comma to be a temporary backup, and arrange for _c_r_o_n (8) to  remove
+                 such files once a day.
+
+                 If the user has a profile component such as
+
+                         rmmproc:        /bin/rm
+
+                 then instead of simply renaming the message file, _r_m_m will call the
+                 named program to delete the file.  Note that at most installations,
+                 _c_r_o_n (8) is told to remove files that begin with  a  comma  once  a
+                 night.
+
+                 Some users of csh prefer the following:
+
+                         alias rmm 'refile +d'
+
+                 where folder +d is a folder for deleted messages, and
+
+                         alias mexp 'rm `mhpath +d all`'
+
+                 is used to "expunge" deleted messages.
+
+                 The current message is not changed by _r_m_m, so a _n_e_x_t  will  advance
+                 to the next message in the folder as expected.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 rmmproc:             Program to delete the message
+
+
+            _S_e_e _A_l_s_o
+                 rmf(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMM(1)                           -105-                            RMM(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _B_u_g_s
+                 Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+                 must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+                 create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                          -106-                           SCAN(1)
+
+
+            _N_A_M_E
+                 scan - produce a one line per message scan listing
+
+            _S_Y_N_O_P_S_I_S
+                 scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+                      [-format string] [-header] [-noheader] [-width columns]
+                      [-reverse] [-noreverse] [-file filename] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_c_a_n produces a one-line-per-message listing of the specified  mes-
+                 sages.   Each  _s_c_a_n  line  contains  the message number (name), the
+                 date, the "From:" field, the "Subject" field, and, if room  allows,
+                 some of the body of the message.  For example:
+
+                      15+  7/ 5  Dcrocker  nned  <<Last week I asked some of
+                      16 - 7/ 5  dcrocker  message id format  <<I recommend
+                      18   7/ 6  Obrien    Re: Exit status from mkdir
+                      19   7/ 7  Obrien    "scan" listing format in MH
+
+                 The `+' on message 15 indicates that it  is  the  current  message.
+                 The  `-'  on  message  16 indicates that it has been replied to, as
+                 indicated by a "Replied:"  component  produced  by  an  `-annotate'
+                 switch to the _r_e_p_l command.
+
+                 If there is sufficient room left on the _s_c_a_n line  after  the  sub-
+                 ject,  the line will be filled with text from the body, preceded by
+                 <<, and terminated by >> if the body is sufficiently  short.   _S_c_a_n
+                 actually  reads  each  of the specified messages and parses them to
+                 extract the desired fields.  During parsing, appropriate error mes-
+                 sages  will  be  produced  if there are format errors in any of the
+                 messages.
+
+                 The `-header' switch produces a header line prior to the _s_c_a_n list-
+                 ing.   Currently,  the  name of the folder and the current date and
+                 time are output (see the HISTORY section for more information).
+
+                 If the `-clear' switch is used and _s_c_a_n'_s output is directed  to  a
+                 terminal, then _s_c_a_n will consult the $TERM and $TERMCAP envariables
+                 to determine your terminal type in order to find out how  to  clear
+                 the  screen  prior  to exiting.  If the `-clear' switch is used and
+                 _s_c_a_n'_s output is not directed to a terminal  (e.g.,  a  pipe  or  a
+                 file), then _s_c_a_n will send a formfeed prior to exiting.
+
+                 For example, the command:
+
+                      (scan -clear -header; show all -show pr -f) | lpr
+
+                 produces a scan listing  of  the  current  folder,  followed  by  a
+                 formfeed,  followed  by  a formatted listing of all messages in the
+                 folder, one per page.  Omitting `-show pr -f' will cause  the  mes-
+                 sages  to  be  concatenated, separated by a one-line header and two
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                          -107-                           SCAN(1)
+
+
+                 blank lines.
+
+                 If _s_c_a_n encounters a message without a "Date:" field,  rather  than
+                 leaving  that  portion  of  the  scan  listing  blank,  the date is
+                 filled-in with the last write date of the message,  and  post-fixed
+                 with  a  `*'.   This  is  particularly  handy  for scanning a _d_r_a_f_t
+                 _f_o_l_d_e_r, as message drafts usually aren't allowed to have  dates  in
+                 them.
+
+                 To override the output format used by _s_c_a_n, the `-format string' or
+                 `-format file'  switches  are used.  This permits individual fields
+                 of the scan listing to be extracted with ease.  The string is  sim-
+                 ply  a  format  string  and  the file is simply a format file.  See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _s_c_a_n also recog-
+                 nizes the following additional _c_o_m_p_o_n_e_n_t escapes:
+
+                 _E_s_c_a_p_e    _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 body      string   the (compressed) first part of the body
+                 dtimenow  date     the current date
+                 folder    string   the name of the current folder
+
+                 Also, if no date header was present in the  message,  the  _f_u_n_c_t_i_o_n
+                 escapes  which operate on {_d_a_t_e} will return values for the date of
+                 last modification of the message file itself.
+
+                 _s_c_a_n will update the _M_H context prior to starting the  listing,  so
+                 interrupting  a  long  _s_c_a_n  listing preserves the new context.  _M_H
+                 purists hate this idea.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), pick(1), show(1), mh-format(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the folder current
+                 `msgs' defaults to all
+                 `-format' defaulted as described above
+                 `-noheader'
+                 `-width' defaulted to the width of the terminal
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                          -108-                           SCAN(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _H_i_s_t_o_r_y
+                 Prior to using the format string mechanism, `-header' used to  gen-
+                 erate a heading saying what each column in the listing was.  Format
+                 strings prevent this from happening.
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _s_c_a_n.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+                 The value of each _c_o_m_p_o_n_e_n_t escape is set by _s_c_a_n to  the  contents
+                 of  the first message header _s_c_a_n encounters with the corresponding
+                 component name; any following headers with the same component  name
+                 are ignored.
+
+                 The switch `-reverse', makes _s_c_a_n list the messages in reverse ord-
+                 er; this should be considered a bug.
+
+                 The `-file filename' switch allows the user to obtain a _s_c_a_n  list-
+                 ing of a maildrop file as produced by _p_a_c_k_f.  This listing includes
+                 every message in the file.  The user should use _m_s_h for more selec-
+                 tive  processing  of the file.  `-reverse' is ignored with this op-
+                 tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                          -109-                           SEND(1)
+
+
+            _N_A_M_E
+                 send - send a message
+
+            _S_Y_N_O_P_S_I_S
+                 send [-alias aliasfile] [-draft] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+                      [-mime] [-nomime] [-msgid] [-nomsgid] [-push] [-nopush]
+                      [-split seconds] [-verbose] [-noverbose] [-watch] [-nowatch]
+                      [-width columns] [file ...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_e_n_d will cause each of the specified files to  be  delivered  (via
+                 _p_o_s_t (8))  to each of the destinations in the "To:", "cc:", "Bcc:",
+                 and "Fcc:" fields of the message.  If  _s_e_n_d  is  re-distributing  a
+                 message,  as invoked from _d_i_s_t, then the corresponding "Resent-xxx"
+                 fields are examined instead.
+
+                 If `-push' is specified, _s_e_n_d will detach itself  from  the  user's
+                 terminal and perform its actions in the background.  If _p_u_s_h 'd and
+                 the draft can't be sent, then the `-forward' switch says that draft
+                 should be forwarded with the failure notice sent to the user.  This
+                 differs from putting _s_e_n_d in the background because the  output  is
+                 trapped and analyzed by _M_H.
+
+                 If `-verbose' is specified, _s_e_n_d  will  indicate  the  interactions
+                 occurring  with the transport system, prior to actual delivery.  If
+                 `-watch' is specified _s_e_n_d will monitor the delivery of  local  and
+                 network  mail.   Hence, by specifying both switches, a large detail
+                 of information can be gathered about each  step  of  the  message's
+                 entry into the transport system.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 If `-split' is specified, _s_e_n_d will split the  draft  into  one  or
+                 more  partial  messages  prior  to  sending.  This makes use of the
+                 multi-media content feature in MH.  Note however that  if  _s_e_n_d  is
+                 invoked  under _d_i_s_t (1), then this switch is ignored -- it makes no
+                 sense to redistribute a message in  this  fashion.   Sometimes  you
+                 want  _s_e_n_d  to pause after posting a partial message.  This is usu-
+                 ally the case when you are running _s_e_n_d_m_a_i_l and expect to  generate
+                 a  lot  of partial messages.  The argument to `-split' tells it how
+                 long to pause between postings.
+
+                 _S_e_n_d with no _f_i_l_e argument will query  whether  the  draft  is  the
+                 intended  file, whereas `-draft' will suppress this question.  Once
+                 the transport system has successfully accepted custody of the  mes-
+                 sage,  the  file will be renamed with a leading comma, which allows
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                          -110-                           SEND(1)
+
+
+                 it to be retrieved until the next draft message is sent.  If  there
+                 are errors in the formatting of the message, _s_e_n_d will abort with a
+                 (hopefully) helpful error message.
+
+                 If a "Bcc:" field is encountered, its addresses will  be  used  for
+                 delivery,  and  the  "Bcc:"  field will be removed from the message
+                 sent to sighted recipients.  The blind recipients will  receive  an
+                 entirely  new  message  with a minimal set of headers.  Included in
+                 the body of the message will be a copy of the message sent  to  the
+                 sighted  recipients.   If  `-filter filterfile'  is specified, then
+                 this copy is filtered (re-formatted) prior to  being  sent  to  the
+                 blind  recipients.  Otherwise, to use the MIME rules for encapsula-
+                 tion, specify the `-mime' switch.
+
+                 Prior to sending the message, the  fields  "From: user@local",  and
+                 "Date: now" will be appended to the headers in the message.  If the
+                 envariable $SIGNATURE is set, then its value is used as  your  per-
+                 sonal  name  when constructing the "From:" line of the message.  If
+                 this envariable is not set, then  _s_e_n_d  will  consult  the  profile
+                 entry "Signature" for this information.  On hosts where _M_H was con-
+                 figured with the UCI option, if $SIGNATURE is not set and the "Sig-
+                 nature"   profile   entry   is   not   present,   then   the   file
+                 $HOME/.signature is consulted.  If `-msgid' is  specified,  then  a
+                 "Message-ID:" field will also be added to the message.
+
+                 If _s_e_n_d is re-distributing a message (when invoked by _d_i_s_t ),  then
+                 "Resent-"  will  be  prepended  to  each  of these fields: "From:",
+                 "Date:", and "Message-ID:".  If  the  message  already  contains  a
+                 "From:"  field,  then a "Sender: user@local" field will be added as
+                 well.  (An already existing "Sender:" field is an error!)
+
+                 By using the `-format' switch, each of the entries in the "To:" and
+                 "cc:" fields will be replaced with "standard" format entries.  This
+                 standard format is designed to be usable  by  all  of  the  message
+                 handlers  on  the various systems around the Internet.  If `-nofor-
+                 mat' is given, then headers are output exactly as  they  appear  in
+                 the message draft.
+
+                 If an "Fcc: folder" is encountered, the message will be  copied  to
+                 the  specified folder for the sender in the format in which it will
+                 appear to any non-Bcc receivers of the message.  That is,  it  will
+                 have the appended fields and field reformatting.  The "Fcc:" fields
+                 will be removed from all outgoing copies of the message.
+
+                 By using the `-width columns' switch, the user can direct  _s_e_n_d  as
+                 to how long it should make header lines containing addresses.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read (more than one file,  each   preceeded  by  `-alias',  can  be
+                 named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                          -111-                           SEND(1)
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Aliasfile:           For a default alias file
+                 Signature:           To determine the user's mail signature
+                 mailproc:            Program to post failure notices
+                 postproc:            Program to post the message
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to <mh-dir>/draft
+                 `-alias /usr/bs/mh-6.8/lib/MailAliases'
+                 `-nodraftfolder'
+                 `-nofilter'
+                 `-format'
+                 `-forward'
+                 `-nomime'
+                 `-nomsgid'
+                 `-nopush'
+                 `-noverbose'
+                 `-nowatch'
+                 `-width 72'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 Under some configurations, it is not possible to mointor  the  mail
+                 delivery transaction; `-watch' is a no-op on those systems.
+
+                 Using `-split 0' doesn't work correctly.
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                          -112-                           SHOW(1)
+
+
+            _N_A_M_E
+                 show - show (list) messages
+
+            _S_Y_N_O_P_S_I_S
+                 show [+folder] [msgs] [-draft] [-header] [-noheader]
+                      [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_h_o_w lists each of the specified messages to  the  standard  output
+                 (typically,  the  terminal).   Typically,  the  messages are listed
+                 exactly as they are, with no reformatting.  A program named by  the
+                 _s_h_o_w_p_r_o_c  profile  component  is invoked to do the listing, and any
+                 switches not recognized by _s_h_o_w are passed along to  that  program.
+                 The  default program is known as _m_o_r_e (1).  To override the default
+                 and the _s_h_o_w_p_r_o_c profile  component,  use  the  `-showproc program'
+                 switch.   For  example, `-show pr' will cause the _p_r (1) program to
+                 list the messages.  The _M_H command _m_h_l can be used as a _s_h_o_w_p_r_o_c to
+                 show  messages in a more uniform format.  Normally, this program is
+                 specified as the _s_h_o_w_p_r_o_c is the user's .mh_profile.   See  _m_h_l (1)
+                 for  the  details.   If  the  `-noshowproc'  option  is  specified,
+                 `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+                 If you have messages with multi-media content,  you  should  define
+                 the  profile entry _m_h_n_p_r_o_c, which is the name of a program to mani-
+                 pulate multi-media messages.  The _m_h_n (1) program is  suitable  for
+                 this  purpose.   Note that if the _m_h_n_p_r_o_c profile entry is defined,
+                 the `-noshowproc' option is NOT specified, and if one or more named
+                 messages  has  a multi-media content, then the program indicated by
+                 _m_h_n_p_r_o_c will be run instead of _s_h_o_w_p_r_o_c.  The use  of  the  _m_h_n_p_r_o_c
+                 can also be disabled if the environment variable $NOMHNPROC is set.
+
+                 The `-header' switch tells _s_h_o_w to display a  one-line  description
+                 of  the  message being shown.  This description includes the folder
+                 and the message number.
+
+                 If no `msgs' are specified, the current message is used.   If  more
+                 than  one  message  is  specified,  _m_o_r_e will prompt for a <RETURN>
+                 prior to listing each message.  _m_o_r_e will list each message, a page
+                 at  a  time.   When  the end of page is reached, _m_o_r_e will ring the
+                 bell and wait for a <SPACE> or <RETURN>.  If a <RETURN> is entered,
+                 _m_o_r_e  will print the next line, whereas <SPACE> will print the next
+                 screenful.  To exit _m_o_r_e, type "q".
+
+                 If the standard output is not a terminal, no queries are made,  and
+                 each file is listed with a one-line header and two lines of separa-
+                 tion.
+
+                 "show -draft" will list the file <mh-dir>/draft if it exists.
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                          -113-                           SHOW(1)
+
+
+                 then _s_h_o_w will remove each of the messages shown from each sequence
+                 named  by  the   profile   entry.    This   is   similar   to   the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+                 showproc:            Program to show messages
+                 mhnproc:             Program to show messages with multi-media con-
+                 tent
+
+
+            _S_e_e _A_l_s_o
+                 mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  last
+                 message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                          -114-                           SHOW(1)
+
+
+            _B_u_g_s
+                 The `-header' switch doesn't work when `msgs' expands to more  than
+                 one  message.   If the _s_h_o_w_p_r_o_c is _m_h_l, then is problem can be cir-
+                 cumvented by referencing the "messagename" field in the _m_h_l  format
+                 file.
+
+                 _S_h_o_w updates the user's context before showing the message.   Hence
+                 _s_h_o_w  will  mark messages as seen prior to the user actually seeing
+                 them.  This is generally not a problem, unless the user  relies  on
+                 the  "unseen"  messages  mechanism, and interrupts _s_h_o_w while it is
+                 showing "unseen" messages.
+
+                 If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w uses a built-in _m_h_l: it does not  ac-
+                 tually  run  the  _m_h_l  program.   Hence,  if  you  define  your own
+                 _s_h_o_w_p_r_o_c, don't call it _m_h_l since _s_h_o_w won't run it.
+
+                 If _m_o_r_e (1) is your showproc (the default), then avoid running _s_h_o_w
+                 in  the  background  with only its standard output piped to another
+                 process, as in
+
+                      show | imprint &
+
+                 Due to a bug in _m_o_r_e, show will go into a "tty  input"  state.   To
+                 avoid  this  problem,  re-direct  _s_h_o_w's diagnostic output as well.
+                 For users of _c_s_h:
+
+                      show |& imprint &
+
+                 For users of _s_h:
+
+                      show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -115-                         SLOCAL(1)
+
+
+            _N_A_M_E
+                 slocal - special local mail delivery
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/slocal [address info sender]
+                      [-addr address] [-info data] [-sender sender]
+                      [-user username] [-mailbox mbox] [-file file]
+                      [-maildelivery deliveryfile] [-verbose] [-noverbose] [-debug]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_l_o_c_a_l is a program designed to allow you to have your inbound mail
+                 processed according to a complex set of selection criteria.  You do
+                 not normally invoke _s_l_o_c_a_l yourself, rather _s_l_o_c_a_l  is  invoked  on
+                 your behalf by your system's Message Transfer Agent.
+
+                 The message selection criteria used by _s_l_o_c_a_l is specified  in  the
+                 file  ._m_a_i_l_d_e_l_i_v_e_r_y  in  the  user's home directory.  The format of
+                 this file is given below.
+
+                 The message delivery address and message sender are determined from
+                 the  Message  Transfer  Agent  envelope  information,  if possible.
+                 Under _S_e_n_d_M_a_i_l, the sender will  obtained  from  the  UUCP  "From "
+                 line,  if present.  The user may override these values with command
+                 line arguments, or arguments to the `-addr' and `-sender' switches.
+
+                 The message is normally read from the standard input.  The  `-file'
+                 switch  sets  the name of the file from which the message should be
+                 read, instead of reading stdin.  The `-user'  switch  tells  _s_l_o_c_a_l
+                 the  name  of the user for whom it is delivering mail.  The `-mail-
+                 box' switch tells _s_l_o_c_a_l the name of the user's maildrop file.
+
+                 The `-info' switch may be used to pass  an  arbitrary  argument  to
+                 sub-processes  which  _s_l_o_c_a_l may invoke on your behalf.  The `-ver-
+                 bose' switch causes _s_l_o_c_a_l to give information on stdout about  its
+                 progress.  The `-debug' switch produces more verbose debugging out-
+                 put on stderr.
+
+
+              _M_e_s_s_a_g_e _T_r_a_n_s_f_e_r _A_g_e_n_t_s
+
+                 If your MTA is _S_e_n_d_M_a_i_l, you should include the line
+
+                          "| /usr/bs/mh-6.8/lib/slocal -user username"
+
+                 in your .forward file in your  home  directory.   This  will  cause
+                 _S_e_n_d_M_a_i_l to invoke _s_l_o_c_a_l on your behalf.
+
+                 If your MTA is _M_M_D_F-_I, you should (symbolically)  link  /usr/bs/mh-
+                 6.8/lib/slocal  to  the  file  bin/rcvmail  in your home directory.
+                 This will cause _M_M_D_F-_I to invoke _s_l_o_c_a_l on  your  behalf  with  the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -116-                         SLOCAL(1)
+
+
+                 correct "_a_d_d_r_e_s_s _i_n_f_o _s_e_n_d_e_r" arguments.
+
+                 If your MTA is  _M_M_D_F-_I_I,  then  you  should  not  use  _s_l_o_c_a_l.   An
+                 equivalent  functionality is already provided by _M_M_D_F-_I_I; see mail-
+                 delivery(5) for details.
+
+
+              _T_h_e _M_a_i_l_d_e_l_i_v_e_r_y _F_i_l_e
+
+
+                 The ._m_a_i_l_d_e_l_i_v_e_r_y file controls how local  delivery  is  performed.
+                 Each  line  of  this  file  consists  of  five fields, separated by
+                 white-space or comma.  Since double-quotes are honored, these char-
+                 acters may be included in a single argument by enclosing the entire
+                 argument in double-quotes.   A  double-quote  can  be  included  by
+                 preceding  it  with  a  backslash.   Lines  beginning  with `#' are
+                 ignored.  The format of each line in the ._m_a_i_l_d_e_l_i_v_e_r_y file is:
+
+
+                         header  pattern action  result  string
+
+                 header:
+                      The name of a header field that is to be searched for  a  pat-
+                      tern.   This  is  any field in the headers of the message that
+                      might be present.   The  following  special  fields  are  also
+                      defined:
+
+                      _s_o_u_r_c_e    the out-of-band sender information
+                      _a_d_d_r      the address that was used to cause delivery  to  the
+                                recipient
+                      _d_e_f_a_u_l_t   this  matches  _o_n_l_y  if  the  message  hasn't   been
+                                delivered yet
+                      *         this always matches
+
+                 pattern:
+                      The sequence of characters to match in  the  specified  header
+                      field.  Matching is case-insensitive, but does not use regular
+                      expressions.
+
+                 action:
+                      The action to take to deliver the message:
+
+                      _d_e_s_t_r_o_y   This action always succeeds.
+
+                      _f_i_l_e or > Append the message to the file named by string.  The
+                                message is appended to the file in the maildrop for-
+                                mat which is used by your message transport  system.
+                                If  the  message  can  be appended to the file, then
+                                this action succeeds.  When writing to the  file,  a
+                                "Delivery-Date: date"  header  is  added which indi-
+                                cates the date and time that message was appended to
+                                the file.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -117-                         SLOCAL(1)
+
+
+                      _m_b_o_x      Identical to _f_i_l_e, but always  appends  the  message
+                                using  the  format  used  by _p_a_c_k_f (the MMDF mailbox
+                                format).
+
+                      _p_i_p_e or | Pipe the message as the standard input to  the  com-
+                                mand  named  by string, using the Bourne shell _s_h(1)
+                                to interpret the string.  Prior to giving the string
+                                to  the  shell,  it  is  expanded with the following
+                                built-in variables:
+
+                                $(sender) the out-of-band sender information
+                                $(address)  the  address  that  was  used  to  cause
+                                          delivery to the recipient
+                                $(size)   the size of the message in bytes
+                                $(reply-to) either the "Reply-To:" or "From:"  field
+                                          of the message
+                                $(info)   the out-of-band information specified
+                      _q_p_i_p_e or
+                      <_c_a_r_e_t>   Similar to _p_i_p_e, but executes the command  directly,
+                                after  built-in  variable  expansion, without assis-
+                                tance from the shell.  This action can  be  used  to
+                                avoid  quoting  special  characters which your shell
+                                might interpret.
+
+                 result:
+                      Indicates how the action should be performed:
+
+                      _A         Perform the action.  If the  action  succeeds,  then
+                                the message is considered delivered.
+
+                      _R         Perform the action.  Regardless of  the  outcome  of
+                                the action, the message is not considered delivered.
+
+                      ?         Perform the action only if the message has not  been
+                                delivered.  If the action succeeds, then the message
+                                is considered delivered.
+
+                      _N         Perform the action only if the message has not  been
+                                delivered  and  the  previous  action succeeded.  If
+                                this action succeeds, then the message is considered
+                                delivered.
+
+                 To summarize, here's an example:
+
+                 #_f_i_e_l_d   _p_a_t_t_e_r_n   _a_c_t_i_o_n  _r_e_s_u_l_t    _s_t_r_i_n_g
+                 # lines starting with a '#' are ignored, as are blank lines
+                 #
+                 # file mail with mmdf2 in the "To:" line into file mmdf2.log
+                 _T_o       _m_m_d_f_2      _f_i_l_e     _A       _m_m_d_f_2._l_o_g
+                 # Messages from mmdf pipe to the program err-message-archive
+                 _F_r_o_m     _m_m_d_f       _p_i_p_e     _A       /_b_i_n/_e_r_r-_m_e_s_s_a_g_e-_a_r_c_h_i_v_e
+                 # Anything with the "Sender:" address "mh-workers"
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -118-                         SLOCAL(1)
+
+
+                 # file in mh.log if not filed already
+                 _S_e_n_d_e_r   _m_h-_w_o_r_k_e_r_s _f_i_l_e     ?       _m_h._l_o_g
+                 # "To:" unix - put in file unix-news
+                 _T_o       _U_n_i_x        >       _A       _u_n_i_x-_n_e_w_s
+                 # if the address is jpo=ack - send an acknowledgement copy back
+                 _a_d_d_r     _j_p_o=_a_c_k     |       _R       "/_b_i_n/_r_e_s_e_n_d -_r $(_r_e_p_l_y-_t_o)"
+                 # anything from steve - destroy!
+                 _F_r_o_m     _s_t_e_v_e    _d_e_s_t_r_o_y    _A       -
+                 # anything not matched yet - put into mailbox
+                 _d_e_f_a_u_l_t  -           >       ?       _m_a_i_l_b_o_x
+                 # always run rcvtty
+                 *        -           |       _R       /_m_h/_l_i_b/_r_c_v_t_t_y
+
+                 The file is always read completely, so that several matches can  be
+                 made and several actions can be taken.  The ._m_a_i_l_d_e_l_i_v_e_r_y file must
+                 be owned either by the user or by root, and must be  writable  only
+                 by  the  owner.  If the ._m_a_i_l_d_e_l_i_v_e_r_y file cannot be found, or does
+                 not perform an action which delivers the  message,  then  the  file
+                 /usr/bs/mh-6.8/lib/maildelivery  is  read  according  to  the  same
+                 rules.  This file must be owned by the root and  must  be  writable
+                 only by the root.  If this file cannot be found or does not perform
+                 an action which delivers the message, then standard delivery to the
+                 user's maildrop is performed.
+
+
+              _S_u_b-_p_r_o_c_e_s_s _e_n_v_i_r_o_n_m_e_n_t
+
+                 When a process is invoked, its environment is:  the  user/group-ids
+                 are   set   to  recipient's  ids;  the  working  directory  is  the
+                 recipient's home directory; the umask is 0077; the process  has  no
+                 /dev/tty;  the  standard  input is set to the message; the standard
+                 output and diagnostic output are set to /dev/null; all other  file-
+                 descriptors  are  closed;  the envariables $USER, $HOME, $SHELL are
+                 set appropriately, and no other envariables exist.
+
+                 The process is given a certain amount of time to execute.   If  the
+                 process  does  not exit within this limit, the process will be ter-
+                 minated with extreme prejudice.  The amount of time  is  calculated
+                 as  ((size  x 60) + 300) seconds, where size is the number of bytes
+                 in the message.
+
+                 The exit status of the process is consulted in determining the suc-
+                 cess  of  the action.  An exit status of zero means that the action
+                 succeeded.  Any other exit status (or abnormal  termination)  means
+                 that the action failed.
+
+                 In order to avoid any time limitations, you might implement a  pro-
+                 cess  that began by _f_o_r_k_i_n_g.  The parent would return the appropri-
+                 ate value immediately, and the child could continue on, doing what-
+                 ever it wanted for as long as it wanted.  This approach is somewhat
+                 risky if the parent is going to return an exit status of zero.   If
+                 the  parent  is  going  to return a non-zero exit status, then this
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -119-                         SLOCAL(1)
+
+
+                 approach can lead to quicker delivery into your maildrop.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/mtstailor         MH tailor file
+                 $HOME/.maildelivery                  The file controlling local delivery
+                 /usr/bs/mh-6.8/lib/maildelivery      Rather than the standard file
+                 /usr/spool/mail/$USER                The default maildrop
+
+
+            _S_e_e _A_l_s_o
+                 rcvstore(1), mhook(1), mh-format(5) , maildelivery(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-noverbose'
+                 `-maildelivery .maildelivery'
+                 `-mailbox /usr/spool/mail/$USER'
+                 `-file' defaults to stdin
+                 `-user' defaults to the current user
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 _S_l_o_c_a_l is designed to be backward-compatible with the  _m_a_i_l_d_e_l_i_v_e_r_y
+                 facility  provided by _M_M_D_F-_I_I.  Thus, the ._m_a_i_l_d_e_l_i_v_e_r_y file syntax
+                 is limited, as is the functionality of _s_l_o_c_a_l.
+
+                 In addition to an exit status of zero, the _M_M_D_F values _R_P__M_O_K  (32)
+                 and  _R_P__O_K (9) mean that the message has been fully delivered.  Any
+                 other non-zero exit status, including abnormal termination, is  in-
+                 terpreted  as the _M_M_D_F value _R_P__M_E_C_H (200), which means "use an al-
+                 ternate route" (deliver the message to the maildrop).
+
+
+            _B_u_g_s
+                 Only two return codes are meaningful, others should be.
+
+                 _S_l_o_c_a_l is designed to be backwards-compatible with the _m_a_i_l_d_e_l_i_v_e_r_y
+                 functionality provided by MMDF-II.
+
+                 Versions of _M_M_D_F with the _m_a_i_l_d_e_l_i_v_e_r_y  mechanism  aren't  entirely
+                 backwards-compatible with earlier versions of _M_M_D_F.  If you have an
+                 _M_M_D_F-_I old-style hook, the best you can do is to  have  a  one-line
+                 ._m_a_i_l_d_e_l_i_v_e_r_y file:
+
+                      default - pipe A "bin/rcvmail $(address) $(info) $(sender)"
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SORTM(1)                         -120-                          SORTM(1)
+
+
+            _N_A_M_E
+                 sortm - sort messages
+
+            _S_Y_N_O_P_S_I_S
+                 sortm [+folder] [msgs] [-datefield field] [-textfield field]
+                      [-notextfield] [-limit days] [-nolimit] [-verbose]
+                      [-noverbose] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_o_r_t_m sorts the specified messages in the named folder according to
+                 the chronological order of the "Date:" field of each message.
+
+                 The `-verbose' switch directs _s_o_r_t_m to tell the  user  the  general
+                 actions that it is taking to place the folder in sorted order.
+
+                 The `-datefield field' switch tells _s_o_r_t_m the name of the field  to
+                 use  when  making  the  date comparison.  If the user has a special
+                 field in each message, such as  "BB-Posted:"  or  "Delivery-Date:",
+                 then  the  `-datefield'  switch  can  be used to direct _s_o_r_t_m which
+                 field to examine.
+
+                 The `-textfield field' switch causes _s_o_r_t_m to sort messages by  the
+                 specified  text  field.   If  this  field is "subject", any leading
+                 "re:" is stripped off.  In any case, all characters except  letters
+                 and  numbers  are  stripped  and  the  resulting strings are sorted
+                 datefield-major, textfield-minor, using  a  case  insensitive  com-
+                 parison.
+
+                 With `-textfield field', if `-limit days'  is  specified,  messages
+                 with  similar textfields that are dated within `days' of each other
+                 appear together.  Specifying `-nolimit' makes the  limit  infinity.
+                 With   `-limit  0',  the  sort  is  instead  made  textfield-major,
+                 date-minor.
+
+                 For example, to order a folder by date-major, subject-minor, use:
+
+                      sortm -textfield subject +folder
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 folder (1)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SORTM(1)                         -121-                          SORTM(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-datefield date'
+                 `-notextfield'
+                 `-noverbose'
+                 `-nolimit'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current  folder.   If  the
+                 current  message  is  moved,  _s_o_r_t_m  will  preserve  its  status as
+                 current.
+
+
+            _H_i_s_t_o_r_y
+                 Timezones used to be ignored when comparing dates: they aren't  any
+                 more.
+
+                 Messages which were in the folder, but  not  specified  by  `msgs',
+                 used  to  be  moved to the end of the folder; now such messages are
+                 left untouched.
+
+                 Previously, _s_o_r_t_m would try to fill any gaps in a folder within the
+                 range  of  messages  it  sorted.  To improve performance, _s_o_r_t_m now
+                 minimizes the number of message  moves.   To  pack  a  folder,  use
+                 "_f_o_l_d_e_r -_p_a_c_k" instead.
+
+
+            _B_u_g_s
+                 If _s_o_r_t_m encounters a message without a date-field, or if the  mes-
+                 sage  has a date-field that _s_o_r_t_m cannot parse, then _s_o_r_t_m attempts
+                 to keep the message in the same relative position.  This  does  not
+                 always  work.  For instance, if the first message encountered lacks
+                 a date which can be parsed, then it will usually be placed  at  the
+                 end of the messages being sorted.
+
+                 When _s_o_r_t_m complains about a message which it can't temporally ord-
+                 er,  it  complains  about  the message number _p_r_i_o_r to sorting.  It
+                 should indicate what the message number will be _a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            VMH(1)                           -122-                            VMH(1)
+
+
+            _N_A_M_E
+                 vmh - visual front-end to MH
+
+            _S_Y_N_O_P_S_I_S
+                 vmh [-prompt string] [-vmhproc program] [-novmhproc]
+                      [switches for _v_m_h_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _v_m_h is a program which implements the server side of the _M_H  window
+                 management  protocol  and  uses  _c_u_r_s_e_s (3)  routines to maintain a
+                 split-screen interface to any program which implements  the  client
+                 side  of the protocol.  This latter program, called the _v_m_h_p_r_o_c, is
+                 specified using the `-vmhproc program' switch.
+
+                 The upshot of all this is that one can run _m_s_h on a display  termi-
+                 nal and get a nice visual interface.  To do this, for example, just
+                 add the line
+
+                      mshproc: vmh
+
+                 to your .mh_profile.  (This takes advantage of the fact that _m_s_h is
+                 the default _v_m_h_p_r_o_c for _v_m_h.)
+
+                 In order to facilitate things, if the `-novmhproc' switch is given,
+                 and  _v_m_h  can't  run  on  the  user's  terminal, the _v_m_h_p_r_o_c is run
+                 directly without the window management protocol.
+
+                 After initializing the protocol, _v_m_h prompts the user for a command
+                 to  be  given to the client.  Usually, this results in output being
+                 sent to one or more windows.  If a output to a window  would  cause
+                 it  to  scroll, _v_m_h prompts the user for instructions, roughly per-
+                 mitting the capabilities of _l_e_s_s or  _m_o_r_e  (e.g.,  the  ability  to
+                 scroll backwards and forwards):
+
+                      SPACE      advance to the next windowful
+                      RETURN  *  advance to the next line
+                      y       *  retreat to the previous line
+                      d       *  advance to the next ten lines
+                      u       *  retreat to the previous ten lines
+                      g       *  go to an arbitrary line
+                                 (preceed g with the line number)
+                      G       *  go to the end of the window
+                                 (if a line number is given, this acts like `g')
+                      CTRL-L     refresh the entire screen
+                      h          print a help message
+                      q          abort the window
+
+                 (A `*' indicates that a numeric prefix is meaningful for this  com-
+                 mand.)
+
+                 Note that if a command resulted in more than one window's worth  of
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            VMH(1)                           -123-                            VMH(1)
+
+
+                 information  being  displayed,  and  you allow the command which is
+                 generating information for the window to gracefully  finish  (i.e.,
+                 you  don't  use  the `q' command to abort information being sent to
+                 the window), then _v_m_h will give you one last change to  peruse  the
+                 window.   This  is  useful for scrolling back and forth.  Just type
+                 `q' when you're done.
+
+                 To abnormally terminate _v_m_h (without core dump), use  <QUIT>  (usu-
+                 ally  CTRL-\).   For instance, this does the "right" thing with _b_b_c
+                 and _m_s_h.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+
+
+            _S_e_e _A_l_s_o
+                 msh(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prompt (vmh) '
+                 `-vmhproc msh'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _v_m_h.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+                 At present, there is no way to pass signals (e.g., interrupt, quit)
+                 to the client.  However, generating QUIT when _v_m_h is reading a com-
+                 mand from the terminal is sufficient to tell the client to go  away
+                 quickly.
+
+                 Acts strangely (loses peer or botches  window  management  protocol
+                 with peer) on random occasions.
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -124-                        WHATNOW(1)
+
+
+            _N_A_M_E
+                 whatnow - prompting front-end for send
+
+            _S_Y_N_O_P_S_I_S
+                 whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _W_h_a_t_n_o_w is the default program that  queries  the  user  about  the
+                 disposition  of a composed draft.  It is normally invoked by one of
+                 _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l after the initial edit.
+
+                 When started, the editor is started on the draft (unless  `-noedit'
+                 is  given,  in  which  case the initial edit is suppressed).  Then,
+                 _w_h_a_t_n_o_w repetitively prompts the user with "What now?" and awaits a
+                 response.  The valid responses are:
+
+                 display         to list the message being distributed/replied-to on
+                                 the terminal
+                 edit            to re-edit using the same editor that was used on the
+                                 preceding round unless a profile entry
+                                 "<lasteditor>-next: <editor>" names an alternate editor
+                 edit <editor>   to invoke <editor> for further editing
+                 list            to list the draft on the terminal
+                 push            to send the message in the background
+                 quit            to terminate the session and preserve the draft
+                 quit -delete    to terminate, then delete the draft
+                 refile +folder  to refile the draft into the given folder
+                 send            to send the message
+                 send -watch     to cause the delivery process to be monitored
+                 whom            to list the addresses that the message will go to
+                 whom -check     to list the addresses and verify that they are
+                                 acceptable to the transport service
+
+                 For the edit response, any valid switch to  the  editor  is  valid.
+                 Similarly,  for  the  send  and whom responses, any valid switch to
+                 _s_e_n_d (1) and _w_h_o_m (1) commands, respectively, are valid.   For  the
+                 push  response,  any  valid  switch  to  _s_e_n_d (1) is valid (as this
+                 merely invokes _s_e_n_d with  the  `-push'  option).   For  the  _r_e_f_i_l_e
+                 response,  any  valid  switch  to  the  _f_i_l_e_p_r_o_c is valid.  For the
+                 display and list responses, any valid  argument  to  the  _l_p_r_o_c  is
+                 valid.   If any non-switch arguments are present, then the pathname
+                 of the draft will be excluded from the argument list given  to  the
+                 _l_p_r_o_c (this is useful for listing another _M_H message).
+
+                 See _m_h-_p_r_o_f_i_l_e (5) for further information about  how  editors  are
+                 used  by MH.  It also discusses how complex envariables can be used
+                 to direct _w_h_a_t_n_o_w's actions.
+
+                 The `-prompt string' switch sets the prompting string for _w_h_a_t_n_o_w.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -125-                        WHATNOW(1)
+
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/draft                       The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 <lasteditor>-next:   To name an editor to be used after  exit  from
+                 <lasteditor>
+                 automhnproc:         Program to automatically run prior to  sending
+                                      if the draft is an _m_h_n composition file
+                 fileproc:            Program to refile the message
+                 lproc:               Program to list the contents of a message
+                 sendproc:            Program to use to send the message
+                 whomproc:            Program to determine who a message would go to
+
+
+            _S_e_e _A_l_s_o
+                 send(1), whom(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prompt "What Now? "'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -126-                        WHATNOW(1)
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token  by the shell that invokes _w_h_a_t_n_o_w.  Therefore, one must
+                 usually place the argument to this switch inside double-quotes.
+
+                 If the initial edit fails, _w_h_a_t_n_o_w deletes your draft (by  renaming
+                 it  with  a  leading  comma); failure of a later edit preverves the
+                 draft.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p, _d_i_s_t, _f_o_r_w, and  _r_e_p_l  use  a
+                 built-in  _w_h_a_t_n_o_w,  and  do  not  actually run the _w_h_a_t_n_o_w program.
+                 Hence, if you define your own _w_h_a_t_n_o_w_p_r_o_c, don't  call  it  _w_h_a_t_n_o_w
+                 since it won't be run.
+
+                 If _s_e_n_d_p_r_o_c is _s_e_n_d, then _w_h_a_t_n_o_w uses a built-in _s_e_n_d, it does not
+                 actually  run  the  _s_e_n_d  program.   Hence,  if you define your own
+                 _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since _w_h_a_t_n_o_w won't run it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHOM(1)                          -127-                           WHOM(1)
+
+
+            _N_A_M_E
+                 whom - report to whom a message would go
+
+            _S_Y_N_O_P_S_I_S
+                 whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [file] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _W_h_o_m is used to expand the headers of  a  message  into  a  set  of
+                 addresses  and  optionally verify that those addresses are deliver-
+                 able at that time (if `-check' is given).
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read (more than one file,  each   preceeded  by  `-alias',  can  be
+                 named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Aliasfile:           For a default alias file
+                 postproc:            Program to post the message
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to <mh-dir>/draft
+                 `-nocheck'
+                 `-alias /usr/bs/mh-6.8/lib/MailAliases'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHOM(1)                          -128-                           WHOM(1)
+
+
+            _B_u_g_s
+                 With the `-check' option, _w_h_o_m makes no  guarantees  that  the  ad-
+                 dresses  listed  as being ok are really deliverable, rather, an ad-
+                 dress being listed as ok means that at the time that _w_h_o_m  was  run
+                 the address was thought to be deliverable by the transport service.
+                 For local addresses, this is absolute; for  network  addresses,  it
+                 means  that the host is known; for uucp addresses, it (often) means
+                 that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+                                                  -129-
+
+
+                 _M_O_R_E _D_E_T_A_I_L_S
+
+                      This section describes some of the more intense points  of  the  _M_H
+                 system,  by  expanding  on  topics  previously  discussed.   The  format
+                 presented conforms to the standard form  for  the  description  of  UNIX
+            documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -130-                       MH-ALIAS(5)
+
+
+            _N_A_M_E
+                 mh-alias - alias file for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 any _M_H command
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 This describes both _M_H personal alias files and the (primary) alias
+                 file for mail delivery, the file
+
+                         /usr/bs/mh-6.8/lib/MailAliases
+
+                 It does not describe aliases files used by  the  message  transport
+                 system.  Each line of the alias file has the format:
+
+                         alias : address-group
+                 or
+                         alias ; address-group
+                 or
+                         < alias-file
+                 or
+                         ; comment
+
+                 where:
+
+                         address-group  :=  address-list
+                                        |   "<" file
+                                        |   "=" UNIX-group
+                                        |   "+" UNIX-group
+                                        |   "*"
+
+                         address-list   :=  address
+                                        |   address-list, address
+
+                 Continuation lines in alias files end with `\' followed by the new-
+                 line character.
+
+                 Alias-file and file are UNIX file names.   UNIX-group  is  a  group
+                 name  (or  number)  from  /_e_t_c/_g_r_o_u_p.   An  address  is  a "simple"
+                 Internet-style address.  Througout  this  file,  case  is  ignored,
+                 except for alias-file names.
+
+                 If the line starts with a `<', then the file named after the `<' is
+                 read  for more alias definitions.  The reading is done recursively,
+                 so a `<' may occur in the beginning  of  an  alias  file  with  the
+                 expected results.
+
+                 If the address-group starts with a `<', then the file  named  after
+                 the  `<' is read and its contents are added to the address-list for
+                 the alias.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -131-                       MH-ALIAS(5)
+
+
+                 If the address-group starts with an `=', then the  file  /_e_t_c/_g_r_o_u_p
+                 is  consulted  for  the UNIX-group named after the `='.  Each login
+                 name  occurring  as  a  member  of  the  group  is  added  to   the
+                 address-list for the alias.
+
+                 In contrast, if the address-group starts with a `+', then the  file
+                 /_e_t_c/_g_r_o_u_p is consulted to determine the group-id of the UNIX-group
+                 named after the `+'.  Each login name occurring in the  /_e_t_c/_p_a_s_s_w_d
+                 file  whose  group-id  is  indicated  by this group is added to the
+                 address-list for the alias.
+
+                 If the address-group is simply `*', then the  file  /_e_t_c/_p_a_s_s_w_d  is
+                 consulted and all login names with a userid greater than some magic
+                 number (usually 200) are added to the address-list for the alias.
+
+                 In match, a trailing * on an alias will match just  about  anything
+                 appropriate.  (See example below.)
+
+                 An approximation of the way aliases are resolved at posting time is
+                 (it's not really done this way):
+
+                      1) Build a list of  all  addresses  from  the  message  to  be
+                      delivered, eliminating duplicate addresses.
+
+                      2) If this draft originated on the local host, then for  those
+                      addresses  in the message that have no host specified, perform
+                      alias resolution.
+
+                      3) For each line in the alias file,  compare  "alias"  against
+                      all of the existing addresses.  If a match, remove the matched
+                      "alias" from the address list, and add each new address in the
+                      address-group  to the address list if it is not already on the
+                      list.  The alias itself is  not  usually  output,  rather  the
+                      address-group  that  the  alias maps to is output instead.  If
+                      "alias" is terminated with a `;' instead of a `:',  then  both
+                      the  "alias" and the address are output in the correct format.
+                      (This makes replies possible since  _M_H  aliases  and  personal
+                      aliases are unknown to the mail transport system.)
+
+                 Since the alias file is read line by line, forward references work,
+                 but  backward  references  are  not  recognized,  thus, there is no
+                 recursion.
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -132-                       MH-ALIAS(5)
+
+
+                 Example:
+                      </usr/bs/mh-6.8/lib/BBoardAliases
+                      sgroup: fred, fear, freida
+                      b-people: Blind List: bill, betty;
+                      fred: frated@UCI
+                      UNIX-committee: <unix.aliases
+                      staff: =staff
+                      wheels: +wheel
+                      everyone: *
+                      news.*: news
+
+                 The first line says that more aliases should  immediately  be  read
+                 from  the  file  /_u_s_r/_b_s/_m_h-_6._8/_l_i_b/_B_B_o_a_r_d_A_l_i_a_s_e_s.  Following this,
+                 "fred" is defined as an alias for  "frated@UCI",  and  "sgroup"  is
+                 defined  as  an alias for the three names "frated@UCI", "fear", and
+                 "freida".
+
+                 The alias "b-people" is a blind list which includes  the  addresses
+                 "bill"   and  "betty";  the  message  will  be  delieved  to  those
+                 addresses, but the message header will  show only "Blind  List:  ;"
+                 (not the addresses).
+
+                 Next, the definition of "UNIX-committee" is given  by  reading  the
+                 file  _u_n_i_x._a_l_i_a_s_e_s in the users _M_H directory, "staff" is defined as
+                 all users who are listed as members of the  group  "staff"  in  the
+                 /_e_t_c/_g_r_o_u_p  file,  and  "wheels"  is  defined  as  all  users whose
+                 group-id in /_e_t_c/_p_a_s_s_w_d is equivalent to the "wheel" group.
+
+                 Finally, "everyone" is defined as  all  users  with  a  user-id  in
+                 /_e_t_c/_p_a_s_s_w_d   greater  than  200,  and  all  aliases  of  the  form
+                 "news.<anything>" are defined to be "news".
+
+                 The key thing to understand about aliasing in _M_H is that aliases in
+                 _M_H  alias  files  are expanded into the headers of messages posted.
+                 This aliasing occurs first, at posting time, without the  knowledge
+                 of  the  message  transport  system.  In contrast, once the message
+                 transport system is given  a  message  to  deliver  to  a  list  of
+                 addresses, for each address that appears to be local, a system-wide
+                 alias file is consulted.  These aliases are NOT expanded  into  the
+                 headers of messages delivered.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 To use aliasing in _M_H quickly, do the following:
+
+                      First, in your ._m_h__p_r_o_f_i_l_e, choose a name for your alias file,
+                      say "aliases", and add the line:
+
+                           Aliasfile: aliases
+
+                      Second, create the file "aliases" in your _M_H directory.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -133-                       MH-ALIAS(5)
+
+
+                      Third,  start  adding  aliases  to  your  "aliases"  file   as
+                      appropriate.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/MailAliases       Primary alias file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Aliasfile:           For a default alias file
+
+
+            _S_e_e _A_l_s_o
+                 ali(1), send(1), whom(1), group(5), passwd(5), conflict(8), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 In previous releases of _M_H, only  a  single,  system-wide  mh-alias
+                 file  was  supported.  Now that _M_H uses _M_M_D_F as a transport system,
+                 the system-wide aliasing facility can  be  more  consistently  con-
+                 trolled  by  the  latter.   This  means  that  at  most  sites, the
+                 system-wide mh-alias file will  be  empty  (or  trivial  at  best).
+                 Hence,  the semantics of mh-alias were extended to support personal
+                 alias files.  Users of _M_H no longer need to bother mail-system  ad-
+                 ministrators for keeping information in the system-wide alias file,
+                 as each _M_H user can create/modify/remove aliases at will  from  any
+                 number of personal files.
+
+
+            _B_u_g_s
+                 Although  the  forward-referencing  semantics  of  _m_h-_a_l_i_a_s   files
+                 prevent  recursion,  the  "< alias-file"  command  may defeat this.
+                 Since the number of file descriptors is finite (and very  limited),
+                 such  infinite recursion will terminate with a meaningless diagnos-
+                 tic when all the fds are used up.
+
+                 Forward references do not work correctly inside blind lists.
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -134-                      MH-FORMAT(5)
+
+
+            _N_A_M_E
+                 mh-format - format file for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 some _M_H commands
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Several _M_H commands utilize either a _f_o_r_m_a_t string or a _f_o_r_m_a_t file
+                 during their execution.  For example, _s_c_a_n (1) uses a format string
+                 which directs it how to generate the scan listing for each message;
+                 _r_e_p_l (1)  uses  a  format file which directs it how to generate the
+                 reply to a message, and so on.
+
+                 Format strings are designed to be efficiently parsed  by  _M_H  which
+                 means  they  are  not  necessarily  simple to write and understand.
+                 This means that novice, casual, or even advanced users of _M_H should
+                 not  have  to deal with them.  Some canned scan listing formats are
+                 in /usr/bs/mh-6.8/lib/scan.time, /usr/bs/mh-6.8/lib/scan.size,  and
+                 /usr/bs/mh-6.8/lib/scan.timely.   Look  in  /usr/bs/mh-6.8/lib  for
+                 other _s_c_a_n and _r_e_p_l format files which may  have  been  written  at
+                 your site.
+
+                 It suffices to have your local _M_H expert actually write new  format
+                 commands or modify existing ones.  This manual section explains how
+                 to do that.   Note:  familiarity  with  the  C  _p_r_i_n_t_f  routine  is
+                 assumed.
+
+                 A format string consists  of  ordinary  text,  and  special  multi-
+                 character _e_s_c_a_p_e sequences which begin with `%'.  When specifying a
+                 format string, the usual C backslash characters are honored:  `\b',
+                 `\f', `\n', `\r', and `\t'.  Continuation lines in format files end
+                 with `\' followed by the newline character.  There are three  types
+                 of  _e_s_c_a_p_e  sequences:  header  _c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and
+                 flow _c_o_n_t_r_o_l.
+
+                 A _c_o_m_p_o_n_e_n_t escape is specified as `%{_c_o_m_p_o_n_e_n_t}', and  exists  for
+                 each  header  found  in  the  message being processed.  For example
+                 `%{date}' refers to the "Date:" field of the  appropriate  message.
+                 All  component  escapes  have  a string value.  Normally, component
+                 values are compressed by converting any control characters (tab and
+                 newline  included)  to spaces, then eliding any leading or multiple
+                 spaces.  However, commands may give  different  interpretations  to
+                 some  component  escapes; be sure to refer to each command's manual
+                 entry for complete details.
+
+                 A _f_u_n_c_t_i_o_n escape is specified as `%(_f_u_n_c_t_i_o_n)'.  All functions are
+                 built-in, and most have a string or numeric value.
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -135-                      MH-FORMAT(5)
+
+
+              _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+                 A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|', or  `%>'.  These  are
+                 combined into the conditional execution construct:
+
+                         %<condition
+                                 _f_o_r_m_a_t _t_e_x_t _1
+                         %?condition2
+                                 _f_o_r_m_a_t _t_e_x_t _2
+                         %?condition3
+                                 _f_o_r_m_a_t _t_e_x_t _3
+                         ...
+                         %|
+                                 _f_o_r_m_a_t _t_e_x_t _N
+                         %>
+
+                 Extra white space is shown here only for clarity.  These constructs
+                 may   be   nested   without   ambiguity.    They   form  a  general
+                 if-elseif-else-endif block where only one of the _f_o_r_m_a_t  _t_e_x_t  seg-
+                 ments is interpreted.
+
+                 The `%<'  and  `%?'  control  escapes  causes  a  condition  to  be
+                 evaluated.  This condition may be either a _c_o_m_p_o_n_e_n_t or a _f_u_n_c_t_i_o_n.
+                 The four constructs have the following syntax:
+
+                         %<{component}
+                         %<(function)
+                         %?{component}
+                         %?(function)
+
+                 These control escapes test whether the function or component  value
+                 is   non-zero  (for  integer-valued  escapes),  or  non-empty  (for
+                 string-valued escapes).
+
+                 If this test evaulates true, then the format text up  to  the  next
+                 corresponding control escape (one of `%|', `%?', or `%>') is inter-
+                 preted normally.   Next,  all  format  text  (if  any)  up  to  the
+                 corresponding  `%>'  control  escape  is skipped.  The `%>' control
+                 escape is not interpreted; normal interpretation resumes after  the
+                 `%>' escape.
+
+                 If the test evaluates false, however, then the format  text  up  to
+                 the next corresponding control escape (again, one of `%|', `%?', or
+                 `%>') is skipped, instead of being  interpreted.   If  the  control
+                 escape  encountered  was  `%?',  then the condition associated with
+                 that control escape is evaluated, and interpretation proceeds after
+                 that  test  as described in the previous paragraph.  If the control
+                 escape encountered was  `%|',  then  the  format  text  up  to  the
+                 corresponding  `%>'  escape is interpreted normally.  As above, the
+                 `%>' escape is not interpreted and  normal  interpretation  resumes
+                 after the `%>' escape.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -136-                      MH-FORMAT(5)
+
+
+                 The `%?' control escape and its following format text is  optional,
+                 and  may  be  included zero or more times.  The `%|' control escape
+                 and its following format text is also optional, and may be included
+                 zero or one times.
+
+
+              _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+                 Most functions expect an argument of a particular type:
+
+                 _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n            _E_x_a_m_p_l_e _S_y_n_t_a_x
+                 literal  A literal number,      %(_f_u_n_c 1234)
+                          or string              %(_f_u_n_c text string)
+                 comp     Any header component   %(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+                 date     A date component       %(_f_u_n_c{_d_a_t_e})
+                 addr     An address component   %(_f_u_n_c{_f_r_o_m})
+                 expr     An optional component, %(_f_u_n_c(_f_u_n_c_2))
+                          function or control,   %(_f_u_n_c %<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+                          perhaps nested         %(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+                 The types _d_a_t_e and _a_d_d_r have the same syntax as _c_o_m_p,  but  require
+                 that  the  header  component  be  a date string, or address string,
+                 respectively.
+
+                 All arguments except those of type _e_x_p_r are required.  For the _e_x_p_r
+                 argument  type,  the  leading `%' must be omitted for component and
+                 function escape arguments, and must  be  present  (with  a  leading
+                 space) for control escape arguments.
+
+                 The evaluation of format strings is based on a simple machine  with
+                 an  integer  register  _n_u_m, and a text string register _s_t_r.  When a
+                 function escape is processed, if it accepts an optional _e_x_p_r  argu-
+                 ment which is not present, it reads the current value of either _n_u_m
+                 or _s_t_r as appropriate.
+
+
+              _R_e_t_u_r_n _v_a_l_u_e_s
+
+                 Component escapes write the value of their message header  in  _s_t_r.
+                 Function  escapes  write  their  return  value in _n_u_m for functions
+                 returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n  values,  and  in  _s_t_r  for  functions
+                 returning string values.  (The _b_o_o_l_e_a_n type is a subset of integers
+                 with usual values 0=false and 1=true.)  Control  escapes  return  a
+                 _b_o_o_l_e_a_n value, and set _n_u_m.
+
+                 All component escapes, and those function escapes which  return  an
+                 _i_n_t_e_g_e_r  or  _s_t_r_i_n_g  value, pass this value back to their caller in
+                 addition to setting _s_t_r or _n_u_m.  These escapes will print out  this
+                 value  unless  called  as  part  of  an  argument to another escape
+                 sequence.  Escapes which return a _b_o_o_l_e_a_n value do pass this  value
+                 back to their caller in _n_u_m, but will never print out the value.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -137-                      MH-FORMAT(5)
+
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 msg                 integer  message number
+                 cur                 integer  message is current
+                 size                integer  size of message
+                 strlen              integer  length of _s_t_r
+                 width               integer  output buffer size in bytes
+                 charleft            integer  bytes left in output buffer
+                 timenow             integer  seconds since the UNIX epoch
+                 me                  string   the user's mailbox
+                 eq         literal  boolean  _n_u_m == _a_r_g
+                 ne         literal  boolean  _n_u_m != _a_r_g
+                 gt         literal  boolean  _n_u_m > _a_r_g
+                 match      literal  boolean  _s_t_r contains _a_r_g
+                 amatch     literal  boolean  _s_t_r starts with _a_r_g
+                 plus       literal  integer  _a_r_g plus _n_u_m
+                 minus      literal  integer  _a_r_g minus _n_u_m
+                 divide     literal  integer  _n_u_m divided by _a_r_g
+                 modulo     literal  integer  _n_u_m modulo _a_r_g
+                 num        literal  integer  Set _n_u_m to _a_r_g
+                 lit        literal  string   Set _s_t_r to _a_r_g
+                 getenv     literal  string   Set _s_t_r to environment value of _a_r_g
+                 nonzero    expr     boolean  _n_u_m is non-zero
+                 zero       expr     boolean  _n_u_m is zero
+                 null       expr     boolean  _s_t_r is empty
+                 nonnull    expr     boolean  _s_t_r is non-empty
+                 void       expr              Set _s_t_r or _n_u_m
+                 comp       comp     string   Set _s_t_r to component text
+                 compval    comp     integer  _n_u_m set to "atoi(_c_o_m_p)"
+                 trim       expr              trim trailing white-space from _s_t_r
+                 putstr     expr              print _s_t_r
+                 putstrf    expr              print _s_t_r in a fixed width
+                 putnum     expr              print _n_u_m
+                 putnumf    expr              print _n_u_m in a fixed width
+
+                 These functions require a date component as an argument:
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 sec        date     integer  seconds of the minute
+                 min        date     integer  minutes of the hour
+                 hour       date     integer  hours of the day (0-23)
+                 wday       date     integer  day of the week (Sun=0)
+                 day        date     string   day of the week (abbrev.)
+                 weekday    date     string   day of the week
+                 sday       date     integer  day of the week known?
+                                              (0=implicit,-1=unknown)
+                 mday       date     integer  day of the month
+                 yday       date     integer  day of the year
+                 mon        date     integer  month of the year
+                 month      date     string   month of the year (abbrev.)
+                 lmonth     date     string   month of the year
+                 year       date     integer  year (may be > 100)
+                 zone       date     integer  timezone in hours
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -138-                      MH-FORMAT(5)
+
+
+                 tzone      date     string   timezone string
+                 szone      date     integer  timezone explicit?
+                                              (0=implicit,-1=unknown)
+                 date2local date              coerce date to local timezone
+                 date2gmt   date              coerce date to GMT
+                 dst        date     integer  daylight savings in effect?
+                 clock      date     integer  seconds since the UNIX epoch
+                 rclock     date     integer  seconds prior to current time
+                 tws        date     string   official 822 rendering
+                 pretty     date     string   user-friendly rendering
+                 nodate     date     integer  _s_t_r not a date string
+
+                 These functions require an address component as  an  argument.  The
+                 return  value of functions noted with `*' pertain only to the first
+                 address present in the header component.
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 proper     addr     string   official 822 rendering
+                 friendly   addr     string   user-friendly rendering
+                 addr       addr     string   mbox@host or host!mbox rendering*
+                 pers       addr     string   the personal name*
+                 note       addr     string   commentary text*
+                 mbox       addr     string   the local mailbox*
+                 mymbox     addr     integer  the user's addresses? (0=no,1=yes)
+                 host       addr     string   the host domain*
+                 nohost     addr     integer  no host was present*
+                 type       addr     integer  host type* (0=local,1=network,
+                                              -1=uucp,2=unknown)
+                 path       addr     string   any leading host route*
+                 ingrp      addr     integer  address was inside a group*
+                 gname      addr     string   name of group*
+                 formataddr expr              append _a_r_g to _s_t_r as a
+                                              (comma separated) address list
+                 putaddr    literal           print _s_t_r address list with
+                                              _a_r_g as optional label;
+                                              get line width from _n_u_m
+
+                 When escapes are nested, evaluation  is  done  from  inner-most  to
+                 outer-most.   The  outer-most escape must begin with `%'; the inner
+                 escapes must not.  For example,
+
+                      %<(mymbox{from}) To: %{to}%>
+
+                 writes the value of the header component "From:" to _s_t_r; then (_m_y_m_-
+                 _b_o_x)  reads  _s_t_r  and  writes  its  result to _n_u_m; then the control
+                 escape evaluates _n_u_m.  If _n_u_m is non-zero, the  string  "To:  "  is
+                 printed followed by the value of the header component "To:".
+
+                 A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is in order.  In general,  it
+                 checks each of the addresses in the header component "_c_o_m_p" against
+                 the user's mailbox name and any  _A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s.   It  returns
+                 true  if  any address matches, however, it also returns true if the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -139-                      MH-FORMAT(5)
+
+
+                 "_c_o_m_p" header is not present in the message.  If needed, the (_n_u_l_l)
+                 function can be used to explicitly test for this condition.
+
+                 When a function or component escape is interpreted and  the  result
+                 will  be immediately printed, an optional field width can be speci-
+                 fied to print the field in exactly a given  number  of  characters.
+                 For  example,  a  numeric escape like %4(_s_i_z_e) will print at most 4
+                 digits of the message size; overflow will be indicated by a `?'  in
+                 the first position (like `?234').  A string escape like %4(_m_e) will
+                 print the first 4 characters and truncate at the end. Short  fields
+                 are  padded  at  the  right  with  the  fill character (normally, a
+                 blank).  If the field width argument begins with  a  leading  zero,
+                 then the fill character is set to a zero.
+
+                 As above, the functions (_p_u_t_n_u_m_f) and (_p_u_t_s_t_r_f) print their  result
+                 in  exactly  the  number  of  characters specified by their leading
+                 field width argument. For example,  %06(_p_u_t_n_u_m_f(_s_i_z_e))  will  print
+                 the message size in a field six characters wide filled with leading
+                 zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print the "From:"  header  component
+                 in  fourteen  characters with trailing spaces added as needed.  For
+                 _p_u_t_s_t_r_f, using a negative value for the field width  causes  right-
+                 justification  of  the string within the field, with padding on the
+                 left up to the field width.  The functions  (_p_u_t_n_u_m)  and  (_p_u_t_s_t_r)
+                 print  their  result  in the minimum number of characters required,
+                 and ignore any leading field width argument.
+
+                 The available output width is kept in  an  internal  register;  any
+                 output past this width will be truncated.
+
+                 Comments may be inserted in most places where a  function  argument
+                 is  not expected.  A comment begins with `%;' and ends with a (non-
+                 escaped) newline.
+
+                 With all this in mind, here's the default format string  for  _s_c_a_n.
+                 It's  been  divided into several pieces for readability.  The first
+                 part is:
+
+                      %4(msg)%<(cur)+%| %>%<{replied}-%?{encrypted}E%| %>
+
+                 which says that the  message  number  should  be  printed  in  four
+                 digits,  if  the  message  is the current message then a `+' else a
+                 space should be printed, and if a "Replied:" field is present  then
+                 a  `-'  else if an "Encrypted:" field is present then an `E' other-
+                 wise a space should be printed.  Next:
+
+                      %02(mon{date})/%02(mday{date})
+
+                 the month  and  date  are  printed  in  two  digits  (zero  filled)
+                 separated by a slash.  Next,
+
+                      %<{date} %|*>
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -140-                      MH-FORMAT(5)
+
+
+                 If a "Date:" field was present, then a space is printed,  otherwise
+                 a `*'.  Next,
+
+                      %<(mymbox{from})%<{to}To:%14(friendly{to})%>%>
+
+                 if the message is from me, and there is a "To:" header, print `To:'
+                 followed by a "user-friendly" rendering of the first address in the
+                 "To:" field.  Continuing,
+
+                      %<(zero)%17(friendly{from})%>
+
+                 if either of the above two tests failed, then the  "From:"  address
+                 is printed in a "user-friendly" format.  And finally,
+
+                      %{subject}%<{body}<<%{body}%>
+
+                 the subject and initial body (if any) are printed.
+
+                 For a more complicated example, next consider the default _r_e_p_l_c_o_m_p_s
+                 format file.
+
+                      %(lit)%(formataddr %<{reply-to}
+
+                 This clears _s_t_r and formats the "Reply-To:" header if present.   If
+                 not present, the else-if clause is executed.
+
+                      %?{from}%?{sender}%?{return-path}%>)\
+
+                 This formats the "From:",  "Sender:"  and  "Return-Path:"  headers,
+                 stopping as soon as one of them is present.  Next:
+
+                      %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+                 If the _f_o_r_m_a_t_a_d_d_r result is non-null, it is printed as  an  address
+                 (with  line folding if needed) in a field _w_i_d_t_h wide with a leading
+                 label of "To: ".
+
+                      %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+                 _s_t_r is cleared, and the "To:" and "Cc:"  headers,  along  with  the
+                 user's  address  (depending  on  what  was specified with the "-cc"
+                 switch to _r_e_p_l) are formatted.
+
+                      %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+                 If the result is non-null, it is printed as above  with  a  leading
+                 label of "cc: ".
+
+                      %<{fcc}Fcc: %{fcc}\n%>\
+
+                 If a "-fcc folder" switch was given to _r_e_p_l (see _r_e_p_l (1) for  more
+                 details about %{_f_c_c}), an "Fcc:" header is output.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -141-                      MH-FORMAT(5)
+
+
+                      %<{subject}Subject: Re: %{subject}\n%>\
+
+                 If a subject component was present, a  suitable  reply  subject  is
+                 output.
+
+                      %<{date}In-reply-to: Your message of "\
+                      %<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id}
+                                   %{message-id}%>\n%>\
+                      --------
+
+                 If a date component was present, an "In-Reply-To:" header is output
+                 with the preface "Your message of ".  If the date was parseable, it
+                 is output in a user-friendly format, otherwise it is output  as-is.
+                 The message-id is included if present.  As with all plain-text, the
+                 row of dashes are output as-is.
+
+                 This last part is a good example for  a  little  more  elaboration.
+                 Here's that part again in pseudo-code:
+
+                      if (comp_exists(date))  then
+                           print ("In-reply-to: Your message of \"")
+                           if (not_date_string(date.value) then
+                                print (date.value)
+                           else
+                                print (pretty(date.value))
+                           endif
+                           print ("\"")
+                           if (comp_exists(message-id)) then
+                                print ("\n\t")
+                                print (message-id.value)
+                           endif
+                           print ("\n")
+                      endif
+
+                 Although this seems complicated, in point of fact, this  method  is
+                 flexible  enough to extract individual fields and print them in any
+                 format the user desires.
+
+            _F_i_l_e_s
+                 None
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 scan(1), repl(1), ap(8), dp(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -142-                      MH-FORMAT(5)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 This software was contributed for MH 6.3.  Prior  to  this,  output
+                 format  specifications  were much easier to write, but considerably
+                 less flexible.
+
+
+            _B_u_g_s
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -143-                        MH-MAIL(5)
+
+
+            _N_A_M_E
+                 mh-mail - message format for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 any _M_H command
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_H processes messages in a particular format.  It should  be  noted
+                 that  although  neither  Bell  nor Berkeley mailers produce message
+                 files in the format that _M_H prefers, _M_H can read message  files  in
+                 that antiquated format.
+
+                 Each user possesses a mail drop box which  initially  receives  all
+                 messages  processed  by _p_o_s_t (8).  _I_n_c (1) will read from that drop
+                 box and incorporate the new messages found there  into  the  user's
+                 own  mail folders (typically `+inbox').  The mail drop box consists
+                 of one or more messages.  To facilitate the separation of messages,
+                 each  message begins and ends with a line consisting of nothing but
+                 four CTRL-A (octal 001) characters.
+
+                 Messages are expected to consist of lines of  text.   Graphics  and
+                 binary data are not handled.  No data compression is accepted.  All
+                 text is clear ASCII 7-bit data.
+
+                 The general "memo" framework of RFC-822 is used.   A  message  con-
+                 sists of a block of information in a rigid format, followed by gen-
+                 eral text with no specified format.  The  rigidly  formatted  first
+                 part of a message is called the header, and the free-format portion
+                 is called the body.  The header must always exist, but the body  is
+                 optional.   These  parts  are separated by an empty line, i.e., two
+                 consecutive newline characters.  Within _M_H, the header and body may
+                 be separated by a line consisting of dashes:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 The header is composed of one or more header  items.   Each  header
+                 item  can  be  viewed as a single logical line of ASCII characters.
+                 If the text of a header item extends across several real lines, the
+                 continuation lines are indicated by leading spaces or tabs.
+
+                 Each header item is called a component and is composed of a keyword
+                 or  name,  along  with  associated text.  The keyword begins at the
+                 left margin, may NOT contain spaces or  tabs,  may  not  exceed  63
+                 characters  (as specified by RFC-822), and is terminated by a colon
+                 (`:').  Certain components (as identified by their  keywords)  must
+                 follow rigidly defined formats in their text portions.
+
+                 The  text  for  most  formatted  components  (e.g.,   "Date:"   and
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -144-                        MH-MAIL(5)
+
+
+                 "Message-Id:") is produced automatically.  The only ones entered by
+                 the user are address fields such as "To:",  "cc:",  etc.   Internet
+                 addresses  are  assigned mailbox names and host computer specifica-
+                 tions.  The rough format is "local@domain", such  as  "MH@UCI",  or
+                 "MH@UCI-ICSA.ARPA".  Multiple addresses are separated by commas.  A
+                 missing host/domain is assumed to be the local host/domain.
+
+                 As mentioned above, a blank line (or a line of dashes) signals that
+                 all  following text up to the end of the file is the body.  No for-
+                 matting is expected or enforced within the body.
+
+                 Following is a list of header components that are considered  mean-
+                 ingful to various MH programs.
+                 Date:
+                      Added by _p_o_s_t (8), contains date and  time  of  the  message's
+                      entry into the transport system.
+
+                 From:
+                      Added by _p_o_s_t (8), contains  the  address  of  the  author  or
+                      authors  (may  be  more  than  one  if  a  "Sender:"  field is
+                      present).  Replies are typically directed to addresses in  the
+                      "Reply-To:"  or  "From:"  field  (the former has precedence if
+                      present).
+
+                 Sender:
+                      Added by _p_o_s_t (8) in the event that the message already has  a
+                      "From:"  line.   This  line contains the address of the actual
+                      sender.  Replies are never sent to addresses in the  "Sender:"
+                      field.
+
+                 To:
+                      Contains addresses of primary recipients.
+
+                 cc:
+                      Contains addresses of secondary recipients.
+
+                 Bcc:
+                      Still more recipients.  However, the "Bcc:" line is not copied
+                      onto  the  message  as  delivered, so these recipients are not
+                      listed.  _M_H uses an encapsulation method for blind copies, see
+                      _s_e_n_d (1).
+
+                 Fcc:
+                      Causes _p_o_s_t (8) to copy the message into the specified  folder
+                      for  the  sender, if the message was successfully given to the
+                      transport system.
+
+                 Message-ID:
+                      A unique message identifier added by _p_o_s_t (8) if the  `-msgid'
+                      flag is set.
+
+                 Subject:
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -145-                        MH-MAIL(5)
+
+
+                      Sender's commentary.  It is displayed by _s_c_a_n (1).
+
+                 In-Reply-To:
+                      A commentary line added by _r_e_p_l (1) when replying  to  a  mes-
+                      sage.
+
+                 Resent-Date:
+                      Added when redistributing a message by _p_o_s_t (8).
+
+                 Resent-From:
+                      Added when redistributing a message by _p_o_s_t (8).
+
+                 Resent-To:
+                      New recipients for a message resent by _d_i_s_t (1).
+
+                 Resent-cc:
+                      Still more recipients.  See "cc:" and "Resent-To:".
+
+                 Resent-Bcc:
+                      Even more recipients.  See "Bcc:" and "Resent-To:".
+
+                 Resent-Fcc:
+                      Copy  resent  message  into  a   folder.    See   "Fcc:"   and
+                      "Resent-To:".
+
+                 Resent-Message-Id:
+                      A unique identifier glued on by _p_o_s_t (8) if the `-msgid'  flag
+                      is set.  See "Message-Id:" and "Resent-To:".
+
+                 Resent:
+                      Annotation for _d_i_s_t (1) under the `-annotate' option.
+
+                 Forwarded:
+                      Annotation for _f_o_r_w (1) under the `-annotate' option.
+
+                 Replied:
+                      Annotation for _r_e_p_l (1) under the `-annotate' option.
+
+
+            _F_i_l_e_s
+                 /usr/spool/mail/$USER                Location of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -146-                        MH-MAIL(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -147-                     MH-PROFILE(5)
+
+
+            _N_A_M_E
+                 mh-profile - user profile customization for MH message handler
+
+            _S_Y_N_O_P_S_I_S
+                 ._m_h__p_r_o_f_i_l_e
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Each user of _M_H is expected to have a file named ._m_h__p_r_o_f_i_l_e in his
+                 or her home directory.  This file contains a set of user parameters
+                 used by some or all of the _M_H family of programs.  Each line of the
+                 file is of the format
+
+                     _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t: _v_a_l_u_e
+
+                 The  possible  profile  components  are  exemplified  below.   Only
+                 `Path:'  is  mandatory.  The others are optional; some have default
+                 values if they are not present.  In the notation used below,  (pro-
+                 file,  default)  indicates  whether  the information is kept in the
+                 user's _M_H profile or _M_H context, and  indicates  what  the  default
+                 value is.
+
+                 Path: Mail
+                           Locates _M_H transactions in directory  "Mail".   (profile,
+                           no default)
+
+                 context: context
+                           Declares the location of the _M_H  context  file,  see  the
+                           HISTORY     section     below.      (profile,    default:
+                           <mh-dir>/context)
+
+                 Current-Folder: inbox
+                           Keeps  track  of  the  current  open  folder.   (context,
+                           default: folder specified by "Inbox")
+
+                 Inbox:  inbox
+                           Defines the  name  of  your  inbox.   (profile,  default:
+                           inbox)
+
+                 Previous-Sequence: pseq
+                           Names the sequences which should be defined as the `msgs'
+                           or  `msg' argument given to the program.  If not present,
+                           or empty, no sequences are defined.  Otherwise, for  each
+                           name  given,  the  sequence is first zero'd and then each
+                           message is added to the sequence.  (profile, no default)
+
+                 Sequence-Negation: not
+                           Defines the string which, when  prefixed  to  a  sequence
+                           name,  negates that sequence.  Hence, "notseen" means all
+                           those messages that are not  a  member  of  the  sequence
+                           "seen".  (profile, no default)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -148-                     MH-PROFILE(5)
+
+
+                 Unseen-Sequence: unseen
+                           Names the sequences which should be defined as those mes-
+                           sages recently incorporated by _i_n_c.  _S_h_o_w knows to remove
+                           messages from this sequence once it thinks they have been
+                           seen.   If  not  present,  or  empty,  no  sequences  are
+                           defined.   Otherwise,  each  message  is  added  to  each
+                           sequence name given.  (profile, no default)
+
+                 mh-sequences: .mh_sequences
+                           The name of the file in each folder which defines  public
+                           sequences.  To disable the use of public sequences, leave
+                           the  value  portion  of  this  entry  blank.    (profile,
+                           default: .mh_sequences)
+
+                 atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+                           Keeps track of the private sequence  called  _s_e_q  in  the
+                           specified folder.  (context, no default)
+
+                 Editor: /usr/ucb/ex
+                           Defines  editor  to  be  used  by   _c_o_m_p (1),   _d_i_s_t (1),
+                           _f_o_r_w (1), and _r_e_p_l (1).  (profile, default: prompter)
+
+                 Msg-Protect: 644
+                           Defines octal protection bits  for  message  files.   See
+                           _c_h_m_o_d (1)  for an explanation of the octal number.  (pro-
+                           file, default: 0644)
+
+                 Folder-Protect: 711
+                           Defines protection bits for  folder  directories.   (pro-
+                           file, default: 0711)
+
+                 _p_r_o_g_r_a_m: default switches
+                           Sets default switches to be used whenever the mh  program
+                           _p_r_o_g_r_a_m  is invoked.  For example, one could override the
+                           _E_d_i_t_o_r: profile component when replying  to  messages  by
+                           adding a component such as:
+                                   repl: -editor /bin/ed
+                           (profile, no defaults)
+
+                 _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+                           Names "nexteditor" to be the default editor  after  using
+                           "lasteditor".   This takes effect at "What now?" level in
+                           _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l.  After editing the draft with
+                           "lasteditor",  the  default editor is set to be "nextedi-
+                           tor".  If the user types "edit" without any arguments  to
+                           "What  now?",  then  "nexteditor"  is used.  (profile, no
+                           default)
+
+                 bboards: system
+                           Tells _b_b_c which BBoards you are interested in.  (profile,
+                           default: system)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -149-                     MH-PROFILE(5)
+
+
+                 Folder-Stack: _f_o_l_d_e_r_s
+                           The contents of the folder-stack for the _f_o_l_d_e_r  command.
+                           (context, no default)
+
+                 mhe:
+                           If present, tells _i_n_c to  compose  an  _M_H_E  auditfile  in
+                           addition  to  its other tasks.  _M_H_E is Brian Reid's _E_m_a_c_s
+                           front-end for _M_H.  An early version is supplied with  the
+                           _m_h._6 distribution.  (profile, no default)
+
+                 Alternate-Mailboxes: mh@uci-750a, bug-mh*
+                           Tells _r_e_p_l and _s_c_a_n which addresses are really yours.  In
+                           this  way,  _r_e_p_l knows which addresses should be included
+                           in the reply, and _s_c_a_n knows if the message  really  ori-
+                           ginated  from  you.   Addresses  must  be  separated by a
+                           comma, and the hostnames listed should be the  "official"
+                           hostnames  for the mailboxes you indicate, as local nick-
+                           names for hosts are not replaced with their official site
+                           names.   For  each  address, if a host is not given, then
+                           that address on any host is considered  to  be  you.   In
+                           addition,  an asterisk (`*') may appear at either or both
+                           ends of the mailbox and host to indicate wild-card match-
+                           ing.  (profile, default: your user-id)
+
+                 Aliasfile: aliases other-alias
+                           Indicates aliases files for _a_l_i, _w_h_o_m,  and  _s_e_n_d.   This
+                           may  be  used instead of the `-alias file' switch.  (pro-
+                           file, no default)
+
+                 Draft-Folder: drafts
+                           Indicates a default draft folder for  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+                           and _r_e_p_l.  (profile, no default)
+
+                 digest-issue-_l_i_s_t: 1
+                           Tells _f_o_r_w the last issue of the last volume sent for the
+                           digest _l_i_s_t.  (context, no default)
+
+                 digest-volume-_l_i_s_t: 1
+                           Tells _f_o_r_w the last volume  sent  for  the  digest  _l_i_s_t.
+                           (context, no default)
+
+                 MailDrop: .mail
+                           Tells _i_n_c your maildrop, if different from  the  default.
+                           This is superceded by the MAILDROP envariable.  (profile,
+                           default: /usr/spool/mail/$USER)
+
+                 Signature: RAND MH System (agent: Marshall Rose)
+                           Tells _s_e_n_d your mail signature.  This  is  superceded  by
+                           the  SIGNATURE envariable.  On hosts where _M_H was config-
+                           ured with the UCI option, if SIGNATURE  is  not  set  and
+                           this   profile   entry   is   not   present,   the   file
+                           $HOME/.signature is consulted.  Your  signature  will  be
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -150-                     MH-PROFILE(5)
+
+
+                           added  to the address _s_e_n_d puts in the "From:" header; do
+                           not include an address in the signature text.   (profile,
+                           no default)
+
+                 The following profile elements are  used  whenever  an  _M_H  program
+                 invokes  some  other program such as _m_o_r_e (1).  The ._m_h__p_r_o_f_i_l_e can
+                 be used to select alternate  programs  if  the  user  wishes.   The
+                 default values are given in the examples.
+
+                      fileproc:     /usr/bs/mh-6.8/bin/refile
+                      incproc:      /usr/bs/mh-6.8/bin/inc
+                      installproc:  /usr/bs/mh-6.8/lib/install-mh
+                      lproc:        /usr/ucb/more
+                      mailproc:     /usr/bs/mh-6.8/bin/mhmail
+                      mhlproc:      /usr/bs/mh-6.8/lib/mhl
+                      moreproc:     /usr/ucb/more
+                      mshproc:      /usr/bs/mh-6.8/bin/msh
+                      packproc:     /usr/bs/mh-6.8/bin/packf
+                      postproc:     /usr/bs/mh-6.8/lib/post
+                      rmmproc:      none
+                      rmfproc:      /usr/bs/mh-6.8/bin/rmf
+                      sendproc:     /usr/bs/mh-6.8/bin/send
+                      showproc:     /usr/ucb/more
+                      whatnowproc:  /usr/bs/mh-6.8/bin/whatnow
+                      whomproc:     /usr/bs/mh-6.8/bin/whom
+
+                 If you define the envariable MH, you can specify  a  profile  other
+                 than ._m_h__p_r_o_f_i_l_e to be read by the _M_H programs that you invoke.  If
+                 the value of MH is not absolute, (i.e., does not begin with a  / ),
+                 it  will  be  presumed to start from the current working directory.
+                 This is one of the very few exceptions  in  _M_H  where  non-absolute
+                 pathnames are not considered relative to the user's _M_H directory.
+
+                 Similarly, if you define the envariable MHCONTEXT, you can  specify
+                 a  context  other than the normal context file (as specified in the
+                 _M_H profile).  As always, unless the value of MHCONTEXT is absolute,
+                 it will be presumed to start from your _M_H directory.
+
+                 _M_H programs also support other envariables:
+
+                 MAILDROP : tells _i_n_c the default maildrop
+                      This supercedes the "MailDrop:" profile entry.
+
+                 SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail signature
+                      This supercedes the "Signature:" profile entry.
+
+                 HOME : tells all _M_H programs your home directory
+
+                 SHELL : tells _b_b_l the default shell to run
+
+                 TERM : tells _M_H your terminal type
+                      The TERMCAP envariable  is  also  consulted.   In  particular,
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -151-                     MH-PROFILE(5)
+
+
+                      these  tell  _s_c_a_n  and _m_h_l how to clear your terminal, and how
+                      many columns wide your terminal is.  They also  tell  _m_h_l  how
+                      many lines long your terminal screen is.
+
+                 editalt : the alternate message
+                      This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+                      peruse  the message being distributed or replied to.  The mes-
+                      sage is also available  through  a  link  called  "@"  in  the
+                      current  directory  if  your current working directory and the
+                      folder the message lives in are on the same UNIX filesystem.
+
+                 mhdraft : the path to the working draft
+                      This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l to  tell  the  _w_h_a_t_-
+                      _n_o_w_p_r_o_c  which  file  to  ask "What now?" questions about.  In
+                      addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l set  mhfolder  if  appropriate.
+                      Further,  _d_i_s_t  and  _r_e_p_l set mhaltmsg to tell the _w_h_a_t_n_o_w_p_r_o_c
+                      about an alternate message associated with the draft (the mes-
+                      sage being distributed or replied to), and _d_i_s_t sets mhdist to
+                      tell the _w_h_a_t_n_o_w_p_r_o_c that message  re-distribution  is  occur-
+                      ring.   Also,  mheditor  is  set  to  tell the _w_h_a_t_n_o_w_p_r_o_c the
+                      user's choice of  editor  (unless  overridden  by  `-noedit').
+                      Similarly,  mhuse  may be set by _c_o_m_p.  Finally, mhmessages is
+                      set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if annotations are to occur (along
+                      with  mhannotate, and mhinplace).  It's amazing all the infor-
+                      mation that has to get passed  via  envariables  to  make  the
+                      "What now?" interface look squeaky clean to the _M_H user, isn't
+                      it?  The reason for all this is that the _M_H  user  can  select
+                      _a_n_y  program as the _w_h_a_t_n_o_w_p_r_o_c, including one of the standard
+                      shells.  As a result, it's not possible  to  pass  information
+                      via an argument list.
+                      If the WHATNOW option was set during  _M_H  configuration  (type
+                      `-help'  to an _M_H command to find out), and if this envariable
+                      is set, if the commands _r_e_f_i_l_e, _s_e_n_d, _s_h_o_w, or  _w_h_o_m  are  not
+                      given  any  `msgs'  arguments, then they will default to using
+                      the file indicated by mhdraft.  This is useful for getting the
+                      default behavior supplied by the default _w_h_a_t_n_o_w_p_r_o_c.
+
+                 mhfolder : the folder containing the alternate message
+                      This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+                      peruse  other  messages  in the current folder besides the one
+                      being distributed or replied to.  The mhfolder  envariable  is
+                      also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t for use by _m_h_l.
+
+                 MHBBRC :
+                      If you define the envariable MHBBRC, you can specify a BBoards
+                      information  file  other than ._b_b_r_c to be read by _b_b_c.  If the
+                      value of MHBBRC is not absolute, (i.e., does not begin with  a
+                      / ),  it  will  be  presumed to start from the current working
+                      directory.
+
+                 MHFD :
+                      If the OVERHEAD option was set during _M_H  configuration  (type
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -152-                     MH-PROFILE(5)
+
+
+                      `-help' to an _M_H command to find out), then if this envariable
+                      is set, _M_H considers it to be the number of a file  descriptor
+                      which  is  opened, read-only to the _M_H profile.  Similarly, if
+                      the envariable MHCONTEXTFD is set, this is  the  number  of  a
+                      file  descriptor  which is opened read-only to the _M_H context.
+                      This feature of _M_H is experimental, and  is  used  to  examine
+                      possible  speed  improvements for _M_H startup.  Note that these
+                      envariables must be set and non-empty to enable this  feature.
+                      However,  if OVERHEAD is enabled during _M_H configuration, then
+                      when _M_H programs call other _M_H programs, this scheme is  used.
+                      These file descriptors are not closed throughout the execution
+                      of the _M_H program, so children may  take  advantage  of  this.
+                      This approach is thought to be completely safe and does result
+                      in some performance enhancements.
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 or $MH                               Rather than the standard profile
+                 <mh-dir>/context                     The user context
+                 or $CONTEXT                          Rather than the standard context
+                 <folder>/.mh_sequences               Public sequences for <folder>
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 All
+
+
+            _S_e_e _A_l_s_o
+                 mh(1), environ(5), mh-sequence(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -153-                     MH-PROFILE(5)
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the current-message value of a writable
+                 folder  was  kept  in a file called "cur" in the folder itself.  In
+                 _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the current-message values for  all
+                 folders, regardless of their writability.
+
+                 In all versions of _M_H since _m_h._4,  the  ._m_h__p_r_o_f_i_l_e  contains  only
+                 static  information, which _M_H programs will NOT update.  Changes in
+                 context are made to the _c_o_n_t_e_x_t file kept in the users MH  _d_i_r_e_c_t_o-
+                 _r_y.  This includes, but is not limited to: the "Current-Folder" en-
+                 try and all private sequence information.  Public sequence informa-
+                 tion is kept in a file called ._m_h__s_e_q_u_e_n_c_e_s in each folder.
+
+                 To convert from the format used in releases of _M_H prior to the for-
+                 mat used in the _m_h._4 release, _i_n_s_t_a_l_l-_m_h should be invoked with the
+                 `-compat' switch.  This generally happens automatically on _M_H  sys-
+                 tems generated with the "COMPAT" option during _M_H configuration.
+
+                 The ._m_h__p_r_o_f_i_l_e may override the  path  of  the  _c_o_n_t_e_x_t  file,  by
+                 specifying  a "context" entry (this must be in lower-case).  If the
+                 entry is not absolute (does not start with a / ), then it is inter-
+                 preted  relative  to the user's _M_H directory.  As a result, you can
+                 actually have more than one set of private sequences by using  dif-
+                 ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -154-                     MH-PROFILE(5)
+
+
+            _B_u_g_s
+                 The shell quoting conventions are not available in the .mh_profile.
+                 Each token is separated by whitespace.
+
+                 There is some question as to  what  kind  of  arguments  should  be
+                 placed  in  the  profile  as  options.  In order to provide a clear
+                 answer, recall command line semantics of all _M_H programs: conflict-
+                 ing  switches  (e.g., `-header and `-noheader') may occur more than
+                 one time on the command line, with the last switch  taking  effect.
+                 Other  arguments, such as message sequences, filenames and folders,
+                 are always remembered on the invocation line and are not superseded
+                 by  following  arguments  of  the  same type.  Hence, it is safe to
+                 place only switches (and their arguments) in the profile.
+
+                 If one finds that an _M_H program is being invoked  again  and  again
+                 with  the same arguments, and those arguments aren't switches, then
+                 there are a few possible solutions to this problem.  The  first  is
+                 to  create a (soft) link in your $_H_O_M_E/_b_i_n directory to the _M_H pro-
+                 gram of your choice.  By giving this link a different name, you can
+                 create  a new entry in your profile and use an alternate set of de-
+                 faults for the _M_H command.  Similarly, you  could  create  a  small
+                 shell script which called the _M_H program of your choice with an al-
+                 ternate set of invocation line switches (using links and an  alter-
+                 nate profile entry is preferable to this solution).
+
+                 Finally, the _c_s_h user could create an alias for the command of  the
+                 form:
+
+                      alias cmd 'cmd arg1 arg2 ...'
+
+                 In this way, the user can avoid lengthy type-in to the  shell,  and
+                 still  give  _M_H commands safely.  (Recall that some _M_H commands in-
+                 voke others, and that in all cases, the profile  is  read,  meaning
+                 that aliases are disregarded beyond an initial command invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -155-                    MH-SEQUENCE(5)
+
+
+            _N_A_M_E
+                 mh-sequence - sequence specification for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 most _M_H commands
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Most _M_H commands accept a  `msg'  or  `msgs'  specification,  where
+                 `msg'  indicates  one message and `msgs' indicates one or more mes-
+                 sages.  To designate a message,  you  may  use  either  its  number
+                 (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+                      _N_a_m_e      _D_e_s_c_r_i_p_t_i_o_n
+                      first     the first message in the folder
+                      last      the last message in the folder
+                      cur       the most recently accessed message
+                      prev      the message numerically preceding "cur"
+                      next      the message numerically following "cur"
+
+                 In commands that take a `msg' argument, the default is "cur".  As a
+                 shorthand, "." is equivalent to "cur".
+
+                 For example: In a folder containing five messages numbered  5,  10,
+                 94,  177  and 325, "first" is 5 and "last" is 325.  If "cur" is 94,
+                 then "prev" is 10 and "next" is 177.
+
+                 The word `msgs' indicates that one or more messages may  be  speci-
+                 fied.   Such a specification consists of one message designation or
+                 of several message designations separated  by  spaces.   A  message
+                 designation  consists either of a message name as defined above, or
+                 a message range.
+
+                 A message range is specified as "name1-name2"  or  "name:n",  where
+                 `name',  `name1'  and  `name2'  are  message  names,  and `n' is an
+                 integer.
+
+                 The specification "name1-name2" designates  all  currently-existing
+                 messages from `name1' to `name2' inclusive.  The message name "all"
+                 is a shorthand for the message range "first-last".
+
+                 The specification "name:n" designates up to  `n'  messages.   These
+                 messages  start with `name' if `name' is a message number or one of
+                 the reserved names "first" "cur", or "next", The messages end  with
+                 `name'  if  `name'  is "prev" or "last".  The interpretation of `n'
+                 may be overridden by preceding `n' with a plus or minus sign;  `+n'
+                 always  means  up  to  `n'  messages starting with `name', and `-n'
+                 always means up to `n' messages ending with `name'.
+
+                 In commands which accept a `msgs' argument, the default  is  either
+                 "cur"  or  "all", depending on which makes more sense for each com-
+                 mand  (see  the  individual  man  pages  for  details).    Repeated
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -156-                    MH-SEQUENCE(5)
+
+
+                 specifications of the same message have the same effect as a single
+                 specification of the message.
+
+
+              _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e_s
+
+                 In addition to the "reserved"  (pre-defined)  message  names  given
+                 above,  _M_H  supports  user-defined  sequence  names.   User-defined
+                 sequences allow the _M_H user a tremendous amount of power in dealing
+                 with  groups of messages in the same folder by allowing the user to
+                 bind a group of messages to a meaningful symbolic name.
+
+                 The name used to denote a  message  sequence  must  consist  of  an
+                 alphabetic  character followed by zero or more alphanumeric charac-
+                 ters, and can not be one of the  "reserved"  message  names  above.
+                 After  defining  a  sequence, it can be used wherever an _M_H command
+                 expects a `msg' or `msgs' argument.
+
+                 Some  forms  of  message  ranges  are  allowed  with   user-defined
+                 sequences.   The  specification "name:n" may be used, and it desig-
+                 nates up to the first `n' messages (or last `n' messages for  `-n')
+                 which are elements of the user-defined sequence `name'.
+
+                 The specifications "name:next" and "name:prev" may  also  be  used,
+                 and  they  designate  the next or previous message (relative to the
+                 current message) which is an element of the  user-defined  sequence
+                 `name'.   The  specificaitions  "name:first"  and  "name:last"  are
+                 equivalent to "name:1" and "name:-1", respectively.  The specifica-
+                 tion  "name:cur" is not allowed (use just "cur" instead).  The syn-
+                 tax of these message range specifcations is subject  to  change  in
+                 the future.
+
+                 User-defined sequence names are specific to each folder.  They  are
+                 defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+              _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                 There are two varieties of sequences: _p_u_b_l_i_c sequences and  _p_r_i_v_a_t_e
+                 sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H
+                 user that can read that folder and are kept  in  the  .mh_sequences
+                 file  in  the folder.  _P_r_i_v_a_t_e sequences are accessible only to the
+                 _M_H user that defined those sequences and are kept in the user's  _M_H
+                 context file.  By default, _p_i_c_k and _m_a_r_k create _p_u_b_l_i_c sequences if
+                 the folder for which the sequences are being defined is writable by
+                 the  _M_H  user.  Otherwise, _p_r_i_v_a_t_e sequences are created.  This can
+                 be overridden with the `-public' and `-private' switches to _m_a_r_k.
+
+
+              _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+                 _M_H provides the ability to select all messages not  elements  of  a
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -157-                    MH-SEQUENCE(5)
+
+
+                 user-defined  sequence.   To  do  this,  the user should define the
+                 entry "Sequence-Negation" in the _M_H profile file; its value may  be
+                 any  string.  This string is then used to preface an existing user-
+                 defined sequence name.  This specification  then  refers  to  those
+                 messages not elements of the specified sequence name.  For example,
+                 if the profile entry is:
+
+                      Sequence-Negation: not
+
+                 then anytime an _M_H command is given "notfoo" as a `msg'  or  `msgs'
+                 argument, it would substitute all messages that are not elements of
+                 the sequence "foo".
+
+                 Obviously, the user should beware of defining sequences with  names
+                 that begin with the value of the "Sequence-Negation" profile entry.
+
+
+              _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+                 _M_H provides the ability to remember the `msgs'  or  `msg'  argument
+                 last  given to an _M_H command.  The entry "Previous-Sequence" should
+                 be defined in the _M_H profile; its value should be a  sequence  name
+                 or  multiple  sequence names separated by spaces.  If this entry is
+                 defined, when when an _M_H  command  finishes,  it  will  define  the
+                 sequence(s)  named  in the value of this entry to be those messages
+                 that were specified to the command.  Hence, a profile entry of
+
+                      Previous-Sequence: pseq
+
+                 directs any _M_H command that accepts a `msg' or `msgs'  argument  to
+                 define the sequence "pseq" as those messages when it finishes.
+
+                 Note:  there  can  be  a   performance   penalty   in   using   the
+                 "Previous-Sequence"  facility.  If it is used, all _M_H programs have
+                 to write the sequence information to the .mh_sequences file for the
+                 folder  each  time  they  run.   If the "Previous-Sequence" profile
+                 entry is not included,  only  _p_i_c_k  and  _m_a_r_k  will  write  to  the
+                 .mh_sequences file.
+
+
+              _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+                 Finally, some users like to indicate messages which have  not  been
+                 previously seen by them.  Both _i_n_c and _s_h_o_w honor the profile entry
+                 "Unseen-Sequence" to support this  activity.   This  entry  in  the
+                 .mh_profile  should  be  defined  as  one  or  more  sequence names
+                 separated by spaces.  If there is a value for "Unseen-Sequence"  in
+                 the profile, then whenever _i_n_c places new messages in a folder, the
+                 new messages will also be added to the  sequence(s)  named  in  the
+                 value of this entry.  Hence, a profile entry of
+
+                      Unseen-Sequence: unseen
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -158-                    MH-SEQUENCE(5)
+
+
+                 directs _i_n_c to add new messages to the sequence  "unseen".   Unlike
+                 the  behavior of the "Previous-Sequence" entry in the profile, how-
+                 ever, the sequence(s) will not be zeroed by _i_n_c.
+
+                 Similarly, whenever _s_h_o_w (or _n_e_x_t or _p_r_e_v) displays a message, that
+                 message   will   be   removed  from  any  sequences  named  by  the
+                 "Unseen-Sequence" entry in the profile.
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 <mh-dir>/context                     The user context
+                 <folder>/.mh_sequences               Public sequences for <folder>
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Sequence-Negation:   To designate messages not in a sequence
+                 Previous-Sequence:   The last message specification given
+                 Unseen-Sequence:     Those messages not yet seen by the user
+
+
+            _S_e_e _A_l_s_o
+                 mh(1), mark(1), pick(1), mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 All
+
+
+            _B_u_g_s
+                 User-defined sequences are stored in the .mh_sequences  file  as  a
+                 series  of  message specifications separated by spaces.  If a user-
+                 defined sequence contains too many  individual  message  specifica-
+                 tions,  that line in the file may become too long for _M_H to handle.
+                 This will generate the error message ".mh_sequences is poorly  for-
+                 matted".   You'll  have  to edit the file by hand to remove the of-
+                 fending line.
+
+                 This can happen to users who define the  "Previous-Sequence"  entry
+                 in  the  _M_H profile and have a folder containing many messages with
+                 gaps in the numbering.  A workaround for large folders is to minim-
+                 ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            AP(8)                            -159-                             AP(8)
+
+
+            _N_A_M_E
+                 ap - parse addresses 822-style
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/ap [-form formatfile] [-format string]
+                      [-normalize] [-nonormalize] [-width columns] addrs ...
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_p is a program that parses addresses according to the ARPA  Inter-
+                 net  standard.   It also understands many non-standard formats.  It
+                 is useful for seeing how _M_H will interpret an address.
+
+                 The _a_p program treats each argument as one or more  addresses,  and
+                 prints  those  addresses out in the official 822-format.  Hence, it
+                 is usually best to enclose each argument in double-quotes  for  the
+                 shell.
+
+                 To override the output format used by _a_p, the  `-format string'  or
+                 `-format file'  switches  are used.  This permits individual fields
+                 of the address to be extracted with ease.  The string is  simply  a
+                 format   stringand   thefile   is   simply   a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 In addition to the standard escapes, _a_p also recognizes the follow-
+                 ing additional escape:
+
+                 _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 error   string   A diagnostic if the parse failed
+
+                 If the `-normalize' switch is given, _a_p will try to track down  the
+                 official hostname of the address.
+
+                 Here is the default format string used by _a_p:
+
+                      %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+                 which says that if an error was detected, print the error,  a  `:',
+                 and  the address in error.  Otherwise, output the 822-proper format
+                 of the address.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            AP(8)                            -160-                             AP(8)
+
+
+            _S_e_e _A_l_s_o
+                 dp(8),
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-format' defaults as described above
+                 `-normalize'
+                 `-width' defaults to the width of the terminal
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _a_p.  Therefore, one must usual-
+                 ly place the argument to this switch inside double-quotes.
+
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            CONFLICT(8)                      -161-                       CONFLICT(8)
+
+
+            _N_A_M_E
+                 conflict - search for alias/password conflicts
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/conflict [-mail name] [-search directory]
+                      [aliasfiles...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _C_o_n_f_l_i_c_t is a program that checks to see if the  interface  between
+                 _M_H and transport system is in good shape
+
+                 _C_o_n_f_l_i_c_t also checks for maildrops in /usr/spool/mail which do  not
+                 belong  to  a  valid user.  It assumes that no user name will start
+                 with `.', and thus ignores files  in  /usr/spool/mail  which  begin
+                 with  `.'.   It also checks for entries in the _g_r_o_u_p (5) file which
+                 do not belong to a valid user, and for users  who  do  not  have  a
+                 valid  group  number.   In  addition duplicate users and groups are
+                 noted.
+
+                 If the `-mail name' switch is used, then the results will  be  sent
+                 to  the  specified  _n_a_m_e.   Otherwise,  the results are sent to the
+                 standard output.
+
+                 The `-search directory' switch can be used  to  search  directories
+                 other  than /usr/spool/mail and to report anomalies in those direc-
+                 tories.  The `-search directory' switch can appear  more  than  one
+                 time in an invocation to _c_o_n_f_l_i_c_t.
+
+                 _C_o_n_f_l_i_c_t should be run under  _c_r_o_n (8), or whenever system account-
+                 ing takes place.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+                 /etc/passwd                          List of users
+                 /etc/group                           List of groups
+                 /usr/bs/mh-6.8/bin/mhmail            Program to send mail
+                 /usr/spool/mail/                     Directory of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `aliasfiles' defaults to /usr/bs/mh-6.8/lib/MailAliases
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            CONFLICT(8)                      -162-                       CONFLICT(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DP(8)                            -163-                             DP(8)
+
+
+            _N_A_M_E
+                 dp - parse dates 822-style
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/dp [-form formatfile] [-format string]
+                      [-width columns] dates ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _D_p is a program that parses dates according to  the  ARPA  Internet
+                 standard.   It  also understands many non-standard formats, such as
+                 those  produced  by  TOPS-20  sites  and  some  UNIX  sites   using
+                 _c_t_i_m_e (3).  It is useful for seeing how _M_H will interpret a date.
+
+                 The _d_p program treats each argument as a single  date,  and  prints
+                 the date out in the official 822-format.  Hence, it is usually best
+                 to enclose each argument in double-quotes for the shell.
+
+                 To override the output format used by _d_p, the  `-format string'  or
+                 `-format file'  switches  are used.  This permits individual fields
+                 of the address to be extracted with ease.  The string is  simply  a
+                 format   stringand   thefile   is   simply   a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 Here is the default format string used by _d_p:
+
+                      %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+                 which says that if an error was detected, print the error,  a  `:',
+                 and  the date in error.  Otherwise, output the 822-proper format of
+                 the date.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 ap(8)
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-format' default as described above
+                 `-width' default to the width of the terminal
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DP(8)                            -164-                             DP(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _d_p.  Therefore, one must usual-
+                 ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FMTDUMP(8)                       -165-                        FMTDUMP(8)
+
+
+            _N_A_M_E
+                 fmtdump - decode MH format files
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/fmtdump [-form formatfile] [-format string]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _F_m_t_d_u_m_p is a program that parses an _M_H format file and  produces  a
+                 pseudo-language listing of the how _M_H interprets the file.
+
+                 The `-format string' and `-form formatfile' switches may be used to
+                 specify a format string or format file to read.  The string is sim-
+                 ply a format string and the file is simply a format file.  See  _m_h-
+                 _f_o_r_m_a_t(5) for the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+                 /usr/bs/mh-6.8/lib/scan.default      The default format file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+
+
+            _S_e_e _A_l_s_o
+                 mh-format(5), mh-sequences(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The output may not be useful  unless  you  are  familiar  with  the
+                 internals of the mh-format subroutines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INSTALL-MH(8)                    -166-                     INSTALL-MH(8)
+
+
+            _N_A_M_E
+                 install-mh - initialize the MH environment
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/install-mh [-auto] [-compat]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 When a user runs any _M_H program for the  first  time,  the  program
+                 will  invoke _i_n_s_t_a_l_l-_m_h (with the `-auto' switch) to query the user
+                 for the initial _M_H environment.  The user does NOT invoke this pro-
+                 gram  directly.   The  user  is asked for the name of the directory
+                 that will be designated as the user's _M_H directory.  If this direc-
+                 tory  does  not  exist,  the user is asked if it should be created.
+                 Normally, this directory should be under the user's home directory,
+                 and  has  the  default name of Mail/.  After _i_n_s_t_a_l_l-_m_h has written
+                 the initial .mh_profile for the user, control returns to the origi-
+                 nal _M_H program.
+
+                 As with all  _M_H  commands,  _i_n_s_t_a_l_l-_m_h  first  consults  the  $HOME
+                 envariable to determine the user's home directory.  If $HOME is not
+                 set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+                 When converting from _m_h._3  to  _m_h._4,  _i_n_s_t_a_l_l-_m_h  is  automatically
+                 invoked with the `-compat' switch.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                    The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To set the user's MH directory
+
+
+            _C_o_n_t_e_x_t
+                 With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POST(8)                          -167-                           POST(8)
+
+
+            _N_A_M_E
+                 post - deliver a message
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/bs/mh-6.8/lib/post [-alias aliasfile] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-mime] [-nomime] [-msgid]
+                      [-nomsgid] [-verbose] [-noverbose] [-watch] [-nowatch]
+                      [-width columns] file [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_o_s_t is the program called by _s_e_n_d (1) to deliver  the  message  in
+                 _f_i_l_e  to  local  and  remote  users.  In fact, all of the functions
+                 attributed to _s_e_n_d on its manual page are performed by  _p_o_s_t,  with
+                 _s_e_n_d  acting as a relatively simple preprocessor.  Thus, it is _p_o_s_t
+                 which parses the various header fields,  appends  From:  and  Date:
+                 lines, and interacts with the _M_M_D_F transport system.  _P_o_s_t will not
+                 normally be called directly by the user.
+
+                 _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:",  and  "Resent-xxx:"
+                 header  lines  of  the specified message for destination addresses,
+                 checks these addresses for validity, and formats them so as to con-
+                 form  to  ARPAnet  Internet  Message  Format  protocol,  unless the
+                 `-noformat' flag is set.  This will normally cause "@_l_o_c_a_l-_s_i_t_e" to
+                 be appended to each local destination address, as well as any local
+                 return addresses. The `-width columns' switch can be used to  indi-
+                 cate  the  preferred  length  of the header components that contain
+                 addresses.
+
+                 If a "Bcc:" field is encountered, its addresses will  be  used  for
+                 delivery,  and  the  "Bcc:"  field will be removed from the message
+                 sent to sighted recipients.  The blind recipients will  receive  an
+                 entirely  new  message  with a minimal set of headers.  Included in
+                 the body of the message will be a copy of the message sent  to  the
+                 sighted  recipients.   If  `-filter filterfile'  is specified, then
+                 this copy is filtered (re-formatted) prior to  being  sent  to  the
+                 blind  recipients.  Otherwise, to use the MIME rules for encapsula-
+                 tion, specify the `-mime' switch.
+
+                 The `-alias aliasfile' switch can be used to specify  a  file  that
+                 post  should  take  aliases from.  More than one file can be speci-
+                 fied, each being preceded with `-alias'.  In any event, the primary
+                 alias file is read first.
+
+                 The   `-msgid'   switch   indicates   that   a   "Message-ID:"   or
+                 "Resent-Message-ID:" field should be added to the header.
+
+                 The `-verbose' switch indicates that the user should be informed of
+                 each step of the posting/filing process.
+
+                 The `-watch' switch indicates that the user would like to watch the
+                 transport  system's handling of the message (e.g., local and "fast"
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POST(8)                          -168-                           POST(8)
+
+
+                 delivery).
+
+                 _P_o_s_t consults the envariable $SIGNATURE to determine  the  sender's
+                 personal name in constructing the "From:" line of the message.
+
+            _F_i_l_e_s
+                 /usr/bs/mh-6.8/lib/mtstailor         tailor file
+                 /usr/bs/mh-6.8/bin/refile            Program to process Fcc:s
+                 /usr/bs/mh-6.8/lib/mhl               Program to process Bcc:s
+                 /usr/bs/mh-6.8/lib/MailAliases       Primary alias file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 _p_o_s_t does NOT consult the user's .mh_profile
+
+
+            _S_e_e _A_l_s_o
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822),
+                 mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-alias /usr/bs/mh-6.8/lib/MailAliases'
+                 `-format'
+                 `-nomime'
+                 `-nomsgid'
+                 `-noverbose'
+                 `-nowatch'
+                 `-width 72'
+                 `-nofilter'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 "Reply-To:" fields are allowed to have groups in them according  to
+                 the 822 specification, but _p_o_s_t won't let you use them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                          _5. _R_E_P_O_R_T_I_N_G _P_R_O_B_L_E_M_S
+
+
+
+
+
+                      If problems are encountered with an _M_H program, the problems should
+                 be  reported  to the local maintainers of _M_H.  When doing this, the name
+                 of the program should be reported, along with  the  version  information
+                 for  the  program.   To  find out what version of an _M_H program is being
+                 run, invoke the program with the `-help' switch.  In addition to listing
+                 the  syntax of the command, the program will list information pertaining
+                 to its version.  This information includes the version of _M_H,  the  host
+                 it was generated on, and the date the program was loaded.  A second line
+                 of information, found on versions of _M_H after #5.380 include  _M_H  confi-
+                 guration options.  For example,
+
+                      version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov  6  01:13:53  PST
+                      1985
+                      options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII] [SMTP] [POP]
+
+                 The `6.1 #1[UCI]' indicates that the program is from the UCI  _m_h._6  ver-
+                 sion  of  _M_H.   The  program was generated on the host `nrtc-gremlin' on
+                 `Wed Nov  6 01:13:53 PST 1985'.  It's usually a good idea  to  send  the
+                 output of the `-help' switch along with your report.
+
+                 If there is no local _M_H maintainer, try the  address  Bug-MH.   If  that
+                 fails, use the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -169-
+
+
+
+
+
+
+
+
+
+
+
+
+                                           _6. _A_D_V_A_N_C_E_D _F_E_A_T_U_R_E_S
+
+
+
+
+
+                      This section describes some  features  of  _M_H  that  were  included
+                 strictly for advanced _M_H users.  These capabilities permit _M_H to exhibit
+                 more powerful behavior for the seasoned _M_H users.
+
+
+                 _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+                      User-defined sequences allow the _M_H user  a  tremendous  amount  of
+                 power  in dealing with groups of messages in the same folder by allowing
+                 the user to bind a group of messages to a meaningful symbolic name.  The
+                 user  may choose any name for a message sequence, as long as it consists
+                 of alphanumeric characters and does not conflict with  the  standard  _M_H
+                 reserved message names (e.g., "first", etc).  After defining a sequence,
+                 it can be used wherever an _M_H command expects a `msg'  or  `msgs'  argu-
+                 ment.
+
+                      A restricted form of message ranges are allowed  with  user-defined
+                 sequences.  The  form  "name:n",  specifies up to the first `n' messages
+                 which are part of the user-defined sequence `name'.  A leading plus sign
+                 is  allowed on `n', but is ignored.  The interpretation of n is overrid-
+                 den if n is preceded by a minus sign; `-n' always means up to  the  last
+                 `n' messages which are part of the sequence `name'.
+
+                      Although all _M_H commands expand user-defined sequences as appropri-
+                 ate, there are two commands that allow the user to define and manipulate
+                 them: _p_i_c_k and _m_a_r_k.
+
+                 _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      Most users of _M_H will use user-defined sequences only with the _p_i_c_k
+                 command.  By giving the `-sequence name' switch to _p_i_c_k (which can occur
+                 more than once on the command line), each sequence named is  defined  as
+                 those  messages  which _p_i_c_k matched according the the selection criteria
+                 it was given.  Hence,
+
+                      pick -from frated -seq fred
+
+                 finds all those messages in the current folder which were from "frated",
+                 creates  a  sequence  called "fred", and then adds them to the sequence.
+                 The user could then invoke
+
+                      scan fred
+
+                 to get a _s_c_a_n listing of those messages.  Note  that  by  default,  _p_i_c_k
+                 creates  the named sequences before it adds the selected messages to the
+                 sequence.  Hence, if the named sequence already existed, the sequence is
+
+                                                  -170-
+
+
+
+
+
+
+
+
+
+                                                  -171-
+
+
+                 destroyed  prior  to  being  re-defined (nothing happens to the messages
+                 that were a part of this sequence, they simply cease to  be  members  of
+                 that  sequence).   By  using  the `-nozero' switch, this behavior can be
+                 inhibited, as in
+
+                      pick -from frated -seq sgroup
+                      pick -from fear -seq sgroup -nozero
+                      pick -from freida -seq sgroup -nozero
+
+                 finds all those messages in the current folder which were from "frated",
+                 "fear", or "freida", and defines the sequence called "sgroup" as exactly
+                 those messages.  These operations amounted to an "inclusive-or" of three
+                 selection  criteria, using _p_i_c_k, one can also generate the "and" of some
+                 selection criteria as well:
+
+                      pick -from frated -seq fred
+                      pick -before friday -seq fred fred
+
+                 This example defines the sequence called "fred" as  exactly  those  mes-
+                 sages from "frated" that were dated prior to "friday".[1]
+
+                      _P_i_c_k is normally used as a back-quoted command, for example,
+
+                      scan `pick -from postmaster`
+
+                 Now suppose that the user decides that another command should be issued,
+                 using   exactly   those   messages.    Since,   _p_i_c_k   wasn't   given  a
+                 `-sequence name' argument in this example, the user would end-up  typing
+                 the entire back-quoted command again.  A simpler way is to add a default
+                 sequence name to the .mh_profile.  For example,
+
+                      pick: -seq select -list
+
+                 will tell _p_i_c_k to always define the sequence "select" whenever it's run.
+                 The  `-list'  is necessary since the `-sequence name' switch sets `-nol-
+                 ist' whenever the former is  encountered.   Hence,  this  profile  entry
+                 makes  _p_i_c_k define the "select" sequence and otherwise behave exactly as
+
+
+                    [1]  Of  course, it is much easier to simply use the built-in boolean
+                 operation of _p_i_c_k to get the desired results:
+
+                      pick -from frated -or -from fear -or -from freida -seq sgroup
+
+                 and
+
+                      pick -from frated -and -before friday -seq fred
+
+                 do exactly the same thing as the five commands listed above.  Hence, the
+                 `-nozero'  option  to  _p_i_c_k  is  only  useful to manipulate existing se-
+                 quences.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -172-
+
+
+                 if there was no profile entry at all.
+
+                 _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      The _m_a_r_k command lets the user perform  low-level  manipulation  of
+                 sequences,  and  also  provides  a  well-needed  debug  facility  to the
+                 implementors/developers/maintainers  of  _M_H  (the  _M_H-hacks).   In   the
+                 future,  a user-friendly "front-end" for _m_a_r_k will probably be developed
+                 to give the _M_H user a way to take better  advantage  of  the  underlying
+                 facilities.
+
+                 _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      There are two kinds of sequences:  _p_u_b_l_i_c  sequences,  and  _p_r_i_v_a_t_e
+                 sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H user
+                 that can read that folder and are kept in the .mh_sequences file in  the
+                 folder.   _P_r_i_v_a_t_e  sequences  are  accessible  only  to the _M_H user that
+                 defined those sequences and are kept in the user's _M_H context file.   By
+                 default,  _p_i_c_k  (and  _m_a_r_k )  create  _p_u_b_l_i_c sequences if the folder for
+                 which the sequences are being defined is writable by the _M_H user.   Oth-
+                 erwise,  _p_r_i_v_a_t_e sequences are created.  This can be overridden with the
+                 `-public' and `-nopublic' switches.
+
+                 _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+                      In addition to telling an _M_H command to use  the  messages  in  the
+                 sequence "seen", as in
+
+                      refile seen +old
+
+                 it would be useful to be easily able to tell an _M_H command  to  use  all
+                 messages  _e_x_c_e_p_t  those in the sequence.  One way of doing this would be
+                 to use _m_a_r_k and define the sequence explicitly, as in
+
+                      mark -delete -zero seen -seq notseen
+
+                 which, owing to _m_a_r_k 's cryptic interpretation of `-delete' and `-zero',
+                 defines  the  sequence  "notseen" to be all messages not in the sequence
+                 "seen".  Naturally, anytime the sequence "seen"  is  changed,  "notseen"
+                 will  have  to be updated.  Another way to achieve this is to define the
+                 entry "Sequence-Negation:" in the .mh_profile.  If the entry was
+
+                      Sequence-Negation: not
+
+                 then anytime an _M_H command was given "notseen"  as  a  `msg'  or  `msgs'
+                 argument,  it would substitute all messages that are not a member of the
+                 sequence "seen".  That is,
+
+                      refile notseen +new
+
+                 does just that.  The value of the "Sequence-Negation:" entry in the pro-
+                 file  can  be  any  string.  Hence, experienced users of _M_H do not use a
+
+
+
+
+
+
+
+
+
+
+
+                                                  -173-
+
+
+                 word, but rather a special character which their shell does  not  inter-
+                 pret  (users  of  the  _C_S_h_e_l_l  use a single caret or circumflex (usually
+                 shift-6), while users of the  Bourne  shell  use  an  exclamation-mark).
+                 This is because there is nothing to prevent a user of _M_H from defining a
+                 sequence with this string as its prefix, if the  string  is  nothing  by
+                 letters and digits.  Obviously, this could lead to confusing behavior if
+                 the "Sequence-Negation:" entry leads _M_H to believe  that  two  sequences
+                 are opposites by virtue of their names differing by the prefix string.
+
+                 _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+                      Many times users find themselves issuing a series  of  commands  on
+                 the  same  sequences  of messages.  If the user first defined these mes-
+                 sages as a sequence, then considerable typing may be saved.  If the user
+                 doesn't  have  this  foresight,  _M_H  provides  a  handy way of having _M_H
+                 remember the `msgs' or `msg' argument last given to an _M_H  command.   If
+                 the  entry "Previous-Sequence:" is defined in the .mh_profile, then when
+                 the command finishes, it will define the sequence(s) named in the  value
+                 of  this  entry  as  being  exactly  those messages that were specified.
+                 Hence, a profile entry of
+
+                      Previous-Sequence: pseq
+
+                 directs any _M_H command that accepts a `msg' or `msgs' argument to define
+                 the  sequence  "pseq" as those messages when it finishes.  More than one
+                 sequence name may be placed in this entry, separated with  spaces.   The
+                 one  disadvantage of this approach is that the _M_H progams have to update
+                 the sequence information for the folder each  time  they  run  (although
+                 most  programs read this information, usually only _p_i_c_k and _m_a_r_k have to
+                 write this information out).
+
+                 _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+                      Finally, some users like to distinguish between messages which have
+                 been  previously seen by them.  Both _i_n_c and _s_h_o_w honorthe profile entry
+                 "Unseen-Sequence" to support this activity.   Whenever  _i_n_c  places  new
+                 messages  in  a folder, if the entry "Unseen-Sequence" is defined in the
+                 .mh_profile, then when the command finishes, _i_n_c will add the  new  mes-
+                 sages  to  the  sequence(s)  named in the value of this entry.  Hence, a
+                 profile entry of
+
+                      Unseen-Sequence:  unseen
+
+                 directs _i_n_c to add new messages to the sequence  "unseen".   Unlike  the
+                 behavior  of  the  "Previous-Sequence" entry in the profile however, the
+                 sequence(s) will not be zero'd.
+
+                      Similarly, whenever _s_h_o_w (or _n_e_x_t or  _p_r_e_v )  displays  a  message,
+                 they   remove   those   messages   from   any  sequences  named  by  the
+                 "Unseen-Sequence" entry in the profile.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -174-
+
+
+                 _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+                      There are a number of interesting advanced facilities for the  com-
+                 position of outgoing mail.
+
+
+                 _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+                      The  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,  and  _r_e_p_l  commands  have  two  switches,
+                 `-draftfolder +folder'        and        `-draftmessage msg'.         If
+                 `-draftfolder +folder' is used, these commands are directed to construct
+                 a  draft  message in the indicated folder.  (The "Draft-Folder:" profile
+                 entry may be used to declare a default draft folder for use  with  _c_o_m_p,
+                 _d_i_s_t, _f_o_r_w, and _r_e_p_l) If `-draftmessage msg' is not used, it defaults to
+                 `new' (unless the user invokes _c_o_m_p  with  `-use',  in  which  case  the
+                 default  is  `cur').   Hence, the user may have several message composi-
+                 tions in progress simultaneously.  Now, all of the _M_H tools  are  avail-
+                 able  on  each of the user's message drafts (e.g., _s_h_o_w, _s_c_a_n, _p_i_c_k, and
+                 so on).  If the folder does not exist, the user is asked if it should be
+                 created (just like with _r_e_f_i_l_e ).  Also, the last draft message the user
+                 was composing is known as `cur' in the draft folder.
+
+                      Furthermore, the _s_e_n_d command has these switches as  well.   Hence,
+                 from  the shell, the user can send off whatever drafts desired using the
+                 standard _M_H `msgs' convention with `-draftmessage msgs'.  If  no  `msgs'
+                 are given, it defaults to `cur'.
+
+                      In addition, all five  programs  have  a  `-nodraftfolder'  switch,
+                 which undoes the last occurrence of `-draftfolder folder' (useful if the
+                 latter occurs in the user's _M_H profile).
+
+                      If the user does not give the `-draftfolder +folder'  switch,  then
+                 all  these  commands act ``normally''.  Note that the `-draft' switch to
+                 _s_e_n_d and _s_h_o_w still refers to the file called `draft' in the  user's  _M_H
+                 directory.   In  the interests of economy of expression, when using _c_o_m_p
+                 or _s_e_n_d, the user needn't prefix the draft `msg' or `msgs' with `-draft-
+                 message'.   Both  of these commands accept a `file' or `files' argument,
+                 and they will, if given `-draftfolder +folder' treat these arguments  as
+                 `msg' or `msgs'.[2] Hence,
+
+                      send -draftf +drafts first
+
+                 is the same as
+
+                      send -draftf +drafts -draftm first
+
+
+
+
+                    [2]  This may appear to be inconsistent, at first, but it saves a lot
+                 of typing.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -175-
+
+
+                      To make all this a bit more clear, here are some  examples.   Let's
+                 assume that the following entries are in the _M_H profile:
+
+                      Draft-Folder: +drafts
+                      sendf: -draftfolder +drafts
+
+                 Furthermore, let's assume that the program _s_e_n_d_f is a (symbolic) link in
+                 the user's $HOME/bin/ directory to _s_e_n_d.  Then, any of the commands
+
+                      comp
+                      dist
+                      forw
+                      repl
+
+                 constructs the message draft in the `draft' folder using the `new'  mes-
+                 sage  number.   Furthermore, they each define `cur' in this folder to be
+                 that message draft.  If the user were to use the _q_u_i_t  option  at  `What
+                 now?'  level, then later on, if no other draft composition was done, the
+                 draft could be sent with simply
+
+                      sendf
+
+                 Or, if more editing was required, the draft could be edited with
+
+                      comp -use
+
+                 Instead, if other drafts had been composed in the meantime, so that this
+                 message  draft  was no longer known as `cur' in the `draft' folder, then
+                 the user could _s_c_a_n the folder to see which message draft in the  folder
+                 should be used for editing or sending.  Clever users could even employ a
+                 back-quoted _p_i_c_k to do the work:
+
+                      comp -use `pick +drafts -to bug-mh`
+
+                 or
+
+                      sendf `pick +drafts -to bug-mh`
+
+                 Note that in the _c_o_m_p example, the output from _p_i_c_k must  resolve  to  a
+                 single  message  draft (it makes no sense to talk about composing two or
+                 more drafts with one invocation of _c_o_m_p ).  In  contrast,  in  the  _s_e_n_d
+                 example,  as  many  message  drafts  as  desired  can appear, since _s_e_n_d
+                 doesn't mind sending more than one draft at a time.
+
+                      Note that the argument `-draftfolder +folder' is  not  included  in
+                 the  profile  entry  for  _s_e_n_d,  since  when  _c_o_m_p, et. al., invoke _s_e_n_d
+                 directly, they supply _s_e_n_d with the UNIX pathname of the message  draft,
+                 and  not  a `draftmessage msg' argument.  As far as _s_e_n_d is concerned, a
+                 _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+                      It is important to realize that _M_H treats the draft folder  like  a
+                 standard  _M_H  folder  in nearly all respects.  There are two exceptions:
+
+
+
+
+
+
+
+
+
+
+
+                                                  -176-
+
+
+                 first_____, under no circumstancs will the `-draftfolder folder' switch cause
+                 the named folder to become the current folder.[3] Second______, although  con-
+                 ceptually _s_e_n_d deletes the `msgs' named in the draft folder, it does not
+                 call `delete-prog' to perform the deletion.
+
+
+                 _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e _D_r_a_f_t _E_x_i_s_t_s
+
+                      When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands are  invoked  and  the
+                 draft  you indicated already exists, these programs will prompt the user
+                 for a reponse directing the program's action.  The prompt is
+
+                      Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+                      Disposition?
+
+                 The appropriate responses and their meanings are: replace_______:  deletes  the
+                 draft  and starts afresh; list____: lists the draft; refile______: files the draft
+                 into a folder and starts afresh; and, quit____: leaves the draft intact  and
+                 exits.   In addition, if you specified `-draftfolder folder' to the com-
+                 mand, then one other response will be accepted: new___: finds a new  draft,
+                 just  as  if `-draftmessage new' had been given.  Finally, the _c_o_m_p com-
+                 mand will accept one more response: use___: re-uses the draft, just  as  if
+                 `-use' had been given.
+
+
+                 _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+                      The _p_u_s_h option to the "What now?" query in the _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+                 and  _r_e_p_l  commands,  directs the command to _s_e_n_d the draft in a special
+                 detached fashion, with all normal output discarded.  If _p_u_s_h is used and
+                 the  draft  can not be sent, then _M_H will send the user a message, indi-
+                 cating the name of the draft file, and an explanation of the failure.
+
+                      The user can also invoke _s_e_n_d  from  the  shell  with  the  `-push'
+                 switch, which makes _s_e_n_d act like it had been _p_u_s_h 'd by one of the com-
+                 position commands.
+
+                      By using _p_u_s_h, the user can free the  shell  to  do  other  things,
+                 because  it appears to the shell that the _M_H command has finished.  As a
+                 result the shell will immediately prompt for  another  command,  despite
+                 the  fact  that  the  command is really still running.  Note that if the
+                 user indicates that annotations are to be performed (with `-annotate' to
+
+
+                    [3]  Obviously,  if  the folder appeared in the context of a standard
+                 `+folder' argument to an _M_H program, as in
+
+                      scan +drafts
+
+                 it might become the current folder, depending on the context changes  of
+                 the _M_H program in question.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -177-
+
+
+                 _d_i_s_t, _f_o_r_w, or _r_e_p_l), the annotations will be performed after  the  mes-
+                 sage has been successfully sent.  This action will appear to occur asyn-
+                 chronously.  Obviously, if one of the messages that is to  be  annotated
+                 is  removed  before  the  draft has been successfully sent, then when _M_H
+                 tries to make the annotations, it won't be able to do so.   In  previous
+                 versions of _M_H, this resulted in an error message mysteriously appearing
+                 on the user's terminal.  In _m_h._5 and later  versions,  in  this  special
+                 circumstance, no error will be generated.
+
+                      If send is _p_u_s_h 'd, then the `-forward' switch  is  examined  if  a
+                 failure notice is generated.  If given, then the draft is forwarded with
+                 the failure notice sent to the user.  This allows  rapid  _b_u_r_s_t 'ing  of
+                 the failure notice to retrieve the unsent draft.
+
+
+                 _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+                      By default, the message composition programs call a program  called
+                 _w_h_a_t_n_o_w  before  the initial draft composition.  The _M_H user can specify
+                 any program for this.  Following is some information about  the  default
+                 "What  now?" level.  More detailed information can be found in the _w_h_a_t_-
+                 _n_o_w (1) manual entry.
+
+                      When using the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands at  "What  now?"
+                 level,  the _e_d_i_t, _l_i_s_t, _h_e_a_d_e_r_s, _r_e_f_i_l_e, and (for the _d_i_s_t and _r_e_p_l com-
+                 mands) the _d_i_s_p_l_a_y options will pass on any additional  arguments  given
+                 them to whatever program they invoke.
+
+                      In _m_h._1 (the original RAND _M_H ) and _m_h._2 (the first UCI version  of
+                 _M_H ),  _M_H  used a complicated heuristic to determine if the draft should
+                 be deleted or preserved after an unsuccessful edit.   In  _m_h._3,  _M_H  was
+                 changed to preserve the draft always, since _c_o_m_p, et. al., could usually
+                 look at a draft, apply another set of heuristics, and decide if  it  was
+                 important  or  not.   With the notion of a _d_r_a_f_t _f_o_l_d_e_r, in which one by
+                 default gets a `new' message draft, the edit deletion/preservation algo-
+                 rithm  was re-implemented, to keep the draft folder from being cluttered
+                 with aborted edits.
+
+                      Also, note that by default, if the  draft  cannot  be  successfully
+                 sent,  these  commands  return  to "What now?" level.  But, when _p_u_s_h is
+                 used, this does not happen (obviously).  Hence, if these  commands  were
+                 expected  to  annotate  any messages, this will have to be done by hand,
+                 later on, with the _a_n_n_o command.
+
+                      Finally, if the `-delete' switch is not given to the  _q_u_i_t  option,
+                 then these commands will inform the user of the name of the unsent draft
+                 file.
+
+
+                 _D_i_g_e_s_t_s
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -178-
+
+
+                      The _f_o_r_w command has the beginnings  of  a  digestifying  facility,
+                 with the `-digest list', `-issue number', and `-volume number' switches.
+
+                 If _f_o_r_w is given "list" to the `-digest' switch as the name of the  dis-
+                 cussion  group,  and  the `-issue number' switch is not given, then _f_o_r_w
+                 looks for an entry in the user's _M_H context  called  "_d_i_g_e_s_t-issue-list"
+                 and  increments its value to use as the issue number.  Similarly, if the
+                 `-volume number'  switch   is   not   given,   then   _f_o_r_w   looks   for
+                 "_d_i_g_e_s_t-volume-list"  (but  does  not increment its value) to use as the
+                 volume number.
+
+                 Having calculated the name of  the  digest  and  the  volume  and  issue
+                 numbers, _f_o_r_w will now process the components file using the same format
+                 string mechanism used by _r_e_p_l.  The current `%'-escapes are:
+
+                 _e_s_c_a_p_e  _t_y_p_e     _s_u_b_s_t_i_t_u_t_i_o_n
+                 digest  string   digest name
+                 msg     integer  issue number
+                 cur     integer  volume number
+
+                 In addition, to capture the current date, any of the escapes  valid  for
+                 _d_p (8) are also valid for _f_o_r_w.
+
+                 The default components file used by _f_o_r_w when in digest mode is:
+
+                      From:     %{digest}-Request
+                      To:       %{digest} Distribution: dist-%{digest};
+                      Subject:  %{digest} Digest V%(cur) #%(msg)
+                      Reply-To: %{digest}
+                      --------
+                      %{digest} Digest        %(weekday{date}), %2(mday{date}) %(month{date}) 19%02(year{date})
+                                      Volume %(cur) : Issue %(msg)
+
+                      Today's Topics:
+
+                 Hence, when the `-digest' switch is present, the  first  step  taken  by
+                 _f_o_r_w  is  to  expand the format strings in the component file.  The next
+                 step is to compose the draft using  the  standard  digest  encapsulation
+                 algorithm  (even  putting an "End of list Digest" trailer in the draft).
+                 Once the draft is composed by _f_o_r_w, _f_o_r_w writes out the volume and issue
+                 profile entries for the digest, and then invokes the editor.
+
+                 Naturally,   when   composing   the   draft,   _f_o_r_w   will   honor   the
+                 `-filter filterfile'  switch,  which is given to _m_h_l to filter each mes-
+                 sage being forwarded prior to encapsulation in the draft.  A good filter
+                 file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -179-
+
+
+                      width=80,overflowoffset=10
+                      leftadjust,compress,compwidth=9
+                      Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+                      From:
+                      Subject:
+                      :
+                      body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+                 _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+                      There are two  interesting  facilities  for  manipulating  folders:
+                 relative folder addressing, which allows a user to shorten the typing of
+                 long folder names; and the folder-stack, which permits a user to keep  a
+                 stack of current folders.
+
+
+                 _R_e_l_a_t_i_v_e _F_o_l_d_e_r _A_d_d_r_e_s_s_i_n_g
+
+                      By default, when `+folder' is given, and the  folder  name  is  not
+                 absolute  (does not start with /, ./, or ../), then the UNIX pathname of
+                 the folder is interpreted relative to the user's _M_H directory.  Although
+                 this  mechanism  works  fine  for  top-level folders and their immediate
+                 sub-folders, once the depth of the sub-folder  tree  grows,  it  becomes
+                 rather unwieldly:
+
+                      scan +mh/mh.4/draft/flames
+
+                 is a lot of typing.  _M_H can't do anything  if  the  current  folder  was
+                 "+inbox", but if the current folder was, say, "+mh/mh.4/draft", _M_H has a
+                 short-hand notation to reference a sub-folder  of  the  current  folder.
+                 Using  the  `@folder'  notation,  the  _M_H user can direct any _M_H program
+                 which expects a `+folder' argument to look for the  folder  relative  to
+                 the  current  folder  instead of the user's _M_H directory.  Hence, if the
+                 current folder _w_a_s "+mh/mh.4/draft", then
+
+                      scan @flames
+
+                 would do the trick handily.  In addition,  if  the  current  folder  _w_a_s
+                 "+mh/mh.4/draft",
+
+                      scan @../pick
+
+                 would scan the folder "+mh/mh.4/pick", since, in the  UNIX  fashion,  it
+                 references the folder "pick" which is a sub-folder of the folder that is
+                 the parent of the current folder.  Since most advanced _M_H users seem  to
+                 exhibit a large degree of locality in referencing folders when they pro-
+                 cess mail, this convention should receive a wide range of uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -180-
+
+
+                 _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+                      The _f_o_l_d_e_r-_s_t_a_c_k mechanism in _M_H gives the _M_H user a facility simi-
+                 lar to the _C_S_h_e_l_l 's directory-stack.  Simply put,
+
+                      folder -push +foo
+
+                 makes "foo" the current folder, saving the folder  that  was  previously
+                 the current folder on the _f_o_l_d_e_r-_s_t_a_c_k.  As expected,
+
+                      folder -pop
+
+                 takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and makes it the current folder.  Each
+                 of  these switches lists the _f_o_l_d_e_r-_s_t_a_c_k when they execute.  It is sim-
+                 ple to write a _p_u_s_h_f command as a shell script.  It's one line:
+
+                      exec folder -push $@
+
+                 Probably a better way is to link  _f_o_l_d_e_r  to  the  $HOME/bin/  directory
+                 under the name of _p_u_s_h_f and then add the entry
+
+                      pushf: -push
+
+                 to the .mh_profile.
+
+                      The manual page for _f_o_l_d_e_r discusses the analogy between the _C_S_h_e_l_l
+                 directory stack commands and the switches in _f_o_l_d_e_r which manipulate the
+                 _f_o_l_d_e_r-_s_t_a_c_k.  The _f_o_l_d_e_r command uses the context entry `Folder-Stack:'
+                 to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                Appendix A
+                                             _C_O_M_M_A_N_D _S_U_M_M_A_R_Y
+
+
+
+
+                 ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+                      [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+                 anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+                      [-date] [-nodate] [-text body] [-help]
+
+                 bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+                      [-archive] [-noarchive] [-protocol] [-noprotocol]
+                      [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+                      [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+                      [-host host] [-help]
+
+                 burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+                      [-verbose] [-noverbose] [-help]
+
+                 comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+                      [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+                      [-form formfile] [-use] [-nouse] [-whatnowproc program]
+                      [-nowhatnowproc] [-help]
+
+                 dist [+folder] [msg] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-form formfile] [-inplace]
+                      [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+                 /usr/bs/mh-6.8/lib/fmtdump [-form formatfile] [-format string]
+                      [-help]
+
+                 folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+                      [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+                      [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+                      [-pop] [-help]
+
+                 folders
+
+                 forw [+folder] [msgs] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-filter filterfile]
+                      [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+                      [-mime] [-nomime] [-whatnowproc program] [-nowhatnowproc]
+                      [-help]
+
+
+
+
+
+
+                                             -181-
+
+
+
+
+
+
+
+
+
+
+
+
+                 forw [+folder] [msgs] [-digest list] [-issue number]
+                      [-volume number] [other switches for _f_o_r_w] [-help]
+
+                 inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+                      [-nochangecur] [-file name] [-form formatfile]
+                      [-format string] [-silent] [-nosilent] [-truncate]
+                      [-notruncate] [-width columns] [-host host] [-user user]
+                      [-apop] [-noapop] [-rpop] [-norpop] [-pack file] [-nopack]
+                      [-help]
+
+                 mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+                      [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+                 /usr/bs/mh-6.8/lib/mhl [-bell] [-nobell] [-clear] [-noclear]
+                      [-folder +folder] [-form formfile] [-length lines]
+                      [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+                      [-help]
+
+                 mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+                      [-subject subject]] [-help]
+
+                 mhn [+folder] [msgs] [-part number]... [-type content]...
+                      [-list [-header] [-noheader]
+                             [-realsize] [-norealsize]] [-nolist]
+                      [-show [-serialonly] [-noserialonly]]
+                             [-form formfile]] [-noshow]
+                      [-store [-auto] [-noauto]] [-nostore]
+                      [-verbose] [-noverbose] [-rfc934mode] [-norfc934mode]
+                      [-ebcdic] [-noebcdicsafe]
+                      [-help]
+
+                 mhparam [profile-components] [-components] [-nocomponents] [-all]
+                      [-help]
+
+                 mhpath [+folder] [msgs] [-help]
+
+                 msgchk [-date] [-nodate] [-notify all/mail/nomail]
+                      [-nonotify all/mail/nomail] [-host host] [-user user] [-apop]
+                      [-noapop] [-rpop] [-norpop] [users ...] [-help]
+
+                 msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+                      [-help]
+
+                 next [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+                 packf [+folder] [msgs] [-file name] [-help]
+
+
+
+
+
+
+                                             -182-
+
+
+
+
+
+
+
+
+
+
+
+
+                 pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+                      [-lbrace ... -rbrace] [--component pattern] [-after date]
+                      [-before date] [-datefield field] [-sequence name ...]
+                      [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+                      [-help]
+
+
+                 prev [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+                 prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+                      [-norapid] [-doteof] [-nodoteof] file [-help]
+
+                 /usr/bs/mh-6.8/lib/rcvstore [+folder] [-create] [-nocreate]
+                      [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+                      [-help]
+
+                 refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+                      [-src +folder] [-file file] +folder ...  [-help]
+
+                 repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+                      [-nocc all/to/cc/me] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-editor editor]
+                      [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+                      [-inplace] [-noinplace] [-query] [-noquery]
+                      [-whatnowproc program] [-nowhatnowproc] [-width columns]
+                      [-help]
+
+                 rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+                 rmm [+folder] [msgs] [-help]
+
+                 scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+                      [-format string] [-header] [-noheader] [-width columns]
+                      [-reverse] [-noreverse] [-file filename] [-help]
+
+                 send [-alias aliasfile] [-draft] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+                      [-mime] [-nomime] [-msgid] [-nomsgid] [-push] [-nopush]
+                      [-split seconds] [-verbose] [-noverbose] [-watch] [-nowatch]
+                      [-width columns] [file ...] [-help]
+
+                 show [+folder] [msgs] [-draft] [-header] [-noheader]
+                      [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+                      [-help]
+
+                 sortm [+folder] [msgs] [-datefield field] [-textfield field]
+                      [-notextfield] [-limit days] [-nolimit] [-verbose]
+                      [-noverbose] [-help]
+
+
+
+                                             -183-
+
+
+
+
+
+
+
+
+
+
+
+
+                 vmh [-prompt string] [-vmhproc program] [-novmhproc]
+                      [switches for _v_m_h_p_r_o_c] [-help]
+
+                 whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+                 whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [file] [-help]
+
+                 /usr/bs/mh-6.8/lib/ap [-form formatfile] [-format string]
+                      [-normalize] [-nonormalize] [-width columns] addrs ...
+                      [-help]
+
+                 /usr/bs/mh-6.8/lib/conflict [-mail name] [-search directory]
+                      [aliasfiles ...] [-help]
+
+                 /usr/bs/mh-6.8/lib/dp [-form formatfile] [-format string]
+                      [-width columns] dates ...  [-help]
+
+                 /usr/bs/mh-6.8/lib/install-mh [-auto] [-compat]
+
+                 /usr/bs/mh-6.8/lib/post [-alias aliasfile] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-mime] [-nomime] [-msgid]
+                      [-nomsgid] [-verbose] [-noverbose] [-watch] [-nowatch]
+                      [-width columns] file [-help]
+
+                 /usr/bs/mh-6.8/lib/slocal [address info sender] [-addr address]
+                      [-info data] [-sender sender] [-user username] [-mailbox mbox]
+                      [-file file] [-maildelivery deliveryfile] [-verbose]
+                      [-noverbose] [-debug] [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -184-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                Appendix B
+                                             _M_E_S_S_A_G_E _N_A_M_E _B_N_F
+
+
+
+
+
+                           msgs                  :=  msgspec                |
+                                                     msgs msgspec
+
+                           msgspec               :=  msg                    |
+                                                     msg-range              |
+                                                     msg-sequence           |
+                                                     user-defined-sequence
+
+                           msg                   :=  msg-name               |
+                                                     <number>
+
+                           msg-name              :=  "first"                |
+                                                     "last"                 |
+                                                     "cur"                  |
+                                                     "."                    |
+                                                     "next"                 |
+                                                     "prev"
+
+                           msg-range             :=  msg"-"msg              |
+                                                     "all"
+
+                           msg-sequence          :=  msg":"signed-number
+
+                           signed-number         :=  "+"<number>            |
+                                                     "-"<number>            |
+                                                     <number>
+
+                           user-defined-sequence :=  <alpha>                |
+                                                     <alpha><alphanumeric>*
+
+
+                 Where <number> is a decimal number greater than zero.
+
+                 Msg-range specifies all of the messages in the given range and must  not
+                 be empty.
+
+                 Msg-sequence specifies up to <number> of messages, beginning with  "msg"
+                 (in the case of first, cur, next, or <number>), or ending with "msg" (in
+                 the case of prev or last).  +<number> forces "starting  with  msg",  and
+                 -<number> forces "ending with number".  In all cases, "msg" must exist.
+
+                 User-defined sequences are defined and manipulated  with  the  _p_i_c_k  and
+                 _m_a_r_k commands.
+
+
+
+                                                  -185-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                _R_E_F_E_R_E_N_C_E_S
+
+
+
+                 1.  Crocker, D. H., J. J. Vittal, K. T. Pogran,  and  D.  A.  Henderson,
+                     Jr.,  "Standard  for  the  Format  of  ARPA  Network Text Messages,"
+                     _R_F_C_7_3_3, November 1977.
+
+                 2.  Thompson, K., and D. M. Ritchie,  "The  UNIX  Time-sharing  System,"
+                     _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+                 3.  McCauley, E. J., and P. J. Drongowski, "KSOS-The Design of a  Secure
+                     Operating  System,"  _A_F_I_P_S _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, National Computer
+                     Conference, Vol. 48, 1979, pp. 345-353.
+
+                 4.  Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d _F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l _M_e_s_-
+                     _s_a_g_e _S_y_s_t_e_m, The RAND Corporation, R-2134-ARPA, December 1977.
+
+                 5.  Thompson, K., and D. M. Ritchie, _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th  ed.,
+                     Western  Electric  Company,  May 1975 (available only to UNIX licen-
+                     sees).
+
+                 6. Crocker, D. H., "Standard for the Format of ARPA Internet  Text  Mes-
+                     sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -186-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -i-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                _R_E_A_D _T_H_I_S
+
+
+
+
+                      Although the _M_H system was originally developed by  the  RAND  Cor-
+                 poration,  and is now in the public domain, the RAND Corporation assumes
+                 no responsibility for _M_H or this particular version of _M_H.
+
+                      In addition, the Regents of the University of California issue  the
+                 following disclaimer in regard to the UCI version of _M_H:
+
+                      "Although each program has been tested by its contributor, no  war-
+                      ranty,  express  or  implied,  is  made  by  the contributor or the
+                      University of California, as to the accuracy and functioning of the
+                      program and related program material, nor shall the fact of distri-
+                      bution constitute any  such  warranty,  and  no  responsibility  is
+                      assumed  by the contributor or the University of California in con-
+                      nection herewith."
+
+                      This version of _M_H is in the public domain, and as such, there  are
+                 no  real  restrictions on its use.  The _M_H source code and documentation
+                 have no licensing restrictions whatsoever.  As a courtesy,  the  authors
+                 ask only that you provide appropriate credit to the RAND Corporation and
+                 the University of California for having developed the software.
+
+                      _M_H is a software package that is supported neither by the RAND Cor-
+                 poration nor the University of California.  However, since we do use the
+                 software ourselves and plan to continue using (and  improving)  _M_H,  bug
+                 reports and their associated fixes should be reported back to us so that
+                 we may include them in future releases.  The  current  computer  mailbox
+                 for   _M_H   is   Bug-MH@ICS.UCI.EDU   (in   the   ARPA   Internet),   and
+                 ...!ucbvax!ucivax!bug-mh (UUCP).  Presently, there are two Internet dis-
+                 cussion   groups,   MH-Users@ICS.UCI.EDU   and   MH-Workers@ICS.UCI.EDU.
+                 MH-Workers is for people discussing code changes to _M_H.  MH-Users is for
+                 general  discussion  about  how to use _M_H.  MH-Users is bi-directionally
+                 gatewayed into USENET as comp.mail.mh.
+
+                 _H_O_W _T_O _G_E_T _M_H
+
+                      Since you probably already have _M_H, you may not need to  read  this
+                 unless  you  suspect you have an old version.  There are two ways to get
+                 the latest release:
+
+                      1.  If you can FTP to the  ARPA  Internet,  use  anonymous  FTP  to
+                 ics.uci.edu  [128.195.1.1]  and  retrieve  the file pub/mh/mh-6.8.tar.Z.
+                 This is a tar  image  after  being  run  through  the  compress  program
+                 (approximately  1.8MB).   There  should  also  be  a README file in that
+                 directory which tells what the current release of _M_H is, and how to  get
+                 updates.
+
+
+
+                                                   -i-
+
+
+
+
+
+
+
+
+
+                                                   -ii-
+
+
+                      This tar file is also available on louie.udel.edu [128.175.1.3]  in
+                 portal/mh-6.8.tar.Z.   You  may  also find MH on various other hosts; to
+                 make sure you get the latest version and don't waste your time re-fixing
+                 bugs, it's best to get it from either ics.uci.edu or louie.udel.edu.
+
+                      2.  You can send $75 US to the address below.  This covers the cost
+                 of  a  6250  BPI  9-track magtape, handling, and shipping.  In addition,
+                 you'll get a laser-printed hard-copy of the entire MH documentation set.
+                 Be  sure  to  include your USPS address with your check.  Checks must be
+                 drawn on U.S. funds and should be made payable to:
+
+                           Regents of the University of California
+
+                 The distribution address is:
+
+                           Computing Support Group
+                           Attn: MH distribution
+                           Department of Information and Computer Science
+                           University of California, Irvine
+                           Irvine, CA  92717
+
+                           714/856-7554
+
+                      If you just want the hard-copies of the  documentation,  you  still
+                 have  to  pay  the $75.  The tar image has the documentation source (the
+                 manual is in roff format, but the rest are in TeX  format).   Postscript
+                 formatted  versions  of  the TeX papers are available, as are crude tty-
+                 conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _F_O_R_E_W_O_R_D
+
+
+
+
+                      This document describes the RAND _M_H Message Handling  System.   Its
+                 primary  purpose  is  to  serve as a user's manual.  It has been heavily
+                 based on a previous version of the manual,  prepared  by  Bruce  Borden,
+                 Stockton Gaines, and Norman Shapiro.
+
+                      _M_H is a particularly novel system, and thus it is often more  prone
+                 to  change  than  other  pieces  of  production software.  As such, some
+                 specific points in this manual may not be correct in the future.  In all
+                 cases,  the  on-line  sections  of  this  manual,  available through the
+                 UNIX[1] _m_a_n command, should present the most current information.
+
+                      When reading this document as a user's manual, certain sections are
+                 more  interesting than others.  The Preface and Summary are not particu-
+                 larly interesting to those interested in learning _M_H.  The  Introduction
+                 is slightly more interesting, as it touches upon the organization of the
+                 remainder of this document.  The most useful sections are the  Overview,
+                 Tutorial,  and Detailed Description.  The Overview should be read by all
+                 _M_H users, regardless of their expertise (beginning, novice, advanced, or
+                 hacker).   The  Tutorial  should  be read by all beginning and novice _M_H
+                 users, as it presents a nice description of the _M_H system.  The Detailed
+                 Description  should  be  read by the day-to-day user of _M_H, as it spells
+                 out all of the realities of the _M_H system.  The Advanced  Features  sec-
+                 tion discusses some powerful _M_H capabilities for advanced users.  Appen-
+                 dix A is particularly useful for novices, as it summarizes  the  invoca-
+                 tion syntax of all the _M_H commands.
+
+                      There are also several other documents which may be useful to  you:
+                 _T_h_e  _R_A_N_D  _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is a tutorial for
+                 _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I _B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+                 describes  the  BBoards handling under _M_H; _M_H._5: _H_o_w _t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+                 _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l _g_e_t _s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which  was  presented  at
+                 the  1985  Summer  Usenix Conference and Exhibition in Portland, Oregon;
+                 _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r _A_g_e_n_t, which has been accepted  for  publication
+                 by  Computer  Networks;  _M_Z_n_e_t: _M_a_i_l _S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l _M_i_c_r_o-_C_o_m_p_u_t_e_r
+                 _S_y_s_t_e_m_s, which was presented at the  First  International  Symposium  on
+                 Computer  Message  Systems  in  Nottingham, U.K.; and, _D_e_s_i_g_n _o_f _t_h_e _T_T_I
+                 _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d _M_a_i_l _A_g_e_n_t, which describes  a  proprietary  "trusted"
+                 mail  system  built on _M_H.  There are also documents, mostly specific to
+                 U.C. Irvine which you may find interesting: _M_H _f_o_r _B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+                 _M_M _U_s_e_r_s.  All of these documents exist in the _m_h._6 distribution sent to
+                 your site.  There's also a document, _C_h_a_n_g_e_s _t_o _t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+                 _d_l_i_n_g  _S_y_s_t_e_m:  _M_H._6,  which  describes  user-visible changes made to _M_H
+                 since the last major release.
+
+
+                    [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+                                                  -iii-
+
+
+
+
+
+
+
+
+
+                                                   -iv-
+
+
+                      This manual is very large, as it describes a large, powerful system
+                 in gruesome detail.  The important thing to remember is:
+
+
+                                              _D_O_N'_T _P_A_N_I_C[_2]
+
+
+                 As explained in the tutorial, you really need to know only 5 commands to
+                 handle most of your mail.
+
+                      Very advanced users may wish to consult _T_h_e _R_A_N_D  _M_H  _M_e_s_s_a_g_e  _H_a_n_-
+                 _d_l_i_n_g  _S_y_s_t_e_m:  _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also present in the _m_h._6
+                 distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                             _A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+                      The _M_H system described herein is based on  the  original  RAND  _M_H
+                 system.   It  has  been  extensively  developed (perhaps too much so) by
+                 Marshall T. Rose and John L. Romine at  the  University  of  California,
+                 Irvine.  Einar A. Stefferud, Jerry N. Sweet, and Terry P. Domae provided
+                 numerous suggestions to improve the UCI version of  _M_H.   Of  course,  a
+                 large  number  of  people have helped _M_H along.  The list of ``_M_H immor-
+                 tals'' is too long to list here.  However, Van Jacobson deserves a  spe-
+                 cial  acknowledgement for his tireless work in improving the performance
+                 of _M_H.  Some programs have been speeded-up by a factor of 10 or 20.  All
+                 of  users  of  _M_H,  everywhere,  owe  a special thanks to Van.  For this
+                 release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes and other changes.  A handful
+                 of  courageous  _M_H-_W_o_r_k_e_r_s volunteered to beta-test these changes; their
+                 help is particularly appreciated.
+
+                      This manual is based on the original _M_H manual written at  RAND  by
+                 Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -v-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _P_R_E_F_A_C_E
+
+
+
+
+                      This report describes a system for dealing with messages  transmit-
+                 ted  on  a  computer.  Such messages might originate with other users of
+                 the same computer or might come from an outside source through a network
+                 to  which the user's computer is connected.  Such computer-based message
+                 systems are becoming increasingly widely used, both within  and  outside
+                 the Department of Defense.
+
+                      The message handling system _M_H was developed for two reasons.   One
+                 was  to  investigate some research ideas concerning how a message system
+                 might take advantage  of  the  architecture  of  the  UNIX  time-sharing
+                 operating  system  for Digital Equipment Corporation PDP-11 and VAX com-
+                 puters, and the special features of UNIX's command-level interface  with
+                 the  user  (the  "shell").  The other reason was to provide a better and
+                 more adaptable base than that of conventional designs on which to  build
+                 a  command and control message system.  The effort has succeeded in both
+                 regards, although this report mainly describes the message system itself
+                 and how it fits in with UNIX.
+
+                      The present report  should  be  of  interest  to  three  groups  of
+                 readers.   First, it is a complete reference manual for the users of _M_H.
+                 Second, it should be of interest to those who have a  general  knowledge
+                 of  computer-based message systems, both in civilian and military appli-
+                 cations.  Finally, it should be of interest to  those  who  build  large
+                 subsystems  that  interface  with  users,  since  it  illustrates  a new
+                 approach to such interfaces.
+
+                      The original _M_H system was developed  by  Bruce  Borden,  using  an
+                 approach  suggested  by  Stockton  Gaines  and Norman Shapiro.  Valuable
+                 assistance was provided by Phyllis Kantar in the  later  stages  of  the
+                 system's  implementation.   Several  colleagues contributed to the ideas
+                 included in this system, particularly Robert Anderson and David Crocker.
+                 In  addition,  valuable  experience  in  message systems, and a valuable
+                 source of ideas, was available to us in the form of a  previous  message
+                 system for UNIX called MS, designed at RAND by David Crocker.
+
+                      This report was originally prepared as part  of  the  RAND  project
+                 entitled "Data Automation Research", sponsored by Project AIR FORCE.
+
+
+
+
+
+
+
+
+
+
+
+                                                   -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _S_U_M_M_A_R_Y
+
+
+
+
+                      Electronic communication of text messages is becoming  commonplace.
+                 Computer-based  message systems-software packages that provide tools for
+                 dealing with messages-are used in many contexts.  In particular, message
+                 systems  are  becoming increasingly important in command and control and
+                 intelligence applications.
+
+                      This report describes a message handling system  called  _M_H.   This
+                 system  provides  the  user with tools to compose, send, receive, store,
+                 retrieve, forward, and reply to messages.  _M_H has been built on the UNIX
+                 time-sharing  system,  a  popular operating system developed for the DEC
+                 PDP-11 and VAX classes of computers.
+
+                      A complete description of _M_H is given for users of the system.  For
+                 those who do not intend to use the system, this description gives a gen-
+                 eral idea of what a message system is like.  The  system  involves  some
+                 new ideas about how large subsystems can be constructed.
+
+                      The interesting and unusual features of _M_H include  the  following:
+                 The  user command interface to _M_H is the UNIX "shell" (the standard UNIX
+                 command interpreter).  Each separable  component  of  message  handling,
+                 such  as  message composition or message display, is a separate command.
+                 Each program is driven from and  updates  a  private  user  environment,
+                 which  is  stored  as  a file between program invocations.  This private
+                 environment also contains information  to  "custom  tailor"  _M_H  to  the
+                 individual's  tastes.   _M_H  stores each message as a separate file under
+                 UNIX, and it utilizes the tree-structured UNIX file system  to  organize
+                 groups  of  files  within separate directories or "folders".  All of the
+                 UNIX facilities for dealing with files and directories, such  as  renam-
+                 ing,  copying, deleting, cataloging, off-line printing, etc., are appli-
+                 cable to messages and directories of messages (folders).   Thus,  impor-
+                 tant capabilities needed in a message system are available in _M_H without
+                 the need (often seen in other message systems) for code that  duplicates
+                 the facilities of the supporting operating system.  It also allows users
+                 familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _C_O_N_T_E_N_T_S
+
+
+
+
+                 READ THIS .........................................................    i
+
+                 FOREWORD ..........................................................  iii
+
+                 ACKNOWLEDGMENTS ...................................................    v
+
+                 PREFACE ...........................................................   vi
+
+                 SUMMARY ...........................................................  vii
+
+                 Section
+
+                    1.  INTRODUCTION ...............................................    1
+
+                    2.  OVERVIEW ...................................................    4
+
+                    3.  TUTORIAL ...................................................    7
+
+                    4.  DETAILED DESCRIPTION .......................................   10
+                      THE USER PROFILE .............................................   10
+                      MESSAGE NAMING ...............................................   13
+                      OTHER MH CONVENTIONS .........................................   14
+                      MH COMMANDS ..................................................   16
+                         ALI .......................................................   17
+                         ANNO ......................................................   19
+                         BBC .......................................................   21
+                         BBOARDS ...................................................   24
+                         BURST .....................................................   26
+                         COMP ......................................................   28
+                         DIST ......................................................   30
+                         FOLDER ....................................................   33
+                         FORW ......................................................   37
+                         INC .......................................................   42
+                         MARK ......................................................   45
+                         MHL .......................................................   47
+                         MHMAIL ....................................................   52
+                         MHN .......................................................   54
+                         MHOOK .....................................................   70
+                         MHPARAM ...................................................   72
+                         MHPATH ....................................................   74
+                         MSGCHK ....................................................   77
+                         MSH .......................................................   79
+                         NEXT ......................................................   83
+                         PACKF .....................................................   84
+                         PICK ......................................................   85
+                         PREV ......................................................   90
+                         PROMPTER ..................................................   91
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                         RCVSTORE ..................................................   94
+                         REFILE ....................................................   96
+                         REPL ......................................................   98
+                         RMF .......................................................  102
+                         RMM .......................................................  104
+                         SCAN ......................................................  106
+                         SEND ......................................................  109
+                         SHOW ......................................................  112
+                         SLOCAL ....................................................  115
+                         SORTM .....................................................  120
+                         VMH .......................................................  122
+                         WHATNOW ...................................................  124
+                         WHOM ......................................................  127
+                      MORE DETAILS .................................................  129
+                         MH-ALIAS ..................................................  130
+                         MH-FORMAT .................................................  134
+                         MH-MAIL ...................................................  143
+                         MH-PROFILE ................................................  147
+                         MH-SEQUENCE ...............................................  155
+                         AP ........................................................  159
+                         CONFLICT ..................................................  161
+                         DP ........................................................  163
+                         FMTDUMP ...................................................  165
+                         INSTALL-MH ................................................  166
+                         POST ......................................................  167
+
+                    5.  REPORTING PROBLEMS .........................................  169
+
+                    6.  ADVANCED FEATURES ..........................................  170
+                      USER-DEFINED SEQUENCES .......................................  170
+                         Pick and User-Defined Sequences ...........................  170
+                         Mark and User-Defined Sequences ...........................  172
+                         Public and Private User-Defined Sequences .................  172
+                         Sequence Negation .........................................  172
+                         The Previous Sequence .....................................  173
+                         The Unseen Sequence .......................................  173
+                      COMPOSITION OF MAIL ..........................................  174
+                         The Draft Folder ..........................................  174
+                         What Happens if the Draft Exists ..........................  176
+                         The Push Option at What now? Level ........................  176
+                         Options at What now? Level ................................  177
+                         Digests ...................................................  178
+                      FOLDER HANDLING ..............................................  179
+                         Relative Folder Addressing ................................  179
+                         The Folder-Stack ..........................................  180
+
+                 Appendix
+                    A.  Command Summary ............................................  181
+                    B.  Message Name BNF ...........................................  185
+
+                 REFERENCES ........................................................  186
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         THE RAND MH
+
+
+                                      MESSAGE HANDLING
+
+
+                                           SYSTEM:
+
+
+                                        USER'S MANUAL
+
+
+
+
+
+
+                                         UCI Version
+
+
+
+
+
+                                      Marshall T. Rose
+
+                                       John L. Romine
+
+
+
+
+                               Based on the original manual by
+
+                                 Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+                                      December 14, 1992
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         6.6 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/MH.pdf b/docs/historical/MH.pdf
new file mode 100644
index 0000000..1a460cc
Binary files /dev/null and b/docs/historical/MH.pdf differ
diff --git a/docs/historical/MH.txt b/docs/historical/MH.txt
new file mode 100644
index 0000000..1c25514
--- /dev/null
+++ b/docs/historical/MH.txt
@@ -0,0 +1,11880 @@
+
+
+
+
+
+
+
+
+                                            _d_i_s_c_a_r_d _t_h_i_s _p_a_g_e
+
+
+
+
+                                               The RAND _M_H
+                                         Message Handling System:
+                                              User's Manual
+
+                                               UCI Version
+
+
+                                            November 30, 1993
+                                              6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                             _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+                      Although people can travel cross-country in  hours  and  can  reach
+                 others by telephone in seconds, communications still depend heavily upon
+                 paper, most of which is distributed through the mails.
+
+                      There are several major reasons for this  continued  dependence  on
+                 written  documents.   First,  a  written  document  may be proofread and
+                 corrected prior to its distribution, giving the author complete  control
+                 over  his  words.   Thus,  a written document is better than a telephone
+                 conversation in this respect.  Second, a carefully written  document  is
+                 far  less  likely to be misinterpreted or poorly translated than a phone
+                 conversation.  Third, a  signature  offers  reasonable  verification  of
+                 authorship, which cannot be provided with media such as telegrams.
+
+                      However, the need for fast____,  accurate,  and  reproducible  document
+                 distribution is obvious.  One solution in widespread use is the telefax.
+                 Another that is rapidly gaining popularity is  electronic  mail.   Elec-
+                 tronic  mail is similar to telefax in that the data to be sent are digi-
+                 tized, transmitted via phone lines, and turned back into a  document  at
+                 the  receiver.   The  advantage of electronic mail is in its compression
+                 factor.  Whereas a telefax must scan a page in very fine lines and  send
+                 all  of the black and white information, electronic mail assigns charac-
+                 ters fixed codes which can be transmitted as a few bits of  information.
+                 Telefax  presently  has the advantage of being able to transmit an arbi-
+                 trary page, including pictures, but electronic mail is beginning to deal
+                 with  this  problem.   Electronic mail also integrates well with current
+                 directions  in  office  automation,  allowing  documents  prepared  with
+                 sophisticated  equipment  at  one  site  to  be  quickly transferred and
+                 printed at another site.
+
+                      Currently, most electronic mail is intraorganizational,  with  mail
+                 transfer  remaining within one computer.  As computer networking becomes
+                 more common, however, it is becoming more feasible to  communicate  with
+                 anyone whose computer can be linked to your own via a network.
+
+                      The pioneering efforts on general-purpose electronic mail  were  by
+                 organizations using the DoD ARPAnet[1].  The capability to send messages
+                 between computers existed before the ARPAnet was developed, but  it  was
+                 used  only in limited ways.  With the advent of the ARPAnet, tools began
+                 to be developed which made it convenient for  individuals  or  organiza-
+                 tions  to distribute messages over broad geographic areas, using diverse
+                 computer facilities.  The interest and activity in message  systems  has
+                 now  reached  such proportions that steps have been taken within the DoD
+                 to coordinate and unify the development  of  military  message  systems.
+                 The  use  of electronic mail is expected to increase dramatically in the
+                 next few years.  The utility of such systems in the command and  control
+                 and  intelligence environments is clear, and applications in these areas
+
+
+
+
+
+
+
+
+
+
+
+                                                   -2-
+
+
+                 will probably lead the way.  As the costs for sending and handling elec-
+                 tronic messages continue their rapid decrease, such uses can be expected
+                 to spread rapidly into other areas and, of course, will not  be  limited
+                 to the DoD.
+
+                      A message system provides tools that  help  users  (individuals  or
+                 organizations)  deal  with  messages  in various ways.  Messages must be
+                 composed, sent, received, stored, retrieved, forwarded, and replied  to.
+                 Today's  best  interactive  computer  systems provide a variety of word-
+                 processing and information handling capabilities.  The message  handling
+                 facilities  should be well integrated with the rest of the system, so as
+                 to be a graceful extension of overall system capability.
+
+                      The message system described in this report, _M_H, provides  most  of
+                 the  features that can be found in other message systems and also incor-
+                 porates some new ones.  It has been built on the UNIX time-sharing  sys-
+                 tem[2],  a  popular  operating  system  for the DEC PDP-11[1] and VAX-11
+                 classes of computers.  A "secure" operating system similar  to  UNIX  is
+                 currently being developed[3], and that system will also run _M_H.
+
+                      This report provides a complete description  of  _M_H  and  thus  may
+                 serve  as  a  user's  manual,  although  parts  of the report will be of
+                 interest to non-users as well.  Sections  2  and  3,  the  Overview  and
+                 Tutorial,  present  the key ideas of _M_H and will give those not familiar
+                 with message systems an idea of what such systems are like.
+
+                      _M_H consists of a set of commands which use some special  files  and
+                 conventions.   The final section is divided into three parts.  The first
+                 part covers the information a user needs to know in addition to the com-
+                 mands.   Then, each of the _M_H commands is described in detail.  Finally,
+                 other obscure details are revealed.  A summary of the commands is  given
+                 in  Appendix A, and the syntax of message sequences is given in Appendix
+                 B.
+
+                      A novel approach has been taken in the design of  _M_H.   Instead  of
+                 creating  a large subsystem that appears as a single command to the user
+                 (such as MS[4]), _M_H is a collection of separate commands which  are  run
+                 as  separate  programs.   The file and directory system of UNIX are used
+                 directly.  Messages are stored as individual files (datasets), and  col-
+                 lections  of them are grouped into directories.  In contrast, most other
+                 message systems store messages in a complicated data structure within  a
+                 monolithic file.  With the _M_H approach, UNIX commands can be interleaved
+                 with commands invoking the  functions  of  the  message  handler.   Con-
+                 versely, existing UNIX commands can be used in connection with messages.
+                 For example, all the usual UNIX editing, text-formatting,  and  printing
+                 facilities  can  be applied directly to individual messages.  MH, there-
+                 fore, consists of a relatively small amount of new code; it makes exten-
+                 sive  use  of  other  UNIX software to provide the capabilities found in
+
+
+                    [1] PDP and VAX are trademarks of Digital Equipment Corporation.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -3-
+
+
+                 other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                               _2. _O_V_E_R_V_I_E_W
+
+
+
+
+
+                      There are three main aspects  of  _M_H :   the   way   messages   are
+                 stored  (the  message  database),  the user's profile (which directs how
+                 certain actions of the message handler take place), and the commands for
+                 dealing with messages.
+
+                      Under _M_H, each message is stored as a separate file.   A  user  can
+                 take  any  action  with a message that he could with an ordinary file in
+                 UNIX.  A UNIX directory in which messages are stored is called a folder.
+                 Each  folder  contains  some  standard  entries  to support the message-
+                 handling functions.  The messages in  a  folder  have  numerical  names.
+                 These  folders (directories) are entries in a particular directory path,
+                 described in the user profile, through which _M_H can find  message  fold-
+                 ers.   Using  the UNIX "link" facility, it is possible for one copy of a
+                 message to be "filed" in more than one folder, providing a message index
+                 facility.   Also, using the UNIX tree-structured file system, it is pos-
+                 sible to have a folder within a folder,  nested  arbitrarily  deep,  and
+                 have the full power of the _M_H commands available.
+
+                      Each user of _M_H has a user profile, a file in  his  $HOME  (initial
+                 login)  directory  called  ._m_h__p_r_o_f_i_l_e.   This  profile contains several
+                 pieces of information used by the _M_H commands: a path name to the direc-
+                 tory  that  contains  the  message folders and parameters that tailor _M_H
+                 commands to the individual user's requirements.  There is  also  another
+                 file,  called  the  user  context, which contains information concerning
+                 which folder the user last referenced (the "current" folder).   It  also
+                 contains most of the necessary state information concerning how the user
+                 is dealing with his messages, enabling _M_H to be implemented as a set  of
+                 individual  UNIX commands, in contrast to the usual approach of a monol-
+                 ithic subsystem.
+
+                      In _M_H, incoming mail is appended to the end of a file in  a  system
+                 spooling  area  for  the user.  This area is called the mail drop direc-
+                 tory, and the file is called the user's mail drop.   Normally  when  the
+                 user  logins  in, s/he is informed of new mail (or the _M_H program _m_s_g_c_h_k
+                 may be run).  The user adds the new messages to his/her collection of _M_H
+                 messages  by  invoking  the  command _i_n_c.  The _i_n_c (incorporate) command
+                 adds the new messages to a folder called "inbox", assigning  them  names
+                 which  are  consecutive  integers starting with the next highest integer
+                 available in inbox.  _i_n_c also produces a _s_c_a_n summary  of  the  messages
+                 thus  incorporated.   A  folder can be compacted into a single file, for
+                 easy storage, by using the  _p_a_c_k_f  command.   Also,  messages  within  a
+                 folder can be sorted by date and time with the _s_o_r_t_m command.
+
+
+                      There are four commands for examining the  messages  in  a  folder:
+                 _s_h_o_w,  _p_r_e_v,  _n_e_x_t,  and _s_c_a_n.  The _s_h_o_w command displays a message in a
+
+                                                   -4-
+
+
+
+
+
+
+
+
+
+                                                   -5-
+
+
+                 folder, _p_r_e_v displays the message preceding  the  current  message,  and
+                 _n_e_x_t  displays  the  message following the current message.  _M_H lets the
+                 user choose the program that displays individual  messages.   A  special
+                 program,  _m_h_l,  can  be used to display messages according to the user's
+                 preferences.  The _s_c_a_n command summarizes the messages in a folder, nor-
+                 mally  producing  one line per message, showing who the message is from,
+                 the date, the subject, etc.
+
+                      The user may move a message from one folder  to  another  with  the
+                 command  _r_e_f_i_l_e.   Messages may be removed from a folder by means of the
+                 command _r_m_m.  In addition, a user may query what the current  folder  is
+                 and may specify that a new folder become the current folder, through the
+                 command _f_o_l_d_e_r.  All folders may be summarized with the _f_o_l_d_e_r_s command.
+                 A  message  folder (or subfolder) may be removed by means of the command
+                 _r_m_f.
+
+                      A set of messages based on content may be selected by  use  of  the
+                 command  _p_i_c_k.   This  command searches through messages in a folder and
+                 selects those that match a given set of criteria.   These  messages  are
+                 then  bound  to  a  "sequence" name for use with other _M_H commands.  The
+                 _m_a_r_k command manipulates these sequences.
+
+                      There are five commands enabling the user to  create  new  messages
+                 and  send them: _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l, and _s_e_n_d.  The _c_o_m_p command pro-
+                 vides the facility for the user to compose a new message; _d_i_s_t redistri-
+                 butes  mail  to  additional addressees; _f_o_r_w enables the user to forward
+                 messages; and _r_e_p_l facilitates the generation of a reply to an  incoming
+                 message.   The  last three commands may optionally annotate the original
+                 message.  Messages may be arbitrarily annotated with the  _a_n_n_o  command.
+                 Once  a  draft has been constructed by one of the four above composition
+                 programs, a user-specifiable program is run to query the user as to  the
+                 disposition of the draft prior to sending.  _M_H provides the simple _w_h_a_t_-
+                 _n_o_w program to start users off.  If a message is not  sent  directly  by
+                 one  of these commands, it may be sent at a later time using the command
+                 _s_e_n_d.  _M_H allows the use of any UNIX editor when  composing  a  message.
+                 For rapid entry, a special editor, _p_r_o_m_p_t_e_r, is provided.  For programs,
+                 a special mail-sending program, _m_h_m_a_i_l, is provided.
+
+                      _M_H supports a personal aliasing  facility  which  gives  users  the
+                 capability  to  considerably  shorten  address typein and use meaningful
+                 names for addresses.  The _a_l_i program can be used to query _M_H as to  the
+                 expansion of a list of aliases.  After composing a message, but prior to
+                 sending, the _w_h_o_m command can be used to determine exactly who a message
+                 would go to.
+
+                      _M_H provides a natural interface for telling the  user's  shell  the
+                 names  of  _M_H  messages  and  folders.  The _m_h_p_a_t_h program achieves this
+                 capability.
+
+                      Finally, _M_H supports the UCI BBoards facility.  _b_b_c can be used  to
+                 query  the  status  of a group of BBoards, while _m_s_h can be used to read
+                 them.  The _b_u_r_s_t command can be used to "shred" digests of messages into
+
+
+
+
+
+
+
+
+
+
+
+                                                   -6-
+
+
+                 individual messages.
+
+                      All of the elements summarized above are described in  more  detail
+                 in  the  following sections.  Many of the normal facilities of UNIX pro-
+                 vide additional capabilities for dealing with messages in various  ways.
+                 For  example,  it  is  possible  to  print  messages on the line-printer
+                 without requiring any additional code within _M_H .  Using  standard  UNIX
+                 facilities, any terminal output can be redirected to a file for repeated
+                 or future viewing.  In general, the flexibility and capabilities of  the
+                 UNIX  interface  with the user are preserved as a result of the integra-
+                 tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                               _3. _T_U_T_O_R_I_A_L
+
+
+
+
+
+                      This tutorial provides a brief introduction to the _M_H commands.  It
+                 should  be sufficient to allow the user to read his mail, do some simple
+                 manipulations of it, and create and send messages.
+
+                      A message has two major pieces:  the header and the body.  The body
+                 consists  of the text of the message (whatever you care to type in).  It
+                 follows the header and is separated from it by an empty line.  (When you
+                 compose  a  message, the form that appears on your terminal shows a line
+                 of dashes after the header.  This is for convenience and is replaced  by
+                 an  empty  line  when  the  message is sent.)  The header is composed of
+                 several components, including the subject of the message and the  person
+                 to whom it is addressed.  Each component starts with a name and a colon;
+                 components must not start with a blank.  The text of the  component  may
+                 take  more  than  one line, but each continuation line must start with a
+                 blank.  Messages typically have "To:", "cc:", and "Subject:" components.
+                 When  composing  a  message, you should include the "To:" and "Subject:"
+                 components; the "cc:" (for people you want to send  copies  to)  is  not
+                 necessary.
+
+                      The basic _M_H commands are _i_n_c, _s_c_a_n, _s_h_o_w, _n_e_x_t, _p_r_e_v,  _r_m_m,  _c_o_m_p,
+                 and _r_e_p_l.  These are described below.
+
+                 _i_n_c
+
+                      When you get the message "You have mail",  type  the  command  _i_n_c.
+                 You will get a "scan listing" such as:
+
+                      7+   7/13  Cas      revival of measurement work
+                      8   10/ 9  Norm     NBS people and publications
+                      9   11/26  To:norm  question <<Are there any functions
+
+                      This shows the messages you received since the last time  you  exe-
+                 cuted  this  command (_i_n_c adds these new messages to your inbox folder).
+                 You can see this list again, plus a list of any other messages you have,
+                 by using the _s_c_a_n command.
+
+                 _s_c_a_n
+
+                      The scan listing shows the message number, followed by the date and
+                 the  sender.   (If  you  are the sender, the addressee in the "To:" com-
+                 ponent is displayed.  You may send yourself a message by including  your
+                 name  among  the "To:" or "cc:" addressees.) It also shows the message's
+                 subject; if the subject is short, the first part of the body of the mes-
+                 sage is included after the characters <<.
+
+
+
+                                                   -7-
+
+
+
+
+
+
+
+
+
+                                                   -8-
+
+
+                 _s_h_o_w
+
+                      This command shows the current message, that is, the first  one  of
+                 the  new messages after an _i_n_c.  If the message is not specified by name
+                 (number), it is generally the last message referred to by an _M_H command.
+                 For example,
+
+
+                      _s_h_o_w 5      will show message 5.
+
+
+                      You can use the show command to copy a message or print a message.
+
+
+                      _s_h_o_w > _x    will copy the message to file x.
+                      _s_h_o_w | _l_p_r  will print the message, using the _l_p_r command.
+                      _n_e_x_t        will show the message that follows the current message.
+                      _p_r_e_v        will show the message previous to the current message.
+                      _r_m_m         will remove the current message.
+                      _r_m_m _3       will remove message 3.
+
+
+                 _c_o_m_p
+
+                      The _c_o_m_p command puts you in the editor to write or edit a message.
+                 Fill  in or delete the "To:", "cc:", and "Subject:" fields, as appropri-
+                 ate, and type the body of the message.  Then exit normally from the edi-
+                 tor.   You will be asked "What now?".  Type a carriage return to see the
+                 options.  Typing send will cause the message to  be  sent;  typing  quit
+                 will cause an exit from _c_o_m_p, with the message draft saved.
+
+                      If you quit without sending the message, it will be saved in a file
+                 called  <name>/Mail/draft  (where  <name> is your $HOME directory).  You
+                 can resume editing the message later with "comp -use"; or you  can  send
+                 the message later, using the _s_e_n_d command.
+
+                 _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+                      This command uses a different editor and is  useful  for  preparing
+                 "quick  and  dirty"  messages.  It prompts you for each component of the
+                 header.  Type the information for that component,  or  type  a  carriage
+                 return to omit the component.  After that, type the body of the message.
+                 Backspacing is the only form of editing allowed with this editor.   When
+                 the  body is complete, type a carriage return followed by <EOT> (usually
+                 <CTRL-D>).  This completes the initial preparation of the message;  from
+                 then on, use the same procedures as with _c_o_m_p (above).
+
+                 _r_e_p_l
+                 _r_e_p_l n
+
+                      This command makes up an initial message form with a header that is
+                 appropriate  for  replying  to  an  existing message.  The message being
+
+
+
+
+
+
+
+
+
+
+
+                                                   -9-
+
+
+                 answered is the current message if no message number is mentioned, or  n
+                 if a number is specified.  After the header is completed, you can finish
+                 the message as in _c_o_m_p (above).
+
+                      This is enough information to get you going using  _M_H.   There  are
+                 more commands, and the commands described here have more features.  Sub-
+                 sequent sections explain _M_H in complete detail.   The  system  is  quite
+                 powerful  if you want to use its sophisticated features, but the forego-
+                 ing commands suffice for sending and receiving messages.
+
+                      There are numerous additional capabilities you may wish to explore.
+                 For  example, the _p_i_c_k command will select a subset of messages based on
+                 specified criteria such as sender and/or subject.   Groups  of  messages
+                 may  be  designated, as described in Sec. IV, under Message Naming.  The
+                 file ._m_h__p_r_o_f_i_l_e can be used to tailor your use of the message system to
+                 your needs and preferences, as described in Sec. IV, under The User Pro-
+                 file.  In general, you may  learn  additional  features  of  the  system
+                 selectively,  according  to  your requirements, by studying the relevant
+                 sections of this manual.  There is no need to learn all the  details  of
+                 the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         _4. _D_E_T_A_I_L_E_D _D_E_S_C_R_I_P_T_I_O_N
+
+
+
+
+
+                      This section describes the _M_H system in detail, including the  com-
+                 ponents  of  the  user  profile, the conventions for message naming, and
+                 some of the other _M_H conventions.  Readers who  are  generally  familiar
+                 with  computer  systems  will  be  able  to  follow the principal ideas,
+                 although some details may be meaningful  only  to  those  familiar  with
+                 UNIX.
+
+
+                 _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+                      The first time an _M_H command is issued by a new  user,  the  system
+                 prompts for a "Path" and creates an _M_H "profile".
+
+                      Each _M_H user has a profile which contains tailoring information for
+                 each  individual  program.   Other  profile  entries control the _M_H path
+                 (where folders and special files are kept), folder and  message  protec-
+                 tions,  editor  selection,  and  default  arguments for each _M_H program.
+                 Each user of _M_H also has a context file  which  contains  current  state
+                 information for the _M_H package (the location of the context file is kept
+                 in the user's _M_H directory, or may be named in the user profile).   When
+                 a  folder  becomes the current folder, it is recorded in the user's con-
+                 text.  (Other state information is kept in the  context  file,  see  the
+                 manual  entry for _m_h-_p_r_o_f_i_l_e (5) for more details.) In general, the term
+                 "profile entry" refer to entries in either the profile or context  file.
+                 Users of _M_H needn't worry about the distinction, _M_H handles these things
+                 automatically.
+
+                      The _M_H profile is stored in the  file  ._m_h__p_r_o_f_i_l_e  in  the  user's
+                 $HOME directory[1].  It has the format of a message  without  any  body.
+                 That is, each profile entry is on one line, with a keyword followed by a
+                 colon (:) followed by text particular to the keyword.
+                 =>   _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t _h_a_v_e _b_l_a_n_k _l_i_n_e_s.
+                 The keywords may have any combination of upper and lower case.  (See the
+                 information of _m_h-_m_a_i_l later on in this manual for a description of mes-
+                 sage formats.)
+
+                      For the average _M_H user, the only profile entry  of  importance  is
+                 "Path".   Path  specifies  a  directory  in which _M_H folders and certain
+                 files such as "draft" are found.  The argument to this keyword must be a
+                 legal  UNIX  path that names an existing directory.  If this path is not
+                 absolute (i.e., does not begin with a / ), it will be presumed to  start
+
+
+                    [1] By defining the envariable $MH, you can specify an alternate pro-
+                 file to be used by _M_H commands.
+
+
+                                                   -10-
+
+
+
+
+
+
+
+
+
+                                                   -11-
+
+
+                 from the user's $HOME directory.   All  folder  and  message  references
+                 within _M_H will relate to this path unless full path names are used.
+
+                      Message protection defaults to 644, and folder protection  to  711.
+                 These  may  be  changed  by  profile  entries "Msg-Protect" and "Folder-
+                 Protect", respectively.  The argument to  these  keywords  is  an  octal
+                 number which is used as the UNIX file mode[2].
+
+                      When an _M_H program starts running, it looks through the user's pro-
+                 file for an entry with a keyword matching the program's name.  For exam-
+                 ple, when _c_o_m_p is run, it looks for a "comp" profile entry.  If  one  is
+                 found,  the text of the profile entry is used as the default switch set-
+                 ting until all defaults are overridden by explicit  switches  passed  to
+                 the     program     as    arguments.     Thus    the    profile    entry
+                 "comp: -form standard.list"  would  direct  _c_o_m_p   to   use   the   file
+                 "standard.list"  as the message skeleton.  If an explicit form switch is
+                 given to the _c_o_m_p command, it will override the switch obtained from the
+                 profile.
+
+                      In UNIX, a program may exist under several names, either by linking
+                 or  aliasing.   The actual invocation name is used by an _M_H program when
+                 scanning for its profile defaults[3].  Thus, each _M_H  program  may  have
+                 several  names by which it can be invoked, and each name may have a dif-
+                 ferent set of default switches.  For example, if _c_o_m_p is invoked by  the
+                 name  _i_c_o_m_p, the profile entry "icomp" will control the default switches
+                 for this invocation of the  _c_o_m_p  program.   This  provides  a  powerful
+                 definitional facility for commonly used switch settings.
+
+                      The default editor for editing within _c_o_m_p, _r_e_p_l, _f_o_r_w,  and  _d_i_s_t,
+                 is  usually  _p_r_o_m_p_t_e_r, but might be something else at your site, such as
+                 /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e.  A different editor may be used by specifying the
+                 profile  entry  "Editor:  ".  The argument to "Editor" is the name of an
+                 executable program or shell command file which  can  be  found  via  the
+                 user's  $PATH defined search path, excluding the current directory.  The
+                 "Editor:"  profile  specification  may  in  turn  be  overridden  by   a
+                 `-editor <editor>'  profile  switch associated with _c_o_m_p, _r_e_p_l, _f_o_r_w, or
+                 _d_i_s_t.  Finally, an explicit editor switch specified with  any  of  these
+                 four commands will have ultimate precedence.
+
+                      During message composition, more than one editor may be used.   For
+                 example,  one  editor  (such  as _p_r_o_m_p_t_e_r ) may be used initially, and a
+
+
+                    [2] See _c_h_m_o_d (1) in the _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+                    [3] Unfortunately, the shell does not preserve  aliasing  information
+                 when  calling  a program, hence if a program is invoked by an alias dif-
+                 ferent than its name, the program will examine  the  profile  entry  for
+                 it's name, not the alias that the user invoked it as.  The correct solu-
+                 tion is to create a (soft) link in your $_H_O_M_E/_b_i_n directory  to  the  _M_H
+                 program  of  your choice.  By giving this link a different name, you can
+                 use an alternate set of defaults for the command.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -12-
+
+
+                 second editor may be invoked later to revise the message being  composed
+                 (see  the discussion of _c_o_m_p in Section 5 for details).  A profile entry
+                 "<lasteditor>-next: <editor>" specifies the name of  the  editor  to  be
+                 used  after  a  particular  editor.  Thus "comp: -e prompter" causes the
+                 initial text  to  be  collected  by  _p_r_o_m_p_t_e_r,  and  the  profile  entry
+                 "prompter-next: ed"  names  ed  as the editor to be invoked for the next
+                 round of editing.
+
+                      Some of the _M_H commands, such as _s_h_o_w, can be used on message fold-
+                 ers owned by others, if those folders are readable.  However, you cannot
+                 write in someone else's folder.  All the _M_H command actions not  requir-
+                 ing write permission may be used with a "read-only" folder.
+
+                      Table 1 lists examples of some of  the  currently  defined  profile
+                 entries, typical arguments, and the programs that reference the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -13-
+
+
+                                                 Table 1
+
+                                            PROFILE COMPONENTS
+                          ______________________________________________________
+
+                                                       _M_H Programs that
+                          Keyword and Argument          use Component______________________________________________________
+
+                          Path: Mail                   All
+                          Current-Folder: inbox        Most
+                          Editor: /usr/ucb/ex          _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                          Inbox: inbox                 _i_n_c, _r_m_f
+                          Msg-Protect: 644             _i_n_c
+                          Folder-Protect: 711          _i_n_c, _p_i_c_k, _r_e_f_i_l_e
+                          <program>: default switches  All
+                          prompter-next: ed            _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l
+                          ______________________________________________________
+
+
+                      Path should______ be present.  Current-Folder is maintained automatically
+                 by many _M_H commands (see the Context sections of the individual commands
+                 in Sec. IV).  All other entries are optional, defaulting to  the  values
+                 described above.
+
+
+                 _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+                      Messages may be referred to explicitly or implicitly when using  _M_H
+                 commands.   A formal syntax of message names is given in Appendix B, but
+                 the following description should be sufficient for most _M_H users.   Some
+                 details  of  message  naming  that  apply  only  to certain commands are
+                 included in the description of those commands.
+
+                      Most of the _M_H commands accept arguments  specifying  one  or  more
+                 folders,  and  one  or more messages to operate on.  The use of the word
+                 "msg" as an argument to a command means that exactly  one  message  name
+                 may  be  specified.   A  message name may be a number, such as 1, 33, or
+                 234, or it may be one of the  "reserved"  message  names:  first,  last,
+                 prev,  next,  and  cur.   (As a shorthand, a period (.) is equivalent to
+                 cur.) The meanings of these names are straightforward:  "first"  is  the
+                 first  message  in the folder; "last" is the last message in the folder;
+                 "prev" is the message  numerically  previous  to  the  current  message;
+                 "next"  is  the message numerically following the current message; "cur"
+                 (or ".") is the current message in the folder.  In addition, _M_H supports
+                 user-defined-sequences; see the description of the _m_a_r_k command for more
+                 information.
+
+                      The default in commands that take a "msg" argument is always "cur".
+
+                      The word "msgs" indicates that several messages may  be  specified.
+                 Such  a specification consists of several message designations separated
+                 by spaces.  A message designation is either a message name or a  message
+
+
+
+
+
+
+
+
+
+
+
+                                                   -14-
+
+
+                 range.   A  message  range is a specification of the form name1-name2 or
+                 name1:n, where name1 and name2 are message names and n  is  an  integer.
+                 The  first  form  designates  all  the  messages  from  name1  to  name2
+                 inclusive; this must be a non-empty range.  The second form specifies up
+                 to  n messages, starting with name1 if name1 is a number, or first, cur,
+                 or next, and ending with name1 if name1 is last or prev.  This interpre-
+                 tation  of  n  is  overridden if n is preceded by a plus sign or a minus
+                 sign; +n always means up to n  messages  starting  with  name1,  and  -n
+                 always  means  up  to n messages ending with name1.  Repeated specifica-
+                 tions of the same message have the same effect as a single specification
+                 of the message.  Examples of specifications are:
+
+
+                     1 5 7-11 22
+                     first 6 8 next
+                     first-10
+                     last:5
+
+
+                      The message name "all" is a shorthand for "first-last",  indicating
+                 all of the messages in the folder.
+
+                      In commands that accept "msgs" arguments, the default is either cur
+                 or all, depending on which makes more sense.
+
+                      In all of the _M_H commands, a plus sign preceding an argument  indi-
+                 cates  a folder name.  Thus, "+inbox" is the name of the user's standard
+                 inbox.  If an explicit folder argument is given to  an  _M_H  command,  it
+                 will  become the current folder (that is, the "Current-Folder:" entry in
+                 the user's profile will be changed to this folder).  In the case of  the
+                 _r_e_f_i_l_e  command,  which  can  have multiple output folders, a new source
+                 folder  (other  than  the  default  current  folder)  is  specified   by
+                 `-src +folder'.
+
+
+                 _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+                      One very powerful feature of _M_H is that  the  _M_H  commands  may  be
+                 issued  from any current directory, and the proper path to the appropri-
+                 ate folder(s) will be taken from the user's profile.  If the _M_H path  is
+                 not  appropriate for a specific folder or file, the automatic prepending
+                 of the _M_H path can be avoided by beginning a folder or file name with /,
+                 or  with  ./  or  ../ component.  Thus any specific absolute path may be
+                 specified along with any path relative to the current working directory.
+
+                      Arguments to the various programs may be given in any  order,  with
+                 the exception of a few switches whose arguments must follow immediately,
+                 such as `-src +folder' for _r_e_f_i_l_e.
+
+                      Whenever an _M_H command prompts the user, the valid options will  be
+                 listed  in  response to a <RETURN>.  (The first of the listed options is
+                 the default if end-of-file is encountered, such as from a command file.)
+
+
+
+
+
+
+
+
+
+
+
+                                                   -15-
+
+
+                 A  valid  response  is  any  _u_n_i_q_u_e  abbreviation  of  one of the listed
+                 options.
+
+                      Standard UNIX documentation conventions are used in this report  to
+                 describe  _M_H  command  syntax.  Arguments enclosed in brackets ([ ]) are
+                 optional; exactly one of the arguments enclosed within braces ({ }) must
+                 be specified, and all other arguments are required.  The use of ellipsis
+                 dots (...) indicates zero or more repetitions of the previous item.  For
+                 example,  "+folder  ..." would indicate that one or more "+folder" argu-
+                 ments is required and "[+folder ...]" indicates that 0 or more "+folder"
+                 arguments may be given.
+
+                      _M_H departs from UNIX standards by using switches  that  consist  of
+                 more  than  one  character,  e.g. `-header'.  To minimize typing, only a
+                 unique abbreviation of a switch need  be  typed;  thus,  for  `-header',
+                 `-hea'  is probably sufficient, depending on the other switches the com-
+                 mand accepts.  Each _M_H program accepts the switch `-help' (which must be
+                 spelled  out  fully)  and  produces  a  syntax description and a list of
+                 switches.  In the list of switches, parentheses indicate required  char-
+                 acters.   For  example,  all  `-help' switches will appear as "-(help)",
+                 indicating that no abbreviation is accepted.  Furthermore,  the  `-help'
+                 switch tells the version of the _M_H program you invoked.
+
+                      Many _M_H switches have both on and off forms, such as `-format'  and
+                 `-noformat'.  In many of the descriptions which follow, only one form is
+                 defined; the other form, often used to nullify profile switch  settings,
+                 is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -16-
+
+
+                 _M_H _C_O_M_M_A_N_D_S
+
+                      The _M_H package comprises several programs:
+
+                      ali (1)        - list mail aliases
+                      anno (1)       - annotate messages
+                      bbc (1)        - check on BBoards
+                      bboards (1)    - the UCI BBoards facility
+                      burst (1)      - explode digests into messages
+                      comp (1)       - compose a message
+                      dist (1)       - redistribute a message to additional addresses
+                      folder (1)     - set/list current folder/message
+                      folders (1)    - list all folders
+                      forw (1)       - forward messages
+                      inc (1)        - incorporate new mail
+                      mark (1)       - mark messages
+                      mhl (1)        - produce formatted listings of MH messages
+                      mhmail (1)     - send or read mail
+                      mhook (1)      - MH receive-mail hooks
+                      mhparam (1)    - print MH profile components
+                      mhpath (1)     - print full pathnames of MH messages and folders
+                      msgchk (1)     - check for messages
+                      msh (1)        - MH shell (and BBoard reader)
+                      next (1)       - show the next message
+                      packf (1)      - compress a folder into a single file
+                      pick (1)       - select messages by content
+                      prev (1)       - show the previous message
+                      prompter (1)   - prompting editor front end
+                      rcvstore (1)   - incorporate new mail asynchronously
+                      refile (1)     - file messages in other folders
+                      repl (1)       - reply to a message
+                      rmf (1)        - remove folder
+                      rmm (1)        - remove messages
+                      scan (1)       - produce a one line per message scan listing
+                      send (1)       - send a message
+                      show (1)       - show (list) messages
+                      slocal (1)     - special local mail delivery
+                      sortm (1)      - sort messages
+                      vmh (1)        - visual front-end to MH
+                      whatnow (1)    - prompting front-end for send
+                      whom (1)       - report to whom a message would go
+
+
+                      These programs are described below.  The form of  the  descriptions
+            conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            ALI(1)                            -17-                            ALI(1)
+
+
+            _N_A_M_E
+                 ali - list mail aliases
+
+            _S_Y_N_O_P_S_I_S
+                 ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+                      [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_l_i searches the named mail alias  files  for  each  of  the  given
+                 _a_l_i_a_s_e_s.   It  creates  a  list of addresses for those _a_l_i_a_s_e_s, and
+                 writes that list on standard output.   If  the  `-list'  option  is
+                 specified,  each address appears on a separate line; otherwise, the
+                 addresses are separated by commas and printed on as  few  lines  as
+                 possible.
+
+                 The `-user' option directs _a_l_i to  perform  its  processing  in  an
+                 inverted  fashion: instead of listing the addresses that each given
+                 alias expands to, _a_l_i will list the aliases  that  expand  to  each
+                 given  address.   If the `-normalize' switch is given, _a_l_i will try
+                 to track down the official hostname of the address.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read.  Each _a_l_i_a_s is processed as described in _m_h-_a_l_i_a_s (5).
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /etc/passwd                         List of users
+                 /etc/group                          List of groups
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Aliasfile:           For a default alias file
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-alias /usr/local/lib/mh/MailAliases'
+                 `-nolist'
+                 `-nonormalize'
+                 `-nouser'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ALI(1)                            -18-                            ALI(1)
+
+
+            _B_u_g_s
+                 The `-user' option with `-nonormalize' is not entirely accurate, as
+                 it  does  not replace local nicknames for hosts with their official
+                 site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ANNO(1)                           -19-                           ANNO(1)
+
+
+            _N_A_M_E
+                 anno - annotate messages
+
+            _S_Y_N_O_P_S_I_S
+                 anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+                      [-date] [-nodate] [-text body] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_n_n_o annotates the specified messages in the named folder using the
+                 field  and body.  Annotation is optionally performed by _d_i_s_t, _f_o_r_w,
+                 and _r_e_p_l, to keep track of your distribution of, forwarding of, and
+                 replies  to  a  message.   By using _a_n_n_o, you can perform arbitrary
+                 annotations of your own.  Each message selected will  be  annotated
+                 with the lines
+
+                     field: date
+                     field: body
+
+                 The `-nodate' switch inhibits the date annotation, leaving only the
+                 body  annotation.   The  `-inplace'  switch causes annotation to be
+                 done in place in order to preserve links to the annotated message.
+
+                 The field specified should be a valid 822-style message field name,
+                 which  means  that  it  should consist of alphanumerics (or dashes)
+                 only.  The body specified is arbitrary text.
+
+                 If a `-component field' is not specified when _a_n_n_o is invoked, _a_n_n_o
+                 will prompt the user for the name of field for the annotation.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 dist (1), forw (1), repl (1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noinplace'
+                 `-date'
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            ANNO(1)                           -20-                           ANNO(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -21-                            BBC(1)
+
+
+            _N_A_M_E
+                 bbc - check on BBoards
+
+            _S_Y_N_O_P_S_I_S
+                 bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+                      [-archive] [-noarchive] [-protocol] [-noprotocol]
+                      [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+                      [-norcfile] [-file BBoardsfile] [-user BBoardsuser] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _b_b_c is a BBoard reading/checking program  that  interfaces  to  the
+                 BBoard channel.
+
+                 The _b_b_c program has three action switches which direct  its  opera-
+                 tion:
+
+                 The `-read' switch invokes the _m_s_h program on  the  named  _B_B_o_a_r_d_s.
+                 If  you  also  specify the `-archive' switch, then  _b_b_c will invoke
+                 the _m_s_h program on the  archives  of  the  named  _B_B_o_a_r_d_s.   If  no
+                 _B_B_o_a_r_d_s   are   given  on  the  command  line,  and  you  specified
+                 `-archive', _b_b_c will not read your  `bboards'  profile  entry,  but
+                 will read the archives of the "system" _B_B_o_a_r_d instead.
+
+                 The `-check' switch types out  status  information  for  the  named
+                 _B_B_o_a_r_d_s.   _b_b_c  can  print one of several messages depending on the
+                 status of both the BBoard and the user's reading  habits.  As  with
+                 each  of these messages, the number given is the item number of the
+                 last item placed in the BBoard.  This number (which  is  marked  in
+                 the  messages  as the "BBoard-Id") is ever increasing.  Hence, when
+                 _b_b_c says "n items", it really means that the highest  BBoard-Id  is
+                 "n".   There  may,  or may not actually be "n" items in the BBoard.
+                 Some common messages are:
+
+                      BBoard -- n items unseen
+                           This message tells how many items the user  has  not  yet
+                           seen.  When invoked with the `-quiet' switch, this is the
+                           only informative line that _b_b_c will possibly print out.
+
+                      BBoard -- empty
+                           The BBoard is empty.
+
+                      BBoard -- n items (none seen)
+                           The BBoard has items in it, but the user hasn't seen any.
+
+                      BBoard -- n items (all seen)
+                           The BBoard is non-empty, and the user has seen everything
+                           in it.
+
+                      BBoard -- n items seen out of m
+                           The BBoard has at most m-n items that the  user  has  not
+                           seen.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -22-                            BBC(1)
+
+
+                 The `-topics' switch directs _b_b_c to print  three  items  about  the
+                 named _B_B_o_a_r_d_s: it's official name, the number of items present, and
+                 the date and time of the last update.  If  no  _B_B_o_a_r_d_s  are  named,
+                 then  all  BBoards  are listed.  If the `-verbose' switch is given,
+                 more information is output.
+
+                 The `-quiet' switch specifies that  _b_b_c  should  be  silent  if  no
+                 _B_B_o_a_r_d_s  are  found  with  new  information.  The `-verbose' switch
+                 specifies that _b_b_c is to consider you to be interested  in  _B_B_o_a_r_d_s
+                 that you've already seen everything in.
+
+                 To override the default _m_s_h_p_r_o_c and  the  profile  entry,  use  the
+                 `-mshproc program' switch.  Any arguments not understood by _b_b_c are
+                 passed to this program.  The `-protocol' switch tells _b_b_c that your
+                 _m_s_h_p_r_o_c  knows  about  the  special _b_b_c protocol for reporting back
+                 information.  _m_s_h (1), the default _m_s_h_p_r_o_c, knows all about this.
+
+                 The `-file BBoardsfile' switch tells  _b_b_c  to  use  a  non-standard
+                 _B_B_o_a_r_d_s  file  when  performing  its  calculations.  Similarly, the
+                 `-user BBoardsuser' switch tells _b_b_c to use  a  non-standard  user-
+                 name.   Both  of  these  switches  are  useful  for debugging a new
+                 _B_B_o_a_r_d_s or _P_O_P file.
+
+                 The ._b_b_r_c file in the user's $HOME directory is used to keep  track
+                 of what messages have been read.  The `-rcfile rcfile' switch over-
+                 rides the use of ._b_b_r_c for this purpose.  If the value given to the
+                 switch  is  not absolute, (i.e., does not begin with a / ), it will
+                 be presumed to start from the current working directory.   If  this
+                 switch  is not given (or the `-norcfile' switch is given), then _b_b_c
+                 consults the envariable $MHBBRC, and honors it similarly.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 $HOME/.bbrc                         BBoard "current" message information
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 bboards:             To specify interesting BBoards
+                 mshproc:             Program to read a given BBoard
+
+
+            _S_e_e _A_l_s_o
+                 bbl(1), bboards(1), msh(1)
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBC(1)                            -23-                            BBC(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-read'
+                 `-noarchive'
+                 `-protocol'
+                 `bboards' defaults to "system"
+                 `-file /usr/spool/bboards/BBoards'
+                 `-user bboards'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The `-user' switch takes effect only if  followed  by  the  `-file'
+                 switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(1)                        -24-                        BBOARDS(1)
+
+
+            _N_A_M_E
+                 bboards - the UCI BBoards facility
+
+            _S_Y_N_O_P_S_I_S
+                 bbc [-check] [-read] bboards ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The home directory of _b_b_o_a_r_d_s is where the BBoard system  is  kept.
+                 This documentation describes some of the nuances of the BBoard sys-
+                 tem.
+
+                 BBoards, BBoard-IDs
+                      A BBoard is just a file containing a group of messages  relat-
+                      ing  to the same topic.  These files live in the ~bboards home
+                      directory.  Each message in a BBoard file has  in  its  header
+                      the  line  "BBoard-Id:  n",  where "n" is an ascending decimal
+                      number.  This id-number  is  unique  for  each  message  in  a
+                      BBoards  file.   It  should  NOT  be confused with the message
+                      number of a message, which can change as messages are  removed
+                      from the BBoard.
+
+                 BBoard Handling
+                      To read BBoards, use the _b_b_c and _m_s_h programs.  The  _m_s_h  com-
+                      mand  is  a  monolithic  program  which contains all the func-
+                      tionality of _M_H in a single program.  The `-check'  switch  to
+                      _b_b_c  lets  you check on the status of BBoards, and the `-read'
+                      switch tells _b_b_c to invoke _m_s_h to read those BBoards.
+
+                 Creating a BBoard
+                      Both public, and private BBoards are supported.   Contact  the
+                      mail  address  _P_o_s_t_M_a_s_t_e_r  if  you'd  like  to  have  a BBoard
+                      created.
+
+                 BBoard addresses
+                      Each BBoard has associated with it 4 addresses, these are (for
+                      the ficticious BBoard called ``hacks''):
+                        hacks : The Internet wide distribution list.
+                        dist-hacks : The local BBoard.
+                        hacks-request : The people responsible for the BBoard at the
+                             Internet level.
+                        local-hacks-request : The people responsible for the  BBoard
+                             locally.
+
+            _F_i_l_e_s
+                $HOME/.mh_profile                   The user profile
+                $HOME/.bbrc                         BBoard information
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BBOARDS(1)                        -25-                        BBOARDS(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 bboards:             To specify interesting BBoards
+                 mshproc:             Program to read a given BBoard
+
+
+            _S_e_e _A_l_s_o
+                bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 The default bboard is "system"
+
+
+            _C_o_n_t_e_x_t
+                None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BURST(1)                          -26-                          BURST(1)
+
+
+            _N_A_M_E
+                 burst - explode digests into messages
+
+            _S_Y_N_O_P_S_I_S
+                 burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+                      [-verbose] [-noverbose] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _B_u_r_s_t considers the specified messages in the named  folder  to  be
+                 Internet digests, and explodes them in that folder.
+
+                 If `-inplace' is given, each digest is replaced by  the  "table  of
+                 contents"  for  the digest (the original digest is removed).  _B_u_r_s_t
+                 then renumbers all of the messages  following  the  digest  in  the
+                 folder  to  make room for each of the messages contained within the
+                 digest.  These messages are placed immediately after the digest.
+
+                 If `-noinplace' is given, each digest is  preserved,  no  table  of
+                 contents  is produced, and the messages contained within the digest
+                 are placed at the end of the folder.  Other messages are  not  tam-
+                 pered with in any way.
+
+                 The `-quiet' switch directs _b_u_r_s_t to be silent about reporting mes-
+                 sages that are not in digest format.
+
+                 The `-verbose' switch directs _b_u_r_s_t to tell the  user  the  general
+                 actions that it is taking to explode the digest.
+
+                 It turns out that _b_u_r_s_t works equally well  on  forwarded  messages
+                 and  blind-carbon-copies  as on Internet digests, provided that the
+                 former two were generated by _f_o_r_w or _s_e_n_d.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Msg-Protect:         To set mode when creating a new message
+
+
+            _S_e_e _A_l_s_o
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+                 inc(1), msh(1), pack(1)
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            BURST(1)                          -27-                          BURST(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noinplace'
+                 `-noquiet'
+                 `-noverbose'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  If  `-in-
+                 place'  is  given, then the first message burst becomes the current
+                 message.  This leaves the context ready for a _s_h_o_w of the table  of
+                 contents  of the digest, and a _n_e_x_t to see the first message of the
+                 digest.  If `-noinplace' is given, then the first message extracted
+                 from  the  first  digest  burst  becomes the current message.  This
+                 leaves the context in a similar, but not identical,  state  to  the
+                 context achieved when using `-inplace'.
+
+
+            _B_u_g_s
+                 The _b_u_r_s_t program enforces a limit on the number of messages  which
+                 may be _b_u_r_s_t from a single message.  This number is on the order of
+                 1000 messages.  There is usually no limit on the number of messages
+                 which may reside in the folder after the _b_u_r_s_ting.
+
+                 Although _b_u_r_s_t uses a sophisticated algorithm  to  determine  where
+                 one  encapsulated message ends and another begins, not all digesti-
+                 fying programs  use  an  encapsulation  algorithm.   In  degenerate
+                 cases, this usually results in _b_u_r_s_t finding an encapsulation boun-
+                 dary prematurely and splitting a single encapsulated  message  into
+                 two or more messages.  These erroneous digestifying programs should
+                 be fixed.
+
+                 Furthermore, any text which appears  after  the  last  encapsulated
+                 message  is not placed in a seperate message by _b_u_r_s_t.  In the case
+                 of digestified messages, this text is usally  an  "End  of  digest"
+                 string.   As  a result of this possibly un-friendly behavior on the
+                 part of _b_u_r_s_t, note that when the `-inplace' option is  used,  this
+                 trailing  information  is lost.  In practice, this is not a problem
+                 since correspondents usually place remarks in  text  prior  to  the
+                 first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            COMP(1)                           -28-                           COMP(1)
+
+
+            _N_A_M_E
+                 comp - compose a message
+
+            _S_Y_N_O_P_S_I_S
+                 comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+                      [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+                      [-form formfile] [-use] [-nouse] [-whatnowproc program]
+                      [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _C_o_m_p is used to create a new message to be  mailed.   It  copies  a
+                 message form to the draft being composed and then invokes an editor
+                 on the draft (unless `-noedit' is given, in which case the  initial
+                 edit is suppressed).
+
+                 The default message form contains the following elements:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 If the file named "components" exists in the user's  MH  directory,
+                 it  will  be  used  instead  of  this  form.  The file specified by
+                 `-form formfile' will be used if given.  You may  also  start  _c_o_m_p
+                 using the contents of an existing message as the form.  If you sup-
+                 ply either a `+folder' or `msg' argument, that message will be used
+                 as  the  form.   You  may  not supply both a `-form formfile' and a
+                 `+folder' or `msg' argument.  The line of dashes or  a  blank  line
+                 must be left between the header and the body of the message for the
+                 message to be identified properly when it is sent  (see  _s_e_n_d (1)).
+                 The  switch  `-use'  directs  _c_o_m_p  to  continue editing an already
+                 started message.  That is, if a _c_o_m_p (or _d_i_s_t, _r_e_p_l, or  _f_o_r_w )  is
+                 terminated without sending the draft, the draft can be edited again
+                 via "comp -use".
+
+                 If the draft already exists, _c_o_m_p will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _c_o_m_p, leaving the
+                 draft intact; replace will replace  the  existing  draft  with  the
+                 appropriate  form;  list  will  display the draft; use will use the
+                 draft for further composition; and  refile +folder  will  file  the
+                 draft  in  the  given  folder,  and  give  you a new draft with the
+                 appropriate form.  (The `+folder' argument to refile is required.)
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 The `-file file' switch says to use the named file as  the  message
+                 draft.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            COMP(1)                           -29-                           COMP(1)
+
+
+                 The `-editor editor' switch indicates the editor  to  use  for  the
+                 initial  edit.   Upon exiting from the editor, _c_o_m_p will invoke the
+                 _w_h_a_t_n_o_w program.  See _w_h_a_t_n_o_w (1) for  a  discussion  of  available
+                 options.   The invocation of this program can be inhibited by using
+                 the `-nowhatnowproc' switch.  (In truth of fact, it is the  _w_h_a_t_n_o_w
+                 program  which  starts  the  initial edit.  Hence, `-nowhatnowproc'
+                 will prevent any edit from occurring.)
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/components        The message skeleton
+                 or <mh-dir>/components              Rather than the standard skeleton
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/draft                      The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to the current message
+                 `-nodraftfolder'
+                 `-nouse'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _c_o_m_p  won't  run
+                 it.
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -30-                           DIST(1)
+
+
+            _N_A_M_E
+                 dist - redistribute a message to additional addresses
+
+            _S_Y_N_O_P_S_I_S
+                 dist [+folder] [msg] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-form formfile] [-inplace]
+                      [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _D_i_s_t is similar to _f_o_r_w.  It prepares  the  specified  message  for
+                 redistribution to addresses that (presumably) are not on the origi-
+                 nal address list.
+
+                 The default message form contains the following elements:
+
+                      Resent-To:
+                      Resent-cc:
+
+                 If the file named "distcomps" exists in the user's MH directory, it
+                 will be used instead of this form.  In either case, the file speci-
+                 fied by `-form formfile' will be used if given.  The form used will
+                 be prepended to the message being resent.
+
+                 If the draft already exists, _d_i_s_t will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _d_i_s_t, leaving the
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 Only   those   addresses   in   "Resent-To:",   "Resent-cc:",   and
+                 "Resent-Bcc:"  will  be sent.  Also, a "Resent-Fcc: folder" will be
+                 honored (see _s_e_n_d (1)).  Note that with _d_i_s_t, the draft should con-
+                 tain  only  "Resent-xxx:"  fields and no body.  The headers and the
+                 body of the original message are copied to the draft when the  mes-
+                 sage  is sent.  Use care in constructing the headers for the redis-
+                 tribution.
+
+                 If the `-annotate' switch is given, the  message being  distributed
+                 will be annotated with the lines:
+
+                      Resent: date
+                      Resent: addrs
+
+                 where each address list contains as many lines as  required.   This
+                 annotation  will  be done only if the message is sent directly from
+                 _d_i_s_t.  If the message is not  sent  immediately  from  _d_i_s_t,  "comp
+                 -use"  may be used to re-edit and send the constructed message, but
+                 the annotations won't take place.   The  '-inplace'  switch  causes
+                 annotation  to  be  done in place in order to preserve links to the
+                 annotated message.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -31-                           DIST(1)
+
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.   Note that while in the editor, the message being resent
+                 is available through a link named "@" (assuming the  default  _w_h_a_t_-
+                 _n_o_w_p_r_o_c ).   In  addition,  the  actual  pathname of the message is
+                 stored in the envariable $editalt, and the pathname of  the  folder
+                 containing the message is stored in the envariable $mhfolder.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _d_i_s_t will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/distcomps         The message skeleton
+                 or <mh-dir>/distcomps               Rather than the standard skeleton
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/draft                      The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 fileproc:            Program to refile the message
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to cur
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noinplace'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  mes-
+                 sage distributed will become the current message.
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DIST(1)                           -32-                           DIST(1)
+
+
+            _H_i_s_t_o_r_y
+                 _D_i_s_t originally used headers of the form "Distribute-xxx:"  instead
+                 of "Resent-xxx:".  In order to conform with the ARPA Internet stan-
+                 dard, RFC-822, the "Resent-xxx:"  form  is  now  used.   _D_i_s_t  will
+                 recognize  "Distribute-xxx:" type headers and automatically convert
+                 them to "Resent-xxx:".
+
+
+            _B_u_g_s
+                 _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check the message  being  distributed  for
+                 adherence  to the transport standard, but _p_o_s_t called by _s_e_n_d does.
+                 The _p_o_s_t program will balk (and rightly  so)  at  poorly  formatted
+                 messages, and _d_i_s_t won't correct things for you.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _d_i_s_t uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _d_i_s_t  won't  run
+                 it.
+
+                 If your current working directory is not writable, the  link  named
+                 "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -33-                         FOLDER(1)
+
+
+            _N_A_M_E
+                 folder, folders - set/list current folder/message
+
+            _S_Y_N_O_P_S_I_S
+                 folder [+folder] [msg] [-all] [-create] [-nocreate] [-print]
+                      [-fast] [-nofast] [-header] [-noheader] [-recurse]
+                      [-norecurse] [-total] [-nototal] [-list] [-nolist] [-push]
+                      [-pop] [-pack] [-nopack] [-verbose] [-noverbose] [-help]
+
+                 folders
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Since the _M_H environment is the shell, it is easy to lose track  of
+                 the  current  folder  from  day  to  day.  When _f_o_l_d_e_r is given the
+                 `-print' switch (the default), _f_o_l_d_e_r will list the current folder,
+                 the number of messages in it, the range of the messages (low-high),
+                 and the current message within the  folder,  and  will  flag  extra
+                 files if they exist.  An example of this summary is:
+
+                 inbox+            has  16 messages (  3- 22); cur=  5.
+
+                 If a `+folder' and/or `msg' are specified,  they  will  become  the
+                 current  folder  and/or  message.   By comparison, when a `+folder'
+                 argument is given, this corresponds to  a  "cd"  operation  in  the
+                 _s_h_e_l_l;  when  no  `+folder'  argument  is  given,  this corresponds
+                 roughly to a "pwd" operation in the _s_h_e_l_l.
+
+                 If the specified (or default) folder  doesn't  exist,  the  default
+                 action  is  to  query  the  user as to whether the folder should be
+                 created; when standard input is not a tty, the answer to the  query
+                 is assumed to be "yes".
+
+                 Specifying `-create'  will  cause  _f_o_l_d_e_r  to  create  new  folders
+                 without any query.  (This is the easy way to create an empty folder
+                 for use later.) Specifying `-nocreate' will cause  _f_o_l_d_e_r  to  exit
+                 without creating a non-existant folder.
+
+              _M_u_l_t_i_p_l_e _F_o_l_d_e_r_s
+
+                 Specifying `-all' will produce a summary line  for  each  top-level
+                 folder  in  the  user's  MH  directory, sorted alphabetically.  (If
+                 _f_o_l_d_e_r is invoked by a  name  ending  with  "s"  (e.g.,  _f_o_l_d_e_r_s ),
+                 `-all'  is  assumed).   Specifying `-recurse' with `-all' will also
+                 produce a line for all sub-folders.  These folders are all preceded
+                 by  the read-only folders, which occur as "atr-cur-" entries in the
+                 user's _M_H context.  For example,
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -34-                         FOLDER(1)
+
+
+                 Folder               # of messages ( range )  cur msg (other files)
+                 /fsd/rs/m/tacc    has  35 messages (  1- 35); cur= 23.
+                 /rnd/phyl/Mail/EP has  82 messages (  1-108); cur= 82.
+                 ff                has  no messages.
+                 inbox+            has  16 messages (  3- 22); cur=  5.
+                 mh                has  76 messages (  1- 76); cur= 70.
+                 notes             has   2 messages (  1-  2); cur=  1.
+                 ucom              has 124 messages (  1-124); cur=  6; (others).
+                           TOTAL=      339 messages in 7 folders
+
+                 The "+" after inbox indicates that it is the current  folder.   The
+                 "(others)"  indicates that the folder `ucom' has files which aren't
+                 messages.  These files may either be  sub-folders,  or  files  that
+                 don't belong under the MH file naming scheme.
+
+                 The header is output if either a `-all' or a  `-header'  switch  is
+                 specified; it is suppressed by `-noheader'.  A `-total' switch will
+                 produce only the summary line.
+
+                 If `-fast' is given, only the folder name (or names in the case  of
+                 `-all')  will  be listed.  (This is faster because the folders need
+                 not be read.)
+
+                 If a `+folder' is given along with the `-all' switch, _f_o_l_d_e_r  will,
+                 in addition to setting the current folder, list the top-level fold-
+                 ers for the current folder (with `-norecurse')  or  list  all  sub-
+                 folders under the current folder recursively (with `-recurse').  In
+                 this case, if a `msg' is also supplied, it will become the  current
+                 message of `+folder'.
+
+                 The `-recurse' switch lists each folder recursively, so use of this
+                 option  effectively  defeats  the  speed enhancement of the `-fast'
+                 option,  since  each  folder  must  be  searched  for   subfolders.
+                 Nevertheless, the combination of these options is useful.
+
+
+              _C_o_m_p_a_c_t_i_n_g _a _F_o_l_d_e_r
+
+                 The `-pack' switch will compress the message names  in  the  desig-
+                 nated folders, removing holes in message numbering.  The `-verbose'
+                 switch directs _f_o_l_d_e_r to tell the user the general actions that  it
+                 is taking to compress the folder.
+
+
+              _T_h_e _F_o_l_d_e_r _S_t_a_c_k
+
+                 The `-push' switch directs _f_o_l_d_e_r to push the current  folder  onto
+                 the  _f_o_l_d_e_r-_s_t_a_c_k,  and  make  the  `+folder'  argument the current
+                 folder.  If `+folder' is not given, the current folder and the  top
+                 of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged.  This corresponds to the "pushd"
+                 operation in the _C_S_h_e_l_l.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -35-                         FOLDER(1)
+
+
+                 The `-pop'  switch  directs  _f_o_l_d_e_r  to  discard  the  top  of  the
+                 _f_o_l_d_e_r-_s_t_a_c_k,  after  setting the current folder to that value.  No
+                 `+folder' argument is allowed.   This  corresponds  to  the  "popd"
+                 operation  in the _C_S_h_e_l_l.  The `-push' switch and the `-pop' switch
+                 are mutually exclusive: the last occurrence of either one overrides
+                 any  previous occurrence of the other.  Both of these switches also
+                 set `-list' by default.
+
+                 The `-list' switch directs _f_o_l_d_e_r  to  list  the  contents  of  the
+                 _f_o_l_d_e_r-_s_t_a_c_k.   No `+folder' argument is allowed.  After a success-
+                 ful `-push' or `-pop', the `-list' action is taken, unless a `-nol-
+                 ist'  switch follows them on the command line.  This corresponds to
+                 the "dirs" operation in  the  _C_S_h_e_l_l.   The  `-push',  `-pop',  and
+                 `-list' switches turn off `-print'.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Folder-Protect:      To set mode when creating a new folder
+                 Folder-Stack:        To determine the folder stack
+
+
+            _S_e_e _A_l_s_o
+                 refile(1), mhpath(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to none
+                 `-nofast'
+                 `-noheader'
+                 `-nototal'
+                 `-nopack'
+                 `-norecurse'
+                 `-noverbose'
+                 `-print' is the default if no `-list', `-push', or `-pop' is specified
+                 `-list' is the default if `-push', or `-pop' is specified
+
+
+            _C_o_n_t_e_x_t
+                 If `+folder' and/or `msg' are given, they will become  the  current
+                 folder and/or message.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FOLDER(1)                         -36-                         FOLDER(1)
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the `-fast'  switch  prevented  context
+                 changes  from  occurring for the current folder.  This is no longer
+                 the case: if `+folder' is given, then _f_o_l_d_e_r will always change the
+                 current folder to that.
+
+
+            _B_u_g_s
+                 `-all' forces `-header' and `-total'.
+
+                 There is no way to restore the default behavior (to  ask  the  user
+                 whether  to  create a non-existant folder) after `-create' or `-no-
+                 create' is given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -37-                           FORW(1)
+
+
+            _N_A_M_E
+                 forw - forward messages
+
+            _S_Y_N_O_P_S_I_S
+                 forw [+folder] [msgs] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-filter filterfile]
+                      [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+                      [-whatnowproc program] [-nowhatnowproc] [-help]
+
+                 forw [+folder] [msgs] [-digest list] [-issue number]
+                      [-volume number] [other switches for _f_o_r_w] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _F_o_r_w may be used to prepare a message  containing  other  messages.
+                 It   constructs  the  new  message  from  the  components  file  or
+                 `-form formfile'  (see  _c_o_m_p ),  with  a  body  composed   of   the
+                 message(s)  to  be forwarded.  An editor is invoked as in _c_o_m_p, and
+                 after editing is complete, the user is prompted before the  message
+                 is sent.
+
+                 The default message form contains the following elements:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 If the file named "forwcomps" exists in the user's MH directory, it
+                 will be used instead of this form.  In either case, the file speci-
+                 fied by `-form formfile' will be used if given.
+
+                 If the draft already exists, _f_o_r_w will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _f_o_r_w, leaving the
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 If the `-annotate' switch is given, each  message  being  forwarded
+                 will be annotated with the lines
+
+                      Forwarded: date
+                      Forwarded: addrs
+
+                 where each address list contains as many lines as  required.   This
+                 annotation  will  be done only if the message is sent directly from
+                 _f_o_r_w.   If  the  message  is  not  sent  immediately   from   _f_o_r_w,
+                 "comp -use"  may  be  used to re-edit and send the constructed mes-
+                 sage, but the annotations won't take place.  The '-inplace'  switch
+                 causes annotation to be done in place in order to preserve links to
+                 the annotated message.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -38-                           FORW(1)
+
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.
+
+                 Although _f_o_r_w uses the `-form formfile' switch to direct it how  to
+                 construct  the  beginning  of  the draft, the `-filter filterfile',
+                 `-format', and `-noformat' switches direct _f_o_r_w as to how each for-
+                 warded  message  should  be formatted in the body of the draft.  If
+                 `-noformat' is specified, then each  forwarded  message  is  output
+                 exactly  as  it  appears.   If `-format' or `-filter filterfile' is
+                 specified, then each forwarded message is  filtered  (re-formatted)
+                 prior  to  being  output to the body of the draft.  The filter file
+                 for _f_o_r_w should be a standard form  file  for  _m_h_l,  as  _f_o_r_w  will
+                 invoke  _m_h_l  to format the forwarded messages.  The default message
+                 filter (what you get with `-format') is:
+
+                      width=80,overflowtext=,overflowoffset=10
+                      leftadjust,compress,compwidth=9
+                      Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+                      From:
+                      To:
+                      cc:
+                      Subject:
+                      :
+                      body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+                 If the file named "mhl.forward" exists in the user's MH  directory,
+                 it  will  be  used  instead of this form.  In either case, the file
+                 specified by `-filter filterfile' will be used if given.   To  sum-
+                 marize:  `-noformat' will reproduce each forwarded message exactly,
+                 `-format' will use _m_h_l and a default filterfile, "mhl.forward",  to
+                 format  each  forwarded  message, and `-filter filterfile' will use
+                 the named filterfile to format each forwarded message with _m_h_l.
+
+                 Each forwarded message is separated with an encapsulation delimiter
+                 and  dashes  in  the first column of the forwarded messages will be
+                 prepended with `- ' so that when received, the message is  suitable
+                 for  bursting  by  _b_u_r_s_t (1).   This  follows  the Internet RFC-934
+                 guidelines.
+
+                 For users of  _p_r_o_m_p_t_e_r (1),  by  specifying  prompter's  `-prepend'
+                 switch  in  the  .mh_profile  file,  any commentary text is entered
+                 before the forwarded messages.  (A major win!)
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _f_o_r_w will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -39-                           FORW(1)
+
+
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+                 The `-digest list', `-issue number', and `-volume number'  switches
+                 implement  a  digest  facility  for  _M_H.  Specifying these switches
+                 enables and/or overloads the following escapes:
+
+                 _T_y_p_e       _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 _c_o_m_p_o_n_e_n_t  _d_i_g_e_s_t  string   Argument to `-digest'
+                 _f_u_n_c_t_i_o_n   _c_u_r     integer  Argument to `-volume'
+                 _f_u_n_c_t_i_o_n   _m_s_g     integer  Argument to `-issue'
+
+                 Consult the Advanced Features section of the _M_H User's  Manual  for
+                 more information on making digests.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/forwcomps         The message skeleton
+                 or <mh-dir>/forwcomps               Rather than the standard skeleton
+                 /usr/local/lib/mh/digestcomps       The message skeleton if `-digest' is given
+                 or <mh-dir>/digestcomps             Rather than the standard skeleton
+                 /usr/local/lib/mh/mhl.forward       The message filter
+                 or <mh-dir>/mhl.forward             Rather than the standard filter
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/draft                      The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 mhlproc:             Program to filter messages being forwarded
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+                 comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noformat'
+                 `-noinplace'
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FORW(1)                           -40-                           FORW(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message forwarded will become the current message.
+
+
+            _B_u_g_s
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _f_o_r_w uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _f_o_r_w  won't  run
+                 it.
+
+                 When _f_o_r_w is told to annotate the messages it forwards, it  doesn't
+                 actually  annotate  them  until the draft is successfully sent.  If
+                 from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h instead of _s_e_n_d,  it's  possible  to
+                 confuse   _f_o_r_w   by   re-ordering   the   file   (e.g.,   by  using
+                 `folder -pack') before the message is successfully sent.  _D_i_s_t  and
+                 _r_e_p_l don't have this problem.
+
+                 To avoid prepending the leading dash characters in  forwarded  mes-
+                 sages,  there  is  a  `-nodashmunging'  option.   See  the  "Hidden
+                 Features" section of the _M_H _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -41-                            INC(1)
+
+
+            _N_A_M_E
+                 inc - incorporate new mail
+
+            _S_Y_N_O_P_S_I_S
+                 inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+                      [-nochangecur] [-form formatfile] [-format string]
+                      [-file name] [-silent] [-nosilent] [-truncate] [-notruncate]
+                      [-width columns] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _I_n_c incorporates mail from the user's incoming mail drop into an _M_H
+                 folder.   If  `+folder'  isn't specified, a folder in the user's _M_H
+                 directory will be used, either that specified by the "Inbox:" entry
+                 in  the  user's profile, or the folder named "inbox".  The new mes-
+                 sages being incorporated are assigned  numbers  starting  with  the
+                 next  highest  number in the folder.  If the specified (or default)
+                 folder doesn't exist, the user will be queried prior to  its  crea-
+                 tion.   As  the  messages  are processed, a _s_c_a_n listing of the new
+                 mail is produced.
+
+                 If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+                 be  used as the protection on the newly created messages, otherwise
+                 the _M_H default of 0644 will be used.  During all operations on mes-
+                 sages,  this  initially  assigned  protection will be preserved for
+                 each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+                 individual   message,   and   its   protection  will  be  preserved
+                 thereafter.
+
+                 If the  switch  `-audit audit-file'  is  specified  (usually  as  a
+                 default  switch in the profile), then _i_n_c will append a header line
+                 and a line per message to the end of the specified audit-file  with
+                 the format:
+
+                      <<inc>> date
+                           <scan line for first message>
+                           <scan line for second message>
+                                     <etc.>
+
+                 This is useful for keeping track of volume and source  of  incoming
+                 mail.   Eventually,  _r_e_p_l,  _f_o_r_w,  _c_o_m_p,  and _d_i_s_t may also produce
+                 audits to this (or another) file, perhaps with "Message-Id:" infor-
+                 mation  to keep an exact correspondence history.  "Audit-file" will
+                 be in the user's MH directory unless a full path is specified.
+
+                 _I_n_c will incorporate even improperly formatted  messages  into  the
+                 user's  MH  folder,  inserting  a blank line prior to the offending
+                 component and printing a comment identifying the bad message.
+
+                 In all cases, the user's mail  drop  will  be  zeroed,  unless  the
+                 `-notruncate' switch is given.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -42-                            INC(1)
+
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+                 then  _i_n_c  will add each of the newly incorporated messages to each
+                 sequence named by the  profile  entry.   This  is  similar  to  the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.  Note that _i_n_c will not  zero
+                 each sequence prior to adding messages.
+
+                 The interpretation of the `-form formatfile', `-format string', and
+                 `-width columns' switches is the same as in _s_c_a_n (1).
+
+                 By using the `-file name' switch, one can direct _i_n_c to incorporate
+                 messages from a file other than the user's maildrop.  Note that the
+                 name file will NOT be zeroed,  unless  the  `-truncate'  switch  is
+                 given.
+
+                 If the envariable $MAILDROP is set, then _i_n_c uses it as  the  loca-
+                 tion  of  the  user's  maildrop  instead  of  the  default  (the `-
+                 file name' switch still overrides this, however).  If this  envari-
+                 able is not set, then _i_n_c will consult the profile entry "MailDrop"
+                 for this information.  If the value found is not absolute, then  it
+                 is  interpreted  relative to the user's _M_H directory.  If the value
+                 is not found, then _i_n_c will look in the  standard  system  location
+                 for the user's maildrop.
+
+                 The `-silent' switch directs _i_n_c to be quiet and not ask any  ques-
+                 tions at all.  This is useful for putting _i_n_c in the background and
+                 going on to other things.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/spool/mail/$USER               Location of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Inbox:               To determine the inbox, default "inbox"
+                 Folder-Protect:      To set mode when creating a new folder
+                 Msg-Protect:         To set mode when creating a  new  message  and
+                 audit-file
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+            _S_e_e _A_l_s_o
+                 mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INC(1)                            -43-                            INC(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaulted by "Inbox" above
+                 `-noaudit'
+                 `-changecur'
+                 `-format' defaulted as described above
+                 `-nosilent'
+                 `-truncate' if `-file name' not given, `-notruncate' otherwise
+                 `-width' defaulted to the width of the terminal
+
+
+            _C_o_n_t_e_x_t
+                 The folder into which messages are being incorporated  will  become
+                 the current folder.  The first message incorporated will become the
+                 current message, unless the  `-nochangecur'  option  is  specified.
+                 This leaves the context ready for a _s_h_o_w of the first new message.
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _i_n_c.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -44-                           MARK(1)
+
+
+            _N_A_M_E
+                 mark - mark messages
+
+            _S_Y_N_O_P_S_I_S
+                 mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+                      [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _m_a_r_k command manipulates message sequences by adding or  delet-
+                 ing  message  numbers from folder-specific message sequences, or by
+                 listing those sequences and messages.  A message sequence is a key-
+                 word,  just  like  one  of  the  "reserved"  message names, such as
+                 "first" or "next".  Unlike the "reserved" message names, which have
+                 a fixed semantics on a per-folder basis, the semantics of a message
+                 sequence may be defined, modified, and removed by the  user.   Mes-
+                 sage  sequences are folder-specific, e.g., the sequence name "seen"
+                 in the context of folder "+inbox" need not have any relation  what-
+                 soever  to the sequence of the same name in a folder of a different
+                 name.
+
+                 Three action switches direct the operation of _m_a_r_k.  These switches
+                 are  mutually  exclusive:  the last occurrence of any of them over-
+                 rides any previous occurrence of the other two.
+
+                 The `-add' switch tells _m_a_r_k to add messages  to  sequences  or  to
+                 create   a   new   sequence.   For  each  sequence  named  via  the
+                 `-sequence name' argument (which must occur at least once) the mes-
+                 sages  named  via  `msgs' (which defaults to "cur" if no `msgs' are
+                 given), are added to the sequence.  The messages to be  added  need
+                 not  be  absent from the sequence.  If the `-zero' switch is speci-
+                 fied, the sequence will be emptied prior to  adding  the  messages.
+                 Hence,  `-add -zero' means that each sequence should be initialized
+                 to the indicated messages, while  `-add -nozero'  means  that  each
+                 sequence should be appended to by the indicated messages.
+
+                 The `-delete' switch tells _m_a_r_k to delete messages from  sequences,
+                 and  is  the  dual of `-add'.  For each of the named sequences, the
+                 named messages are removed from the sequence.  These messages  need
+                 not  be  already present in the sequence.  If the `-zero' switch is
+                 specified, then all messages in the  folder  are  appended  to  the
+                 sequence  prior  to  removing the messages.  Hence, `-delete -zero'
+                 means that each sequence should contain all messages  except  those
+                 indicated,  while  `-delete -nozero'  means that only the indicated
+                 messages should be removed from each sequence.   As  expected,  the
+                 command   `mark -sequence seen -delete all'  deletes  the  sequence
+                 "seen" from the current folder.
+
+                 When creating (or modifying) a sequence, the `-public' switch indi-
+                 cates that the sequence should be made readable for other _M_H users.
+                 In contrast, the `-nopublic' switch  indicates  that  the  sequence
+                 should be private to the user's _M_H environment.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -45-                           MARK(1)
+
+
+                 The `-list' switch tells _m_a_r_k to list both  the  sequences  defined
+                 for  the  folder  and the messages associated with those sequences.
+                 _M_a_r_k will list the name of each sequence given by  `-sequence name'
+                 and  the  messages  associated  with that sequence.  If `-sequence'
+                 isn't used, all sequences will be listed,  with  private  sequences
+                 being  so indicated.  The `-zero' switch does not affect the opera-
+                 tion of `-list'.
+
+                 The current restrictions on sequences are:
+
+                   The name used to denote a message sequence  must  consist  of  an
+                   alphabetic  character followed by zero or more alphanumeric char-
+                   acters, and cannot be one of the (reserved) message names  "new",
+                   "first", "last", "all", "next", or "prev".
+
+                   Only a certain number of sequences may be  defined  for  a  given
+                   folder.   This  number is usually limited to 26 (10 on small sys-
+                   tems).
+
+                   Message ranges with user-defined sequence names are restricted to
+                   the  form  "name:n"  or "name:-n", and refer to the first or last
+                   `n' messages of the sequence `name', respectively.  Constructs of
+                   the form "name1-name2" are forbidden.
+
+            _F_i_l_e_s
+                $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                pick (1), mh-sequence (5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-add' if `-sequence' is specified, `-list' otherwise
+                 `msgs' defaults to cur (or all if `-list' is specified)
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-nozero'
+
+
+            _C_o_n_t_e_x_t
+                If a folder is given, it will become the current folder.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 Use "pick sequence -list" to enumerate the messages in  a  sequence
+                 (such as for use by a shell script).
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MARK(1)                           -46-                           MARK(1)
+
+
+            _N_A_M_E
+                 mhl - produce formatted listings of MH messages
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+                      [-folder +folder] [-form formfile] [-length lines]
+                      [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_l is a formatted message listing program.  It can be  used  as  a
+                 replacement  for  _m_o_r_e (1)  (the default _s_h_o_w_p_r_o_c ).  As with _m_o_r_e,
+                 each of the messages specified as arguments (or the standard input)
+                 will  be  output.   If more than one message file is specified, the
+                 user will be prompted prior to each one, and a  <RETURN>  or  <EOT>
+                 will  begin  the  output,  with  <RETURN>  clearing  the screen (if
+                 appropriate), and <EOT> (usually  CTRL-D)  suppressing  the  screen
+                 clear.  An <INTERRUPT> (usually CTRL-C) will abort the current mes-
+                 sage output, prompting for the next message (if there is one),  and
+                 a  <QUIT> (usually CTRL-\) will terminate the program (without core
+                 dump).
+
+                 The `-bell' option tells _m_h_l to ring the terminal's bell at the end
+                 of  each  page,  while  the  `-clear' option tells _m_h_l to clear the
+                 scree at the end of each page (or output a formfeed after each mes-
+                 sage).   Both  of  these  switches (and their inverse counterparts)
+                 take effect only if the  profile  entry  _m_o_r_e_p_r_o_c  is  defined  but
+                 empty,  and _m_h_l is outputting to a terminal.  If the _m_o_r_e_p_r_o_c entry
+                 is defined and non-empty, and _m_h_l is outputting to a terminal, then
+                 _m_h_l  will  cause the _m_o_r_e_p_r_o_c to be placed between the terminal and
+                 _m_h_l and the switches are ignored.   Furthermore,  if  the  `-clear'
+                 switch is used and _m_h_l'_s output is directed to a terminal, then _m_h_l
+                 will consult the $TERM and $TERMCAP envariables  to  determine  the
+                 user's  terminal type in order to find out how to clear the screen.
+                 If the `-clear' switch is used and _m_h_l'_s output is not directed  to
+                 a  terminal (e.g., a pipe or a file), then _m_h_l will send a formfeed
+                 after each message.
+
+                 To override the default _m_o_r_e_p_r_o_c and the  profile  entry,  use  the
+                 `-moreproc program'  switch.   Note  that  _m_h_l  will  never start a
+                 _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+                 The `-length length' and `-width width'  switches  set  the  screen
+                 length  and width, respectively.  These default to the values indi-
+                 cated by $TERMCAP, if appropriate, otherwise they default to 40 and
+                 80, respectively.
+
+                 The default format file used by _m_h_l is called _m_h_l._f_o_r_m_a_t (which  is
+                 first  searched  for in the user's _M_H directory, and then sought in
+                 the /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h directory), this can be changed by using  the
+                 `-form formatfile' switch.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -47-                            MHL(1)
+
+
+                 Finally, the `-folder +folder' switch  sets  the  _M_H  folder  name,
+                 which  is  used  for the "messagename:" field described below.  The
+                 envariable $mhfolder is consulted  for  the  default  value,  which
+                 _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize appropriately.
+
+                 _M_h_l operates in two phases: 1) read and parse the format file,  and
+                 2)  process  each  message  (file).   During  phase  1, an internal
+                 description of the format is produced as  a  structured  list.   In
+                 phase  2,  this list is walked for each message, outputting message
+                 information under the format constraints from the format file.
+
+                 The "mhl.format" form file contains information controlling  screen
+                 clearing,  screen size, wrap-around control, transparent text, com-
+                 ponent ordering, and component formatting.  Also, a  list  of  com-
+                 ponents  to ignore may be specified, and a couple of "special" com-
+                 ponents are defined to provide added functionality.  Message output
+                 will be in the order specified by the order in the format file.
+
+                 Each line of mhl.format has one of the formats:
+
+                      ;comment
+                      :cleartext
+                      variable[,variable...]
+                      component:[variable,...]
+
+                 A line beginning with a `;' is a comment, and is ignored.   A  line
+                 beginning with a `:' is clear text, and is output exactly as is.  A
+                 line containing only a `:' produces a blank line in the output.   A
+                 line  beginning with "component:" defines the format for the speci-
+                 fied component, and finally,  remaining  lines  define  the  global
+                 environment.
+
+                 For example, the line:
+
+                      width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+                 defines the screen size to be 80 columns by 40 rows, specifies that
+                 the screen should be cleared prior to each page, that the  overflow
+                 indentation  is  5,  and  that overflow text should be flagged with
+                 "***".
+
+                 Following are all of the current variables and their arguments.  If
+                 they  follow a component, they apply only to that component, other-
+                 wise, their affect is global.  Since the  whole  format  is  parsed
+                 before  any output processing, the last global switch setting for a
+                 variable applies to the whole message if that variable is used in a
+                 global context (i.e., bell, clearscreen, width, length).
+
+                      _v_a_r_i_a_b_l_e       _t_y_p_e       _s_e_m_a_n_t_i_c_s
+                      width          integer    screen width or component width
+                      length         integer    screen length or component length
+                      offset         integer    positions to indent "component: "
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -48-                            MHL(1)
+
+
+                      overflowtext   string     text to use at the beginning of an
+                                                overflow line
+                      overflowoffset integer    positions to indent overflow lines
+                      compwidth      integer    positions to indent component text
+                                                after the first line is output
+                      uppercase      flag       output text of this component in all
+                                                upper case
+                      nouppercase    flag       don't uppercase
+                      clearscreen    flag/G     clear the screen prior to each page
+                      noclearscreen  flag/G     don't clearscreen
+                      bell           flag/G     ring the bell at the end of each page
+                      nobell         flag/G     don't bell
+                      component      string/L   name to use instead of "component" for
+                                                this component
+                      nocomponent    flag       don't output "component: " for this
+                                                component
+                      center         flag       center component on line (works for
+                                                one-line components only)
+                      nocenter       flag       don't center
+                      leftadjust     flag       strip off leading whitespace on each
+                                                line of text
+                      noleftadjust   flag       don't leftadjust
+                      compress       flag       change newlines in text to spaces
+                      nocompress     flag       don't compress
+                      split          flag       don't combine multiple fields into a single field
+                      nosplit        flag       combine multiple fields into a single field
+                      newline        flag       print newline at end of components (default)
+                      nonewline      flag       don't print newline at end of components
+                      formatfield    string     format string for this component (see below)
+                      addrfield      flag       field contains addresses
+                      datefield      flag       field contains dates
+
+                 To specify the value of integer-valued and string-valued variables,
+                 follow   their   name   with   an   equals-sign   and   the  value.
+                 Integer-valued  variables   are   given   decimal   values,   while
+                 string-valued  variables  are  given  arbitrary  text  bracketed by
+                 double-quotes.  If a value is suffixed by "/G" or  "/L",  then  its
+                 value  is  useful  in  a global-only or local-only context (respec-
+                 tively).
+
+                 A line of the form:
+
+                     ignores=component,...
+
+                 specifies a list of components which are never output.
+
+                 The component  "MessageName"  (case-insensitive)  will  output  the
+                 actual  message name (file name) preceded by the folder name if one
+                 is specified or found in the environment.  The format is  identical
+                 to that produced by the `-header' option to _s_h_o_w.
+
+                 The component "Extras" will output all of  the  components  of  the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -49-                            MHL(1)
+
+
+                 message  which were not matched by explicit components, or included
+                 in the ignore list.  If this component is not specified, an  ignore
+                 list  is  not  needed  since  all  non-specified components will be
+                 ignored.
+
+                 If "nocomponent" is NOT specified, then the component name will  be
+                 output as it appears in the format file.
+
+                 The default format is:
+
+                      : -- using template mhl.format --
+                      overflowtext="***",overflowoffset=5
+                      leftadjust,compwidth=9
+                      ignores=msgid,message-id,received
+                      Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+                      To:
+                      cc:
+                      :
+                      From:
+                      Subject:
+                      :
+                      extras:nocomponent
+                      :
+                      body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+                 The  variable  "formatfield"  specifies  a   format   string   (see
+                 _m_h-_f_o_r_m_a_t (5)).   The  flag  variables  "addrfield" and "datefield"
+                 (which are mutually exclusive), tell _m_h_l to interpret  the  escapes
+                 in the format string as either addresses or dates, respectively.
+
+                 By default, _m_h_l does not apply any formatting string to fields con-
+                 taining  address  or  dates  (see  _m_h-_m_a_i_l (5)  for a list of these
+                 fields).  Note that this results in faster operation since _m_h_l must
+                 parse both addresses and dates in order to apply a format string to
+                 them.  If desired, _m_h_l can be given a  default  format  string  for
+                 either  address  or  date  fields (but not both).  To do this, on a
+                 global line specify: either the flag addrfield or datefield,  along
+                 with the apropriate formatfield variable string.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mhl.format        The message template
+                 or <mh-dir>/mhl.format              Rather than the standard template
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 moreproc:            Program to use as interactive front-end
+
+
+            _S_e_e _A_l_s_o
+                 show(1), ap(8), dp(8)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHL(1)                            -50-                            MHL(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-bell'
+                 `-noclear'
+                 `-length 40'
+                 `-width 80'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 There should be some way to pass `bell' and `clear' information  to
+                 the front-end.
+
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+                 The "nonewline" option interacts badly with "compress" and "split".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHMAIL(1)                         -51-                         MHMAIL(1)
+
+
+            _N_A_M_E
+                 mhmail - send or read mail
+
+            _S_Y_N_O_P_S_I_S
+                 mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+                      [-subject subject]] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_H_m_a_i_l is intended as a replacement for the standard Bell mail pro-
+                 gram  (_b_e_l_l_m_a_i_l (1)),  compatible  with  _M_H.   When invoked without
+                 arguments, it simply invokes _i_n_c (1) to  incorporate  new  messages
+                 from  the  user's maildrop.  When one or more users is specified, a
+                 message is read from the standard input and spooled to a  temporary
+                 file.   _M_H_m_a_i_l then invokes _p_o_s_t (8) with the name of the temporary
+                 file as its argument to deliver the message to the specified user.
+
+                 The `-subject subject' switch can be used to specify the "Subject:"
+                 field  of  the  message.   The  `-body text'  switch can be used to
+                 specify the text of the message; if it is specified, then the stan-
+                 dard input is not read.  Normally, addresses appearing as arguments
+                 are put in the "To:" field.  If  the  `-cc'  switch  is  used,  all
+                 addresses following it are placed in the "cc:" field.
+
+                 By using `-from addr', you can specify the "From:"  header  of  the
+                 draft.    Naturally,   _p_o_s_t   will  fill-in  the  "Sender:"  header
+                 correctly.
+
+                 This program is intended for the use of programs  such  as  _a_t (1),
+                 which  expect  to  send  mail automatically to various users.  Nor-
+                 mally, real people (as opposed to the "unreal" ones) will prefer to
+                 use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+            _F_i_l_e_s
+                 /usr/local/inc                      Program to incorporate a maildrop into a folder
+                 /usr/local/lib/mh/post              Program to deliver a message
+                 /tmp/mhmail*                        Temporary copy of message
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHMAIL(1)                         -52-                         MHMAIL(1)
+
+
+            _C_o_n_t_e_x_t
+                 If _i_n_c is invoked, then _i_n_c's context changes occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHOOK(1)                          -53-                          MHOOK(1)
+
+
+            _N_A_M_E
+                 mhook, rcvdist, rcvpack, rcvtty  - MH receive-mail hooks
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/rcvdist [-form formfile] [switches for _p_o_s_t_p_r_o_c]
+                      address ...  [-help]
+
+                 /usr/local/lib/mh/rcvpack file [-help]
+
+                 /usr/local/lib/mh/rcvtty [command] [-form formatfile]
+                      [-format string] [-bell] [-nobell] [-newline] [-nonewline]
+                      [-biff] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 A receive-mail hook is a program that is run whenever you receive a
+                 mail message.  You do NOT invoke the hook yourself, rather the hook
+                 is invoked on your behalf by your system's Message Transport Agent.
+                 See _s_l_o_c_a_l (1) for details on how to activate receive-mail hooks on
+                 your system.
+
+                 Four programs are  currently  available  as  part  of  _M_H,  _r_c_v_d_i_s_t
+                 (redistribute  incoming messages to additional recipients), _r_c_v_p_a_c_k
+                 (save incoming messages in a _p_a_c_k_f'd file), and _r_c_v_t_t_y (notify user
+                 of   incoming  messages).   The  fourth  program,  _r_c_v_s_t_o_r_e (1)  is
+                 described separately.  They all reside  in  the  /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/
+                 directory.
+
+                 The _r_c_v_d_i_s_t program will resend a copy of the message to all of the
+                 addresses  listed  on  its command line.  It uses the format string
+                 facility described in _m_h-_f_o_r_m_a_t (5).
+
+                 The _r_c_v_p_a_c_k program will append a copy of the message to  the  file
+                 listed  on  its  command  line.  Its use is obsoleted by the "file"
+                 action of _s_l_o_c_a_l.
+
+                 The _r_c_v_t_t_y program executes the named file with the message as  its
+                 standard input, and writes the resulting output on your terminal.
+
+                 If no file is specified,  or  is  bogus,  etc.,  then  _r_c_v_t_t_y  will
+                 instead    write    a    one-line   scan   listing.    Either   the
+                 `-form formatfile' or `-format string' option may be used to  over-
+                 ride  the  default output format (see _m_h-_f_o_r_m_a_t (5)).  A newline is
+                 output before the message output, and the  terminal  bell  is  rung
+                 after  the  output.   The  `-nonewline'  and `-nobell' options will
+                 inhibit these functions.
+
+                 In addition to the  standard  _m_h-_f_o_r_m_a_t (5)  escapes,  _r_c_v_t_t_y  also
+                 recognizes the following additional _c_o_m_p_o_n_e_n_t escapes:
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHOOK(1)                          -54-                          MHOOK(1)
+
+
+                 _E_s_c_a_p_e    _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 body      string   the (compressed) first part of the body
+                 dtimenow  date     the current date
+                 folder    string   the name of the current folder
+
+                 Normally, _r_c_v_t_t_y obeys write permission  as  granted  by  _m_e_s_g (1).
+                 With  the  `-biff' option, _r_c_v_t_t_y will obey the notification status
+                 set by _b_i_f_f (1) instead.  If the terminal access daemon  (TTYD)  is
+                 available  on  your system, then _r_c_v_t_t_y will give its output to the
+                 daemon for output instead of writing on the user's terminal.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 $HOME/.maildelivery                 The file controlling local delivery
+                 /usr/local/lib/mh/maildelivery      Rather than the standard file
+
+
+            _S_e_e _A_l_s_o
+                 rcvstore (1), mh-format(5), slocal(1)
+
+
+            _B_u_g_s
+                 Only two return codes are meaningful, others should be.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPARAM(1)                        -55-                        MHPARAM(1)
+
+
+            _N_A_M_E
+                 mhparam - print MH profile components
+
+            _S_Y_N_O_P_S_I_S
+                 mhparam [components] [-all] [-component] [-nocomponent] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_p_a_r_a_m writes the value of the specified profile component to  the
+                 standard output separated by newlines.  If the profile component is
+                 not present, the default value (or nothing if there is no  default)
+                 is printed.
+
+                 If more than one component is specified in the  `components'  list,
+                 the  component  value is preceded by the component name.  If `-com-
+                 ponent' is specified, the component name  is  displayed  even  when
+                 only  one  component is specified.  If `-nocomponent' is specified,
+                 the component name is not displayed even when more  than  one  com-
+                 ponent is specified.
+
+                 If `-all' is specified,  all  components  if  the  MH  profile  are
+                 displayed and other arguments are ignored.
+
+                 Examples:
+
+                      % mhparam path
+                      Mail
+
+                      % mhparam mhlproc
+                      /usr/local/lib/mh/mhl
+
+                      % mhparam -component path
+                      Path:       Mail
+
+                      % mhparam AliasFile rmmproc
+                      AliasFile:  aliases
+                      rmmproc:    rmmproc
+
+                      % mhparam -nocomponent AliasFile rmmproc
+                      aliases
+                      rmmproc
+
+                 _M_h_p_a_r_a_m is also useful in back-quoted operations:
+
+                      % fgrep cornell.edu `mhpath +`/`mhparam aliasfile`
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPARAM(1)                        -56-                        MHPARAM(1)
+
+
+            _S_e_e _A_l_s_o
+                 mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-nocomponent' if only one component is specified
+                 `-component' if more than one component is specified
+                 `components' defaults to none
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -57-                         MHPATH(1)
+
+
+            _N_A_M_E
+                 mhpath - print full pathnames of MH messages and folders
+
+            _S_Y_N_O_P_S_I_S
+                 mhpath [+folder] [msgs] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_h_p_a_t_h expands and sorts the message list  `msgs'  and  writes  the
+                 full  pathnames of the messages to the standard output separated by
+                 newlines.  If no `msgs' are specified, _m_h_p_a_t_h  outputs  the  folder
+                 pathname  instead.   If  the  only argument is `+', your MH _P_a_t_h is
+                 output; this can be useful is shell scripts.
+
+                 Contrasted with other MH commands, a message argument to _m_h_p_a_t_h may
+                 often be intended for _w_r_i_t_i_n_g.  Because of this:
+
+                 1) the name "new" has been added to _m_h_p_a_t_h's list of reserved  mes-
+                 sage  names (the others are "first", "last", "prev", "next", "cur",
+                 and "all").  The new message is equivalent to the message after the
+                 last  message  in a folder (and equivalent to 1 in a folder without
+                 messages).  The "new" message may not be used as part of a  message
+                 range.
+
+                 2) Within a message list, the following designations may  refer  to
+                 messages that do not exist: a single numeric message name, the sin-
+                 gle message name "cur", and (obviously)  the  single  message  name
+                 "new".   All  other message designations must refer to at least one
+                 existing message.
+
+                 3) An empty folder is not in itself an error.
+
+                 Message numbers greater than the  highest  existing  message  in  a
+                 folder  as  part  of a range designation are replaced with the next
+                 free message number.
+
+                 Examples: The current folder foo contains messages 3 5 6.   Cur  is
+                 4.
+
+                      % mhpath
+                      /r/phyl/Mail/foo
+
+                      % mhpath all
+                      /r/phyl/Mail/foo/3
+                      /r/phyl/Mail/foo/5
+                      /r/phyl/Mail/foo/6
+
+                      % mhpath 2001
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath 1-2001
+                      /r/phyl/Mail/foo/3
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -58-                         MHPATH(1)
+
+
+                      /r/phyl/Mail/foo/5
+                      /r/phyl/Mail/foo/6
+
+                      % mhpath new
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath last new
+                      /r/phyl/Mail/foo/6
+                      /r/phyl/Mail/foo/7
+
+                      % mhpath last-new
+                      bad message list "last-new".
+
+                      % mhpath cur
+                      /r/phyl/Mail/foo/4
+
+                      % mhpath 1-2
+                      no messages in range "1-2".
+
+                      % mhpath first:2
+                      /r/phyl/Mail/foo/3
+                      /r/phyl/Mail/foo/5
+
+                      % mhpath 1 2
+                      /r/phyl/Mail/foo/1
+                      /r/phyl/Mail/foo/2
+
+                 _M_H_p_a_t_h is also useful in back-quoted operations:
+
+                      % cd `mhpath +inbox`
+
+                      % echo `mhpath +`
+                      /r/phyl/Mail
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 folder(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to none
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MHPATH(1)                         -59-                         MHPATH(1)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 Like all MH commands, _m_h_p_a_t_h expands and sorts  [msgs].   So  don't
+                 expect
+
+                      mv `mhpath 501 500`
+
+                 to move 501 to 500.  Quite the reverse.  But
+
+                      mv `mhpath 501` `mhpath 500`
+
+                 will do the trick.
+
+                 Out of range message 0 is treated far more severely than large  out
+                 of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSGCHK(1)                         -60-                         MSGCHK(1)
+
+
+            _N_A_M_E
+                 msgchk - check for messages
+
+            _S_Y_N_O_P_S_I_S
+                 msgchk [-date] [-nodate] [-notify all/mail/nomail]
+                      [-nonotify all/mail/nomail] [users ...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 The _m_s_g_c_h_k program checks all known mail drops for mail waiting for
+                 you.  For those drops which have mail for you, _m_s_g_c_h_k will indicate
+                 if it believes that you have seen the mail in question before.
+
+                 The `-notify type' switch indicates under what circumstances _m_s_g_c_h_k
+                 should  produce a message.  The default is `-notify all' which says
+                 that _m_s_g_c_h_k should always report the status of the users  maildrop.
+                 Other  values  for  `type'  include  `mail'  which says that _m_s_g_c_h_k
+                 should report the status of waiting mail; and, `nomail' which  says
+                 that  _m_s_g_c_h_k  should  report  the  status  of empty maildrops.  The
+                 `-nonotify type' switch has the inverted sense, so  `-nonotify all'
+                 directs  _m_s_g_c_h_k  to  never report the status of maildrops.  This is
+                 useful if the  user  wishes  to  check  _m_s_g_c_h_k's  exit  status.   A
+                 non-zero  exit  status  indicates  that mail was not waiting for at
+                 least one of the indicated users.
+
+                 If _m_s_g_c_h_k produces output, then the `-date' switch  directs  _m_s_g_c_h_k
+                 to  print  out  the  last date mail was read, if this can be deter-
+                 mined.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/spool/mail/$USER               Location of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 inc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `user' defaults to the current user
+                 `-date'
+                 `-notify all'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSGCHK(1)                         -61-                         MSGCHK(1)
+
+
+            _N_A_M_E
+                 msh - MH shell (and BBoard reader)
+
+            _S_Y_N_O_P_S_I_S
+                 msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _m_s_h is an interactive program that implements a subset of the  nor-
+                 mal _M_H commands operating on a single file in _p_a_c_k_f'd format.  That
+                 is, _m_s_h is used to read a file that contains a number of  messages,
+                 as  opposed  to the standard _M_H style of reading a number of files,
+                 each file being a separate message in a folder.  _m_s_h's chief advan-
+                 tage is that the normal _M_H style does not allow a file to have more
+                 than one message in it.  Hence, _m_s_h is ideal for  reading  _B_B_o_a_r_d_s,
+                 as  these  files are delivered by the transport system in this for-
+                 mat.  In addition, _m_s_h can be used on other files, such as  message
+                 archives  which  have been _p_a_c_ked (see _p_a_c_k_f (1)).  Finally, _m_s_h is
+                 an excellent _M_H tutor.  As the only commands available to the  user
+                 are  _M_H  commands,  this  allows _M_H beginners to concentrate on how
+                 commands to _M_H are formed and (more or less) what they mean.
+
+                 When invoked, _m_s_h reads the named file, and enters a command  loop.
+                 The  user  may type most of the normal _M_H commands.  The syntax and
+                 semantics of these commands typed to _m_s_h are identical to their  _M_H
+                 counterparts.   In  cases  where  the nature of _m_s_h would be incon-
+                 sistent (e.g., specifying a `+folder' with some commands), _m_s_h will
+                 duly inform the user.  The commands that _m_s_h currently supports (in
+                 some slightly modified or restricted forms) are:
+
+                      ali
+                      burst
+                      comp
+                      dist
+                      folder
+                      forw
+                      inc
+                      mark
+                      mhmail
+                      msgchk
+                      next
+                      packf
+                      pick
+                      prev
+                      refile
+                      repl
+                      rmm
+                      scan
+                      send
+                      show
+                      sortm
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -62-                            MSH(1)
+
+
+                      whatnow
+                      whom
+
+                 In addition, _m_s_h has a "help" command which gives a brief overview.
+                 To  terminate  _m_s_h, type CTRL-D, or use the "quit" command.  If _m_s_h
+                 is being invoked from _b_b_c, then typing CTRL-D will also tell _b_b_c to
+                 exit as well, while using the "quit" command will return control to
+                 _b_b_c, and _b_b_c will continue examining the list of BBoards that it is
+                 scanning.
+
+                 If the file is writable and has been modified,  then  using  "quit"
+                 will query the user if the file should be updated.
+
+                 The `-prompt string' switch sets the prompting string for _m_s_h.
+
+                 You may wish to use an alternate _M_H profile for the  commands  that
+                 _m_s_h  executes; see _m_h-_p_r_o_f_i_l_e (5) for details about the $MH envari-
+                 able.
+
+                 When invoked from _b_b_c, two special features are enabled: First, the
+                 `-scan' switch directs _m_s_h to do a `scan unseen' on start-up if new
+                 items are present in the BBoard.  This feature is  best  used  from
+                 _b_b_c,  which  correctly sets the stage.  Second, the _m_a_r_k command in
+                 _m_s_h acts specially when you are reading a BBoard,  since  _m_s_h  will
+                 consult the sequence "unseen" in determining what messages you have
+                 actually read.  When _m_s_h exits, it reports this information to _b_b_c.
+                 In  addition,  if  you give the _m_a_r_k command with no arguments, _m_s_h
+                 will interpret  it  as  `mark -sequence unseen -delete -nozero all'
+                 Hence,  to discard all of the messages in the current BBoard you're
+                 reading, just use the _m_a_r_k command with no arguments.
+
+                 Normally, the "exit" command is identical to the "quit" command  in
+                 _m_s_h.   When  run  under _b_b_c however, "exit" directs _m_s_h to mark all
+                 messages as seen and then "quit".  For speedy type-in, this command
+                 is often abbreviated as just "e".
+
+                 When invoked from _v_m_h, another  special  feature  is  enabled:  The
+                 `topcur' switch directs _m_s_h to have the current message "track" the
+                 top line of the _v_m_h scan window.  Normally,  _m_s_h  has  the  current
+                 message  "track" the center of the window (under `-notopcur', which
+                 is the default).
+
+                 _m_s_h supports an output redirection facility.  Commands may be  fol-
+                 lowed by one of
+
+                      > _f_i_l_e     write output to _f_i_l_e
+                      >> _f_i_l_e    append output to _f_i_l_e
+                      | _c_o_m_m_a_n_d  pipe output to UNIX _c_o_m_m_a_n_d
+
+                 If _f_i_l_e starts with a `~' (tilde), then a _c_s_h-like expansion  takes
+                 place.  Note that _c_o_m_m_a_n_d is interpreted by _s_h (1).  Also note that
+                 _m_s_h does NOT support history substitutions, variable substitutions,
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -63-                            MSH(1)
+
+
+                 or alias substitutions.
+
+                 When parsing commands to the left of any  redirection  symbol,  _m_s_h
+                 will honor `\' (back-slash) as the quote next-character symbol, and
+                 `"' (double-quote)  as  quote-word  delimiters.   All  other  input
+                 tokens are separated by whitespace (spaces and tabs).
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /usr/local/lib/mh/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Msg-Protect:         To set mode when creating a new `file'
+                 fileproc:            Program to file messages
+                 showproc:            Program to show messages
+
+
+            _S_e_e _A_l_s_o
+                 bbc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to "./msgbox"
+                 `-prompt (msh) '
+                 `-noscan'
+                 `-notopcur'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MSH(1)                            -64-                            MSH(1)
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _m_s_h.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+                 There is a strict limit of messages  per  file  in  _p_a_c_k_f'd  format
+                 which _m_s_h can handle.  Usually, this limit is 1000 messages.
+
+                 Please remember that _m_s_h is not the _C_S_h_e_l_l, and that a lot  of  the
+                 nice facilities provided by the latter are not present in the form-
+                 er.
+
+                 In particular, _m_s_h does not understand back-quoting,  so  the  only
+                 effective  way  to  use  _p_i_c_k  inside  _m_s_h  is  to  always  use the
+                 `-seq select' switch.  Clever users of _M_H will put the line
+
+                      pick: -seq select -list
+
+                 in their .mh_profile file so that _p_i_c_k works equally well from both
+                 the shell and _m_s_h.
+
+                 _s_o_r_t_m always uses "-noverbose" and if "-textfield field"  is  used,
+                 "-limit 0".
+
+                 The _m_s_h program inherits most (if not all) of the bugs from the  _M_H
+                 commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            NEXT(1)                           -65-                           NEXT(1)
+
+
+            _N_A_M_E
+                 next - show the next message
+
+            _S_Y_N_O_P_S_I_S
+                 next [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _N_e_x_t performs a _s_h_o_w on the  next  message  in  the  specified  (or
+                 current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+                 gram _s_h_o_w_p_r_o_c, which is called to list the message.   This  command
+                 is  almost  exactly  equivalent to "show next".  Consult the manual
+                 entry for _s_h_o_w (1) for all the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 showproc:            Program to show the message
+
+
+            _S_e_e _A_l_s_o
+                 show(1), prev(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is specified, it will become the current  folder.   The
+                 message that is shown (i.e., the next message in sequence) will be-
+                 come the current message.
+
+
+            _B_u_g_s
+                 _n_e_x_t is really a link to the _s_h_o_w program.  As  a  result,  if  you
+                 make  a  link  to  _n_e_x_t and that link is not called _n_e_x_t, your link
+                 will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+                 profile-entry  for the link to your _M_H profile and add the argument
+                 _n_e_x_t to the entry.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PACKF(1)                          -66-                          PACKF(1)
+
+
+            _N_A_M_E
+                 packf - compress an MH folder into a single file
+
+            _S_Y_N_O_P_S_I_S
+                 packf [+folder] [msgs] [-file name] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_a_c_k_f takes messages from a folder and  copies  them  to  a  single
+                 file.  Each message in the file is separated by four CTRL-A's and a
+                 newline.  Messages packed can be unpacked using _i_n_c.
+
+                 If the _n_a_m_e given to the `-file name' switch exists, then the  mes-
+                 sages  specified will be appended to the end of the file, otherwise
+                 the file will be created and the messages appended.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 .msgbox.map                         A binary index of the file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Msg-Protect:         To set mode when creating a new `file'
+
+
+            _S_e_e _A_l_s_o
+                 inc(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-file ./msgbox'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The first
+                 message packed will become the current message.
+
+
+            _B_u_g_s
+                 _P_a_c_k_f doesn't handle the old  UUCP-style  "mbox"  format  (used  by
+                 _S_e_n_d_M_a_i_l).   To  pack  messages  into  this  format, use the script
+                 /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_p_a_c_k_m_b_o_x.  Note that _p_a_c_k_m_b_o_x does not  take  the
+                 `-file' option of _p_a_c_k_f, and instead writes its output on _s_t_d_o_u_t.
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -67-                           PICK(1)
+
+
+            _N_A_M_E
+                 pick - select messages by content
+
+            _S_Y_N_O_P_S_I_S
+                 pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+                      [-lbrace ... -rbrace] [--component pattern] [-cc pattern]
+                      [-date pattern] [-from pattern] [-search pattern]
+                      [-subject pattern] [-to pattern] [-after date] [-before date]
+                      [-datefield field] [-sequence name ...] [-public] [-nopublic]
+                      [-zero] [-nozero] [-list] [-nolist] [-help]
+
+                 typically:
+                      scan `pick -from jones`
+                      pick -to holloway -sequence select
+                      show `pick -before friday`
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_i_c_k searches messages within a folder for the specified  contents,
+                 and then identifies those messages.  Two types of search primitives
+                 are available: pattern matching and date constraint operations.
+
+                 A modified _g_r_e_p(1) is used to perform the  matching,  so  the  full
+                 regular  expression  (see _e_d(1)) facility is available within `pat-
+                 tern'.  With `-search', `pattern' is used directly,  and  with  the
+                 others, the grep pattern constructed is:
+
+                      "component[ \t]*:.*pattern"
+
+                 This means that the pattern specified for a `-search' will be found
+                 everywhere in the message, including the header and the body, while
+                 the other pattern matching  requests  are  limited  to  the  single
+                 specified component.  The expression
+
+                      `--component pattern'
+
+                 is a shorthand for specifying
+
+                      `-search "component[ \t]*:.*pattern" '
+
+                 It is used to pick a component which is not one  of  "To:",  "cc:",
+                 "Date:",     "From:",     or    "Subject:".     An    example    is
+                 `pick --reply-to pooh'.
+
+                 Pattern matching is performed on  a  per-line  basis.   Within  the
+                 header  of the message, each component is treated as one long line,
+                 but in the body, each line is separate.  Lower-case letters in  the
+                 search  pattern  will  match either lower or upper case in the mes-
+                 sage, while upper case will match only upper case.
+
+                 Note that since the `-date' switch is a pattern matching  operation
+                 (as  described  above), to find messages sent on a certain date the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -68-                           PICK(1)
+
+
+                 pattern string must match the text of the "Date:" field of the mes-
+                 sage.
+
+                 Independent of  any  pattern  matching  operations  requested,  the
+                 switches `-after date' or `-before date' may also be used to intro-
+                 duce date/time contraints on all of the messages.  By default,  the
+                 "Date:"  field  is  consulted,  but  if another date yielding field
+                 (such as "BB-Posted:" or  "Delivery-Date:")  should  be  used,  the
+                 `-datefield field' switch may be used.
+
+                 With `-before' and `-after', _p_i_c_k  will  actually  parse  the  date
+                 fields in each of the messages specified in `msgs' and compare them
+                 to the date/time specified.  If `-after' is given, then only  those
+                 messages  whose  "Date:"  field  value is chronologically after the
+                 date specified will be considered.  The `-before' switch  specifies
+                 the complimentary action.
+
+                 Both the `-after' and `-before' switches take legal 822-style  date
+                 specifications  as  arguments.   _P_i_c_k  will default certain missing
+                 fields so that the entire date need not be specified.  These fields
+                 are  (in  order  of defaulting): timezone, time and timezone, date,
+                 date and timezone.  All defaults are taken from the  current  date,
+                 time, and timezone.
+
+                 In addition to 822-style dates, _p_i_c_k will also recognize any of the
+                 days  of  the week ("sunday", "monday", and so on), and the special
+                 dates "today", "yesterday" (24 hours ago), and "tomorrow" (24 hours
+                 from  now).   All  days of the week are judged to refer to a day in
+                 the past (e.g.,  telling  _p_i_c_k  "saturday"  on  a  "tuesday"  means
+                 "last saturday" not "this saturday").
+
+                 Finally, in addition to these  special  specifications,  _p_i_c_k  will
+                 also  honor a specification of the form "-dd", which means "dd days
+                 ago".
+
+                 _P_i_c_k supports complex boolean operations on  the  searching  primi-
+                 tives  with  the  `-and',  `-or', `-not', and `-lbrace ... -rbrace'
+                 switches.  For example,
+
+                      pick -after yesterday -and
+                           -lbrace -from freida -or -from fear -rbrace
+
+                 identifies messages recently sent by "frieda" or "fear".
+
+                 The matching primitives take precedence  over  the  `-not'  switch,
+                 which in turn takes precedence over `-and' which in turn takes pre-
+                 cedence over  `-or'.   To  override  the  default  precedence,  the
+                 `-lbrace'  and `-rbrace' switches are provided, which act just like
+                 opening and closing parentheses in logical expressions.
+
+                 If no search criteria are given, all the messages specified on  the
+                 command line are selected (this defaults to "all").
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -69-                           PICK(1)
+
+
+                 Once the search has been performed, if the `-list' switch is given,
+                 the  message  numbers  of  the selected messages are written to the
+                 standard output separated by newlines.  This  is  _e_x_t_r_e_m_e_l_y  useful
+                 for quickly generating arguments for other _M_H programs by using the
+                 "backquoting" syntax of the shell.  For example, the command
+
+                      scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+                 says to _s_c_a_n those messages in the indicated folder which meet  the
+                 appropriate criterion.  Note that since _p_i_c_k 's context changes are
+                 written out prior to _s_c_a_n 's invocation,  you  need  not  give  the
+                 folder argument to _s_c_a_n as well.
+
+                 Regardless of the operation of the `-list' switch,  the  `-sequence
+                 name' switch may be given once for each sequence the user wishes to
+                 define.  For each sequence named, that sequence will be defined  to
+                 mean exactly those messages selected by _p_i_c_k.  For example,
+
+                      pick -from frated -seq fred
+
+                 defines a new message sequence for the current folder called "fred"
+                 which contains exactly those messages that were selected.
+
+                 Note that whenever _p_i_c_k processes  a  `-sequence name'  switch,  it
+                 sets `-nolist'.
+
+                 By default, _p_i_c_k will zero the sequence  before  adding  it.   This
+                 action  can be disabled with the `-nozero' switch, which means that
+                 the messages selected by _p_i_c_k will be added to the sequence, if  it
+                 already  exists,  and  any messages already a part of that sequence
+                 will remain so.
+
+                 The `-public' and `-nopublic' switches are used by _p_i_c_k in the same
+                 way _m_a_r_k uses them.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 mark(1)
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -70-                           PICK(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-datefield date'
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-zero'
+                 `-list' is the default if no `-sequence', `-nolist' otherwise
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the _p_i_c_k command would _s_h_o_w,  _s_c_a_n,  or
+                 _r_e_f_i_l_e  the  selected  messages.   This was rather "inverted logic"
+                 from the UNIX point of view, so _p_i_c_k  was  changed  to  define  se-
+                 quences  and  output  those  sequences.  Hence, _p_i_c_k can be used to
+                 generate the arguments for all other _M_H commands, instead of giving
+                 _p_i_c_k endless switches for invoking those commands itself.
+
+                 Also, previous versions of _p_i_c_k balked  if  you  didn't  specify  a
+                 search  string or a date/time constraint.  The current version does
+                 not, and merely matches the messages you specify.   This  lets  you
+                 type something like:
+
+                      show `pick last:20 -seq fear`
+
+                 instead of typing
+
+                      mark -add -nozero -seq fear last:20
+                      show fear
+
+                 Finally, timezones used to be ignored when  comparing  dates:  they
+                 aren't any more.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 Use "pick sequence -list" to enumerate the messages in  a  sequence
+                 (such as for use by a shell script).
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PICK(1)                           -71-                           PICK(1)
+
+
+            _B_u_g_s
+                 The argument to the `-after' and `-before' switches must be  inter-
+                 preted  as  a  single token by the shell that invokes _p_i_c_k.  There-
+                 fore, one must usually place the argument  to  this  switch  inside
+                 double-quotes.  Furthermore, any occurance of `-datefield' must oc-
+                 cur prior to the `-after' or `-before' switch it applies to.
+
+                 If _p_i_c_k is used in a back-quoted operation, such as
+
+                      scan `pick -from jones`
+
+                 and _p_i_c_k selects no messages (e.g., no messages are from  "jones"),
+                 then  the  shell  will  still run the outer command (e.g., "scan").
+                 Since no messages were matched, _p_i_c_k produced no  output,  and  the
+                 argument given to the outer command as a result of backquoting _p_i_c_k
+                 is empty.  In the case of _M_H programs, the outer command  now  acts
+                 as  if  the  default `msg' or `msgs' should be used (e.g., "all" in
+                 the case of  _s_c_a_n ).   To  prevent  this  unexpected  behavior,  if
+                 `-list'  was  given,  and if its standard output is not a tty, then
+                 _p_i_c_k outputs the illegal message number "0" when  it  fails.   This
+                 lets the outer command fail gracefully as well.
+
+                 The pattern syntax "[l-r]" is not  supported;  each  letter  to  be
+                 matched must be included within the square brackets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PREV(1)                           -72-                           PREV(1)
+
+
+            _N_A_M_E
+                 prev - show the previous message
+
+            _S_Y_N_O_P_S_I_S
+                 prev [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [-switches for _s_h_o_w_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_r_e_v performs a _s_h_o_w on the previous message in the  specified  (or
+                 current)  folder.  Like _s_h_o_w, it passes any switches on to the pro-
+                 gram named by _s_h_o_w_p_r_o_c, which is called to list the message.   This
+                 command  is  almost exactly equivalent to "show prev".  Consult the
+                 manual entry for _s_h_o_w (1) for all the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 showproc:            Program to show the message
+
+
+            _S_e_e _A_l_s_o
+                 show(1), next(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is specified, it will become the current  folder.   The
+                 message that is shown (i.e., the previous message in sequence) will
+                 become the current message.
+
+
+            _B_u_g_s
+                 _p_r_e_v is really a link to the _s_h_o_w program.  As  a  result,  if  you
+                 make  a  link  to  _p_r_e_v and that link is not called _p_r_e_v, your link
+                 will  act  like  _s_h_o_w  instead.   To   circumvent   this,   add   a
+                 profile-entry  for the link to your _M_H profile and add the argument
+                 _p_r_e_v to the entry.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -73-                       PROMPTER(1)
+
+
+            _N_A_M_E
+                 prompter - prompting editor front-end for MH
+
+            _S_Y_N_O_P_S_I_S
+                 prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+                      [-norapid] [-doteof] [-nodoteof] file [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 This program is normally not invoked directly by  users  but  takes
+                 the  place  of  an  editor  and  acts  as  an editor front-end.  It
+                 operates on an 822-style message draft skeleton specified by  file,
+                 normally provided by _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l.
+
+                 _P_r_o_m_p_t_e_r is an editor which allows rapid composition  of  messages.
+                 It  is particularly useful to network and low-speed (less than 2400
+                 baud) users of _M_H.  It is an _M_H program in that it can have its own
+                 profile  entry with switches, but it is not invoked directly by the
+                 user.  The commands _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l invoke  _p_r_o_m_p_t_e_r  as
+                 an  editor,  either when invoked with `-editor prompter', or by the
+                 profile  entry  "Editor: prompter",  or  when  given  the   command
+                 `edit prompter' at "What now?" level.
+
+                 For each empty component _p_r_o_m_p_t_e_r finds in the draft, the  user  is
+                 prompted  for a response; A <RETURN> will cause the whole component
+                 to be left out.  Otherwise, a `\' preceding a  <RETURN>  will  con-
+                 tinue  the  response  on the next line, allowing for multiline com-
+                 ponents.  Continuation lines must begin with a space or tab.
+
+                 Each non-empty component is copied to the draft  and  displayed  on
+                 the terminal.
+
+                 The start of the message body is denoted by a blank line or a  line
+                 of dashes.  If the body is non-empty, the prompt, which isn't writ-
+                 ten to the file, is
+
+                     "--------Enter additional text",
+
+                 or (if `-prepend' was given)
+
+                     "--------Enter initial text".
+
+                 Message-body typing is  terminated  with  an  end-of-file  (usually
+                 CTRL-D).   With  the  `-doteof'  switch,  a period on a line all by
+                 itself also  signifies  end-of-file.   At  this  point  control  is
+                 returned  to  the  calling  program,  where the user is asked "What
+                 now?".  See _w_h_a_t_n_o_w for the valid options to this query.
+
+                 By using the `-prepend' switch, the user can  add  type-in  to  the
+                 beginning of the message body and have the rest of the body follow.
+                 This is useful for the _f_o_r_w command.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -74-                       PROMPTER(1)
+
+
+                 By using the `-rapid' switch, if the draft already contains text in
+                 the message-body, it is not displayed on the user's terminal.  This
+                 is useful for low-speed terminals.
+
+                 The line editing characters for kill and erase may be specified  by
+                 the  user via the arguments `-kill chr' and `-erase chr', where chr
+                 may be a character; or `\nnn', where "nnn" is the octal  value  for
+                 the character.
+
+                 An interrupt (usually CTRL-C) during component  typing  will  abort
+                 _p_r_o_m_p_t_e_r  and  the _M_H command that invoked it.  An interrupt during
+                 message-body typing is equivalent to CTRL-D,  for  historical  rea-
+                 sons.  This means that _p_r_o_m_p_t_e_r should finish up and exit.
+
+                 The first non-flag argument to _p_r_o_m_p_t_e_r is taken as the name of the
+                 draft file, and subsequent non-flag arguments are ignored.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /tmp/prompter*                      Temporary copy of message
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 prompter-next:       To name the editor to be  used  on  exit  from
+                 _p_r_o_m_p_t_e_r
+                 Msg-Protect:         To set mode when creating a new draft
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prepend'
+                 `-norapid'
+                 `-nodoteof'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 The  `-rapid'  option  is  particularly  useful  with   _f_o_r_w,   and
+                 `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+                 The user may wish to link _p_r_o_m_p_t_e_r under several names (e.g.,  "ra-
+                 pid")  and  give  appropriate switches in the profile entries under
+                 these names (e.g., "rapid:  -rapid").   This  facilitates  invoking
+                 prompter  differently for different _M_H commands (e.g., "forw: -edi-
+                 tor rapid").
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            PROMPTER(1)                       -75-                       PROMPTER(1)
+
+
+            _B_u_g_s
+                 _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will lose if  you  edit  files  with
+                 nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RCVSTORE(1)                       -76-                       RCVSTORE(1)
+
+
+            _N_A_M_E
+                 rcvstore - incorporate new mail asynchronously
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+                      [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_c_v_s_t_o_r_e incorporates a message from the standard input into an  _M_H
+                 folder.   If  `+folder'  isn't specified, a folder in the user's _M_H
+                 directory will be used, either that specified by the "Inbox:" entry
+                 in  the  user's profile, or the folder named "inbox".  The new mes-
+                 sage being incorporated is assigned the next highest number in  the
+                 folder.   If  the specified (or default) folder doesn't exist, then
+                 it will be created if the `-create' option is specified,  otherwise
+                 _r_c_v_s_t_o_r_e will exit.
+
+                 If the user's profile contains a "Msg-Protect: nnn" entry, it  will
+                 be  used as the protection on the newly created messages, otherwise
+                 the _M_H default of 0644 will be used.  During all operations on mes-
+                 sages,  this  initially  assigned  protection will be preserved for
+                 each message, so _c_h_m_o_d(1) may be used to set  a  protection  on  an
+                 individual   message,   and   its   protection  will  be  preserved
+                 thereafter.
+
+                 _R_c_v_s_t_o_r_e will incorporate anything except zero length messages into
+                 the user's MH folder.
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+                 then  _r_c_v_s_t_o_r_e  will  add  the  newly  incorporated message to each
+                 sequence named by the  profile  entry.   This  is  similar  to  the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.  Note that _r_c_v_s_t_o_r_e will  not
+                 zero each sequence prior to adding messages.
+
+                 Furthermore, the incoming messages may  be  added  to  user-defined
+                 sequences  as  they  arrive  by  appropriate use of the `-sequence'
+                 option.  As with _p_i_c_k, use of the `-zero'  and  `-nozero'  switches
+                 can  also  be used to zero old sequences or not.  Similarly, use of
+                 the `-public' and `-nopublic switches may be used  to  force  addi-
+                 tions to public and private sequences.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RCVSTORE(1)                       -77-                       RCVSTORE(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Folder-Protect:      To set mode when creating a new folder
+                 Inbox:               To find the default inbox
+                 Msg-Protect:         To set mode when creating a new message
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), pick(1), mh-mail(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to "inbox"
+                 `-create'
+                 `-nopublic' if the folder is read-only, `-public' otherwise
+                 `-nozero'
+
+
+            _C_o_n_t_e_x_t
+                 No context changes will be attempted, with  the  exception  of  se-
+                 quence manipulation.
+
+
+            _B_u_g_s
+                 If you use the "Unseen-Sequence" profile entry, _r_c_v_s_t_o_r_e could  try
+                 to update the context while another _M_H process is also trying to do
+                 so.  This can cause the context  to  become  corrupted.   To  avoid
+                 this,  do not use _r_c_v_s_t_o_r_e if you use the "Unseen-Sequence" profile
+                 entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REFILE(1)                         -78-                         REFILE(1)
+
+
+            _N_A_M_E
+                 refile - file message in other folders
+
+            _S_Y_N_O_P_S_I_S
+                 refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+                      [-src +folder] [-file file] [-rmmproc program] [-normmproc]
+                      +folder ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_e_f_i_l_e moves (_m_v (1)) or links  (_l_n (1))  messages  from  a  source
+                 folder  into  one  or  more destination folders.  If you think of a
+                 message as a sheet of paper, this operation is  not  unlike  filing
+                 the  sheet  of  paper  (or copies) in file cabinet folders.  When a
+                 message is filed, it is linked into the  destination  folder(s)  if
+                 possible,  and  is  copied  otherwise.   As long as the destination
+                 folders are all on the same file  system,  multiple  filing  causes
+                 little  storage  overhead.   This  facility  provides a good way to
+                 cross-file or multiply-index messages.  For example, if  a  message
+                 is received from Jones about the ARPA Map Project, the command
+
+                      refile cur +jones +Map
+
+                 would allow the message to be found in either of  the  two  folders
+                 `jones' or `Map'.
+
+                 The option `-file file' directs _r_e_f_i_l_e to use the specified file as
+                 the  source  message  to  be  filed,  rather  than a message from a
+                 folder.  Note that the file should be a validly formatted  message,
+                 just like any other _M_H message.  It should NOT be in mail drop for-
+                 mat (to convert a file in mail drop format to a folder of  _M_H  mes-
+                 sages, see _i_n_c (1)).
+
+                 If a destination folder doesn't exist, _r_e_f_i_l_e will ask if you  want
+                 to  create  it.  A negative response will abort the file operation.
+                 If the standard input for _r_e_f_i_l_e is _n_o_t a tty, then _r_e_f_i_l_e will not
+                 ask any questions and will proceed as if the user answered "yes" to
+                 all questions.
+
+                 The option `-link' preserves the source folder copy of the  message
+                 (i.e.,  it  does  a  _l_n(1) rather than a _m_v(1)), whereas, `-nolink'
+                 deletes the filed messages from the source folder.  Normally,  when
+                 a  message  is filed, it is assigned the next highest number avail-
+                 able in each of the destination folders.  Use  of  the  `-preserve'
+                 switch  will override this message renaming, but name conflicts may
+                 occur, so use this switch cautiously.
+
+                 If `-link' is not specified (or `-nolink' is specified), the  filed
+                 messages  will  be removed from the source folder, by renaming them
+                 with a site-dependent prefix (usually a comma).
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REFILE(1)                         -79-                         REFILE(1)
+
+
+                 If the user has a profile component such as
+
+                         rmmproc:        /bin/rm
+
+                 then _r_e_f_i_l_e will instead call the named program to delete the  mes-
+                 sage files.  The user may specify `-rmmproc program' on the command
+                 line to override  this  profile  specification.   The  `-normmproc'
+                 option  forces  the message files to be deleted by renaming them as
+                 described above.
+
+                 The `-draft' switch tells _r_e_f_i_l_e to file the <mh-dir>/draft.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Folder-Protect:      To set mode when creating a new folder
+                 rmmproc:             Program to delete the message
+
+
+            _S_e_e _A_l_s_o
+                 folder(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-src +folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-nolink'
+                 `-nopreserve'
+
+
+            _C_o_n_t_e_x_t
+                 If `-src +folder' is given, it will become the current folder.   If
+                 neither  `-link' nor `all' is specified, the current message in the
+                 source folder will be set to the last message specified; otherwise,
+                 the current message won't be changed.
+
+                 If the Previous-Sequence profile entry is set, in addition  to  de-
+                 fining the named sequences from the source folder, _r_e_f_i_l_e will also
+                 define  those  sequences  for   the   destination   folders.    See
+                 _m_h-_s_e_q_u_e_n_c_e (5) for information concerning the previous sequence.
+
+
+            _B_u_g_s
+                 Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+                 must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+                 create an infinte loop.
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -80-                           REPL(1)
+
+
+            _N_A_M_E
+                 repl - reply to a message
+
+            _S_Y_N_O_P_S_I_S
+                 repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+                      [-nocc all/to/cc/me] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-editor editor]
+                      [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+                      [-inplace] [-noinplace] [-query] [-noquery] [-width columns]
+                      [-whatnowproc program] [-nowhatnowproc] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_e_p_l aids a user in producing a reply to an existing message.  _R_e_p_l
+                 uses  a  reply  template to guide its actions when constructing the
+                 message draft of the reply.  In its simplest form  (with  no  argu-
+                 ments),  it  will  set  up  a message-form skeleton in reply to the
+                 current message in the  current  folder,  and  invoke  the  whatnow
+                 shell.   The  default  reply template will direct _r_e_p_l to construct
+                 the composed message as follows:
+
+                      To: <Reply-To> or <From>
+                      cc: <cc>, <To>, and yourself
+                      Subject: Re: <Subject>
+                      In-reply-to: Your message of <Date>.
+                                   <Message-Id>
+
+                 where field names enclosed in angle  brackets  (< >)  indicate  the
+                 contents  of the named field from the message to which the reply is
+                 being made.  A  reply  template  is  simply  a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 The `-cc type' switch takes an argument which  specifies  who  gets
+                 placed  on  the "cc:" list of the reply.  The `-query' switch modi-
+                 fies the action of `-cc type' switch by interactively asking you if
+                 each  address  that normally would be placed in the "To:" and "cc:"
+                 list  should  actually  be  sent  a  copy.   (This  is  useful  for
+                 special-purpose  replies.)  Note that the position of the `-cc' and
+                 `-nocc' switches, like all other switches which take a positive and
+                 negative form, is important.
+
+                 Lines beginning with the fields "To:", "cc:", and  "Bcc:"  will  be
+                 standardized  and  have  duplicate addresses removed.  In addition,
+                 the `-width columns' switch will guide _r_e_p_l's formatting  of  these
+                 fields.
+
+                 If the file named "replcomps" exists in the user's MH directory, it
+                 will be used instead of the default form.  In either case, the file
+                 specified by `-form formfile' will be used if given.
+
+                 If the draft already exists, _r_e_p_l will ask you as to  the  disposi-
+                 tion  of  the  draft.  A reply of quit will abort _r_e_p_l, leaving the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -81-                           REPL(1)
+
+
+                 draft intact; replace will replace the existing draft with a  blank
+                 skeleton; and list will display the draft.
+
+                 See _c_o_m_p (1) for a  description  of  the  `-editor'  and  `-noedit'
+                 switches.  Note that while in the editor, the message being replied
+                 to is available through a link  named  "@"  (assuming  the  default
+                 _w_h_a_t_n_o_w_p_r_o_c ).   In addition, the actual pathname of the message is
+                 stored in the envariable $editalt, and the pathname of  the  folder
+                 containing the message is stored in the envariable $mhfolder.
+
+                 Although _r_e_p_l uses the `-form formfile' switch to direct it how  to
+                 construct  the  beginning  of  the  draft, the `-filter filterfile'
+                 switch directs _r_e_p_l as to how the message being  replied-to  should
+                 be  formatted in the body of the draft.  If `-filter' is not speci-
+                 fied, then the message being replied-to is not included in the body
+                 of  the draft.  If `-filter filterfile' is specified, then the mes-
+                 sage being replied-to is filtered  (re-formatted)  prior  to  being
+                 output  to  the body of the draft.  The filter file for _r_e_p_l should
+                 be a standard form file for _m_h_l, as _r_e_p_l will invoke _m_h_l to  format
+                 the  message  being replied-to.  There is no default message filter
+                 (`-filter' must be followed by a file name).  A filter file that is
+                 commonly used is:
+
+                      :
+                      body:nocomponent,compwidth=9,offset=9
+
+                 which says to output a blank line and then the body of the  message
+                 being replied-to, indented by one tab-stop.  Another format popular
+                 on USENET is:
+
+
+                      message-id:nocomponent,nonewline,\
+                      formatfield="In message %{text}, "
+                      from:nocomponent,formatfield="%(friendly{text}) writes:"
+                      body:component=">",overflowtext=">",overflowoffset=0
+
+                 Which  cites  the  Message-ID  and  author  of  the  message  being
+                 replied-to,  and  then  outputs each line of the body prefaced with
+                 the ">" character.
+
+                 If the `-annotate' switch is given, the  message  being  replied-to
+                 will be annotated with the lines
+
+                      Replied: date
+                      Replied: addrs
+
+                 where the address list contains one line for each  addressee.   The
+                 annotation  will  be done only if the message is sent directly from
+                 _r_e_p_l.   If  the  message  is  not  sent  immediately   from   _r_e_p_l,
+                 "comp -use"  may  be  used to re-edit and send the constructed mes-
+                 sage, but the annotations won't take place.  The `-inplace'  switch
+                 causes annotation to be done in place in order to preserve links to
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -82-                           REPL(1)
+
+
+                 the annotated message.
+
+                 The `-fcc +folder' switch can be used to  automatically  specify  a
+                 folder  to  receive Fcc:s.  More than one folder, each preceeded by
+                 `-fcc' can be named.
+
+                 In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _r_e_p_l also recog-
+                 nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+                 _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 _f_c_c     string   Any folders specified with `-fcc folder'
+
+                 To avoid reiteration, _r_e_p_l strips any leading `Re: '  strings  from
+                 the _s_u_b_j_e_c_t component.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 Upon exiting from the editor, _r_e_p_l will invoke the _w_h_a_t_n_o_w program.
+                 See _w_h_a_t_n_o_w (1) for a discussion of available options.  The invoca-
+                 tion of this program can be inhibited by using the `-nowhatnowproc'
+                 switch.   (In truth of fact, it is the _w_h_a_t_n_o_w program which starts
+                 the initial edit.  Hence, `-nowhatnowproc' will  prevent  any  edit
+                 from occurring.)
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/replcomps         The reply template
+                 or <mh-dir>/replcomps               Rather than the standard template
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/draft                      The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Current-Folder:      To find the default current folder
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 Msg-Protect:         To  set  mode  when  creating  a  new  message
+                 (draft)
+                 fileproc:            Program to refile the message
+                 mhlproc:             Program to filter message being replied-to
+                 whatnowproc:         Program to ask the "What now?" questions
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            REPL(1)                           -83-                           REPL(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msg' defaults to cur
+                 `-nocc all' at ATHENA sites, `-cc all' otherwise
+                 `-noannotate'
+                 `-nodraftfolder'
+                 `-noinplace'
+                 `-noquery'
+                 `-width 72'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  mes-
+                 sage replied-to will become the current message.
+
+
+            _H_i_s_t_o_r_y
+                 Prior to using the format string  mechanism,  `-noformat'  used  to
+                 cause  address  headers to be output as-is.  Now all address fields
+                 are formatted using Internet standard guidelines.
+
+
+            _B_u_g_s
+                 If any addresses occur in the reply template, addresses in the tem-
+                 plate that do not contain hosts are defaulted incorrectly.  Instead
+                 of using the localhost for the  default,  _r_e_p_l  uses  the  sender's
+                 host.   Moral of the story: if you're going to include addresses in
+                 a reply template, include the host portion of the address.
+
+                 The `-width columns' switch is only  used  to  do  address-folding;
+                 other headers are not line-wrapped.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _r_e_p_l uses a  built-in  _w_h_a_t_n_o_w,  it
+                 does  not  actually  run the _w_h_a_t_n_o_w program.  Hence, if you define
+                 your own _w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w since  _r_e_p_l  won't  run
+                 it.
+
+                 If your current working directory is not writable, the  link  named
+                 "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMF(1)                            -84-                            RMF(1)
+
+
+            _N_A_M_E
+                 rmf - remove an MH folder
+
+            _S_Y_N_O_P_S_I_S
+                 rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_m_f removes all of the messages (files) within  the  specified  (or
+                 default)  folder,  and  then removes the folder (directory) itself.
+                 If there are any files within the folder which are not  a  part  of
+                 _M_H,  they  will  _n_o_t be removed, and an error will be produced.  If
+                 the folder is given explicitly or the  `-nointeractive'  option  is
+                 given,  then the folder will be removed without confirmation.  Oth-
+                 erwise, the user will be asked for confirmation.  If _r_m_f can't find
+                 the  current  folder,  for  some  reason,  the folder to be removed
+                 defaults to `+inbox' (unless overridden  by  user's  profile  entry
+                 "Inbox") with confirmation.
+
+                 _R_m_f irreversibly deletes messages that don't have other  links,  so
+                 use it with caution.
+
+                 If the folder being removed is a subfolder, the parent folder  will
+                 become  the new current folder, and _r_m_f will produce a message tel-
+                 ling the user this has happened.  This provides an  easy  mechanism
+                 for selecting a set of messages, operating on the list, then remov-
+                 ing the list and returning to the current  folder  from  which  the
+                 list was extracted.
+
+                 _R_m_f of a read-only folder will delete the private sequence and  cur
+                 information  (i.e.,  "atr-_s_e_q-_f_o_l_d_e_r"  entries)  from  the  profile
+                 without affecting the folder itself.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Inbox:               To find the default inbox
+
+
+            _S_e_e _A_l_s_o
+                 rmm(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder, usually with confirmation
+                 `-interactive' if +folder' not given, `-nointeractive' otherwise
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMF(1)                            -85-                            RMF(1)
+
+
+            _C_o_n_t_e_x_t
+                 _R_m_f will set the current folder to the parent folder if a subfolder
+                 is  removed; or if the current folder is removed, it will make "in-
+                 box" current.  Otherwise, it doesn't change the current  folder  or
+                 message.
+
+
+            _B_u_g_s
+                 Although intuitively one would suspect that _r_m_f works  recursively,
+                 it  does  not.   Hence if you have a sub-folder within a folder, in
+                 order to _r_m_f the parent, you must first _r_m_f each of the children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMM(1)                            -86-                            RMM(1)
+
+
+            _N_A_M_E
+                 rmm - remove messages
+
+            _S_Y_N_O_P_S_I_S
+                 rmm [+folder] [msgs] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _R_m_m removes the specified messages by renaming  the  message  files
+                 with preceding commas.  Many sites consider files that start with a
+                 comma to be a temporary backup, and arrange for _c_r_o_n (8) to  remove
+                 such files once a day.
+
+                 If the user has a profile component such as
+
+                         rmmproc:        /bin/rm
+
+                 then instead of simply renaming the message file, _r_m_m will call the
+                 named program to delete the file.  Note that at most installations,
+                 _c_r_o_n (8) is told to remove files that begin with  a  comma  once  a
+                 night.
+
+                 Some users of csh prefer the following:
+
+                         alias rmm 'refile +d'
+
+                 where folder +d is a folder for deleted messages, and
+
+                         alias mexp 'rm `mhpath +d all`'
+
+                 is used to "expunge" deleted messages.
+
+                 The current message is not changed by _r_m_m, so a _n_e_x_t  will  advance
+                 to the next message in the folder as expected.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 rmmproc:             Program to delete the message
+
+
+            _S_e_e _A_l_s_o
+                 rmf(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            RMM(1)                            -87-                            RMM(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _B_u_g_s
+                 Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the message,  the  _r_m_m_p_r_o_c
+                 must  NOT  call _r_e_f_i_l_e without specifying `-normmproc', or you will
+                 create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                           -88-                           SCAN(1)
+
+
+            _N_A_M_E
+                 scan - produce a one line per message scan listing
+
+            _S_Y_N_O_P_S_I_S
+                 scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+                      [-format string] [-header] [-noheader] [-width columns]
+                      [-reverse] [-noreverse] [-file filename] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_c_a_n produces a one-line-per-message listing of the specified  mes-
+                 sages.   Each  _s_c_a_n  line  contains  the message number (name), the
+                 date, the "From:" field, the "Subject" field, and, if room  allows,
+                 some of the body of the message.  For example:
+
+                      15+  7/ 5  Dcrocker  nned  <<Last week I asked some of
+                      16 - 7/ 5  dcrocker  message id format  <<I recommend
+                      18   7/ 6  Obrien    Re: Exit status from mkdir
+                      19   7/ 7  Obrien    "scan" listing format in MH
+
+                 The `+' on message 15 indicates that it  is  the  current  message.
+                 The  `-'  on  message  16 indicates that it has been replied to, as
+                 indicated by a "Replied:"  component  produced  by  an  `-annotate'
+                 switch to the _r_e_p_l command.
+
+                 If there is sufficient room left on the _s_c_a_n line  after  the  sub-
+                 ject,  the line will be filled with text from the body, preceded by
+                 <<, and terminated by >> if the body is sufficiently  short.   _S_c_a_n
+                 actually  reads  each  of the specified messages and parses them to
+                 extract the desired fields.  During parsing, appropriate error mes-
+                 sages  will  be  produced  if there are format errors in any of the
+                 messages.
+
+                 The `-header' switch produces a header line prior to the _s_c_a_n list-
+                 ing.   Currently,  the  name of the folder and the current date and
+                 time are output (see the HISTORY section for more information).
+
+                 If the `-clear' switch is used and _s_c_a_n'_s output is directed  to  a
+                 terminal, then _s_c_a_n will consult the $TERM and $TERMCAP envariables
+                 to determine your terminal type in order to find out how  to  clear
+                 the  screen  prior  to exiting.  If the `-clear' switch is used and
+                 _s_c_a_n'_s output is not directed to a terminal  (e.g.,  a  pipe  or  a
+                 file), then _s_c_a_n will send a formfeed prior to exiting.
+
+                 For example, the command:
+
+                      (scan -clear -header; show all -show pr -f) | lpr
+
+                 produces a scan listing  of  the  current  folder,  followed  by  a
+                 formfeed,  followed  by  a formatted listing of all messages in the
+                 folder, one per page.  Omitting `-show pr -f' will cause  the  mes-
+                 sages  to  be  concatenated, separated by a one-line header and two
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                           -89-                           SCAN(1)
+
+
+                 blank lines.
+
+                 If _s_c_a_n encounters a message without a "Date:" field,  rather  than
+                 leaving  that  portion  of  the  scan  listing  blank,  the date is
+                 filled-in with the last write date of the message,  and  post-fixed
+                 with  a  `*'.   This  is  particularly  handy  for scanning a _d_r_a_f_t
+                 _f_o_l_d_e_r, as message drafts usually aren't allowed to have  dates  in
+                 them.
+
+                 To override the output format used by _s_c_a_n, the `-format string' or
+                 `-form file'  switches are used.  This permits individual fields of
+                 the scan listing to be extracted with ease.  The string is simply a
+                 format   string  and  the  file  is  simply  a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes, _s_c_a_n also recog-
+                 nizes the following additional _c_o_m_p_o_n_e_n_t escapes:
+
+                 _E_s_c_a_p_e    _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 body      string   the (compressed) first part of the body
+                 dtimenow  date     the current date
+                 folder    string   the name of the current folder
+
+                 Also, if no date header was present in the  message,  the  _f_u_n_c_t_i_o_n
+                 escapes  which operate on {_d_a_t_e} will return values for the date of
+                 last modification of the message file itself.
+
+                 _s_c_a_n will update the _M_H context prior to starting the  listing,  so
+                 interrupting  a  long  _s_c_a_n  listing preserves the new context.  _M_H
+                 purists hate this idea.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Alternate-Mailboxes: To determine the user's mailboxes
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 inc(1), pick(1), show(1), mh-format(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the folder current
+                 `msgs' defaults to all
+                 `-format' defaulted as described above
+                 `-noheader'
+                 `-width' defaulted to the width of the terminal
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SCAN(1)                           -90-                           SCAN(1)
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.
+
+
+            _H_i_s_t_o_r_y
+                 Prior to using the format string mechanism, `-header' used to  gen-
+                 erate a heading saying what each column in the listing was.  Format
+                 strings prevent this from happening.
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _s_c_a_n.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+                 The value of each _c_o_m_p_o_n_e_n_t escape is set by _s_c_a_n to  the  contents
+                 of  the first message header _s_c_a_n encounters with the corresponding
+                 component name; any following headers with the same component  name
+                 are ignored.
+
+                 The switch `-reverse', makes _s_c_a_n list the messages in reverse ord-
+                 er; this should be considered a bug.
+
+                 The `-file filename' switch allows the user to obtain a _s_c_a_n  list-
+                 ing of a maildrop file as produced by _p_a_c_k_f.  This listing includes
+                 every message in the file.  The user should use _m_s_h for more selec-
+                 tive  processing  of the file.  `-reverse' is ignored with this op-
+                 tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                           -91-                           SEND(1)
+
+
+            _N_A_M_E
+                 send - send a message
+
+            _S_Y_N_O_P_S_I_S
+                 send [-alias aliasfile] [-draft] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+                      [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+                      [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_e_n_d will cause each of the specified files to  be  delivered  (via
+                 _p_o_s_t (8))  to each of the destinations in the "To:", "cc:", "Bcc:",
+                 and "Fcc:" fields of the message.  If  _s_e_n_d  is  re-distributing  a
+                 message,  as invoked from _d_i_s_t, then the corresponding "Resent-xxx"
+                 fields are examined instead.
+
+                 If `-push' is specified, _s_e_n_d will detach itself  from  the  user's
+                 terminal and perform its actions in the background.  If _p_u_s_h 'd and
+                 the draft can't be sent, then the `-forward' switch says that draft
+                 should be forwarded with the failure notice sent to the user.  This
+                 differs from putting _s_e_n_d in the background because the  output  is
+                 trapped and analyzed by _M_H.
+
+                 If `-verbose' is specified, _s_e_n_d  will  indicate  the  interactions
+                 occurring  with the transport system, prior to actual delivery.  If
+                 `-watch' is specified _s_e_n_d will monitor the delivery of  local  and
+                 network  mail.   Hence, by specifying both switches, a large detail
+                 of information can be gathered about each  step  of  the  message's
+                 entry into the transport system.
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 _S_e_n_d with no _f_i_l_e argument will query  whether  the  draft  is  the
+                 intended  file, whereas `-draft' will suppress this question.  Once
+                 the transport system has successfully accepted custody of the  mes-
+                 sage,  the  file will be renamed with a leading comma, which allows
+                 it to be retrieved until the next draft message is sent.  If  there
+                 are errors in the formatting of the message, _s_e_n_d will abort with a
+                 (hopefully) helpful error message.
+
+                 If a "Bcc:" field is encountered, its addresses will  be  used  for
+                 delivery,  and  the  "Bcc:"  field will be removed from the message
+                 sent to sighted recipients.  The blind recipients will  receive  an
+                 entirely  new  message  with a minimal set of headers.  Included in
+                 the body of the message will be a copy of the message sent  to  the
+                 sighted  recipients.   If  `-filter filterfile'  is specified, then
+                 this copy is filtered (re-formatted) prior to  being  sent  to  the
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                           -92-                           SEND(1)
+
+
+                 blind recipients.
+
+                 Prior to sending the message, the  fields  "From: user@local",  and
+                 "Date: now" will be appended to the headers in the message.  If the
+                 envariable $SIGNATURE is set, then its value is used as  your  per-
+                 sonal  name  when constructing the "From:" line of the message.  If
+                 this envariable is not set, then  _s_e_n_d  will  consult  the  profile
+                 entry "Signature" for this information.  On hosts where _M_H was con-
+                 figured with the UCI option, if $SIGNATURE is not set and the "Sig-
+                 nature"   profile   entry   is   not   present,   then   the   file
+                 $HOME/.signature is consulted.  If `-msgid' is  specified,  then  a
+                 "Message-ID:" field will also be added to the message.
+
+                 If _s_e_n_d is re-distributing a message (when invoked by _d_i_s_t ),  then
+                 "Resent-"  will  be  prepended  to  each  of these fields: "From:",
+                 "Date:", and "Message-ID:".  If  the  message  already  contains  a
+                 "From:"  field,  then a "Sender: user@local" field will be added as
+                 well.  (An already existing "Sender:" field is an error!)
+
+                 By using the `-format' switch, each of the entries in the "To:" and
+                 "cc:" fields will be replaced with "standard" format entries.  This
+                 standard format is designed to be usable  by  all  of  the  message
+                 handlers  on  the various systems around the Internet.  If `-nofor-
+                 mat' is given, then headers are output exactly as  they  appear  in
+                 the message draft.
+
+                 If an "Fcc: folder" is encountered, the message will be  copied  to
+                 the  specified folder for the sender in the format in which it will
+                 appear to any non-Bcc receivers of the message.  That is,  it  will
+                 have the appended fields and field reformatting.  The "Fcc:" fields
+                 will be removed from all outgoing copies of the message.
+
+                 By using the `-width columns' switch, the user can direct  _s_e_n_d  as
+                 to how long it should make header lines containing addresses.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read (more than one file,  each   preceeded  by  `-alias',  can  be
+                 named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Aliasfile:           For a default alias file
+                 Signature:           To determine the user's mail signature
+                 mailproc:            Program to post failure notices
+                 postproc:            Program to post the message
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SEND(1)                           -93-                           SEND(1)
+
+
+            _S_e_e _A_l_s_o
+                 comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to <mh-dir>/draft
+                 `-alias /usr/local/lib/mh/MailAliases'
+                 `-nodraftfolder'
+                 `-nofilter'
+                 `-format'
+                 `-forward'
+                 `-nomsgid'
+                 `-nopush'
+                 `-noverbose'
+                 `-nowatch'
+                 `-width 72'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 Under some configurations, it is not possible to mointor  the  mail
+                 delivery transaction; `-watch' is a no-op on those systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                           -94-                           SHOW(1)
+
+
+            _N_A_M_E
+                 show - show (list) messages
+
+            _S_Y_N_O_P_S_I_S
+                 show [+folder] [msgs] [-draft] [-header] [-noheader]
+                      [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_h_o_w lists each of the specified messages to  the  standard  output
+                 (typically,  the  terminal).   Typically,  the  messages are listed
+                 exactly as they are, with no reformatting.  A program named by  the
+                 _s_h_o_w_p_r_o_c  profile  component  is invoked to do the listing, and any
+                 switches not recognized by _s_h_o_w are passed along to  that  program.
+                 The  default program is known as _m_o_r_e (1).  To override the default
+                 and the _s_h_o_w_p_r_o_c profile  component,  use  the  `-showproc program'
+                 switch.   For  example, `-show pr' will cause the _p_r (1) program to
+                 list the messages.  The _M_H command _m_h_l can be used as a _s_h_o_w_p_r_o_c to
+                 show  messages in a more uniform format.  Normally, this program is
+                 specified as the _s_h_o_w_p_r_o_c is the user's .mh_profile.   See  _m_h_l (1)
+                 for  the  details.   If  the  `-noshowproc'  option  is  specified,
+                 `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+                 The `-header' switch tells _s_h_o_w to display a  one-line  description
+                 of  the  message being shown.  This description includes the folder
+                 and the message number.
+
+                 If no `msgs' are specified, the current message is used.   If  more
+                 than  one  message  is  specified,  _m_o_r_e will prompt for a <RETURN>
+                 prior to listing each message.  _m_o_r_e will list each message, a page
+                 at  a  time.   When  the end of page is reached, _m_o_r_e will ring the
+                 bell and wait for a <SPACE> or <RETURN>.  If a <RETURN> is entered,
+                 _m_o_r_e  will print the next line, whereas <SPACE> will print the next
+                 screenful.  To exit _m_o_r_e, type "q".
+
+                 If the standard output is not a terminal, no queries are made,  and
+                 each file is listed with a one-line header and two lines of separa-
+                 tion.
+
+                 "show -draft" will list the file <mh-dir>/draft if it exists.
+
+                 If the profile entry "Unseen-Sequence" is  present  and  non-empty,
+                 then _s_h_o_w will remove each of the messages shown from each sequence
+                 named  by  the   profile   entry.    This   is   similar   to   the
+                 "Previous-Sequence"  profile  entry  supported  by  all _M_H commands
+                 which take `msgs' or `msg' arguments.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                           -95-                           SHOW(1)
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+                 Unseen-Sequence:     To name sequences denoting unseen messages
+                 showproc:            Program to show messages
+
+
+            _S_e_e _A_l_s_o
+                 mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to cur
+                 `-header'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current folder.  The  last
+                 message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SHOW(1)                           -96-                           SHOW(1)
+
+
+            _B_u_g_s
+                 The `-header' switch doesn't work when `msgs' expands to more  than
+                 one  message.   If the _s_h_o_w_p_r_o_c is _m_h_l, then is problem can be cir-
+                 cumvented by referencing the "messagename" field in the _m_h_l  format
+                 file.
+
+                 _S_h_o_w updates the user's context before showing the message.   Hence
+                 _s_h_o_w  will  mark messages as seen prior to the user actually seeing
+                 them.  This is generally not a problem, unless the user  relies  on
+                 the  "unseen"  messages  mechanism, and interrupts _s_h_o_w while it is
+                 showing "unseen" messages.
+
+                 If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w uses a built-in _m_h_l: it does not  ac-
+                 tually  run  the  _m_h_l  program.   Hence,  if  you  define  your own
+                 _s_h_o_w_p_r_o_c, don't call it _m_h_l since _s_h_o_w won't run it.
+
+                 If _m_o_r_e (1) is your showproc (the default), then avoid running _s_h_o_w
+                 in  the  background  with only its standard output piped to another
+                 process, as in
+
+                      show | imprint &
+
+                 Due to a bug in _m_o_r_e, show will go into a "tty  input"  state.   To
+                 avoid  this  problem,  re-direct  _s_h_o_w's diagnostic output as well.
+                 For users of _c_s_h:
+
+                      show |& imprint &
+
+                 For users of _s_h:
+
+                      show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                         -97-                         SLOCAL(1)
+
+
+            _N_A_M_E
+                 slocal - special local mail delivery
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/slocal [address info sender]
+                      [-addr address] [-info data] [-sender sender]
+                      [-user username] [-mailbox mbox] [-file file]
+                      [-maildelivery deliveryfile] [-verbose] [-noverbose] [-debug]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_l_o_c_a_l is a program designed to allow you to have your inbound mail
+                 processed according to a complex set of selection criteria.  You do
+                 not normally invoke _s_l_o_c_a_l yourself, rather _s_l_o_c_a_l  is  invoked  on
+                 your behalf by your system's Message Transfer Agent.
+
+                 The message selection criteria used by _s_l_o_c_a_l is specified  in  the
+                 file  ._m_a_i_l_d_e_l_i_v_e_r_y  in  the  user's home directory.  The format of
+                 this file is given below.
+
+                 The message delivery address and message sender are determined from
+                 the  Message  Transfer  Agent  envelope  information,  if possible.
+                 Under _S_e_n_d_M_a_i_l, the sender will  obtained  from  the  UUCP  "From "
+                 line,  if present.  The user may override these values with command
+                 line arguments, or arguments to the `-addr' and `-sender' switches.
+
+                 The message is normally read from the standard input.  The  `-file'
+                 switch  sets  the name of the file from which the message should be
+                 read, instead of reading stdin.  The `-user'  switch  tells  _s_l_o_c_a_l
+                 the  name  of the user for whom it is delivering mail.  The `-mail-
+                 box' switch tells _s_l_o_c_a_l the name of the user's maildrop file.
+
+                 The `-info' switch may be used to pass  an  arbitrary  argument  to
+                 sub-processes  which  _s_l_o_c_a_l may invoke on your behalf.  The `-ver-
+                 bose' switch causes _s_l_o_c_a_l to give information on stdout about  its
+                 progress.  The `-debug' switch produces more verbose debugging out-
+                 put on stderr.
+
+
+              _M_e_s_s_a_g_e _T_r_a_n_s_f_e_r _A_g_e_n_t_s
+
+                 If your MTA is _S_e_n_d_M_a_i_l, you should include the line
+
+                          "| /usr/local/lib/mh/slocal -user username"
+
+                 in your .forward file in your  home  directory.   This  will  cause
+                 _S_e_n_d_M_a_i_l to invoke _s_l_o_c_a_l on your behalf.
+
+                 If  your  MTA   is   _M_M_D_F-_I,   you   should   (symbolically)   link
+                 /usr/local/lib/mh/slocal  to  the  file  bin/rcvmail  in  your home
+                 directory.  This will cause _M_M_D_F-_I to invoke _s_l_o_c_a_l on your  behalf
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                         -98-                         SLOCAL(1)
+
+
+                 with the correct "_a_d_d_r_e_s_s _i_n_f_o _s_e_n_d_e_r" arguments.
+
+                 If your MTA is  _M_M_D_F-_I_I,  then  you  should  not  use  _s_l_o_c_a_l.   An
+                 equivalent  functionality is already provided by _M_M_D_F-_I_I; see mail-
+                 delivery(5) for details.
+
+
+              _T_h_e _M_a_i_l_d_e_l_i_v_e_r_y _F_i_l_e
+
+
+                 The ._m_a_i_l_d_e_l_i_v_e_r_y file controls how local  delivery  is  performed.
+                 Each  line  of  this  file  consists  of  five fields, separated by
+                 white-space or comma.  Since double-quotes are honored, these char-
+                 acters may be included in a single argument by enclosing the entire
+                 argument in double-quotes.   A  double-quote  can  be  included  by
+                 preceding  it  with  a  backslash.   Lines  beginning  with `#' are
+                 ignored.  The format of each line in the ._m_a_i_l_d_e_l_i_v_e_r_y file is:
+
+
+                         header  pattern action  result  string
+
+                 header:
+                      The name of a header field that is to be searched for  a  pat-
+                      tern.   This  is  any field in the headers of the message that
+                      might be present.   The  following  special  fields  are  also
+                      defined:
+
+                      _s_o_u_r_c_e    the out-of-band sender information
+                      _a_d_d_r      the address that was used to cause delivery  to  the
+                                recipient
+                      _d_e_f_a_u_l_t   this  matches  _o_n_l_y  if  the  message  hasn't   been
+                                delivered yet
+                      *         this always matches
+
+                 pattern:
+                      The sequence of characters to match in  the  specified  header
+                      field.  Matching is case-insensitive, but does not use regular
+                      expressions.
+
+                 action:
+                      The action to take to deliver the message:
+
+                      _d_e_s_t_r_o_y   This action always succeeds.
+
+                      _f_i_l_e or > Append the message to the file named by string.  The
+                                message is appended to the file in the maildrop for-
+                                mat which is used by your message transport  system.
+                                If  the  message  can  be appended to the file, then
+                                this action succeeds.  When writing to the  file,  a
+                                "Delivery-Date: date"  header  is  added which indi-
+                                cates the date and time that message was appended to
+                                the file.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                         -99-                         SLOCAL(1)
+
+
+                      _m_b_o_x      Identical to _f_i_l_e, but always  appends  the  message
+                                using  the  format  used  by _p_a_c_k_f (the MMDF mailbox
+                                format).
+
+                      _p_i_p_e or | Pipe the message as the standard input to  the  com-
+                                mand  named  by string, using the Bourne shell _s_h(1)
+                                to interpret the string.  Prior to giving the string
+                                to  the  shell,  it  is  expanded with the following
+                                built-in variables:
+
+                                $(sender) the out-of-band sender information
+                                $(address)  the  address  that  was  used  to  cause
+                                          delivery to the recipient
+                                $(size)   the size of the message in bytes
+                                $(reply-to) either the "Reply-To:" or "From:"  field
+                                          of the message
+                                $(info)   the out-of-band information specified
+                      _q_p_i_p_e or
+                      <_c_a_r_e_t>   Similar to _p_i_p_e, but executes the command  directly,
+                                after  built-in  variable  expansion, without assis-
+                                tance from the shell.  This action can  be  used  to
+                                avoid  quoting  special  characters which your shell
+                                might interpret.
+
+                 result:
+                      Indicates how the action should be performed:
+
+                      _A         Perform the action.  If the  action  succeeds,  then
+                                the message is considered delivered.
+
+                      _R         Perform the action.  Regardless of  the  outcome  of
+                                the action, the message is not considered delivered.
+
+                      ?         Perform the action only if the message has not  been
+                                delivered.  If the action succeeds, then the message
+                                is considered delivered.
+
+                      _N         Perform the action only if the message has not  been
+                                delivered  and  the  previous  action succeeded.  If
+                                this action succeeds, then the message is considered
+                                delivered.
+
+                 To summarize, here's an example:
+
+                 #_f_i_e_l_d   _p_a_t_t_e_r_n   _a_c_t_i_o_n  _r_e_s_u_l_t    _s_t_r_i_n_g
+                 # lines starting with a '#' are ignored, as are blank lines
+                 #
+                 # file mail with mmdf2 in the "To:" line into file mmdf2.log
+                 _T_o       _m_m_d_f_2      _f_i_l_e     _A       _m_m_d_f_2._l_o_g
+                 # Messages from mmdf pipe to the program err-message-archive
+                 _F_r_o_m     _m_m_d_f       _p_i_p_e     _A       /_b_i_n/_e_r_r-_m_e_s_s_a_g_e-_a_r_c_h_i_v_e
+                 # Anything with the "Sender:" address "mh-workers"
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -100-                         SLOCAL(1)
+
+
+                 # file in mh.log if not filed already
+                 _S_e_n_d_e_r   _m_h-_w_o_r_k_e_r_s _f_i_l_e     ?       _m_h._l_o_g
+                 # "To:" unix - put in file unix-news
+                 _T_o       _U_n_i_x        >       _A       _u_n_i_x-_n_e_w_s
+                 # if the address is jpo=ack - send an acknowledgement copy back
+                 _a_d_d_r     _j_p_o=_a_c_k     |       _R       "/_b_i_n/_r_e_s_e_n_d -_r $(_r_e_p_l_y-_t_o)"
+                 # anything from steve - destroy!
+                 _F_r_o_m     _s_t_e_v_e    _d_e_s_t_r_o_y    _A       -
+                 # anything not matched yet - put into mailbox
+                 _d_e_f_a_u_l_t  -           >       ?       _m_a_i_l_b_o_x
+                 # always run rcvtty
+                 *        -           |       _R       /_m_h/_l_i_b/_r_c_v_t_t_y
+
+                 The file is always read completely, so that several matches can  be
+                 made and several actions can be taken.  The ._m_a_i_l_d_e_l_i_v_e_r_y file must
+                 be owned either by the user or by root, and must be  writable  only
+                 by  the  owner.  If the ._m_a_i_l_d_e_l_i_v_e_r_y file cannot be found, or does
+                 not perform an action which delivers the  message,  then  the  file
+                 /usr/local/lib/mh/maildelivery is read according to the same rules.
+                 This file must be owned by the root and must be  writable  only  by
+                 the  root.   If  this  file  cannot be found or does not perform an
+                 action which delivers the message, then standard  delivery  to  the
+                 user's maildrop is performed.
+
+
+              _S_u_b-_p_r_o_c_e_s_s _e_n_v_i_r_o_n_m_e_n_t
+
+                 When a process is invoked, its environment is:  the  user/group-ids
+                 are   set   to  recipient's  ids;  the  working  directory  is  the
+                 recipient's home directory; the umask is 0077; the process  has  no
+                 /dev/tty;  the  standard  input is set to the message; the standard
+                 output and diagnostic output are set to /dev/null; all other  file-
+                 descriptors  are  closed;  the envariables $USER, $HOME, $SHELL are
+                 set appropriately, and no other envariables exist.
+
+                 The process is given a certain amount of time to execute.   If  the
+                 process  does  not exit within this limit, the process will be ter-
+                 minated with extreme prejudice.  The amount of time  is  calculated
+                 as  ((size  x 60) + 300) seconds, where size is the number of bytes
+                 in the message.
+
+                 The exit status of the process is consulted in determining the suc-
+                 cess  of  the action.  An exit status of zero means that the action
+                 succeeded.  Any other exit status (or abnormal  termination)  means
+                 that the action failed.
+
+                 In order to avoid any time limitations, you might implement a  pro-
+                 cess  that began by _f_o_r_k_i_n_g.  The parent would return the appropri-
+                 ate value immediately, and the child could continue on, doing what-
+                 ever it wanted for as long as it wanted.  This approach is somewhat
+                 risky if the parent is going to return an exit status of zero.   If
+                 the  parent  is  going  to return a non-zero exit status, then this
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SLOCAL(1)                        -101-                         SLOCAL(1)
+
+
+                 approach can lead to quicker delivery into your maildrop.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         MH tailor file
+                 $HOME/.maildelivery                 The file controlling local delivery
+                 /usr/local/lib/mh/maildelivery      Rather than the standard file
+                 /usr/spool/mail/$USER               The default maildrop
+
+
+            _S_e_e _A_l_s_o
+                 rcvstore(1), mhook(1), mh-format(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-noverbose'
+                 `-maildelivery .maildelivery'
+                 `-mailbox /usr/spool/mail/$USER'
+                 `-file' defaults to stdin
+                 `-user' defaults to the current user
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 _S_l_o_c_a_l is designed to be backward-compatible with the  _m_a_i_l_d_e_l_i_v_e_r_y
+                 facility  provided by _M_M_D_F-_I_I.  Thus, the ._m_a_i_l_d_e_l_i_v_e_r_y file syntax
+                 is limited, as is the functionality of _s_l_o_c_a_l.
+
+                 In addition to an exit status of zero, the _M_M_D_F values _R_P__M_O_K  (32)
+                 and  _R_P__O_K (9) mean that the message has been fully delivered.  Any
+                 other non-zero exit status, including abnormal termination, is  in-
+                 terpreted  as the _M_M_D_F value _R_P__M_E_C_H (200), which means "use an al-
+                 ternate route" (deliver the message to the maildrop).
+
+
+            _B_u_g_s
+                 Only two return codes are meaningful, others should be.
+
+                 _S_l_o_c_a_l is designed to be backwards-compatible with the _m_a_i_l_d_e_l_i_v_e_r_y
+                 functionality provided by MMDF-II.
+
+                 Versions of _M_M_D_F with the _m_a_i_l_d_e_l_i_v_e_r_y  mechanism  aren't  entirely
+                 backwards-compatible with earlier versions of _M_M_D_F.  If you have an
+                 _M_M_D_F-_I old-style hook, the best you can do is to  have  a  one-line
+                 ._m_a_i_l_d_e_l_i_v_e_r_y file:
+
+                      default - pipe A "bin/rcvmail $(address) $(info) $(sender)"
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SORTM(1)                         -102-                          SORTM(1)
+
+
+            _N_A_M_E
+                 sortm - sort messages
+
+            _S_Y_N_O_P_S_I_S
+                 sortm [+folder] [msgs] [-datefield field] [-textfield field]
+                      [-notextfield] [-limit days] [-nolimit] [-verbose]
+                      [-noverbose] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _S_o_r_t_m sorts the specified messages in the named folder according to
+                 the chronological order of the "Date:" field of each message.
+
+                 The `-verbose' switch directs _s_o_r_t_m to tell the  user  the  general
+                 actions that it is taking to place the folder in sorted order.
+
+                 The `-datefield field' switch tells _s_o_r_t_m the name of the field  to
+                 use  when  making  the  date comparison.  If the user has a special
+                 field in each message, such as  "BB-Posted:"  or  "Delivery-Date:",
+                 then  the  `-datefield'  switch  can  be used to direct _s_o_r_t_m which
+                 field to examine.
+
+                 The `-textfield field' switch causes _s_o_r_t_m to sort messages by  the
+                 specified  text  field.   If  this  field is "subject", any leading
+                 "re:" is stripped off.  In any case, all characters except  letters
+                 and  numbers  are  stripped  and  the  resulting strings are sorted
+                 datefield-major, textfield-minor, using  a  case  insensitive  com-
+                 parison.
+
+                 With `-textfield field', if `-limit days'  is  specified,  messages
+                 with  similar textfields that are dated within `days' of each other
+                 appear together.  Specifying `-nolimit' makes the  limit  infinity.
+                 With   `-limit  0',  the  sort  is  instead  made  textfield-major,
+                 date-minor.
+
+                 For example, to order a folder by date-major, subject-minor, use:
+
+                      sortm -textfield subject +folder
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Current-Folder:      To find the default current folder
+
+
+            _S_e_e _A_l_s_o
+                 folder (1)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            SORTM(1)                         -103-                          SORTM(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `+folder' defaults to the current folder
+                 `msgs' defaults to all
+                 `-datefield date'
+                 `-notextfield'
+                 `-noverbose'
+                 `-nolimit'
+
+
+            _C_o_n_t_e_x_t
+                 If a folder is given, it will become the current  folder.   If  the
+                 current  message  is  moved,  _s_o_r_t_m  will  preserve  its  status as
+                 current.
+
+
+            _H_i_s_t_o_r_y
+                 Timezones used to be ignored when comparing dates: they aren't  any
+                 more.
+
+                 Messages which were in the folder, but  not  specified  by  `msgs',
+                 used  to  be  moved to the end of the folder; now such messages are
+                 left untouched.
+
+                 _S_o_r_t_m sometimes did not preserve the message numbering in a  folder
+                 (e.g.,  messages 1, 3, and 5, might have been renumbered to 1, 2, 3
+                 after sorting).  This was a bug, and has been fixed.   To  compress
+                 the message numbering in a folder, use "_f_o_l_d_e_r -_p_a_c_k" as always.
+
+
+            _B_u_g_s
+                 If _s_o_r_t_m encounters a message without a date-field, or if the  mes-
+                 sage  has a date-field that _s_o_r_t_m cannot parse, then _s_o_r_t_m attempts
+                 to keep the message in the same relative position.  This  does  not
+                 always  work.  For instance, if the first message encountered lacks
+                 a date which can be parsed, then it will usually be placed  at  the
+                 end of the messages being sorted.
+
+                 When _s_o_r_t_m complains about a message which it can't temporally ord-
+                 er,  it  complains  about  the message number _p_r_i_o_r to sorting.  It
+                 should indicate what the message number will be _a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            VMH(1)                           -104-                            VMH(1)
+
+
+            _N_A_M_E
+                 vmh - visual front-end to MH
+
+            _S_Y_N_O_P_S_I_S
+                 vmh [-prompt string] [-vmhproc program] [-novmhproc]
+                      [switches for _v_m_h_p_r_o_c] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _v_m_h is a program which implements the server side of the _M_H  window
+                 management  protocol  and  uses  _c_u_r_s_e_s (3)  routines to maintain a
+                 split-screen interface to any program which implements  the  client
+                 side  of the protocol.  This latter program, called the _v_m_h_p_r_o_c, is
+                 specified using the `-vmhproc program' switch.
+
+                 The upshot of all this is that one can run _m_s_h on a display  termi-
+                 nal and get a nice visual interface.  To do this, for example, just
+                 add the line
+
+                      mshproc: vmh
+
+                 to your .mh_profile.  (This takes advantage of the fact that _m_s_h is
+                 the default _v_m_h_p_r_o_c for _v_m_h.)
+
+                 In order to facilitate things, if the `-novmhproc' switch is given,
+                 and  _v_m_h  can't  run  on  the  user's  terminal, the _v_m_h_p_r_o_c is run
+                 directly without the window management protocol.
+
+                 After initializing the protocol, _v_m_h prompts the user for a command
+                 to  be  given to the client.  Usually, this results in output being
+                 sent to one or more windows.  If a output to a window  would  cause
+                 it  to  scroll, _v_m_h prompts the user for instructions, roughly per-
+                 mitting the capabilities of _l_e_s_s or  _m_o_r_e  (e.g.,  the  ability  to
+                 scroll backwards and forwards):
+
+                      SPACE      advance to the next windowful
+                      RETURN  *  advance to the next line
+                      y       *  retreat to the previous line
+                      d       *  advance to the next ten lines
+                      u       *  retreat to the previous ten lines
+                      g       *  go to an arbitrary line
+                                 (preceed g with the line number)
+                      G       *  go to the end of the window
+                                 (if a line number is given, this acts like `g')
+                      CTRL-L     refresh the entire screen
+                      h          print a help message
+                      q          abort the window
+
+                 (A `*' indicates that a numeric prefix is meaningful for this  com-
+                 mand.)
+
+                 Note that if a command resulted in more than one window's worth  of
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            VMH(1)                           -105-                            VMH(1)
+
+
+                 information  being  displayed,  and  you allow the command which is
+                 generating information for the window to gracefully  finish  (i.e.,
+                 you  don't  use  the `q' command to abort information being sent to
+                 the window), then _v_m_h will give you one last change to  peruse  the
+                 window.   This  is  useful for scrolling back and forth.  Just type
+                 `q' when you're done.
+
+                 To abnormally terminate _v_m_h (without core dump), use  <QUIT>  (usu-
+                 ally  CTRL-\).   For instance, this does the "right" thing with _b_b_c
+                 and _m_s_h.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+
+
+            _S_e_e _A_l_s_o
+                 msh(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prompt (vmh) '
+                 `-vmhproc msh'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token by the shell that invokes _v_m_h.  Therefore, one must usu-
+                 ally place the argument to this switch inside double-quotes.
+
+                 At present, there is no way to pass signals (e.g., interrupt, quit)
+                 to the client.  However, generating QUIT when _v_m_h is reading a com-
+                 mand from the terminal is sufficient to tell the client to go  away
+                 quickly.
+
+                 Acts strangely (loses peer or botches  window  management  protocol
+                 with peer) on random occasions.
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -106-                        WHATNOW(1)
+
+
+            _N_A_M_E
+                 whatnow - prompting front-end for send
+
+            _S_Y_N_O_P_S_I_S
+                 whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _W_h_a_t_n_o_w is the default program that  queries  the  user  about  the
+                 disposition  of a composed draft.  It is normally invoked by one of
+                 _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l after the initial edit.
+
+                 When started, the editor is started on the draft (unless  `-noedit'
+                 is  given,  in  which  case the initial edit is suppressed).  Then,
+                 _w_h_a_t_n_o_w repetitively prompts the user with "What now?" and awaits a
+                 response.  The valid responses are:
+
+                 display         to list the message being distributed/replied-to on
+                                 the terminal
+                 edit            to re-edit using the same editor that was used on the
+                                 preceding round unless a profile entry
+                                 "<lasteditor>-next: <editor>" names an alternate editor
+                 edit <editor>   to invoke <editor> for further editing
+                 list            to list the draft on the terminal
+                 push            to send the message in the background
+                 quit            to terminate the session and preserve the draft
+                 quit -delete    to terminate, then delete the draft
+                 refile +folder  to refile the draft into the given folder
+                 send            to send the message
+                 send -watch     to cause the delivery process to be monitored
+                 whom            to list the addresses that the message will go to
+                 whom -check     to list the addresses and verify that they are
+                                 acceptable to the transport service
+
+                 For the edit response, any valid switch to  the  editor  is  valid.
+                 Similarly,  for  the  send  and whom responses, any valid switch to
+                 _s_e_n_d (1) and _w_h_o_m (1) commands, respectively, are valid.   For  the
+                 push  response,  any  valid  switch  to  _s_e_n_d (1) is valid (as this
+                 merely invokes _s_e_n_d with  the  `-push'  option).   For  the  _r_e_f_i_l_e
+                 response,  any  valid  switch  to  the  _f_i_l_e_p_r_o_c is valid.  For the
+                 display and list responses, any valid  argument  to  the  _l_p_r_o_c  is
+                 valid.   If any non-switch arguments are present, then the pathname
+                 of the draft will be excluded from the argument list given  to  the
+                 _l_p_r_o_c (this is useful for listing another _M_H message).
+
+                 See _m_h-_p_r_o_f_i_l_e (5) for further information about  how  editors  are
+                 used  by MH.  It also discusses how complex envariables can be used
+                 to direct _w_h_a_t_n_o_w's actions.
+
+                 The `-prompt string' switch sets the prompting string for _w_h_a_t_n_o_w.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -107-                        WHATNOW(1)
+
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/draft                      The draft file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Editor:              To override the default editor
+                 <lasteditor>-next:   To name an editor to be used after  exit  from
+                 <lasteditor>
+                 fileproc:            Program to refile the message
+                 lproc:               Program to list the contents of a message
+                 sendproc:            Program to use to send the message
+                 whomproc:            Program to determine who a message would go to
+
+
+            _S_e_e _A_l_s_o
+                 send(1), whom(1)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-prompt "What Now? "'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-prompt' switch must be interpreted as a  sin-
+                 gle  token  by the shell that invokes _w_h_a_t_n_o_w.  Therefore, one must
+                 usually place the argument to this switch inside double-quotes.
+
+                 If the initial edit fails, _w_h_a_t_n_o_w deletes your draft (by  renaming
+                 it  with  a  leading  comma); failure of a later edit preverves the
+                 draft.
+
+                 If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then _c_o_m_p, _d_i_s_t, _f_o_r_w, and  _r_e_p_l  use  a
+                 built-in  _w_h_a_t_n_o_w,  and  do  not  actually run the _w_h_a_t_n_o_w program.
+                 Hence, if you define your own _w_h_a_t_n_o_w_p_r_o_c, don't  call  it  _w_h_a_t_n_o_w
+                 since it won't be run.
+
+                 If _s_e_n_d_p_r_o_c is _s_e_n_d, then _w_h_a_t_n_o_w uses a built-in _s_e_n_d, it does not
+                 actually  run  the  _s_e_n_d  program.   Hence,  if you define your own
+                 _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since _w_h_a_t_n_o_w won't run it.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHATNOW(1)                       -108-                        WHATNOW(1)
+
+
+            _N_A_M_E
+                 whom - report to whom a message would go
+
+            _S_Y_N_O_P_S_I_S
+                 whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [file] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _W_h_o_m is used to expand the headers of  a  message  into  a  set  of
+                 addresses  and  optionally verify that those addresses are deliver-
+                 able at that time (if `-check' is given).
+
+                 The `-draftfolder +folder' and `-draftmessage msg' switches  invoke
+                 the _M_H draft folder facility.  This is an advanced (and highly use-
+                 ful) feature.  Consult the Advanced  Features  section  of  the  _M_H
+                 manual for more information.
+
+                 The files specified by the profile entry "Aliasfile:" and any addi-
+                 tional  alias  files given by the `-alias aliasfile' switch will be
+                 read (more than one file,  each   preceeded  by  `-alias',  can  be
+                 named).  See _m_h-_a_l_i_a_s (5) for more information.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+                 Draft-Folder:        To find the default draft-folder
+                 Aliasfile:           For a default alias file
+                 postproc:            Program to post the message
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 `file' defaults to <mh-dir>/draft
+                 `-nocheck'
+                 `-alias /usr/local/lib/mh/MailAliases'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            WHOM(1)                          -109-                           WHOM(1)
+
+
+            _B_u_g_s
+                 With the `-check' option, _w_h_o_m makes no  guarantees  that  the  ad-
+                 dresses  listed  as being ok are really deliverable, rather, an ad-
+                 dress being listed as ok means that at the time that _w_h_o_m  was  run
+                 the address was thought to be deliverable by the transport service.
+                 For local addresses, this is absolute; for  network  addresses,  it
+                 means  that the host is known; for uucp addresses, it (often) means
+                 that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+                                                  -110-
+
+
+                 _M_O_R_E _D_E_T_A_I_L_S
+
+                      This section describes some of the more intense points  of  the  _M_H
+                 system,  by  expanding  on  topics  previously  discussed.   The  format
+                 presented conforms to the standard form  for  the  description  of  UNIX
+            documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -111-                       MH-ALIAS(5)
+
+
+            _N_A_M_E
+                 mh-alias - alias file for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 any _M_H command
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 This describes both _M_H personal alias files and the (primary) alias
+                 file for mail delivery, the file
+
+                         /usr/local/lib/mh/MailAliases
+
+                 It does not describe aliases files used by  the  message  transport
+                 system.  Each line of the alias file has the format:
+
+                         alias : address-group
+                 or
+                         alias ; address-group
+                 or
+                         < alias-file
+                 or
+                         ; comment
+
+                 where:
+
+                         address-group  :=  address-list
+                                        |   "<" file
+                                        |   "=" UNIX-group
+                                        |   "+" UNIX-group
+                                        |   "*"
+
+                         address-list   :=  address
+                                        |   address-list, address
+
+                 Continuation lines in alias files end with `\' followed by the new-
+                 line character.
+
+                 Alias-file and file are UNIX file names.   UNIX-group  is  a  group
+                 name  (or  number)  from  /_e_t_c/_g_r_o_u_p.   An  address  is  a "simple"
+                 Internet-style address.  Througout  this  file,  case  is  ignored,
+                 except for alias-file names.
+
+                 If the line starts with a `<', then the file named after the `<' is
+                 read  for more alias definitions.  The reading is done recursively,
+                 so a `<' may occur in the beginning  of  an  alias  file  with  the
+                 expected results.
+
+                 If the address-group starts with a `<', then the file  named  after
+                 the  `<' is read and its contents are added to the address-list for
+                 the alias.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -112-                       MH-ALIAS(5)
+
+
+                 If the address-group starts with an `=', then the  file  /_e_t_c/_g_r_o_u_p
+                 is  consulted  for  the UNIX-group named after the `='.  Each login
+                 name  occurring  as  a  member  of  the  group  is  added  to   the
+                 address-list for the alias.
+
+                 In contrast, if the address-group starts with a `+', then the  file
+                 /_e_t_c/_g_r_o_u_p is consulted to determine the group-id of the UNIX-group
+                 named after the `+'.  Each login name occurring in the  /_e_t_c/_p_a_s_s_w_d
+                 file  whose  group-id  is  indicated  by this group is added to the
+                 address-list for the alias.
+
+                 If the address-group is simply `*', then the  file  /_e_t_c/_p_a_s_s_w_d  is
+                 consulted and all login names with a userid greater than some magic
+                 number (usually 200) are added to the address-list for the alias.
+
+                 In match, a trailing * on an alias will match just  about  anything
+                 appropriate.  (See example below.)
+
+                 An approximation of the way aliases are resolved at posting time is
+                 (it's not really done this way):
+
+                      1) Build a list of  all  addresses  from  the  message  to  be
+                      delivered, eliminating duplicate addresses.
+
+                      2) If this draft originated on the local host, then for  those
+                      addresses  in the message that have no host specified, perform
+                      alias resolution.
+
+                      3) For each line in the alias file,  compare  "alias"  against
+                      all of the existing addresses.  If a match, remove the matched
+                      "alias" from the address list, and add each new address in the
+                      address-group  to the address list if it is not already on the
+                      list.  The alias itself is  not  usually  output,  rather  the
+                      address-group  that  the  alias maps to is output instead.  If
+                      "alias" is terminated with a `;' instead of a `:',  then  both
+                      the  "alias" and the address are output in the correct format.
+                      (This makes replies possible since  _M_H  aliases  and  personal
+                      aliases are unknown to the mail transport system.)
+
+                 Since the alias file is read line by line, forward references work,
+                 but  backward  references  are  not  recognized,  thus, there is no
+                 recursion.
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -113-                       MH-ALIAS(5)
+
+
+                 Example:
+                      </usr/local/lib/mh/BBoardAliases
+                      sgroup: fred, fear, freida
+                      b-people: Blind List: bill, betty;
+                      fred: frated@UCI
+                      UNIX-committee: <unix.aliases
+                      staff: =staff
+                      wheels: +wheel
+                      everyone: *
+                      news.*: news
+
+                 The first line says that more aliases should  immediately  be  read
+                 from  the  file  /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_B_B_o_a_r_d_A_l_i_a_s_e_s.   Following this,
+                 "fred" is defined as an alias for  "frated@UCI",  and  "sgroup"  is
+                 defined  as  an alias for the three names "frated@UCI", "fear", and
+                 "freida".
+
+                 The alias "b-people" is a blind list which includes  the  addresses
+                 "bill"   and  "betty";  the  message  will  be  delieved  to  those
+                 addresses, but the message header will  show only "Blind  List:  ;"
+                 (not the addresses).
+
+                 Next, the definition of "UNIX-committee" is given  by  reading  the
+                 file  _u_n_i_x._a_l_i_a_s_e_s in the users _M_H directory, "staff" is defined as
+                 all users who are listed as members of the  group  "staff"  in  the
+                 /_e_t_c/_g_r_o_u_p  file,  and  "wheels"  is  defined  as  all  users whose
+                 group-id in /_e_t_c/_p_a_s_s_w_d is equivalent to the "wheel" group.
+
+                 Finally, "everyone" is defined as  all  users  with  a  user-id  in
+                 /_e_t_c/_p_a_s_s_w_d   greater  than  200,  and  all  aliases  of  the  form
+                 "news.<anything>" are defined to be "news".
+
+                 The key thing to understand about aliasing in _M_H is that aliases in
+                 _M_H  alias  files  are expanded into the headers of messages posted.
+                 This aliasing occurs first, at posting time, without the  knowledge
+                 of  the  message  transport  system.  In contrast, once the message
+                 transport system is given  a  message  to  deliver  to  a  list  of
+                 addresses, for each address that appears to be local, a system-wide
+                 alias file is consulted.  These aliases are NOT expanded  into  the
+                 headers of messages delivered.
+
+            _H_e_l_p_f_u_l _H_i_n_t_s
+
+                 To use aliasing in _M_H quickly, do the following:
+
+                      First, in your ._m_h__p_r_o_f_i_l_e, choose a name for your alias file,
+                      say "aliases", and add the line:
+
+                           Aliasfile: aliases
+
+                      Second, create the file "aliases" in your _M_H directory.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-ALIAS(5)                      -114-                       MH-ALIAS(5)
+
+
+                      Third,  start  adding  aliases  to  your  "aliases"  file   as
+                      appropriate.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/MailAliases       Primary alias file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Aliasfile:           For a default alias file
+
+
+            _S_e_e _A_l_s_o
+                 ali(1), send(1), whom(1), group(5), passwd(5), conflict(8), post(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 In previous releases of _M_H, only  a  single,  system-wide  mh-alias
+                 file  was  supported.  This led to a number of problems, since only
+                 mail-system administrators were capable  of  (un)defining  aliases.
+                 Hence,  the semantics of mh-alias were extended to support personal
+                 alias files.  Users of _M_H no longer need to bother mail-system  ad-
+                 ministrators for keeping information in the system-wide alias file,
+                 as each _M_H user can create/modify/remove aliases at will  from  any
+                 number of personal files.
+
+
+            _B_u_g_s
+                 Although  the  forward-referencing  semantics  of  _m_h-_a_l_i_a_s   files
+                 prevent  recursion,  the  "< alias-file"  command  may defeat this.
+                 Since the number of file descriptors is finite (and very  limited),
+                 such  infinite recursion will terminate with a meaningless diagnos-
+                 tic when all the fds are used up.
+
+                 Forward references do not work correctly inside blind lists.
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -115-                      MH-FORMAT(5)
+
+
+            _N_A_M_E
+                 mh-format - format file for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 some _M_H commands
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Several _M_H commands utilize either a _f_o_r_m_a_t string or a _f_o_r_m_a_t file
+                 during their execution.  For example, _s_c_a_n (1) uses a format string
+                 which directs it how to generate the scan listing for each message;
+                 _r_e_p_l (1)  uses  a  format file which directs it how to generate the
+                 reply to a message, and so on.
+
+                 Format strings are designed to be efficiently parsed  by  _M_H  which
+                 means  they  are  not  necessarily  simple to write and understand.
+                 This means that novice, casual, or even advanced users of _M_H should
+                 not  have  to deal with them.  Some canned scan listing formats are
+                 in  /usr/local/lib/mh/scan.time,  /usr/local/lib/mh/scan.size,  and
+                 /usr/local/lib/mh/scan.timely.  Look in /usr/local/lib/mh for other
+                 _s_c_a_n and _r_e_p_l format files which may  have  been  written  at  your
+                 site.
+
+                 It suffices to have your local _M_H expert actually write new  format
+                 commands or modify existing ones.  This manual section explains how
+                 to do that.   Note:  familiarity  with  the  C  _p_r_i_n_t_f  routine  is
+                 assumed.
+
+                 A format string consists  of  ordinary  text,  and  special  multi-
+                 character _e_s_c_a_p_e sequences which begin with `%'.  When specifying a
+                 format string, the usual C backslash characters are honored:  `\b',
+                 `\f', `\n', `\r', and `\t'.  Continuation lines in format files end
+                 with `\' followed by the newline character.  There are three  types
+                 of  _e_s_c_a_p_e  sequences:  header  _c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and
+                 flow _c_o_n_t_r_o_l.
+
+                 A _c_o_m_p_o_n_e_n_t escape is specified as `%{_c_o_m_p_o_n_e_n_t}', and  exists  for
+                 each  header  found  in  the  message being processed.  For example
+                 `%{date}' refers to the "Date:" field of the  appropriate  message.
+                 All  component  escapes  have  a string value.  Normally, component
+                 values are compressed by converting any control characters (tab and
+                 newline  included)  to spaces, then eliding any leading or multiple
+                 spaces.  However, commands may give  different  interpretations  to
+                 some  component  escapes; be sure to refer to each command's manual
+                 entry for complete details.
+
+                 A _f_u_n_c_t_i_o_n escape is specified as `%(_f_u_n_c_t_i_o_n)'.  All functions are
+                 built-in, and most have a string or numeric value.
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -116-                      MH-FORMAT(5)
+
+
+              _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+                 A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|', or  `%>'.  These  are
+                 combined into the conditional execution construct:
+
+                         %<condition
+                                 _f_o_r_m_a_t _t_e_x_t _1
+                         %?condition2
+                                 _f_o_r_m_a_t _t_e_x_t _2
+                         %?condition3
+                                 _f_o_r_m_a_t _t_e_x_t _3
+                         ...
+                         %|
+                                 _f_o_r_m_a_t _t_e_x_t _N
+                         %>
+
+                 Extra white space is shown here only for clarity.  These constructs
+                 may   be   nested   without   ambiguity.    They   form  a  general
+                 if-elseif-else-endif block where only one of the _f_o_r_m_a_t  _t_e_x_t  seg-
+                 ments is interpreted.
+
+                 The `%<'  and  `%?'  control  escapes  causes  a  condition  to  be
+                 evaluated.  This condition may be either a _c_o_m_p_o_n_e_n_t or a _f_u_n_c_t_i_o_n.
+                 The four constructs have the following syntax:
+
+                         %<{component}
+                         %<(function)
+                         %?{component}
+                         %?(function)
+
+                 These control escapes test whether the function or component  value
+                 is   non-zero  (for  integer-valued  escapes),  or  non-empty  (for
+                 string-valued escapes).
+
+                 If this test evaulates true, then the format text up  to  the  next
+                 corresponding control escape (one of `%|', `%?', or `%>') is inter-
+                 preted normally.   Next,  all  format  text  (if  any)  up  to  the
+                 corresponding  `%>'  control  escape  is skipped.  The `%>' control
+                 escape is not interpreted; normal interpretation resumes after  the
+                 `%>' escape.
+
+                 If the test evaluates false, however, then the format  text  up  to
+                 the next corresponding control escape (again, one of `%|', `%?', or
+                 `%>') is skipped, instead of being  interpreted.   If  the  control
+                 escape  encountered  was  `%?',  then the condition associated with
+                 that control escape is evaluated, and interpretation proceeds after
+                 that  test  as described in the previous paragraph.  If the control
+                 escape encountered was  `%|',  then  the  format  text  up  to  the
+                 corresponding  `%>'  escape is interpreted normally.  As above, the
+                 `%>' escape is not interpreted and  normal  interpretation  resumes
+                 after the `%>' escape.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -117-                      MH-FORMAT(5)
+
+
+                 The `%?' control escape and its following format text is  optional,
+                 and  may  be  included zero or more times.  The `%|' control escape
+                 and its following format text is also optional, and may be included
+                 zero or one times.
+
+
+              _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+                 Most functions expect an argument of a particular type:
+
+                 _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n            _E_x_a_m_p_l_e _S_y_n_t_a_x
+                 literal  A literal number,      %(_f_u_n_c 1234)
+                          or string              %(_f_u_n_c text string)
+                 comp     Any header component   %(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+                 date     A date component       %(_f_u_n_c{_d_a_t_e})
+                 addr     An address component   %(_f_u_n_c{_f_r_o_m})
+                 expr     An optional component, %(_f_u_n_c(_f_u_n_c_2))
+                          function or control,   %(_f_u_n_c %<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+                          perhaps nested         %(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+                 The types _d_a_t_e and _a_d_d_r have the same syntax as _c_o_m_p,  but  require
+                 that  the  header  component  be  a date string, or address string,
+                 respectively.
+
+                 All arguments except those of type _e_x_p_r are required.  For the _e_x_p_r
+                 argument  type,  the  leading `%' must be omitted for component and
+                 function escape arguments, and must  be  present  (with  a  leading
+                 space) for control escape arguments.
+
+                 The evaluation of format strings is based on a simple machine  with
+                 an  integer  register  _n_u_m, and a text string register _s_t_r.  When a
+                 function escape is processed, if it accepts an optional _e_x_p_r  argu-
+                 ment which is not present, it reads the current value of either _n_u_m
+                 or _s_t_r as appropriate.
+
+
+              _R_e_t_u_r_n _v_a_l_u_e_s
+
+                 Component escapes write the value of their message header  in  _s_t_r.
+                 Function  escapes  write  their  return  value in _n_u_m for functions
+                 returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n  values,  and  in  _s_t_r  for  functions
+                 returning string values.  (The _b_o_o_l_e_a_n type is a subset of integers
+                 with usual values 0=false and 1=true.)  Control  escapes  return  a
+                 _b_o_o_l_e_a_n value, and set _n_u_m.
+
+                 All component escapes, and those function escapes which  return  an
+                 _i_n_t_e_g_e_r  or  _s_t_r_i_n_g  value, pass this value back to their caller in
+                 addition to setting _s_t_r or _n_u_m.  These escapes will print out  this
+                 value  unless  called  as  part  of  an  argument to another escape
+                 sequence.  Escapes which return a _b_o_o_l_e_a_n value do pass this  value
+                 back to their caller in _n_u_m, but will never print out the value.
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -118-                      MH-FORMAT(5)
+
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 msg                 integer  message number
+                 cur                 integer  message is current
+                 size                integer  size of message
+                 strlen              integer  length of _s_t_r
+                 width               integer  output buffer size in bytes
+                 charleft            integer  bytes left in output buffer
+                 timenow             integer  seconds since the UNIX epoch
+                 me                  string   the user's mailbox
+                 eq         literal  boolean  _n_u_m == _a_r_g
+                 ne         literal  boolean  _n_u_m != _a_r_g
+                 gt         literal  boolean  _n_u_m > _a_r_g
+                 match      literal  boolean  _s_t_r contains _a_r_g
+                 amatch     literal  boolean  _s_t_r starts with _a_r_g
+                 plus       literal  integer  _a_r_g plus _n_u_m
+                 minus      literal  integer  _a_r_g minus _n_u_m
+                 divide     literal  integer  _n_u_m divided by _a_r_g
+                 modulo     literal  integer  _n_u_m modulo _a_r_g
+                 num        literal  integer  Set _n_u_m to _a_r_g
+                 lit        literal  string   Set _s_t_r to _a_r_g
+                 getenv     literal  string   Set _s_t_r to environment value of _a_r_g
+                 profile    literal  string   Set _s_t_r to profile component _a_r_g value
+                 nonzero    expr     boolean  _n_u_m is non-zero
+                 zero       expr     boolean  _n_u_m is zero
+                 null       expr     boolean  _s_t_r is empty
+                 nonnull    expr     boolean  _s_t_r is non-empty
+                 void       expr              Set _s_t_r or _n_u_m
+                 comp       comp     string   Set _s_t_r to component text
+                 compval    comp     integer  _n_u_m set to "atoi(_c_o_m_p)"
+                 trim       expr              trim trailing white-space from _s_t_r
+                 putstr     expr              print _s_t_r
+                 putstrf    expr              print _s_t_r in a fixed width
+                 putnum     expr              print _n_u_m
+                 putnumf    expr              print _n_u_m in a fixed width
+
+                 These functions require a date component as an argument:
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 sec        date     integer  seconds of the minute
+                 min        date     integer  minutes of the hour
+                 hour       date     integer  hours of the day (0-23)
+                 wday       date     integer  day of the week (Sun=0)
+                 day        date     string   day of the week (abbrev.)
+                 weekday    date     string   day of the week
+                 sday       date     integer  day of the week known?
+                                              (0=implicit,-1=unknown)
+                 mday       date     integer  day of the month
+                 yday       date     integer  day of the year
+                 mon        date     integer  month of the year
+                 month      date     string   month of the year (abbrev.)
+                 lmonth     date     string   month of the year
+                 year       date     integer  year (may be > 100)
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -119-                      MH-FORMAT(5)
+
+
+                 zone       date     integer  timezone in hours
+                 tzone      date     string   timezone string
+                 szone      date     integer  timezone explicit?
+                                              (0=implicit,-1=unknown)
+                 date2local date              coerce date to local timezone
+                 date2gmt   date              coerce date to GMT
+                 dst        date     integer  daylight savings in effect?
+                 clock      date     integer  seconds since the UNIX epoch
+                 rclock     date     integer  seconds prior to current time
+                 tws        date     string   official 822 rendering
+                 pretty     date     string   user-friendly rendering
+                 nodate     date     integer  _s_t_r not a date string
+
+                 These functions require an address component as  an  argument.  The
+                 return  value of functions noted with `*' pertain only to the first
+                 address present in the header component.
+
+                 _F_u_n_c_t_i_o_n   _A_r_g_u_m_e_n_t _R_e_t_u_r_n   _D_e_s_c_r_i_p_t_i_o_n
+                 proper     addr     string   official 822 rendering
+                 friendly   addr     string   user-friendly rendering
+                 addr       addr     string   mbox@host or host!mbox rendering*
+                 pers       addr     string   the personal name*
+                 note       addr     string   commentary text*
+                 mbox       addr     string   the local mailbox*
+                 mymbox     addr     integer  the user's addresses? (0=no,1=yes)
+                 host       addr     string   the host domain*
+                 nohost     addr     integer  no host was present*
+                 type       addr     integer  host type* (0=local,1=network,
+                                              -1=uucp,2=unknown)
+                 path       addr     string   any leading host route*
+                 ingrp      addr     integer  address was inside a group*
+                 gname      addr     string   name of group*
+                 formataddr expr              append _a_r_g to _s_t_r as a
+                                              (comma separated) address list
+                 putaddr    literal           print _s_t_r address list with
+                                              _a_r_g as optional label;
+                                              get line width from _n_u_m
+
+                 When escapes are nested, evaluation  is  done  from  inner-most  to
+                 outer-most.   The  outer-most escape must begin with `%'; the inner
+                 escapes must not.  For example,
+
+                      %<(mymbox{from}) To: %{to}%>
+
+                 writes the value of the header component "From:" to _s_t_r; then (_m_y_m_-
+                 _b_o_x)  reads  _s_t_r  and  writes  its  result to _n_u_m; then the control
+                 escape evaluates _n_u_m.  If _n_u_m is non-zero, the  string  "To:  "  is
+                 printed followed by the value of the header component "To:".
+
+                 A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is in order.  In general,  it
+                 checks each of the addresses in the header component "_c_o_m_p" against
+                 the user's mailbox name and any  _A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s.   It  returns
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -120-                      MH-FORMAT(5)
+
+
+                 true  if  any address matches, however, it also returns true if the
+                 "_c_o_m_p" header is not present in the message.  If needed, the (_n_u_l_l)
+                 function can be used to explicitly test for this condition.
+
+                 When a function or component escape is interpreted and  the  result
+                 will  be immediately printed, an optional field width can be speci-
+                 fied to print the field in exactly a given  number  of  characters.
+                 For  example,  a  numeric escape like %4(_s_i_z_e) will print at most 4
+                 digits of the message size; overflow will be indicated by a `?'  in
+                 the first position (like `?234').  A string escape like %4(_m_e) will
+                 print the first 4 characters and truncate at the end. Short  fields
+                 are  padded  at  the  right  with  the  fill character (normally, a
+                 blank).  If the field width argument begins with  a  leading  zero,
+                 then the fill character is set to a zero.
+
+                 As above, the functions (_p_u_t_n_u_m_f) and (_p_u_t_s_t_r_f) print their  result
+                 in  exactly  the  number  of  characters specified by their leading
+                 field width argument. For example,  %06(_p_u_t_n_u_m_f(_s_i_z_e))  will  print
+                 the message size in a field six characters wide filled with leading
+                 zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print the "From:"  header  component
+                 in  fourteen  characters with trailing spaces added as needed.  For
+                 _p_u_t_s_t_r_f, using a negative value for the field width  causes  right-
+                 justification  of  the string within the field, with padding on the
+                 left up to the field width.  The functions  (_p_u_t_n_u_m)  and  (_p_u_t_s_t_r)
+                 print  their  result  in the minimum number of characters required,
+                 and ignore any leading field width argument.
+
+                 The available output width is kept in  an  internal  register;  any
+                 output past this width will be truncated.
+
+                 Comments may be inserted in most places where a  function  argument
+                 is  not expected.  A comment begins with `%;' and ends with a (non-
+                 escaped) newline.
+
+                 With all this in mind, here's the default format string  for  _s_c_a_n.
+                 It's  been  divided into several pieces for readability.  The first
+                 part is:
+
+                      %4(msg)%<(cur)+%| %>%<{replied}-%?{encrypted}E%| %>
+
+                 which says that the  message  number  should  be  printed  in  four
+                 digits,  if  the  message  is the current message then a `+' else a
+                 space should be printed, and if a "Replied:" field is present  then
+                 a  `-'  else if an "Encrypted:" field is present then an `E' other-
+                 wise a space should be printed.  Next:
+
+                      %02(mon{date})/%02(mday{date})
+
+                 the month  and  date  are  printed  in  two  digits  (zero  filled)
+                 separated by a slash.  Next,
+
+                      %<{date} %|*>
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -121-                      MH-FORMAT(5)
+
+
+                 If a "Date:" field was present, then a space is printed,  otherwise
+                 a `*'.  Next,
+
+                      %<(mymbox{from})%<{to}To:%14(friendly{to})%>%>
+
+                 if the message is from me, and there is a "To:" header, print `To:'
+                 followed by a "user-friendly" rendering of the first address in the
+                 "To:" field.  Continuing,
+
+                      %<(zero)%17(friendly{from})%>
+
+                 if either of the above two tests failed, then the  "From:"  address
+                 is printed in a "user-friendly" format.  And finally,
+
+                      %{subject}%<{body}<<%{body}%>
+
+                 the subject and initial body (if any) are printed.
+
+                 For a more complicated example, next consider the default _r_e_p_l_c_o_m_p_s
+                 format file.
+
+                      %(lit)%(formataddr %<{reply-to}
+
+                 This clears _s_t_r and formats the "Reply-To:" header if present.   If
+                 not present, the else-if clause is executed.
+
+                      %?{from}%?{sender}%?{return-path}%>)\
+
+                 This formats the "From:",  "Sender:"  and  "Return-Path:"  headers,
+                 stopping as soon as one of them is present.  Next:
+
+                      %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+                 If the _f_o_r_m_a_t_a_d_d_r result is non-null, it is printed as  an  address
+                 (with  line folding if needed) in a field _w_i_d_t_h wide with a leading
+                 label of "To: ".
+
+                      %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+                 _s_t_r is cleared, and the "To:" and "Cc:"  headers,  along  with  the
+                 user's  address  (depending  on  what  was specified with the "-cc"
+                 switch to _r_e_p_l) are formatted.
+
+                      %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+                 If the result is non-null, it is printed as above  with  a  leading
+                 label of "cc: ".
+
+                      %<{fcc}Fcc: %{fcc}\n%>\
+
+                 If a "-fcc folder" switch was given to _r_e_p_l (see _r_e_p_l (1) for  more
+                 details about %{_f_c_c}), an "Fcc:" header is output.
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -122-                      MH-FORMAT(5)
+
+
+                      %<{subject}Subject: Re: %{subject}\n%>\
+
+                 If a subject component was present, a  suitable  reply  subject  is
+                 output.
+
+                      %<{date}In-reply-to: Your message of "\
+                      %<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id}
+                                   %{message-id}%>\n%>\
+                      --------
+
+                 If a date component was present, an "In-Reply-To:" header is output
+                 with the preface "Your message of ".  If the date was parseable, it
+                 is output in a user-friendly format, otherwise it is output  as-is.
+                 The message-id is included if present.  As with all plain-text, the
+                 row of dashes are output as-is.
+
+                 This last part is a good example for  a  little  more  elaboration.
+                 Here's that part again in pseudo-code:
+
+                      if (comp_exists(date))  then
+                           print ("In-reply-to: Your message of \"")
+                           if (not_date_string(date.value) then
+                                print (date.value)
+                           else
+                                print (pretty(date.value))
+                           endif
+                           print ("\"")
+                           if (comp_exists(message-id)) then
+                                print ("\n\t")
+                                print (message-id.value)
+                           endif
+                           print ("\n")
+                      endif
+
+                 Although this seems complicated, in point of fact, this  method  is
+                 flexible  enough to extract individual fields and print them in any
+                 format the user desires.
+
+            _F_i_l_e_s
+                 None
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 scan(1), repl(1), ap(8), dp(8)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-FORMAT(5)                     -123-                      MH-FORMAT(5)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _H_i_s_t_o_r_y
+                 This software was contributed for MH 6.3.  Prior  to  this,  output
+                 format  specifications  were much easier to write, but considerably
+                 less flexible.
+
+
+            _B_u_g_s
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -124-                        MH-MAIL(5)
+
+
+            _N_A_M_E
+                 mh-mail - message format for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 any _M_H command
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _M_H processes messages in a particular format.  It should  be  noted
+                 that  although  neither  Bell  nor Berkeley mailers produce message
+                 files in the format that _M_H prefers, _M_H can read message  files  in
+                 that antiquated format.
+
+                 Each user possesses a mail drop box which  initially  receives  all
+                 messages  processed  by _p_o_s_t (8).  _I_n_c (1) will read from that drop
+                 box and incorporate the new messages found there  into  the  user's
+                 own  mail folders (typically `+inbox').  The mail drop box consists
+                 of one or more messages.
+
+                 Messages are expected to consist of lines of  text.   Graphics  and
+                 binary data are not handled.  No data compression is accepted.  All
+                 text is clear ASCII 7-bit data.
+
+                 The general "memo" framework of RFC-822 is used.   A  message  con-
+                 sists of a block of information in a rigid format, followed by gen-
+                 eral text with no specified format.  The  rigidly  formatted  first
+                 part of a message is called the header, and the free-format portion
+                 is called the body.  The header must always exist, but the body  is
+                 optional.   These  parts  are separated by an empty line, i.e., two
+                 consecutive newline characters.  Within _M_H, the header and body may
+                 be separated by a line consisting of dashes:
+
+                      To:
+                      cc:
+                      Subject:
+                      --------
+
+                 The header is composed of one or more header  items.   Each  header
+                 item  can  be  viewed as a single logical line of ASCII characters.
+                 If the text of a header item extends across several real lines, the
+                 continuation lines are indicated by leading spaces or tabs.
+
+                 Each header item is called a component and is composed of a keyword
+                 or  name,  along  with  associated text.  The keyword begins at the
+                 left margin, may NOT contain spaces or  tabs,  may  not  exceed  63
+                 characters  (as specified by RFC-822), and is terminated by a colon
+                 (`:').  Certain components (as identified by their  keywords)  must
+                 follow rigidly defined formats in their text portions.
+
+                 The  text  for  most  formatted  components  (e.g.,   "Date:"   and
+                 "Message-Id:") is produced automatically.  The only ones entered by
+                 the user are address fields such as "To:",  "cc:",  etc.   Internet
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -125-                        MH-MAIL(5)
+
+
+                 addresses  are  assigned mailbox names and host computer specifica-
+                 tions.  The rough format is "local@domain", such  as  "MH@UCI",  or
+                 "MH@UCI-ICSA.ARPA".  Multiple addresses are separated by commas.  A
+                 missing host/domain is assumed to be the local host/domain.
+
+                 As mentioned above, a blank line (or a line of dashes) signals that
+                 all  following text up to the end of the file is the body.  No for-
+                 matting is expected or enforced within the body.
+
+                 Following is a list of header components that are considered  mean-
+                 ingful to various MH programs.
+                 Date:
+                      Added by _p_o_s_t (8), contains date and  time  of  the  message's
+                      entry into the transport system.
+
+                 From:
+                      Added by _p_o_s_t (8), contains  the  address  of  the  author  or
+                      authors  (may  be  more  than  one  if  a  "Sender:"  field is
+                      present).  Replies are typically directed to addresses in  the
+                      "Reply-To:"  or  "From:"  field  (the former has precedence if
+                      present).
+
+                 Sender:
+                      Added by _p_o_s_t (8) in the event that the message already has  a
+                      "From:"  line.   This  line contains the address of the actual
+                      sender.  Replies are never sent to addresses in the  "Sender:"
+                      field.
+
+                 To:
+                      Contains addresses of primary recipients.
+
+                 cc:
+                      Contains addresses of secondary recipients.
+
+                 Bcc:
+                      Still more recipients.  However, the "Bcc:" line is not copied
+                      onto  the  message  as  delivered, so these recipients are not
+                      listed.  _M_H uses an encapsulation method for blind copies, see
+                      _s_e_n_d (1).
+
+                 Fcc:
+                      Causes _p_o_s_t (8) to copy the message into the specified  folder
+                      for  the  sender, if the message was successfully given to the
+                      transport system.
+
+                 Message-ID:
+                      A unique message identifier added by _p_o_s_t (8) if the  `-msgid'
+                      flag is set.
+
+                 Subject:
+                      Sender's commentary.  It is displayed by _s_c_a_n (1).
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -126-                        MH-MAIL(5)
+
+
+                 In-Reply-To:
+                      A commentary line added by _r_e_p_l (1) when replying  to  a  mes-
+                      sage.
+
+                 Resent-Date:
+                      Added when redistributing a message by _p_o_s_t (8).
+
+                 Resent-From:
+                      Added when redistributing a message by _p_o_s_t (8).
+
+                 Resent-To:
+                      New recipients for a message resent by _d_i_s_t (1).
+
+                 Resent-cc:
+                      Still more recipients.  See "cc:" and "Resent-To:".
+
+                 Resent-Bcc:
+                      Even more recipients.  See "Bcc:" and "Resent-To:".
+
+                 Resent-Fcc:
+                      Copy  resent  message  into  a   folder.    See   "Fcc:"   and
+                      "Resent-To:".
+
+                 Resent-Message-Id:
+                      A unique identifier glued on by _p_o_s_t (8) if the `-msgid'  flag
+                      is set.  See "Message-Id:" and "Resent-To:".
+
+                 Resent:
+                      Annotation for _d_i_s_t (1) under the `-annotate' option.
+
+                 Forwarded:
+                      Annotation for _f_o_r_w (1) under the `-annotate' option.
+
+                 Replied:
+                      Annotation for _r_e_p_l (1) under the `-annotate' option.
+
+
+            _F_i_l_e_s
+                 /usr/spool/mail/$USER               Location of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-MAIL(5)                       -127-                        MH-MAIL(5)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -128-                     MH-PROFILE(5)
+
+
+            _N_A_M_E
+                 mh-profile - user profile customization for MH message handler
+
+            _S_Y_N_O_P_S_I_S
+                 ._m_h__p_r_o_f_i_l_e
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Each user of _M_H is expected to have a file named ._m_h__p_r_o_f_i_l_e in his
+                 or her home directory.  This file contains a set of user parameters
+                 used by some or all of the _M_H family of programs.  Each line of the
+                 file is of the format
+
+                     _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t: _v_a_l_u_e
+
+                 The  possible  profile  components  are  exemplified  below.   Only
+                 `Path:'  is  mandatory.  The others are optional; some have default
+                 values if they are not present.  In the notation used below,  (pro-
+                 file,  default)  indicates  whether  the information is kept in the
+                 user's _M_H profile or _M_H context, and  indicates  what  the  default
+                 value is.
+
+                 Path: Mail
+                           Locates _M_H transactions in directory  "Mail".   (profile,
+                           no default)
+
+                 context: context
+                           Declares the location of the _M_H  context  file,  see  the
+                           HISTORY     section     below.      (profile,    default:
+                           <mh-dir>/context)
+
+                 Current-Folder: inbox
+                           Keeps  track  of  the  current  open  folder.   (context,
+                           default: folder specified by "Inbox")
+
+                 Inbox:  inbox
+                           Defines the  name  of  your  inbox.   (profile,  default:
+                           inbox)
+
+                 Previous-Sequence: pseq
+                           Names the sequences which should be defined as the `msgs'
+                           or  `msg' argument given to the program.  If not present,
+                           or empty, no sequences are defined.  Otherwise, for  each
+                           name  given,  the  sequence is first zero'd and then each
+                           message is added to the sequence.  (profile, no default)
+
+                 Sequence-Negation: not
+                           Defines the string which, when  prefixed  to  a  sequence
+                           name,  negates that sequence.  Hence, "notseen" means all
+                           those messages that are not  a  member  of  the  sequence
+                           "seen".  (profile, no default)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -129-                     MH-PROFILE(5)
+
+
+                 Unseen-Sequence: unseen
+                           Names the sequences which should be defined as those mes-
+                           sages recently incorporated by _i_n_c.  _S_h_o_w knows to remove
+                           messages from this sequence once it thinks they have been
+                           seen.   If  not  present,  or  empty,  no  sequences  are
+                           defined.   Otherwise,  each  message  is  added  to  each
+                           sequence name given.  (profile, no default)
+
+                 mh-sequences: .mh_sequences
+                           The name of the file in each folder which defines  public
+                           sequences.  To disable the use of public sequences, leave
+                           the  value  portion  of  this  entry  blank.    (profile,
+                           default: .mh_sequences)
+
+                 atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+                           Keeps track of the private sequence  called  _s_e_q  in  the
+                           specified folder.  (context, no default)
+
+                 Editor: /usr/ucb/ex
+                           Defines  editor  to  be  used  by   _c_o_m_p (1),   _d_i_s_t (1),
+                           _f_o_r_w (1), and _r_e_p_l (1).  (profile, default: prompter)
+
+                 Msg-Protect: 644
+                           Defines octal protection bits  for  message  files.   See
+                           _c_h_m_o_d (1)  for an explanation of the octal number.  (pro-
+                           file, default: 0644)
+
+                 Folder-Protect: 711
+                           Defines protection bits for  folder  directories.   (pro-
+                           file, default: 0711)
+
+                 _p_r_o_g_r_a_m: default switches
+                           Sets default switches to be used whenever the mh  program
+                           _p_r_o_g_r_a_m  is invoked.  For example, one could override the
+                           _E_d_i_t_o_r: profile component when replying  to  messages  by
+                           adding a component such as:
+                                   repl: -editor /bin/ed
+                           (profile, no defaults)
+
+                 _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+                           Names "nexteditor" to be the default editor  after  using
+                           "lasteditor".   This takes effect at "What now?" level in
+                           _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l.  After editing the draft with
+                           "lasteditor",  the  default editor is set to be "nextedi-
+                           tor".  If the user types "edit" without any arguments  to
+                           "What  now?",  then  "nexteditor"  is used.  (profile, no
+                           default)
+
+                 bboards: system
+                           Tells _b_b_c which BBoards you are interested in.  (profile,
+                           default: system)
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -130-                     MH-PROFILE(5)
+
+
+                 Folder-Stack: _f_o_l_d_e_r_s
+                           The contents of the folder-stack for the _f_o_l_d_e_r  command.
+                           (context, no default)
+
+                 mhe:
+                           If present, tells _i_n_c to  compose  an  _M_H_E  auditfile  in
+                           addition  to  its other tasks.  _M_H_E is Brian Reid's _E_m_a_c_s
+                           front-end for _M_H.  An early version is supplied with  the
+                           _m_h._6 distribution.  (profile, no default)
+
+                 Alternate-Mailboxes: mh@uci-750a, bug-mh*
+                           Tells _r_e_p_l and _s_c_a_n which addresses are really yours.  In
+                           this  way,  _r_e_p_l knows which addresses should be included
+                           in the reply, and _s_c_a_n knows if the message  really  ori-
+                           ginated  from  you.   Addresses  must  be  separated by a
+                           comma, and the hostnames listed should be the  "official"
+                           hostnames  for the mailboxes you indicate, as local nick-
+                           names for hosts are not replaced with their official site
+                           names.   For  each  address, if a host is not given, then
+                           that address on any host is considered  to  be  you.   In
+                           addition,  an asterisk (`*') may appear at either or both
+                           ends of the mailbox and host to indicate wild-card match-
+                           ing.  (profile, default: your user-id)
+
+                 Aliasfile: aliases other-alias
+                           Indicates aliases files for _a_l_i, _w_h_o_m,  and  _s_e_n_d.   This
+                           may  be  used instead of the `-alias file' switch.  (pro-
+                           file, no default)
+
+                 Draft-Folder: drafts
+                           Indicates a default draft folder for  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+                           and _r_e_p_l.  (profile, no default)
+
+                 digest-issue-_l_i_s_t: 1
+                           Tells _f_o_r_w the last issue of the last volume sent for the
+                           digest _l_i_s_t.  (context, no default)
+
+                 digest-volume-_l_i_s_t: 1
+                           Tells _f_o_r_w the last volume  sent  for  the  digest  _l_i_s_t.
+                           (context, no default)
+
+                 MailDrop: .mail
+                           Tells _i_n_c your maildrop, if different from  the  default.
+                           This is superceded by the MAILDROP envariable.  (profile,
+                           default: /usr/spool/mail/$USER)
+
+                 Signature: RAND MH System (agent: Marshall Rose)
+                           Tells _s_e_n_d your mail signature.  This  is  superceded  by
+                           the  SIGNATURE  envariable.   If SIGNATURE is not set and
+                           this profile entry is not present, the  "gcos"  field  of
+                           the  /_e_t_c/_p_a_s_s_w_d  file  will be used; otherwise, on hosts
+                           where _M_H was configured with the  UCI  option,  the  file
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -131-                     MH-PROFILE(5)
+
+
+                           $HOME/.signature  is  consulted.   Your signature will be
+                           added to the address _s_e_n_d puts in the "From:" header;  do
+                           not  include an address in the signature text.  (profile,
+                           no default)
+
+                 The following profile elements are  used  whenever  an  _M_H  program
+                 invokes  some  other program such as _m_o_r_e (1).  The ._m_h__p_r_o_f_i_l_e can
+                 be used to select alternate  programs  if  the  user  wishes.   The
+                 default values are given in the examples.
+
+                      fileproc:     /usr/local/refile
+                      incproc:      /usr/local/inc
+                      installproc:  /usr/local/lib/mh/install-mh
+                      lproc:        /usr/ucb/more
+                      mailproc:     /usr/local/mhmail
+                      mhlproc:      /usr/local/lib/mh/mhl
+                      moreproc:     /usr/ucb/more
+                      mshproc:      /usr/local/msh
+                      packproc:     /usr/local/packf
+                      postproc:     /usr/local/lib/mh/post
+                      rmmproc:      none
+                      rmfproc:      /usr/local/rmf
+                      sendproc:     /usr/local/send
+                      showproc:     /usr/ucb/more
+                      whatnowproc:  /usr/local/whatnow
+                      whomproc:     /usr/local/whom
+
+                 If you define the envariable MH, you can specify  a  profile  other
+                 than ._m_h__p_r_o_f_i_l_e to be read by the _M_H programs that you invoke.  If
+                 the value of MH is not absolute, (i.e., does not begin with a  / ),
+                 it  will  be  presumed to start from the current working directory.
+                 This is one of the very few exceptions  in  _M_H  where  non-absolute
+                 pathnames are not considered relative to the user's _M_H directory.
+
+                 Similarly, if you define the envariable MHCONTEXT, you can  specify
+                 a  context  other than the normal context file (as specified in the
+                 _M_H profile).  As always, unless the value of MHCONTEXT is absolute,
+                 it will be presumed to start from your _M_H directory.
+
+                 _M_H programs also support other envariables:
+
+                 MAILDROP : tells _i_n_c the default maildrop
+                      This supercedes the "MailDrop:" profile entry.
+
+                 SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail signature
+                      This supercedes the "Signature:" profile entry.
+
+                 HOME : tells all _M_H programs your home directory
+
+                 SHELL : tells _b_b_l the default shell to run
+
+                 TERM : tells _M_H your terminal type
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -132-                     MH-PROFILE(5)
+
+
+                      The TERMCAP envariable  is  also  consulted.   In  particular,
+                      these  tell  _s_c_a_n  and _m_h_l how to clear your terminal, and how
+                      many columns wide your terminal is.  They also  tell  _m_h_l  how
+                      many lines long your terminal screen is.
+
+                 editalt : the alternate message
+                      This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+                      peruse  the message being distributed or replied to.  The mes-
+                      sage is also available  through  a  link  called  "@"  in  the
+                      current  directory  if  your current working directory and the
+                      folder the message lives in are on the same UNIX filesystem.
+
+                 mhdraft : the path to the working draft
+                      This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l to  tell  the  _w_h_a_t_-
+                      _n_o_w_p_r_o_c  which  file  to  ask "What now?" questions about.  In
+                      addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l set  mhfolder  if  appropriate.
+                      Further,  _d_i_s_t  and  _r_e_p_l set mhaltmsg to tell the _w_h_a_t_n_o_w_p_r_o_c
+                      about an alternate message associated with the draft (the mes-
+                      sage being distributed or replied to), and _d_i_s_t sets mhdist to
+                      tell the _w_h_a_t_n_o_w_p_r_o_c that message  re-distribution  is  occur-
+                      ring.   Also,  mheditor  is  set  to  tell the _w_h_a_t_n_o_w_p_r_o_c the
+                      user's choice of  editor  (unless  overridden  by  `-noedit').
+                      Similarly,  mhuse  may be set by _c_o_m_p.  Finally, mhmessages is
+                      set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if annotations are to occur (along
+                      with  mhannotate, and mhinplace).  It's amazing all the infor-
+                      mation that has to get passed  via  envariables  to  make  the
+                      "What now?" interface look squeaky clean to the _M_H user, isn't
+                      it?  The reason for all this is that the _M_H  user  can  select
+                      _a_n_y  program as the _w_h_a_t_n_o_w_p_r_o_c, including one of the standard
+                      shells.  As a result, it's not possible  to  pass  information
+                      via an argument list.
+                      If the WHATNOW option was set during  _M_H  configuration  (type
+                      `-help'  to an _M_H command to find out), and if this envariable
+                      is set, if the commands _r_e_f_i_l_e, _s_e_n_d, _s_h_o_w, or  _w_h_o_m  are  not
+                      given  any  `msgs'  arguments, then they will default to using
+                      the file indicated by mhdraft.  This is useful for getting the
+                      default behavior supplied by the default _w_h_a_t_n_o_w_p_r_o_c.
+
+                 mhfolder : the folder containing the alternate message
+                      This is set by _d_i_s_t and _r_e_p_l during edit sessions so  you  can
+                      peruse  other  messages  in the current folder besides the one
+                      being distributed or replied to.  The mhfolder  envariable  is
+                      also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t for use by _m_h_l.
+
+                 MHBBRC :
+                      If you define the envariable MHBBRC, you can specify a BBoards
+                      information  file  other than ._b_b_r_c to be read by _b_b_c.  If the
+                      value of MHBBRC is not absolute, (i.e., does not begin with  a
+                      / ),  it  will  be  presumed to start from the current working
+                      directory.
+
+                 MHFD :
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -133-                     MH-PROFILE(5)
+
+
+                      If the OVERHEAD option was set during _M_H  configuration  (type
+                      `-help' to an _M_H command to find out), then if this envariable
+                      is set, _M_H considers it to be the number of a file  descriptor
+                      which  is  opened, read-only to the _M_H profile.  Similarly, if
+                      the envariable MHCONTEXTFD is set, this is  the  number  of  a
+                      file  descriptor  which is opened read-only to the _M_H context.
+                      This feature of _M_H is experimental, and  is  used  to  examine
+                      possible  speed  improvements for _M_H startup.  Note that these
+                      envariables must be set and non-empty to enable this  feature.
+                      However,  if OVERHEAD is enabled during _M_H configuration, then
+                      when _M_H programs call other _M_H programs, this scheme is  used.
+                      These file descriptors are not closed throughout the execution
+                      of the _M_H program, so children may  take  advantage  of  this.
+                      This approach is thought to be completely safe and does result
+                      in some performance enhancements.
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 or $MH                              Rather than the standard profile
+                 <mh-dir>/context                    The user context
+                 or $CONTEXT                         Rather than the standard context
+                 <folder>/.mh_sequences              Public sequences for <folder>
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 All
+
+
+            _S_e_e _A_l_s_o
+                 mh(1), environ(5), mh-sequence(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -134-                     MH-PROFILE(5)
+
+
+            _H_i_s_t_o_r_y
+                 In previous versions of _M_H, the current-message value of a writable
+                 folder  was  kept  in a file called "cur" in the folder itself.  In
+                 _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the current-message values for  all
+                 folders, regardless of their writability.
+
+                 In all versions of _M_H since _m_h._4,  the  ._m_h__p_r_o_f_i_l_e  contains  only
+                 static  information, which _M_H programs will NOT update.  Changes in
+                 context are made to the _c_o_n_t_e_x_t file kept in the users MH  _d_i_r_e_c_t_o-
+                 _r_y.  This includes, but is not limited to: the "Current-Folder" en-
+                 try and all private sequence information.  Public sequence informa-
+                 tion is kept in a file called ._m_h__s_e_q_u_e_n_c_e_s in each folder.
+
+                 To convert from the format used in releases of _M_H prior to the for-
+                 mat used in the _m_h._4 release, _i_n_s_t_a_l_l-_m_h should be invoked with the
+                 `-compat' switch.  This generally happens automatically on _M_H  sys-
+                 tems generated with the "COMPAT" option during _M_H configuration.
+
+                 The ._m_h__p_r_o_f_i_l_e may override the  path  of  the  _c_o_n_t_e_x_t  file,  by
+                 specifying  a "context" entry (this must be in lower-case).  If the
+                 entry is not absolute (does not start with a / ), then it is inter-
+                 preted  relative  to the user's _M_H directory.  As a result, you can
+                 actually have more than one set of private sequences by using  dif-
+                 ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-PROFILE(5)                    -135-                     MH-PROFILE(5)
+
+
+            _B_u_g_s
+                 The shell quoting conventions are not available in the .mh_profile.
+                 Each token is separated by whitespace.
+
+                 There is some question as to  what  kind  of  arguments  should  be
+                 placed  in  the  profile  as  options.  In order to provide a clear
+                 answer, recall command line semantics of all _M_H programs: conflict-
+                 ing  switches  (e.g., `-header and `-noheader') may occur more than
+                 one time on the command line, with the last switch  taking  effect.
+                 Other  arguments, such as message sequences, filenames and folders,
+                 are always remembered on the invocation line and are not superseded
+                 by  following  arguments  of  the  same type.  Hence, it is safe to
+                 place only switches (and their arguments) in the profile.
+
+                 If one finds that an _M_H program is being invoked  again  and  again
+                 with  the same arguments, and those arguments aren't switches, then
+                 there are a few possible solutions to this problem.  The  first  is
+                 to  create a (soft) link in your $_H_O_M_E/_b_i_n directory to the _M_H pro-
+                 gram of your choice.  By giving this link a different name, you can
+                 create  a new entry in your profile and use an alternate set of de-
+                 faults for the _M_H command.  Similarly, you  could  create  a  small
+                 shell script which called the _M_H program of your choice with an al-
+                 ternate set of invocation line switches (using links and an  alter-
+                 nate profile entry is preferable to this solution).
+
+                 Finally, the _c_s_h user could create an alias for the command of  the
+                 form:
+
+                      alias cmd 'cmd arg1 arg2 ...'
+
+                 In this way, the user can avoid lengthy type-in to the  shell,  and
+                 still  give  _M_H commands safely.  (Recall that some _M_H commands in-
+                 voke others, and that in all cases, the profile  is  read,  meaning
+                 that aliases are disregarded beyond an initial command invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -136-                    MH-SEQUENCE(5)
+
+
+            _N_A_M_E
+                 mh-sequence - sequence specification for MH message system
+
+            _S_Y_N_O_P_S_I_S
+                 most _M_H commands
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 Most _M_H commands accept a  `msg'  or  `msgs'  specification,  where
+                 `msg'  indicates  one message and `msgs' indicates one or more mes-
+                 sages.  To designate a message,  you  may  use  either  its  number
+                 (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+                      _N_a_m_e      _D_e_s_c_r_i_p_t_i_o_n
+                      first     the first message in the folder
+                      last      the last message in the folder
+                      cur       the most recently accessed message
+                      prev      the message numerically preceding "cur"
+                      next      the message numerically following "cur"
+
+                 In commands that take a `msg' argument, the default is "cur".  As a
+                 shorthand, "." is equivalent to "cur".
+
+                 For example: In a folder containing five messages numbered  5,  10,
+                 94,  177  and 325, "first" is 5 and "last" is 325.  If "cur" is 94,
+                 then "prev" is 10 and "next" is 177.
+
+                 The word `msgs' indicates that one or more messages may  be  speci-
+                 fied.   Such a specification consists of one message designation or
+                 of several message designations separated  by  spaces.   A  message
+                 designation  consists either of a message name as defined above, or
+                 a message range.
+
+                 A message range is specified as "name1-name2"  or  "name:n",  where
+                 `name',  `name1'  and  `name2'  are  message  names,  and `n' is an
+                 integer.
+
+                 The specification "name1-name2" designates  all  currently-existing
+                 messages from `name1' to `name2' inclusive.  The message name "all"
+                 is a shorthand for the message range "first-last".
+
+                 The specification "name:n" designates up to  `n'  messages.   These
+                 messages  start with `name' if `name' is a message number or one of
+                 the reserved names "first" "cur", or "next", The messages end  with
+                 `name'  if  `name'  is "prev" or "last".  The interpretation of `n'
+                 may be overridden by preceding `n' with a plus or minus sign;  `+n'
+                 always  means  up  to  `n'  messages starting with `name', and `-n'
+                 always means up to `n' messages ending with `name'.
+
+                 In commands which accept a `msgs' argument, the default  is  either
+                 "cur"  or  "all", depending on which makes more sense for each com-
+                 mand  (see  the  individual  man  pages  for  details).    Repeated
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -137-                    MH-SEQUENCE(5)
+
+
+                 specifications of the same message have the same effect as a single
+                 specification of the message.
+
+
+              _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e_s
+
+                 In addition to the "reserved"  (pre-defined)  message  names  given
+                 above,  _M_H  supports  user-defined  sequence  names.   User-defined
+                 sequences allow the _M_H user a tremendous amount of power in dealing
+                 with  groups of messages in the same folder by allowing the user to
+                 bind a group of messages to a meaningful symbolic name.
+
+                 The name used to denote a  message  sequence  must  consist  of  an
+                 alphabetic  character followed by zero or more alphanumeric charac-
+                 ters, and can not be one of the  "reserved"  message  names  above.
+                 After  defining  a  sequence, it can be used wherever an _M_H command
+                 expects a `msg' or `msgs' argument.
+
+                 Some  forms  of  message  ranges  are  allowed  with   user-defined
+                 sequences.   The  specification "name:n" may be used, and it desig-
+                 nates up to the first `n' messages (or last `n' messages for  `-n')
+                 which are elements of the user-defined sequence `name'.
+
+                 The specifications "name:next" and "name:prev" may  also  be  used,
+                 and  they  designate  the next or previous message (relative to the
+                 current message) which is an element of the  user-defined  sequence
+                 `name'.   The  specificaitions  "name:first"  and  "name:last"  are
+                 equivalent to "name:1" and "name:-1", respectively.  The specifica-
+                 tion  "name:cur" is not allowed (use just "cur" instead).  The syn-
+                 tax of these message range specifcations is subject  to  change  in
+                 the future.
+
+                 User-defined sequence names are specific to each folder.  They  are
+                 defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+              _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                 There are two varieties of sequences: _p_u_b_l_i_c sequences and  _p_r_i_v_a_t_e
+                 sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H
+                 user that can read that folder and are kept  in  the  .mh_sequences
+                 file  in  the folder.  _P_r_i_v_a_t_e sequences are accessible only to the
+                 _M_H user that defined those sequences and are kept in the user's  _M_H
+                 context file.  By default, _p_i_c_k and _m_a_r_k create _p_u_b_l_i_c sequences if
+                 the folder for which the sequences are being defined is writable by
+                 the  _M_H  user.  Otherwise, _p_r_i_v_a_t_e sequences are created.  This can
+                 be overridden with the `-public' and `-private' switches to _m_a_r_k.
+
+
+              _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+                 _M_H provides the ability to select all messages not  elements  of  a
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -138-                    MH-SEQUENCE(5)
+
+
+                 user-defined  sequence.   To  do  this,  the user should define the
+                 entry "Sequence-Negation" in the _M_H profile file; its value may  be
+                 any  string.  This string is then used to preface an existing user-
+                 defined sequence name.  This specification  then  refers  to  those
+                 messages not elements of the specified sequence name.  For example,
+                 if the profile entry is:
+
+                      Sequence-Negation: not
+
+                 then anytime an _M_H command is given "notfoo" as a `msg'  or  `msgs'
+                 argument, it would substitute all messages that are not elements of
+                 the sequence "foo".
+
+                 Obviously, the user should beware of defining sequences with  names
+                 that begin with the value of the "Sequence-Negation" profile entry.
+
+
+              _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+                 _M_H provides the ability to remember the `msgs'  or  `msg'  argument
+                 last  given to an _M_H command.  The entry "Previous-Sequence" should
+                 be defined in the _M_H profile; its value should be a  sequence  name
+                 or  multiple  sequence names separated by spaces.  If this entry is
+                 defined, when when an _M_H  command  finishes,  it  will  define  the
+                 sequence(s)  named  in the value of this entry to be those messages
+                 that were specified to the command.  Hence, a profile entry of
+
+                      Previous-Sequence: pseq
+
+                 directs any _M_H command that accepts a `msg' or `msgs'  argument  to
+                 define the sequence "pseq" as those messages when it finishes.
+
+                 Note:  there  can  be  a   performance   penalty   in   using   the
+                 "Previous-Sequence"  facility.  If it is used, all _M_H programs have
+                 to write the sequence information to the .mh_sequences file for the
+                 folder  each  time  they  run.   If the "Previous-Sequence" profile
+                 entry is not included,  only  _p_i_c_k  and  _m_a_r_k  will  write  to  the
+                 .mh_sequences file.
+
+
+              _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+                 Finally, some users like to indicate messages which have  not  been
+                 previously seen by them.  Both _i_n_c and _s_h_o_w honor the profile entry
+                 "Unseen-Sequence" to support this  activity.   This  entry  in  the
+                 .mh_profile  should  be  defined  as  one  or  more  sequence names
+                 separated by spaces.  If there is a value for "Unseen-Sequence"  in
+                 the profile, then whenever _i_n_c places new messages in a folder, the
+                 new messages will also be added to the  sequence(s)  named  in  the
+                 value of this entry.  Hence, a profile entry of
+
+                      Unseen-Sequence: unseen
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            MH-SEQUENCE(5)                   -139-                    MH-SEQUENCE(5)
+
+
+                 directs _i_n_c to add new messages to the sequence  "unseen".   Unlike
+                 the  behavior of the "Previous-Sequence" entry in the profile, how-
+                 ever, the sequence(s) will not be zeroed by _i_n_c.
+
+                 Similarly, whenever _s_h_o_w (or _n_e_x_t or _p_r_e_v) displays a message, that
+                 message   will   be   removed  from  any  sequences  named  by  the
+                 "Unseen-Sequence" entry in the profile.
+
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 <mh-dir>/context                    The user context
+                 <folder>/.mh_sequences              Public sequences for <folder>
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Sequence-Negation:   To designate messages not in a sequence
+                 Previous-Sequence:   The last message specification given
+                 Unseen-Sequence:     Those messages not yet seen by the user
+
+
+            _S_e_e _A_l_s_o
+                 mh(1), mark(1), pick(1), mh-profile(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 None
+
+
+            _C_o_n_t_e_x_t
+                 All
+
+
+            _B_u_g_s
+                 User-defined sequences are stored in the .mh_sequences  file  as  a
+                 series  of  message specifications separated by spaces.  If a user-
+                 defined sequence contains too many  individual  message  specifica-
+                 tions,  that line in the file may become too long for _M_H to handle.
+                 This will generate the error message ".mh_sequences is poorly  for-
+                 matted".   You'll  have  to edit the file by hand to remove the of-
+                 fending line.
+
+                 This can happen to users who define the  "Previous-Sequence"  entry
+                 in  the  _M_H profile and have a folder containing many messages with
+                 gaps in the numbering.  A workaround for large folders is to minim-
+                 ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            AP(8)                            -140-                             AP(8)
+
+
+            _N_A_M_E
+                 ap - parse addresses 822-style
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/ap [-form formatfile] [-format string]
+                      [-normalize] [-nonormalize] [-width columns] addrs ...
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _A_p is a program that parses addresses according to the ARPA  Inter-
+                 net  standard.   It also understands many non-standard formats.  It
+                 is useful for seeing how _M_H will interpret an address.
+
+                 The _a_p program treats each argument as one or more  addresses,  and
+                 prints  those  addresses out in the official 822-format.  Hence, it
+                 is usually best to enclose each argument in double-quotes  for  the
+                 shell.
+
+                 To override the output format used by _a_p, the  `-format string'  or
+                 `-format file'  switches  are used.  This permits individual fields
+                 of the address to be extracted with ease.  The string is  simply  a
+                 format   stringand   thefile   is   simply   a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 In addition to the standard escapes, _a_p also recognizes the follow-
+                 ing additional escape:
+
+                 _E_s_c_a_p_e  _R_e_t_u_r_n_s  _D_e_s_c_r_i_p_t_i_o_n
+                 error   string   A diagnostic if the parse failed
+
+                 If the `-normalize' switch is given, _a_p will try to track down  the
+                 official hostname of the address.
+
+                 Here is the default format string used by _a_p:
+
+                      %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+                 which says that if an error was detected, print the error,  a  `:',
+                 and  the address in error.  Otherwise, output the 822-proper format
+                 of the address.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /usr/local/lib/mh/mtstailor         tailor file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            AP(8)                            -141-                             AP(8)
+
+
+            _S_e_e _A_l_s_o
+                 dp(8),
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-format' defaults as described above
+                 `-normalize'
+                 `-width' defaults to the width of the terminal
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _a_p.  Therefore, one must usual-
+                 ly place the argument to this switch inside double-quotes.
+
+                 On hosts where _M_H was configured  with  the  BERK  option,  address
+                 parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            CONFLICT(8)                      -142-                       CONFLICT(8)
+
+
+            _N_A_M_E
+                 conflict - search for alias/password conflicts
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/conflict [-mail name] [-search directory]
+                      [aliasfiles...] [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _C_o_n_f_l_i_c_t is a program that checks to see if the  interface  between
+                 _M_H and transport system is in good shape
+
+                 _C_o_n_f_l_i_c_t also checks for maildrops in /usr/spool/mail which do  not
+                 belong  to  a  valid user.  It assumes that no user name will start
+                 with `.', and thus ignores files  in  /usr/spool/mail  which  begin
+                 with  `.'.   It also checks for entries in the _g_r_o_u_p (5) file which
+                 do not belong to a valid user, and for users  who  do  not  have  a
+                 valid  group  number.   In  addition duplicate users and groups are
+                 noted.
+
+                 If the `-mail name' switch is used, then the results will  be  sent
+                 to  the  specified  _n_a_m_e.   Otherwise,  the results are sent to the
+                 standard output.
+
+                 The `-search directory' switch can be used  to  search  directories
+                 other  than /usr/spool/mail and to report anomalies in those direc-
+                 tories.  The `-search directory' switch can appear  more  than  one
+                 time in an invocation to _c_o_n_f_l_i_c_t.
+
+                 _C_o_n_f_l_i_c_t should be run under  _c_r_o_n (8), or whenever system account-
+                 ing takes place.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /etc/passwd                         List of users
+                 /etc/group                          List of groups
+                 /usr/local/mhmail                   Program to send mail
+                 /usr/spool/mail/                    Directory of mail drop
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `aliasfiles' defaults to /usr/local/lib/mh/MailAliases
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            CONFLICT(8)                      -143-                       CONFLICT(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DP(8)                            -144-                             DP(8)
+
+
+            _N_A_M_E
+                 dp - parse dates 822-style
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/dp [-form formatfile] [-format string]
+                      [-width columns] dates ...  [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _D_p is a program that parses dates according to  the  ARPA  Internet
+                 standard.   It  also understands many non-standard formats, such as
+                 those  produced  by  TOPS-20  sites  and  some  UNIX  sites   using
+                 _c_t_i_m_e (3).  It is useful for seeing how _M_H will interpret a date.
+
+                 The _d_p program treats each argument as a single  date,  and  prints
+                 the date out in the official 822-format.  Hence, it is usually best
+                 to enclose each argument in double-quotes for the shell.
+
+                 To override the output format used by _d_p, the  `-format string'  or
+                 `-format file'  switches  are used.  This permits individual fields
+                 of the address to be extracted with ease.  The string is  simply  a
+                 format   stringand   thefile   is   simply   a  format  file.   See
+                 _m_h-_f_o_r_m_a_t (5) for the details.
+
+                 Here is the default format string used by _d_p:
+
+                      %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+                 which says that if an error was detected, print the error,  a  `:',
+                 and  the date in error.  Otherwise, output the 822-proper format of
+                 the date.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 None
+
+
+            _S_e_e _A_l_s_o
+                 ap(8)
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-format' default as described above
+                 `-width' default to the width of the terminal
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            DP(8)                            -145-                             DP(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The argument to the `-format' switch must be interpreted as a  sin-
+                 gle token by the shell that invokes _d_p.  Therefore, one must usual-
+                 ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            FMTDUMP(8)                       -146-                        FMTDUMP(8)
+
+
+            _N_A_M_E
+                 fmtdump - decode MH format files
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/fmtdump [-form formatfile] [-format string]
+                      [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _F_m_t_d_u_m_p is a program that parses an _M_H format file and  produces  a
+                 pseudo-language listing of the how _M_H interprets the file.
+
+                 The `-format string' and `-form formatfile' switches may be used to
+                 specify a format string or format file to read.  The string is sim-
+                 ply a format string and the file is simply a format file.  See  _m_h-
+                 _f_o_r_m_a_t(5) for the details.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+                 /usr/local/lib/mh/scan.default      The default format file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To determine the user's MH directory
+
+
+            _S_e_e _A_l_s_o
+                 mh-format(5), mh-sequences(8)
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 The output may not be useful  unless  you  are  familiar  with  the
+                 internals of the mh-format subroutines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            INSTALL-MH(8)                    -147-                     INSTALL-MH(8)
+
+
+            _N_A_M_E
+                 install-mh - initialize the MH environment
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 When a user runs any _M_H program for the  first  time,  the  program
+                 will  invoke _i_n_s_t_a_l_l-_m_h (with the `-auto' switch) to query the user
+                 for the initial _M_H environment.  The user does NOT invoke this pro-
+                 gram  directly.   The  user  is asked for the name of the directory
+                 that will be designated as the user's _M_H directory.  If this direc-
+                 tory  does  not  exist,  the user is asked if it should be created.
+                 Normally, this directory should be under the user's home directory,
+                 and  has  the  default name of Mail/.  After _i_n_s_t_a_l_l-_m_h has written
+                 the initial .mh_profile for the user, control returns to the origi-
+                 nal _M_H program.
+
+                 As with all  _M_H  commands,  _i_n_s_t_a_l_l-_m_h  first  consults  the  $HOME
+                 envariable to determine the user's home directory.  If $HOME is not
+                 set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+                 When converting from _m_h._3  to  _m_h._4,  _i_n_s_t_a_l_l-_m_h  is  automatically
+                 invoked with the `-compat' switch.
+
+            _F_i_l_e_s
+                 $HOME/.mh_profile                   The user profile
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 Path:                To set the user's MH directory
+
+
+            _C_o_n_t_e_x_t
+                 With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POST(8)                          -148-                           POST(8)
+
+
+            _N_A_M_E
+                 post - deliver a message
+
+            _S_Y_N_O_P_S_I_S
+                 /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+                      [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+                      file [-help]
+
+            _D_E_S_C_R_I_P_T_I_O_N
+
+                 _P_o_s_t is the program called by _s_e_n_d (1) to deliver  the  message  in
+                 _f_i_l_e  to  local  and  remote  users.  In fact, all of the functions
+                 attributed to _s_e_n_d on its manual page are performed by  _p_o_s_t,  with
+                 _s_e_n_d  acting as a relatively simple preprocessor.  Thus, it is _p_o_s_t
+                 which parses the various header fields,  appends  From:  and  Date:
+                 lines, and interacts with the _S_e_n_d_M_a_i_l transport system.  _P_o_s_t will
+                 not normally be called directly by the user.
+
+                 _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:",  and  "Resent-xxx:"
+                 header  lines  of  the specified message for destination addresses,
+                 checks these addresses for validity, and formats them so as to con-
+                 form  to  ARPAnet  Internet  Message  Format  protocol,  unless the
+                 `-noformat' flag is set.  This will normally cause "@_l_o_c_a_l-_s_i_t_e" to
+                 be appended to each local destination address, as well as any local
+                 return addresses. The `-width columns' switch can be used to  indi-
+                 cate  the  preferred  length  of the header components that contain
+                 addresses.
+
+                 If a "Bcc:" field is encountered, its addresses will  be  used  for
+                 delivery,  and  the  "Bcc:"  field will be removed from the message
+                 sent to sighted recipients.  The blind recipients will  receive  an
+                 entirely  new  message  with a minimal set of headers.  Included in
+                 the body of the message will be a copy of the message sent  to  the
+                 sighted  recipients.   If  `-filter filterfile'  is specified, then
+                 this copy is filtered (re-formatted) prior to  being  sent  to  the
+                 blind recipients.
+
+                 The `-alias aliasfile' switch can be used to specify  a  file  that
+                 post  should  take  aliases from.  More than one file can be speci-
+                 fied, each being preceded with `-alias'.  In any event, the primary
+                 alias file is read first.
+
+                 The   `-msgid'   switch   indicates   that   a   "Message-ID:"   or
+                 "Resent-Message-ID:" field should be added to the header.
+
+                 The `-verbose' switch indicates that the user should be informed of
+                 each step of the posting/filing process.
+
+                 The `-watch' switch indicates that the user would like to watch the
+                 transport  system's handling of the message (e.g., local and "fast"
+                 delivery).
+
+            [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+            POST(8)                          -149-                           POST(8)
+
+
+                 _P_o_s_t consults the envariable $SIGNATURE to determine  the  sender's
+                 personal name in constructing the "From:" line of the message.
+
+            _F_i_l_e_s
+                 /usr/local/lib/mh/mtstailor         tailor file
+                 /usr/local/refile                   Program to process Fcc:s
+                 /usr/local/lib/mh/mhl               Program to process Bcc:s
+                 /usr/local/lib/mh/MailAliases       Primary alias file
+
+
+            _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+                 _p_o_s_t does NOT consult the user's .mh_profile
+
+
+            _S_e_e _A_l_s_o
+                 _S_t_a_n_d_a_r_d _f_o_r  _t_h_e  _F_o_r_m_a_t  _o_f  _A_R_P_A  _I_n_t_e_r_n_e_t  _T_e_x_t  _M_e_s_s_a_g_e_s  (aka
+                 RFC-822),
+                 mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+            _D_e_f_a_u_l_t_s
+                 `-alias /usr/local/lib/mh/MailAliases'
+                 `-format'
+                 `-nomsgid'
+                 `-noverbose'
+                 `-nowatch'
+                 `-width 72'
+                 `-nofilter'
+
+
+            _C_o_n_t_e_x_t
+                 None
+
+
+            _B_u_g_s
+                 "Reply-To:" fields are allowed to have groups in them according  to
+                 the 822 specification, but _p_o_s_t won't let you use them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                 [mh.6]                           MH.6.8                      UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+                                          _5. _R_E_P_O_R_T_I_N_G _P_R_O_B_L_E_M_S
+
+
+
+
+
+                      If problems are encountered with an _M_H program, the problems should
+                 be  reported  to the local maintainers of _M_H.  When doing this, the name
+                 of the program should be reported, along with  the  version  information
+                 for  the  program.   To  find out what version of an _M_H program is being
+                 run, invoke the program with the `-help' switch.  In addition to listing
+                 the  syntax of the command, the program will list information pertaining
+                 to its version.  This information includes the version of _M_H,  the  host
+                 it was generated on, and the date the program was loaded.  A second line
+                 of information, found on versions of _M_H after #5.380 include  _M_H  confi-
+                 guration options.  For example,
+
+                      version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov  6  01:13:53  PST
+                      1985
+                      options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII] [SMTP] [POP]
+
+                 The `6.1 #1[UCI]' indicates that the program is from the UCI  _m_h._6  ver-
+                 sion  of  _M_H.   The  program was generated on the host `nrtc-gremlin' on
+                 `Wed Nov  6 01:13:53 PST 1985'.  It's usually a good idea  to  send  the
+                 output of the `-help' switch along with your report.
+
+                 If there is no local _M_H maintainer, try the  address  Bug-MH.   If  that
+                 fails, use the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -150-
+
+
+
+
+
+
+
+
+
+
+
+
+                                           _6. _A_D_V_A_N_C_E_D _F_E_A_T_U_R_E_S
+
+
+
+
+
+                      This section describes some  features  of  _M_H  that  were  included
+                 strictly for advanced _M_H users.  These capabilities permit _M_H to exhibit
+                 more powerful behavior for the seasoned _M_H users.
+
+
+                 _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+                      User-defined sequences allow the _M_H user  a  tremendous  amount  of
+                 power  in dealing with groups of messages in the same folder by allowing
+                 the user to bind a group of messages to a meaningful symbolic name.  The
+                 user  may choose any name for a message sequence, as long as it consists
+                 of alphanumeric characters and does not conflict with  the  standard  _M_H
+                 reserved message names (e.g., "first", etc).  After defining a sequence,
+                 it can be used wherever an _M_H command expects a `msg'  or  `msgs'  argu-
+                 ment.
+
+                      A restricted form of message ranges are allowed  with  user-defined
+                 sequences.  The  form  "name:n",  specifies up to the first `n' messages
+                 which are part of the user-defined sequence `name'.  A leading plus sign
+                 is  allowed on `n', but is ignored.  The interpretation of n is overrid-
+                 den if n is preceded by a minus sign; `-n' always means up to  the  last
+                 `n' messages which are part of the sequence `name'.
+
+                      Although all _M_H commands expand user-defined sequences as appropri-
+                 ate, there are two commands that allow the user to define and manipulate
+                 them: _p_i_c_k and _m_a_r_k.
+
+                 _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      Most users of _M_H will use user-defined sequences only with the _p_i_c_k
+                 command.  By giving the `-sequence name' switch to _p_i_c_k (which can occur
+                 more than once on the command line), each sequence named is  defined  as
+                 those  messages  which _p_i_c_k matched according the the selection criteria
+                 it was given.  Hence,
+
+                      pick -from frated -seq fred
+
+                 finds all those messages in the current folder which were from "frated",
+                 creates  a  sequence  called "fred", and then adds them to the sequence.
+                 The user could then invoke
+
+                      scan fred
+
+                 to get a _s_c_a_n listing of those messages.  Note  that  by  default,  _p_i_c_k
+                 creates  the named sequences before it adds the selected messages to the
+                 sequence.  Hence, if the named sequence already existed, the sequence is
+
+                                                  -151-
+
+
+
+
+
+
+
+
+
+                                                  -152-
+
+
+                 destroyed  prior  to  being  re-defined (nothing happens to the messages
+                 that were a part of this sequence, they simply cease to  be  members  of
+                 that  sequence).   By  using  the `-nozero' switch, this behavior can be
+                 inhibited, as in
+
+                      pick -from frated -seq sgroup
+                      pick -from fear -seq sgroup -nozero
+                      pick -from freida -seq sgroup -nozero
+
+                 finds all those messages in the current folder which were from "frated",
+                 "fear", or "freida", and defines the sequence called "sgroup" as exactly
+                 those messages.  These operations amounted to an "inclusive-or" of three
+                 selection  criteria, using _p_i_c_k, one can also generate the "and" of some
+                 selection criteria as well:
+
+                      pick -from frated -seq fred
+                      pick -before friday -seq fred fred
+
+                 This example defines the sequence called "fred" as  exactly  those  mes-
+                 sages from "frated" that were dated prior to "friday".[1]
+
+                      _P_i_c_k is normally used as a back-quoted command, for example,
+
+                      scan `pick -from postmaster`
+
+                 Now suppose that the user decides that another command should be issued,
+                 using   exactly   those   messages.    Since,   _p_i_c_k   wasn't   given  a
+                 `-sequence name' argument in this example, the user would end-up  typing
+                 the entire back-quoted command again.  A simpler way is to add a default
+                 sequence name to the .mh_profile.  For example,
+
+                      pick: -seq select -list
+
+                 will tell _p_i_c_k to always define the sequence "select" whenever it's run.
+                 The  `-list'  is necessary since the `-sequence name' switch sets `-nol-
+                 ist' whenever the former is  encountered.   Hence,  this  profile  entry
+                 makes  _p_i_c_k define the "select" sequence and otherwise behave exactly as
+
+
+                    [1]  Of  course, it is much easier to simply use the built-in boolean
+                 operation of _p_i_c_k to get the desired results:
+
+                      pick -from frated -or -from fear -or -from freida -seq sgroup
+
+                 and
+
+                      pick -from frated -and -before friday -seq fred
+
+                 do exactly the same thing as the five commands listed above.  Hence, the
+                 `-nozero'  option  to  _p_i_c_k  is  only  useful to manipulate existing se-
+                 quences.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -153-
+
+
+                 if there was no profile entry at all.
+
+                 _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      The _m_a_r_k command lets the user perform  low-level  manipulation  of
+                 sequences,  and  also  provides  a  well-needed  debug  facility  to the
+                 implementors/developers/maintainers  of  _M_H  (the  _M_H-hacks).   In   the
+                 future,  a user-friendly "front-end" for _m_a_r_k will probably be developed
+                 to give the _M_H user a way to take better  advantage  of  the  underlying
+                 facilities.
+
+                 _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e _U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+                      There are two kinds of sequences:  _p_u_b_l_i_c  sequences,  and  _p_r_i_v_a_t_e
+                 sequences.   _P_u_b_l_i_c  sequences of a folder are accessible to any _M_H user
+                 that can read that folder and are kept in the .mh_sequences file in  the
+                 folder.   _P_r_i_v_a_t_e  sequences  are  accessible  only  to the _M_H user that
+                 defined those sequences and are kept in the user's _M_H context file.   By
+                 default,  _p_i_c_k  (and  _m_a_r_k )  create  _p_u_b_l_i_c sequences if the folder for
+                 which the sequences are being defined is writable by the _M_H user.   Oth-
+                 erwise,  _p_r_i_v_a_t_e sequences are created.  This can be overridden with the
+                 `-public' and `-nopublic' switches.
+
+                 _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+                      In addition to telling an _M_H command to use  the  messages  in  the
+                 sequence "seen", as in
+
+                      refile seen +old
+
+                 it would be useful to be easily able to tell an _M_H command  to  use  all
+                 messages  _e_x_c_e_p_t  those in the sequence.  One way of doing this would be
+                 to use _m_a_r_k and define the sequence explicitly, as in
+
+                      mark -delete -zero seen -seq notseen
+
+                 which, owing to _m_a_r_k 's cryptic interpretation of `-delete' and `-zero',
+                 defines  the  sequence  "notseen" to be all messages not in the sequence
+                 "seen".  Naturally, anytime the sequence "seen"  is  changed,  "notseen"
+                 will  have  to be updated.  Another way to achieve this is to define the
+                 entry "Sequence-Negation:" in the .mh_profile.  If the entry was
+
+                      Sequence-Negation: not
+
+                 then anytime an _M_H command was given "notseen"  as  a  `msg'  or  `msgs'
+                 argument,  it would substitute all messages that are not a member of the
+                 sequence "seen".  That is,
+
+                      refile notseen +new
+
+                 does just that.  The value of the "Sequence-Negation:" entry in the pro-
+                 file  can  be  any  string.  Hence, experienced users of _M_H do not use a
+
+
+
+
+
+
+
+
+
+
+
+                                                  -154-
+
+
+                 word, but rather a special character which their shell does  not  inter-
+                 pret  (users  of  the  _C_S_h_e_l_l  use a single caret or circumflex (usually
+                 shift-6), while users of the  Bourne  shell  use  an  exclamation-mark).
+                 This is because there is nothing to prevent a user of _M_H from defining a
+                 sequence with this string as its prefix, if the  string  is  nothing  by
+                 letters and digits.  Obviously, this could lead to confusing behavior if
+                 the "Sequence-Negation:" entry leads _M_H to believe  that  two  sequences
+                 are opposites by virtue of their names differing by the prefix string.
+
+                 _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+                      Many times users find themselves issuing a series  of  commands  on
+                 the  same  sequences  of messages.  If the user first defined these mes-
+                 sages as a sequence, then considerable typing may be saved.  If the user
+                 doesn't  have  this  foresight,  _M_H  provides  a  handy way of having _M_H
+                 remember the `msgs' or `msg' argument last given to an _M_H  command.   If
+                 the  entry "Previous-Sequence:" is defined in the .mh_profile, then when
+                 the command finishes, it will define the sequence(s) named in the  value
+                 of  this  entry  as  being  exactly  those messages that were specified.
+                 Hence, a profile entry of
+
+                      Previous-Sequence: pseq
+
+                 directs any _M_H command that accepts a `msg' or `msgs' argument to define
+                 the  sequence  "pseq" as those messages when it finishes.  More than one
+                 sequence name may be placed in this entry, separated with  spaces.   The
+                 one  disadvantage of this approach is that the _M_H progams have to update
+                 the sequence information for the folder each  time  they  run  (although
+                 most  programs read this information, usually only _p_i_c_k and _m_a_r_k have to
+                 write this information out).
+
+                 _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+                      Finally, some users like to distinguish between messages which have
+                 been  previously seen by them.  Both _i_n_c and _s_h_o_w honorthe profile entry
+                 "Unseen-Sequence" to support this activity.   Whenever  _i_n_c  places  new
+                 messages  in  a folder, if the entry "Unseen-Sequence" is defined in the
+                 .mh_profile, then when the command finishes, _i_n_c will add the  new  mes-
+                 sages  to  the  sequence(s)  named in the value of this entry.  Hence, a
+                 profile entry of
+
+                      Unseen-Sequence:  unseen
+
+                 directs _i_n_c to add new messages to the sequence  "unseen".   Unlike  the
+                 behavior  of  the  "Previous-Sequence" entry in the profile however, the
+                 sequence(s) will not be zero'd.
+
+                      Similarly, whenever _s_h_o_w (or _n_e_x_t or  _p_r_e_v )  displays  a  message,
+                 they   remove   those   messages   from   any  sequences  named  by  the
+                 "Unseen-Sequence" entry in the profile.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -155-
+
+
+                 _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+                      There are a number of interesting advanced facilities for the  com-
+                 position of outgoing mail.
+
+
+                 _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+                      The  _c_o_m_p,  _d_i_s_t,  _f_o_r_w,  and  _r_e_p_l  commands  have  two  switches,
+                 `-draftfolder +folder'        and        `-draftmessage msg'.         If
+                 `-draftfolder +folder' is used, these commands are directed to construct
+                 a  draft  message in the indicated folder.  (The "Draft-Folder:" profile
+                 entry may be used to declare a default draft folder for use  with  _c_o_m_p,
+                 _d_i_s_t, _f_o_r_w, and _r_e_p_l) If `-draftmessage msg' is not used, it defaults to
+                 `new' (unless the user invokes _c_o_m_p  with  `-use',  in  which  case  the
+                 default  is  `cur').   Hence, the user may have several message composi-
+                 tions in progress simultaneously.  Now, all of the _M_H tools  are  avail-
+                 able  on  each of the user's message drafts (e.g., _s_h_o_w, _s_c_a_n, _p_i_c_k, and
+                 so on).  If the folder does not exist, the user is asked if it should be
+                 created (just like with _r_e_f_i_l_e ).  Also, the last draft message the user
+                 was composing is known as `cur' in the draft folder.
+
+                      Furthermore, the _s_e_n_d command has these switches as  well.   Hence,
+                 from  the shell, the user can send off whatever drafts desired using the
+                 standard _M_H `msgs' convention with `-draftmessage msgs'.  If  no  `msgs'
+                 are given, it defaults to `cur'.
+
+                      In addition, all five  programs  have  a  `-nodraftfolder'  switch,
+                 which undoes the last occurrence of `-draftfolder folder' (useful if the
+                 latter occurs in the user's _M_H profile).
+
+                      If the user does not give the `-draftfolder +folder'  switch,  then
+                 all  these  commands act ``normally''.  Note that the `-draft' switch to
+                 _s_e_n_d and _s_h_o_w still refers to the file called `draft' in the  user's  _M_H
+                 directory.   In  the interests of economy of expression, when using _c_o_m_p
+                 or _s_e_n_d, the user needn't prefix the draft `msg' or `msgs' with `-draft-
+                 message'.   Both  of these commands accept a `file' or `files' argument,
+                 and they will, if given `-draftfolder +folder' treat these arguments  as
+                 `msg' or `msgs'.[2] Hence,
+
+                      send -draftf +drafts first
+
+                 is the same as
+
+                      send -draftf +drafts -draftm first
+
+
+
+
+                    [2]  This may appear to be inconsistent, at first, but it saves a lot
+                 of typing.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -156-
+
+
+                      To make all this a bit more clear, here are some  examples.   Let's
+                 assume that the following entries are in the _M_H profile:
+
+                      Draft-Folder: +drafts
+                      sendf: -draftfolder +drafts
+
+                 Furthermore, let's assume that the program _s_e_n_d_f is a (symbolic) link in
+                 the user's $HOME/bin/ directory to _s_e_n_d.  Then, any of the commands
+
+                      comp
+                      dist
+                      forw
+                      repl
+
+                 constructs the message draft in the `draft' folder using the `new'  mes-
+                 sage  number.   Furthermore, they each define `cur' in this folder to be
+                 that message draft.  If the user were to use the _q_u_i_t  option  at  `What
+                 now?'  level, then later on, if no other draft composition was done, the
+                 draft could be sent with simply
+
+                      sendf
+
+                 Or, if more editing was required, the draft could be edited with
+
+                      comp -use
+
+                 Instead, if other drafts had been composed in the meantime, so that this
+                 message  draft  was no longer known as `cur' in the `draft' folder, then
+                 the user could _s_c_a_n the folder to see which message draft in the  folder
+                 should be used for editing or sending.  Clever users could even employ a
+                 back-quoted _p_i_c_k to do the work:
+
+                      comp -use `pick +drafts -to bug-mh`
+
+                 or
+
+                      sendf `pick +drafts -to bug-mh`
+
+                 Note that in the _c_o_m_p example, the output from _p_i_c_k must  resolve  to  a
+                 single  message  draft (it makes no sense to talk about composing two or
+                 more drafts with one invocation of _c_o_m_p ).  In  contrast,  in  the  _s_e_n_d
+                 example,  as  many  message  drafts  as  desired  can appear, since _s_e_n_d
+                 doesn't mind sending more than one draft at a time.
+
+                      Note that the argument `-draftfolder +folder' is  not  included  in
+                 the  profile  entry  for  _s_e_n_d,  since  when  _c_o_m_p, et. al., invoke _s_e_n_d
+                 directly, they supply _s_e_n_d with the UNIX pathname of the message  draft,
+                 and  not  a `draftmessage msg' argument.  As far as _s_e_n_d is concerned, a
+                 _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+                      It is important to realize that _M_H treats the draft folder  like  a
+                 standard  _M_H  folder  in nearly all respects.  There are two exceptions:
+
+
+
+
+
+
+
+
+
+
+
+                                                  -157-
+
+
+                 first_____, under no circumstancs will the `-draftfolder folder' switch cause
+                 the named folder to become the current folder.[3] Second______, although  con-
+                 ceptually _s_e_n_d deletes the `msgs' named in the draft folder, it does not
+                 call `delete-prog' to perform the deletion.
+
+
+                 _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e _D_r_a_f_t _E_x_i_s_t_s
+
+                      When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands are  invoked  and  the
+                 draft  you indicated already exists, these programs will prompt the user
+                 for a reponse directing the program's action.  The prompt is
+
+                      Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+                      Disposition?
+
+                 The appropriate responses and their meanings are: replace_______:  deletes  the
+                 draft  and starts afresh; list____: lists the draft; refile______: files the draft
+                 into a folder and starts afresh; and, quit____: leaves the draft intact  and
+                 exits.   In addition, if you specified `-draftfolder folder' to the com-
+                 mand, then one other response will be accepted: new___: finds a new  draft,
+                 just  as  if `-draftmessage new' had been given.  Finally, the _c_o_m_p com-
+                 mand will accept one more response: use___: re-uses the draft, just  as  if
+                 `-use' had been given.
+
+
+                 _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+                      The _p_u_s_h option to the "What now?" query in the _c_o_m_p,  _d_i_s_t,  _f_o_r_w,
+                 and  _r_e_p_l  commands,  directs the command to _s_e_n_d the draft in a special
+                 detached fashion, with all normal output discarded.  If _p_u_s_h is used and
+                 the  draft  can not be sent, then _M_H will send the user a message, indi-
+                 cating the name of the draft file, and an explanation of the failure.
+
+                      The user can also invoke _s_e_n_d  from  the  shell  with  the  `-push'
+                 switch, which makes _s_e_n_d act like it had been _p_u_s_h 'd by one of the com-
+                 position commands.
+
+                      By using _p_u_s_h, the user can free the  shell  to  do  other  things,
+                 because  it appears to the shell that the _M_H command has finished.  As a
+                 result the shell will immediately prompt for  another  command,  despite
+                 the  fact  that  the  command is really still running.  Note that if the
+                 user indicates that annotations are to be performed (with `-annotate' to
+
+
+                    [3]  Obviously,  if  the folder appeared in the context of a standard
+                 `+folder' argument to an _M_H program, as in
+
+                      scan +drafts
+
+                 it might become the current folder, depending on the context changes  of
+                 the _M_H program in question.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -158-
+
+
+                 _d_i_s_t, _f_o_r_w, or _r_e_p_l), the annotations will be performed after  the  mes-
+                 sage has been successfully sent.  This action will appear to occur asyn-
+                 chronously.  Obviously, if one of the messages that is to  be  annotated
+                 is  removed  before  the  draft has been successfully sent, then when _M_H
+                 tries to make the annotations, it won't be able to do so.   In  previous
+                 versions of _M_H, this resulted in an error message mysteriously appearing
+                 on the user's terminal.  In _m_h._5 and later  versions,  in  this  special
+                 circumstance, no error will be generated.
+
+                      If send is _p_u_s_h 'd, then the `-forward' switch  is  examined  if  a
+                 failure notice is generated.  If given, then the draft is forwarded with
+                 the failure notice sent to the user.  This allows  rapid  _b_u_r_s_t 'ing  of
+                 the failure notice to retrieve the unsent draft.
+
+
+                 _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+                      By default, the message composition programs call a program  called
+                 _w_h_a_t_n_o_w  before  the initial draft composition.  The _M_H user can specify
+                 any program for this.  Following is some information about  the  default
+                 "What  now?" level.  More detailed information can be found in the _w_h_a_t_-
+                 _n_o_w (1) manual entry.
+
+                      When using the _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l commands at  "What  now?"
+                 level,  the _e_d_i_t, _l_i_s_t, _h_e_a_d_e_r_s, _r_e_f_i_l_e, and (for the _d_i_s_t and _r_e_p_l com-
+                 mands) the _d_i_s_p_l_a_y options will pass on any additional  arguments  given
+                 them to whatever program they invoke.
+
+                      In _m_h._1 (the original RAND _M_H ) and _m_h._2 (the first UCI version  of
+                 _M_H ),  _M_H  used a complicated heuristic to determine if the draft should
+                 be deleted or preserved after an unsuccessful edit.   In  _m_h._3,  _M_H  was
+                 changed to preserve the draft always, since _c_o_m_p, et. al., could usually
+                 look at a draft, apply another set of heuristics, and decide if  it  was
+                 important  or  not.   With the notion of a _d_r_a_f_t _f_o_l_d_e_r, in which one by
+                 default gets a `new' message draft, the edit deletion/preservation algo-
+                 rithm  was re-implemented, to keep the draft folder from being cluttered
+                 with aborted edits.
+
+                      Also, note that by default, if the  draft  cannot  be  successfully
+                 sent,  these  commands  return  to "What now?" level.  But, when _p_u_s_h is
+                 used, this does not happen (obviously).  Hence, if these  commands  were
+                 expected  to  annotate  any messages, this will have to be done by hand,
+                 later on, with the _a_n_n_o command.
+
+                      Finally, if the `-delete' switch is not given to the  _q_u_i_t  option,
+                 then these commands will inform the user of the name of the unsent draft
+                 file.
+
+
+                 _D_i_g_e_s_t_s
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -159-
+
+
+                      The _f_o_r_w command has the beginnings  of  a  digestifying  facility,
+                 with the `-digest list', `-issue number', and `-volume number' switches.
+
+                 If _f_o_r_w is given "list" to the `-digest' switch as the name of the  dis-
+                 cussion  group,  and  the `-issue number' switch is not given, then _f_o_r_w
+                 looks for an entry in the user's _M_H context  called  "_d_i_g_e_s_t-issue-list"
+                 and  increments its value to use as the issue number.  Similarly, if the
+                 `-volume number'  switch   is   not   given,   then   _f_o_r_w   looks   for
+                 "_d_i_g_e_s_t-volume-list"  (but  does  not increment its value) to use as the
+                 volume number.
+
+                 Having calculated the name of  the  digest  and  the  volume  and  issue
+                 numbers, _f_o_r_w will now process the components file using the same format
+                 string mechanism used by _r_e_p_l.  The current `%'-escapes are:
+
+                 _e_s_c_a_p_e  _t_y_p_e     _s_u_b_s_t_i_t_u_t_i_o_n
+                 digest  string   digest name
+                 msg     integer  issue number
+                 cur     integer  volume number
+
+                 In addition, to capture the current date, any of the escapes  valid  for
+                 _d_p (8) are also valid for _f_o_r_w.
+
+                 The default components file used by _f_o_r_w when in digest mode is:
+
+                      From:     %{digest}-Request
+                      To:       %{digest} Distribution: dist-%{digest};
+                      Subject:  %{digest} Digest V%(cur) #%(msg)
+                      Reply-To: %{digest}
+                      --------
+                      %{digest} Digest        %(weekday{date}), %2(mday{date}) %(month{date}) 19%02(year{date})
+                                      Volume %(cur) : Issue %(msg)
+
+                      Today's Topics:
+
+                 Hence, when the `-digest' switch is present, the  first  step  taken  by
+                 _f_o_r_w  is  to  expand the format strings in the component file.  The next
+                 step is to compose the draft using  the  standard  digest  encapsulation
+                 algorithm  (even  putting an "End of list Digest" trailer in the draft).
+                 Once the draft is composed by _f_o_r_w, _f_o_r_w writes out the volume and issue
+                 profile entries for the digest, and then invokes the editor.
+
+                 Naturally,   when   composing   the   draft,   _f_o_r_w   will   honor   the
+                 `-filter filterfile'  switch,  which is given to _m_h_l to filter each mes-
+                 sage being forwarded prior to encapsulation in the draft.  A good filter
+                 file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -160-
+
+
+                      width=80,overflowoffset=10
+                      leftadjust,compress,compwidth=9
+                      Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+                      From:
+                      Subject:
+                      :
+                      body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+                 _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+                      There are two  interesting  facilities  for  manipulating  folders:
+                 relative folder addressing, which allows a user to shorten the typing of
+                 long folder names; and the folder-stack, which permits a user to keep  a
+                 stack of current folders.
+
+
+                 _R_e_l_a_t_i_v_e _F_o_l_d_e_r _A_d_d_r_e_s_s_i_n_g
+
+                      By default, when `+folder' is given, and the  folder  name  is  not
+                 absolute  (does not start with /, ./, or ../), then the UNIX pathname of
+                 the folder is interpreted relative to the user's _M_H directory.  Although
+                 this  mechanism  works  fine  for  top-level folders and their immediate
+                 sub-folders, once the depth of the sub-folder  tree  grows,  it  becomes
+                 rather unwieldly:
+
+                      scan +mh/mh.4/draft/flames
+
+                 is a lot of typing.  _M_H can't do anything  if  the  current  folder  was
+                 "+inbox", but if the current folder was, say, "+mh/mh.4/draft", _M_H has a
+                 short-hand notation to reference a sub-folder  of  the  current  folder.
+                 Using  the  `@folder'  notation,  the  _M_H user can direct any _M_H program
+                 which expects a `+folder' argument to look for the  folder  relative  to
+                 the  current  folder  instead of the user's _M_H directory.  Hence, if the
+                 current folder _w_a_s "+mh/mh.4/draft", then
+
+                      scan @flames
+
+                 would do the trick handily.  In addition,  if  the  current  folder  _w_a_s
+                 "+mh/mh.4/draft",
+
+                      scan @../pick
+
+                 would scan the folder "+mh/mh.4/pick", since, in the  UNIX  fashion,  it
+                 references the folder "pick" which is a sub-folder of the folder that is
+                 the parent of the current folder.  Since most advanced _M_H users seem  to
+                 exhibit a large degree of locality in referencing folders when they pro-
+                 cess mail, this convention should receive a wide range of uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -161-
+
+
+                 _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+                      The _f_o_l_d_e_r-_s_t_a_c_k mechanism in _M_H gives the _M_H user a facility simi-
+                 lar to the _C_S_h_e_l_l 's directory-stack.  Simply put,
+
+                      folder -push +foo
+
+                 makes "foo" the current folder, saving the folder  that  was  previously
+                 the current folder on the _f_o_l_d_e_r-_s_t_a_c_k.  As expected,
+
+                      folder -pop
+
+                 takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and makes it the current folder.  Each
+                 of  these switches lists the _f_o_l_d_e_r-_s_t_a_c_k when they execute.  It is sim-
+                 ple to write a _p_u_s_h_f command as a shell script.  It's one line:
+
+                      exec folder -push $@
+
+                 Probably a better way is to link  _f_o_l_d_e_r  to  the  $HOME/bin/  directory
+                 under the name of _p_u_s_h_f and then add the entry
+
+                      pushf: -push
+
+                 to the .mh_profile.
+
+                      The manual page for _f_o_l_d_e_r discusses the analogy between the _C_S_h_e_l_l
+                 directory stack commands and the switches in _f_o_l_d_e_r which manipulate the
+                 _f_o_l_d_e_r-_s_t_a_c_k.  The _f_o_l_d_e_r command uses the context entry `Folder-Stack:'
+                 to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                Appendix A
+                                             _C_O_M_M_A_N_D _S_U_M_M_A_R_Y
+
+
+
+
+                 ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+                      [-nonormalize] [-user] [-nouser] aliases ...  [-help]
+
+                 anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+                      [-date] [-nodate] [-text body] [-help]
+
+                 bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+                      [-archive] [-noarchive] [-protocol] [-noprotocol]
+                      [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile rcfile]
+                      [-norcfile] [-file BBoardsfile] [-user BBoardsuser] [-help]
+
+                 burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+                      [-verbose] [-noverbose] [-help]
+
+                 comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+                      [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+                      [-form formfile] [-use] [-nouse] [-whatnowproc program]
+                      [-nowhatnowproc] [-help]
+
+                 dist [+folder] [msg] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-form formfile] [-inplace]
+                      [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+                 /usr/local/lib/mh/fmtdump [-form formatfile] [-format string]
+                      [-help]
+
+                 folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+                      [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+                      [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+                      [-pop] [-help]
+
+                 folders
+
+                 forw [+folder] [msgs] [-annotate] [-noannotate]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-filter filterfile]
+                      [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+                      [-whatnowproc program] [-nowhatnowproc] [-help]
+
+                 forw [+folder] [msgs] [-digest list] [-issue number]
+                      [-volume number] [other switches for _f_o_r_w] [-help]
+
+
+
+
+
+                                             -162-
+
+
+
+
+
+
+
+
+
+
+
+
+                 inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+                      [-nochangecur] [-file name] [-form formatfile]
+                      [-format string] [-silent] [-nosilent] [-truncate]
+                      [-notruncate] [-width columns] [-help]
+
+                 mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+                      [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+                 /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+                      [-folder +folder] [-form formfile] [-length lines]
+                      [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+                      [-help]
+
+                 mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+                      [-subject subject]] [-help]
+
+                 mhparam [profile-components] [-components] [-nocomponents] [-all]
+                      [-help]
+
+                 mhpath [+folder] [msgs] [-help]
+
+                 msgchk [-date] [-nodate] [-notify all/mail/nomail]
+                      [-nonotify all/mail/nomail] [users ...] [-help]
+
+                 msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+                      [-help]
+
+                 next [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+                 packf [+folder] [msgs] [-file name] [-help]
+
+                 pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+                      [-lbrace ... -rbrace] [--component pattern] [-after date]
+                      [-before date] [-datefield field] [-sequence name ...]
+                      [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+                      [-help]
+
+
+                 prev [+folder] [-header] [-noheader] [-showproc program]
+                      [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+                 prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+                      [-norapid] [-doteof] [-nodoteof] file [-help]
+
+                 /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+                      [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+                      [-help]
+
+
+
+
+
+                                             -163-
+
+
+
+
+
+
+
+
+
+
+
+
+                 refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+                      [-src +folder] [-file file] +folder ...  [-help]
+
+                 repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+                      [-nocc all/to/cc/me] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-editor editor]
+                      [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+                      [-inplace] [-noinplace] [-query] [-noquery]
+                      [-whatnowproc program] [-nowhatnowproc] [-width columns]
+                      [-help]
+
+                 rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+                 rmm [+folder] [msgs] [-help]
+
+                 scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+                      [-format string] [-header] [-noheader] [-width columns]
+                      [-reverse] [-noreverse] [-file filename] [-help]
+
+                 send [-alias aliasfile] [-draft] [-draftfolder +folder]
+                      [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+                      [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+                      [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+                 show [+folder] [msgs] [-draft] [-header] [-noheader]
+                      [-showproc program] [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
+                      [-help]
+
+                 sortm [+folder] [msgs] [-datefield field] [-textfield field]
+                      [-notextfield] [-limit days] [-nolimit] [-verbose]
+                      [-noverbose] [-help]
+
+                 vmh [-prompt string] [-vmhproc program] [-novmhproc]
+                      [switches for _v_m_h_p_r_o_c] [-help]
+
+                 whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+                 whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+                      [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+                      [file] [-help]
+
+                 /usr/local/lib/mh/ap [-form formatfile] [-format string]
+                      [-normalize] [-nonormalize] [-width columns] addrs ...
+                      [-help]
+
+                 /usr/local/lib/mh/conflict [-mail name] [-search directory]
+                      [aliasfiles ...] [-help]
+
+
+
+
+                                             -164-
+
+
+
+
+
+
+
+
+
+
+
+
+                 /usr/local/lib/mh/dp [-form formatfile] [-format string]
+                      [-width columns] dates ...  [-help]
+
+                 /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+                 /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+                      [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+                      [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+                      file [-help]
+
+                 /usr/local/lib/mh/slocal [address info sender] [-addr address]
+                      [-info data] [-sender sender] [-user username] [-mailbox mbox]
+                      [-file file] [-maildelivery deliveryfile] [-verbose]
+                      [-noverbose] [-debug] [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -165-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                Appendix B
+                                             _M_E_S_S_A_G_E _N_A_M_E _B_N_F
+
+
+
+
+
+                           msgs                  :=  msgspec                |
+                                                     msgs msgspec
+
+                           msgspec               :=  msg                    |
+                                                     msg-range              |
+                                                     msg-sequence           |
+                                                     user-defined-sequence
+
+                           msg                   :=  msg-name               |
+                                                     <number>
+
+                           msg-name              :=  "first"                |
+                                                     "last"                 |
+                                                     "cur"                  |
+                                                     "."                    |
+                                                     "next"                 |
+                                                     "prev"
+
+                           msg-range             :=  msg"-"msg              |
+                                                     "all"
+
+                           msg-sequence          :=  msg":"signed-number
+
+                           signed-number         :=  "+"<number>            |
+                                                     "-"<number>            |
+                                                     <number>
+
+                           user-defined-sequence :=  <alpha>                |
+                                                     <alpha><alphanumeric>*
+
+
+                 Where <number> is a decimal number greater than zero.
+
+                 Msg-range specifies all of the messages in the given range and must  not
+                 be empty.
+
+                 Msg-sequence specifies up to <number> of messages, beginning with  "msg"
+                 (in the case of first, cur, next, or <number>), or ending with "msg" (in
+                 the case of prev or last).  +<number> forces "starting  with  msg",  and
+                 -<number> forces "ending with number".  In all cases, "msg" must exist.
+
+                 User-defined sequences are defined and manipulated  with  the  _p_i_c_k  and
+                 _m_a_r_k commands.
+
+
+
+                                                  -166-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                _R_E_F_E_R_E_N_C_E_S
+
+
+
+                 1.  Crocker, D. H., J. J. Vittal, K. T. Pogran,  and  D.  A.  Henderson,
+                     Jr.,  "Standard  for  the  Format  of  ARPA  Network Text Messages,"
+                     _R_F_C_7_3_3, November 1977.
+
+                 2.  Thompson, K., and D. M. Ritchie,  "The  UNIX  Time-sharing  System,"
+                     _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+                 3.  McCauley, E. J., and P. J. Drongowski, "KSOS-The Design of a  Secure
+                     Operating  System,"  _A_F_I_P_S _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, National Computer
+                     Conference, Vol. 48, 1979, pp. 345-353.
+
+                 4.  Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d _F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l _M_e_s_-
+                     _s_a_g_e _S_y_s_t_e_m, The RAND Corporation, R-2134-ARPA, December 1977.
+
+                 5.  Thompson, K., and D. M. Ritchie, _U_N_I_X _P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th  ed.,
+                     Western  Electric  Company,  May 1975 (available only to UNIX licen-
+                     sees).
+
+                 6. Crocker, D. H., "Standard for the Format of ARPA Internet  Text  Mes-
+                     sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -167-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -i-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                _R_E_A_D _T_H_I_S
+
+
+
+
+                      Although the _M_H system was originally developed by  the  RAND  Cor-
+                 poration,  and is now in the public domain, the RAND Corporation assumes
+                 no responsibility for _M_H or this particular version of _M_H.
+
+                      In addition, the Regents of the University of California issue  the
+                 following disclaimer in regard to the UCI version of _M_H:
+
+                      "Although each program has been tested by its contributor, no  war-
+                      ranty,  express  or  implied,  is  made  by  the contributor or the
+                      University of California, as to the accuracy and functioning of the
+                      program and related program material, nor shall the fact of distri-
+                      bution constitute any  such  warranty,  and  no  responsibility  is
+                      assumed  by the contributor or the University of California in con-
+                      nection herewith."
+
+                      This version of _M_H is in the public domain, and as such, there  are
+                 no  real  restrictions on its use.  The _M_H source code and documentation
+                 have no licensing restrictions whatsoever.  As a courtesy,  the  authors
+                 ask only that you provide appropriate credit to the RAND Corporation and
+                 the University of California for having developed the software.
+
+                      _M_H is a software package that is supported neither by the RAND Cor-
+                 poration nor the University of California.  However, since we do use the
+                 software ourselves and plan to continue using (and  improving)  _M_H,  bug
+                 reports and their associated fixes should be reported back to us so that
+                 we may include them in future releases.  The  current  computer  mailbox
+                 for   _M_H   is   Bug-MH@ICS.UCI.EDU   (in   the   ARPA   Internet),   and
+                 ...!ucbvax!ucivax!bug-mh (UUCP).  Presently, there are two Internet dis-
+                 cussion   groups,   MH-Users@ICS.UCI.EDU   and   MH-Workers@ICS.UCI.EDU.
+                 MH-Workers is for people discussing code changes to _M_H.  MH-Users is for
+                 general  discussion  about  how to use _M_H.  MH-Users is bi-directionally
+                 gatewayed into USENET as comp.mail.mh.
+
+                 _H_O_W _T_O _G_E_T _M_H
+
+                      Since you probably already have _M_H, you may not need to  read  this
+                 unless  you  suspect you have an old version.  There are two ways to get
+                 the latest release:
+
+                      1.  If you can FTP to the  ARPA  Internet,  use  anonymous  FTP  to
+                 ics.uci.edu  [128.195.1.1]  and  retrieve  the file pub/mh/mh-6.8.tar.Z.
+                 This is a tar  image  after  being  run  through  the  compress  program
+                 (approximately  1.8MB).   There  should  also  be  a README file in that
+                 directory which tells what the current release of _M_H is, and how to  get
+                 updates.
+
+
+
+                                                   -i-
+
+
+
+
+
+
+
+
+
+                                                   -ii-
+
+
+                      This tar file is also available on louie.udel.edu [128.175.1.3]  in
+                 portal/mh-6.8.tar.Z.   You  may  also find MH on various other hosts; to
+                 make sure you get the latest version and don't waste your time re-fixing
+                 bugs, it's best to get it from either ics.uci.edu or louie.udel.edu.
+
+                      2.  You can send $75 US to the address below.  This covers the cost
+                 of  a  6250  BPI  9-track magtape, handling, and shipping.  In addition,
+                 you'll get a laser-printed hard-copy of the entire MH documentation set.
+                 Be  sure  to  include your USPS address with your check.  Checks must be
+                 drawn on U.S. funds and should be made payable to:
+
+                           Regents of the University of California
+
+                 The distribution address is:
+
+                           Computing Support Group
+                           Attn: MH distribution
+                           Department of Information and Computer Science
+                           University of California, Irvine
+                           Irvine, CA  92717
+
+                           714/856-7554
+
+                      If you just want the hard-copies of the  documentation,  you  still
+                 have  to  pay  the $75.  The tar image has the documentation source (the
+                 manual is in roff format, but the rest are in TeX  format).   Postscript
+                 formatted  versions  of  the TeX papers are available, as are crude tty-
+                 conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _F_O_R_E_W_O_R_D
+
+
+
+
+                      This document describes the RAND _M_H Message Handling  System.   Its
+                 primary  purpose  is  to  serve as a user's manual.  It has been heavily
+                 based on a previous version of the manual,  prepared  by  Bruce  Borden,
+                 Stockton Gaines, and Norman Shapiro.
+
+                      _M_H is a particularly novel system, and thus it is often more  prone
+                 to  change  than  other  pieces  of  production software.  As such, some
+                 specific points in this manual may not be correct in the future.  In all
+                 cases,  the  on-line  sections  of  this  manual,  available through the
+                 UNIX[1] _m_a_n command, should present the most current information.
+
+                      When reading this document as a user's manual, certain sections are
+                 more  interesting than others.  The Preface and Summary are not particu-
+                 larly interesting to those interested in learning _M_H.  The  Introduction
+                 is slightly more interesting, as it touches upon the organization of the
+                 remainder of this document.  The most useful sections are the  Overview,
+                 Tutorial,  and Detailed Description.  The Overview should be read by all
+                 _M_H users, regardless of their expertise (beginning, novice, advanced, or
+                 hacker).   The  Tutorial  should  be read by all beginning and novice _M_H
+                 users, as it presents a nice description of the _M_H system.  The Detailed
+                 Description  should  be  read by the day-to-day user of _M_H, as it spells
+                 out all of the realities of the _M_H system.  The Advanced  Features  sec-
+                 tion discusses some powerful _M_H capabilities for advanced users.  Appen-
+                 dix A is particularly useful for novices, as it summarizes  the  invoca-
+                 tion syntax of all the _M_H commands.
+
+                      There are also several other documents which may be useful to  you:
+                 _T_h_e  _R_A_N_D  _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is a tutorial for
+                 _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I _B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+                 describes  the  BBoards handling under _M_H; _M_H._5: _H_o_w _t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+                 _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l _g_e_t _s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which  was  presented  at
+                 the  1985  Summer  Usenix Conference and Exhibition in Portland, Oregon;
+                 _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r _A_g_e_n_t, which has been accepted  for  publication
+                 by  Computer  Networks;  _M_Z_n_e_t: _M_a_i_l _S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l _M_i_c_r_o-_C_o_m_p_u_t_e_r
+                 _S_y_s_t_e_m_s, which was presented at the  First  International  Symposium  on
+                 Computer  Message  Systems  in  Nottingham, U.K.; and, _D_e_s_i_g_n _o_f _t_h_e _T_T_I
+                 _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d _M_a_i_l _A_g_e_n_t, which describes  a  proprietary  "trusted"
+                 mail  system  built on _M_H.  There are also documents, mostly specific to
+                 U.C. Irvine which you may find interesting: _M_H _f_o_r _B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+                 _M_M _U_s_e_r_s.  All of these documents exist in the _m_h._6 distribution sent to
+                 your site.  There's also a document, _C_h_a_n_g_e_s _t_o _t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+                 _d_l_i_n_g  _S_y_s_t_e_m:  _M_H._6,  which  describes  user-visible changes made to _M_H
+                 since the last major release.
+
+
+                    [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+                                                  -iii-
+
+
+
+
+
+
+
+
+
+                                                   -iv-
+
+
+                      This manual is very large, as it describes a large, powerful system
+                 in gruesome detail.  The important thing to remember is:
+
+
+                                              _D_O_N'_T _P_A_N_I_C[_2]
+
+
+                 As explained in the tutorial, you really need to know only 5 commands to
+                 handle most of your mail.
+
+                      Very advanced users may wish to consult _T_h_e _R_A_N_D  _M_H  _M_e_s_s_a_g_e  _H_a_n_-
+                 _d_l_i_n_g  _S_y_s_t_e_m:  _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also present in the _m_h._6
+                 distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                             _A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+                      The _M_H system described herein is based on  the  original  RAND  _M_H
+                 system.   It  has  been  extensively  developed (perhaps too much so) by
+                 Marshall T. Rose and John L. Romine at  the  University  of  California,
+                 Irvine.  Einar A. Stefferud, Jerry N. Sweet, and Terry P. Domae provided
+                 numerous suggestions to improve the UCI version of  _M_H.   Of  course,  a
+                 large  number  of  people have helped _M_H along.  The list of ``_M_H immor-
+                 tals'' is too long to list here.  However, Van Jacobson deserves a  spe-
+                 cial  acknowledgement for his tireless work in improving the performance
+                 of _M_H.  Some programs have been speeded-up by a factor of 10 or 20.  All
+                 of  users  of  _M_H,  everywhere,  owe  a special thanks to Van.  For this
+                 release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes and other changes.  A handful
+                 of  courageous  _M_H-_W_o_r_k_e_r_s volunteered to beta-test these changes; their
+                 help is particularly appreciated.
+
+                      This manual is based on the original _M_H manual written at  RAND  by
+                 Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                   -v-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _P_R_E_F_A_C_E
+
+
+
+
+                      This report describes a system for dealing with messages  transmit-
+                 ted  on  a  computer.  Such messages might originate with other users of
+                 the same computer or might come from an outside source through a network
+                 to  which the user's computer is connected.  Such computer-based message
+                 systems are becoming increasingly widely used, both within  and  outside
+                 the Department of Defense.
+
+                      The message handling system _M_H was developed for two reasons.   One
+                 was  to  investigate some research ideas concerning how a message system
+                 might take advantage  of  the  architecture  of  the  UNIX  time-sharing
+                 operating  system  for Digital Equipment Corporation PDP-11 and VAX com-
+                 puters, and the special features of UNIX's command-level interface  with
+                 the  user  (the  "shell").  The other reason was to provide a better and
+                 more adaptable base than that of conventional designs on which to  build
+                 a  command and control message system.  The effort has succeeded in both
+                 regards, although this report mainly describes the message system itself
+                 and how it fits in with UNIX.
+
+                      The present report  should  be  of  interest  to  three  groups  of
+                 readers.   First, it is a complete reference manual for the users of _M_H.
+                 Second, it should be of interest to those who have a  general  knowledge
+                 of  computer-based message systems, both in civilian and military appli-
+                 cations.  Finally, it should be of interest to  those  who  build  large
+                 subsystems  that  interface  with  users,  since  it  illustrates  a new
+                 approach to such interfaces.
+
+                      The original _M_H system was developed  by  Bruce  Borden,  using  an
+                 approach  suggested  by  Stockton  Gaines  and Norman Shapiro.  Valuable
+                 assistance was provided by Phyllis Kantar in the  later  stages  of  the
+                 system's  implementation.   Several  colleagues contributed to the ideas
+                 included in this system, particularly Robert Anderson and David Crocker.
+                 In  addition,  valuable  experience  in  message systems, and a valuable
+                 source of ideas, was available to us in the form of a  previous  message
+                 system for UNIX called MS, designed at RAND by David Crocker.
+
+                      This report was originally prepared as part  of  the  RAND  project
+                 entitled "Data Automation Research", sponsored by Project AIR FORCE.
+
+
+
+
+
+
+
+
+
+
+
+                                                   -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _S_U_M_M_A_R_Y
+
+
+
+
+                      Electronic communication of text messages is becoming  commonplace.
+                 Computer-based  message systems-software packages that provide tools for
+                 dealing with messages-are used in many contexts.  In particular, message
+                 systems  are  becoming increasingly important in command and control and
+                 intelligence applications.
+
+                      This report describes a message handling system  called  _M_H.   This
+                 system  provides  the  user with tools to compose, send, receive, store,
+                 retrieve, forward, and reply to messages.  _M_H has been built on the UNIX
+                 time-sharing  system,  a  popular operating system developed for the DEC
+                 PDP-11 and VAX classes of computers.
+
+                      A complete description of _M_H is given for users of the system.  For
+                 those who do not intend to use the system, this description gives a gen-
+                 eral idea of what a message system is like.  The  system  involves  some
+                 new ideas about how large subsystems can be constructed.
+
+                      The interesting and unusual features of _M_H include  the  following:
+                 The  user command interface to _M_H is the UNIX "shell" (the standard UNIX
+                 command interpreter).  Each separable  component  of  message  handling,
+                 such  as  message composition or message display, is a separate command.
+                 Each program is driven from and  updates  a  private  user  environment,
+                 which  is  stored  as  a file between program invocations.  This private
+                 environment also contains information  to  "custom  tailor"  _M_H  to  the
+                 individual's  tastes.   _M_H  stores each message as a separate file under
+                 UNIX, and it utilizes the tree-structured UNIX file system  to  organize
+                 groups  of  files  within separate directories or "folders".  All of the
+                 UNIX facilities for dealing with files and directories, such  as  renam-
+                 ing,  copying, deleting, cataloging, off-line printing, etc., are appli-
+                 cable to messages and directories of messages (folders).   Thus,  impor-
+                 tant capabilities needed in a message system are available in _M_H without
+                 the need (often seen in other message systems) for code that  duplicates
+                 the facilities of the supporting operating system.  It also allows users
+                 familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                  -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+                                                 _C_O_N_T_E_N_T_S
+
+
+
+
+                 READ THIS .........................................................    i
+
+                 FOREWORD ..........................................................  iii
+
+                 ACKNOWLEDGMENTS ...................................................    v
+
+                 PREFACE ...........................................................   vi
+
+                 SUMMARY ...........................................................  vii
+
+                 Section
+
+                    1.  INTRODUCTION ...............................................    1
+
+                    2.  OVERVIEW ...................................................    4
+
+                    3.  TUTORIAL ...................................................    7
+
+                    4.  DETAILED DESCRIPTION .......................................   10
+                      THE USER PROFILE .............................................   10
+                      MESSAGE NAMING ...............................................   13
+                      OTHER MH CONVENTIONS .........................................   14
+                      MH COMMANDS ..................................................   16
+                         ALI .......................................................   17
+                         ANNO ......................................................   19
+                         BBC .......................................................   21
+                         BBOARDS ...................................................   24
+                         BURST .....................................................   26
+                         COMP ......................................................   28
+                         DIST ......................................................   30
+                         FOLDER ....................................................   33
+                         FORW ......................................................   37
+                         INC .......................................................   41
+                         MARK ......................................................   44
+                         MHL .......................................................   46
+                         MHMAIL ....................................................   51
+                         MHOOK .....................................................   53
+                         MHPARAM ...................................................   55
+                         MHPATH ....................................................   57
+                         MSGCHK ....................................................   60
+                         MSH .......................................................   61
+                         NEXT ......................................................   65
+                         PACKF .....................................................   66
+                         PICK ......................................................   67
+                         PREV ......................................................   72
+                         PROMPTER ..................................................   73
+                         RCVSTORE ..................................................   76
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                         REFILE ....................................................   78
+                         REPL ......................................................   80
+                         RMF .......................................................   84
+                         RMM .......................................................   86
+                         SCAN ......................................................   88
+                         SEND ......................................................   91
+                         SHOW ......................................................   94
+                         SLOCAL ....................................................   97
+                         SORTM .....................................................  102
+                         VMH .......................................................  104
+                         WHATNOW ...................................................  106
+                         WHOM ......................................................  108
+                      MORE DETAILS .................................................  110
+                         MH-ALIAS ..................................................  111
+                         MH-FORMAT .................................................  115
+                         MH-MAIL ...................................................  124
+                         MH-PROFILE ................................................  128
+                         MH-SEQUENCE ...............................................  136
+                         AP ........................................................  140
+                         CONFLICT ..................................................  142
+                         DP ........................................................  144
+                         FMTDUMP ...................................................  146
+                         INSTALL-MH ................................................  147
+                         POST ......................................................  148
+
+                    5.  REPORTING PROBLEMS .........................................  150
+
+                    6.  ADVANCED FEATURES ..........................................  151
+                      USER-DEFINED SEQUENCES .......................................  151
+                         Pick and User-Defined Sequences ...........................  151
+                         Mark and User-Defined Sequences ...........................  153
+                         Public and Private User-Defined Sequences .................  153
+                         Sequence Negation .........................................  153
+                         The Previous Sequence .....................................  154
+                         The Unseen Sequence .......................................  154
+                      COMPOSITION OF MAIL ..........................................  155
+                         The Draft Folder ..........................................  155
+                         What Happens if the Draft Exists ..........................  157
+                         The Push Option at What now? Level ........................  157
+                         Options at What now? Level ................................  158
+                         Digests ...................................................  159
+                      FOLDER HANDLING ..............................................  160
+                         Relative Folder Addressing ................................  160
+                         The Folder-Stack ..........................................  161
+
+                 Appendix
+                    A.  Command Summary ............................................  162
+                    B.  Message Name BNF ...........................................  166
+
+                 REFERENCES ........................................................  167
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                         THE RAND MH
+
+
+                                      MESSAGE HANDLING
+
+
+                                           SYSTEM:
+
+
+                                        USER'S MANUAL
+
+
+
+
+
+
+                                         UCI Version
+
+
+
+
+
+                                      Marshall T. Rose
+
+                                       John L. Romine
+
+
+
+
+                               Based on the original manual by
+
+                                 Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+                                      November 30, 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                        6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/README b/docs/historical/README
new file mode 100644
index 0000000..5fdb663
--- /dev/null
+++ b/docs/historical/README
@@ -0,0 +1,108 @@
+The most recent versions of the documents in this directory were
+downloaded from ftp://ftp.vim.org/pub/mail/mh/doc/
+
+These older versions:
+  ADMIN-19910201.txt
+  MH-19910201.txt
+  MH-19921214.pdf
+  MH-19921214.txt
+were downloaded from ftp://munnari.oz.au/pub/mh/doc/
+
+designOfMH.pdf was downloaded from
+http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA257836
+
+The README below is retained in its original form for posterity.  All
+of the txt (.doc and .tty) files have been renamed to .txt.  All of
+the postscript (.ps) files have been converted to pdf using ps2pdf.
+
+D. Levine  28 Feb 2012
+
+------------------------------------------------------------------------
+------------------------------------------------------------------------
+
+mh/doc/README
+
+These are formatted versions of the major MH documents (written
+using the troff "-ms" and "-me" macro packages).  The ".doc" files
+are formatted for 66 lines/page:
+
+  ADMIN.doc	- The MH Administrator's Manual - how to configure MH
+  MH.doc	- The MH User's Manual
+  changes.doc	- Changes from MH 6.6 to MH 6.8
+  mh-gen.doc	- The "READ-ME" file - how to generate MH (aka mh-gen(8))
+
+Postscript versions are also available:
+
+  ADMIN.ps	- The MH Administrator's Manual - how to configure MH
+  MH.ps		- The MH User's Manual
+  changes.ps	- Changes from MH 6.6 to MH 6.8
+  mh-gen.ps	- The "READ-ME" file - how to generate MH (aka mh-gen(8))
+
+------------------------------------------------------------------------
+
+These are postscript conversions of the MH papers which were written
+using the TeX typesetting language:
+
+  bboards.ps		- The UCI BBoards Facility
+  beginners.ps		- UCI MH for Beginners
+  mh4mm.ps		- MH for MM users
+  mh6.ps		- Changes from MH 6.0 to MH 6.5 for 4.3BSD
+  multifarious.ps	- MH: A Multifarious User Agen
+  mznet.ps		- MZnet - Mail Service for Personal Micro Comp. Sys.
+  realwork.ps		- MH.5 - How to process 200 messages...
+  trusted.ps		- Design of the TTI Prototype Trusted Mail Agent
+  tutorial.ps		- The MH Tutorial
+
+These conversions have been provided because they may be of use to some
+sites who retrieved MH using FTP, and who do not have TeX to typeset
+the papers themselves.  Of course, all recipients of an MH distribution
+tape receive a complete set of laser-printed manuals.
+
+These conversions were generated with the "dvips" program.  I have
+printed them on an Imagen 5320 w/ Turboscript, and the output is
+identical to the original "dvi" versions of these papers.
+
+As yet, I have had no success downloading the postscript files to a Mac-
+intosh, and printing them on a Laserwriter.  If you are able to generate
+copies of these papers which will print (identically to the originals or
+otherwise) on a Laserwriter, please contact "Bug-MH@ICS.UCI.EDU".
+
+------------------------------------------------------------------------
+
+These files are tty-readable conversions of the MH papers which were
+written using the TeX typesetting language:
+
+  bboards.tty		- The UCI BBoards Facility
+  beginners.tty		- UCI MH for Beginners
+  mh4mm.tty		- MH for MM users
+  mh6.tty		- Changes from MH 6.0 to MH 6.5 for 4.3BSD
+  multifarious.tty	- MH: A Multifarious User Agen
+  mznet.tty		- MZnet - Mail Service for Personal Micro Comp. Sys.
+  realwork.tty		- MH.5 - How to process 200 messages...
+  trusted.tty		- Design of the TTI Prototype Trusted Mail Agent
+  tutorial.tty		- The MH Tutorial
+
+These conversions have been provided because they may be of use to some
+sites who retrieved MH using FTP, and who do not have TeX or a laser
+printer on which to print the papers.  If you have a Postscript
+printer, you may want to retrieve the Postscript conversion of these
+papers, available in a different tar archive.
+
+Of course, all recipients of an MH distribution tape receive a complete
+set of laser-printed manuals, and these conversions are not a
+substitute for properly-formatted copies of the originals.
+
+The conversion was generated by the "dvi2tty" program.  As full use of
+TeX's rich typesetting environment was used in writing many of these
+papers, and since the output is intended for a line printer, it is
+necessarily quite primitive.
+
+Font changes and special character representations are lost entirely.
+White-space between words may be deleted or expanded, especially near
+punctuation characters.  Blank lines may be added or deleted.
+
+Since typeset lines are typically longer than 80 tty characters, the
+output has been generated for 132-colunm output devices.  A typical
+page has about 76 lines.  Pages are separated by a formfeed character.
+
+/JLR
diff --git a/docs/historical/bboards.pdf b/docs/historical/bboards.pdf
new file mode 100644
index 0000000..6e7d2cf
Binary files /dev/null and b/docs/historical/bboards.pdf differ
diff --git a/docs/historical/bboards.txt b/docs/historical/bboards.txt
new file mode 100644
index 0000000..ace0d08
--- /dev/null
+++ b/docs/historical/bboards.txt
@@ -0,0 +1,965 @@
+
+
+
+
+                     The  Rand  MH  Message  Handling  System:
+
+
+
+                                   The  UCI  BBoards  Facility
+
+
+                                           Marshall T. Rosey
+
+                                  Wed May 21 21:03:57 PDT 1986
+
+
+
+                                                Abstract
+
+
+               This document discusses how to process BBoards using the
+
+               Rand MH system.  In particular, this guide discusses:  check-
+
+               ing  the  status  of  a  BBoard,  viewing  new  messages,  archive
+
+               handling, composing mail destined for a BBoard, and reply-
+
+               ing to a message posted to a BBoard.
+
+
+                      Although this document is based on the standard MH
+
+               user manual[MH], this document is meant to supplement, not
+
+               supersede, that lengthier work.
+
+
+                      Comments concerning this documentation should be ad-
+
+               dressed to the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+_____________________________________
+y Computer Mail: MRose@NRTC.NORTHROP.COM.
+
+
+                     The  Rand  MH  Message  Handling  System:
+
+
+
+                                   The  UCI  BBoards  Facility
+
+
+
+Acknowledgements
+
+        The MH system described herein is based on the original Rand MH system.
+
+It has been extensively developed (perhaps too much so) by Marshall Rose and
+
+John Romine at the University of California, Irvine.  Einar Stefferud, Jerry Sweet,
+
+and Terry Domae provided numerous suggestions to improve the UCI version of
+
+MH.
+
+
+        In  particular,  the  UCI  BBoards  facility,  which  was  suggested  by  Einar
+
+Stefferud, has been in place at the University of California, Irvine (in one form or
+
+another) for the last two and one-half years.  The UCI BBoards facilities runs under
+
+both MMDF and SendMail, and, in a more restricted form, under stand-alone MH.
+
+
+
+Disclaimer
+
+        The Regents of the University of California wish to make it known that:
+
+
+
+       "Although each program has been tested by its contributor, no warranty, express or
+        implied, is made by the contributor or the University of California, as to the accuracy
+        and functioning of the program and related program material, nor shall the fact of
+        distribution constitute any such warranty, and no responsibility is assumed by the
+        contributor or the University of California in connection herewith."
+
+
+
+Scope
+
+        This  document  explains  how  to  use  the  UCI  BBoards  facility  to  a  user
+
+familiar with MH and the UNIX1  operating system in general.  A large degree of
+
+expertise is not assumed.  This document does not attempt to introduce MH to the
+
+novice user (for that task, consult the MH tutorial known as [MH.TUT]). Additional
+
+information on the programs discussed here (particularly bbc) is to be found in
+
+[MH].
+
+
+
+_____________________________________
+1  UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+                                                       1
+                                                                                                              2
+
+
+Conventions
+
+        In this document, certain TEX-formatting conventions are adhered to:
+
+
+           1.  The  names  of  UNIX  commands,  such  as  comp,  are  presented  in  text
+
+               italics.
+
+
+           2.  Arguments to programs, such as `msgs'    , are presented in typewriter
+
+               style and delimited by single-quotes.
+
+
+           3.  UNIX pathnames and envariables, such as /usr/uci/     and $ SIGNATURE         ,
+
+               are presented in slanted roman.
+
+
+           4.  Text presenting an example, such as
+
+
+                   comp -editor zz
+
+
+               is presented in typewriter  style.
+
+
+
+Introduction
+
+        MH is a very powerful message handling system that runs under the UNIX
+
+operating system.  One of the many features which MH offers is an interface to
+
+the UCI BBoards facility.  This facility permits the efficient distribution of interest
+
+group messages on a single host, a group of hosts under a single administration,
+
+and the ARPA Internet community.
+
+
+        Described simply, a interest group is composed of a number of subscribers
+
+with a common interest.  These subscribers post mail to a single address, known
+
+as a distribution address.  From this distribution address, a copy of the message
+
+is sent to each subscriber.  Each group has a moderator, which is the person that
+
+runs the the group.  This moderator can usually be reached at a special address,
+
+known as a request address.  Usually, the responsibilities of the moderator are quite
+
+simple, since the mail system handles the distribution to subscribers automatically.
+
+In  some  cases,  the  interest  group,  instead  of  being  distributed  directly  to  its
+
+subscribers,  is put into a digest format by the moderator and then sent to the
+
+subscribers.  Although this requires more work on the part of the moderator, such
+
+groups tend to be better organized.
+
+
+        Unfortunately,  there  are  a  few  problems  with  the  scheme  outlined  above.
+
+First, if two users on the same host subscribe to the same interest group, two copies
+
+of the message get delivered.  This is wasteful of both processor and disk resources.
+
+
+        Second,  some of these groups carry a lot of traffic.  Although subscription
+
+to an group does indicate interest on the part of a subscriber,  it is usually not
+
+interesting to get 50 messages or so delivered to the user's private maildrop each
+
+day, interspersed with personal mail, that is likely to be of a much more important
+
+and timely nature.
+                                                                                                              3
+
+
+        Third,  if  a  subscriber  on  the  distribution  list  for  a  group  becomes  "bad"
+
+somehow,  the originator of the message and not the moderator of the group is
+
+notified.  It  is  not  uncommon  for  a  large  list  to  have  10  or  so  bogus  addresses
+
+present.  This results in the originator being flooded with "error messages" from
+
+mailers across the ARPA Internet stating that a given address on the list was bad.
+
+Needless to say, the originator usually could not care less if the bogus addresses
+
+got a copy of the message or not.  The originator is merely interested in posting a
+
+message to the group at large.  Furthermore, the moderator of the group does care
+
+if there are bogus addresses on the list, but ironically does not receive notification.
+
+
+        To solve all of these problems, the UCI BBoards facility introduces a new
+
+entity into the picture:  all interest group mail is handled by a special component of
+
+the mail system.  The distribution address maps to a special channel that performs
+
+several  actions.  First,  if  local  delivery  is  to  be  performed,  then  a  copy  of  the
+
+message is placed in a global maildrop for the interest group with a timestamp
+
+and a unique number.  Local users can read messages posted for the interest group
+
+by  reading  the  file.   Second,  if  further  distribution  is  to  take  place,  a  copy  of
+
+the message is sent to the distribution address in such a way that if any of the
+
+addresses are bogus, the failure notice is sent to the maintainer of the group and
+
+not the originator.
+
+
+        This scheme has several advantages:  First,  messages delivered to the host
+
+are  processed  and  saved  once  in  a  globally  accessible  area.  The  UCI  BBoards
+
+facility  supports  software  which  allows  a  user  to  query  the  interest  group  for
+
+new messages and to read those messages in the MH-style.  Second, once a host
+
+subscribes to an interest group, a user can add or remove him/herself from the list
+
+without contacting the moderator.  Third, a hierarchical distribution scheme can
+
+be constructed to further reduce the amount of message traffic.  Fourth, errors are
+
+prevented from propagating.  When an address on the distribution list goes bad,
+
+the request address immediately responsible for the address is notified.  Usually,
+
+this is the local PostMaster and not the group moderator.
+
+
+        In addition to solving the problems outlined above, the UCI BBoards facility
+
+supports several other capabilities.  BBoards may be automatically archived in
+
+order to conserve disk space and reduce processing time when reading them.
+
+
+        Special  alias  files  may  be  generated  which  allow  the  MH  user  to  shorten
+
+address  type-in.  For  example,  instead  of  sending  to  ``SF-Lovers@Rutgers''            ,
+
+a  user  of  MH  usually  sends  to  ``SF-Lovers''         and  the  MH  aliasing  facility
+
+automatically  makes  the  appropriate  expansion  in  the  headers  of  the  outgoing
+
+message.  Hence,  one need only know the name of a interest group and not its
+
+address.
+                                                                                                              4
+
+
+        Finally, the UCI BBoards facility supports private interest groups using the
+
+UNIX  group  access  mechanism.  This  allows  a  group  of  people  on  the  same  or
+
+different machines to conduct a private discussion.
+
+
+        The practical upshot of all this is that the UCI BBoards facility automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+
+BBoard Handling
+
+        Usually the term BBoard is used interchangeably with the terms discussion
+
+group and interest group.  This is true of the discussion that follows.
+
+
+        The messages for a BBoard delivered locally are kept in the same format as a
+
+maildrop.2  Unlike the user's private maildrop however, the inc program is not run
+
+to incorporate new BBoard messages into the user's MH ``+inbox''        folder.  The
+
+programs which are used will be discussed momentarily.
+
+
+        Each message in a BBoard maildrop has a unique number and a timestamp.
+
+The  number,  called  the  BBoard-ID,  is  always  ascending.  The  BBoard-ID  of  a
+
+message should NOT be confused with the message number of a message, which
+
+can change as messages are removed from the BBoard.  The BBoard-ID is a value
+
+which is unique for every message delivered locally to the BBoard.
+
+
+        To read BBoards,  the MH user invokes bbc.  The bbc program has several
+
+switches to direct it's action.  The `-topics'       switch to bbc tells the MH user about
+
+the status of a BBoard.  The `-check'      switch to bbc lets the MH user check on the
+
+activity of a BBoard.  The `-read'      switch to bbc invokes the msh program on the
+
+BBoard.  msh is a monolithic program which contains most of the functionality of
+
+MH in a single program.  These commands are now discussed in greater detail.
+
+
+BBoard status
+
+        The `-topics'       option to the bbc program can be used to report information
+
+about a BBoard that does not pertain to the user's reading habits.  If the MH users
+
+types
+
+
+           bbc -topics
+
+
+then bbc will list the following information for all BBoards received on the host:
+
+
+            -  the official name of the BBoard
+
+
+            -  the number of messages delivered to the BBoard (but not necessarily
+
+               present)
+
+
+_____________________________________
+2  Actually, your site might be running with all BBoards kept on a single host.  MH supports the
+
+remote access of BBoards using a modified version of the ARPA Post Office Protocol (POP). This
+has the advantage that it saves a lot of disk space, and incurs only a modest performance penalty.
+                                                                                                              5
+
+
+            -  the date and time of the last message delivered to the BBoard
+
+
+
+In addition to `-topics'      ,  if the `-verbose'        option is given to bbc,  then more
+
+information is listed:
+
+
+            -  any aliases the BBoard is known as
+
+
+            -  the local leaders of the BBoard
+
+
+            -  the file that the BBoard is locally delivered to
+
+
+            -  the "global" distribution address
+
+
+            -  the "global" request address
+
+
+            -  the host that distributes the BBoard to the local host
+
+
+            -  the addresses to which this host distributes
+
+
+            -  miscellaneous information (presently only archiving status)
+
+
+
+Naturally, bbc can be invoked with the `-topics'       option and one or more BBoard
+
+names listed on its command line.  For example
+
+
+           bbc -topics unix-wizards
+
+
+is  completely  acceptable  _  it  tells  bbc  to  report  the  status  of  the  BBoard
+
+``unix-wizards''          .
+
+
+BBoard checking
+
+        The `-check'      option to the bbc program can be used to check for new BBoard
+
+messages in a synchronous fashion (i.e., when you specifically ask for it).  The MH
+
+users types
+
+
+           bbc -check
+
+
+and bbc consults the profile entry for ``bboards:''         in the user's .mh_profile     file.
+
+For each BBoard listed, bbc prints one of several messages depending on the status
+
+of both the BBoard and the user's reading habits (for example, in the case of the
+
+mythical BBoard ``foo''     ):
+
+
+           1.  ``foo  --  n  items  unseen''
+
+               This message indicates items in the BBoard have not been seen by the
+
+               user.  When bbc is invoked with the ``quiet''       switch, this is the only
+
+               informative message that bbc will print out.  Users of MH usually put
+
+
+                   bbc -check -quiet
+
+
+               in their $ HOME/.login        file.
+                                                                                                              6
+
+
+           2.  ``foo  --  empty''
+
+               The BBoard is empty.
+
+
+           3.  ``foo  --  n  items  (none  seen)''
+
+               The BBoard has n items in it, but the user hasn't seen any.
+
+
+           4.  ``foo  --  n  items  (all  seen)''
+
+               The BBoard is non-empty, and the user has seen everything in it.
+
+
+           5.  ``foo  --  n  items  seen  out  of  m''
+
+               The BBoard has at most m  n items that the user has not seen.
+
+
+
+It is important to note that bbc performs its calculations on BBoard-ID:s and not
+
+the messages actually present in a BBoard.  This means that the numbers given by
+
+bbc are maximal end-points.  When bbc says n, bbc means "at most n".
+
+
+        Naturally,  bbc can be invoked with the `-check'       option and one or more
+
+BBoards listed on its command line.  For example
+
+
+           bbc -check info-c poli-sci
+
+
+is completely acceptable _ it tells bbc to check on the BBoards ``info-c''        and
+
+``poli-sci''         only.
+
+
+        There are two ways to check for new BBoard messages in an asynchronous
+
+fashion:  using the CShell variable $ mail   and running the useto program.
+
+
+Asynchronous Checking with the CShell
+
+        The CShell has a variable called $ mail  .  This variable can contain one or more
+
+words.  Each word should be a filename where the shell should check for new mail.
+
+The check is performed after a specified time interval has elapsed just before the
+
+shell would prompt the user.
+
+
+        If the first word of $ mail   is a number, then this number specifies a different
+
+checking interval, in seconds, than the default, which is 10 minutes.
+
+
+        Whenever the time interval elapses and the shell is ready to prompt the user,
+
+the shell looks at the file and decides if new messages have arrived.  If so, it says
+
+
+           You  have  new  mail.
+
+
+if only one file is present in $ mail  .  Otherwise, if more than one file is present in
+
+$ mail  , then the shell says
+
+
+           New  mail  in  foo.
+
+
+whenever there is new mail in the file called ``foo''     .
+                                                                                                              7
+
+
+        To find out what file is associated with a BBoard, say ``info-unix''        , the
+
+MH user types
+
+
+           bbc -topics -verbose info-unix
+
+
+Usually the local file for a BBoard has an extension of .mbox   .
+
+
+Asynchronous Checking with Useto
+
+        In  contrast  to  using  the  $mail   variable  in  the  CShell,  the  MH  user  might
+
+employ useto instead.3   The useto program is a continuous update display that
+
+prints  information  on  the  status  line  of  your  terminal.   Needless  to  say,  your
+
+terminal must support a status line in order to run useto.  Not all terminals have
+
+this capability, but for those that do it's usually well worth the effort to run useto.
+
+
+        For example, users of MH could put
+
+
+           useto -bepf tcp-ip sftp % D % M % d % h:% m% z% b % n.tty% t:% l1
+
+
+in their $ HOME/.login        file.  This command line to useto says to inform the user of
+
+
+            -  the current date and time
+
+
+            -  new mail for the user
+
+
+            -  new messages for the BBoards ``tcp-ip''       and ``sftp''
+
+
+            -  the name of the host and tty that the user is logged in on
+
+
+            -  the 5-minute load average of that host
+
+
+        The useto program is really quite amusing and useful.4
+
+
+BBoard reading
+
+        If bbc is not given either the `-check'      or `-topics'       option, the bbc program
+
+reads BBoard messages.  For each BBoard listed in the MH user's profile entry for
+
+``bboards:''        , bbc checks to see if there is unread mail.  If so, bbc starts msh on
+
+the BBoard, telling msh which messages haven't been seen.5
+
+
+        When msh starts it identifies the BBoard being read and indicates how many
+
+messages are present and how many the user has read.  Usually, in the user's MH
+
+profile, the user has the entry
+
+
+           msh: -scan
+
+
+
+_____________________________________
+3  Not all sites have useto; contact the same people who supplied MH to get a copy.
+4  To  be  honest,  the  author  considers  computing  environments  without  useto  to  be  less  than
+
+adequate.
+5  If the `-verbose'     option is given to bbc, then bbc will start msh on the BBoard regardless of
+
+whether there are unseen messages there.
+                                                                                                                         8
+
+
+           This says that when msh starts, it should print a scan listing of the messages which
+
+           the user hasn't seen yet.
+
+
+                   The msh program now prompts the user for MH commands.  The user may
+
+           type most of the normal MH command.  The syntax and semantics of the commands
+
+           typed to msh are identical to their MH counterparts.  For example,  to reply to
+
+           a  message  on  the  BBoard,  the  MH  user  types  ``repl''    ;  other  MH  commands
+
+           likewise may be applied to BBoard messages.  In cases where the nature of msh
+
+           would be inconsistent (e.g., specifying a `+folder'       with some commands), msh
+
+           will duly inform the user.  In addition to supporting most MH commands, msh also
+
+           has a ``help''      command which gives a brief overview.
+
+
+                   The only command that behaves entirely differently in msh is the ``mark''
+
+           command  when  given  no  arguments.   The  msh  program  maintains  a  special
+
+           sequence, ``unseen''      , which it uses to keep track of the messages you've seen.  If
+
+           the ``mark''      command is given without any arguments, then msh will interpret it
+
+           as
+
+
+                      mark -sequence unseen -delete -nozero all
+
+
+           Hence, to discard all of the messages in the current BBoard being read, the MH
+
+           user  types  ``mark''      which  says  to  remove  all  messages  from  sequence  called
+
+           ``unseen''       .
+
+
+                   To leave msh use the ``quit''      command.  This tells msh to terminate and
+
+           bbc to go to the next BBoard.  Instead, if the user types EOT (usually CTRL-D),
+
+           then bbc will exit as well, updating whatever information was appropriate.
+
+
+
+           Current BBoards
+
+                   There are many,  many active interest groups.  Consult the BBoard called
+
+           ``list-of-lists''            for a comprehensive description.  Here are a few of the more
+
+           popular:
+
+
+               system     Important announcements for the local system are posted here.
+
+
+            mh-users      A discussion group for users of MH.
+
+
+arpanet-bboards           Redistribution address for all known BBoards on the ARPAnet.
+
+
+   editor-people          Discussion  of  topics  related  to  computerized  text  editing,  display
+
+                          editors, and human factors in man/machine interaction.  The theoretical
+
+                          discussion is catholic, but practical discussion focuses particularly on
+
+                          Tops206  and UNIX.
+
+
+   franz-friends          Discusses the Franz Lisp language.
+
+
+           _____________________________________
+           6  Tops20 is a trademark of Digital Equipment Corporation.
+                                                                                                                      9
+
+
+header-people          Interest specifically in the format of message headers and related issues
+
+                       such as inter-network mail formats/standards, etc.
+
+
+     human-nets        Human-Nets  has  discussed  many  topics,  all  of  them  related  in  some
+
+                       way to the theme of a world-wide computer and telecommunications
+
+                       network usually called WorldNet.  The topics have ranged very widely,
+
+                       from something like tutorials, to state of the art discussions, to rampant
+
+                       speculation about technology and its impact.
+
+
+     info-micro        Information/discussion list on the general interest topic of microcom-
+
+                       puters.
+
+
+       info-unix       Info-UNIX is intended for question/answer discussion, where "novice"
+
+                       system administrators can pose questions.
+
+
+         msggroup      Interest in electronic mail, message formats, message systems, and the
+
+                       sociological implications of the above.
+
+
+         poli-sci      A permanent distributed political "bull" session.
+
+
+       sf-lovers       Science Fiction lovers.  SF-Lovers has discussed many topics, all of them
+
+                       related in some way to the theme of science fiction or fantasy.
+
+
+             space     Discussions (daily digest) on space-related topics.
+
+
+          telecom      A broad spectrum moderated-digest-format discussion on telecommu-
+
+                       nictions technology:  the telephone system,  modems,  and other more
+
+                       technical aspects of telecommunications systems.
+
+
+     unix-emacs        Used for new release announcements and general discussions of Gosling's
+
+                       EMACS.
+
+
+  unix-wizards         Distribution  list  for  people  maintaining  machines  running  the  UNIX
+
+                       operating system.
+
+
+
+        As  discussed  earlier,  to  find  out  about  all  of  the  BBoards  that  the  local  host
+
+        subscribes to, the MH users types
+
+
+                   bbc -topics
+
+
+
+        More on BBoards
+
+                Finally, here are a few more operational details:
+
+
+        Creating a BBoard
+
+                Contact the PostMaster at your host to have a BBoard created.  Be sure to
+
+        indicate its status (public or private) and scope (where distribution should occur).
+                                                                                                                          10
+
+
+              Subscribing to a BBoard
+
+                      If your local host already receives an interest group,  then simply add the
+
+              name of the BBoard to the ``bboards:''        entry in your MH profile.  If not, ask the
+
+              PostMaster to create the BBoard and contact the global request address for you.
+
+
+              BBoard Archives
+
+                      BBoard messages are automatically archived on a weekly basis.  Usually, this
+
+              results in messages older than 12 days being moved to an archive area.  To read
+
+              the archives for a BBoard, the `-archive'       option is used.  For example,
+
+
+                         bbc -archive telecom
+
+
+              tells bbc to invoke msh on the archives for the ``telecom''        BBoard.
+
+
+                      Note that the archives may not be present for all BBoards on a given host;
+
+              also note that the archives may be periodically moved to tape and expunged from
+
+              the system.  Contact your local PostMaster for the details.
+
+
+              BBoard Addresses
+
+                      Each BBoard has associated with it 4 addresses (for example, in the case of
+
+              the mythical BBoard ``foo''     ):
+
+
+                       foo   The global distribution list
+
+                             If you post a message addressed to foo then the message is distributed
+
+                             to everyone who subscribes to ``foo''     .
+
+
+               dist-foo      The local distribution list
+
+                             If  you  post  a  message  addressed  to  dist-foo  then  the  message  is
+
+                             distributed to the local BBoard for ``foo''      and to any sites which the
+
+                             local system distributes to.
+
+
+         foo-request         The global moderator
+
+                             If you post a message addressed to foo-request then the message is
+
+                             sent to the moderator for the entire interest group called ``foo''     .
+
+
+local-foo-request            The local moderator
+
+                             If  you  post  a  message  addressed  to  local-foo-request  then  the
+
+                             message is sent to the person responsible for the BBoard ``foo''      on
+
+                             the local system.
+
+
+
+              These addresses are defined by the MH alias facility.  Users of the BBoards facility
+
+              who do not use MH may not be able to make use of them.
+
+
+              Leading a BBoard
+
+                      Except for special circumstances, this task is wholly automated.  For more
+
+              information though, see the manual entries for bbl (1) and bbleaders (8).
+                                                                                                            11
+
+
+Extra for Experts
+
+        Some clever MH users might ask why BBoards aren't kept as folders instead
+
+of pack'd files.  This is a good question.  Perhaps some future release of MH and the
+
+UCI BBoards facility will treat BBoards as a variant of read-only folders.
+
+
+        The  problem  with  msh,  of  course,  is  that  it's  a  monolithic  program,  and
+
+although  it  does  support  input/output  redirection  and  a  few  other  primitive
+
+shell-like properties, it's still not the CShell.
+                                                                                                            12
+
+
+                                               References
+
+
+
+[MH]           M.T. Rose,  J.L. Romine.  The Rand MH Message Handling System:
+
+               User's Manual. UCI Version. Department of Information and Computer
+
+               Science, University of California, Irvine (July, 1984).
+
+
+
+[MH.TUT]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  Tutorial.
+
+               Department  of  Computer  and  Information  Sciences,  University  of
+
+               Delaware (October, 1984).
+
+
+
+
+                                                 Contents
+
+
+
+                                                                                                          Page
+
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
+
+ Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
+
+ BBoard Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       4
+
+         BBoard status  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       4
+
+         BBoard checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
+
+                Asynchronous Checking with the CShell. . . . . . . . . . . . . . . .       6
+
+                Asynchronous Checking with Useto. . . . . . . . . . . . . . . . . . .       7
+
+         BBoard reading  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       7
+
+ Current BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       8
+
+ More on BBoards  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       9
+
+         Creating a BBoard  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       9
+
+         Subscribing to a BBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+         BBoard Archives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+         BBoard Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+         Leading a BBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+ Extra for Experts  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      11
+
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
+
+
+
+ _____________________________________
+This document (version #2.6) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+                                                        i
diff --git a/docs/historical/beginners.pdf b/docs/historical/beginners.pdf
new file mode 100644
index 0000000..8d12ca0
Binary files /dev/null and b/docs/historical/beginners.pdf differ
diff --git a/docs/historical/beginners.txt b/docs/historical/beginners.txt
new file mode 100644
index 0000000..18cf893
--- /dev/null
+++ b/docs/historical/beginners.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+                                   MH  for  Beginners
+
+
+
+                            Mary  Hegardt                           Tim  Morgan
+
+
+
+                                               April  12,  1990
+
+
+
+This  document  is  intended  to  be  an  introduction  for  new  users  to  the  MH
+
+mail  system.   For  more  detailed  information,  users  will  want  to  read  the
+
+document  called  The  Rand  MH  Message  Handling  System:  User's  Manual
+
+by  Marshall  T.  Rose  and  John  L.  Romine.   It  is  available  for  Xeroxing  in
+
+suite CS408.
+
+
+
+1         Using  Electronic  Mail
+
+
+
+Electronic  mail  (e-mail)  is  a  quick,  convenient  way  to  send  a  message  to
+
+another  person  (or  persons).   The  message  recipient  can  read  and  reply  to
+
+the  message  at  his  convenience.  E-mail  is  much  faster  than  a  paper  memo
+
+and  avoids  inconveniences  associated  with  the  telephone  such  as  unwanted
+
+interruptions and "phone tag."
+
+
+At UCI, one can send e-mail to people within the ICS department, people in
+
+other  units  on  campus,  and  to  people  at  some  other  institutions  off  campus
+
+(usually other universities).
+
+
+An electronic mail message consists of two parts:  the headers and the body.
+
+The  body  comes  after  the  headers  and  consists  of  the  "message":  whatever
+
+the  sender  types  in.   The  headers  are  the  lines  at  the  top  of  the  message
+
+including  the  subject  and  addresses  of  the  people  to  whom  the  message  is
+
+addressed.  It  is  similar  to  the  top  lines  of  a  memo:  To:,  From:,  Subject:,
+
+and so on.  The headers are separated from the body by a blank line.  As in
+
+
+
+                                                           1
+
+
+
+
+memos, the people listed in the Cc: field are not intended to be the primary
+
+recipients  of  the  message.   The  message  is  for  their  information  only,  and
+
+they are not expected to reply.
+
+
+E-mail is also useful for discussions among groups of people.  This "bboards"
+
+(electronic bulletin boards) facility will be discussed later.
+
+
+An  electronic  mail  address  looks  like  "name @site ".  The  name  is  a  person's
+
+"mail  handle"  _  usually  his  first  initial  followed  by  his  last  name.    For
+
+example, Mary Hegardt's mail handle is "mhegardt".  The site  is the system
+
+where  the  addressee  receives  mail.   Within  the  ICS  Department,  you  need
+
+only  know  the  person's  mail  handle;  the  mail  system  will  automatically  fill
+
+in the "@site " part.
+
+
+
+2         Why  MH  ?
+
+
+
+The  MH  system  is  very  different  from  most  mail  user  agents.   Instead  of
+
+running  one  large  program  which  handles  all  mail  functions  and  keeps  mes-
+
+sages in one large file, MH is a collection of smaller single-purpose programs
+
+used  to  manipulate  mail  messages  which  are  kept  in  individual  files.   MH
+
+may seem to be more complicated or harder to use than other mail systems
+
+(MM, for example), but MH has been designed to allow you to take full ad-
+
+vantage of existing Unix1  commands and programs in connection with mail
+
+messages.  For example, you can use your usual text editor, spelling program,
+
+and printer commands on individual messages.
+
+
+
+3         The  Basics
+
+
+
+The  first  time  you  use  an  MH  command  (probably  inc),  MH  will  create  a
+
+directory called "Mail" in your home (login) directory.  All your mail will be
+
+stored in directories beneath this one.  It will also create a file in your home
+
+directory  called  .mh_profile.  It  is  a  file  that  allows  you  to  tailor  your  MH
+
+environment.  We'll discuss this more later.
+________________________________________________
+    1 Unix is a trademark of AT&T Bell Laboratories
+
+
+
+                                                           2
+
+
+
+
+3.1         Reading  Mail
+
+
+
+When  someone  sends  a  mail  message  to  you,  it  is  delivered  to  a  file  called
+
+your  "mail  drop"  file.  When  you  are  ready  to  read  your  mail,  you  have  to
+
+incorporate (or "inc") your mail messages from the mail drop area into your
+
+account.
+
+
+Everytime  you  log  in  to  your  Unix  account,  you  will  be  told  if  you  have
+
+new  mail  messages.  When  you  are  ready  to  read  them,  type  inc.  The  inc
+
+program will copy your mail into your "inbox" and generate a "scan" listing
+
+of the new messages.  For example,
+
+
+
+4.2  BSD  UNIX  #116:  Mon  Jul  15  14:03:21  PDT  1985
+You  have  new  ZOTnet  mail,  type  "inc"  (or  mail)
+
+TERM  =  (dm1520)
+
+%  inc
+
+Incorporating  new  mail  into  inbox  ...
+
+    1+  10/29  1732-PST  Tim  Morgan           new  bboard!   <<Please  add  us  to  the  uni
+    2   11/12  0016-PST  ROODE@uci-20b       CP6  from  the  20s   <<What  is  (will  be)  t
+    4   11/15  1909-EDT  tts@tts               Hello,  got  a  few  questions
+    5   11/15  2134-PST  Marshall  Rose       MH.6  on  750a   <<Mary,  I've  left  the  dis
+    6   11/16  0808-PST  Mail  Delivery  Su   Returned  mail:  Host  unknown
+    7   11/16  1021-PST  Tim  Morgan           Unix-wizards/info-unix  move
+    8   11/18  0952-PST  freeman@icsd.UCI   Re:New  system  wide  aliases  for  ICS  facu
+    9   11/18  1346-EDT  tts@tts               Have  we  got  a  problem?
+
+
+
+This is what a typical "inc" session for the Postmaster looks like.  Inc  copies
+
+my  mail  into  my  "inbox"  folder,  assigns  a  unique  number  to  each  message,
+
+and  scans  them  for  me.   The  numbers  allow  you  to  refer  to  each  message
+
+individually.  After the message number, you see the date and time the mes-
+
+sage was sent, the name of the sender, and the subject of the message.  The
+
+"current" message is indicated by a "+" sign.  To read it, type "show":
+
+
+
+%  show
+
+    (Message  inbox:1)
+    Received:  from  localhost  by  UCI.EDU  id  a005369;  29  Oct  85  17:32  PST
+    To:  postmaster@UCI.EDU
+    Subject:  new  bboard!
+    Date:  29  Oct  85  17:32:24  PST  (Tue)
+    From:  Tim  Morgan  <morgan@UCI.EDU>
+
+
+
+                                                           3
+
+
+
+
+    Please  add  us  to  the  unix-sw  list.   Also,  if  RAJ  hasn't  mentioned  it,
+    and  if  it  still  exists,  we  should  get  on  the  Astronomy  bboard.
+
+    Tim
+
+
+
+If the message is longer than one screenful, you will see the word "more" at
+
+the bottom_of_the_screen.__When you are ready to see "more" of the message,______
+
+press the __space_bar______ __to see another screenful, or press the __return____ _key to see
+
+just one more line.
+
+
+To see the next message, you could type a couple of different commands:
+
+
+                 %  next
+
+
+or
+
+
+                 %  show  next
+
+
+or
+
+
+                 %  show  2
+
+
+All  of  these  commands  would  have  the  same  effect:   to  type  out  the  next
+
+message in the list.  The most efficient thing to do is to type "next".  When
+
+You  do  that,  message  number  2  will  be  shown  and  become  the  "current
+
+message".
+
+
+
+%  next
+
+
+(Message  inbox:2)
+Received:  from  UCI-20B  by  UCI-ICSA  id  aa01222;  12  Nov  85  0:23  PST
+Date:  12  Nov  1985  0016-PST
+From:  ROODE@uci-20b
+Subject:  CP6  from  the  20s
+To:  zotnet@uci-20b
+cc:  dana_roode%ucicp6@UCI.EDU
+
+
+What  is  (will  be)  the  prescribed  method  of  addressing  for  sending
+CP6  mail  from  the  20s?   They  dont  seem  to  know  about  @CF,  @UCICP6,
+but  "Name_Name%UCICP6"@ICSA  seems  to  fly.
+
+
+dana
+
+
+
+                                                           4
+
+
+
+
+3.2         Selecting  Messages
+
+
+
+As  you  have  seen,  messages  can  be  referred  to  by  their  message  numbers.
+
+Some  MH  commands,  such  as  show,  can  act  upon  more  than  one  message
+
+at  a  time.   A  range  of  messages  can  be  specified  using  the  form  "name1-
+
+name2 "  where  name  is  a  message  number  or  one  of  the  reserved  message
+
+names described below:
+
+
+
+      cur           The current message (the last one that was handled)
+
+
+     next           The next message (same as cur    + 1)
+
+
+     prev           The previous message (cur     1)
+
+
+     first          The first message in the current folder
+
+
+      last          The last message in the folder
+
+
+       all          All messages (first  last )
+
+
+
+If you do not name a specific message, the command will act upon the "cur-
+
+rent message".
+
+
+
+3.3         Sending  Messages
+
+
+
+A mail message consists of two parts:  the headers and the body.  The headers
+
+are the lines at the top of the message that say "To:"  and so on.  The body
+
+is  the  actual  text  of  the  message  (what  you  want  to  say).  To  send  someone
+
+a  message,  you  start  with  the  comp  command.  This  will  start  up  an  editor
+
+called prompter  that will prompt you to fill in_the_headers._ You should type
+
+the requested information for that header or a __return____ _to_omit_it._ You should
+
+end the message by typing control-D (press down the key marked __ctrl__ __and
+
+strike the D key) at the beginning of a new line.  Here's an example:
+
+
+
+%  comp
+
+To:  morgan,  raj
+
+Cc:
+
+
+
+                                                           5
+
+
+
+
+Subject:  Lunch
+
+---------
+
+Where  are  we  going  for  lunch  today  ?
+
+
+
+Mary
+
+<control-D>
+
+--------
+
+What  now  ?    send
+
+
+
+At  the  "What  now  ?"  prompt  you  can  type  a  ?  to  see  what  commands  you
+
+can  type  next.   One  of  the  most  useful  options  at  this  point  is  to  edit  the
+
+draft of the message to correct any mistakes.  To do this you type:
+
+
+                 What  now  ?    edit  vi
+
+
+This will put you in the vi  editor to edit the message.  If you use emacs or any
+
+other  editor,  just  type  "edit  emacs"  or  whatever.   When  you  have  finished
+
+editing, just exit the editor as you would normally.  You will then get another
+
+"What  now  ?" prompt.  Here are some of the "What now" options:
+
+
+
+     edit  editor              Edit  the  message  using  the  specified  editor.   When  you
+
+                               exit, you will be back at What  now.
+
+
+                list           Shows the message you just typed
+
+
+   whom  -check                Verifies that the addresses you have used are valid as far
+
+                               as our system can tell
+
+
+                send           Sends the message to the recipients
+
+
+                push           Sends the message in the background
+
+
+                quit           Quits  without  sending  the  message.   Saves  the  text  of
+
+                               the  message  as  a  "draft".  Type  comp  -use  to  get  back
+
+                               to that draft later.
+
+
+ quit  -delete                 Quit, throwing away the draft
+
+
+
+Make sure you are happy with your message before typing send.  There is no
+
+way to recall a message once it has been sent.
+
+
+
+                                                           6
+
+
+
+
+3.4         Replying  to  Messages
+
+
+
+To  reply  to  the  current  message  type  repl.   When  you  do  this,  the  reply
+
+headers  will  be  printed  out  and  you  will  be  put  in  the  prompter  editor  to
+
+type  in  your  reply  text.  When  you  are  replying  to  a  message,  the  name  of
+
+the sender of the original message will appear in the "To:"  field.  Any people
+
+on  the  "To:"  or  "Cc:"  lists  will  also  be  copied  on  your  reply  message.   As
+
+with  comp,  when  you  have  finished,  type  control-D  and  send  (or  whatever)
+
+at What  now  ?.
+
+
+
+3.5         Forwarding  Messages
+
+
+
+If  you  receive  a  particularly  interesting  message  and  can't  resist  sharing
+
+it  with  others,  you  can  forward  it  using  the  forw  command.   You  will  be
+
+prompted  to  fill  in  the  headers  (the  address  to  which  the  message  is  to  be
+
+forwarded, etc.).  When you have done this, you will see the text of the mes-
+
+sage which you are forwarding and will be given the opportunity to add some
+
+enlightening text to the message.  Exit with control-D and do whatever feels
+
+good at the What  now  ? prompt.
+
+
+
+3.6         The  Advanced  Features
+
+
+
+You  will  probably  want  to  master  the  beginning  MH  concepts  before  you
+
+tackle the following. . .
+
+
+
+3.7         Folders
+
+
+
+Folders  are  really  just  directories  for  storing  mail  messages  in  an  organized
+
+way.  To store a message in a folder named "inbox", type:
+
+
+                 %  refile  5  +inventory
+
+
+If  the  folder  doesn't  exist  yet,  you  will  be  asked  if  it  should  be  created.  To
+
+access  messages  in  another  folder,  you  can  change  your  current  folder  from
+
+
+
+                                                           7
+
+
+
+
+"inbox" to something else.  If you want to look at all the messages pertaining
+
+to the inventory, you type:
+
+
+                 %  folder  +inventory
+
+
+and now you use scan, show, etc., to manipulate the messages in that folder.
+
+To change back to inbox, type:
+
+
+                 %  folder  +inbox
+
+
+Using  the  inc  command  will  change  your  current  folder  to  be  the  "inbox"
+
+automatically.
+
+
+
+4         Mailing  files
+
+
+
+Mailing  files  is  usually  not  a  good  idea,  especially  for  large  files.  The  mail
+
+system  was  never  designed  for  moving  big  files.  You  can  use  the  cp  file  to
+
+move the file to another account much more efficiently:
+
+
+                 %  cp  "frated/desired-file  "./newfile
+
+
+This will copy the file from frated's account to the current directory and call
+
+it "newfile".
+
+
+You can also copy files across the network using rcp:
+
+
+                 %  rcp  icsd:frated/desired-file  ./newfile
+
+
+This copies frated's file on the system icsd to the current directory.
+
+
+If you really  have to mail a file, you use the mhmail  program.  To mail a file
+
+"myfile" to another user "frated", with "MyFile" as the subject type:
+
+
+                 %  mhmail  frated  -subject  MyFile  <  myfile
+
+
+
+5         Searching  for  messages
+
+
+
+The  pick  program  allows  you  to  search  your  inbox  (or  any  other)  folder  to
+
+find messages which contain a certain word.  If you want to list all messages
+
+
+
+                                                           8
+
+
+
+
+from Smith you can type:
+
+
+                 %  pick  -from  smith  -list
+
+
+and  it  will  list  the  numbers  of  all  messages  from  Smith  that  are  in  the  cur-
+
+rent  folder.   You  can  pick  messages  according  to  any  of  the  headers  (-to
+
+-from  -subj  -cc  or  -date) or just search all the messages for a given word
+
+(-search).
+
+
+
+6         The  MH  Profile
+
+
+
+Each MH user has a file in his directory called .mh_profile.  This file contains
+
+a  list  of  user-specified  default  options  for  MH  programs.  The  only  required
+
+entry is the name of your MH directory:
+
+
+                 Path:    Mail
+
+
+or
+
+
+                 Path:    mhbox
+
+
+To make a change to your .mh_profile, you edit the file and add a line for
+
+the  applicable  program.  For  example,  if  you  would  like  to  use  vi  instead  of
+
+prompter  as  your  initial  editor  when  composing  messages,  you  would  add
+
+this line to your .mh_profile:
+
+
+                 comp:    -editor  vi
+
+
+or, if you want to have a format file for scan  to use, you should have:
+
+
+                 scan:    -form  formatfile
+
+
+Almost  all  of  the  MH  programs  have  options  that  can  be  set  using  the
+
+.mh_profile.   You  should  consult  the  MH  User's  Manual  for  more  infor-
+
+mation about this.
+
+
+Many  people  will  want  to  add  a  signature  line  to  their  .mh_profile.  This
+
+line will appear as your signature on the From:  line in messages you send.  It
+
+looks like this:
+
+
+
+                                                           9
+
+
+
+
+                 Signature:    John  Q.  Public
+
+
+Occasionally  people  express  an  interest  in  getting  rid  of  some  of  the  header
+
+lines  in  their  mail  messages.  They  don't  want  to  see  the  "Received  from",
+
+"Via"  information,  or  some  other  header.   It  is  possible  to  prevent  these
+
+and  other  annoying  headers  from  being  displayed  by  changing  your  show
+
+processor to be mhless.  To do this you must add this line
+
+
+                 showproc:    mhless
+
+
+to your .mh_profile.  You also must create a file called ".mhlessrc" contain-
+
+ing  the  words  which  appear  at  the  beginning  of  the  lines  you  don't  want  to
+
+see.
+
+
+The typical ".mhlessrc" file will look like this:
+
+
+
+Received
+
+Via
+
+BB-Posted
+
+Return-Path
+
+
+
+The ".mhlessrc" file must be in your home directory.
+
+
+
+7         BBoards
+
+
+
+Electronic bulletin boards (BBoards) are a convenient way for a group of peo-
+
+ple to discuss a particular topic.  Messages are sent to an address where they
+
+can  be  read  and  replied  to  by  all  interested  parties.  In  the  ICS  department
+
+we have some "local" BBoards which involve only people in the department.
+
+We  also  subscribe  to  many  nationally  distributed  BBoards.   BBoards  are
+
+read  using  the  bbc  program  which  will  allow  you  to  read  the  messages  with
+
+an MH-like interface.
+
+
+One  very  important  BBoard  is  "system".    It  contains  vital  news  about
+
+changes  in  software,  system  downtime,  new  programs,  and  other  informa-
+
+tion useful to all users.
+
+
+
+                                                           10
+
+
+
+
+To  read  a  BBoard,  you  type  "bbc  BBoard__name ".   The  bbc  program  will
+
+check to see if there are new messages in the named BBoard and if there are,
+
+it  will  start  up  msh  so  you  can  read  them.  The  msh  program  allows  you  to
+
+use  regular  MH  commands  when  reading  BBoards.  Type  "show"  to  see  the
+
+current message, "next" to see the next message, and so on.  Type "quit" to
+
+quit reading the current BBoard.  If you have named more than one BBoard
+
+on  the  command  line  or  in  your  .mh_profile,  bbc  will  continue  processing
+
+the next BBoard in the list.
+
+
+Here is an example of using bbc  to read the system BBoard:
+
+
+
+                                                           11
+
+
+
+
+%  bbc  system
+Reading  system,  currently  at  message  1  of  22
+(msh)  show
+
+
+(Message  1,  BBoard-ID:  1360)
+BBoard-ID:  1360
+BB-Posted:  Wed,  29  Jan  86  15:36:39  PST
+Received:  from  localhost  by  UCI.EDU  id  a006693;  29  Jan  86  15:20  PST
+To:  network@UCI.EDU
+Subject:  Imagen  24300
+Date:  Wed,  29  Jan  86  15:19:43  -0800
+From:  Tinh  Tang  <ttang@UCI.EDU>
+
+
+The  Imagen  24300  is  now  operating  normally.   It  was  broken  down
+due  to  the  paper  jammed  in  the  drum.   Luckily,  it  didn't  cause
+any  damage.
+
+
+/ttang
+
+
+(msh)  next
+
+
+(Message  4,  BBoard-ID:  1363)
+BBoard-ID:  1363
+BB-Posted:  Fri,  31  Jan  86  13:33:37  PST
+Received:  from  localhost  by  UCI.EDU  id  a001631;  31  Jan  86  13:30  PST
+To:  msgs@UCI.EDU
+Subject:  uci.edu  down  2/7/86  17:10  -  2/7/86  20:30
+Date:  Fri,  31  Jan  86  13:30:27  -0800
+From:  root@UCI.EDU
+
+
+The  uci.edu  will  be  down  from
+February   7,1986  17:10  till  February   7,1986  20:30.
+The  reason  for  the  downtime  is:
+Both,  the  Computing  Facility  and  the  Physical  Sciences  Dataswitches
+will  be  unavailable  from  5:10pm  until  8:30pm  on  Friday,  February  7th.
+Therefore  all  the  Computers  attached  to  those  switches  and  the
+corresponding  tandem  link  will  be  unavailable  to  users  on
+the  specified  time.                       (RJ).
+
+
+Downtime  Scheduler
+
+
+(msh)  quit
+%
+
+
+
+                                                           12
+
+
+
+
+You can see a list of all the available BBoards by typing:
+
+
+                 %  bbc  -topics
+
+
+You  can  also  put  a  line  in  your  ".mh_profile"  listing  all  the  BBoards  you
+
+want to read on a regular basis:
+
+
+                 bboards:    system  movies  mh-users  events
+
+
+Then you only need to type "bbc" to read all your BBoards.
+
+
+
+8         Checking  for  Mail
+
+
+
+Under Unix, there are many different ways to check for new mail.  The easiest
+
+way to do it is to set the csh  variable named "mail" to tell csh  to check for
+
+new mail for you periodically.  To do this, add the line
+
+
+                 set  mail=(60  /usr/spool/mail/$USER)
+
+
+to  the  .login  file  in  your  home  directory.  This  command  says  to  check  for
+
+mail if csh  is about to prompt you with a % sign,  and if it has been at least
+
+60  seconds  since  it  last  checked  for  mail.  The  advantage  of  this  method  of
+
+mail notification, besides simplicity, is that you will never be interrupted by
+
+a  mail  notification.  You  will  only  be  notified  about  new  mail  when  you  are
+
+between commands.
+
+
+If you want asynchronous mail notification, which will print to your terminal
+
+regardless  of  what  you  are  currently  doing,  you  may  make  use  of  a  "receive
+
+mail  hook"  called  "rcvtty".  To  do  this,  create  a  file  in  your  home  directory
+
+called ".maildelivery".  In this file, put the line
+
+
+                 *  -  pipe  R  /usr/uci/lib/mh/rcvtty
+
+
+Then,  each  time  mail  arrives,  you  will  receive  a  one-line  "scan"  listing  of
+
+the  mail  if  your  terminal  is  world-writable.   For  more  information  on  mail
+
+delivery files, type:
+
+
+                 %  man  5  maildelivery
+
+
+
+                                                           13
+
+
+
+
+This will tell you about all the options available to you if you use maildelivery
+
+files.
+
+
+
+9         Aliases
+
+
+
+Using MH, you may specify your own private mail aliases.  This feature allows
+
+you to store lists of addresses or long internet addresses of people with whom
+
+you  frequently  correspond  in  one  file,  and  then  to  address  them  using  short
+
+mnemonic names.  Typically, you will call your alias file "aliases";  it must
+
+be  stored  in  your  MH  directory.  The  format  of  this  file  is  simple.  The  alias
+
+is  given,  followed  by  a  colon,  followed  by  one  or  more  legal  mail  addresses
+
+separated by commas.  For example, you might for some reason have an alias
+
+for all the users named "Rose" in the ICS department:
+
+
+                 roses:    prose,  srose,  mrose,  drose
+
+
+In   addition   to   your   "aliases"   file,   you   will   need   to   modify   your
+
+.mh_profile  in  order  to  use  aliases.    You  should  add  the  flag  "-alias
+
+aliases"  to  the  entries  for  the  commands  ali,  whom,  send,  and  push,  cre-
+
+ating entries for these programs if they aren't already in your .mh_profile.
+
+Now,  messages  addressed  to  "roses"  will  be  distributed  to  all  the  people
+
+listed in the alias.
+
+
+The  ali  command  is  used  to  show  you  what  an  alias  expands  to.  You  just
+
+type
+
+
+                 %  ali  alias
+
+
+and ali  will respond with the expansion of the alias.  Ali  searches the system
+
+aliases file in addition to your private ones.
+
+
+
+10           Blind  Lists
+
+
+
+There  are  two  different  types  of  so-called  "blind  addressing"  of  messages.
+
+The  BCC:  field  allows  you  to  add  recipients  to  your  message  just  like  those
+
+who are CC'd, but the normal recipients will not see that the BCC recipients
+
+
+
+                                                           14
+
+
+
+
+were copied on the message, their replies will not go to the blind recipients,
+
+and the blind recipients cannot (easily) reply to the message.
+
+
+The  second  type  of  blind  mailing  is  actually  called  a  "group  address  list",
+
+although it is commonly referred to as a "blind list".  The format of this type
+
+of address is
+
+
+                 phrase :    address__list ;
+
+
+where  the  "phrase "  is  any  English  phrase  of  one  or  more  words,  and  the
+
+address__list  consists  of  one  or  more  addresses  separated  by  commas.   The
+
+recipients of a message addressed in this fashion will see simply
+
+
+                 phrase :    ;
+
+
+so  when  they  reply  to  the  message,  their  reply  will  come  only  to  the  sender
+
+(or  the  Reply-To:  field,  if  one  was  specified),  rather  than  going  to  all  the
+
+recipients of the original list.  For example, to use a group address list for the
+
+"roses" alias you would type:
+
+
+                 To:    People  Named  Rose:    roses;
+
+
+This type of group address is very useful for making up lists of related people,
+
+such as all the people working on a particular research project.
+
+
+
+                                                           15
diff --git a/docs/historical/changes.pdf b/docs/historical/changes.pdf
new file mode 100644
index 0000000..12b4c64
Binary files /dev/null and b/docs/historical/changes.pdf differ
diff --git a/docs/historical/changes.txt b/docs/historical/changes.txt
new file mode 100644
index 0000000..813e341
--- /dev/null
+++ b/docs/historical/changes.txt
@@ -0,0 +1,1452 @@
+
+
+
+
+
+
+
+
+
+                                   Changes to
+                      The RAND MH Message Handling System:
+                               UCI version MH 6.8
+
+
+                                 John L. Romine
+
+                            Computing Support Group
+                 Department of Information and Computer Science
+                        University of California, Irvine
+                             Irvine, CA  92717-3425
+                               Bug-MH@ICS.UCI.EDU
+
+
+                                    _A_B_S_T_R_A_C_T
+
+
+                    This document describes the changes to the
+               UCI version of the RAND MH system from MH 6.6 to
+               this release of MH 6.8.  This document is meant to
+               supplement, not supersede, the standard MH User's
+               manual and MH Administrator's manual.
+
+                    Comments concerning this documentation should
+               be addressed to the mailbox Bug-MH@ICS.UCI.EDU, or
+               ucbvax!ucivax!bug-mh.
+
+
+
+          _A_C_K_N_O_W_L_E_D_G_E_M_E_N_T_S
+
+          The _M_H system described herein is based on the original RAND
+          _M_H system.  It has been extensively developed (perhaps too
+          much so) by Marshall T. Rose and John L. Romine at the
+          University of California, Irvine.  Einar A. Stefferud, Jerry
+          N. Sweet, and Terry P. Domae provided numerous suggestions
+          to improve the UCI version of _M_H.
+
+               Of course, a large number of people have helped _M_H
+          along.  The list of "_M_H immortals" is too long to list here.
+          For this release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes and
+          other changes.  A handful of courageous _M_H-_W_o_r_k_e_r_s volun-
+          teered to beta-test these changes; their help is particu-
+          larly appreciated.
+
+
+
+
+
+
+
+
+
+
+                              December 1, 1993
+
+
+
+
+
+          Changes to MH 6.8                                          2
+
+
+
+          _D_I_S_C_L_A_I_M_E_R
+
+          The Regents of the University of California wish to make  it
+          known that:
+
+               Although each program has been tested by its  con-
+               tributor, no warranty, express or implied, is made
+               by the contributor or the University  of  Califor-
+               nia,  as  to  the  accuracy and functioning of the
+               program and related program  material,  nor  shall
+               the  fact of distribution constitute any such war-
+               ranty, and no responsibility  is  assumed  by  the
+               contributor  or  the  University  of California in
+               connection herewith.
+
+          _C_O_N_V_E_N_T_I_O_N_S
+
+          In this document, certain formatting conventions are adhered
+          to:
+
+               The names of UNIX commands, such as _c_o_m_p are  presented
+               in _i_t_a_l_i_c_s.
+
+               Arguments to programs, such as `msgs' and `-nobell' are
+               delimited by single-quotes.
+
+               Text that should be typed exactly as-is, such  as  com-
+               mand  lines  (e.g.,  "folder  -pack"), are delimited by
+               double-quotes.
+
+               UNIX pathnames and envariables, such  as  /usr/uci  and
+               $SIGNATURE, are presented in bold font.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              December 1, 1993
+
+
+
+
+
+          Changes for MH 6.8.3                                       3
+
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._8._3
+
+          The MH 6.8.3 maintenance release contains few user-visible
+          changes.  Most of the changes are internal to the multi-
+          media display program _m_h_n to support RFC 1521 (the new MIME
+          standard).  This is the current version of MH as of December
+          1, 1993.
+
+          _R_u_n_t_i_m_e _T_a_i_l_o_r_i_n_g
+
+          When posting mail using the SMTP, _p_o_s_t does not normally
+          send the HELO command. This is because _S_e_n_d_M_a_i_l would fail
+          if the host name given in the HELO command was the local
+          host.  Later versions of _S_e_n_d_M_a_i_l will now complain if you
+          omit the HELO command.
+
+               If you specify a hostname with the clientname: option
+          in the _m_t_s_t_a_i_l_o_r file, _p_o_s_t will give the HELO command with
+          that name, otherwise no HELO command is given.  See _m_h-
+          _t_a_i_l_o_r(5) for more details.
+
+          _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+          folder  The _f_o_l_d_e_r command now has `-create' and `-nocreate'
+                  options.  See _f_o_l_d_e_r(1) for details.
+
+          inc     A bug where `-host' would not override the pophost
+                  as set in the _m_t_s_t_a_i_l_o_r file has been fixed.  This
+                  bug was also fixed in _m_s_g_c_h_k.
+
+          mhn     The _m_h_n command has several changes: updates for
+                  conformance with RFC 1521, addition of two caches:
+                  public and private, addition of two caching poli-
+                  cies: one for reading and one for writing, support
+                  for storing multipart entities, and a few bug fixes.
+                  See _m_h_n(1) for complete details.
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._8._2
+
+          The MH.6.8.2 patch release contains only internal changes to
+          support the BSD 4.4 and 386BSD versions of UNIX.  This ver-
+          sion of _M_H was released August 25, 1993, but was not widely
+          distributed.
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._8._1
+
+          The MH.6.8.1 patch release is a maintenance release.  This
+          is the current released version of _M_H as of August 20, 1993.
+
+               This release includes a small number of bug fixes, a
+          few minor enhancements, some changes for the new MIME stan-
+          dard, and support for ESMTP (RFC 1425).  Support for BSD 4.4
+          and 386BSD is planned for the next release.
+
+
+
+
+                              December 1, 1993
+
+
+
+
+
+          Changes for MH 6.8.3                                       4
+
+
+               Many other fixes which have already been received are
+          still being merged.  If you've sent an update for MH 6.8 to
+          Bug-MH@ics.uci.edu and it isn't in this release, it'll prob-
+          ably appear in the next release.
+
+          _F_i_x_e_s _a_n_d _E_n_h_a_n_c_e_m_e_n_t_s
+
+          Many minor documentation corrections were made.  There are
+          also a few program changes:
+
+          mhn   The `-cache policy', `-[no]check', and `-[no]pause'
+                switches have been added.   Some other minor changes
+                have been made to comply with the new MIME standard.
+                See _m_h_n(1) for complete details.
+
+          post  When posting mail with SendMail, _p_o_s_t will not use the
+                ONEX command when it is posting a message with BCCs.
+
+          scan  _s_c_a_n will now work with big width values.
+
+          _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+          One new function has been added:
+
+          %(profile arg)  This function looks up a component in the
+                          .mh_profile or context files and returns the
+                          value of that component.
+
+          _C_o_n_f_i_g_u_r_a_t_i_o_n
+
+          Two new configuration options are present:
+
+          GCOS_HACK    The so-called "gcos" field of the password file
+                       is used as a last resort to find the user's
+                       full name (see _m_h-_p_r_o_f_i_l_e(5) for details).
+                       Enable this option if your _p_a_s_s_w_d(5) man page
+                       notes that the `&' character in the "gcos"
+                       field stands for the login name.
+
+          NORUSERPASS  Tells _M_H that your system doesn't have the
+                       _r_u_s_e_r_p_a_s_s(3) routine; _M_H will include its own
+                       copy of this routine in its library.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              December 1, 1993
+
+
+
+
+
+          Changes for MH 6.8                                         5
+
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._8
+
+          This is the current released version of _M_H as of December
+          14, 1992.  This release includes a number of bug fixes and
+          internal changes to make the code more portable.  Two new
+          authentication methods are provided for the POP, and support
+          for SVR4 shared libraries is complete.
+
+               The major user-visible change in this release is the
+          incorporation of support for multi-media mail as specified
+          by the Multi-purpose Internet Mail Extensions (MIME)
+          RFC 1341.  This allows you to include things like audio,
+          graphics, and the like, in your mail messages.  A new com-
+          mand, _m_h_n, has been provided to support MIME and a detailed
+          man page is provided in _m_h_n(1).
+
+          _D_o_c_u_m_e_n_t_a_t_i_o_n
+
+          The documentation has some general improvements, and the
+          READ-ME document has been re-organized to help _M_H adminis-
+          trators find the appropriate configuration options for their
+          system.  The Makefiles in the papers/ hierarchy have been
+          changed to invoke _T_e_X as "tex" (instead of "tex82").
+
+          The following new man pages are also available:
+
+          _m_h_n(1)      _m_h_n helps the user process multi-media mail.
+
+          _m_h_p_a_r_a_m(1)  _m_h_p_a_r_a_m lets the user extract information from
+                      the _M_H profile.
+
+          _p_o_p_a_u_t_h(8)  the APOP database administration program (see
+                      below).
+
+          _p_o_p_i(1)     the POP initiator (see below).
+
+          _s_l_o_c_a_l(1)   fully documents _s_l_o_c_a_l.  The _m_h_o_o_k(1) man page
+                      now documents only the _M_H receive-mail hooks.
+
+          _I_n_t_e_r_n_a_l _C_h_a_n_g_e_s
+
+          The _M_H source code is in the process of being cleaned up to
+          make pedantic ANSI C compilers happy.  Occurrences of "NULL"
+          have been replaced by "0" where appropriate.  Extra tokens
+          after "#else" and "#endif" have been put inside comments
+          (this is still in progress).  The code should now compile
+          cleanly on many more systems, specifically, more variants of
+          SVR4.
+
+               The version of tws/dtimep.c which was included in MH
+          6.7.2 was incompatible with the _l_e_x library on some systems,
+          and has been removed.
+
+               A bug in the handling of blind lists inside alias files
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.8                                         6
+
+
+          has been fixed.
+
+          _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+          There were three new options added to the POP.
+
+          APOP  This option indicates that the POP daemon will support
+                the   non-standard   APOP  command  which  provides  a
+                challenge-based authentication system  using  the  MD5
+                message digest algorithm.
+
+                This option also causes the _p_o_p_a_u_t_h program to be  in-
+                stalled,  which allows the administrator to manipulate
+                the APOP authorization database.
+
+          KPOP  Support for KERBEROS with POP.  This code builds _p_o_p_d,
+                _i_n_c and _m_s_g_c_h_k to support only the "kpop" protocol.
+                This code is still expiremental, but is available for
+                those sites wishing to test it.
+
+          MPOP  This option indicates that the POP daemon will support
+                the non-standard XTND SCAN command which provides per-
+                formance enhancements when using the POP over low-
+                speed connections.
+
+                This option also causes an interactive POP client pro-
+                gram, _p_o_p_i, to be compiled and installed.  A man page
+                for the _p_o_p_i program is also provided.  This option
+                requires the configuration to have "bboards: pop".
+
+          The APOP and MPOP non-standard POP facilities are documented
+          in _T_h_e _I_n_t_e_r_n_e_t _M_e_s_s_a_g_e (ISBN 0-13-092941-7), a book by
+          Marshall T. Rose.  For more details, see support/pop/pop-
+          more.txt and the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.  The APOP option
+          peacefully co-exists with the standard POP, KPOP completely
+          replaces the standard POP, and MPOP requires "bboards: pop".
+
+          _F_i_l_e _L_o_c_k_i_n_g
+
+          The file locking code has been cleaned up to support three
+          kinds of kernel-level file locking.  As appropriate for your
+          system, include the LOCKF, FCNTL or FLOCK option.  For more
+          details, see _m_h-_t_a_i_l_o_r(5).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.8                                         7
+
+
+          Configuration Directives
+
+          A number of new configuration directives have been added  or
+          changed.  The full details are given in the READ-ME.
+
+          cp:        The command used to  install  new  files  if  not
+                     "cp".
+
+          ln:        The command used to link files  together  in  the
+                     source tree if not "ln".
+
+          mts:       Full support for ZMAILER has been added.
+
+          popdir:    The directory where _p_o_p_d will be installed if not
+                     /usr/etc.
+
+          regtest:   Set to "on" to prevent the hostname  and  compile
+                     date from being included in _M_H binaries.
+
+          sharedlib: You may now specify "sun4" or "sys5"  (for  SVR4)
+                     shared libraries.
+
+          signal:    Specifies the base type of the function  returned
+                     by  _s_i_g_n_a_l().   This  was previously defined with
+                     "options TYPESIG".
+
+          Several `-D' options to _c_c have been added or changed:
+
+          APOP       Authenticated POP (see above).
+
+          AUX        Support for A/UX systems.
+
+          DBMPWD     The DBM option has been renamed DBMPWD.
+
+          HESIOD     Support for the HESIOD name server.
+
+          KPOP       KERBEROS POP (see above).
+
+          LOCALE     Support for local characters sets; uses the _s_e_t_-
+                     _l_o_c_a_l() function.
+
+          MAILGROUP  Makes _i_n_c set-group-id.  You may need this option
+                     if your /usr/spool/mail is not world-writeable.
+
+          MIME       Multi-media mail.
+
+          MPOP       Mobile POP (see above).
+
+          MSGID      Enables _s_l_o_c_a_l to detect and surpress duplicate
+                     messages.
+
+          OSF1       Support for DEC OSF1 systems.  May be incomplete.
+
+          RENAME     Include this option if your system has a _r_e_n_a_m_e()
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.8                                         8
+
+
+                     system call.
+
+          SVR4       Support for System 5 Release 4 or newer systems.
+
+          TYPESIG    This option has been dropped.  See `signal'
+                     above.
+
+          UNISTD     Include this option if your system has the
+                     include file <unistd.h>.
+
+          VSPRINTF   Include this option if your system has the
+                     _v_s_p_r_i_n_t_f() library routine; otherwise, __d_o_p_r_n_t()
+                     will be used.
+
+          YEARMOD    Forces the _m_h-_f_o_r_m_a_t `year' function to return
+                     2-digit values.  Use this option during a brief
+                     transition period if you have local _m_h-_f_o_r_m_a_t
+                     files which need to be converted to support 4-
+                     digit years.
+
+          _F_U_N_C_T_I_O_N_A_L _C_H_A_N_G_E_S
+
+          In addition to the configuration changes mentioned above, a
+          number of functional changes have been made to the system.
+          Many programs have new features added and a few new programs
+          have are provided. Each command's manual page gives complete
+          information about the its operation.  Here is a short sum-
+          mary of the changes.
+
+          _M_H _S_e_q_u_e_n_c_e_s
+
+          A larger number of user-defined sequences are available.
+          Previously, this number had been 10.  On 32-bit systems, 26
+          user-defined sequences are available.
+
+          _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+
+          _M_H programs will now complain if the .mh_profile does not
+          end in a newline.  Also, one enhancement and one new profile
+          component are provided:
+
+          Aliasfile:  Multiple filenames may now be given.
+
+          Inbox:      New; the default folder (for _i_n_c, etc.) if not
+                      "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.8                                         9
+
+
+
+          _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+          A few minor bugs were fixed in format string handling, and a
+          few  new features were added.  See _m_h-_f_o_r_m_a_t(5) for complete
+          details.
+
+          Addresses      An  attempt  is  made   to   decipher   X.400
+                         RFC 987-style addresses.
+
+          Comments       Comments may be added to _m_h-_f_o_r_m_a_t  files;  a
+                         comment  begins with the 2-character sequence
+                         "%;", and ends with an un-escaped newline.
+
+          %(modulo n)    The `modulo' function escape has been added.
+
+          %(year{date})  The date parser has been enhanced  to  under-
+                         stand  more  illegal date formats; `year' now
+                         returns a 4-digit number.
+
+          _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+          A number of _M_H commands have minor changes:
+
+          ali       The output with `-user -list' was changed to match
+                    the output with `-nouser -list'.
+
+          burst     Will no longer drop the last message of a digest.
+
+          inc       Accepts the `-apop' switch for authenticated POP
+                    (see above); will attempt to detect write errors
+                    (e.g., no space left on device) when incorporating
+                    mail; no longer replaces newline characters with
+                    NULLs.
+
+          folder    The `-noprint' option was broken and has been
+                    dropped.
+
+          forw      Supports `-mime' to use MIME-style multi-part mes-
+                    sages.
+
+          mhl       Will no longer put an extra space at the end of
+                    the `%{text}' in a formatfield.
+
+          mhn       New; manipulates multi-media (MIME) messages; a
+                    detailed man page is provided.
+
+          mhparam   New; reads the _M_H profile (and context) and writes
+                    the values of the specified components on the
+                    standard output; useful in programmatic con-
+                    structs.
+
+          msgchk    Supports `-apop' (see above).
+
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.8                                        10
+
+
+          packmbox  New; packs an _M_H folder into a UUCP-style mailbox.
+
+          popi      New; a client-side POP initiator; available only
+                    if you built _M_H with the MPOP option (see above).
+
+          refile    A bug where the `rmmproc' did not remove all
+                    specified message files has been fixed.
+
+          scan      The `-file' option is fully supported and will no
+                    longer complain about empty folders.
+
+          send      Supports `-mime' and `-split' to split large mes-
+                    sages into multiple partial messages using MIME.
+
+          _S_u_p_p_o_r_t _P_r_o_g_r_a_m_s
+
+          fmtdump   Can now read a format file, or a format string
+                    given on the command line.
+
+          popauth   New; manages the APOP authorization database (see
+                    above).
+
+          sendmail  The _s_e_n_d_m_a_i_l replacement will be installed only if
+                    your `mts' setting uses the `/smtp' option.
+
+          slocal    A new man page for _s_l_o_c_a_l is available; the new
+                    `mbox' action is available to write a file in
+                    _p_a_c_k_f format; a bug where extra `>' characters
+                    were written to MMDF-style maildrops has been
+                    fixed; if compiled with the MSGID option, can
+                    detect and suppress reception of duplicate mes-
+                    sages.
+
+          viamail   New; bundles a directory (like _s_h_a_r) and sends it
+                    through multi-media mail.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                               December 14, 1992
+
+
+
+
+
+          Changes for MH 6.7.2                                      11
+
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._7._2
+
+          The MH.6.7.2 patch release is a maintenance release.  This
+          is the current released version of _M_H as of February 1,
+          1992.
+
+               This release now supports the NCR Tower running SYS5R4.
+          The WP changes installed in MH.6.7.0 have been removed.
+
+          _S_h_a_r_e_d _L_i_b_r_a_r_i_e_s
+
+          Support for SYS 5 shared libraries is in progress.
+
+               Support for Sun OS 4.0 shared libraries had been
+          improved.  The _M_H library has been modified to move initial-
+          ized data into a data definition file.  The shared library
+          will now consist of a libmh.so and libmh.sa file.  The
+          shared library version number will no longer track the _M_H
+          patch release number, and its numbering begins with version
+          `1.1' with this release.
+
+          _R_e_p_l_a_c_e_m_e_n_t _S_e_n_d_M_a_i_l
+
+          Since many standard system programs expect to post mail by
+          invoking /usr/lib/sendmail, a minimal replacement _S_e_n_d_M_a_i_l
+          is provided in this release.  This replacement is meant to
+          be installed on (e.g., diskless) client workstations which
+          post mail using SMTP, and do not run a message transport
+          system.  It will call _p_o_s_t to post mail; be sure you have
+          configured _M_H with the `/smtp' mts option.  This sendmail
+          replacement is installed in your _M_H etc directory, and you
+          should link /usr/lib/sendmail to it.
+
+          _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+          A manual page for the _f_m_t_d_u_m_p format string disassembler  is
+          supplied, and some new format functions were added:
+
+          folder   In _s_c_a_n, this component escape contains the name of
+                   the current folder.  It is not defined for other _M_H
+                   commands.
+
+          getenv   This function escape returns the value  of  an  en-
+                   vironment variable.
+
+               There will be some additional changes in these routines
+          in the next patch release.
+
+
+
+
+
+
+
+
+
+
+                                  Feb 1, 1992
+
+
+
+
+
+          Changes for MH 6.7.2                                      12
+
+
+
+          _O_t_h_e_r _B_u_g _F_i_x_e_s _a_n_d _E_n_h_a_n_c_e_m_e_n_t_s
+
+          In addition to some other minor enhancements, some bugs were
+          fixed which in general were not user-visible:
+
+          Blind lists   Users may now specify RFC822 address groups in
+                        their  alias  files.   These groups are imple-
+                        mented by _M_H as blind lists.
+
+          date parsing  A number of sites have brain-damaged  versions
+                        of lex.  _M_H will now come with the date parser
+                        already run through lex.
+
+          mark          A bug dealing with _m_a_r_k and the sequence named
+                        `cur' is fixed.  This was previously a problem
+                        for mh-e users.
+
+          MH.doc        The _M_H nroff version of the manual  no  longer
+                        contains teletype escape sequences.
+
+          scan          Can now handle headers as long as 512 bytes.
+
+          Signals       _M_H programs will no longer catch the  HUP  and
+                        TERM  signals while waiting for a sub-process.
+                        This was causing hung processes when your ter-
+                        minal line was was dropped unexpectedly.
+
+          Signature     If your signature is not defined, _M_H will  use
+                        the   value   of   the  gecos  field  of  your
+                        /etc/passwd entry as your signature.
+
+          version.sh    A bug in the awk script  in  config/version.sh
+                        was fixed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                  Feb 1, 1992
+
+
+
+
+
+          Changes for MH 6.7.1a                                     13
+
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._7._1_a
+
+          The MH.6.7.1a patch was made available on January 25, 1991
+          for limited distribution only.  (This release had some known
+          bugs, and so was not widely distributed.) This release
+          incorporates several new features of particular note to
+          users of sequences and format strings, as well as some gen-
+          eral documentation improvements.  There are a few minor
+          enhancements and internal bug fixes also.  Complete documen-
+          tation of these changes is given in the individual manual
+          pages, and the READ-ME file.
+
+          _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e_s
+
+          A new manual page, _m_h-_s_e_q_u_e_n_c_e (5), has been added.  This
+          manual page attempts to completely document the syntax and
+          semantics of _M_H message sequence specifications.
+
+               A powerful new feature is the ability to specify mes-
+          sage ranges with user-defined sequences.  The  specification
+          "name:n" may be used, and it designates up to the first `n'
+          messages (or  last  `n' messages  for  `-n') which  are
+          elements  of the user-defined sequence `name'.
+
+               The message specifications "name:next" and "name:prev"
+          may also be used, and they designate the next or previous
+          message (relative to the current message) which is an ele-
+          ment of the user-defined sequence `name'.  The specifica-
+          tions "name:first" and "name:last" are equivalent to
+          "name:1" and "name:-1", respectively.  The specification
+          "name:cur" is not allowed (use just "cur" instead).
+
+               These specifications allow the user to step through a
+          sequence with a command like "show name:next".
+
+          _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+          _M_H format strings now support an if-then-elseif-else clause
+          (the `elseif' is new).  This will make format strings with
+          multi-case conditions somewhat less complex.
+
+               A new format function `addr' had been added.  This
+          function takes an address header name as its argument, and
+          returns a rendering of the address contained in that header
+          as "user@host" or "host!user".
+
+               Format widths now may be specified as a negative
+          number.  This causes the output to be right-justified within
+          the format width.
+
+
+
+
+
+
+
+
+                                January 25, 1991
+
+
+
+
+
+          Changes for MH 6.7.1a                                     14
+
+
+
+          _O_t_h_e_r _C_h_a_n_g_e_s
+
+          Along with a few minor enhancements, some  bugs  were  fixed
+          which in general were not user-visible:
+
+          fmtdump  This  new  program  produces   an   pseudo-language
+                   representation of an _M_H format file, vaguely remin-
+                   iscent of assembly  language.   While  this  output
+                   format  is  not explicitly documented, it can still
+                   be useful when debugging _M_H format files.
+
+          refile   Now takes a `-[no]rmmproc' switch.  This  makes  it
+                   easier to avoid loops when your "rmmproc" calls _r_e-
+                   _f_i_l_e.
+
+          slocal   A  problem  with  the  UUCP-style  mailboxes,   the
+                   `RPATHS'  configuration  option,  and  the "Return-
+                   Path:" header was fixed.
+
+          sortm    Will ensure that no messages are lost if it is  in-
+                   terrupted.
+
+          whatnow  Will now tell you where it is  leaving  the  draft,
+                   when  interrupted  in the initial edit.  Previously
+                   the draft was simply unlinked.
+
+          _C_o_m_p_i_l_a_t_i_o_n _O_p_t_i_o_n_s
+
+          LOCKF    This option causes _M_H to  use  the  lockf()  system
+                   call   for   locking  (if  available),  instead  of
+                   flock().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                January 25, 1991
+
+
+
+
+
+          Changes for MH 6.7.1                                      15
+
+
+          _C_H_A_N_G_E_S _F_O_R _M_H _6._7._1
+
+          The MH.6.7.1 patch release is a maintenance release, and as
+          such, provides few changes from the previous release.  This
+          is the current released version of _M_H as of December 14,
+          1990.
+
+          _U_s_e_r-_V_i_s_i_b_l_e _C_h_a_n_g_e_s
+
+          The major change in this release is to the POP daemon
+          (popd).  In _M_H 6.7, it was changed to be able to read both
+          UUCP and MMDF-style mailboxes.  This did not work as
+          reported.  The code has now been changed to parse MMDF-style
+          mailboxes if you are configuring MH to run with MMDF as your
+          message transport system.  Otherwise, UUCP-style mailboxes
+          are expected.
+
+               Since there are number of client programs available for
+          only the POP2 protocol instead of POP3, popd has been
+          updated to support both protocols.  This is a major win.  If
+          you are compiling with POP turned on, add the `POP2' option
+          to your _M_H config file, and the POP daemon will respond to
+          POP2 or POP3 commands.  If you're using POP, there's no rea-
+          son not to include this option; it does not affect the
+          existing support for POP3.
+
+          _I_n_t_e_r_n_a_l _C_h_a_n_g_e_s
+
+          Some bugs were fixed which in general were not user-visible:
+
+          context     Errors when writing out sequences  are  detected
+                      correctly.
+
+          inc         No longer inserts extra blank  lines  into  mes-
+                      sages.
+
+          mh-format   A nil pointer bug  in  the  address  parser  was
+                      fixed.
+
+          repl, etc.  The malloc/free problem has been fixed.
+
+          rmf         A spelling error in the `-nointeractive'  switch
+                      has been corrected.
+
+          rcvtty      Will not print the message size if not available
+                      (i.e., zero).
+
+          send/post   Illegal signatures  (those  containing  unquoted
+                      "."s) will be quoted.
+
+
+
+
+
+
+
+
+                               December 14, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      16
+
+
+          _G_E_N_E_R_A_L _C_H_A_N_G_E_S _F_O_R _M_H _6._7._0
+
+          The author is pleased to announce that there are very few
+          user-visible changes to _M_H 6.7 from the previous _M_H 6.6 dis-
+          tribution.  The majority of development was in the form of
+          bug fixes and slight enhancements.  In addition, this
+          release is slightly faster than the previous release.  With
+          a few minor exceptions, it is backward-compatible with the
+          previous release.  _M_H 6.7.0 is the current released version
+          of _M_H as of April 12, 1990.
+
+               The changes were made mainly to generalize the source
+          code to be compatible with a larger range of systems and
+          compilers.  There were many small changes to add declara-
+          tions for ANSI C compliance.  The System 5 support has been
+          brought up to SYS5 R3, and there is support for Sun OS 4.0.
+
+          _U_s_e_r-_V_i_s_i_b_l_e _C_h_a_n_g_e_s
+
+          Here a quick summary of the changes that were made which are
+          not backward-compatible with the previous release of _M_H:
+
+          repl   The `-format' and `-noformat' switches have not been
+                 functional since _M_H 5, and have been removed.  Any
+                 users who have these switches in their .mh_profile,
+                 will have to remove them.
+
+          sortm  Previously, in most cases _s_o_r_t_m would fill-in any
+                 gaps in the numbering of a folder, by renumbering the
+                 messages starting with `1'.  This will no longer
+                 occur; for this behavior, use "folder -pack".
+
+
+          _U_s_i_n_g _A_l_i_a_s_e_s
+
+          A new profile entry `Aliasfile:' has been added.  The _a_l_i,
+          _s_e_n_d, and _w_h_o_m programs will look for this profile entry and
+          treat it as they would an argument to `-alias'.  This should
+          make it easier for novice _M_H users to begin using aliases.
+
+
+          _R_e_a_d_i_n_g _N_e_t_w_o_r_k _N_e_w_s & _B_B_o_a_r_d_s
+
+          The UCI BBoards facility can read local BBoards, and if com-
+          piled with the `bboards: pop' and `pop: on' options, can
+          also read remote BBoards using the Post Office Protocol (POP
+          ver. 3).  With this release, _M_H can instead be compiled to
+          read the Network News (i.e., USENET) using the Network News
+          Transfer Protocol (NNTP).
+
+               This capability is enabled by compiling _M_H with the
+          `bboards: nntp' and `pop: on' options.  Unfortunately, read-
+          ing remote BBoards via the POP and reading the Network News
+          via the NNTP are mutually exclusive options.
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      17
+
+
+               To support the NNTP, a new module, uip/pshsbr.c, is
+          compiled and loaded into _b_b_c and _m_s_h instead of
+          uip/popsbr.c.  The default BBoard is changed from "system"
+          to "general" for the NNTP.
+
+               When reading BBoards, _b_b_c will first look for local
+          BBoards, and then contact the NNTP server to read the Net-
+          work News.  The location of the NNTP server should be speci-
+          fied with the `nntphost:' entry in the mtstailor file (see
+          the _M_H Administrator's Guide for details), or may be speci-
+          fied on the command line with the `-host' switch.
+
+
+          _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+          The manual page _m_h-_f_o_r_m_a_t (5) has been rewritten to give a
+          better explanation of how to write format strings, and how
+          they are interpreted by _M_H.  A line-by-line description of
+          the default _r_e_p_l form file (replcomps) is now included in
+          that manual page.
+
+          Some new format functions were added, and others  were  aug-
+          mented:
+
+          trim        Strips any leading and trailing white-space from
+                      the current string value.
+
+          date2local  Will coerce the date to the local timezone.
+
+          date2gmt    Will coerce the date to GMT.
+
+          divide      Divides the current numeric value by  its  argu-
+                      ment.   This  could  be useful for building _s_c_a_n
+                      format strings which print large  message  sizes
+                      in "Kb" or "Mb".
+
+          friendly    If the address  field  cannot  be  parsed,  this
+                      function  will  return  the  text of the address
+                      header, instead of a null string.
+
+          szone       A flag indicating whether the timezone  was  ex-
+                      plicit in the date string.
+
+          _P_R_O_G_R_A_M _C_H_A_N_G_E_S
+
+          In addition to the general changes mentioned above, many
+          programs have specific new features added, either by new
+          switches or by expanded functionality.  Each command's
+          manual page gives complete information about its new
+          options.  Here is a short summary.
+
+          _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+          anno      Accepts a `-nodate' switch which inhibits the date
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      18
+
+
+                    annotation, leaving only the body annotation.
+
+          folder    When invoked with the `-pack' switch and the new
+                    `-verbose' switch, _f_o_l_d_e_r will give information
+                    about the actions taken to renumber the folder.
+
+                    On most systems, _f_o_l_d_e_r can now create any
+                    non-existing parent folders of a new sub-folder.
+
+          forw      When making digests, _f_o_r_w will put the issue and
+                    volume numbers in addition to the digest list
+                    name, in the digest trailer.
+
+          inc       Detects NFS write failures, and will not zero your
+                    maildrop in that event.
+
+          msh       Supports a variant of the new _s_o_r_t_m.
+
+          prompter  Considers a period on a line by itself to signify
+                    end-of-file when the `-doteof' switch is speci-
+                    fied.
+
+          repl      The `-[no]format' switches have not been used
+                    since _M_H 5 and have been deleted. _r_e_p_l will now
+                    find filter files in the _M_H library area.
+
+          scan      With the `-file msgbox' switch, _s_c_a_n can list a
+                    _p_a_c_k_f'd-format file directly (without using _m_s_h).
+
+                    Lists messages in reverse order with the
+                    `-reverse' switch.  This should be considered a
+                    bug.
+
+          sortm     Now has the options: `-textfield field', `-notext-
+                    field', `-limit days', and `-nolimit'.
+
+                    With these options, _s_o_r_t_m can be instructed to
+                    sort a folder based on the contents of an arbi-
+                    trary header such as "subject".
+
+                    _s_o_r_t_m minimizes renaming messages, and will no
+                    longer arbitrarily pack folders; for this
+                    behavior, use "folder -pack".
+
+          whatnow   Deletes the draft by renaming it with leading
+                    comma, instead of unlinking it.
+
+          _M_H _S_u_p_p_o_r_t _P_r_o_g_r_a_m_s
+
+          The following support programs also have changes or enhance-
+          ments:
+
+          mhl     Will now accept a format string  on  any  component,
+                  not just on addresses and dates.
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      19
+
+
+          popd    Will use _s_h_a_d_o_w passwords if compiled with the SHA-
+                  DOW option.  It can now also read UUCP-style mail-
+                  drops directly.
+
+          rcvtty  If given no arguments, _r_c_v_t_t_y will produce a scan
+                  listing as specified by a format string or file; a
+                  default format string is used if one is not speci-
+                  fied.
+
+                  Before the listing is written to the users terminal,
+                  the terminal's bell is rung and a newline is output.
+                  The `-nobell' and the `-nonewline' options inhibit
+                  these functions.
+
+                  _r_c_v_t_t_y will obey terminal write notification set by
+                  _m_e_s_g.  With the `-biff' switch, _r_c_v_t_t_y will also
+                  obey the mail notification status set by _b_i_f_f.
+
+                  On BSD43 systems, as with _w_r_i_t_e, _r_c_v_t_t_y will be
+                  installed set-group-id to the group "tty".
+
+          slocal  Understands UUCP-style "From " lines and will write
+                  output files using this format if appropriate.
+                  Before invoking a delivery program, _s_l_o_c_a_l will
+                  strip such lines unless compiled with the RPATHS
+                  option, in which case it will will convert such
+                  lines into "Return-Path:" headers.
+
+                  _s_l_o_c_a_l has a new result code "N", for use in .mail-
+                  delivery files.  With this result code, _s_l_o_c_a_l will
+                  perform the action only if the message has not been
+                  delivered and the previous action succeeded.  This
+                  allows for performing an action only if multiple
+                  conditions are true.
+
+          _D_O_C_U_M_E_N_T_A_T_I_O_N
+
+          Several of the older _M_H papers have been difficult to format
+          because they depended on an older version of PhDTeX which
+          was not supplied.  These papers have been updated, and some
+          TeX library files are supplied in papers/doclib/, so that
+          these papers may be generated on any system with TeX.
+
+               Many of the manual pages have been revised to include
+          documentation of new command options, and some have been
+          expanded to give more detail.  All are now slightly refor-
+          matted at installation time to make them more compatible
+          with programs like _m_a_k_e_w_h_a_t_i_s.
+
+
+          _M_H _A_D_M_I_N_I_S_T_R_A_T_I_O_N
+
+          This section describes changes in configuring, compiling and
+          installing _M_H 6.7 and should not be of interest to casual _M_H
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      20
+
+
+          users.  The READ-ME file has been considerably revised and
+          expanded to give more detail about the configuration and
+          compilation options which have been included in this
+          release.  Some compilation options have been removed, and
+          many new options have been added.
+
+               All _M_H Makefiles have been updated to work around some
+          incompatibilities introduced in newer versions of _m_a_k_e.  _M_H
+          programs will no longer be installed with the sticky-bit
+          turned on.
+
+               Reading this section not a substitute for carefully
+          reading the READ-ME file before attempting to compile _M_H
+
+
+          _B_u_g _F_i_x_e_s
+
+          Some bugs were fixed which in general were not user-visible:
+
+          address parser  Fixed to allow use of the "AT"  domain,  and
+                          some minor bugs were fixed pertaining to ad-
+                          dress groups.
+
+          date parser     Improved to accept  more  forms  of  illegal
+                          dates.  Military timezones were removed.
+
+          dynamic memory  Many problems with corruption of the dynamic
+                          memory pool have been fixed.
+
+          locking         Will open files for write, if  necessary  to
+                          enable locking.
+
+          nil pointers    All reported nil pointer problems have  been
+                          fixed.
+
+          replcomps       The "In-Reply-To:" header had  quotes  added
+                          around the date field to comply with RFC822.
+
+          _W_h_i_t_e _P_a_g_e_s
+
+          If _M_H is compiled with the WP option, _s_e_n_d recognizes an
+          address between "<<" and ">>" characters such as:
+
+                  To: << rose -org psi >>
+
+          to be a name meaningful to a whitepages service.  In order
+          to expand the name, _s_e_n_d must be invoked interactively
+          (i.e., not from _p_u_s_h).  For each name, _s_e_n_d will invoke a
+          command called _f_r_e_d in a special mode asking to expand the
+          name.
+
+               To get a copy of the white pages service, contact
+          wpp-manager@psi.com.
+
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      21
+
+
+          _C_o_n_f_i_g_u_r_a_t_i_o_n _O_p_t_i_o_n_s
+
+          Some configuration options have been added or changed:
+
+          cc          To specify an alternate C compiler.
+
+          ccoptions   Defaults to `-O'.
+
+          bboards     May now be defined as "on", "off", "pop", or
+                      "nntp".
+
+          bbdelivery  Determines whether the bboard delivery agent and
+                      library files should be installed.
+
+          lex         To specify an alternate version of _l_e_x.
+
+          mailgroup   If defined, _i_n_c will be made set-group-id to
+                      this group.
+
+          sharedlib   For SUN40 systems; if "on", makes libmh.a into a
+                      shared library.
+
+          slibdir     The directory where the above shared library
+                      should be installed.
+
+          sprintf     Set this to "int" if that's what your
+                      _s_p_r_i_n_t_f (3) library routine returns.
+
+          _C_o_m_p_i_l_a_t_i_o_n _O_p_t_i_o_n_s
+
+          For different configurations, several `-D' options to _c_c
+          have been added or changed:
+
+          BERK        This disables the address and date parsing rou-
+                      tines.  If you want to do much with
+                      _m_h-_f_o_r_m_a_t (5), don't enable this.
+
+          BSD43       Will make _r_c_v_t_t_y set-group-id to the group
+                      "tty".
+
+          DBM         For sites with a dbm-style password file (such
+                      as with Yellow Pages), _M_H will not read the
+                      entire passwd file into a cache.  At one site
+                      that runs YP on a large passwd file, using this
+                      showed a 6:1 performance improvement.
+
+          NETWORK     This option has been deleted.  See SOCKETS.
+
+          NOIOCTLH    Tells _M_H not to include the file sys/ioctl.h.
+                      Use this if this file is not present on your
+                      system.
+
+          NTOHLSWAP   On systems with TCP/IP networking, _m_s_h will try
+                      to use the ntohl() macro from the file
+
+
+
+                                 April 12, 1990
+
+
+
+
+
+          Changes for MH 6.7.0                                      22
+
+
+                      netinet/in.h to byte-swap the binary map files
+                      it writes.
+
+          SENDMAILBUG Some versions of _s_e_n_d_m_a_i_l return a 451 (failure)
+                      reply code when they don't mean to indicate
+                      failure.  This option considers that code to be
+                      equivalent to 250 (OK).
+
+          SHADOW      Causes _p_o_p_d to read the file /etc/shadow for
+                      encrypted passwords instead of /etc/passwd.  Use
+                      this if you have a shadow password file (such as
+                      on newer versions of SYSTEM 5).
+
+          SOCKETS     Enable this if you are on a non-BSD system with
+                      a socket interface for TCP/IP networking compa-
+                      tible with 4.2BSD UNIX.
+
+          SUN40       Use on Suns running Sun OS 4.0 and later.
+
+          SYS5        This option has been updated to refer to SYS5 R3
+                      and later systems.
+
+          SYS5DIR     Use this if your system uses "struct dirent"
+                      instead of "struct direct".  This should be true
+                      for systems based on SYS5 R3 and later.
+
+          TYPESIG     Defines the base type for the _s_i_g_n_a_l system
+                      call.  This defaults to "int", but should be
+                      defined as "void" if appropriate for your sys-
+                      tem.
+
+          WP          Enables support for the White Pages service.
+
+          _I_n_s_t_a_l_l_a_t_i_o_n
+
+          _M_H will now explicitly set the protection mode on every file
+          it installs.
+
+               Previously any existing file installed by _M_H would be
+          backed up into the source tree, and then overwritten.  Now,
+          a few system-dependent files will not be overwritten, and
+          your changes will have to be merged in by hand.  See the
+          READ-ME file for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 April 12, 1990
+
+
diff --git a/docs/historical/designOfMH.pdf b/docs/historical/designOfMH.pdf
new file mode 100644
index 0000000..bf86e4f
Binary files /dev/null and b/docs/historical/designOfMH.pdf differ
diff --git a/docs/historical/mh-gen.pdf b/docs/historical/mh-gen.pdf
new file mode 100644
index 0000000..d71cd7d
Binary files /dev/null and b/docs/historical/mh-gen.pdf differ
diff --git a/docs/historical/mh-gen.txt b/docs/historical/mh-gen.txt
new file mode 100644
index 0000000..6c7f755
--- /dev/null
+++ b/docs/historical/mh-gen.txt
@@ -0,0 +1,1452 @@
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+NAME
+     mh-gen - generating the MH system
+
+READ THIS
+     This documentation describes how to configure, generate, and
+     install the UCI version of the RAND _M_H system.  Be certain
+     to read this document completely before you begin.  You
+     probably will also want to familiarize yourself with the _M_H
+     Administrator's Guide before you install _M_H.  A copy can be
+     found in the file doc/ADMIN.doc is the _M_H sources.
+
+DISCLAIMER
+     Although the _M_H system was originally developed by the RAND
+     Corporation, and is now in the public domain, the RAND Cor-
+     poration assumes no responsibility for _M_H or this particular
+     modification of _M_H.
+
+     In addition, the Regents of the University of California
+     issue the following disclaimer in regard to the UCI version
+     of _M_H:
+          "Although each program has been tested by its contribu-
+          tor, no warranty, express or implied, is made by the
+          contributor or the University of California, as to the
+          accuracy and functioning of the program and related
+          program material, nor shall the fact of distribution
+          constitute any such warranty, and no responsibility is
+          assumed by the contributor or the University of Cali-
+          fornia in connection herewith."
+
+     This version of _M_H is in the public domain, and as such,
+     there are no real restrictions on its use.  The _M_H source
+     code and documentation have no licensing restrictions what-
+     soever.  As a courtesy, the authors ask only that you pro-
+     vide appropriate credit to the RAND Corporation and the
+     University of California for having developed the software.
+
+GETTING HELP
+     _M_H is a software package that is neither supported by the
+     RAND Corporation nor the University of California.  However,
+     since we do use the software ourselves and plan to continue
+     using (and improving) _M_H, bug reports and their associated
+     fixes should be reported back to us so that we may include
+     them in future releases.  The current computer mailbox for
+     _M_H is Bug-MH@ICS.UCI.EDU (in the ARPA Internet), and
+     ...!ucbvax!ucivax!bug-mh (UUCP).
+
+     Presently, there are two Internet discussion groups,
+     MH-Users@ICS.UCI.EDU and MH-Workers@ICS.UCI.EDU.  MH-Workers
+     is for people discussing code changes to _M_H.  MH-Users is
+     for general discussion about how to use _M_H.  MH-Users is
+     bi-directionally gatewayed into USENET as comp.mail.mh.
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                     1
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+HOW TO GET MH
+     Since you probably already have _M_H, you may not need to read
+     this unless you suspect you have an old version.  There are
+     two ways to get the latest release:
+
+     1.  If you can FTP to the ARPA Internet, use anonymous FTP
+     to ftp.ics.uci.edu [128.195.1.1] and retrieve the file
+     pub/mh/mh-6.8.tar.Z.  This is a tar image after being run
+     through the compress program (approximately 1.8MB).  There
+     should also be a README file in that directory which tells
+     what the current release of _M_H is, and how to get updates.
+
+     This tar file is also available on louie.udel.edu
+     [128.175.1.3] in portal/mh-6.8.tar.Z.  You may also find MH
+     on various other hosts; to make sure you get the latest ver-
+     sion and don't waste your time re-fixing bugs, it's best to
+     get it from either ftp.ics.uci.edu or louie.udel.edu.
+
+     2.  You can send $75 US to the address below.  This covers
+     the cost of a 6250 BPI 9-track magtape, handling, and ship-
+     ping.  In addition, you'll get a laser-printed hard-copy of
+     the entire MH documentation set.  Be sure to include your
+     USPS address with your check.  Checks must be drawn on U.S.
+     funds and should be made payable to:
+
+               Regents of the University of California
+
+     The distribution address is:
+
+               Univeristy of California at Irvine
+               Office of Academic Computing
+               360 Computer Science
+               Irvine, CA  92717  USA
+
+               +1 714 856 5153
+
+     Sadly, if you just want the hard-copies of the documenta-
+     tion, you still have to pay the $75.  The tar image has the
+     documentation source (the manual is in roff format, but the
+     rest are in TeX format).  Postscript formatted versions of
+     the TeX papers are available, as are crude tty-conversions
+     of those papers.
+
+SYNOPSIS
+     MAKE
+
+DESCRIPTION
+     This is a description of how one can bring up an _M_H system.
+     It is assumed that you have super-user privileges in order
+     to (re-)install _M_H.  Super-user privileges are not required
+     to configure or generate _M_H.
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                     2
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     Become the super-user and cd to /usr/src/local/ (or whatever
+     you keep your local sources).  The distribution tape con-
+     tains the hierarchy for the mh.6-8/ directory.  Bring the
+     sources on-line:
+
+     # cd /usr/src/local
+     % tar xv
+     % cd mh-6.8
+
+CONFIGURATION
+     First, go to the conf/ directory.
+
+     % cd conf/
+
+     This directory contains files that will produce source files
+     tailored for your choice of _M_H configuration.  You should
+     edit only the file MH.  This file contains configuration
+     directives.  These configuration directives are read by the
+     _m_h_c_o_n_f_i_g program to produce customized files.
+
+     For examples of various configurations, look in the direc-
+     tory conf/examples/.  The file MH provided in conf/ is a
+     reasonable default.  Lines beginning with `#' are comments,
+     and are not otherwise interpreted.
+
+     Here are the _M_H configuration directives available.  Be sure
+     to read through this list completely before attempting to
+     decide what directives are appropriate for your system.
+
+     More information on some of these options is available in
+     the the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.  If you do not have a printed
+     copy, you should configure your system with the default con-
+     figuration file, MH, then generate and print a copy of the
+     guide (as described below).
+
+  Installation paths
+     bin: /usr/local
+          The directory where user-invoked programs go (see
+          manual section 1).
+
+     etc: /usr/local/lib/mh
+          The directory where pgm-invoked programs go (see manual
+          section 8).
+
+     mail: /usr/spool/mail
+          The directory where the maildrops are stored.  If this
+          pathname is absolute (i.e., begins with a / ), then the
+          user's maildrop is a file called $USER in this direc-
+          tory.  If the pathname is not absolute, then the user's
+          maildrop is in the user's home directory under the
+          given name.
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                     3
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     mandir: /usr/man
+          The parent directory of the manual entries.
+
+     manuals: standard
+          Where manual entries should be installed, relative to
+          the directory given with "mandir".  Either "local" to
+          install manual entries under manl/, or "new" to install
+          manual entries under mann/, or "old" to install manual
+          entries under mano/, or "standard" to install manual
+          entries under man?/, or "bsd44" to install manual
+          entries as man?/_p_a_g_e.0, or "gen" to generate but not
+          install them, or "none" to neither generate nor install
+          them.
+
+          Any of these values may have the suffix "/cat" appended
+          to it.   In that case, the manual entries will be for-
+          matted with "nroff -man" and they will be installed in
+          the corresponding "cat?" directories.
+
+          For example, to install manual entries under
+          /usr/man/u_man/man?, use "standard" and /usr/man/u_man
+          for "mandir".  To install formatted manual entires
+          under /usr/contrib/man/cat?, use "standard/cat" and
+          /usr/contrib/man for "mandir".  To install formatted
+          manual entries using the BSD44 convention, use
+          "bsd44/cat".
+
+     chown: /etc/chown
+          The location of the _c_h_o_w_n(8) on your system.  If _c_h_o_w_n
+          is in your search path, just use the value of "chown".
+          On SYS5 systems, this should probably be "/bin/chown".
+
+     cp: cp
+          The command to copy files when installing, if not "cp".
+          (Some sites use "cp -p".)
+
+     ln: ln
+          The command to link files together in the source tree,
+          if not "ln".  If you're using something like lndir to
+          keep your compile tree separate from your source tree,
+          set this to "ln -s" or "cp".
+
+     remove: mv -f
+          How _M_H should make backup copies of existing files when
+          installing new files.  To simply remove the old files,
+          use "rm -f".
+
+  Compiler/loader
+     cc: cc
+          The name of your C compiler, if not "cc".
+
+     ccoptions: -O
+
+
+
+[mh.6]                Last change: MH.6.8.3                     4
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+          Options given directly to _c_c(1).  The most common is
+          "-M" if you're running _M_H on an ALTOS.  This defaults
+          to "-O".  If you define this and want to keep "-O", be
+          sure to include it explicitly.  If you're using the _G_N_U
+          C compiler, it should include `-traditional'.  See
+          "options:" for `-D' options.
+
+     curses: -lcurses -ltermlib
+          This should be the loader option required to load the
+          _t_e_r_m_c_a_p(3) and _c_u_r_s_e_s(3) libraries on your system.  On
+          SYS5 systems, it probably should be just "-lcurses".
+          Some sites have reported that both "-lcurses" and
+          "-ltermlib" are necessary.
+
+     ldoptions: -s
+          Options given directly to _l_d(1) (via _c_c) at the begin-
+          ning of the command line.  Useful for machines which
+          require arguments to tell _l_d to increase the stack
+          space (e.g. the Gould, which uses "-m 8").  Usually,
+          "-s" is a good choice in any event.
+
+     ldoptlibs:
+          Options given directly to _l_d(1) (via _c_c) at the end of
+          the command line.  The two most common are: "-ldbm" if
+          you're running MMDF with the _d_b_m package; and, "-lndir"
+          if you are generating _M_H on a system which does not
+          load the new directory access mechanism by default
+          (e.g., 4.1BSD, SYS5).  If you don't have _l_i_b_n_d_i_r on
+          your system, the sources are in miscellany/libndir/.
+
+     lex: lex -nt
+          Alternative version of _l_e_x.  Used in zotnet/tws/.
+
+     oldload: off
+          This controls how _M_H will try to process library object
+          files to eliminate local symbols.  Support for the
+          ALTOS loader if "on".  Support for loaders not handling
+          `-x -r' correctly if "none".
+
+     ranlib: on
+          Support for systems with _r_a_n_l_i_b(1).  For SYSTEM 5 sys-
+          tems, this should be "off" which tells _M_H to use _l_o_r_d_e_r
+          and _t_s_o_r_t instead.  Some SYSTEM 5 sites reported that
+          running this isn't always sufficient.  If this is the
+          case, then you should edit conf/makefiles/uip to
+          include ../sbr/libmh.a and ../zotnet/libzot.a twice in
+          the LIBES variable.
+
+  Message Transport System
+     mts: sendmail
+          Which message transport system to use.  Either "mmdf"
+          to use _M_M_D_F as the transport system, "mmdf2" to use
+
+
+
+[mh.6]                Last change: MH.6.8.3                     5
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+          _M_M_D_F-_I_I as the transport system, "sendmail" to have
+          _S_e_n_d_M_a_i_l as the transport system, "zmailer" to have
+          _Z_M_A_I_L_E_R as the transport system, or, "mh" to have _M_H as
+          the transport system.
+
+          On UNIX systems supporting TCP/IP networking via sock-
+          ets you can add the suffix "/smtp" to the mts setting.
+          This often yields a superior interface as _M_H will post
+          mail with the local _S_M_T_P server instead of interacting
+          directly with _M_M_D_F or _S_e_n_d_M_a_i_l.  Hence, for TCP/IP UNIX
+          systems, the "/smtp" suffix to either "sendmail" or
+          "mmdf2" is the preferred MTS configuration.  The
+          "/smtp" suffix is described in detail in the
+          _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e; be sure to set "servers:" as
+          described in _m_h-_t_a_i_l_o_r(8) if you use this option.
+
+     mf: off
+          Support for mail filtering on those systems in which
+          the message transport system isn't integrated with _U_U_C_P
+          This option is strictly for an _M_H system using either
+          _M_M_D_F-_I as its transport system or one using
+          "stand-alone delivery".
+
+  UCI BBoards Facility
+     bboards: off
+          If "on", include support for the UCI BBoards facility.
+          BBoards may be enabled with any mts setting.  If "off",
+          the BBoard reading program _b_b_c will not be installed.
+          If "nntp", include support for the UCI BBoards facility
+          to read the Network News via the NNTP.  If "pop" (form-
+          erly "popbboards: on"), include support for the UCI
+          BBoards facility via the POP3 service; this setting
+          requires "pop: on".
+
+     bbdelivery: off
+          If "off", the BBoards delivery agent and library files
+          will not be installed.  If "on", and you set "bboards:"
+          to something besides "off", then the BBoards delivery
+          agent and library files will be installed in the _b_b_h_o_m_e
+          directory (see below).  To read remote BBoards, the
+          usual configuration would have _b_b_c talk to a _P_O_P_3 or
+          _N_N_T_P server.  However, it may be useful to set this to
+          "off" if you NFS mount the _b_b_h_o_m_e directory from
+          another host and want to use _b_b_c to read those files
+          directly.
+
+     bbhome: /usr/spool/bboards
+          The home directory for the BBoards user.
+
+
+
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                     6
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+  Post Office Protocol
+     pop: off
+          Support for POP service.  This allows local delivery
+          for non-local users (a major win).  See
+          support/pop/pop.rfc for more information on the POP.
+          This option currently works only on UNIX systems with
+          TCP/IP sockets.  (It doesn't hurt to enable this option
+          regardless of whether or not you intend to use POP.)
+          See also "bboards: pop" to enable reading bboards with
+          the POP.
+
+     popdir: /usr/etc
+          The directory where the POP daemon (popd) will be
+          installed.
+
+     options:
+          `-D' options to _c_c(1).
+
+       APOP='"/etc/pop.auth"'
+            This option indicates that the POP daemon will sup-
+            port the non-standard APOP command, and specifies the
+            name of APOP authorization database.  The APOP com-
+            mand provides a challenge-based authentication system
+            using the MD5 message digest algorithm.  This facil-
+            ity is documented in _T_h_e _I_n_t_e_r_n_e_t _M_e_s_s_a_g_e (ISBN
+            0-13-092941-7), a book by Marshall T. Rose.
+
+            This option also causes the popauth program to be
+            installed, which allows the administrator to manipu-
+            late the APOP authorization database.  For more
+            details, see support/pop/pop-more.txt and the
+            _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.
+
+       DPOP
+            This option indicates that POP subscribers do not
+            have entries in the _p_a_s_s_w_d(5) file, and instead have
+            their own separate database (a win).
+
+       KPOP
+            Support for KERBEROS with POP.  This code builds
+            _p_o_p_d, _i_n_c and _m_s_g_c_h_k to support only the "kpop" pro-
+            tocol.  This code is still experimental, but is
+            available for those sites wishing to test it.
+
+       MPOP
+            This option indicates that the POP daemon will sup-
+            port the non-standard XTND SCAN command which pro-
+            vides performance enhancements when using the POP
+            over low-speed connections.  This option also causes
+            an interactive POP client program, popi, to be com-
+            piled and installed.  A man page for the popi program
+            is also provided.
+
+
+
+[mh.6]                Last change: MH.6.8.3                     7
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+            These extensions are described in _T_h_e _I_n_t_e_r_n_e_t _M_e_s_-
+            _s_a_g_e, a book by Marshall T. Rose.  For more details,
+            see support/pop/pop-more.txt.  Note: this option
+            requires "bboards: pop".
+
+       POP2
+            Have the POP daemon understand the older POP2 proto-
+            col as well as the _M_H POP3 protocol - a major win.
+            The POP daemon auto-magically determines which POP
+            protocol your client is using.  If you're enabling
+            POP service, there's no reason not to enable this
+            option as well.  See also _P_O_P_S_E_R_V_I_C_E.
+
+       POPSERVICE
+            The port name the _M_H POP will use.  For historical
+            reasons, this defaults to "pop".
+
+            In 1987, the _M_H POP protocol (POP version 3) was pub-
+            lished as RFC1081 and was assigned its own port
+            number (110), which differs from the original POP
+            (version 1 and 2) port number (109).
+
+            To have _M_H POP use the new assigned port number, set
+            POPSERVICE='"pop3"', and be sure that this service
+            name is listed in your /etc/services file on both POP
+            client and server hosts as "110/tcp".  If you enable
+            _P_O_P_2, you can safely leave _P_O_P_S_E_R_V_I_C_E undefined
+            unless you are using POP3 clients besides _M_H.
+
+       RPOP
+            This option indicates that support for the UNIX vari-
+            ant of POP, RPOP, which uses privileged sockets for
+            authentication be enabled.  This peacefully co-exists
+            with the standard POP.
+
+       SHADOW
+            Indicates that the popd POP server can find encrypted
+            passwords in the /etc/shadow file (and not in the
+            /etc/passwd file).  It should be used only for some
+            (newer) SYSTEM 5 systems.
+
+         The "APOP" and "MPOP" non-standard POP facilities are
+         documented in _T_h_e _I_n_t_e_r_n_e_t _M_e_s_s_a_g_e (ISBN 0-13-092941-7),
+         a book by Marshall T. Rose.  For more details, see
+         support/pop/pop-more.txt.  The "APOP" option peacefully
+         co-exists with the standard POP.  The "MPOP" option
+         requires "bboards: pop".
+
+ Shared libraries
+    sharedlib: off
+         If "sun4", makes libmh.a into a SunOS 4.0 (and later)
+         shared library.  If you enable this, be sure to also use
+
+
+
+[mh.6]                Last change: MH.6.8.3                     8
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+         "options SUN40".  If "sys5", makes libmh.a into a SYS5
+         R4 (and later) shared library.  If you enable this, be
+         sure to also use "options SVR4".
+
+    slflags: -pic
+         The compiler flags to produce position independent code.
+
+    slibdir: /usr/local/lib
+         The directory where the _M_H shared library should go.
+
+      Under SunOS (sun4)
+         Since some _M_H programs are setuid, they'll only look for
+         the library in "trusted" locations.  Putting the library
+         somewhere besides /usr/lib or /usr/local/lib is not
+         advisable.
+
+         If you must do this, be sure that you add the path given
+         by slibdir to the compiler's library search list (e.g.,
+         "ldoptions: -L/usr/mh/lib") and make sure the path
+         starts with a leading `/'.
+
+         You may need to run _l_d_c_o_n_f_i_g(8) manually whenever a new
+         shared object is installed on the system.  See _l_d(1) for
+         more information about using shared libraries.
+
+      Under Solaris 2.0 (and newer)
+         The above instructions for SunOS apply, except you
+         should set the run-time library search path using `-R'
+         instead of `-L' (e.g., "ldoptions: -R/usr/mh/lib").
+
+ General System Dependencies
+    You should include the following directives which are
+    appropriate for your version of UNIX.  If you don't know what
+    an option does, it probably doesn't apply to you.
+
+    mailgroup: off
+         If set, _i_n_c is made set-group-id to this group name.
+         Some SYS5 systems want this to be set to "mail".  Set
+         this if your /usr/spool/mail is not world-writeable.
+
+         Note that slocal doesn't know how to deal with this, and
+         will not work under these systems; just making it set-
+         group-id will open a security hole.  If you're using
+         "mailgroup", you should remove slocal (and its man page)
+         from your system.
+
+    signal: int
+         The base type (int or void) of the function
+         parameter/return value of _s_i_g_n_a_l(2).  The default is
+         int.  Set "signal void" on systems which use this type
+         (e.g., SYSTEM 5 V3.0 and later or Sun OS 4.0 and later).
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                     9
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+    sprintf: char *
+         The return value of the _s_p_r_i_n_t_f library routine.  This
+         defaults to "char *".  Set this to "int" if you have an
+         older version of SYSTEM 5 which has this routine return
+         an "int" type.
+
+    options:
+         `-D' options to _c_c(1).
+
+      ALTOS
+           Use on XENIX/v7 systems.  Also, be sure to use
+           "options V7".
+
+      ATTVIBUG
+           This option causes _M_H to return to the "What now?"
+           prompt if your initial editor is vi and it exits with
+           non-zero status.  Use on Sun OS 4.1 and other systems
+           where the /usr/ucb/vi editor was changed to exit with
+           its status equal to the number of pseudo-"errors"
+           encountered during the edit.  This causes a problem
+           for programs that test the exit status of their editor
+           and abort if the status is non-zero.  (This includes
+           _M_H and programs like /usr/etc/vipw).
+
+      AUX
+           Use with AUX systems.
+
+      BIND
+           If you are running with the BIND code on UNIX systems
+           with TCP/IP sockets (e.g. 4.{2,3}BSD), be sure to
+           define this.
+
+      BSD41A
+           Use on 4.1a Berkeley UNIX systems.
+
+      BSD42
+           Use on Berkeley UNIX systems on or after 4.2BSD.
+
+      BSD43
+           Use on 4.3 Berkeley UNIX systems.  Also, be sure to
+           use "options BSD42".  If _o_p_e_n_l_o_g(3) (see "man 3 sys-
+           log") takes three arguments instead of two, and your
+           _w_r_i_t_e(1) command is set-group-id to group "tty", use
+           this option.  If only one of these conditions is true,
+           you lose.
+
+      BSD44
+           Use on Berkeley UNIX systems on or after 4.4BSD.
+           Also, be sure to use "options BSD43" and "options
+           BSD42".
+
+      DBMPWD
+
+
+
+[mh.6]                Last change: MH.6.8.3                    10
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+           Use this option if your _g_e_t_p_w_e_n_t(3) routines read a
+           dbm database (such as with Yellow Pages) instead of
+           doing a sequential read of /etc/passwd.  Without
+           DBMPWD the entire passwd file is read into memory one
+           entry at a time for alias expansion.  This is a per-
+           formance improvement when reading a standard
+           /etc/passwd file, but is _v_e_r_y slow on systems with a
+           dbm database.  At one site that runs YP on a large
+           passwd file, it showed a 6:1 performance improvement.
+
+      GCOS_HACK
+           The so-called "gcos" field of the password file is
+           used as a last resort to find the user's full name
+           (see _m_h-_p_r_o_f_i_l_e(5) for details).  Enable this option
+           if your _p_a_s_s_w_d(5) man page notes that the `&' charac-
+           ter in the "gcos" field stands for the login name.
+
+      FCNTL
+           Directs _M_H to use the fcntl() system call for kernel-
+           level locking.  If you're using a SYS5 system, you may
+           want this option.  (See also `FLOCK' and `LOCKF').
+
+      FLOCK
+           Directs _M_H to use the flock() system call for kernel-
+           level locking.  If you're on a BSD42 system, and
+           you're not using NFS to read or write maildrops, you
+           should enable this option.  (See also `FCNTL' and
+           `LOCKF').
+
+      HESIOD
+           Support for HESIOD. This code was contributed, and
+           included no documentation.
+
+      LOCKF
+           Directs _M_H to use the lockf() system call for kernel-
+           level locking.  If you're using NFS to read or write
+           maildrops, you should enable this option.  (See also
+           `FLOCK' and `FCNTL').
+
+      locname
+           Hard-wires the local name for the host _M_H is running
+           on.  For example, locname='"PICKLE"'.  It's probably
+           better to either let UNIX tell _M_H this information, or
+           to put the information in the host specific mtstailor
+           file.
+
+      MORE
+           Defines  the location of the _m_o_r_e(1) program.  On
+           ALTOS and DUAL systems, set MORE='"/usr/bin/more"'.
+           The default is "/usr/ucb/more".
+
+      NDIR
+
+
+
+[mh.6]                Last change: MH.6.8.3                    11
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+           For non-Berkeley UNIX systems, this _M_H will try to
+           find the new directory access mechanism by looking in
+           <ndir.h> if this option is given.  Otherwise, _M_H will
+           try <dir.h>.  If you still can't get this to work on
+           your system, edit h/local.h as appropriate.  (See also
+           `SYS5DIR'.)
+
+      NFS
+           Tells _M_H to hack around a problem in the NFS C
+           library.  If you get an undefined symbol "ruserpass"
+           when compiling _M_H, you probably need this option.  If,
+           however, you include this option and get an undefined
+           symbol "__ruserpass" when compiling, then you should
+           omit this option.  (See also `NORUSERPASS'.)
+
+      NOIOCTLH
+           Tells _M_H not to include the file <sys/ioctl.h>.  To be
+           used on systems where this file is not present.
+
+      NORUSERPASS
+           Tells _M_H that your system doesn't have the _r_u_s_e_r_-
+           _p_a_s_s(3) routine; _M_H will include its own copy of this
+           routine in its library.  (See also `NFS'.)
+
+      NTOHLSWAP
+           Tells _M_H to use the ntohl() macro when processing _m_s_h
+           binary map files.  _M_H can use this macro on systems
+           with the include file netinet/in.h, to byte-swap the
+           binary information in these map files.  If you're
+           using the same map files on machines of different
+           architectures, enable this option.
+
+      RENAME
+           Include this option if your system has a rename()
+           library call.  This is true on BSD42 and newer and
+           some SYS5 systems.
+
+      SENDMAILBUG
+           Causes SMTP reply code 451 (failure) to be considered
+           the same as code 250 (OK).  Since this might cause
+           problems, only enable this if you are certain that
+           your SendMail will return this code even when it
+           doesn't mean to indicate a failure.
+
+      SOCKETS
+           Indicates the availability of a socket interface for
+           TCP/IP networking that is compatible with 4.{2,3}BSD
+           UNIX.  It is not necessary to define this when BSD42
+           is already defined, but it might be useful for SYSTEM
+           5 or HPUX systems with TCP/IP sockets.
+
+      SUN40
+
+
+
+[mh.6]                Last change: MH.6.8.3                    12
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+           Use on Sun OS 4.0 (and later?) systems.  You also will
+           need "options BSD42", "options BSD43", and "signal
+           void".
+
+           If you're using Sun's brain-damaged approach to offer-
+           ing Domain Name Service through NIS, be sure to
+           include "options BIND" and "ldoptions -lresolv" to
+           work around some NIS/DNS bugs.
+
+      SYS5
+           Use on AT&T SYSTEM 5 R3 (and newer?) UNIX systems.
+           See also _m_a_i_l_g_r_o_u_p.
+
+      SYS5DIR
+           Define this if your system uses "struct dirent"
+           instead of "struct direct".  This is true of System V
+           Release 3.0 and later.  Uses include file <dirent.h>
+           and the routines _m_k_d_i_r, _r_m_d_i_r and _g_e_t_c_w_d.
+
+      SVR4
+           Use on AT&T SYSTEM 5 R4 (and newer?) UNIX systems. You
+           should also include "options SYS5" and "options
+           SYS5DIR".  See also _m_a_i_l_g_r_o_u_p.  You will also need to
+           include "oldload none" if your ld doesn't handle
+           `-x -r' correctly.
+
+      TERMINFO
+           Define TERMINFO if you have it.  You get it automati-
+           cally if you're running SYS5, and you don't get it if
+           you're not.  (If you're not SYS5, you probably have
+           termcap.)
+
+      TZNAME
+           Use time zone names from the _t_z_n_a_m_e variable, set via
+           _t_z_s_e_t.  Only applicable on SYSTEM 5 systems and only
+           effective when you have asked for alpha-timezones (see
+           the ATZ option).  See also ZONEINFO.
+
+      UNISTD
+           Include this option if your system has the file
+           <unistd.h>.  If not specified, the LOCKF option will
+           include <sys/fcntl.h>.
+
+      V7
+           Use on V7 UNIX systems.  Also, be sure to use "options
+           void=int".
+
+      VSPRINTF
+           Include this option if your system has the _v_s_p_r_i_n_t_f(3)
+           library routine; otherwise, __d_o_p_r_n_t(3) will be used.
+
+      WAITINT
+
+
+
+[mh.6]                Last change: MH.6.8.3                    13
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+           BSD42 based systems call the _w_a_i_t(2) system routine
+           with a pointer to type _u_n_i_o_n _w_a_i_t.  Include this
+           option if you included "options BSD42", but your sys-
+           tem calls the _w_a_i_t(2) system routine with a pointer to
+           type _i_n_t (the non-BSD42 default).
+
+      ZONEINFO
+           Specify this if you have a BSD43 based system that
+           keeps time zone information /etc/zoneinfo or
+           /usr/lib/zoneinfo (SunOS), and where the _s_t_r_u_c_t _t_m
+           returned by _l_o_c_a_l_t_i_m_e(3) contains a _t_m__g_m_t_o_f_f element
+           (see /usr/include/time.h).  With this fix the GMT
+           offset specified in outgoing mail will be corrected
+           when the TZ enviornment variable is set to a different
+           time zone.  See also TZNAME.
+
+Site Preferences
+   These options change the default behavior of _M_H or enable
+   optional features.  Add the options which are appropriate for
+   your configuration or your site preferences.
+
+   editor: prompter
+        The default editor for _M_H.
+
+   options:
+        `-D' options to _c_c(1).
+
+     ATZ
+          Directs _M_H to use alpha-timezones whenever possible.
+          You should not use this option if you are on the Inter-
+          net, since it will make your host non-compliant with
+          RFC-1123 (Requirements for Internet Hosts).
+
+     ATHENA
+          Makes _r_e_p_l `-nocc all' the default instead of
+          `-cc all'.  You may want to enable this if you're using
+          _x_m_h.
+
+     BANG
+          Directs _M_H to favor `!' over `@' in addressing.
+
+     BERK
+          Optional for for 4.{2,3}BSD sites running SendMail.
+          Disables nearly all of the RFC822 address and header-
+          parsing routines in favor of recognizing such formats
+          as ASCnet, and so on.  If you don't need to disable the
+          parser for this reason, you probably want to use
+          "options DUMB" instead.
+
+     COMPAT
+          If you previously ran a version of _M_H earlier than mh.4
+          use this option.  After a short grace period, remove it
+
+
+
+[mh.6]                Last change: MH.6.8.3                    14
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+          and re-{configure,generate,install} everything.
+
+     DUMB
+          Directs _M_H not to try and rewrite addresses to their
+          "official" form.
+
+     FOLDPROT
+          Defines the octal value for default folder-protection.
+          For example, FOLDPROT='"0700"'.  The default is "0711".
+
+     ISI
+          When using "repl -ccme", only "cc:" the first address
+          found which belongs to the user; any other _A_l_t_e_r_n_a_t_e-
+          _M_a_i_l_b_o_x_e_s do not receive "cc:"s.
+
+     LINK
+          Defines the filename for alternate file name for _d_i_s_t
+          and _r_e_p_l.  For example, LINK='"\\043"' to use the
+          pound-sign character.  The default is "@".
+
+     MHE
+          Enables crude support for Brien Reid's MHE interface.
+          Recommended for use with the GNU Emacs mh-e package.
+
+     MHRC
+          Enables _M_H to recognize the _C_S_h_e_l_l's `~'-construct.
+          This is useful for sites that run with a ~/.mhrc for
+          their users.
+
+     MIME
+          Enables support for multi-media messages, as specified
+          in RFC 1341 -- a major win.  This allows you to include
+          things like audio, graphics, and the like, in your mail
+          messages.  Several _M_H commands are extended to support
+          these multi-media messages, and the _m_h_n command is pro-
+          vided to encode and decode MIME messages.  For more
+          details, see miscellany/multi-media/READ-ME and _m_h_n(1).
+
+     MSGID
+          Enables slocal to detect and surpress duplicate mes-
+          sages received.  This code uses the <ndbm.h> library,
+          and requires "options BSD42" since it uses the _f_l_o_c_k(2)
+          system call for locking.  (Note that this means its
+          database locking does not work over NFS.) It has only
+          been tested under SUN40.
+
+     MSGPROT
+          Defines the octal value for default folder-protection.
+          For example, MSGPROT='"0600"'.  The default is "0644".
+
+     NOMHSEQ
+          Directs _M_H to make private sequences the default.
+
+
+
+[mh.6]                Last change: MH.6.8.3                    15
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     OVERHEAD
+          Enable _M_H commands to read profile/context from open
+          fd:s without doing an open(); see _m_h-_p_r_o_f_i_l_e(5) for the
+          details.
+
+     RPATHS
+          Directs _i_n_c to note UNIX "From " lines as Return-Path:
+          info.
+
+     SBACKUP
+          Defines the prefix string for backup file names.  For
+          example, SBACKUP='"\\043"'.  The default is ",".
+
+     TMA
+          Support for the TTI _t_r_u_s_t_e_d _m_a_i_l _a_g_e_n_t (TMA).  Although
+          the TTI TMA is not in the public domain, the _M_H support
+          for the TTI TMA is in the public domain.  You should
+          enable this option only if you are licensed to run the
+          TMA software (otherwise, you don't have the software in
+          your _M_H source tree).
+
+     TTYD
+          Support for TTYD.  This is no longer in wide use, and
+          is not recommended.
+
+     UCI
+          First, "_" and "#" are recognized as the prefixes for
+          scratch files.  Second, support for the UCI
+          group-leadership mechanism is enabled in _c_o_n_f_l_i_c_t.
+          Third, the first line of the file file $HOME/.signature
+          is used as the _F_u_l_l _N_a_m_e part of your "From:" header.
+          This may conflict with the interpretation of this file
+          by _N_e_w_s.  If you're not at UCI, you probably don't want
+          this option.
+
+     UK
+          Directs the _s_c_a_n program to generate UK-style dates by
+          default.
+
+     WHATNOW
+          Enable certain _M_H commands to act differently when
+          $mhdraft set.
+
+     YEARMOD
+          This option makes the _m_h-_f_o_r_m_a_t %(year) function always
+          return a value less than 100.  Enable this option if
+          you have local _m_h-_f_o_r_m_a_t(5) files which cannot handle
+          4-digit years.  You should convert these files to use a
+          4-character field width, or use the %(modulo 100) func-
+          tion to obtain a 2-digit year value.  After a short
+          grace period, remove `YEARMOD' and re-
+          {configure,generate,install} everything.
+
+
+
+[mh.6]                Last change: MH.6.8.3                    16
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+Testing/debugging
+  debug: off
+       Support for debug mode of _M_H.  Don't use this unless you
+       know what you're doing, which isn't likely if you're read-
+       ing this document!
+
+  regtest: off
+       Set this to "on" if you are doing regression testing among
+       different compilations of _M_H, and you do not want the
+       hostname and compile date included in _M_H binaries.
+
+
+
+     Now edit conf/config/mtstailor, depending on your choice of
+     the setting for mts in the _M_H configuration file.  for an
+     mts setting of "mh", look at the file conf/tailor/mhmts; for
+     an mts setting of "sendmail", "sendmail/smtp", "mmdf/smtp",
+     or "mmdf2/smtp", look at the file conf/tailor/sendmts; and,
+     for an mts setting of "mmdf", or  "mmdf2", look at the file
+     conf/tailor/mmdf.
+
+     Now install the configured files into the source areas.  (On
+     SYS5 systems, or other systems where you get complaints
+     about "_index" and "_rindex" being undefined, you should use
+     "make sys5" to compile mhconfig.)
+
+     % make
+     % ./mhconfig MH
+
+     Before proceeding, you should familiarize yourself with the
+     _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.  To generate an _n_r_o_f_f version, go to
+     the doc/ directory and type:
+
+     % (cd ../doc/; make ADMIN.doc)
+
+
+     If you're already running _M_H at your site, you should also
+     read the _m_h changes document CHANGES.  The source is in
+     papers/changes/.
+
+     After reading the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, you may decide to
+     change your MH configuration.  If so, cd back to the conf/
+     directory, re-edit the files MH and conf/config/mtstailor,
+     and re-run _m_h_c_o_n_f_i_g.
+
+     You now proceed based on your choice of a transport system
+     (the setting for mts above).  The best interface is achieved
+     with "sendmail" followed by "mmdf" or ("mmdf2"), and then
+     "mh" (stand-alone delivery, not recommended).
+
+  SENDMAIL
+     If you have not enabled BBoards or POP then no further
+
+
+
+[mh.6]                Last change: MH.6.8.3                    17
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     MTS-specific action is required on your part!
+
+     If you have enabled POP, but you want to let _S_e_n_d_M_a_i_l
+     deliver mail POP mail using its standard delivery program
+     /bin/mail, then, again, no further MTS-specific action is
+     required on your part!
+
+     Otherwise, go to the mts/sendmail/ directory.
+
+     % cd ../mts/sendmail/
+
+     This directory contains files whose definitions correspond
+     to the configuration of your _S_e_n_d_M_a_i_l system.  If you have
+     enabled BBoards or POP service, then you will need to
+     re-configure _S_e_n_d_M_a_i_l.  First, in the "local info" section
+     of your site's _S_e_n_d_M_a_i_l configuration file, choose a free
+     macro/class (B is used in this distribution), and add these
+     lines:
+
+          # BBoards support
+          DBbboards
+          CBbboards
+
+     Second, immediately after the inclusion of the zerobase
+     file, in the "machine dependent part of ruleset zero" sec-
+     tion, add these lines:
+
+          # resolve names for the BBoards system
+          R$+<@$=B>      $#bboards$@$2$:$1        topic@bboards
+
+     Be sure to use tabs when separating these fields.  Third,
+     add the line
+
+          include(bboardsMH.m4)
+
+     after the line
+
+          include(localm.m4)
+
+     in your site's _S_e_n_d_M_a_i_l configuration file.  Finally, you
+     should link the file mts/sendmail/bboardsMH.m4 into your
+     _S_e_n_d_M_a_i_l cf/ directory and re-configure _S_e_n_d_M_a_i_l.
+
+     If you have enabled POP service, a similar procedure must be
+     used on the POP service host, to re-configure _S_e_n_d_M_a_i_l.
+     First, in the "local info" section of your site's _S_e_n_d_M_a_i_l
+     configuration file, choose a free macro/class (P is used in
+     this distribution), and add these lines:
+
+          # POP support
+          DPpop
+          CPpop
+
+
+
+[mh.6]                Last change: MH.6.8.3                    18
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     Second, immediately after the inclusion of the zerobase
+     file, in the "machine dependent part of ruleset zero" sec-
+     tion, add these lines:
+
+          # resolve names for the POP system
+          R$+<@$=P>      $#pop$@$2$:$1            subscriber@pop
+
+     Be sure to use tabs when separating these fields.  Third,
+     add the line
+
+          include(popMH.m4)
+
+     after the line
+
+          include(localm.m4)
+
+     in your site's _S_e_n_d_M_a_i_l configuration file.  Finally, you
+     should link the file mts/sendmail/popMH.m4 into your _S_e_n_d_-
+     _M_a_i_l cf/ directory and re-configure _S_e_n_d_M_a_i_l.
+
+  MMDF
+     If you want _M_M_D_F to be your transport service, and have NOT
+     specified "mmdf/smtp" (or "mmdf2/smtp") as your mts setting,
+     then go to the mmdf/ directory.  (If you're using
+     "mmdf/smtp" or "mmdf2/smtp" as your mts setting, then skip
+     to the next section.)
+
+     % cd ../mts/mmdf/
+
+     This directory contains files whose definitions correspond
+     to the configuration of your _M_M_D_F system.
+
+     If you're running _M_M_D_F-_I, then copy the following files from
+     wherever you keep the _M_M_D_F sources to this directory:
+     mmdf/h/ch.h, mmdf/h/conf.h, utildir/conf_util.h,
+     utildir/ll_log.h, mmdf/h/mmdf.h, utildir/util.h,
+     mmdf/mmdf_lib.a, and utildir/util_lib.a.
+
+     If you're running _M_M_D_F-_I_I, then copy the following files
+     from where you keep the _M_M_D_F sources to this directory:
+     h/ch.h, h/conf.h, h/dm.h, h/ll_log.h, h/mmdf.h, h/util.h,
+     and lib/libmmdf.a
+
+     If you have enabled bboards, then the directories
+     support/bboards/mmdfI and support/bboards/mmdfII contain
+     information you'll need to put a UCI BBoards channel in your
+     _M_M_D_F configuration.  Similarly, if you have enabled option
+     "mf" and are running _M_M_D_F-_I, then the zotnet/mf/mmdfI/
+     directory contains information you'll need to put a _U_U_C_P
+     channel in your _M_M_D_F-_I configuration.  Finally, the direc-
+     tory support/pop/mmdfII contains information you'll need to
+     put a POP channel in your _M_M_D_F-_I_I configuration.
+
+
+
+[mh.6]                Last change: MH.6.8.3                    19
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     Note that _M_M_D_F-_I_I is distributed with the BBoards channel,
+     although the version in the _M_H distribution might be more
+     current, the version in the _M_M_D_F-_I_I distribution has been
+     tested with that revision of _M_M_D_F.
+
+  MMDF/SMTP
+     If you are using "mmdf/smtp" as your mts setting, then no
+     further MTS-specific action is required on your part!
+
+  MMDF2/SMTP
+     If you are using "mmdf2/smtp" as your mts setting, then no
+     further MTS-specific action is required on your part!
+
+  STAND-ALONE DELIVERY
+     If, instead, you want _M_H to handle its own mail delivery,
+     then no further MTS-specific action is required on your
+     part!
+
+GENERATION
+     Go to the _M_H top-level directory and generate the system.
+
+     % cd ../; make
+
+     This will cause a complete generation of the _M_H system.  If
+     all goes well, proceed with installation.  If not, complain,
+     as there "should be no problems" at this step.
+
+INSTALLATION
+     If the directories you chose for the user-programs,
+     support-programs and manuals ("bin", "etc", "popdir", "slib-
+     dir", and "mandir" in the conf/MH file) don't exist, you
+     should create them at this point.
+
+     Next, if you enabled support for the UCI BBoards facility,
+     then create a login called "bboards" with the following
+     characteristics: home directory is /usr/spool/bboards/ with
+     mode 755 (actually, use the value for "bbhome" given in the
+     _M_H configuration file), login shell is /bin/csh (or
+     /bin/sh), and, encrypted password field is "*".  The
+     "bboards" login should own the /usr/spool/bboards/ direc-
+     tory.  In addition to creating /usr/spool/bboards/, also
+     create /usr/spool/bboards/etc/ and
+     /usr/spool/bboards/archive/.  These directories should also
+     be owned by the "bboards" login.
+
+     If you enabled support for POP, then on the POP service
+     host, create a login called "pop" with the following charac-
+     teristics: home directory is /usr/spool/pop/ with mode 755,
+     login shell is /bin/csh, and, encrypted password field is
+     "*".  If you don't have /bin/csh on your system (V7), then
+     /bin/sh is just fine.  The "pop" login should own the
+     /usr/spool/pop/ directory.  You'll also need to add a line
+
+
+
+[mh.6]                Last change: MH.6.8.3                    20
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     to the /etc/services file and the /etc/rc.local file, see
+     the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e  for more details.
+
+     If this is not the first time you have installed _M_H, these
+     files will need particular attention:
+
+          _D_i_r_e_c_t_o_r_y                 _F_i_l_e_s
+          "etc/"                    MailAliases, BBoardAliases, mtstailor
+          /usr/spool/bboards/       BBoards, .cshrc, .mh_profile
+          /usr/spool/bboards/etc/   *
+
+     The MailAliases, BBoardAliases, mtstailor and BBoards files
+     will NOT be installed over existing copies; you will need to
+     edit these by hand and merge in any changes from your previ-
+     ous _M_H release.  The other files under /usr/spool/bboards/
+     will be overwritten if they exist.  You may wish to preserve
+     your old versions of these before installing _M_H.
+
+     As the super-user, and from the mh.6/ directory, install the
+     system.
+
+     # make inst-all
+
+     This will cause the _M_H processes and files to be transferred
+     to the appropriate areas with the appropriate attributes.
+
+TAILORING
+     See the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for information on tailoring
+     _M_H for the MTS, BBoards, and POP.
+
+DOCUMENTATION
+     In addition to this document, the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, and
+     the _U_s_e_r'_s _M_a_n_u_a_l, there are several documents referenced by
+     the user's manual which may be useful.  The sources for all
+     of these can be found under the papers/ directory.
+
+OTHER THINGS
+     Consult the directory miscellany/ for the sources to a
+     number of things which aren't part of the mainstream _M_H dis-
+     tribution, but which are still quite useful.
+
+FILES
+     Too numerous to mention.  Really.
+
+SEE ALSO
+     make(1)
+
+BUGS
+     The _m_h_c_o_n_f_i_g program should be smarter.
+
+     There's no way to print the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e until
+     after you have configured the system; it is difficult to
+
+
+
+[mh.6]                Last change: MH.6.8.3                    21
+
+
+
+
+
+
+MH-GEN(8)             MAINTENANCE COMMANDS              MH-GEN(8)
+
+
+
+     configure the system without the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.
+
+     The Makefiles should know when _m_h_c_o_n_f_i_g has been run and
+     force "make clean" behavior.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[mh.6]                Last change: MH.6.8.3                    22
+
+
+
diff --git a/docs/historical/mh4mm.pdf b/docs/historical/mh4mm.pdf
new file mode 100644
index 0000000..466d319
Binary files /dev/null and b/docs/historical/mh4mm.pdf differ
diff --git a/docs/historical/mh4mm.txt b/docs/historical/mh4mm.txt
new file mode 100644
index 0000000..3aa30f1
--- /dev/null
+++ b/docs/historical/mh4mm.txt
@@ -0,0 +1,1168 @@
+
+
+
+
+                                   MH  for  MM  Users
+
+
+
+                            Mary  Hegardt                           Tim  Morgan
+
+
+
+                                               April  12,  1990
+
+
+
+1         Introduction
+
+
+
+This document is another in a continuing series on use of the MH mail system
+
+at  UCI.  It  is  intended  for  those  users  accustomed  to  the  mm  "user  agent"
+
+(mail  program)  under  Tops-20  and  who  are  already  familiar  with  network
+
+mail,  but  who  may  not  be  experienced  Unix  users.   For  an  introduction
+
+to  MH,  see  "MH  For  Beginners"  by  Mary  Hegardt  and  Tim  Morgan.   For
+
+complete, detailed information on the MH system, see The Rand MH Message
+
+Handling System:  User's Manual  by Marshall T. Rose and John L. Romine.
+
+Both documents are available for Xeroxing in suite CS408.
+
+
+
+1.1         UNIX  Versus  Tops-20
+
+
+
+The  Unix1  paradigm  is  that  each  command,  or  program,  should  perform
+
+only  one  function.   An  extension  of  this  idea  is  that  the  operating  system
+
+implements  only  those  functions  which  are  necessary,  but  it  does  so  in  a
+
+very general way so that programs may still accomplish their functions.  This
+
+philosophy  probably  evolved  because  the  original  versions  of  Unix  ran  on
+
+PDP-11 minicomputers which had only a small memory space for each pro-
+
+cess.
+________________________________________________
+    1 Unix is a trademark of AT&T Bell Laboratories
+
+
+
+                                                           1
+
+
+
+
+Consequently,  all  commands  in  Unix,  with  a  very  few  exceptions,  are  in
+
+actuality  programs.  On  Tops-20,  in  contrast,  many  of  the  most  frequently
+
+used  commands  are  built  into  the  user's  shell,  or  exec.  Both  the  Exec  and
+
+csh,  which  is  typically  the  user's  command  interface  on  Unix,  will  accept
+
+and parse command lines, attempting to invoke a command as a program if
+
+it is not one of the built-in commands.  Unix and Tops-20 are surprisingly
+
+similar internally:  the use of the shell, separate processes for each command
+
+or  program  to  execute,  standard  input  and  output  for  each  program,  and
+
+many  other  ideas  are  common  to  both  operating  systems.  Users  should  be
+
+familiar with the capabilities of the shell, which is described in the document
+
+"Introduction to the Csh."
+
+
+
+1.2         The  MH  User  Interface
+
+
+
+The  MH  mail  "user  agent"  is  different  from  most  other  mail  systems.  mm,
+
+for example, is a monolithic  system because one program implements all the
+
+mail-related  functions.   The  disadvantages  of  monolithic  systems  are  that
+
+(a) they are large, so they tend to put more burden on the computer system,
+
+and (b) they allow for much less flexibility.  In contrast, MH implements each
+
+mail command as a separate program:  there is no single program called mh.
+
+This  approach  facilitates  interspersing  mail  commands  with  other,  perhaps
+
+unrelated, commands.
+
+
+Another  unique  feature  of  MH  is  that  it  takes  advantage  of  the  facilities
+
+provided  by  the  operating  system.  Most  mail  agents,  such  as  mm,  maintain
+
+a file containing the user's mail in a special, usually undocumented, format.
+
+When  a  message  is  deleted,  mm  must  take  care  of  compacting  the  mail  file.
+
+It  must  be  able  to  distinguish  the  separate  messages  contained  in  the  file.
+
+mm must also implement a simple text editor to allow the user to enter and
+
+modify a message while it is being composed.  These functions are essentially
+
+those provided by the operating system when separate files are stored within
+
+a  directory.   Therefore,  the  approach  taken  by  MH  is  that  each  message  is
+
+kept  in  a  separate  file.  This  file  simply  contains  the  message,  with  no  other
+
+special  formatting  characters  or  requirements.   All  the  messages  are  stored
+
+within  a  normal  Unix  directory.   This  approach  makes  it  easy  to  add  new
+
+MH commands, to edit messages using standard text editors, etc.
+
+
+
+                                                           2
+
+
+
+
+All your MH related files are stored in a directory within your home directory.
+
+Usually this directory is called Mail or mhbox, although you are free to name
+
+it as you choose.  Another file in your home directory called .mh_profile is
+
+equivalent  to  the  MM.INIT  file  under  mm.  It  contains  all  the  options  which
+
+you  prefer  for  the  various  MH  commands.  It  also  contains  the  name  of  the
+
+MH  directory  and  the  name  that  you  want  on  your  outgoing  mail  in  the
+
+From:  field (your "signature ").
+
+
+
+2         Getting  Started
+
+
+
+2.1         Incorporating  Mail
+
+
+
+Another important difference between mm and MH is the concept of the mail-
+
+drop  file.  Under Tops-20, the mail transport system delivers new messages
+
+directly into the recipient's MAIL.TXT file, where they may then be processed
+
+with  mm.   In  contrast,  the  Unix  mail  transport  system,  called  MMDF-II,
+
+makes  no  assumptions  about  the  user  agent  used  by  the  recipient.  Instead,
+
+it puts all new mail into a special file called the maildrop.  This file is in the
+
+/usr/spool/mail  directory.  When  you  log  in,  if  there  is  new  mail  for  you
+
+in your maildrop, you will be so notified by the message
+
+
+                 You  have  new  ZOTnet  mail  --  type  inc  (or  mail)
+
+
+When you are ready to process this new mail, you may type the command
+
+
+                 %  inc
+
+
+("incorporate") which will copy the new mail into separate files, one per mes-
+
+sage, stored in your "inbox" folder.  A folder is a subdirectory beneath your
+
+MH directory which is used to store related messages.  Additional information
+
+on  folders  is  given  in  Section  4.5,  page  13.   The  "inbox"  is  a  distinguished
+
+folder  because  by  default  inc  will  always  copy  new  mail  into  that  folder,
+
+removing it from the maildrop.
+
+
+If  this  is  the  first  time  you  have  used  inc  or  any  other  MH  command,  the
+
+mh-install  program  will  inform  you  that  it  is  creating  your  Mail  directory.
+
+It will also create the "inbox" folder directory, and .mh_profile.
+
+
+
+                                                           3
+
+
+
+
+2.2         Message  Numbers
+
+
+
+As inc processes each message, it prints a "scan" listing showing the message
+
+number, the date the message was sent, the name of the sender, the subject,
+
+and  sometimes  the  initial  part  of  the  text  of  the  message.  A  "scan"  listing
+
+is thus similar to the output of the HEADERS command in mm.  Each message
+
+within  a  folder  is  given  a  number,  starting  with  1,  by  which  it  can  be  ref-
+
+erenced.  Inc  will  display  the  numbers  assigned  to  each  new  message  in  its
+
+"scan" listing.
+
+
+As  in  mm,  there  is  a  "current  message"  number  which  usually  identifies  the
+
+message most recently manipulated by the user.  With most MH commands,
+
+this  will  be  the  default  message  if  no  messages  are  explicitly  specified  in
+
+a  command.   Inc  makes  the  first  new  message  the  current  message,  which
+
+is  indicated  by  a  "+"  character  in  the  scan  listing,  just  after  the  message
+
+number.
+
+
+Many  MH  commands  take  a  list  of  messages  to  process.   A  message  desig-
+
+nation  is  either  a  single  message  number,  two  message  numbers  separated
+
+by  a  dash.   The  dash  format  indicates  a  range  of  messages  including  the
+
+endpoints.  A message list consists of one or more message designations sep-
+
+arated by spaces.  For example, messages 11 through 15 and message 17 may
+
+be indicated by typing
+
+
+                 11-15  17
+
+
+as the argument to some command.  There are also several predefined names
+
+for  messages  or  lists  of  messages  which  may  be  used  in  place  of  message
+
+numbers:
+
+
+   cur          The  current  message  (the  last  one  that  was  handled).  Equivalent
+
+                to "."  or "CURRENT" in mm.
+
+  next          The next message
+
+  prev          The previous message
+
+  first         The first message in the current folder.
+
+   last         The last message in the folder.  Equivalent to % or * in mm.
+
+     all        All messages (first  last ).  Same as in mm.
+
+
+It  is  also  possible  for  you  to  define  your  own  named  sequences  of  messages.
+
+
+
+                                                           4
+
+
+
+
+See the pick  command description for more details.
+
+
+
+3         Processing  Messages
+
+
+
+This section contains a list of the common mm commands and their equiva-
+
+lents in the in MH mail system.  A short textual note describes how the MH
+
+commands differ from their mm counterparts.
+
+
+
+3.1         Listing  Messages
+
+
+
+As mentioned in Section 2.2, the scan  command may be used to summarize
+
+the  messages  in  a  folder,  similar  to  the  HEADERS  command  in  mm.   Unlike
+
+most MH commands, however, scan defaults to all the messages in the current
+
+folder unless you specify one or messages on the command line to be scanned.
+
+So simply typing
+
+
+                 %  scan
+
+
+is equivalent to typing HEADERS  ALL (or H  A) in mm.
+
+
+
+3.2         Reading  Mail
+
+
+
+Unlike  the  READ  command  in  mm,  in  MH  there  is  no  special  mail-reading
+
+mode (indicated in mm by the R> prompt).  The command to read messages
+
+in  MH  is  show.   If  no  message  list  is  specified,  then  the  current  message
+
+is  displayed.  The  message  is  displayed  by  your  "showproc",  as  specified  in
+
+the  .mh_profile,  described  in  Section  4.2.  Normally,  your  "showproc"  will
+
+be  more  or  mhless.  Both  of  these  programs__will__display_ your  messages  one
+
+screenful  at  a  time.   You  press  the  __space_bar______ __on  your  terminal  to  see  the
+                       ____________
+next screenful, or the __return____ _key to see the next line.
+
+
+The command
+
+
+                 %  show  next
+
+
+
+                                                           5
+
+
+
+
+(which  will  display  the  first  message  following  the  current  message  in  the
+
+current folder) can be abbreviated as simply
+
+
+                 %  next
+
+
+Similarly, the command "show  prev" can be abbreviated as simply "prev".
+
+
+To get a paper copy of a mail message, take the output from the show  com-
+
+mand and pipe it into the imprint  command.
+
+
+                 %  show  5  _  imprint
+
+
+See the manual page for imprint  for more information.
+
+
+
+3.3         Deleting  Messages
+
+
+
+The equivalent of the DELETE command in mm is rmm  in MH (remove mes-
+
+sages).  It  acts  on  the  current  message  unless  messages  are  specified  on  the
+
+command  line.  Unlike  mm,  the  deleted  messages  will  no  longer  show  up  in
+
+a  "scan"  listing.   But  the  messages  are  not  completely  removed;  they  are
+
+renamed to have a comma prepended to the name of the file containing the
+
+message within its folder directory.  Therefore, if you need to recover a mes-
+
+sage,  it  is  possible  to  go  into  the  directory  and  rename  the  message  back.
+
+Be careful in doing this not to overwrite a new message with the same mes-
+
+sage  number!  It  is  a  Unix  convention  that  files  whose  names  begin  with  a
+
+comma will be removed from disk (expunged ) early each morning.  Therefore,
+
+your deleted messages will be available for the rest of the day, unless you re-
+
+move another message subsequently which has the same message.  Then the
+
+previously deleted message is gone.
+
+
+
+3.4         Replying  to  Mail
+
+
+
+The  equivalent  of  the  REPLY  command  in  mm  is  repl  in  MH.  Repl  may  be
+
+given the number of the message to which you wish to reply, or it will default
+
+to  the  current  message.   When  replying  in  mm,  you  are  prompted  asking
+
+if  you  wish  to  reply  to  all  the  recipients  of  the  message  to  which  you  are
+
+replying, or only to its sender.  In MH, normally the reply will be constructed
+
+
+
+                                                           6
+
+
+
+
+to be sent to all the recipients.  You may select which recipients receive copies
+
+of  your  reply  by  using  the  -query  option  on  repl,  or  by  putting  this  option
+
+in  your  .mh_profile,  as  described  in  Section  4.2.  If  you  wish  a  reply  to  go
+
+to everyone but yourself, you can use repl  -nocc  me.
+
+
+
+3.5         Sending  Mail
+
+
+
+The equivalent of the SEND mm command is comp ("compose") in MH. These
+
+two  commands  are  fairly  similar,  except  that  the  recipient  of  the  message
+
+cannot be specified on the comp  command line.  The comp  program invokes
+
+a simple editor called prompter  which will prompt you for the To:, Cc:, and
+
+Subject:   fields  of  the  message.   Then  a  line  of  dashes  is  typed,  and  you
+
+may  enter  the__body__of  your  message  (its  text,__in__mm_ terms).  When  you  are
+
+finished, type __ctrl__-__D (equivalent to typing __ESC_______or control-Z in mm).  Then
+
+you'll receive the prompt
+
+
+                 What  now?
+
+
+which  is  similar  to  mm's  S>  prompt.  You  may  receive  a  list__of__the_ options
+
+that  you  have  at  this  point  by  typing  "?"   followed  by  __return____._  Here  is  a
+
+short  list  of  the  options  and  their  meanings.  Notice  that,  unlike  mm,  there
+
+are very few commands to modify the message (such as the TEXT, TO, CC, etc.,
+
+commands which may be typed at the S> prompt in mm).  In place of these
+
+commands,  you  use  the  edit  command  to  invoke  your  favorite  text  editor
+
+on the message, and you use it to make the equivalent changes.  You also use
+
+your  editor  to  include  other  files  into  the  body  of  the  message,  rather  than
+
+using  control-B,  as  in  mm.  One  additional  use  of  the  edit  command  is  for
+
+spelling checking.  In mm, you may use the command SPELL for this purpose.
+
+In MH, you type "edit  spell"2  instead.  This will cause the spelling checker
+
+to be run, giving you a list of the possibly misspelled words in your message.
+
+
+
+     edit  editor              Edit  the  message  using  the  specified  editor.   When  you
+
+                               exit, you will be back at What  now?.
+________________________________________________
+    2 Actually, any program named after the "edit" command will be invoked with what-
+
+ever  arguments  you  have  given  and  a  path  to  the  file  containing  the  message  you  are
+editing.
+
+
+
+                                                           7
+
+
+
+
+                list           Shows the message you just typed
+
+
+   whom  -check                Verifies that the addresses you have used are valid as far
+
+                               as our system can tell
+
+
+                send           Sends the message to the recipients
+
+
+                push           Sends the message in the background
+
+
+                quit           Quits  without  sending  the  message.   Saves  the  text  of
+
+                               the  message  as  a  "draft".  Type  comp  -use  to  get  back
+
+                               to that draft later.
+
+
+ quit  -delete                 Quit, throwing away the draft
+
+
+
+3.6         Forwarding  Mail
+
+
+
+The  forw  command  is  used  in  MH  to  forward  messages.   It  will  take  a  list
+
+of  messages  on  the  command  line  to  be  forwarded,  or  it  will  default  to  the
+
+current  message  if  none  are  specified.   It  will  prompt  you  like  comp  does
+
+for  the  To:,  Cc:,  and  Subject:  fields.    Note  that,  unlike  mm's  FORWARD
+
+command, forw  will not construct a subject line automatically.  Also as with
+
+comp, you will have the opportunity to add additional text to the message(s)
+
+which you are forwarding, ended with a control-D.
+
+
+
+3.7         Resending  Mail
+
+
+
+The  equivalent  of  the  RESEND  command  in  mm  is  the  dist  ("distribute")
+
+command  in  MH.  Dist  works  very  much  like  the  forw  command,  except
+
+that  the  prompts  will  be  Resend-To:,  Resend-Cc:,  etc.  After  filling  in  the
+
+headers,  a  line  of  dashes  is  typed  giving  the  impression  that  additional  text
+
+can be entered.  Nothing could be further from the truth; if you add any text
+
+at  this  point  the  dist  will  fail.  Your  only  opportunity  to  add  text  is  in  the
+
+Resend-Note:  field.
+
+
+
+                                                           8
+
+
+
+
+4         Advanced  Topics
+
+
+
+4.1         Selecting  Messages
+
+
+
+In  mm,  you  may  use  several  reserved  command  words  to  select  messages
+
+in  place  of  an  explicit  list  of  message  numbers.    For  example,  you  can
+
+type  "DELETE  FROM  SMITH"  to  remove  all  the  messages  from  a  user  named
+
+"Smith".   Rather  than  building  such  a  capability  into  each  MH  program
+
+which  can  process  message  lists,  a  special  program  called  pick  is  used  in-
+
+stead.   Just  as  there  are  predefined  sequences  of  messages,  such  as  "all",
+
+"cur", etc., you may use pick  to define your own sequences.  Pick  is capable
+
+of selecting messages from a folder based on the To:, From:, Subject:, Cc:,
+
+or  Date:  fields,  or  by  searching  the  body  of  the  message.  The  patterns  to
+
+be searched for may include full regular expressions (see the "man" page for
+
+ed(1)  for more information) or simple strings.
+
+
+Pick  may  be  used  in  one  of  two  ways.  First,  it  may  output  the  sequence  of
+
+message  numbers  which  match  the  search  parameters.  Using  the  backquot-
+
+ing  mechanism  of  the  shell,  these  message  numbers  may  then  become  the
+
+arguments to other MH programs.  The second way to use pick  is to have it
+
+define a new sequence name which will be the messages which were selected.
+
+Only  this  second  method  of  using  pick  will  be  described  here;  see  pick(l)  if
+
+you wish to use the first method.
+
+
+In your .mh_profile, add the line
+
+
+                 pick:    -seq  sel
+
+
+Then  each  time  you  use  the  pick  command,  it  will  define  the  resulting  se-
+
+quence of messages to be called "sel".  Then to "pick" all the messages in the
+
+current folder which are from "Smith", just type
+
+
+                 %  pick  -from  smith
+
+
+To see a summary of those messages, type
+
+
+                 %  scan  sel
+
+
+Then to the remove the messages, type the command
+
+
+
+                                                           9
+
+
+
+
+                 %  rmm  sel
+
+
+You  can  pick  messages  according  to  any  of  the  headers  (-to  -from  -subj
+
+-cc  or  -date) or just search all the messages for a given word (-search).
+
+
+
+4.2         Customizing  Your  Mail  Environment
+
+
+
+In  mm,  you  use  the  PROFILE  command  to  tailor  your  mail  environment.
+
+This  command  writes  a  file  called  MM.INIT  in  your  home  directory  which
+
+is  then  read  by  subsequent  executions  of  mm.   In  the  MH  system,  the  file
+
+.mh_profile  serves  the  same  purpose.   It  is  edited  with  any  normal  text
+
+editor,  rather  than  using  a  special-purpose  command  to  modify  it.    The
+
+format of the file is line oriented, one line per MH program or MH option to
+
+be  set.  The  only  required  line  in  the  profile  is  the  name  of  the  primary  MH
+
+mail directory, which is by default Mail.  This information is specified by the
+
+line
+
+
+                 Path:    Mail
+
+
+The  textual  name  you  would  like  to  have  on  your  outgoing  mail  is  specified
+
+by the Signature:  line.  For example,
+
+
+                 Signature:    Mary  Hegardt
+
+
+The BBoards which you like to read should also be listed in the .mh_profile
+
+(see  Section  4.6,  page  14,  for  additional  information).   For  example,  if  you
+
+read the "system" BBoard (where all important announcements are posted),
+
+as well as "whimsey" and "imagen-users" BBoards, your .mh_profile should
+
+contain the line
+
+
+                 bboards:    system  whimsey  imagen-users
+
+
+Other options may be specified on a per-program basis.  The format for these
+
+lines is the same.  First, the program name is given followed by a colon.  Then
+
+any flags which are to be the default options for that program are given.  Here
+
+is a short list of the most common options which you may want to set in your
+
+.mh_profile:
+
+
+                 showproc:    mhless
+
+
+
+                                                           10
+
+
+
+
+The  showproc  is  the  program  used  to  show  messages  to  you.  By  default,  it
+
+is the more  command.  Mhless  is the same as more  except that it omits the
+
+headers of the messages which you indicate that you wish not to see.  Type
+
+
+                 %  man  mhless
+
+
+for more information about this program.
+
+
+                 msh:    -scan
+
+
+Selecting this option causes an automatic scan of new messages on BBoards to
+
+be made when reading BBoards with bbc, similar to the scan listing produced
+
+by inc.
+
+
+                 repl:    -query
+
+
+causes repl  to ask for each address in the message being replied to if it should
+
+be included in the To:  or Cc:  fields of the reply being composed.
+
+
+                 pick:    -seq  sel
+
+
+This  line  will  cause  messages  "picked"  by  the  pick  command  to  be  put  into
+
+a  sequence  named  "sel".  This  sequence  name  may  then  be  used  just  as  the
+
+built-in sequences ("last", "first", etc.).
+
+
+
+4.3         Aliases
+
+
+
+Using MH, you may specify your own private mail aliases.  This feature allows
+
+you to store lists of addresses or long internet addresses of people with whom
+
+you  frequently  correspond  in  one  file,  and  then  to  address  them  using  short
+
+mnemonic names.  Typically, you will call your alias file "aliases";  it must
+
+be  stored  in  your  MH  directory.  The  format  of  this  file  is  simple.  The  alias
+
+is  given,  followed  by  a  colon,  followed  by  one  or  more  legal  mail  addresses
+
+separated by commas.  For example, you might for some reason have an alias
+
+for all the users named "Rose" in the ICS department:
+
+
+                 roses:    prose,  srose,  mrose,  drose
+
+
+In addition to your "aliases" file, you will need to modify your .mh_profile
+
+in  order  to  use  aliases.   You  should  add  the  flag  "-alias  aliases"  to  the
+
+
+
+                                                           11
+
+
+
+
+entries  for  the  commands  ali,  whom,  send,  and  push,  creating  entries  for
+
+these  programs  if  they  aren't  already  in  your  .mh_profile.  Now,  messages
+
+addressed to "roses" will be distributed to all the people listed in the alias.
+
+
+The  ali  command  is  used  to  show  you  what  an  alias  expands  to.  You  just
+
+type
+
+
+                 %  ali  alias
+
+
+and ali  will respond with the expansion of the alias.  Ali  searches the system
+
+aliases file in addition to your private ones.
+
+
+
+4.4         Blind  Lists
+
+
+
+There  are  two  different  types  of  so-called  "blind  addressing"  of  messages.
+
+Users  of  mm  may  already  be  familiar  with  the  "Blind  Carbon  Copy",  or
+
+BCC:  field.   It  allows  you  to  add  recipients  to  your  message  just  like  those
+
+who are CC'd, but the normal recipients will not see that the BCC recipients
+
+were copied on the message, their replies will not go to the blind recipients,
+
+and the blind recipients cannot (easily) reply to the message.
+
+
+The  second  type  of  blind  mailing  is  actually  called  a  "group  address  list",
+
+although it is commonly referred to as a "blind list".  The format of this type
+
+of address is
+
+
+                 phrase :    address__list ;
+
+
+where  the  "phrase "  is  any  English  phrase  of  one  or  more  words,  and  the
+
+address__list  consists  of  one  or  more  addresses  separated  by  commas.   The
+
+recipients of a message addressed in this fashion will see simply
+
+
+                 phrase :    ;
+
+
+so  when  they  reply  to  the  message,  their  reply  will  come  only  to  the  sender
+
+(or  the  Reply-To:  field,  if  one  was  specified),  rather  than  going  to  all  the
+
+recipients of the original list.  For example, to use a group address list for the
+
+"roses" alias you would type:
+
+
+                 To:    People  Named  Rose:    roses;
+
+
+
+                                                           12
+
+
+
+
+This type of group address is very useful for making up lists of related people,
+
+such as all the people working on a particular research project.
+
+
+
+4.5         Folders
+
+
+
+As  mentioned  previously,  folders  are  directories  within  your  MH  directory
+
+used  to  store  related  messages.  There  is  no  equivalent  of  the  folder  concept
+
+in the mm system.  Usually, you will use only the folder "inbox", so you won't
+
+have to worry about folders.  However, if you process a large volume of mail,
+
+then folders become invaluable in managing the messages which you wish to
+
+keep for future reference.
+
+
+Just as there is a "current message," MH maintains a "current folder," which
+
+will  normally  be  "inbox".   You  can  change  folders  either  by  specifying  the
+
+folder on the command line of MH programs which take a list of messages as
+
+an argument, or by using the folder command:
+
+
+                 %  folder  +folder__name
+
+
+In  general,  the  folder  name  is  indicated  by  a  "+"  sign  followed  immediately
+
+by  the  folder  name,  all  preceeding  any  list  of  messages.   For  example,  you
+
+may  read  the  most  recent  message  in  a  folder  called  "job__offers"  using  the
+
+command
+
+
+                 %  show  +job__offers  last
+
+
+This  command  will  have  the  side-effect  of  setting  the  current  folder  to  be
+
+"job__offers".    You  may  move  messages  from  the  current  folder  into  the
+
+"job__offers" folder using the command
+
+
+                 %  refile  +job__offers  messages
+
+
+where, as usual, the messages  list will default to the current message in the
+
+current  folder  if  none  are  specified.   Note  that,  in  contrast  with  the  show
+
+command  and  most  other  MH  commands,  the  messages  are  not  considered
+
+to be in the folder "job__offers".  You may obtain a summary of all your folders
+
+by typing the command
+
+
+                 %  folders
+
+
+
+                                                           13
+
+
+
+
+When  you  remove  messages  from  a  folder  using  the  rmm  command,  the
+
+deleted  messages  will  show  up  as  a  "hole"  in  the  message  numbering.  The
+
+command
+
+
+                 %  folder  -pack
+
+
+will cause all the messages within one folder to be renumbered starting with 1.
+
+Similarly, the command
+
+
+                 %  folders  -pack
+
+
+will do the same thing for all your folders.
+
+
+To remove an empty folder, use the command
+
+
+                 %  rmf  +folder
+
+
+
+4.6         Reading  BBoards
+
+
+
+Two  special-purpose  programs  are  utilized  in  reading  BBoards.  The  first  is
+
+bbc,  which  is  used  to  check  a  list  of  BBoards  for  new  messages.  The  list  of
+
+messages may be given on the command line, or if not, it will be taken from
+
+the  BBoards:   list  in  your  .mh_profile.   You  may  obtain  a  list  of  all  the
+
+available BBoards by typing the command
+
+
+                 %  bbc  -topics
+
+
+For  each  BBoard  with  unseen  messages,  bbc  will  invoke  the  MH  shell,  msh,
+
+whose prompt is
+
+
+                 (msh)
+
+
+The msh  program allows you to read BBoard mail as if it were normal mes-
+
+sages  in  one  of  your  folders.   Almost  all  the  MH  commands  will  work  just
+
+as  the  normally  do.  Typing  the  command  "quit"  to  msh  causes  it  to  stop
+
+reading  the  current  BBoard  and  go  on  to  the  next  one  containing  unseen
+
+messages,  or  to  exit  if  there  are  no  more  such  BBoards.   Typing  control-D
+
+causes  msh  to  exit  unconditionally.  The  command  mark  followed  by  a  mes-
+
+sage  number  causes  msh  to  act  as  if  you  have  seen  that  message  and  all
+
+previous ones.
+
+
+
+                                                           14
+
+
+
+
+4.7         Checking  for  Mail
+
+
+
+Under  Unix,  there  are  about  a  dozen  different  ways  to  check  for  new  mail.
+
+The  easiest  way  to  do  it  is  to  set  the  csh  variable  named  "mail"  to  tell  csh
+
+to check for new mail for you periodically.  To do this, add the line
+
+
+                 set  mail=(60  /usr/spool/mail/$USER)
+
+
+to  your  .login  file  in  your  home  directory.   This  command  says  to  check
+
+for  mail  if  csh  is  about  to  prompt  you  with  a  %  sign,  and  if  it  has  been  at
+
+least 60 seconds since it last checked for mail.  The advantage of this method
+
+of  mail  notification,  besides  simplicity,  is  that  you  will  never  be  interrupted
+
+by  a  mail  notification.  You  will  only  be  notified  of  new  mail  when  you  are
+
+between commands, when the shell is about to prompt you.
+
+
+If you desire asynchronous mail notification, which will print to your terminal
+
+regardless of what you are currently doing, you may make use of a "Receive
+
+Mail Hook" called "rcvtty".  To do this, create a file in your home directory
+
+called ".maildelivery".  In this file, put the line
+
+
+                 *  -  pipe  R  /usr/uci/lib/mh/rcvtty
+
+
+Then  each  time  new  mail  arrives,  you  will  receive  a  one-line  "scan"  listing
+
+of  the  mail  if  your  terminal  is  world-writable.    For  more  information  on
+
+"maildelivery" files, type:
+
+
+                 %  man  5  maildelivery
+
+
+
+4.8         Saving  Drafts
+
+
+
+Normally  when  you  use  comp,  it  creates  the  message  being  composed  in  a
+
+file  called  "draft"  in  your  MH  directory.   If  you  use  the  "quit"  option  at
+
+the "What  now?"  prompt, this file will remain there.  You may later use the
+
+command
+
+
+                 %  comp  -use
+
+
+to resume composing the message.
+
+
+
+                                                           15
+
+
+
+
+If you begin composing a new message and there is already a "draft" file,_you___
+
+will  be  asked  for  the  disposition  of  this  file.  Typing  ?  __return____ _will  give  you
+
+a list of the options at this point.  Normally you will either replace (delete)
+
+the old draft and begin a new one or use the old one.
+
+
+The -file switch to comp  may be used to specify the name of a draft other
+
+than "draft".  For example, one might type
+
+
+                 %  comp  -file  mary
+
+
+to begin composing a message maintained in the draft file "mary".  Typing
+
+
+                 %  comp  -file  mary  -use
+
+
+would cause comp  to resume composing this same draft after a "quit" com-
+
+mand to the "What  now?"  prompt.
+
+
+Very  advanced  users  of  MH  maintain  multiple  draft  files  in  a  draft  folder.
+
+This  is  a  normal  folder  which  holds  all  your  drafts,  rather  than  having  just
+
+one draft in your MH directory named "draft".  If you feel that you need to
+
+use  draft  folders,  you  should  consult  the  MH  User's  Manual  for  additional
+
+information.
+
+
+
+                                                           16
diff --git a/docs/historical/mh6.pdf b/docs/historical/mh6.pdf
new file mode 100644
index 0000000..482ccc5
Binary files /dev/null and b/docs/historical/mh6.pdf differ
diff --git a/docs/historical/mh6.txt b/docs/historical/mh6.txt
new file mode 100644
index 0000000..46c0ca0
--- /dev/null
+++ b/docs/historical/mh6.txt
@@ -0,0 +1,1030 @@
+
+
+
+
+                                             Changes  to
+
+
+  The  Rand  MH  Message  Handling  System:
+
+
+                     MH  #6.5  for  4.3BSD  UNIX
+
+
+
+                                            Marshall  T.  Rose
+
+                   Northrop  Research  and  Technology  Center
+
+                                          One  Research  Park
+
+                           Palos  Verdes  Peninsula,  CA  90274
+
+
+
+                                               April  12,  1990
+
+
+
+                                                     Abstract
+
+              This  document  describes  the  user-visible  change  to  the  UCI  ver-
+         sion of the Rand MH     system that were made from mh.5     to MH     #6.5.
+         It  is  based  on  the  mh.6    changes  document,  but  has  been  updated  to
+         accurately reflect the MH     distributed with 4.3bsd UNIX1 . This docu-
+         ment  does  not  describe  bug-fixes,  per  se,  or  internal  changes,  unless
+         these activities resulted in a visible change for the MH     user.
+              This  document  is  meant  to  supplement,  not  supersede,  the  stan-
+         dard MH     User's manual[MRose85       ].
+              Comments concerning this documentation should be addressed to
+         the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+________________________________________________
+   T0his document (version  #2.10) was LaTEX   set April 12, 1990 with lplain v2.09-10/29/85.
+    1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+                                                           1
+
+
+
+
+Acknowledgements
+
+
+The MH     system described herein is based on the original Rand MH     system.
+
+It has been extensively developed (perhaps too much so) by Marshall T. Rose
+
+and  John  L.  Romine  at  the  University  of  California,  Irvine.  Einar  A.  Stef-
+
+ferud,  Jerry  N.  Sweet,  and  Terry  P.  Domae  provided  numerous  suggestions
+
+to improve the UCI version of MH    .  Of course, a large number of people have
+
+helped MH     along.  The list of "MH     immortals" is too long to list here.  How-
+
+ever, Van Jacobson deserves a special acknowledgement for his tireless work
+
+in improving the performance of MH    .  Some programs have been speeded-up
+
+by a factor of 10 or 20.  All of users of MH    , everywhere, owe a special thanks
+
+to Van.
+
+
+
+Disclaimer
+
+
+The Regents of the University of California wish to make it known that:
+
+
+         Although  each  program  has  been  tested  by  its  contributor,  no
+
+         warranty,  express  or  implied,  is  made  by  the  contributor  or  the
+
+         University  of  California,  as  to  the  accuracy  and  functioning  of
+
+         the  program  and  related  program  material,  nor  shall  the  fact  of
+
+         distribution  constitute  any  such  warranty,  and  no  responsibility
+
+         is  assumed  by  the  contributor  or  the  University  of  California  in
+
+         connection herewith.
+
+
+
+                                                           2
+
+
+
+
+Conventions
+
+
+In this document, certainaL TE X    -formatting conventions are adhered to:
+
+
+     1.  The  names  of  UNIX  commands,  such  as  comp    ,  are  presented  in  text
+
+         italics.
+
+
+     2.  Arguments  to  programs,  such  as  `msgs',  are  presented  in  typewriter
+
+         style and delimited by single-quotes.
+
+
+     3.  UNIX pathnames and envariables, such as
+
+
+                                   /usr/uci/             and          $SIGNATURE              ;
+
+
+         are presented in slanted roman.
+
+
+     4.  Text presenting an example, such as
+
+
+
+                 comp  -editor  zz
+
+
+
+         is presented in typewriter  style.
+
+
+
+                                                           3
+
+
+
+
+General  Changes
+
+
+Unlike  the  changes  between  mh.4     and  mh.5   ,  a  large  number  of  user-visible
+
+changes  have  been  made  in  mh.6   .  These  changes  have  been  in  the  form  of
+
+bug  fixes  and  several  generalizations.  The  majority  of  these  will  not  affect
+
+novice users.  In addition, mh.6     is a great deal faster than mh.5    :  all programs
+
+have been speeded-up significantly, thanks to work done by Van Jacobson as
+
+part of the process of including mh.6     in the 4.3bsd UNIX distribution.
+
+      This document describes all user-visible changes to mh.5     from it's initial
+
+release to the intermediate release of MH     #6.5.
+
+
+
+System-5  Support
+
+
+In addition to support for bsd UNIX, V7 UNIX and Xenix2  variants of UNIX,
+
+MH     finally has support for the AT&T variant of UNIX, System 5.  Hopefully
+
+this will greatly expand the number of system which can run MH    .  Ironically,
+
+it  appears  that  five  ports  of  earlier  versions  of  MH     (including  mh.5   )  were
+
+done, but news of the work was not widespread.3
+
+
+
+Documentation
+
+
+Several  new  documents  have  been  included  in  the  mh.6     distribution:   The
+
+paper MH.5:  How to process 200 messages a day and still get some real work
+
+done  was  presented  at  the  1985  Summer  Usenix  Conference  and  Exhibition
+
+in  Portland,  Orgeon.  Another  paper,  MH:  A  Multifarious  User  Agent,  has
+
+been accepted for publication by Computer Networks.  Both describe MH    , the
+
+former from a more technical and somewhat humorous perspective, the latter
+
+from  a  more  serious  and  research-oriented  perspective.  In  addition,  a  third
+
+paper  has  been  included,  Design  of  the  TTI  Prototype  Trusted  Mail  Agent,
+
+which  describes  a  so-called  "trusted"  mail  agent  built  on  top  of  MH   .   This
+
+paper  was  presented  at  the  Second  International  Symposium  on  Computer
+
+Message Systems in Washington, D.C. A fourth paper, MZnet:  Mail Service
+
+for  Personal  Micro-Computer  Systems,  is  also  included.  This  paper,  which
+________________________________________________
+    2 Xenix is a trademark of Microsoft Corporation.
+    3 In fact, three groups in one large organization ported MH    independently, each without
+
+knowledge of the others' work.
+
+
+
+                                                           4
+
+
+
+
+was  presented  at  the  First  International  Symposium  on  Computer  Message
+
+Systems in Nottingham, U.K., describes a CP/M4 -based version of MH    .
+
+      In  addition,  the  MH     tutorial,  The  Rand  MH  Message  Handling  System:
+
+Tutorial,  and,  The  Rand  MH  Message  Handling  System:  The  UCI  BBoards
+
+Facility, have both been updated by Jerry N. Sweet.
+
+      For  MH     administrators  (PostMasters  and  the  like),  there's  an  entirely
+
+new  document,  The  Rand  MH  Message  Handling  System:  Administrator's
+
+Guide.  It explains most of the "ins and outs" of maintaining an MH     system.
+
+      Finally, all of the manual entries and the MH     manual have had a thorough
+
+working  over.   The  documentation  is  expanded,  more  accurate,  and  more
+
+detailed.
+
+
+
+Help  Listings
+
+
+When  any  MH     command  is  invoked  with  the  `-help'  switch,  in  addition  to
+
+listing  the  syntax  of  the  command  and  version  information,  the  MH     config-
+
+uration  options  will  be  listed.  MH     has  so  many  configuration  options,  that
+
+when debugging problems, this information is invaluable.
+
+
+
+The  MH       Profile
+
+
+There are two new profile entries worth noting:  MH-Sequences tells MH     the
+
+name  of  the  file  to  record  public  sequences  in.   Users  of  vm  ,  a  proprietary,
+
+visual  front-end  to  MH    ,  make  use  of  this  to  disable  the  public  sequences
+
+feature of MH    .
+
+      The profile entry Unseen-Sequence names those sequences which should
+
+be defined as those messages recently incorporated by inc  .  The show     program
+
+knows to remove messages from this sequence once it thinks they have been
+
+seen.  If  this  profile  entry  is  not  present,  or  is  empty,  then  no  sequences  are
+
+defined.  Otherwise, for each name given, the sequence is first zero'd and then
+
+each  message  incorporated  is  added  to  the  sequence.   As  such,  this  profile
+
+entry is rather analogous to the Previous-Sequence entry in the user's MH
+
+profile.
+
+      In  addition,  the  Alternate-Mailboxes  entry  in  the  profile  has  been  ex-
+
+panded to support simple wild-carding.  Also, the default for this profile entry
+________________________________________________
+    4 CP/M is a trademark of Digital Research Corporation.
+
+
+
+                                                           5
+
+
+
+
+is  now  the  user's  mail-id  at  any  host.  This  change  was  made  since  MH     can
+
+no longer reliably figure out what the user's real outgoing address looks like.
+
+      Finally, when the install-mh       program is automatically invoked by MH    , it
+
+won't prompt the user for information.  Instead, it notes that it's setting up
+
+the  default  environment.   In  addition,  the  MH     administrator  may  set-up  a
+
+file called mh.profile       in the MH     library area which is consulted by install-mh
+
+when initializing the user's .mh__profile      .
+
+
+
+The  MH       Context
+
+
+The folder   , scan   , and show     programs have been modified to update the user's
+
+MH     context prior to writing to the user's terminal.  This allows the MH     user
+
+interrupt output to the terminal and still have the expected context.  This is
+
+especially useful to interrupt long scan     listings.  This change also introduces
+
+a subtle bug between show     and messages denoted by the Unseen-Sequence.
+
+See show    (1) for the details.
+
+
+
+Addresses  and  822  support
+
+
+MH     now fully supports the RFC-822 routing syntax for addresses (it used to
+
+recognize the syntax, but ignore the information present).  In addition, there
+
+are three major modes for support of non-822 addressing in MH    :
+
+
+      -  BERK
+
+         This  is  useful  on  sites  running  SendMail      .  It  doesn't  support  full  822-
+
+         style  addressing,  in  favor  of  recognizing  such  formats  as  ACSnet,  and
+
+         so on.  For sites that can't run in an 822-compliant environment, this is
+
+         the option to use (at the price of sacrificing some of the power of 822-
+
+         style addressing).  This also drastically reduces the address formatting
+
+         facilities described below.
+
+
+      -  DUMB
+
+         Although not as liberal as BERK, the DUMB option is useful on sites
+
+         in  which  the  message  transport  system  conforms  to  the  822  standard,
+
+         but wants to do all the defaulting itself.
+
+
+      -  BANG
+
+         From out in left field, the BANG option favors UUCP      -style addressing
+
+
+
+                                                           6
+
+
+
+
+         over  822-style  addressing.  Hopefully  when  all  the  UUCP      sites  around
+
+         get  around  to  adopting  domain-style  addresses,  this  option  won't  be
+
+         needed.
+
+
+      The ap   program (mentioned momentarily) and the ali  program both sup-
+
+port  a  `-normalize'  switch  indicate  if  addresses  should  be  resolved  to  their
+
+"official" hostnames.
+
+
+
+New  Programs
+
+
+There  are  five  new  programs  available:  The  ap   program  is  the  MH     stand-
+
+alone address parser.  It's useful for printing address in various formats (and
+
+for  debugging  address  strings).   The  dp   program  is  similar,  but  works  on
+
+dates instead of addresses.
+
+      The msgchk       program checks for new mail, possibly using the Post Office
+
+Protocol, POP, described below.
+
+      A  new  receive  mail  hook,  the  rcvstore      program,  which  was  written  by
+
+Julian L. Onions is available.
+
+      Finally,  a  visual  front-end  to  msh    called  vmh     has  been  included.   (This
+
+program is discussed in greater detail later on.)
+
+
+
+Message  Numbering
+
+
+MH     now  no  longer  restricts  the  number  of  messages  which  may  reside  in  a
+
+folder (beyond that of system memory constraints).  This means that message
+
+numbers larger than 2000 are permissible.  Hopefully this will make life easier
+
+for people reading the network news using MH    .
+
+
+
+The  WhatNow  Shell
+
+
+In  mh.6   ,  there  is  now  the  concept  of  a  unified  What  now?   processor  that
+
+the  four  composition  programs,  comp    ,  dist ,  forw   ,  and  repl   all  invoke.   This
+
+permits  a  greater  flexibility  in  building  mail  applications  with  MH    .   As  a
+
+result, there's a new program, whatnow       , which acts as the default What  now?
+
+program.  Consult the whatnow       (1) manual entry for all the details.  The only
+
+important user-visible change is the headers option went away, which wasn't
+
+used that much anyway.
+
+
+
+                                                           7
+
+
+
+
+      The  only  other  thing  worth  noting  is  that  unless  MH    has  been  compiled
+
+with  the  UCI  option,  the  user's  $HOME/.signature               file  is  not  consulted  for
+
+the user's personal name.
+
+
+
+Format  Strings
+
+
+A  general  format  string  facility  has  been  added  to  allow  MH     users  to  tailor
+
+the output of certain commands.
+
+      The  inc ,  scan   ,  ap ,  and  dp   programs  all  consult  a  file  containing  format
+
+strings.  Format strings, which look a lot like printf    (3) strings, give these MH
+
+commands precise instructions on how to format their output.
+
+      As  a  result,  the  inc   and  scan    programs  no  longer  have  the  `-size',  `-
+
+nosize',  `-time',  `-notime',  `-numdate',  and  `-nonumdate'  switches.   These
+
+switches  have  been  replaced  with  the  `-form formatfile'  switch  and  the
+
+`-format string'  switch.   The  former  directs  the  program  to  consult  the
+
+named file for the format strings.  The latter directs the program to use the
+
+named  string  as  the  format.  To  get  the  behavior  of  the  old  `-time'  option,
+
+use the `-form scan.time' option.  Similarly, to get the effect of `-size', use
+
+`-form scan.size'.
+
+      A fun form to use is `-form scan.timely' with scan   .  Try it sometime.
+
+      The repl   command uses a file containing format files to indicate how the
+
+reply  draft  should  be  constructed.  Note  that  reply  templates  prior  to  mh.6
+
+are incompatible with mh.5    .5  Don't worry though, it's quite easy to convert
+
+the templates by hand.  (Those clever enough to have written a reply template
+
+to begin with won't have any  problem.)
+
+      Similarly,  when  the  forw    program  is  constructing  a  digest,  it  uses  a  file
+
+containing format strings to indicate how to build the encapsulating draft.
+
+      Finally, you can use these facilities in mhl    as well.
+
+
+
+News
+
+
+The depreciated MH     news system (from mh.1    ) is now de-supported.  Use the
+
+"hoopy" BBoards facility instead.
+________________________________________________
+    5 In fact, reply templates between mh.6    and MH    #6.5 are imcompatible.
+
+
+
+                                                           8
+
+
+
+
+BBoards
+
+
+MH     maintainers take note:  the default home directory for the bboards login
+
+has  changed  from  /usr/bboards/           to  /usr/spool/bboards/              .   Use  the  bbhome
+
+directive  in  your  MH    configuration  file  to  set  it  back  to  the  old  value  if  you
+
+wish.
+
+      In  addition,  the  aliases  field  for  a  BBoard  in  the  BBoards  file  is  now
+
+deemed  useful  only  for  addressing,  not  for  user  input  to  bbc  .   This  means
+
+when  giving  the  name  of  a  BBoard  to  bbc ,  only  the  official  name  should  be
+
+used.
+
+      A  final  note  for  mailsystem  maintainers:   the  MMDF-II         BBoards  chan-
+
+nel  and  the  SendMail       BBoards  mailer  have  been  modified  to  use  the  stan-
+
+dard message encapsulation format when returning failed messages to the list
+
+maintainer.  This means that the failure notices that the maintainer receives
+
+can simply be burst   .
+
+
+
+New  Switches  in  bbc
+
+
+The bbc   program permits you to specify the mshproc to use on the command
+
+line by using the `-mshproc program' option.  There's also a `-rcfile file'
+
+option  which  does  "the  obvious  thing".   In  addition,  options  which  aren't
+
+understood by bbc   are passed along to the mshproc.
+
+      In  addition,  the  following  commands  pass  any  unrecognized  switches  on
+
+to the program that they invoke:  bbc  , next   , show    , prev   , and vmh    .
+
+
+
+Distributed  BBoards
+
+
+If both BBoards and POP (see the next section) are enabled, then distributed
+
+BBoards  can  be  supported  on  top  of  the  POP  service.  This  allows  the  MH
+
+user  to  read  BBoards  on  a  server  machine  instead  of  the  local  host  (which
+
+saves  a  lot  of  wasted  disk  space  when  the  same  BBoards  are  replicated  sev-
+
+eral  times  at  a  site  with  several  hosts).   See  the  Administrator's  Guide  for
+
+information on how this can be made completely transparent to the MH     user.
+
+      If you have several machines at your site running 4.2bsd UNIX and con-
+
+nected by an Ethernet6  (or other high-speed LAN), you want  this software.
+________________________________________________
+    6 Ethernet is a trademark of the Xerox Corporation.
+
+
+
+                                                           9
+
+
+
+
+Visual  Front-End  to  msh
+
+
+A  simple  window  management  protocol  has  been  implemented  for  MH     pro-
+
+grams  that  might  wish  to  act  as  a  back-end  to  a  sophisticated  visual  front-
+
+end.
+
+      The  first  implementation  of  a  server  side  (front-end)  program  is  vmh   ,
+
+which uses curses    (3) to maintain a split-screen interface.  Perhaps look for a
+
+mhtool      program for the SUN next!
+
+      The  msh    program  has  been  modified  to  speak  the  client  side  (back-end)
+
+of  this  protocol,  if  so  directed.  At  present,  msh    is  the  only  program  in  the
+
+MH     distribution which implements the client side of the window management
+
+protocol.
+
+
+
+Updates  in  msh
+
+
+Prior to quitting, the msh     command now asks if the packf    'd file you've been
+
+perusing  should  be  updated  if  you've  modified  it  and  the  file  is  writable  by
+
+you.  The file can be modified by using burst   , rmm     , rmm     , or sortm     commands.
+
+The file can also be modified by using the refile   command without the `-link'
+
+option.  (Or  course,  the  `-link'  option  doesn't  actually  link  anything  to  the
+
+file.)
+
+
+
+Distributed  Mail
+
+
+MH     now  contains  a  powerful  facility  for  doing  distributed  mail  (having  MH
+
+reside  on  a  host  different  than  the  message  transport  agent).   For  general
+
+information,  consult  either  the  MH.5:  How  to  process  200  messages  a  day
+
+and  still  get  some  real  work  done  paper,  or  the  MH:  A  Multifarious  User
+
+Agent  paper.   For  specific  information,  consult  the  Administrator's  Guide.
+
+Here's a brief synopsis:
+
+      This  POP  facility  in  MH     is  based  on  a  modification  of  the  ARPA  Post
+
+Office Protocol (POP). A POP subscriber  is a remote user, on a POP client
+
+host, that wishes to pick-up mail on a POP service  host.
+
+      There are two ways to administer POP:
+
+
+      -  Naive Mode
+
+         Each user-id in the passwd      (5) file is considered a POP subscriber.  No
+
+
+
+                                                           10
+
+
+
+
+         changes are required for the mailsystem on the POP service host.  How-
+
+         ever,  this  method  requires  that  each  POP  subscriber  have  an  entry  in
+
+         the password file.  The POP server will fetch the user's mail from wher-
+
+         ever  maildrops  are  kept  on  the  POP  service  host.  This  means  that  if
+
+         maildrops  are  kept  in  the  user's  home  directory,  then  each  POP  sub-
+
+         scriber must have a home directory.
+
+
+      -  Smart Mode
+
+         This  is  based  on  the  notion  that  the  list  of  POP  subscribers  and  the
+
+         list  of  login  users  are  completely  separate  name  spaces.   A  separate
+
+         database (similar to the BBoards       (5) file) is used to record information
+
+         about each POP subscriber.  Unfortunately, the local mailsystem must
+
+         be  changed  to  reflect  this.   This  requires  two  changes  (both  of  which
+
+         are simple):
+
+
+             1.  Aliasing
+
+                 The aliasing mechanism is augmented so that POP subscriber ad-
+
+                 dresses  are  diverted  to  a  special  delivery  mechanism.  MH     comes
+
+                 with  a  program,  popaka    (8),  which  generates  the  additional  infor-
+
+                 mation to be put in the mailsystem's alias file.
+
+             2.  Delivery
+
+                 A special POP delivery channel (for MMDF-II       ) or POP mailer (for
+
+                 SendMail      )  performs  the  actual  delivery  (mh.6     supplies  both).  All
+
+                 it really does is just place the mail in the POP spool area.
+
+
+         Clever  mailsystem  people  will  note  that  the  POP  mechanism  is  really
+
+         a special case of the more general BBoards mechanism.
+
+
+These two different philosophies are not compatible on the same POP service
+
+host:  one or the other, but not both, may be run.
+
+      In  addition,  there  is  one  user-visible  difference,  which  the  administrator
+
+controls  the  availability  of.   The  difference  is  whether  the  POP  subscriber
+
+must supply a password to the POP server:
+
+
+      -  ARPA standard method
+
+         This  uses  the  standard  ARPA  technique  of  sending  a  username  and  a
+
+         password.  The  appropriate  programs  (inc  ,  msgchk     ,  and  possibly  bbc  )
+
+         will prompt the user for this information.
+
+
+
+                                                           11
+
+
+
+
+      -  UNIX remote method
+
+         This uses the Berkeley UNIX reserved port method for authentication.
+
+         This requires that the two or three mentioned above programs be setuid
+
+         to root.  (There are no known holes in any of these programs.)
+
+
+These  two  different  philosophies  are  compatible  on  the  same  POP  service
+
+host:  to selectively disable RPOP for hosts which aren't trusted, either mod-
+
+ify the .rhosts     file in the case of POP subscribers being UNIX logins, or zero
+
+the  contents  of  network  address  field  of  the  pop  (5)  file  for  the  desired  POP
+
+subscribers.
+
+      The  inc   command  also  has  two  other  switches  when  MH     is  enabled  for
+
+POP: `-pack file' and `-nopack'.  Normally, inc   will use the POP to incor-
+
+porate mail from a POP service host into an MH     folder (+inbox).  However,
+
+there  are  some  misguided  individuals  who  prefer  to  msh    to  read  their  mail-
+
+drop.  By  using  the  `-pack file'  option,  these  individuals  can  direct  inc   to
+
+fetch  their  maildrop  from  the  POP  service  host  and  store  it  locally  in  the
+
+named file.  As expected, inc   will treat the local file as a maildrop, performing
+
+the  appropriate  locking  protocols.  And,  if  the  file  doesn't  exist,  the  user  is
+
+now asked for confirmation.
+
+
+
+Rcvmail  hooks
+
+
+In order to offer users of MH     increased rcvmail hook functionality, the slocal
+
+program has been upgraded to support the semantics of the MMDF-II         mail-
+
+delivery  mechanism.   This  means  that  users  of  mh.6     can  maintain  identi-
+
+cal  .maildelivery         files  regardless  of  the  underlying  transport  system.    See
+
+mhook      (1) for all the details.
+
+
+
+Change  in  rcvdist
+
+
+The  rcvdist    rcvmail  hook  now  uses  the  MH     formatting  facility  when  redis-
+
+tributing a message.
+
+
+
+Field  change  in  rcvpack
+
+
+The rcvpack      rcvmail hook now adds the field name Delivery-Date: instead
+
+of Cron-Date: to messages it pack    s.
+
+
+
+                                                           12
+
+
+
+
+GNU  Emacs  Support
+
+
+James  Larus'  mh-e     macro  package  for  GNU  Emacs  (version  17)  is  included
+
+in the distribution.  When loaded in Emacs, this provides a handy front-end.
+
+
+
+Other  Changes
+
+
+Here's the miscellany:
+
+
+
+Continuation  Lines
+
+
+Alias files used by MH    , display templates used by mhl   , and format files used
+
+by  forw  ,  repl ,  and  scan    all  support  a  standard  continuation  line  syntax.  To
+
+continue  a  line  in  one  of  these  files,  simply  end  the  line  with  the  backslash
+
+character  (`n').   All  the  other  files  used  by  MH     are  in  822-format,  so  the
+
+822-continuation mechanism is used.7
+
+
+
+Default  Date  Format
+
+
+MH      now  uses  numeric  timezones  instead  of  locally-meaningful  alpha  time-
+
+zones  when  generating  mail.   This  change  was  made  to  encourage  the  use
+
+of  unambiguous,  globally-meaningful  timezone  strings.   A  local  configura-
+
+tion option can disable this correct behavior.  All of the mhl    templates have
+
+been  modified  to  use  locally-meaningful  alpha  timezones  when  displaying
+
+messages.
+
+
+
+New  switch  in  ali
+
+
+The ali  command now has a `-noalias' switch to prevent system-wide aliases
+
+from being interpreted.
+
+
+
+Modifications  to  show
+
+
+The `-format', `-noformat', `-pr', and `-nopr' options to show     have gone away
+
+in favor of a more general mechanism.  The `-showproc program' option tells
+________________________________________________
+    7 Looking back, it would have been best had all files in MH    used the 822-format.
+
+
+
+                                                           13
+
+
+
+
+show      (or  next    or  prev   )  to  use  the  named  program  as  the  showproc.   The
+
+`-noshowproc' option tells show    , et.  al., to use the cat  (1) program instead of
+
+a showproc.  As a result, the profile entry prproc is no longer used.
+
+
+
+Switch  change  in  inc
+
+
+The  `-ms ms-file'  switch  in  inc   has  been  changed  to  `-file name'  to  be
+
+more consistent.
+
+
+
+Front-End  to  mhl
+
+
+When  outputting  to  a  terminal,  the  mhl    program  now  runs  the  program
+
+denoted  by  the  profile  entry  moreproc.    If  this  entry  is  not  present,  the
+
+default  is  the  UCB  more     program.   If  the  entry  is  non-empty,  then  that
+
+program is spliced between mhl    and the user's terminal.  The author uses the
+
+less   program as his moreproc.
+
+      Of  course,  if  mhl    isn't  outputting  to  a  terminal,  then  moreproc  is  not
+
+invoked.
+
+      Finally, to aid in the construction of replies, a prefix string may be speci-
+
+fied for the body component of the message being replied-to.  Simply use the
+
+component= construct in mhl    for body:.
+
+
+
+Confirmation  in  packf
+
+
+If the file specified by the `-file name' switch doesn't exist, the user is now
+
+asked for confirmation.
+
+
+
+Complex  Expressions  in  pick
+
+
+The pick    command now handles complex boolean expressions.
+
+
+
+Defaults  change  in  prompter  and  burst
+
+
+The  `-prepend'  option  is  now  the  default  in  prompter      .   The  `-noinplace'
+
+option is now the default in burst   .
+
+
+
+                                                           14
+
+
+
+
+Fcc:s  and  post
+
+
+If multiple Fcc:s for a message are specified during posting, post   will try much
+
+harder to preserve links.
+
+
+
+Interactive  option  in  rmf
+
+
+The  rmf    program  has  been  changed  to  support  an  `-interactive'  switch.
+
+If  given,  then  the  user  is  prompted  regarding  whether  the  folder  should  be
+
+deleted.  If  the  folder  to  be  removed  is  not  given  by  the  user,  this  switch  is
+
+defaulted to on.
+
+
+
+Trusted  Mail  Interface
+
+
+MH     now has an interface for so-called "trusted mail" applications.  Although
+
+the modifications to MH     to support this are in the public domain, the actual
+
+library that MH     uses is not.  Contact Professor David J. Farber (Farber@UDel)
+
+for more information.
+
+
+
+References
+
+
+[MRose85]          Marshall  T.  Rose  and  John  L.  Romine.  The  Rand  MH  Message
+
+                   Handling  System:   User's  Manual.   Department  of  Information
+
+                   and Computer Science, University of California, Irvine, mh.6     edi-
+
+                   tion, November, 1985.  UCI Version.
+
+
+
+                                                           15
diff --git a/docs/historical/multifarious.pdf b/docs/historical/multifarious.pdf
new file mode 100644
index 0000000..25d07ed
Binary files /dev/null and b/docs/historical/multifarious.pdf differ
diff --git a/docs/historical/multifarious.txt b/docs/historical/multifarious.txt
new file mode 100644
index 0000000..195c2aa
--- /dev/null
+++ b/docs/historical/multifarious.txt
@@ -0,0 +1,2284 @@
+
+
+
+
+                               MH:  A  Multifarious  User  Agent
+
+
+                                              Marshall T. Rose
+
+                                 Member, Research Technical Staff
+
+                          Northrop Research and Technology Centery
+
+
+
+                                             Einar A. Stefferud
+
+                         President, Network Management Associatesz
+
+                    and Visiting Lecturer, University of California, Irvine
+
+
+
+                                               Jerry N. Sweet
+
+                                        Member, Technical Staff
+
+                                        Local Network Systems./
+
+
+
+                                                  Abstract
+
+
+The UCI version of the Rand Message Handling System (MH) is discussed, including
+
+important  extensions.  MH  is  a  powerful  user  agent  which  operates  in  the  ARPA
+
+Internet  and  UUCP  environments.   In  addition  to  the  basic  functions  provided
+
+by a user agent,  such as reading and sending mail,  MH has several distinguishing
+
+characteristics  which  give  the  user  additional  message  handling  capabilities.   In
+
+particular,  MH  provides  mechanisms  for  organizing  messages,  tailoring  its  own
+
+behavior, and extending its functions.
+
+
+This  document  describes  MH  from  several  perspectives.   Particular  emphasis  is
+
+given to:  the MH user environment, advanced features of MH which have proven to
+
+be particularly useful for sophisticated users of electronic mail,  MH's potential as
+
+a record manager, and MH as a part of a distributed mail environment.  Although
+
+MH as been widely used since its creation in 1979, a discussion of its perspectives
+
+and functionality has not appeared in the open literature.
+
+
+________________________________________
+y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
+
+Computer mail: MRose% NRTC@USC-ECL
+z 17301 Drey Lane, Huntington Beach, CA 92647. Telephone: 714/842-3711.
+
+Computer mail: EStefferud@ICS.UCI.EDU
+./ 130 McCormick Avenue, Suite 102, Costa Mesa, CA 92626. Telephone: 714/754-6631.
+
+Computer mail: JSweet@ICS.UCI.EDU
+
+
+                               MH:  A  Multifarious  User  Agent
+
+
+
+Introduction
+
+       The UCI version of the Rand Message Handling System, MH, is a user agent.
+
+In the interests of brevity, we dispense with the usual definition of terms, refer the
+
+reader to Figure 1, and simply note that MH is not responsible for delivering mail.
+
+Rather,  it interacts with a message  transport  system,  MTS, at two interfaces:  it
+
+sends mail by placing it through a posting slot to the MTS, and it receives mail by
+
+retrieving it through a delivery slot from the MTS. Besides these two MTS-specific
+
+activities, the tasks which MH addresses are:  the composition of messages (which
+
+may,  or  may  not,  be  in  reference  to  previously  sent  messages),  the  reading  of
+
+messages, and the organization of messages.
+
+
+       MH  was  originally  developed  by  the  Rand  Corporation,  and  initially  was
+
+proprietary  software.   The  Department  of  Information  and  Computer  Science
+
+at  University  of  California,  Irvine,  shortly  after  joining  the  Computer  Science
+
+Network  (CSnet),  acquired  a  copy  of  MH,  and  began  additional  development  of
+
+the software.  Since that time, the Rand Corporation has declared MH to be in the
+
+public domain, and the UCI version of MH has passed through four major releases.
+
+
+       Much credit must be given to the initial designers and implementors of MH:
+
+Bruce Borden, Stockton Gaines, and Norman Shapiro.  Although MH has suffered
+
+significant  development  at  UCI  since  Rand's  initial  release,  the  fundamental
+
+concepts  of  MH's  environs  have  remained  nearly  unchanged.   In  addition,  the
+
+current maintainers of MH gratefully acknowledge the comments of the many sites
+
+which have run various releases of MH in the past.
+
+
+       MH  runs  on  different  versions  of  the  UNIX1  operating  system  (such  as
+
+4.2bsd  UNIX  and  various  flavors  of  v7  UNIX).  In  addition,  MH  supports  four
+
+different  MTS  interfaces:   SendMail[EAllm83],  the  standard  mailer  for  4.2bsd
+
+systems;  MMDF[DCroc79]  and  MMDF-II[DKing84],  the  Multi-Channel  Memo
+
+Distribution  Facility  developed  by  the  University  of  Delaware  which  forms  the
+
+software-backbone  for  CSnet[DCome83]  mail  relays  service;  SMTP,  the  ARPA
+
+Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
+
+
+       The organization of this paper is straight-forward, given space considerations.
+
+Initially, the MH philosophy of mail handling is presented, along with a description
+
+of  the  environment  which  the  MH  user  is  given  to  process  mail.  Following  this,
+
+certain advanced features of MH are discussed in more detail.  In particular,  the
+
+
+________________________________________
+1  UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ Copyright fcl1985, North Holland Publishing Company                                                                1
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     2
+______________________________________________________________________________________________________________________
+
+
+
+                UA                                                                                UA
+
+
+
+   POSTING                                                                                            RECEIPT
+
+
+
+                                                        MTS
+
+
+
+               MTA                  MTA                  : : :                : : :              MTA
+
+                                                              RELAYING
+
+
+
+                                                    Figure 1
+
+___________________________________________________MTS_model__________________________________________________________
+
+
+
+notion of a draft folder is introduced, which permits the handling of multiple drafts
+
+during composition.  In addition, message selection facilities are described.  Next,
+
+two  different  aspects  of  MH's  power  as  a  software  system  are  discussed:  record
+
+handling, in which MH facilitates record processing systems; and, how MH can be
+
+employed in a distributed mail environment.  This latter section raises questions
+
+as  to  the  location  of  the  posting  and  delivery  slots,  along  with  authentication
+
+mechanisms.  Finally, we conclude by discussing areas of future development which
+
+MH may endure.
+
+
+       Although  familiarity  with  MH  is  not  assumed  on  the  part  of  the  reader,
+
+some knowledge of the UNIX operating system is useful.  Appendix A gives a short
+
+synopsis of the MH commands.
+
+
+
+The MH Philosophy
+
+       Although MH has many traits which tend to differ it from other user agents,
+
+the design aspect which fundamentally influences the interface between MH and
+
+the user is that it is composed of many small programs instead of one very large
+
+one.   This  architecture  gives  MH  much  of  its  strength,  since  intermediate  and
+
+advanced users are able to take advantage of this flexibility.
+
+
+       The key to this flexibility is that the UNIX shell (usually the C shell or the
+
+Bourne shell), is the user's interface to MH. This means that when handling mail,
+
+the entire power of the shell is at the user's disposal in addition to the facilities
+
+which  MH  provides.  Hence,  the  user  may  intersperse  mail  handling  commands
+
+with other commands in an arbitrary fashion, making use of command handling
+
+capabilities that the user's shell provides.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     3
+
+
+       Furthermore,  rather than storing messages in a complicated data structure
+
+within a monolithic file, in MH, each message is a UNIX file, and each folder (an
+
+object which holds groups of messages) is a UNIX directory.  That is, the directory
+
+and  file  structure  of  UNIX  is  used  directly.  As  a  result,  any  UNIX  file-handling
+
+command can be applied to any message.
+
+
+       To the novice,  this may not make much sense or may not seem important.
+
+From three years of observation,  we have seen that as users of MH have become
+
+more  experienced  they  have  found  this  capability  to  be  quite  attractive.   In
+
+addition,  this  approach  is  often  quite  pleasing  to  system  implementors,  because
+
+it minimizes the amount of coding to be performed and, given a modular design,
+
+changes to the software system can be maintained easily.  Our empirical findings
+
+confirm our theoretical expectations regarding the MH architecture.
+
+
+       Having described how MH fits into the UNIX environment,  we now discuss
+
+the mail handling environment which is available to the MH user.
+
+
+The MH Environs
+
+       MH  provides  a  complementary  environment  to  the  user's  shell.  While  the
+
+shell maintains a context related to the user's focus in the file system (a current
+
+working  directory ), mail handling is performed in a separate mail folder context.
+
+Operations  on  mail  can  therefore  be  performed  entirely  without  regard  to  the
+
+current file system context, although MH does not prevent the user from making
+
+use of that context.  Certain mail handling functions do make use of information
+
+maintained by the shell.  For instance, by setting certain shell parameters, called
+
+environment variables, alternate mail handling contexts can be selected.
+
+
+       MH conventions often have direct analogs to shell or file system conventions.
+
+The shell has a current working directory;  MH has a current mail folder.  When
+
+the user begins a session on the system,  the user's "home directory" is the base
+
+context; MH's default base area, the Mail directory, is found under the user's home
+
+directory.  The user's default shell parameters are set upon beginning a new session
+
+from a startup profile (called .profile   for sh users or .cshrc   for csh users); the default
+
+parameters for MH commands are taken from a file called .mh_profile      in the user's
+
+home directory.  The shell has an environment ; MH has a context     file.  Each of the
+
+user's directories has files; each of the user's MH folders has messages.
+
+
+       These parallels have a basis not only in MH's high level mail handling model,
+
+but also in the way low level shell and file system conventions have been abstracted
+
+to implement MH conventions.  Directories are folders; files are messages.  The Mail
+
+directory forms the root of a virtual file subsystem within which the user operates
+
+on mail without disturbing files outside this mail handling domain.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     4
+______________________________________________________________________________________________________________________
+
+
+
+        $HOME/      (user's home directory)
+
+
+
+    .mh_profile                           Mail
+
+
+
+      context             inbox/           mhl.format          replcomps             drafts/            chron/
+
+
+
+                               1      2     3                               1
+            sequences                                                                 yr.1984/         yr.1985/
+
+
+
+                                                    Figure 2
+
+                                             MH File Subsystem
+
+__________________________________________(directories_are_shaded)____________________________________________________
+
+
+
+The MH Profile
+
+       The  .mh_profile      contains  plaintext  that  describes  the  user's  default  mail
+
+handling parameters.  An example of an elaborated profile is shown in Figure 3.
+
+
+       Each line in the profile consists of an MH parameter name terminated with
+
+a colon (`:')  followed by parameter values.  In this example, "global" parameters
+
+are listed in the first few lines, with program-specific parameters following.  Each
+
+MH program examines global parameters as well as any parameter with the same
+
+name by which the program was invoked.  For example, the comp program, which
+
+is used to compose new messages to be sent, examines the entries:
+
+
+
+             Path___:  The path parameter specifies the name of the MH root directory.
+
+                       This is normally named Mail.
+
+
+           Editor____: The  editor  parameter  specifies  which  text  editor  is  first  invoked
+
+                       to create the header information and body of a message draft.  In
+
+                       most cases, this editor is the MH default editor, prompter.
+
+
+   Draft-Folder______: This parameter specifies a folder within which new message drafts
+
+                       are  to  be  created.  The  draft  folder  mechanism  is  an  advanced
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     5
+______________________________________________________________________________________________________________________
+
+Path:  Mail
+Editor:  prompter
+prompter-next:  emacs
+Folder-Protect:  700
+Msg-Protect:  600
+Previous-Sequence:  pseq
+Alternate-Mailboxes:  jsweet@uci-icse,  jsweet@uci-750a
+Draft-Folder:  drafts
+Sequence-Negation:  not
+bbc:         -quiet
+bboards:   system  mh-workers  sf-lovers  whimsey
+comp:       -form  mycomponents
+dist:       -annotate  -inplace
+folder:     -noheader
+forw:       -annotate  -inplace  -format
+mhl:         -noclear
+next:       -noheader
+prev:       -noheader
+prompter:  -prepend
+repl:       -annotate  -inplace  -cc  me
+send:       -format  -msgid
+scan:       -noheader  -time
+show:       -noheader  -format
+showproc:  mhl
+
+
+                                                    Figure 3
+
+___________________________________________Elaborated_MH_Profile______________________________________________________
+
+
+
+                       feature of MH that is given separate treatment in a later segment
+
+                       of this paper.
+
+
+             comp____: The  program-specific  parameter  examined  by  comp  lists  user-
+
+                       default options.
+
+
+
+Other programs invoked by comp (e.g.  prompter and send ) would examine their
+
+own  profile  entries  as  well.  MH  programs  have  reasonable  compiled-in  defaults
+
+and also permit options to be specified on the shell command line with which the
+
+programs are invoked.  The order of override precedence is:  command line options
+
+first, .mh_profile      options second, and compiled-in defaults last.
+
+
+       Each program option is prefixed by a dash (`-') following the UNIX convention.
+
+Unlike most UNIX-style options, however, the options are words rather than single
+
+letters.   An  option  may  be  abbreviated  to  an  unambiguous  prefix.   Each  MH
+
+program  has  a  `-help'      option  that  displays  a  brief  summary  of  the  program's
+
+available options.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     6
+
+
+Folders and Messages
+
+       In a typical paper-oriented office, new correspondence arrives and is stacked
+
+in an "in box", while outgoing correspondence is placed in an "out box".  Processed
+
+material  is  stored  in  appropriately  labelled  folders  and  filed  away  for  future
+
+reference.  This state of affairs is modelled in MH with folders and messages, which
+
+are simply text files (one message per file) stored under the folder directories.  Most
+
+of the user's folders are kept under the Mail directory.
+
+
+       A  folder  is  given  an  alphanumeric  name  permissible  within  the  UNIX  file
+
+system structure, and each message stored therein is given a numeric name in the
+
+range  1..1999.  The  upper  bound  on  message  numbers  was  selected  for  efficient
+
+access to an internal representation,  an array of bits (a "bit set"),  with each bit
+
+indicating the presence or absence of a message with a number in the range 1..1999.
+
+This internal representation also restricts the order of multiple message reference
+
+to  an  ascending  numerical  sequence.   Other  representations  have  been  studied
+
+(e.g., an unsorted sparse array of integers), but have been rejected for reasons of
+
+efficiency.  Folders may contain subfolders, corresponding to UNIX tree-structured
+
+directories.  For  the  sake  of  completeness,  it  might  be  said  that  "sub-messages"
+
+exist insofar as message "digests", which nest messages inside other messages, are
+
+supported by certain advanced MH functions.
+
+
+       The current working folder is the default folder selected for almost all MH
+
+commands.   To  select  explicitly  a  folder  for  mail  handling  commands  entails
+
+specifying the name of the folder, prefixing the name with a plus-symbol (`+').  An
+
+example is:
+
+
+           refile 1 2 3 +chron/yr.1984
+
+
+This command re-files the selected messages (1 ,  2,  and 3  here) from the current
+
+working folder to a subfolder under the folder chron     named yr.1984    .  To see the
+
+folder/subfolder relationship, refer to Figure 2.
+
+
+       The plus-symbol notation is specific to those folders immediately subordinate
+
+to the Mail directory.  This is analogous to "absolute pathnames" in UNIX_those
+
+files whose positions in the file system hierarchy are given starting with the system
+
+root, names prefixed with the slash character (`/').  To specify folders subordinate to
+
+the current working folder, an at-sign (`@') is substituted for (`+').  It is permitted
+
+to use UNIX dot notation to specify parent folders.  Referring to Figure 2,  if the
+
+current working folder were ``+chron/yr.1985''             , then the command
+
+
+           folder @../yr.1984
+
+
+selects  the  subfolder  yr.1984    in  the  parent  directory  chron  ,  as  the  new  current
+
+working folder.  While the current working folder is normally the default, it may
+
+be specified explicitly as ``@.''     .
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     7
+______________________________________________________________________________________________________________________
+
+To:  <reply-to_from>
+cc:  <?to_cc_me><to>,<cc>,<me>
+Subject:  <?subject>Re:  <subject>
+In-reply-to:  <?date><?message-id>Your  message  of  <date>.
+       <message-id>
+In-reply-to:  <?date><!message-id>Your  message  of  <date>.
+Fcc:  <?fcc><fcc>
+--------
+
+
+                                                    Figure 4
+
+_______________________________________Elaborated_Reply_Template______________________________________________________
+
+
+
+The Context File
+
+       The .mh_profile      contains static information about the user's preferences.  A
+
+context    file,  contained  in  the  Mail  directory,  contains  the  current  mail  handling
+
+environment information, which changes as different folders, messages, and named
+
+message lists (called message sequences ) are selected, created, and updated.  This
+
+information  is  retained  between  invocations  of  MH  commands,  and  is  preserved
+
+across system sessions.
+
+
+Templates
+
+       The  message  draft  composition  functions  (comp,  repl,  forw,  and  dist )  use
+
+certain default header formats, which may be changed by the user through the use
+
+of message templates.  The exact format of a template may vary among commands.
+
+An  example  of  an  elaborated  template  for  the  reply  command  repl  is  shown  in
+
+Figure 4.
+
+
+       This template specifies how the automatically-generated header for a draft
+
+message in reply to a source message is to be formatted.  The syntax is capable of
+
+directing output of header lines based on the presence or absence of other header
+
+lines in the source message.
+
+
+       Other kinds of templates are used to specify the display formats of messages,
+
+or to specify the way that messages are to be included in other messages.  This is
+
+similar to the functionality provided by BBN Hermes[HERMES], another powerful
+
+mail handling system for Tops202  based systems.
+
+
+Explaining All This to New Users
+
+       There  do  exist  people  who  do  not  like  MH.3  The  emerging  pattern  of
+
+complaints from such people indicates that MH accentuates their perceptions of
+
+the deficiencies of UNIX, to wit, lack of interactivity and lack of easily found help
+
+facilities.  Also,  some  feel  that  the  proximity  of  the  mail  handling  environment
+
+to the operating system is a distraction,  rather than an asset.  There have been
+
+________________________________________
+2  Tops20 is a trademark of Digital Equipment Corporation.
+3  At UCI, these people are reported to be weeded out at an early stage and quietly taken to the
+
+Ministry of Love to be made uncrimethinkful.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     8
+
+
+some attempts to make MH more accessible to users who prefer menu-oriented or
+
+monolithic mail system interfaces.4
+
+
+       In  truth,  users  new  to  UNIX  do  not  always  acclimate  to  MH  easily.   The
+
+command  set  is  undistinguishably  mixed  in  with  all  other  UNIX  utilities,  and  it
+
+is  not  easy,  without  aid  of  a  manual,  to  pick  out  the  necessary  commands.  MH
+
+does not provide any "hand-holding" to guide the user through a minimally useful
+
+command subset.
+
+
+       Another  problem  is  that  the  initial  default  user  profile  is  too  often  sparse,
+
+containing only a ``Path:''        parameter.  MH commands will perform adequately
+
+without specific information in the profile,  so new users often neglect optionally
+
+useful  MH  capabilities,  eventually  becoming  frustrated  with  the  limited  default
+
+capabilities,  yet  unable  to  determine  without  researching  through  the  user's
+
+manual, the necessary options that would solve their problems.
+
+
+       The currently available means for learning how to use MH are:
+
+
+
+                    -  One-on-one tutoring by knowledgeable MH users, which has so far
+
+                       shown the best results with new users.
+
+
+                    -  Consulting  the  MH  Tutorial [MRose84b],  or  the  MH  User's
+
+                       Manual [MRose85a].
+
+
+                    -  Using the msh ("MH shell") program as a training shell to read
+
+                       bulletin boards.  The msh command is an interactive program that
+
+                       provides some help messages and can list available MH commands.
+
+
+
+No  on-line  tutorial  materials  are  presently  distributed  with  the  mh.5  system,
+
+although  there  are  some  plans  in  the  works  to  provide  a  program  to  help  with
+
+setting  up  the  user  profile  that  would  also  provide  operational  tips  for  MH  and
+
+UNIX.
+
+
+       It should be noted that these perceived defects of MH do not affect its utility
+
+any  more  than  analogous  problems  with  any  operating  system  will  diminish  its
+
+actual  capabilities.  Users  may  quarrel  with  the  means  chosen  for  orchestrating
+
+MH, but the fact remains that MH is a very useful set of mail handling tools that
+
+is  flexible,  infinitely  interoperable  with  other  UNIX  text  handling  tools,  and  yet
+
+simple enough for new users to grasp once they are given the proper start.  The
+
+fact that better tutorial materials and training do not exist only means that some
+
+further work needs to be done in the area of user-education.
+
+
+
+________________________________________
+4  For  example,  mhe  from  Brian  Reid  of  Stanford  University  and  emh  from  Marshall  Rose  are
+
+instances of macro packages for James Gosling's EMACS extensible editor, while the hm program
+from Jim Guyton of the Rand Corporation is a monolithic MH interface.  As of this writing, none
+of these programs is documented in the literature.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                     9
+
+
+A Few Advanced Features
+
+       We now consider certain advanced features in MH. These features have been
+
+chosen to demonstrate some useful capabilities available to the MH user.  It should
+
+be noted that many capabilities of MH, such as shell scripts for extensibility, mail
+
+delivery hooks, the personal aliasing facility, and so forth, are not described here
+
+for lack of space.
+
+
+Draft Folders
+
+       The draft folder facility provides a method by which several message drafts can
+
+be simultaneously composed and maintained until sent.  The rationale for this is that
+
+partially composed message drafts,  perhaps elaborate sets of separate messages,
+
+can be incrementally completed, while a folder provides a consistent organization
+
+for drafts in progress.  This is comparable to similar situations in the "paper world"
+
+where contracts, business correspondence, and other communications, rather than
+
+being  created  serially  with  each  posted  in  turn  before  composing  the  next,  are
+
+usually left in various stages of completion before they are eventually mailed.
+
+
+       The ``Draft-Folder:''             parameter value in the MH profile is used to specify
+
+a default draft folder, where each draft is given a number and an "artificial" date
+
+stamp.  Provided that the proper header fields have been completed, a scan listing
+
+of  the  draft  folder  provides  a  summary  of  each  draft  in  progress:  to  whom  the
+
+message  is  to  be  sent,  the  subject,  the  date  of  the  draft's  initial  creation  and
+
+optionally, the current size of the draft in terms of characters.  Experienced users
+
+of MH may often keep as many as five to ten unfinished drafts in their draft folder.
+
+"Draft clutter" can be remedied easily with the rmm command.
+
+
+Message Selection
+
+       MH commands accept message sequence specifications to specify which `msg'
+
+or `msgs'      are to be operated upon.  Here are some examples:
+
+
+           scan 1 3 5 19 185
+
+
+to get a scan listing of messages 1, 3, 5, 19 and 185.
+
+
+           scan pseq
+
+
+to get a scan listing of whatever message sequence was given to the previous MH
+
+command (in this case 1, 3, 5, 19, and 185).
+
+
+           show first last
+
+
+to  get  a  display  of  the  first  and  last  messages  in  the  folder.  The  MH  sequences
+
+named ``first''       and ``last''      are system defined pseudo sequences which act like
+
+explicit sequences when given to MH commands.  Others are ``cur''     , ``next''      ,
+
+``prev''     ,  and  ``all''      which  respectively  specify  the  "current"  message,  the
+
+"next"  after  cur,  the  "previous"  message  before  cur,  or  "all"  messages  in  the
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   10
+
+
+current-folder.  The  scan  assumes  ``all''      while  show  assumes  ``cur''    ,  unless
+
+overridden  on  the  command  line.  Over-ride  precedence  is:  command-line  first,
+
+.mh_profile     second, and compiled-in default last.
+
+
+       Users can define additional sequences for similar use, but must avoid using
+
+reserved names.  A few optional sequence names have been preempted by MH, such
+
+as  ``pseq''       to  mean  the  "sequence  used  by  the  previous  MH  command,"  and
+
+``unseen''        to mean the "messages not yet seen by the user."  Sometimes these
+
+preempted names can be changed by resetting them in the user's MH profile, but
+
+these facilities are beyond the scope of this discussion.
+
+
+       The mark command can be used to set the values for user-defined sequences:
+
+
+           mark 1 3 5 -seq zzz
+
+           mark 4 5 9 -seq zzz -nozero
+
+
+will create a user-sequence named ``zzz''      and put the sequence ``1  3  5''      in it.
+
+The mark command assumes that any prior content in an existing user-sequence
+
+should  be  "zeroed"  before  the  new  sequence  value  is  recorded.   This  can  be
+
+prevented with a `-nozero'        switch on the command line,  to add ``4  5  9''      to
+
+the original ``1  3  5''      to yield ``1  3  4  5  9''     .
+
+
+           mark pseq zzz -seq zzznew
+
+
+will create a new sequence named ``zzznew''         and set its value to the combined
+
+(inclusive or) of the existing user-sequences in ``pseq''       and ``zzz''      for its value.
+
+
+       Another more powerful way to set the values of a user-sequence is with the
+
+pick command, which provides full string search capabilities:
+
+
+           pick -from mrose -seq yyy
+
+           pick -from mrose -seq yyy -list
+
+
+will  search  though  all  the  ``From:''       fields  in  the  current  folder  for  the  string
+
+``mrose''       and  place  the  list  of  "hits"  in  the  sequence  named  ``yyy''     .   The
+
+`-list'      switch  will  cause  the  resulting  list  to  also  be  displayed  on  the  user's
+
+terminal.  If no `-seq name'         switch is given,  pick will assume `-list'       and will
+
+simply display the resulting list of hits on the user's terminal.
+
+
+       This `-list'       behavior of pick allows users to take advantage of the UNIX
+
+backquoting facility to embed searches in other MH commands.
+
+
+           scan `pick -from mrose`
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   11
+
+
+will  produce  a  scan  listing  of  `-from mrose'          hits  because  the  UNIX  shell  will
+
+spawn a process to execute the ``pick -from mrose''                segment and return the
+
+`-list'      results as the message sequence to be scanned.
+
+
+           mark pseq -seq zzz
+
+
+could then be used to capture the "previous sequence" in zzz for later use.
+
+
+       One  last  facility  should  be  mentioned  here.  It  is  also  possible  to  negate  a
+
+sequence to specify a new sequence.  The default negation string is ``not''     .
+
+
+           scan notzzz
+
+           mark notzzz -seq zzznot
+
+
+will give the user a scan listing of all the messages in the current folder that are
+
+not  included  in  the  sequence  ``zzz''    .  The  mark  example  will  of  course  record
+
+the  negation  of  zzz  in  zzznot.  It  is  a  bad  idea  to  use  the  string  ``not''      as  the
+
+beginning of any user-sequence name, if ``not''      is defined as the negation string.
+
+(Users can choose a different negation string.)
+
+
+       From this discussion,  it should be clear that MH provides a uniform set of
+
+ways  to  capture  and  use  sequences  to  augment  the  user's  short-  and  long-term
+
+memory  and  to  manipulate  lists  of  interesting  messages.   User-sequences  are
+
+normally stored as RFC822 labeled text lines in a file (e.g., sequences) in the folder
+
+with the messages referred to in the sequence.  If a user does not have write access
+
+to a folder, then the MH mark and pick commands will create a "private" sequence
+
+in the user's context     file.  Switches are available to give the user control over the
+
+choice of `-private'        or `-public'        sequence options.
+
+
+       Since user-sequences are stored as ordinary text lines in RFC822 labeled fields,
+
+there is no prohibition against someone writing programs to perform any kind of
+
+useful  manipulation  on  MH  sequences.  Boolean  operators  can  be  implemented,
+
+or complex indexing structures could be developed to serve special purposes.  If a
+
+DBMS can utilize UNIX pathnames or MH `+folder'        and message names, then
+
+the full power of the DBMS might be applied.  The intention of MH development
+
+teams  has  always  been  to  leave  open  the  widest  possible  array  of  options  for
+
+later extension.  The only restrictions should be the user's ingenuity, programming
+
+prowess, and the available machine resources.  Unfortunately these resources always
+
+seem to be available in limited quantities.
+
+
+Distribution Lists
+
+       MH has a convenient interface to the UCI BBoards facility[MRose84a].5  This
+
+facility  permits  the  efficient  distribution  of  interest  group  messages  on  a  single
+
+
+
+________________________________________
+5  The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
+
+form under stand-alone MH.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   12
+
+
+host, to a group of hosts under a single administration, and to the ARPA Internet
+
+community.
+
+
+       Described simply, an interest group is composed of a number of subscribers
+
+with a common interest.  These subscribers post mail to a single address, known
+
+as a distribution address (e.g., MH-Workers@UCI). From this distribution address,
+
+a  copy  of  the  message  is  sent  to  each  subscriber.  Each  group  has  a  moderator,
+
+which is the person that runs the group.  This moderator can usually be reached
+
+at a special address, known as a request address (e.g., MH-Workers-Request@UCI).
+
+Usually,  the  responsibilities  of  the  moderator  are  quite  simple,  since  the  mail
+
+system handles distribution to subscribers automatically.  In some interest groups,
+
+instead of each separate message being distributed directly to subscribers, a batch
+
+of (related) messages are put into a digest format by the moderator and then sent
+
+to the subscribers.  Although this requires more work on the part of the moderator
+
+and introduces delays, such groups tend to be better organized.
+
+
+       Unfortunately, some problems arise with the scheme outlined above.  First, if
+
+two users on the same host subscribe to the same interest group, two copies of the
+
+message will be delivered.  This is wasteful of both processor and disk resources at
+
+that host.
+
+
+       Second, some groups carry a lot of traffic.  Although subscription to a group
+
+does indicate interest on the part of a subscriber, it is usually not interesting to get
+
+50 messages or so delivered to the user's private maildrop each day, interspersed
+
+with  personal  mail,  that  is  likely  to  be  of  a  much  more  important  and  timely
+
+nature.
+
+
+       Third, if a subscriber's address in a distribution list becomes "bad" somehow
+
+and causes failed mail to be returned,  the originator of the message is normally
+
+notified.  It is not uncommon for a large list to have several bogus addresses.  This
+
+results in the originator being flooded with "error messages" from mailers across
+
+the Internet stating that a given address on the list was bad.  Needless to say, the
+
+originator usually does not care if the bogus addresses got a copy of the message
+
+or not.  The originator is merely interested in posting a message to the group at
+
+large.  On the other hand, the moderator of the group does care if there are bogus
+
+addresses on the list, but ironically does not receive notification.
+
+
+       To  solve  all  of  these  problems,  the  UCI  BBoards  facility  introduces  a  new
+
+entity into the picture:  all interest group mail is handled by a special component of
+
+the mail system.  The distribution address maps to a special channel that performs
+
+several  actions.   First,  if  local  delivery  is  to  be  performed,  then  a  copy  of  the
+
+message is placed in a global maildrop for the interest group with a timestamp and
+
+a unique number.  Local users can read messages posted for the interest group by
+
+reading this "public" maildrop.  Second, if further distribution is to take place, a
+
+copy of the message is sent to the distribution address in such a way that if any of
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   13
+
+
+the addresses are bogus, failure notices will be returned to the local maintainer of
+
+the group address list, rather than the originator of the message.
+
+
+       This  scheme  has  several  advantages:  First,  messages  delivered  to  the  local
+
+host are processed and saved once in a globally accessible area.  The UCI BBoards
+
+facility supports software which allows a user to query an interest group for new
+
+messages and to read and process those messages in the MH-style.  Second, once
+
+a  host  administrator  subscribes  to  an  interest  group,  each  user  can  join  or  quit
+
+the list's readership without contacting anyone.  Third, a hierarchical distribution
+
+scheme can be constructed to reduce the amount of delivery effort.  Fourth, errors
+
+are  prevented  from  propagating.  When  an  address  on  the  distribution  list  goes
+
+bad, the list moderator who is immediately responsible for the address is notified.
+
+If a local moderator does not exist, then the local PostMaster is notified (not the
+
+global group moderator).
+
+
+       In addition to solving the problems outlined above, the UCI BBoards facility
+
+supports  several  other  capabilities.  BBoards  may  be  automatically  archived  in
+
+order  to  conserve  disk  space  and  reduce  processing  time  when  reading  current
+
+items.   Also,  the  archives  can  be  separately  maintained  on  tape  for  access  by
+
+interested researchers.
+
+
+       Special  alias  files  may  be  generated  which  allow  the  MH  user  to  shorten
+
+address type-in.  For example,  instead of sending to SF-Lovers@Rutgers,  a user
+
+of MH usually sends to ``SF-Lovers''           and the MH aliasing facility automatically
+
+makes the appropriate expansion in the headers of the outgoing message.  Hence,
+
+the user need only know the name of an interest group and not its global network
+
+address.
+
+
+       Finally, the UCI BBoards facility supports private interest groups using the
+
+UNIX  group  access  mechanism.   This  allows  a  group  of  people  on  the  same  or
+
+different machines to conduct a private discussion.
+
+
+       The practical upshot of all this is that the UCI BBoards facility automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+       MH provides three programs to deal with interest groups.  The bbc program
+
+is used to check on the status of one or more groups,  and to optionally start an
+
+MH shell on those groups which the user is interested in.  The bbl program can be
+
+used  to  perform  manual  maintenance  on  a  discussion  group  beyond  the  normal
+
+automatic  capabilities  of  the  UCI  BBoards  facility.   Finally,  the  msh  program
+
+implements  an  MH  shell  for  reading  BBoards,  in  which  nearly  all  of  the  MH
+
+commands are implemented in a single program.
+
+
+       Observant  readers  may  note  that  the  use  of  msh  is  contrary  to  the  MH
+
+philosophy of using relatively small, single-purposed programs.  Sadly, the authors
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   14
+
+
+admit that this is true.  In an effort to avoid some problems with shared-access and
+
+message naming conventions (which are beyond the scope of this paper), BBoards
+
+are  kept  in  maildrop  format  (monolithic)  instead  of  folders.  Some  research  has
+
+gone into overcoming this problem in order to restore MH's purity of purpose, but
+
+all solutions proposed to date are either unworkable or require significant recoding
+
+of MH's internals.
+
+
+Encapsulation
+
+       As  described  above,  some  interest  groups  appear  in  digest  form.   This
+
+means that the messages which appear in such a forum actually encapsulate other
+
+messages  in  their  body.   It  turns  out  that  the  generation  of  a  digest  is  not  at
+
+all  unlike  the  generation  of  a  draft  which  forwards  one  or  more  messages.   In
+
+RFC934[MRose85b],  a method is proposed to standardize message encapsulation
+
+for  the  ARPA  Internet  community.  MH  uses  this  method  for  the  generation  of
+
+digests, forwardings, and blind-carbon-copies.
+
+
+       A  key  requisite  for  using  an  encapsulation  technique  for  digests  and
+
+forwardings is the ability to later decapsulate the contents.  Without this ability,
+
+the forwarded messages are of little use to the recipients because they can not be
+
+distributed, forwarded, replied-to, searched-for, or otherwise processed as separate
+
+individual  messages.  In  the  case  of  a  digest,  a  bursting  capability  is  especially
+
+useful.  Not only does the ability to burst a digest permit a recipient of the digest
+
+to  reply  to  an  individual  digestified  message,  but  it  also  allows  the  recipient  to
+
+selectively process the other messages encapsulated in the digest.
+
+
+       For example,  a single digest issue usually contains more than one topic.  A
+
+subscriber may only be interested in a subset of the topic discussed in a particular
+
+issue.  With  a  bursting  capability,  the  subscriber  can  burst  the  digest,  scan  the
+
+headers,  and  process  those  messages  which  are  of  interest.   The  others  can  be
+
+ignored, if the user so desires.
+
+
+       Note  that  with  proper  encapsulation  technology,  one  can  argue  for  the
+
+re-distribution of messages simply becoming special cases of message forwarding.
+
+For  example,  the  NBS  Standard  for  Mail  Interchange[FIPS98]  and  the  recent
+
+CCITT  draft  on  Mail  Handling  Systems  standards[X.400]  both  discourage  the
+
+re-distribution facility in favor of forwarding by encapsulation.
+
+
+Encapsulation and Blind-Carbon-Copies
+
+       Many user agents support a blind-carbon-copy facility.  MH implements this
+
+using  a  form  of  encapsulation.  It  may  not  be  apparent  to  the  reader  as  to  why
+
+encapsulation of the original message is a good way to deliver blind-carbon-copies.
+
+With a blind-carbon-copy facility, two types of addressees are possible in the draft
+
+to be sent:  visible and blind.  The visible recipients are listed as addresses in the
+
+``To:''      and ``cc:''       fields,  and the blind recipients are listed in the ``Bcc:''
+
+fields of the draft.  The idea behind this facility is that copies of the draft which are
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   15
+
+
+delivered to the ``To:''      and ``cc:''      recipients should show the visible recipients
+
+only.
+
+
+       A  major  concern  with  a  blind-carbon-copy  facility  is  that  blind  recipients
+
+should be prevented from accidentally replying to the message in such a way that
+
+the visible recipients are included as addressees in the reply.
+
+
+       There are several methods to implement this facility.  Most rely on posting
+
+two drafts with the MTS. One draft is destined for visible recipients, and simply
+
+lacks the ``Bcc:''       fields of the original draft.  The second draft is destined for the
+
+blind recipients.  The question then arises as to what form this latter draft posted
+
+should take.
+
+
+       One  approach  might  be  to  disable  the  ``To:''      and  ``cc:''      fields  of  the
+
+draft sent to the blind recipients (e.g., by prefixing the string ``BCC-''       to these
+
+fields).  Unfortunately, this is often very confusing to the blind recipients because
+
+it differs from what the visible recipients got.  Although accidental replies are not
+
+possible,  it  is  often  difficult  to  tell  that  the  message  received  is  the  result  of  a
+
+blind-carbon-copy.
+
+
+       The method used by MH is to post two drafts, a visible draft for the visible
+
+recipients,  and  a  blind  draft  for  the  blind  recipients.  The  visible  draft  consists
+
+of  the  original  draft  without  any  ``Bcc:''      fields.  The  blind  draft  contains  the
+
+visible message as a forwarded message.  The headers for the blind draft contain
+
+the  minimal  RFC822  headers  (``From:''        and  ``Date:''      )  and,  if  the  original
+
+draft had a "Subject:"  field, then this header field is also included.  In addition,
+
+MH  alerts  the  recipient  that  the  message  is  a  blind-carbon-copy  by  placing  this
+
+information in the initial encapsulation information in the blind recipient's copy.
+
+This scheme prevents inadvertent replies while allowing the recipient full access to
+
+an exact copy of what was sent to the visible recipients.
+
+
+
+MH as a Record Handler
+
+       Although message format standards such as RFC822 (and its predecessors)
+
+were originally devised to facilitate computer processing of interpersonal messages,
+
+there  is  no  special  reason  why  the  concept  should  be  limited  to  interpersonal
+
+message processing.  Messages are just one of a variety of useful record forms that
+
+might  be  created  in  one  place  and  transfered  to  another  for  processing.  In  this
+
+regard,  RFC822  wisely  left  open  the  option  for  higher  level  applications  to  use
+
+arbitrary header names or field contents by proscribing MTS use of header names
+
+beginning with ``X-''     .
+
+
+       MH carries though on this idea by allowing the pick command to accept any
+
+arbitrary field name for string searches, so MH users can select on any arbitrary
+
+field name without prior definition.  Beyond this, since all messages are simply files
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   16
+
+
+in  UNIX  directories,  applications  can  be  developed  to  apply  any  programmable
+
+process to any selected message.
+
+
+       For example, a Time Card Form might be called up by an MH user with
+
+
+           comp -form timecomps
+
+
+to  enter  time  and  attendance  information  into  ``X-time: : ::''        fields  in  a  draft
+
+message record.  The timecomps        form would include the address of a supervisor
+
+who should validate the information, along with empty fields to be filled in with
+
+data.  In  fancy  applications,  this  might  be  done  with  a  sophisticated  interactive
+
+data entry tool which would validate entered information, but this is an open choice
+
+within the MH framework.  Another alternative would be to use a received message
+
+as  the  blank  form  to  add  a  degree  of  central  control  over  time  and  attendance
+
+reporting forms.
+
+
+       Receiving  supervisors  could  simply  register  approval  by  using  the  MH  dist
+
+command to resend subordinates' time cards to higher approval levels, or to send
+
+them  to  a  time  card  collection  address.   The  MH  dist  command  automatically
+
+inserts  "ReSent"  header  fields  showing  who  resent  it  and  the  resending  date.
+
+Alternatively, the MH forw command could be used to transfer a batch of approved
+
+time cards to the next processing station.  If desired, a new "approval" command
+
+could  be  programmed  to  provide  a  more  trusted  authentication,  perhaps  with
+
+encryption of the content.  Trusted mail systems, such as Trusted Mail6 [MRose85c],
+
+are becoming available for this purpose.
+
+
+       At  the  final  collection  destination,  an  automated  User  Agent  could  be
+
+programmed to directly load the data into the Time and Attendance DBMS by
+
+parsing and decoding the data contained in the ``X-time: : ::''        fields.  It might be
+
+noted that while the RFC822 does not restrict the internal forms of messages, it is
+
+necessary to conform to the interchange standard if specialized filters for message
+
+headers are not to be built to serve as export  laundries (a term originating with
+
+Stephen H. Willson to describe conformance transformations in Ada7 ).
+
+
+Mapping Between Record Modes (DBMS/MHS)
+
+       This time and attendance example suggests that it is possible to define one-to-
+
+one mappings between RFC822 fields and DBMS data elements.  For every DBMS
+
+data  element  definition,  there  is  a  potential  corresponding  RFC822  transferable
+
+equivalent  definition  which  can  facilitate  mail  transfers  of  record  information.
+
+Indeed, a large portion of the definitional work is already done where a Data Base
+
+has already been defined.  All that remains is to define the RFC822 equivalents.
+
+
+
+________________________________________
+6  Trusted Mail is a trademark of Trusted Technologies, Incorporated.
+7  Ada is a trademark of the Department of Defense (Ada Joint Program Office).
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   17
+
+
+       The  suggestion  that  a  batch  of  time  cards  be  forwarded  inside  a  "cover"
+
+message  implies  that  it  is  possible  in  the  MH  framework  to  recursively  bundle
+
+messages  within  messages,  and  be  able  to  recover  the  originals  for  separate
+
+processing  at  a  receiving  destination.  The  MH  burst  command  can  be  applied
+
+recursively for this purpose because MH encapsulation uses an unambiguous scheme
+
+to delimit messages that are enclosed inside other messages.  Thus,  it should be
+
+possible to extract a structured set of records from a DBMS and mail the set to a
+
+foreign site for processing, or reinsertion into another DBMS. As long as the DBMS
+
+data element definitions correctly correspond to the RFC822 definitions, it is not
+
+even necessary for the source and destination DBMS systems to be the same.
+
+
+       From this discussion,  it is concluded that the MH framework can be useful
+
+for building distributed record handling systems where people at widely scattered
+
+locations must create and submit record forms for processing at distant locations.
+
+This  might  prove  to  be  especially  effective  when  a  mail  system  is  also  needed
+
+for other communication purposes.  A network of sales offices is a good example,
+
+where  general  message  service  would  be  used  for  communications  with  remote
+
+manufacturing and distribution centers, and could also be used for an order entry
+
+system.
+
+
+       Another  example  might  be  for  structured  communications,  as  occur  in
+
+requisition and purchasing systems.  Requisitions could be filled in and mailed to
+
+approval offices, and resent or forwarded to others for action.  At some point, the
+
+requisitions could flow into other other more suitable processing systems as needed.
+
+At the very least, the ability to originate requisitions can be distributed to anyone
+
+with access to a mail system that can originate a proper requisition form.
+
+
+       As a last example, MH already supports group discussions with its BBoard
+
+facilities which allow for automatic sorting of mail by group address, with shared
+
+private  or  public  group  access  to  contributed  items.  As  has  been  shown  to  be
+
+possible with administrative record systems, there is no obvious limit to the ways
+
+that group discussion traffic might be organized into structured collections with
+
+indices,  annotations,  or  reference  pointers  to  aid  in  making  conference  archives
+
+more  useful.  Indeed,  MH  tools  could  even  be  used  to  feed  discussion  items  into
+
+existing conference systems.
+
+
+
+Distributed Mail
+
+       Next, we consider how MH might be used in a distributed mail environment.
+
+Two  schemes  are  discussed:  one  in  which  connectivity  is  high  and  connections
+
+are relatively "cheap", and one in which connectivity is low and connections are
+
+"expensive".
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   18
+
+
+The ARPA Internet Environs
+
+       The  ARPA  Internet  community  consists  of  many  types  of  heterogeneous
+
+nodes.   Some  hosts  are  large  mainframe  computers,  others  are  personal  work-
+
+stations.   All  communicate  using  the  milstd  TCP/IP  protocol  suite[IP,  TCP].
+
+Messages which conform to the Standard for the Format of ARPA Internet Text
+
+Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
+
+
+       On smaller nodes in the ARPA Internet it is often impractical to maintain
+
+a  message  transport  agent.  For  example,  a  workstation  may  not  have  sufficient
+
+resources (cycles, disk space) in order to permit an SMTP server and associated
+
+local  mail  delivery  system  to  be  kept  resident  and  continuously  running.
+
+Furthermore,  the  workstation  could  be  off-net  for  extended  periods  of  time.
+
+Similarly,  it  may  be  expensive  (or  impossible)  to  keep  a  personal  computer
+
+interconnected to an IP-style network for long periods of time.  In other words, the
+
+node is lacking the resource known as "connectivity".
+
+
+       Despite  this,  it  is  often  desirable  to  be  able  to  process  mail  with  MH  on
+
+these smaller nodes, and they often support a user agent to aid the tasks of mail
+
+handling.  To  solve  this  problem,  a  network  node  which  can  support  a  message
+
+transport  entity  (known  as  service  host)  offers  a  maildrop  service  to  these  less
+
+endowed nodes (known as client hosts).  The Post Office Protocol[JReyn84] (POP)
+
+is intended to permit a workstation to dynamically access a maildrop on a service
+
+host  to  pick-up  mail.8   The  level  of  access  includes  the  ability  to  determine  the
+
+number  of  messages  in  the  maildrop  and  the  size  of  each  message,  as  well  as  to
+
+retrieve and delete individual messages.  More sophisticated implementations of the
+
+POP server are able to distinguish between the header and body portion of each
+
+message, and send n lines of a message to the POP client.  This capability is useful
+
+in thinly connected environments where conservation of bandwidth is important.
+
+By utilizing a more intelligent POP client, a user may generate "scan listings" and
+
+dynamically decide which messages are worth taking delivery on.  The philosophy
+
+of the POP is to put intelligence in the POP clients and not the POP servers.
+
+
+       The  underlying  paradigm  in  which  the  POP  functions  is  that  of  a  split-
+
+slot/remote-UA  model.   The  client  host  (such  as  a  workstation)  is  without  a
+
+co-resident message  transport  agent (MTA), and thus makes use of a service host
+
+with an MTA to obtain posting (SMTP) and delivery (POP) services.  The entity
+
+which supports this type of environment is called a remote-UA since the user agent
+
+resides on a different host than its associated message transport agent.
+
+
+
+________________________________________
+8  Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
+
+original description of the protocol, which suffered from certain problems. Since then, two alternate
+descriptions have been developed. The official revision of the POP[MButl85], and the revision of the
+POP which MH uses (which is documented in an internal memorandum in the MH release).  This
+paper considers the POP in the context of the MH release.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   19
+
+
+       One  very  important  issue  which  must  be  raised  at  this  point  is  one  of
+
+authentication.  The POP requires that a client identify itself to the server using
+
+a server-specific user-id and a server/user-specific password.  This authentication
+
+is required to prevent unauthorized entities from accessing a maildrop on a POP
+
+service host.  It must be emphasized that the POP client is not a "trusted" entity
+
+of the MTS in any sense at all.
+
+
+       Ideally, one would also like to authenticate mail as it is posted on the POP
+
+service  host  using  the  SMTP.  Currently,  in  the  ARPA  Internet  community,  no
+
+authentication is done with SMTP transactions.  This is considered a shortcoming
+
+by  those  interested  in  researching  the  split-UA  model  of  distributed  mail.  The
+
+MZnet environment, discussed in the next section, has authentication facilities for
+
+posting mail.
+
+
+       The  current  release  of  MH  supports  the  above  model  fully:  a  POP  client
+
+program is available to retrieve a maildrop on a POP service host.  In addition,
+
+using  the  SMTP  configuration  for  delivery  in  MH,  a  user  is  able  to  specify  a
+
+search-list of service hosts (and networks) with which to try to post mail.  Using
+
+this  search-list,  when  an  MH  user  posts  a  draft,  the  post  program  will  attempt
+
+to establish an SMTP connection with each host in the list to post the message
+
+until  it  succeeds.   Initial  experimentation  with  the  split-UA  in  a  local  network
+
+environment has proved quite successful.
+
+
+The MZnet Environs
+
+       In 1983,  the MZnet project[EStef84] at the University of California,  Irvine
+
+set out to study the problems involved with bringing Internet-class mail handling
+
+facilities to personal computers.  The project used Apple II computers running the
+
+CP/M 2.2 operating system.  Programming was done in a subset of the C language
+
+called BDS C. The transport system was based on the MMDF PhoneNet software,
+
+and  implemented  a  split-slot  arrangement  between  a  personal  computer  and  a
+
+larger, centralized mail distribution system that performed user authentication and
+
+provided a relatively secure mail transfer channel.  The user agent, CP/MH, was
+
+based on MH.
+
+
+       A  conclusion  of  the  experiment  was  that  small  personal  computer  systems
+
+with dial-up phone connections constrain user agent systems design in ways that
+
+require use of a split-slot interface between the UA and its supporting MTA, and that
+
+this interface best provides the required services if it has error controlled command
+
+and data transfer facilities, with interactive behavior.  Another conclusion indicated
+
+that a good design for a user agent in such a small personal computer environment
+
+could be based on a very modular architecture, such as MH. A final conclusion was
+
+that session-level authentication of the client UA is required for both posting and
+
+delivery.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   20
+
+
+       It should be noted that the MZnet project had a profound influence on the
+
+development  of  the  POP  used  by  MH.  A  somewhat  more  detailed  discussion  of
+
+the relations between the two environments can be found in the POP description
+
+contained in the MH release.
+
+
+
+A Final Note
+
+       With the fifth major release of the MH system, it has become clear that most
+
+major increases in functionality can come only at the expense of either efficiency or
+
+portability.  Although there has been great effort to keep MH portable to a number
+
+of  UNIX  implementations,9  the  divergence  in  process  management  facilities,  file
+
+system  enhancements,  and  even  C  compiler  capabilities  has  already  presented
+
+obstacles to some attempts to rehost the MH code.
+
+
+       There  has  been  some  discussion  of  implementing  specialized  MH  daemons
+
+that maintain context information over one or more sessions, thus decreasing the
+
+amount of overhead involved in starting each MH command.  Unfortunately, even
+
+if such daemons were to be implemented, they would be very difficult to move to
+
+versions  of  UNIX  without  sophisticated  process  management  facilities,  and  even
+
+then  the  differences  in  "philosophies"  of  process  management[WJoy83, EOlse84]
+
+would tend to keep such daemons system specific.  A better solution seems to be
+
+simply to tune existing code.
+
+
+
+Acknowledgements
+
+       The authors would like to thank Norman Z. Shapiro and Phyllis Kantar of
+
+the Rand Corporation for their invaluable comments during the preparation of this
+
+paper.
+
+
+
+Distribution Information
+
+       For information concerning distribution mechanics for the current release of
+
+MH, please contact:
+
+
+           Support Group
+
+           Attn:  MH Distribution
+
+           Department of Information and Computer Science
+
+           University of California, Irvine
+
+           Irvine, CA 92717       USA
+
+
+
+           714/856-6852
+
+
+
+________________________________________
+9  As of this writing, there are approximately 75 sites running mh.5 on five different implementations
+
+of UNIX.
+
+
+                                                 References
+
+
+
+[DCome83]        D.  Comer.   The  Computer  Science  Research  Network  CSnet:   A
+
+                 History  and  Status  Report.  Communications  of  the  ACM  26,  10
+
+                 (October, 1983), 747-753.
+
+
+
+[DCroc79]        D.H.  Crocker,  E.S.  Szurkowski,  D.J.  Farber.   An  Internetwork
+
+                 Memo  Distribution  Facility  _  MMDF.  Appearing  in  Proceedings,
+
+                 Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
+
+
+
+[DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
+
+                 Messages.  Request  for  Comments  822.  ARPA  Internet  Network
+
+                 Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DKing84]        D.P.  Kingston,  III.   MMDFII:  A  Technical  Review.  Appearing  in
+
+                 Proceedings  Usenix  Summer  '84  Conference,  Salt  Lake  City,  Utah,
+
+                 1984, pp. 32-41.
+
+
+
+[EAllm83]        E.  Allman.    SENDMAIL  _  An  Internetwork  Mail  Router.
+
+                 Britton-Lee, Inc., Berkeley, California (July, 1983).
+
+
+
+[EOlse84]        E.W. Olsen.  NetOS Concepts and Facilities. Local Network Systems,
+
+                 Inc., Costa Mesa, California (August, 1984).
+
+
+
+[EStef84]        E.A. Stefferud, J.N. Sweet, T.P. Domae.  MZnet:  Mail Service for
+
+                 Personal Micro-Computer Systems. Appearing in Proceedings, Second
+
+                 International Symposium on Computer Message Systems, Nottingham,
+
+                 U.K, 1984, pp. 293-302.
+
+
+
+[FIPS98]         Specification  for  Message  Format  for  Computer  Based  Message
+
+                 Systems. National Bureau of Standards (January, 1983).
+
+
+
+[HERMES]         Bolt, Beranek, and Newman.  Hermes User's Manual. for TOPS-20.
+
+                 Bolt, Beranek, and Newman, Boston, MA (January, 1979).
+
+
+
+[IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
+
+                 Appearing in Internet Protocol Transition Workbook, ARPA Internet
+
+                 Network Information Center (NIC), SRI International, 1981.
+
+
+
+[JReyn84]        J.K.  Reynolds.   Post  Office  Protocol.  Request  for  Comments  918.
+
+                 ARPA Internet Network Information Center (NIC), SRI International
+
+                 (October, 1984).
+
+
+
+ Copyright fcl1985, North Holland Publishing Company                                                              21
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   22
+
+
+[MButl85]        M.  Butler,  J.B.  Postel,  et.  al.   Post  Office  Protocol  -  Version  2.
+
+                 Request  for  Comments  937.  ARPA  Internet  Network  Information
+
+                 Center (NIC), SRI International (February, 1985).
+
+
+
+[MRose84a]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  The  UCI
+
+                 BBoards Facility. Department of Computer and Information Sciences,
+
+                 University of Delaware (October, 1984).
+
+
+
+[MRose84b]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  Tutorial.
+
+                 Department  of  Computer  and  Information  Sciences,  University  of
+
+                 Delaware (October, 1984).
+
+
+
+[MRose85a]       M.T. Rose,  J.L. Romine.  The Rand MH Message Handling System:
+
+                 User's Manual. UCI Version. Department of Information and Computer
+
+                 Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85b]       M.T.  Rose,  E.A.  Stefferud.    Proposed  Standard  for  Message
+
+                 Encapsulation. Request for Comments 934. ARPA Internet Network
+
+                 Information Center (NIC), SRI International (January, 1985).
+
+
+
+[MRose85c]       M.T. Rose, D.J. Farber, S.T. Walker.  Design of the TTI Prototype
+
+                 Trusted Mail Agent. Appearing in Proceedings, Second International
+
+                 Symposium on Computer Message Systems, Washington, D.C., 1985
+
+                 (to appear).
+
+
+
+[SMTP]           Simple  Mail  Transfer  Protocol.  Request  for  Comments  821.  ARPA
+
+                 Internet  Network  Information  Center  (NIC),  SRI  International
+
+                 (August, 1982).
+
+
+
+[TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
+
+                 1778).  Appearing  in  Internet  Protocol  Transition  Workbook,  ARPA
+
+                 Internet Network Information Center (NIC), SRI International, 1981.
+
+
+
+[WJoy83]         W.N.  Joy,  E.  Cooper,  R.S.  Fabry,  S.J.  Leffler,  K.  McKusick,
+
+                 D.  Mosher.   4.2bsd  System  Manual.  Technical  Report  Number  5.
+
+                 Computer Systems Research Group, University of California, Berkeley.
+
+
+
+[X.400]          Message  Handling  Systems:   System  Model-Service  Elements,
+
+                 Recommendation  X.400,  International  Telegraph  and  Telephone
+
+                 Consultative Committee (CCITT).
+
+
+                                                        Appendix  A
+
+                                                     MH  Commands
+
+
+
+               MH is composed of several UNIX programs, which in theory are fairly simple
+
+        and single-purposed.  These commands are functionally grouped below:
+
+
+                                                       Composing_Mail__________
+
+     comp:     compose a message
+
+               A program to originate a message.  Usually, a special prompting editor front-
+
+               end, prompter, is used to fill-in a composition template with the addressees
+
+               of the message, subject, and so forth.
+
+
+       dist :  redistribute a message to additional addresses
+
+               A program that re-enters a message previously received by the user into the
+
+               message transport system.  Only new addresses are added;  the body of the
+
+               message is not changed in any way.
+
+
+      forw :   forward messages
+
+               A program that encapsulates one or more messages in a new message draft.
+
+               In addition, the user may add initial and/or closing comments.
+
+
+       repl :  reply to a message
+
+               A program that constructs a reply to a message using a reply template.  The
+
+               template mechanism has sufficient generality to permit the user to "program"
+
+               the  form  of  the  reply  draft  based  on  the  contents  of  the  message  being
+
+               replied-to.
+
+
+      send :   send a message
+
+               A  program  that  posts  a  draft  with  the  message  transport  system.   The
+
+               send program is usually invoked by one of the four preceding programs, and
+
+               performs simple front-end pre-processing prior to invoking the post program.
+
+               For  example,  if  invoked  in  push'd  mode,  send  will  immediately  relinquish
+
+               control  of  the  user's  terminal  and  post  the  message  in  the  background.  If
+
+               the posting fails, send will send back a failure notice to the user.  If the user
+
+               had push'd the sending of the draft, then by default the draft being sent is
+
+               encapsulated in the failure notice.  This permits easy burst'ing of the failure
+
+               notice to retrieve the original draft.  Otherwise, if the posting was successful,
+
+               the draft is marked as having been sent.
+
+
+whatnow :      prompting front-end for send
+
+               A program which is called by comp, et.  al., after the initial draft has been
+
+
+
+         Copyright fcl1985, North Holland Publishing Company                                                              23
+           Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   24
+
+
+                 generated.  The  MH  user  can  specify  a  different  whatnow  program,  which
+
+                 yields considerable extensibility.
+
+
+      whom:      report to whom a message would go
+
+                 A program which examines the addresses of the draft and expands all user-
+
+                 defined  aliases  contained  therein.  Optionally,  whom  may  actually  interact
+
+                 with  the  message  transport  system  to  determine  the  validity  of  the  final
+
+                 addresses.  This program is also usually invoked by comp, et. al.
+
+
+                                                           Posting_Mail_______
+
+           ali : list mail aliases
+
+                 A simple front-end to the MH aliasing mechanism.
+
+
+           ap:   parse addresses 822-style
+
+                 A  useful  debugging  tool  for  PostMasters  who  wish  to  examine  how  MH
+
+                 interprets an Internet address.
+
+
+    conflict :   search for alias/password conflicts
+
+                 Another program used by system administrators to check the consistency of
+
+                 MH alias files, and portions of the local message transport agent.
+
+
+install-mh:      initialize the MH environment
+
+                 A program which is automatically executed the first time a user issues an MH
+
+                 command.  This program performs once-only initialization of the user's MH
+
+                 environment.
+
+
+    mhmail :     send or read mail
+
+                 A simple program generally used by other programs to generate messages.
+
+                 The mhmail command is similar in purpose to the old BellMail program.
+
+
+         post :  deliver a message
+
+                 A  complex  MH  back-end  that  interacts  with  the  local  message  transport
+
+                 agent to enter messages through the posting slot.  (See the description of send
+
+                 above).
+
+
+                                                           Reading_Mail________
+
+          inc:   incorporate new mail
+
+                 A program that interacts with the local message transport agent to retrieve
+
+                 messages from the user's maildrop.
+
+
+    msgchk :     check for waiting mail
+
+                 A program which reports the status of mail waiting in the user's maildrop.
+
+
+        show :   show (list) messages
+
+                 A  program  which  lists  messages  to  its  standard  output  (usually  the  user's
+
+                 terminal), possibly invoking another program to do the actual listing.  Most
+
+                 users  of  MH  have  show  automatically  call  the  mhl  program  to  format  the
+      Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   25
+
+
+            message.   The  next  and  prev  programs  are  simply  ``show next''          and
+
+            ``show prev''          , respectively.
+
+
+    mhl :   produce formatted listings of MH messages
+
+            A program which displays a message as directed by a template.  This permits
+
+            the user to filter out uninteresting headers and re-arrange other headers to a
+
+            particular preference.  In addition to being invoked by show, the mhl program
+
+            is optionally also invoked by forw to format each message being forwarded;
+
+            invoked  by  repl  to  format  the  body  of  a  message  being  replied-to,  if  that
+
+            message is being included in the reply draft; and, invoked by post to format
+
+            a message being sent as a blind-carbon-copy.
+
+
+   rmm:     remove messages
+
+            A program that removes messages from an MH folder, optionally running a
+
+            user-defined program instead of deleting them.  If no program is given,  the
+
+            messages are "softly" removed, so they may possibly be recovered later.
+
+
+   scan:    produce a one-line-per-message scan listing
+
+            A program that generates a scan listing for messages.  Each line of the listing
+
+            contains date, source, subject, and possibly the initial body of the message.
+
+
+                                                    Folder_Handling________
+
+ folder :   set/list current folder/message
+
+            A program used to list information concerning the current folder, or set the
+
+            current folder and/or message.
+
+
+folders :   list all folders
+
+            A program to list information on all folders (actually, just a special case of
+
+            the folder command).  Since the MH folder structure may be recursive,  the
+
+            user can indicate that folders should recursively examine all folders.
+
+
+   refile:  file message(s) in (an)other folder(s)
+
+            A program to move (or copy) messages from a source folder to one or more
+
+            destination folders.
+
+
+    rmf :   remove folder
+
+            A program that deletes a folder and all messages therein.
+
+
+                                                  Message_Selection_________
+
+   anno:    annotate messages
+
+            A  program  to  arbitrarily  annotate  messages.   If  the  user  so  desires,  after
+
+            distributing,  forwarding,  or  replying-to  a  message,  MH  will  automatically
+
+            attach an annotation to the original message indicating the date and addresses.
+
+
+  mark :    mark messages
+
+            A program to manipulate user-defined sequences (lists of messages).  Usually,
+
+            mark is not employed directly by the MH user.
+       Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985                                   26
+
+
+     pick :  select messages by content
+
+             A  program  to  examine  a  list  of  messages  and  choose  those  which  meet
+
+             a  particular  selection  criterion.   The  pick  program  is  often  used  in  UNIX
+
+             back-quoted operations to pass message sequences to other MH commands.
+
+
+   sortm:    sort messages
+
+             A program to sort a list of messages according to the date given in a particular
+
+             field.
+
+
+                                             Distribution_List_Handling____________
+
+      bbc:   check on BBoards
+
+             A  front-end  to  run  msh  on  a  list  of  distribution  lists  which  the  user  isn't
+
+             current on.
+
+
+       bbl : manage a BBoard
+
+             A  (depreciated)  program  used  to  manually  manage  the  local  archives  of
+
+             a  distribution  list.  These  functions  (archiving,  expunging)  are  performed
+
+             automatically by MH.
+
+
+    burst :  explode digests into messages
+
+             A  program  used  to  decapsulate  messages  from  ARPA  Internet  digests.  In
+
+             addition,  messages  which  have  been  encapsulated  during  forwarding  (i.e.,
+
+             with forw ) can also be decapsulated using burst.10
+
+
+     msh:    MH shell (and BBoard reader)
+
+             A  monolithic  program  used  to  implement  MH  commands  on  messages
+
+             arranged in a single file (maildrop format).  Useful since distribution lists are
+
+             kept in this format to minimize consumption of system resources.
+
+
+    pack :   compress a folder into a single file
+
+             A program which takes messages stored in MH format and places them in a
+
+             single file (using the same format known by msh).
+
+
+                                        Interface_to_the_UNIX_File_System________________
+
+mhpath:      print full pathnames of MH messages and folders
+
+             A program which maps MH-style names into the UNIX file naming convention.
+
+
+
+      ________________________________________
+     10  Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
+
+      so.
+
+
+
+
+                                                  Contents
+
+
+
+                                                                                                              Page
+
+Introduction .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .*
+ *        1
+
+The MH Philosophy .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        2
+
+       The MH Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        3
+
+       The MH Profile  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        4
+
+       Folders and Messages .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        6
+
+       The Context File  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        7
+
+       Templates .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
+ *      7
+
+       Explaining All This to New Users .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        7
+
+A Few Advanced Features  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        9
+
+       Draft Folders .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    *
+ *    9
+
+       Message Selection .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        9
+
+       Distribution Lists  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      11
+
+       Encapsulation  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      *
+ *14
+
+       Encapsulation and Blind-Carbon-Copies .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      14
+
+MH as a Record Handler .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      15
+
+       Mapping Between Record Modes (DBMS/MHS) .  .  .  .  .  .  .  .  .  .  .  .  .  .      16
+
+Distributed Mail  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    *
+ *  17
+
+       The ARPA Internet Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      18
+
+       The MZnet Environs .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      19
+
+A Final Note  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
+ *    20
+
+Acknowledgements .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      20
+
+Distribution Information .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      20
+
+References .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
+ *.      21
+
+Appendix A: MH Commands  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      23
+
+
+
+________________________________________
+This document (version #1.54) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+                                                                                                                    i
diff --git a/docs/historical/mznet.pdf b/docs/historical/mznet.pdf
new file mode 100644
index 0000000..e8fbfc3
Binary files /dev/null and b/docs/historical/mznet.pdf differ
diff --git a/docs/historical/mznet.txt b/docs/historical/mznet.txt
new file mode 100644
index 0000000..7a6b9a8
--- /dev/null
+++ b/docs/historical/mznet.txt
@@ -0,0 +1,1103 @@
+
+
+
+
+  MZnet:   Mail  Service  for  Personal
+
+
+             Micro-Computer  Systems
+
+
+
+                                  Einar  Stefferud
+
+                                       President,
+
+                Network  Management  Associates
+
+                                             and
+
+                               Visiting  Lecturer,
+
+            in  Information  and  Computer  Science
+
+                University  of  California  at  Irvine
+
+
+
+                                     Jerry  Sweet
+
+Department  of  Information  and  Computer  Science
+
+                University  of  California  at  Irvine
+
+
+
+                                Terrance  Domae
+
+                           School  of  Engineering
+
+          University  of  California  at  Los  Angeles
+
+
+
+                                               0
+
+
+
+
+                                            Abstract
+
+     Traditional computer mail systems involve a co-resident User Agent
+(UA)  and  Mail  Transfer  System  (MTS)  on  a  time-shared  host  com-
+puter which may be connected to other hosts in a network, with new
+mail  posted  or  delivered  directly  through  co-resident  mail-slot  pro-
+grams.  To  introduce  personal  micro-computers  (PCs)  into  this  envi-
+ronment requires modification of the traditional mail system architec-
+ture.  To this end,  the MZnet project uses a split-slot model,  placing
+UA programs on the PCs while leaving MTA programs on a mail relay
+host  which  can  provide  authentication  and  buffering.   The  split-slot
+arrangement might be viewed as a new protocol level which operates
+somewhere between the currently defined MTS-MTS and UA-UA lev-
+els.
+
+
+
+
+Introduction
+
+
+Mail  systems  were  born  and  have  grown  up  on  large  central  time  sharing
+
+systems, often imbedded in large networks of inter-operating computers with
+
+a set of distributed processes automatically transferring mail between users.
+
+This  is  certainly  the  case  with  the  U.S.  Department  of  Defense  (DoD)  Ad-
+
+vanced  Research  Projects  Agency  Network  (ARPANET)  [1 ]  where  much  of
+
+the  original  computer  network  mail  systems  research  and  development  has
+
+taken  place.   Other  mail  networks  such  as  the  Computer  Science  Network
+
+[2 ]  sponsored  by  the  U.S.  National  Science  Foundation,  have  also  used  rela-
+
+tively large shared computers lodged in an institutional setting, though they
+
+are often connected together with ordinary dial-up telephone links to form a
+
+large geographic network.  Another U.S. example is USENET [3 ] which con-
+
+nects  thousands  of  Unix1  systems  together  with  informally-supported  dial
+
+telephone links.  Although there have been several attempts, there appear to
+
+be  no  successful  mail  networks  based  on  small  personal  computers,  such  as
+
+those that use the CP/M2  or MS-DOS3  operating systems.
+
+      The  accepted  architectural  model  (see  Figure  1)  for  computer  network
+
+mail (first articulated by the IFIP 6.5 Systems Environment Working Group)
+
+involves a User Agent (UA) which posts new mail items through a mail slot
+
+[4 ,  5,  6,  7]  to  a  Mail  Transfer  Agent  (MTA)  which  delivers  posted  items  to
+
+designated  UA  recipients  through  corresponding  delivery  slots.  When  mail
+
+is  to  be  delivered  to  a  UA  on  another  host,  it  is  transferred  first  to  another
+
+MTA on the recipient user's host, which in turn puts the mail item through
+
+its  local  delivery  slot.   In  this  model,  a  Mail  Transfer  System  (MTS)  may
+
+be viewed as a collection of MTAs with network connections among them to
+
+provide  Mail  Transfer  Services  for  a  large  number  of  users  on  different  host
+
+computers.
+
+      Replicating  this  UA/MTA/MTS  model  on  a  personal  micro-computer
+
+(PC)  is  not  an  easy  task.  Aspects  of  PCs  that  make  support  of  this  model
+
+difficult  include  limited  storage  capacities,  limited  processing  capabilities,
+
+and the fact that PCs are geared to support a single user rather than several
+
+users  at  once.   A  PC  with  limited  secondary  diskette  storage  and  limited
+________________________________________________
+    1 UNIX is a Trademark of Bell Laboratories, Inc.
+    2 CP/M is a Trademark of Digital Research, Inc.
+    3 MS-DOS is a Trademark of Microsoft Corporation.
+
+
+
+                                                           1
+
+
+
+
+processing capacity (often single-thread) is not well suited to support the full
+
+range of automatic interactions between a UA and an MTA, or the necessary
+
+interactions between MTAs in an MTS. For example, we do not see any way
+
+to  certify  PC  systems  for  authentication  of  posted  mail.  A  PC  can  change
+
+its  entire  character  and  behavior  with  insertion  of  a  new  program  diskette,
+
+suggesting that it is the operating system diskettes and their users that must
+
+be certified, rather than the computers.  Review of certification issues shows
+
+that  it  is  not  the  computer,  but  its  operators  and  managers  that  must  be
+
+certified,  and  this  involves  the  notions  of  central  management  and  control.
+
+All  this  is  lost  in  the  maze  of  PCs  that  we  see  proliferating  on  and  off  our
+
+campuses, in and out of our offices and homes.
+
+      Thus, we see a need for a new arrangement with the UA separated from
+
+its  MTA,  and  using  communication  protocols  to  interact  with  it  in  ways
+
+that resemble MTA-to-MTA interactions.  The UA is placed on the PC end,
+
+while  the  more  complex  tasks  performed  by  the  MTA  are  relegated  to  the
+
+remote host end.  The remote MTA must authenticate mail items offered by
+
+the PC-based UA, just as it would for a co-located UA, but the task is more
+
+difficult because the PC UA is potentially anyone among the public telephone
+
+connectable  population.   This  can  be  handled  with  password  systems,  but
+
+recognition and identification are not the only services to be provided at the
+
+posting  slot.   Posting  also  requires  some  validation  of  recipient  addresses,
+
+and validation of the syntax and semantics of certain header fields.  Example
+
+standards are provided by the U.S. National Bureau of Standards (NBS) and
+
+the U.S. DoD ARPANET for the format of mail to be transferred [8 , 9 , 10  ].
+
+      The new arrangement described in this paper might be called a split mail
+
+slot in that the UA side of the slot is split away from the MTA side.  Although
+
+the  UA  and  MTA  may  be  on  opposite  ends  of  a  telephone  connection,  they
+
+must  still  act  together  as  a  single  processing  unit  to  move  mail  from  one
+
+to  the  other,  with  all  that  this  may  entail.   This  gives  rise  to  a  number  of
+
+new  MTA/UA  requirements  such  as  error  control  for  service  requests,  user
+
+intervention to select items for delivery, and user postponement or rejection
+
+of delivery without triggering failure notices to senders.  These are not serious
+
+problems  when  both  MTA  and  UA  are  programs  running  on  a  single  host.
+
+For example, with both UA and MTA on the same host, unwanted junk mail
+
+is  simply  deleted  at  low  cost,  compared  to  the  cost  of  deletion  after  a  long
+
+delivery transmission time.  Better that our PC users be able to discard items
+
+without delivery transmission.
+
+
+
+                                                           2
+
+
+
+
+Overview  of  the  MZnet  Environment
+
+
+The MZnet project is an undergraduate student effort sponsored within the
+
+Information  and  Computer  Science  (ICS)  Department  of  the  University  of
+
+California  at  Irvine  (UCI)  in  Southern  California.  For  the  past  2  years,  the
+
+UCI mail network, known as ZOTnet, has been connected into the Computer
+
+Science  Network  (CSnet)  and  in  1984,  has  joined  the  DoD  ARPA  Internet
+
+with a Split-Gateway connection [11  ] to the University of Southern California
+
+Information Sciences Institute (USC-ISI). The MZnet split-slot arrangement
+
+may  have  some  similarities  to  the  Split-Slot  Internet  Gateway  at  least  in
+
+name, but the problems and the implementations are quite different.
+
+      The UCI ZOTnet environment [13  ] gives the MZnet project a full-fledged
+
+Internet-class mail system as its foundation.  The MZnet project objective is
+
+to extend this class of mail service to personal computers located in student
+
+and faculty residences, offices and laboratories, without waiting for full-blown
+
+local area networking to first provide connections.  This follows a pattern of
+
+making the most of existing facilities to provide a reasonable level of service.
+
+      The UCI ZOTnet uses the CSnet-provided MMDF (Multi-channel Memo
+
+Distribution Facility) software [12  ] from the University of Delaware to inter-
+
+connect two VAX 750 Unix systems with two DEC TOPS-20 systems through
+
+a  port  selector,  with  dial  telephone  connection  to  a  CSnet  relay  [14  ].   The
+
+ZOTnet has since evolved into an ethernet-connected local area network with
+
+the aforementioned gateway connection into the DoD Internet.  The ZOTnet
+
+also  connects  to  USENET  with  the  UUCP  protocols,  and  provides  format
+
+transformations for mail flowing between protocol domains [15  , 16  ].  Adding
+
+to the reach of the ZOTnet with MZnet is a natural part of its evolution4 .
+
+      To this point we have set the context of the MZnet project.  The remainder
+
+of this paper is devoted to relatively technical discussions of implementation
+
+of the PC user agent programs and the split-slot UA/MTA interface.
+________________________________________________
+    4 For  those  who  are  properly  curious  about  such  things,  the  name  "ZOTnet"  derives
+
+from  the  cry  of  the  UCI  mascot  which  is  the  Anteater  from  the  B.C.  comic  strip,  and
+MZnet is simply a contraction for Micro-ZOTnet.
+
+
+
+                                                           3
+
+
+
+
+The  MZnet  User  Agent:   CP/MH
+
+
+CP/MH  is  a  collection  of  programs  designed  to  work  in  conjunction  with
+
+the  Micro  ZOTnet  (MZnet)  as  an  extension  of  the  UCI  ZOTnet.   CP/MH
+
+programs permit a user of a CP/M 2.2-based microcomputer to send and re-
+
+ceive ZOTnet mail messages, as well as to manipulate them locally on floppy
+
+disks.   The  CP/MH  programs  are  written  in  the  C  programming  language
+
+and should be portable to similar operating environments, such as MS-DOS,
+
+etc.
+
+      CP/MH  is  based  on  the  UCI  version  of  the  Rand  MH  message  handling
+
+system  [17  ]  for  the  Unix  operating  system.   The  major  philosophical  dif-
+
+ferences  between  CP/MH  and  typical  user  agents  such  as  MSG  [4 ]  and  its
+
+descendants  are  those  of  modularity  and  of  user  interface.   In  CP/MH  (as
+
+in  MH)  the  user  does  not  invoke  a  single  monolithic  program  to  deal  with
+
+mail,  but  rather  invokes  individual,  non-interactive  programs  with  common
+
+knowledge of the way messages are stored.  Each program has default behav-
+
+ior which can be modified by using Unix-style command line options at time
+
+of  invocation  or  through  a  user  profile.   Help  messages  can  also  be  evoked
+
+from CP/MH programs.
+
+
+
+Messages  and  Folders
+
+
+The format of a CP/MH message adheres more or less to the syntax described
+
+in  RFC  822  in  which  a  message  consists  of  headers  containing  information
+
+pertaining  to  the  message  source  and  destination,  and  the  message  body,
+
+separated  from  the  headers  by  a  blank  line.  An  example  of  such  a  message
+
+might be:
+
+
+
+          Date:  02  Nov  83  23:04:53  PST  (Wed)
+
+          To:  Toto  <dog@Univ-Kansas>
+
+          From:  The  Great  And  Powerful  Oz  <Oz@Emerald-City>
+
+          Subject:  What  Be  Your  Excuse?
+
+
+
+          What's  the  matter?    I  ask  you  for  a  simple  thing  like
+
+          "distribute  this  to  Witch@Oz-West,"  and  you  can't  do  it.
+
+          You  undergrads  will  do  anything  to  get  out  of  work!
+
+
+
+                                                           4
+
+
+
+
+          --ozzie
+
+
+      Following  the  MH  convention,  each  message  is  kept  in  a  separate  file.
+
+Since  a  message  is  simply  ASCII  text,  it  can  be  operated  upon  by  non-
+
+CP/MH programs (such as text editors, in particular).
+
+      Collections  of  messages  are  called  folders.   Under  CP/MH,  folders  are
+
+represented by several files:  an info file, containing maintenance information
+
+about  the  folder,  and  a  set  of  message  files  with  the  same  name  as  the  info
+
+file,  but  with  unique  numeric  suffixes  (extensions  in  CP/M  parlance).   An
+
+example of this naming scheme might be:
+
+
+DRAFT       the info file for the DRAFT folder
+
+
+DRAFT.001          message 1 in the folder
+
+
+DRAFT.002          message 2 in the folder
+
+
+DRAFT.003          message 3 in the folder
+
+
+      The number of messages that may be stored in a folder is limited primarily
+
+by  the  storage  capacity  of  a  floppy  disk,  but  also  by  the  three-digit  limit  of
+
+a CP/M extension.
+
+      The info file contains a field named CURRENT: specifying the current mes-
+
+sage  number.   The  current  message  number  signifies  the  default  message
+
+operated upon by CP/MH commands using a particular folder.  The current
+
+message  number  may  be  modified  by  some  commands.   An  example  of  the
+
+contents of the info file DRAFT might be
+
+
+             CURRENT:  3
+
+
+      This  indicates  that  the  file  DRAFT.003  would  be  operated  upon  when
+
+default conditions apply (i.e.  when no message number is explicitly given to
+
+a CP/MH command).
+
+      Possible future uses for the info file include named message sequences (a
+
+set  of  messages  to  which  commands  may  be  applied  as  a  whole)  and  user
+
+profile  information  for  application  to  particular  folders  (there  is  presently  a
+
+single user profile, described shortly).
+
+      A  floppy  diskette  may  contain  more  than  one  folder,  but  folders  do  not
+
+extend  over  more  than  one  floppy  diskette;  therefore  two  different  diskettes
+
+may contain folders with the same name.
+
+
+
+                                                           5
+
+
+
+
+CP/MH  Commands
+
+
+Commands  operating  on  messages  can  be  divided  into  several  general  cate-
+
+gories:
+
+
+
+Transporting:              sending, receiving
+
+
+Viewing:          selecting for display, showing header summaries
+
+
+Creating:          composing, replying, forwarding
+
+
+Archiving:           categorizing, refiling, deleting, sorting
+
+
+
+      The architecture of CP/MH permits the simulation of some of these cat-
+
+egories using standard CP/M commands when CP/MH, in its present prim-
+
+itive state, does not cover them.
+
+      A minimal functionality is presently provided by the following four com-
+
+mands:
+
+
+
+COMP           composes  mail  items:  creates  a  file  containing  header  information
+
+         taken  from  a  standard  or  user-specified  template.  This  newly-created
+
+         file may be edited to fill in the header fields and body.
+
+
+REPL         replies  to  mail  items:   creates  a  file  containing  header  information
+
+         appropriate  for  answering  a  given  mail  item.   This  newly-created  file
+
+         may be edited to change header fields and fill in the body.
+
+
+SEND          sends mail items:  posts selected items through the split-slot from a
+
+         draft folder.
+
+
+INC       receives  mail  items:  takes  delivery  of  selected  items  across  the  split-
+
+         slot, incorporating them into a mailbox folder.
+
+
+
+These  commands,  with  a  few  enhancements  and  modifications  appropriate
+
+to  the  CP/M  environment,  are  functionally  almost  identical  to  their  Unix
+
+MH counterparts.
+
+      CP/MH commands are invoked like any other CP/M commands such as
+
+ED,  PIP,  or  DIR.  Command  line  options  are  generally  preceded  by  a  dash
+
+(e.g.  -editor  A:ED),  and  may  be  abbreviated.  Folder  names  are  preceded
+
+
+
+                                                           6
+
+
+
+
+by  a  plus  (e.g.   +B:DRAFT).  Messages  are  identified  by  numbers  or  by  the
+
+special names first, last, current, next, and previous.
+
+      An example of use of a CP/MH command is:
+
+
+
+                        comp  -edit  a:ed  -use  last  +b:draft  -log
+
+
+
+      This  particular  example  will  edit  the  last-composed  message  (the  -use
+
+last  option)  in  the  folder  DRAFT  on  disk  drive  B:  (the  +b:draft  option),
+
+using  the  standard  CP/M  editor  ED  on  disk  drive  A:  (the  -edit  a:ed  op-
+
+tion),  and  prompting  the  user  when  it  is  appropriate  to  change  disks  (the
+
+-log option).
+
+      All  CP/MH  commands  have  a  -help  option  which  displays  all  available
+
+options  for  the  particular  command  invoked.   Another  common  option  is
+
+-log  which  permits  the  user  to  change  (relog)  diskettes  after  invoking  a
+
+command,  for  purposes  of  selecting  diskettes  with  message  folders  or  with
+
+editor  programs.   This  is  particularly  useful  on  single-drive  systems  or  on
+
+systems with diskettes of low storage capacity.
+
+
+
+The  Profile
+
+
+If  there  are  options  commonly  used  with  a  particular  CP/MH  command,
+
+they may be entered in the user profile contained in the file called (naturally
+
+enough)  PROFILE,  which  must  exist  on  the  same  diskette  on  which  CP/MH
+
+commands reside and from which the commands are invoked.  A profile entry
+
+consists  of  a  program  name  followed  by  a  colon  and  the  options  to  be  used
+
+with that program, for example:
+
+
+
+                        comp:    -editor  A:VEDIT  +B:outbox  -log
+
+                        repl:    -editor  A:VEDIT  -log
+
+                        send:    +B:outbox
+
+                        inc:    +B:inbox  -log
+
+
+
+      Individual profile components are overridden by options given at the time
+
+of  invocation  (e.g.   -noedit  given  on  the  command  line  will  override  the
+
+-editor profile component for a particular command).
+
+
+
+                                                           7
+
+
+
+
+The  MZnet  Split-Slot  Mail  Transfer  System
+
+
+The MZnet split-slot software implements a peer-to-peer communication pro-
+
+tocol  between  a  time-sharing  host's  MTA  and  a  personal  micro-computer
+
+(PC) UA. This MZnet protocol extends the UA/MTA/UA model of computer-
+
+based message systems (CBMS) to provide a split gateway function between
+
+individual PCs and the ZOTnet similar to the UCI ICS split Internet gateway
+
+described previously (see Figure 2).
+
+
+
+The  Structure  of  the  Split-Slot
+
+
+The  MZnet  Split  Gateway  consists  of  three  distributed  processing  compo-
+
+nents:
+
+
+
+      -  A PC running a UA (in MZnet, CP/MH) acting as the mail server.
+
+
+      -  A  mini/mainframe  host  running  a  full  MTA  (MMDF  in  MZnet)  pro-
+
+         viding mail relay services.
+
+
+      -  A  communication  protocol  (a  modified  version  of  MMDF  PhoneNet)
+
+         to connect the two ends of the split-slot.
+
+
+
+Although  this  combination  may  not  be  unique,  the  method  by  which  the
+
+MZnet  split-slot  bonds  these  parts  together  uniquely  deals  with  the  prob-
+
+lems  of  remote  user  agents.  In  addition  to  overcoming  limited  storage  and
+
+processing capacities, remote user agents must deal with noisy modem lines,
+
+mail  software  certification,  and  mail  system  security  problems.  The  MZnet
+
+architecture  appears  to  solve  these  problems  with  a  clean  mail  interface  for
+
+PCs.
+
+
+
+The  MZnet  Mail  Server
+
+
+The split-slot mail server consists of a set of command  packet programs run
+
+from the PC. These programs simply present commands through the Phone-
+
+Net  communication  protocol  to  the  mail  relay  slave  program  on  the  host.
+
+Some basic commands are:
+
+
+
+PostMail          posts mail drafts to MTA
+
+
+
+                                                           8
+
+
+
+
+GetMail          accepts mail from MTA
+
+
+RemoteScan               displays information about waiting mail
+
+
+Quit      drops connection between PC and Host
+
+
+
+      Each command has the form:
+
+
+
+             Command Request
+
+             Data Transmission
+
+             Command Termination
+
+
+
+      For example, the PostMail command is a small program that:
+
+
+
+      -  initiates a command with the Mail Slave by sending the command name
+
+         (PostMail) encoded within a PhoneNet packet;
+
+
+      -  sends a series of PhoneNet packets that contain pieces of the mail item
+
+         to be posted;
+
+
+      -  finally sends a command termination signal to end the transaction with-
+
+         out terminating the connection between host and PC.
+
+
+
+The  MZnet  Channel  To  MMDF
+
+
+The MZnet Channel runs on the MTA host under the University of Delaware's
+
+MMDF  (Version  1)  and  is  responsible  for  both  delivery  of  received  mail  to
+
+MZnet users, and posting of MZnet user-originated mail.  The MMDF MZnet
+
+channel  maintains  a  unique  message  queue  for  each  registered  MZnet  user.
+
+As new mail items arrive, they are posted to the appropriate queues, where
+
+MZnet holds the mail items for pickup by their registered recipients.
+
+      To send or receive mail, the MZnet user must attach to the host, log into
+
+the  public  MZnet  account,  and  identify  (authenticate)  himself.  During  the
+
+MZnet  session  with  the  host,  the  user  has  access  only  to  that  restricted  set
+
+of  functions  provided  by  the  MZnet  split  gateway  protocol:  he  may  request
+
+delivery of queued mail with GetMail, or post new mail with PostMail.  Prior
+
+to  taking  delivery  of  queued  mail,  a  survey  of  waiting  mail  also  may  be
+
+
+
+                                                           9
+
+
+
+
+requested with RemoteScan to obtain message size information (among other
+
+data) to allow intelligent disposition of mail in the queue.
+
+      Hidden within these activities are issues of security and certification.  To
+
+certify and establish the identity of the user, a second password is requested
+
+after  logging  into  the  public  MZnet  account.   This  certification  procedure
+
+allows  MZnet  to  certify  the  source  of  originated  mail.   A  relatively  secure
+
+environment  is  provided  by  MZnet,  as  it  is  the  only  interface  to  the  host
+
+permitted  to  MZnet  users  (once  beyond  the  public  login  procedure),  and  it
+
+offers only the severely restricted set of PhoneNet-encoded commands.  Aside
+
+from security issues, using a single account to handle all MZnet users reduces
+
+demands on system resources.
+
+
+
+The  MZnet-PhoneNet  Protocol
+
+
+A unique facet of the MZnet system derives from the PhoneNet File Transfer
+
+Protocol  (FTP).  PhoneNet  FTP  is  a  simple  error-checked  packet  protocol
+
+which transfers ASCII plaintext.  PhoneNet encodes any non-plaintext char-
+
+acter  (or  any  other  character  "forbidden"  by  the  idiosyncrasies  of  the  com-
+
+municating  systems)  by  mapping  it  onto  an  "accepted"  character  set.  The
+
+accepted character set mapping is determined by a "negotiating" session be-
+
+tween the two systems at the start of the PhoneNet session.
+
+      MZnet transfers all information (both commands and data) in PhoneNet
+
+packets to obtain error control.  The MZnet-PhoneNet command FTP toler-
+
+ates noise with a high degree of success, and in effect, connects both ends of
+
+the Split Slot together with a reliable set of virtual wires.
+
+
+
+MZnet  Session  Example
+
+
+Here,  a  typical  MZnet  session  is  presented,  with  the  UA  commands  issued
+
+from  the  PC  side  of  the  connection  printed  in  a  typewriter  typeface,  and
+
+the  responses  from  the  host  side  printed  in  an  italic  typeface.   PhoneNet
+
+interactions are indented.  The initial connection to the host is accomplished
+
+with the term program, which provides a simple terminal emulation function.
+
+The prompt of the PC for a UA command is "Ai".  Note that passwords are
+
+never echoed by the host system.
+
+
+
+                 Ai term
+
+
+
+                                                           10
+
+
+
+
+                 login:  mznet
+
+                 password:
+
+                 MZ-Password:
+
+                               PhoneNet packet negotiation
+
+                 Connected.
+
+                               exit terminal mode
+
+                 Ai send  cur
+
+                               PostMail command
+
+                               message text packet transmission
+
+                               command terminator
+
+                 Ai quit
+
+                               Quit command
+
+                 Disconnecting.
+
+
+
+Conclusions
+
+
+The main conclusions of this paper are that small personal computer systems
+
+with dial-up phone connections constrain User Agent systems design in ways
+
+that  require  use  of  a  split-slot  interface  between  the  UA  and  its  supporting
+
+Mail Transfer Agent (MTA), and that this interface will best provide the re-
+
+quired services if it has error controlled command and data transfer facilities,
+
+with interactive behavior.
+
+      It  is  also  believed  that  a  good  design  for  the  small  PC  UA  is  based  on
+
+a  very  modular  architecture,  such  as  the  Rand  MH  system,  which  has  been
+
+used as a pattern for the MZnet UA.
+
+      By bringing these concepts together, we expect MZnet to provide reliable
+
+UA/MTA service to a distributed set of small personal computers, to match
+
+the  quality  of  service  that  is  normally  only  available  from  larger  mainframe
+
+host systems with co-resident UA/MTA pairs.
+
+
+
+References
+
+
+ [1]   SRI-NIC,  ARPANET  Directory,  Network  Information  Center,  SRI  In-
+
+       ternational, Menlo Park, California (November 1980).
+
+
+
+                                                           11
+
+
+
+
+ [2]   Comer,  D.,  A  Computer  Science  Research  Network  CSNET:  A  History
+
+       and Status Report, Communications of the ACM, volume 26, number 10
+
+       (October 1983) 747-753.
+
+
+ [3]   Emerson,  S.  L.,  USENET:  A  Bulletin  Board  for  Unix  Users.  BYTE,
+
+       volume 8, number 10 (October 1983) 219-236.
+
+
+ [4]   Vittal, J., MSG: A Simple Message System, in:  Uhlig (editor), Proceed-
+
+       ings  of  the  IFIP  TC-6  International  Symposium  on  Computer  Message
+
+       Systems (North-Holland, April 1981).
+
+
+ [5]   Deutsch,  D.,  Design  of  a  Message  Format  Standard,  in:  Uhlig  (editor),
+
+       Proceedings  of  the  IFIP  TC-6  International  Symposium  on  Computer
+
+       Message Systems (North-Holland, April 1981).
+
+
+ [6]   v.Bochmann,  G.  and  Pickens,  J.  R.,  A  Methodology  for  the  Specifica-
+
+       tion  of  a  Message  Transport  System,  in:  Uhlig  (editor),  Proceedings  of
+
+       the IFIP TC-6 International Symposium on Computer Message Systems
+
+       (North-Holland, April 1981).
+
+
+ [7]   Kerr,  I.  H.,  Interconnection  of  Electronic  Mail  Systems,  in:  Uhlig  (edi-
+
+       tor),  Proceedings  of  the  IFIP  TC-6  International  Symposium  on  Com-
+
+       puter Message Systems (North-Holland, April 1981).
+
+
+ [8]   Crocker,  D.,  Standard  for  the  Format  of  ARPA  Internet  Text  Messages
+
+       (RFC 822) Network Information Center, SRI International, Menlo Park,
+
+       California (August 1982).
+
+
+ [9]   NBS,  Message  Format  for  Computer-Based  Message  Systems,  U.S.  Na-
+
+       tional Bureau of Standards FIPS Publication 98 (March 1983).
+
+
+[10]    CCITT  Study  Group  VII/5,  Draft  Recommendation  X.MHS1:   Mes-
+
+       sage  Handling  Systems:   System  Model_Service  Elements  (version  2),
+
+       Technical  Report,  International  Telegraph  and  Telephone  Consultative
+
+       Committee (CCITT) (December 1982).
+
+
+[11]    Rose,  M.,  Low  Tech  Connections  into  the  ARPA  Internet:  The  Raw-
+
+       Packet  Split-Gateway,  University  of  California  Irvine  Techical  Report
+
+       number 216 (February 1984).
+
+
+
+                                                           12
+
+
+
+
+[12]    Crocker, D., Szurkowski, E., Farber, D. J., An Internet Memo Distribu-
+
+       tion  Facility_MMDF,  Proceedings  of  the  Sixth  IEEE  Data  Communi-
+
+       cations Symposium (November 1979).
+
+
+[13]    Rose,  M.,  The  ZOTnet_A  Local  Area  Mailing  Network,  University  of
+
+       California Irvine Technical Report number 200 (January 1983).
+
+
+[14]    CSNET-CIC,  Focus  on  the  University  of  California,  Irvine,  CSNET
+
+       News 2, Bolt, Beranek, and Newman, Cambridge, Massachusetts (Octo-
+
+       ber 1983).
+
+
+[15]    Rose,    M.,    Achieving    Interoperability    Between    Two    Domains_
+
+       Connecting the ZOTnet and UUCP Computer Mail Networks, University
+
+       of California Irvine Technical Report number 201 (January 1983).
+
+
+[16]    Rose, M., Proposed Standard for Message Munging (RFC 886), Network
+
+       Information Center, SRI International, Menlo Park, California (Decem-
+
+       ber 1983).
+
+
+[17]    Borden, B. S., Gaines, R. S., and Shapiro, N.Z., The Rand MH Message
+
+       Handling System:  User's Manual (Rand Corporation, March 1983).
+
+
+
+                                                           13
+
+
+
+
+________________________________________________________________________________________________________________________
+
+Any  Host                                          Relay  Host                                       Any  Other  Host
+
+
+
+     user                                                                                                     user
+
+
+
+     UA                                                                                                        UA
+
+
+
+           slot                                                                                          slot
+
+
+
+    MTA                                    MTA                        MTA                                    MTA
+
+
+
+PhoneNet                               PhoneNet                    PhoneNet                               PhoneNet
+
+
+
+  modem                                  modem                       modem                                  modem
+
+
+
+_______________________________________Figure_1:__The_MHS_Model_________________________________________________________
+
+
+
+                                                           14
+
+
+
+
+________________________________________________________________________________________________________________________
+
+Any  Host                                          MZnet  Host                                                 PC
+
+
+
+     user                                                                                                     user
+
+
+
+     UA                                                                                                        UA
+
+
+
+           slot                                                           split slot
+                                                       MZnet                                                MZnet
+
+
+
+    MTA                                    MTA
+
+
+
+PhoneNet                               PhoneNet                    PhoneNet                               PhoneNet
+
+
+
+  modem                                  modem                       modem                                  modem
+
+
+
+____________________________________Figure_2:__The_Split-Slot_Model_____________________________________________________
+
+
+
+                                                           15
diff --git a/docs/historical/realwork.pdf b/docs/historical/realwork.pdf
new file mode 100644
index 0000000..4c56b91
Binary files /dev/null and b/docs/historical/realwork.pdf differ
diff --git a/docs/historical/realwork.txt b/docs/historical/realwork.txt
new file mode 100644
index 0000000..4e69868
--- /dev/null
+++ b/docs/historical/realwork.txt
@@ -0,0 +1,2445 @@
+
+
+
+
+                                                   MH.5:
+
+                          How  to  process  200  messages  a  day
+
+                           and  still  get  some  real  work  done./
+
+
+                                            Marshall T. Rose
+
+                                Member, Research Technical Staff
+
+                          Northrop Research and Technology Centery
+
+
+
+                                             John L. Romine
+
+                                     Computing Support Group
+
+                     Department of Information and Computer Science
+
+                                   University of California, Irvinez
+
+
+
+                                                Abstract
+
+
+        The  UCI  version  of  the  Rand  Message  Handling  System  (MH)  is  dis-
+
+        cussed.  MH is a powerful user agent which operates in the ARPA Internet
+
+        and UUCP environments.  In addition to the usual functions provided
+
+        by similar programs, MH has several distinguishing characteristics which
+
+        give the user additional message handling capability.  In particular, MH
+
+        provides  mechanisms  for  maintaining  an  organized  mail  environment,
+
+        tailoring its behavior, and extending its functions.
+
+
+        This document describes MH from several perspectives.  Particular em-
+
+        phasis is given to:  the MH user environment, advanced features of MH
+
+        which  have  proven  to  be  particularly  useful  for  sophisticated  users  of
+
+        electronic mail, the user interface issues in MH, and the mh.5 distribu-
+
+        tion.  The paper concludes with a summary of the authors' experiences
+
+        with MH, and a discussion of future areas of enhancement.
+
+
+
+_____________________________________
+./ Alternate title: MH: Your Key to Success.
+y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
+
+Computer mail: MRose% NRTC@USC-ECL, : : :!fucbvax!ucivax,trwrbg!nrtc!mrose.
+z University of California at Irvine, Irvine, CA 92717. Telephone: 714/856-6852.
+
+Computer mail: J-Romine@USC-ECL, : : :!fucbvax,trwrbg!ucivax!jromine.
+
+
+                                                   MH.5:
+
+                          How  to  process  200  messages  a  day
+
+                             and  still  get  some  real  work  done
+
+
+
+Introduction
+
+        The UCI version of the Rand Message Handling System, MH, is a software
+
+system  that  performs  two  functions:  first_,  it  interfaces  a  user  to  a  message
+
+transport system, so the user may receive and send mail; second___, it permits the
+
+user to maintain an organized mail environment to facilitate the composition of
+
+new messages and the reading of old messages.  In short, while not responsible for
+
+the delivery of messages, MH aids the user in handling mail.
+
+
+        MH  was  originally  developed  by  the  Rand  Corporation,  and  initially  was
+
+proprietary  software.   The  Department  of  Information  and  Computer  Science
+
+at  University  of  California,  Irvine,  shortly  after  joining  the  Computer  Science
+
+Network (CSnet), acquired a copy of MH, and began additional development of
+
+the software.  Since that time, the Rand Corporation has declared MH to be in the
+
+public domain, and the UCI version of MH has passed through four major releases.
+
+The current version, mh.5, is available from U.C. Irvine for a nominal distribution
+
+fee, or may be retrieved from the University of Delaware via anonymous FTP.
+
+
+        Much credit must be given to the initial designers and implementors of MH:
+
+Bruce Borden, Stockton Gaines, and Norman Shapiro.  Although MH has suffered
+
+significant  development  at  UCI  since  Rand's  initial  release,  the  fundamental
+
+concepts  of  MH's  environs  have  remained  nearly  unchanged.   In  addition,  the
+
+authors of the current release gratefully acknowledge the comments of the many
+
+sites which have run various releases of MH in the past.  In particular, the dozen
+
+or so beta test sites for mh.5 provided tremendous help in stabilizing the current
+
+release.
+
+
+        MH  runs  on  different  versions  of  the  UNIX1  operating  system  (such  as
+
+Berkeley  4.2bsd  and  various  flavors  of  v7).   In  addition,  MH  supports  four
+
+different  message  transport  interfaces:  SendMail[EAllm83],  the  standard  mailer
+
+for 4.2bsd systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel
+
+Memo Distribution Facility developed by the University of Delaware which forms
+
+the software-backbone for CSnet[DCome83] mail relay service; SMTP, the ARPA
+
+Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery system.
+
+
+
+_____________________________________
+1  UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+                                                       1
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              2
+
+
+        This  paper  is  organized  in  a  straight-forward  fashion:  Initially,  the  MH
+
+philosophy  of  mail  handling  is  presented,  along  with  a  description  of  the
+
+environment which the MH user is given to process mail.  Following this, certain
+
+advanced features of MH are discussed in more detail, such as facilities for selecting
+
+messages, and "advanced" concepts in draft handling.  In addition, user interface
+
+issues in mail handling are addressed, and the merits of MH's approach is critically
+
+examined.  Next, the mh.5 distribution package is described.  Finally, we conclude
+
+by discussing the authors' experience with MH development and introducing areas
+
+where MH may be further developed.
+
+
+        Although  familiarity  with  MH  is  not  assumed  on  the  part  of  the  reader,
+
+some knowledge of the UNIX operating system is useful.  Appendix A gives a short
+
+synopsis of the MH commands.
+
+
+
+The MH Philosophy
+
+        Although MH has many traits which tend to distinguish it from other systems
+
+which handle mail, there is a single fundamental design decision which influences
+
+the interface between MH and the user:  MH differs from most other systems in
+
+that it is composed of many small programs instead of one very large one.  This
+
+architecture gives MH much of its strength, since intermediate and advanced users
+
+are able to take advantage of this flexibility.
+
+
+        The key to this flexibility is that the UNIX shell (usually the C shell or the
+
+Bourne shell), is the user's interface to MH. This means that when handling mail,
+
+the entire power of the shell is at the user's disposal, in addition to the facilities
+
+which MH provides.  Hence,  the user may intersperse mail handling commands
+
+with other commands in an arbitrary fashion, making use of command handling
+
+capabilities which the user's shell provides.
+
+
+        Furthermore, rather than storing messages in a complicated data structure
+
+within a monolithic file, each message in MH is a UNIX file, and each folder (an
+
+object  which  holds  groups  of  messages)  in  MH  is  a  UNIX  directory.   That  is,
+
+the directory- and file-structure of UNIX is used directly.  As a result, any UNIX
+
+file-handling command can be applied to any message.
+
+
+        To the novice, this may not make much sense or may not seem important.
+
+However,  as  users  of  MH  become  more  experienced,  they  find  this  capability
+
+attractive.  In addition, this approach is often quite pleasing to system implemen-
+
+tors,  because  it  minimizes  the  amount  of  coding  to  be  performed,  and  given  a
+
+modular design, changes to the software system can be maintained easily.  There
+
+are,  however,  performance penalties to be paid with this scheme.  This issue is
+
+considered later in the paper.
+
+
+        Having described how MH fits into the UNIX environment, we now discuss
+
+the mail handling environment which is available to the MH user.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              3
+
+
+The MH Environs
+
+        In the $ HOME       directory of each MH user, a file named .mh_profile     contains
+
+static information about the user's MH environment, and default arguments for
+
+MH programs.  For the latter case, each line of profile takes the form:
+
+
+           program-name: options
+
+
+Each MH program consults the user's .mh_profile     for its options.  These options
+
+are consulted prior to evaluating any command-line arguments, and so provide the
+
+MH user the capability to customize the defaults for each command.  Futher, by
+
+using the UNIX link facility, different names can be given to the same command.
+
+Since each MH command looks in the .mh_profile     for a component with the name
+
+by  which  it  was  invoked,  it's  possible  to  have  different  defaults  for  the  same
+
+program.  For example, it is not uncommon to link prompter (a simple prompting
+
+editor front-end) under the name rapid in the user's bin/   directory, and add to the
+
+.mh_profile    :
+
+
+           rapid: -prepend -rapid
+
+
+As a result, when prompter is invoked as rapid, it automatically uses the `-prepend'
+
+and `-rapid'      options.
+
+
+        The profile component ``Path:''       is the path to the user's MH-directory,
+
+usually Mail.  In addition to containing the user's folders, the MH-directory also
+
+contains skeletons and templates used by the MH programs, and the user's context
+
+file.  This latter file has the same format as the user's .mh_profile    , and contains the
+
+dynamic, context-dependent information about the user's environment.  Whenever
+
+MH looks for an MH-specific file, such as a template or skeleton, it first consults
+
+the user's MH-directory, and then a system-wide library area.
+
+
+        The MH user always has a current folder, which is the folder in which the user
+
+is currently (or was last) working.  Since any MH program which deals with folders
+
+implicitly manipulates this information, the name of the current folder is stored in
+
+the context    component ``Current-Folder:''            .  Every folder has a current message
+
+known as `cur'   .  These values are the defaults for MH commands which accept
+
+folder and/or messages arguments.
+
+
+        MH programs make use of a set of envariables which further customize their
+
+behavior.  The $ MH    envariable, if present, specifies the name of an alternate profile
+
+for the user.  This allows a user of MH to easily maintain multiple mail-handling
+
+environments.
+
+
+        In terms of command syntax, most MH commands accept an optional folder
+
+argument, such as `+outbox'      .  Unlike most UNIX commands, all MH commands
+
+have  switches  which  are  words,  rather  than  single  letters.   Switches  may  be
+
+abbreviated  to  the  least  unambiguous  prefix.  All  MH  commands  also  support
+   Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              4
+ _______________________________________________________________________________________________________________
+
+  1   %  inc
+  2   Incorporating  new  mail  into  inbox...
+  3
+  4       1+  03/16  Rand  MH  System      MH  transcript   <<Here's  the  body  of  a  sample  m
+  5
+  6   %  show
+  7   (Message  inbox:1)
+  8   To:  jromine@uci-icsa
+  9   Subject:  MH  transcript
+10    Date:  16  Mar  85  18:28:59  PST  (Sat)
+11    From:  Rand  MH  System  <mh@uci-icsa>
+12
+13    Here's  the  body  of  a  sample  message.
+14    %  repl
+15    To:  Rand  MH  System  <mh@uci-icsa>
+16    cc:  jromine@uci-icsa
+17    Subject:  Re:  MH  transcript
+18    In-reply-to:  Your  message  of  16  Mar  85  18:28:59  PST  (Sat).
+19    --------
+20    Thanks  for  the  test.
+21
+22    /JLR
+23    ^D
+24
+25    What  now?  send
+26    %  comp
+27    To:  MRose@UCI
+28    cc:
+29    Subject:  sample  comp
+30    --------
+31    Here's  a  sample  compose  for  the  MH  transcript.
+32
+33    /JLR
+34    ^D
+35
+36    What  now?  send  -verbose
+37      --  Posting  for  All  Recipients  --
+38       --  Local  Recipients  --
+39       MRose:  address  ok
+40      --  Recipient  Copies  Posted  --
+41    Message  Processed
+
+
+                                                  Figure 1
+
+ _____________________________________________An_MH_Session_____________________________________________________
+
+
+
+ a  `-help'     switch,  which  lists  the  syntax  of  the  command  along  with  available
+
+ switches, and the version number of the command.  Most MH commands also take
+
+ a `msg'    or `msgs'     argument which takes the form of a message number (``1''   ), a
+
+ message range (``1-2''     ), a standard sequence name (``cur''     ), or a user-defined
+
+ sequence name (``select''      ).
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              5
+
+
+An MH Transcript
+
+        Figure 1 contains a transcript of a simple MH session.  First, inc is run to
+
+incorporate the new mail into the user's ``+inbox''       folder.
+
+
+        A  scan  listing  of  the  mail  is  printed  while  it  is  being  incorporated.  (The
+
+user could run scan explicitly to generate additional scan listings later on.)  The
+
+scan  listing  gives  the  message  number,  followed  by  the  date,  message  sender,
+
+and subject.  (If the message originated from the user generating the listing, the
+
+``to:''      addressee is displayed instead of the sender.)  If the subject is short, the
+
+first part of the message body is displayed after the characters ``<<''    .  The plus
+
+sign (`+') after the message number indicates the current message.
+
+
+        The user show s the message, and decides to repl y.  A reply draft is created
+
+using  the  headers  of  the  message  being  replied-to,  using  the  default  replcomps
+
+template.  The  default  editor,  prompter,  is  called  to  edit  the  draft.  When  an
+
+EOT is typed, prompter exits and the user is left at the What  now?  prompt.  The
+
+option send is chosen.  Since there were no problems in posting the draft with the
+
+message transport system, no additional output is produced.  (MH is not verbose
+
+by default.)
+
+
+        The  user  then  decides  to  compose  a  new  message.  The  default  skeleton,
+
+components      ,  is  copied  to  the  draft,  and  prompter  is  once  again  called.   After
+
+entering the addresses, subject, and body, the user then send s the draft   from the
+
+What  now?  prompt, using ``send -verbose''           , which causes MH to list out the
+
+message addresses as it submits them to the message transport system.
+
+
+
+Some MH Features
+
+        We now consider certain advanced features in MH. These features have been
+
+chosen to demonstrate some useful capabilities available to the MH user.
+
+
+Message Sequences and Selection
+
+        MH  has  several  built-in  message  sequence  names,  which  may  be  used
+
+anywhere a `msg'     or `msgs'     argument is expected.  These are:  `cur'   , `next'    ,
+
+`prev'    , `first'     , `last'    , and `all'   .  Message ranges may also be specified.  For
+
+example, `all'     is actually `first-last'        , and `+mh last:5'         references the last
+
+five messages in your `+mh'    folder.  A powerful capability of MH is the ability to use
+
+not only the pre-defined message sequence names, but also arbitrary user-defined
+
+message sequence names.
+
+
+        Although all MH programs recognize user-defined sequences when appropriate,
+
+the  pick  and  mark  commands  can  create  and  modify  user-defined  message
+
+sequences.  The mark command allows low-level manipulation of sequences, and is
+
+not particularly interesting in our discussion.
+
+
+        The pick command selects certain messages out of a folder.  The criteria used
+
+for selection may be a search string and/or a date range.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              6
+
+
+        Searching  is  performed  on  either  a  specific  header  in  the  message  (e.g.,
+
+``To:''     ), or anywhere within the message.  By default, pick lists out the message
+
+numbers that matched the selection criteria.  Thus, pick is useful in backquoted
+
+operations to the shell.  For example, to scan all the messages in the current folder
+
+from "frated", the MH user issues the command:
+
+
+           scan `pick -from frated`
+
+
+To  perform  more  complicated  message  selection,  user-defined  sequences  are
+
+employed.  Supplying a `-sequence name'           argument to pick, will cause it to define
+
+the sequence `name'     as those messages matched.
+
+
+        Giving  pick  a  list  of  messages  causes  it  to  limit  its  search  to  just  those
+
+messages.  For example, to find all the messages in the current folder from "frated"
+
+also dated before friday:
+
+
+           pick -from frated -sequence select
+
+           pick select -before friday -sequence select
+
+
+With the first pick command, the sequence ``select''        is defined to be all those
+
+messages from "frated".  In the second command, only those messages already in
+
+the ``select''       sequence are searched, and the ``select''       sequence is redefined
+
+to be only those messages which are also dated before friday.  Those messages could
+
+then be show n with:
+
+
+           show select
+
+
+When  a  `-sequence name'           argument  is  given  to  pick,  the  default  behavior  _
+
+listing the message numbers matched _ is inhibited.  To re-enable this behavior,
+
+the `-list'     option may be given.  As a result, advanced users of MH often put the
+
+following line in their .mh_profile    :
+
+
+           pick: -sequence select -list
+
+
+which allows them to easily make use of the `select'      sequence as the messages
+
+last selected with pick.
+
+
+        Often it is desirable to act upon those messages which are not members of
+
+a given sequence.  For this purpose, the ``Sequence-Negation:''               profile entry
+
+is useful.  If the name of a user-defined sequence is prefixed with the value of the
+
+sequence-negation profile entry, MH commands will operate upon those messages
+
+which are not members of that sequence.  For example, given a profile entry of:
+
+
+           Sequence-Negation: not
+
+
+those messages which are not in the `select'      sequence could be scan'd with:
+
+
+           scan notselect
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              7
+
+
+        Obviously, some confusion could result if an attempt was made to define a se-
+
+quence name which began with the sequence-negation string (e.g., ``notselect''        ).
+
+For this reason, MH users will often use a single character, which their shell doesn't
+
+interpret, as their sequence-negation string (e.g., up-caret (`^') for C Shell users,
+
+and exclamation-mark (`!')  for Bourne shell users).
+
+
+        MH also provides a way of automatically remembering the last message list
+
+given to an MH command.  This facility is implemented by using a profile entry
+
+called ``Previous-Sequence:''              .
+
+
+Draft Handling
+
+        After  the  initial  edit  of  a  message  draft,  the  comp,  dist,  forw,  and  repl
+
+programs give the user a What  now?  prompt.  The valid responses include:  edit to
+
+re-edit the draft, quit to exit without sending the draft, send to send the draft, and
+
+push to send the draft in the background.
+
+
+        When the send option is given, the draft is posted with the message transport
+
+system.  If there problems posting the draft, the What  now?  prompt is re-issued, so
+
+errors in the draft may be corrected.
+
+
+        Since posting the draft can be slow, the push option allows the MH user to
+
+send the draft in the background, and return immediately to the shell.  If there are
+
+problems posting the message, the user will not see the diagnostics produced by
+
+the message transport system.  For this reason, if push is used instead of send, and
+
+the message is not successfully posted, MH mails a message to the user containing
+
+any diagnostics which the message transport system produced along with a copy
+
+of the message.  Later, the draft may be re-edited by entering ``comp -use''        .
+
+
+        A relatively new feature of MH is the ability to use a folder to store multiple
+
+drafts.  These drafts are kept in an ordinary MH folder, and may be operated upon
+
+by MH commands.  To enable this feature, the MH user selects a folder-name for
+
+the draft-folder, and creates an entry in the .mh_profile    :
+
+
+           Draft-Folder: +foldername
+
+
+From this point on, when a message is composed, the draft will be created as a
+
+message in that folder, instead of using the draft   file in the user's MH directory.
+
+Unfortunately, if posting problems occur on a message which has been push'd, it
+
+may be difficult to re-edit the draft with ``comp -use''        .  This might be the case
+
+if the user had started composing another message, while that first draft was being
+
+posted.  In  that  event,  the  current-message  in  the  draft-folder  would  no  longer
+
+point to the failed draft.
+
+
+        There is a solution for this problem, however.  By default, push assumes the
+
+`-forward'        option,  which  says  that  if  the  message  draft  fails  to  be  posted,  it
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              8
+
+
+should be forwarded back to the user in the error report which push generates.
+
+The failed draft may then be extracted with the burst program (discussed later).
+
+
+BBoards
+
+        MH has a convenient interface to the UCI BBoards facility[MRose84a].2  This
+
+facility  permits  the  efficient  distribution  of  interest  group  messages  on  a  single
+
+host, to a group of hosts under a single administration, and to the ARPA Internet
+
+community.
+
+
+        Although most readers are probably familiar with the concept of an interest
+
+group in the Internet context, a brief description is now given.  Observant readers
+
+will notice that the distributed nature of the "network news" (a.k.a. USENET)
+
+tends to avoid many of the problems described below.
+
+
+        Described simply, an interest group is composed of a number of subscribers
+
+with a common interest.  These subscribers post mail to a single address, known
+
+as the distribution address (e.g., MH-Workers@UCI. From this distribution address,
+
+a copy of the message is sent to each subscriber.  Each group has a moderator,
+
+who is the person that runs the group.  This moderator can usually be reached at
+
+a special address, known as the request address (e.g., MH-Workers-Request@UCI).
+
+Usually,  the  responsibilities  of  the  moderator  are  quite  simple,  since  the  mail
+
+system handles distribution to subscribers automatically.  In some interest groups,
+
+instead of each separate message being distributed directly to subscribers, a batch
+
+of (hopefully related) messages are put into a digest format by the moderator and
+
+then sent to the subscribers.  (This is similar to a newsletter format.)  Although
+
+this requires more work on the part of the moderator and introduces delays, such
+
+groups tend to be better organized.
+
+
+        Unfortunately, some problems arise with the scheme outlined above.  First,
+
+if two users on the same host subscribe to the same interest group, two copies of
+
+the message are delivered.  This is wasteful of both processor and disk resources at
+
+that host.
+
+
+        Second, some groups carry a lot of traffic.  Although subscription to a group
+
+does indicate interest on the part of a subscriber, it is usually not interesting to get
+
+50 or so messages delivered each day to the user's private maildrop, interspersed
+
+with personal mail,  which is likely to be of a much more important and timely
+
+nature.
+
+
+        Third, if a subscriber's address in a distribution list becomes "bad" somehow
+
+and causes failed mail to be returned, the originator of the message is normally
+
+notified.  It is not uncommon for a large list to have several bogus addresses.  This
+
+results in the originator being flooded with "error messages" from mailers across
+
+
+_____________________________________
+2  The UCI BBoards facility can run under either the MMDF or SendMail, or in a more restricted
+
+form under stand-alone MH.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985              9
+
+
+the Internet stating that a given address on the list was bad.  Needless to say, the
+
+originator usually does not care if the bogus addresses got a copy of the message
+
+or not.  The originator is merely interested in posting a message to the group at
+
+large.  On the other hand, the moderator of the group does care if there are bogus
+
+addresses on the list, but ironically does not receive notification.
+
+
+        To solve these problems, the UCI BBoards facility introduces a new entity
+
+into the picture:  a distribution channel.  All interest group mail is handled by the
+
+special mail system component.  The distribution address for an interest-group
+
+maps mail for that interest-group to the distribution channel, which then performs
+
+several actions.  First, if local delivery is to be performed, a copy of the message is
+
+placed in a global maildrop for the interest group with a timestamp and a unique
+
+number.  Local users can read messages posted for the interest group by reading
+
+this "public" maildrop.  Second, if further distribution is to take place, a copy of
+
+the message is sent to the distribution address in such a way that if any of the
+
+addresses are bogus, failure notices will be returned to the local maintainer of the
+
+group address list, rather than the originator of the message.
+
+
+        This scheme has several advantages:  First, messages delivered to the local
+
+host are processed and saved once in a globally accessible area.  The UCI BBoards
+
+facility supports software which allows a user to query an interest group for new
+
+messages and to read and process those messages in the MH-style.  Second, once
+
+a host administrator subscribes to an interest group, each user may join or quit
+
+the list's readership without contacting anyone.  Third, a hierarchical distribution
+
+scheme can be constructed to reduce the amount of delivery effort.  Finally, errors
+
+are prevented from propagating.  When an address on the distribution list goes
+
+bad, the list moderator who is responsible for the address is notified.  If a local
+
+moderator does not exist,  then the local PostMaster is notified (not the global
+
+group moderator).
+
+
+        In addition to solving the problems outlined above, the UCI BBoards facility
+
+supports several other capabilities.  BBoards may be automatically archived in
+
+order  to  conserve  disk  space  and  reduce  processing  time  when  reading  current
+
+items.   Also,  the  archives  can  be  separately  maintained  on  tape  for  access  by
+
+interested researchers.
+
+
+        Special  alias  files  may  be  generated  which  allow  the  MH  user  to  shorten
+
+address entry.  For example, instead of sending to SF-Lovers@Rutgers, a user of
+
+MH usually sends to ``SF-Lovers''          and the MH aliasing facility automatically
+
+makes the appropriate expansion in the headers of the outgoing message.  Hence,
+
+the user need only know the name of an interest group and not its global network
+
+address.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             10
+
+
+        Finally, the UCI BBoards facility supports private interest groups using the
+
+UNIX  group  access  mechanism.  This  allows  a  group  of  people  on  the  same  or
+
+different machines to conduct a private discussion.
+
+
+        The practical upshot of all this is that the UCI BBoards facility automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+        MH provides three programs to deal with interest groups.  The bbc program
+
+is used to check on the status of one or more groups, and to optionally start an
+
+MH shell on those groups which the user is interested in.  The bbl program can be
+
+used to manually perform maintenance on a discussion group beyond the normal
+
+automatic  capabilities  of  the  UCI  BBoards  facility.  Finally,  the  msh  program
+
+implements  an  MH  shell  for  reading  BBoards,  in  which  nearly  all  of  the  MH
+
+commands are implemented in a single program.
+
+
+        Observant  readers  may  note  that  the  use  of  msh  is  contrary  to  the  MH
+
+philosophy of using relatively small, single-purpose programs.  Sadly, the authors
+
+admit that this is true.  In an effort to minimize use of system resources however,
+
+BBoards are kept in maildrop format instead of folders.3  Some research has gone
+
+into overcoming this problem to restore MH's purity of purpose, but all solutions
+
+proposed  to  date  are  either  unworkable  or  require  significant  recoding  of  MH's
+
+internals.
+
+
+Bursting
+
+        Internet interest group mail is often sent out in digest form.  The experienced
+
+MH user may wish to deal with the digest messages on an individual basis, however.
+
+The burst program allows the MH user to extract these digest messages, and store
+
+each as an individual MH message.
+
+
+        Burst will also extract forwarded messages generated by forw (or the forwarded
+
+message  in  the  error  report  generated  by  push,  as  described  above).  Although
+
+burst cannot always decapsulate messages encapsulated by sites not running MH,
+
+it adheres to the proposed standard described in [MRose85b].
+
+
+
+_____________________________________
+3  When the message transport system delivers a message to a user it stores it in a single file, called
+
+a maildrop. Since many messages may be present in a single maildrop, (in theory) there is a unique
+string acting as a separator between messages in the maildrop.  Although this is convenient for
+storage of messages, it makes retrieval more difficult unless a separate index into the maildrop is
+kept. This latter approach is taken by the msg program available with MMDF-II and by msh as well.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             11
+
+
+Distributed Mail
+
+        The  ARPA  Internet  community  consists  of  many  types  of  heterogeneous
+
+nodes.  Some  hosts  are  large  mainframe  computers,  others  are  personal  work-
+
+stations.  All  communicate  using  the  milstd  TCP/IP  protocol  suite[IP, TCP].
+
+Messages which conform to the Standard for the Format of ARPA Internet Text
+
+Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
+
+
+        On smaller nodes in the ARPA Internet, it is often impractical to maintain
+
+a message transport system (e.g., SendMail).  For example, a workstation may not
+
+have sufficient resources (cycles, disk space) in order to permit an SMTP server
+
+and associated local mail delivery system to be kept resident and continuously
+
+running.  Furthermore, the workstation could be off-net for extended periods of
+
+time.  Similarly, it may be expensive (or impossible) to keep a personal computer
+
+interconnected to an IP-style network for long periods of time.  In other words, the
+
+node is lacking the resource known as "connectivity".
+
+
+        Despite  this,  it  is  often  desirable  to  be  able  to  manage  mail  with  MH  on
+
+these smaller nodes, and they often support a user agent to aid the tasks of mail
+
+handling.  To solve this problem,  a network node which can support a message
+
+transport  entity  (known  as  service  host)  offers  a  maildrop  service  to  these  less
+
+endowed nodes (known as client hosts).  The Post Office Protocol[JReyn84] (POP)
+
+is intended to permit a workstation to dynamically access a maildrop on a service
+
+host to pick-up mail.4  The level of access includes the ability to determine the
+
+number of messages in the maildrop and the size of each message, as well as to
+
+retrieve and delete individual messages.  More sophisticated implementations of the
+
+POP server are able to distinguish between the header and body portion of each
+
+message, and send n lines of a message to the POP client.  This capability is useful
+
+in thinly connected environments where conservation of bandwidth is important.
+
+By utilizing a more intelligent POP client, a user may generate "scan listings" and
+
+decide dynamically which messages are worth taking delivery on.  The philosophy
+
+of the POP is to put intelligence in the POP clients and not the POP servers.
+
+
+        The current release of MH supports the above model fully.  A POP client
+
+program is available to retrieve a maildrop from a POP service host.  In addition,
+
+using  the  SMTP  configuration  for  delivery  in  MH  (either  in  conjunction  with
+
+SendMail  or  the  MMDF),  a  user  is  able  to  specify  a  search-list  of  service  hosts
+
+(and/or networks) to try to post mail.  Using this search-list, when an MH user
+
+posts a draft,  the post program will attempt to establish an SMTP connection
+
+with  each  host  in  the  search-list  to  post  the  message  until  it  succeeds.  Initial
+
+
+_____________________________________
+4  Actually, there are three different descriptions of the POP. The first, cited in [JReyn84], was the
+
+original description of the protocol, which suffered from certain problems. Since then, two alternate
+descriptions have been developed. The official revision of the POP[MButl85], and the revision of the
+POP which MH uses (which is documented in an internal memorandum in the MH release).  This
+paper considers the POP in the context of the MH release.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             12
+
+
+experimentation  using  the  POP  and  MH  in  a  local  network  environment  has
+
+proved quite successful.
+
+
+
+User Interface Issues in MH
+
+        At this point, it is perhaps useful to take a step backwards and examine the
+
+success and problems of MH's approach to user interfaces.
+
+
+Creeping Featurism
+
+        A complaint often heard about systems which undergo substantial develop-
+
+ment by many people over a number of years, is that more and more options are
+
+introduced which add little to the functionality but greatly increase the amount of
+
+information a user needs to know in order to get useful work done.  This is usually
+
+referred to as creeping featurism.
+
+
+        Unfortunately MH, having undergone six years of off-and-on development by
+
+ten or so well-meaning programmers (the present authors included), suffers mightily
+
+from this.  For example, the send command has twenty-five visible switches, and at
+
+least nine hidden switches, for a total of thirty-four.  The poor user who types
+
+
+           send -help
+
+
+watches the options scroll off the screen (since the `-help'      switch also lists out
+
+four other lines of information).5   The sad part is that all of these switches are
+
+useful in one form or another.
+
+
+        There are a lot of good things to be said for the "one program, one function"
+
+philosophy of system design.  In the MH case, however, each program really does
+
+only  one  mail  handling  activity  (with  a  few  minor  exceptions).   The  options
+
+associated with each command are present to modify the program's behavior to
+
+perform similar, but slightly different tasks.  In further defense of MH, note that
+
+there are 32 MH commands at present, all performing different tasks.
+
+
+        The problem with creeping featurism though, is that while the functionality
+
+of the system increases sub-linearly, the complexity of the system increases linearly.
+
+That is, although the number of switches that a program takes might double, it is
+
+unlikely that the program's functionality or capabilities will double.
+
+
+
+_____________________________________
+5  Recently, this was fixed by compressing the way in which switches are presented. The solution is
+
+only temporary however, as send will no doubt acquire an endless number of switches in the years
+to come.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             13
+_______________________________________________________________________________________________________________
+
+To:
+cc:
+Bcc:
+Fcc:  outbox
+Fcc:
+Subject:
+Reply-To:
+--------
+
+
+                                                 Figure 2
+
+______________________________________________Draft_Skeleton___________________________________________________
+
+_______________________________________________________________________________________________________________
+
+To:  <reply-to_from>
+cc:  <?to_cc><to>,<cc>
+Fcc:  +outbox
+Fcc:  <?fcc><fcc>
+Subject:  <?subject>Re:  <subject>
+In-reply-to:  <?date><?message-id>Your  message  of  <date>.
+       <message-id>
+In-reply-to:  <?date><!message-id>Your  message  of  <date>.
+--------
+
+
+                                                 Figure 3
+
+_____________________________________________Reply_Template____________________________________________________
+
+
+
+Templates versus Switches
+
+        One  way  to  trim  the  explosion  of  available  options,  while  still  increasing
+
+functionality, is to introduce options with a richer domain.  Hence, instead of using
+
+options which take on or off forms or simple numeric or string values, the possible
+
+values which an option might take on is given a large space.  There are several ways
+
+that this might be accomplished.
+
+
+        The comp,  dist,  and forw programs use draft skeletons (simple form fill-in
+
+files) to construct the general format of the draft being composed.  An example of
+
+a draft skeleton used for composing new messages (by comp) is shown in Figure 2.
+
+The approach is to let the user specify (and later edit) both arbitrary headers of
+
+draft and the body of the draft.  Note while most of the fields are empty, the first
+
+``Fcc:''       field already contains a value.  By using the simple prompting editor,
+
+prompter, the user can speedily enter the headers of the message.  The prompter
+
+program given the skeleton in Figure 2 would prompt the user for the contents
+
+of each field, except for the second ``fcc:''     , which it would include verbatim.
+
+It would then read the body of the message up to an end-of-file.  Naturally, the
+
+MH user is free to use any editor to edit any part of the draft (headers or body).
+
+This example demonstrates the flexibility achieved by not limiting what headers a
+
+draft may contain (which most mail sending programs do), while still retaining the
+
+simplicity of being able to treat the entire message draft as a UNIX file.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             14
+_______________________________________________________________________________________________________________
+
+From:  <?me>Message  Agent  "<<me>>
+To:  <reply-to_from>
+Fcc:  +rcvtrip
+Fcc:  <?fcc><fcc>
+Subject:  <?subject>BEEP!  Re:  <subject>
+Subject:  <!subject>BEEP!
+In-reply-to:  <?date><?message-id>Your  message  of  <date>.
+       <message-id>
+In-reply-to:  <?date><!message-id>Your  message  of  <date>.
+--------
+
+
+      This  is  an  automatic  reply.   Feel  free  to  send  additional  mail,  as  only
+      this  one  notice  will  be  generated.
+
+
+      I  am  attending  the  USENIX  Summer  '85  conference  in  Portland,  Oregon.
+      I  expect  to  be  reading  mail  again  on  the  16th  of  June.
+
+
+/mtr
+
+
+                                                 Figure 4
+
+__________________________________The_tripcomps______Reply_Template____________________________________________
+
+
+
+        Another  more  interesting  approach  is  used  by  the  repl  command,  which
+
+constructs a draft in reply-to a previously received message.  Instead of adding
+
+switches to indicate which fields of the draft should be derived from the message
+
+being replied-to, and how they should be derived, a single option, the ability to
+
+specify a template, was made available.  An example of a reply template is shown
+
+in Figure 3.  Put simply,  based on the presence of certain fields in the message
+
+being replied-to, and a few switches given by the user, using the reply template,
+
+repl generates the reply draft automatically.
+
+
+        This facility, for example, can be used to generate automatic replies.6  One
+
+function  might  be  to  write  a  rcvtrip  shell  script  which  automatically  answered
+
+messages when mail wasn't being read for a period of time (e.g., while attending a
+
+conference).  An example of a reply template at the heart of such a script is shown
+
+in Figure 4.
+
+
+        Finally, another application might be to utilize the highly useful letter bomb
+
+protocol.7  The important thing to note about this template is that it generates
+
+not only the headers of the reply draft (with a creative ``Reply-to:''         address),
+
+but the body as well.  Hence, the commands
+
+
+           repl -form bombcomps -noedit ; rmm
+
+
+_____________________________________
+6  MH supports the notion of a user-defined mail hook which is invoked each time a user receives
+
+mail.
+7  The  authors  wish  to  credit  Ron  Natalie  of  the  Ballistics  Research  Laboratory  in  Aberdeen,
+
+Maryland for formalizing the use of this protocol in the ARPA Internet community.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             15
+_______________________________________________________________________________________________________________
+
+To:  <reply-to_from>
+cc:  <?to_cc><to>,<cc>
+Fcc:  +outbox
+Fcc:  <?fcc><fcc>
+Subject:  <?subject>Re:  <subject>
+In-reply-to:  <?date><?message-id>Your  message  of  <date>.
+       <message-id>
+In-reply-to:  <?date><!message-id>Your  message  of  <date>.
+Reply-To:  /dev/null
+--------
+
+
+                                   "
+                                  *-XXX
+                                   /    XX
+                                           X
+                                              X
+                                               X
+                                               X
+                                               X
+                                          IIIIIIIII
+                                          IIIIIIIII
+                                          IIIIIIIII
+                                          IIIIIIIII
+                                          XXXXXXXXX
+                                XXXXXXXXXXXXXXXXXXXXXXX
+                            XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+               XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+            XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+            XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+            XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+               XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                            XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+                                XXXXXXXXXXXXXXXXXXXXXXX
+                                          XXXXXXXXX
+
+
+                                                 Figure 5
+
+_________________________________The_bombcomps________Reply_Template___________________________________________
+
+
+
+           What now? push
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             16
+_______________________________________________________________________________________________________________
+
+width=80,length=0,overflowtext=,overflowoffset=10
+Date:leftadjust,compress,compwidth=9
+Subject:leftadjust,compress,compwidth=9
+From:leftadjust,compress,compwidth=9
+To:leftadjust,compress,compwidth=9
+cc:leftadjust,compress,compwidth=9
+Resent-Note:leftadjust,compwidth=9
+:
+body:nocomponent,overflowoffset=0
+
+
+                                                 Figure 6
+
+____________________________________________Display_Template___________________________________________________
+
+
+
+are very handy for dealing with disturbing mail in a straight-forward manner.  Of
+
+course, repl could be linked to bomb in the user's bin/   directory and an appropriate
+
+line could be added to the user's MH profile, in order to further shorten type-in.
+
+
+        A variation on the reply template is the display template.  A display template,
+
+as used by the mhl program, contains instructions on how to format a message.  In
+
+addition to being used by show, et. al., the forw program can also use a display
+
+template to format each message being forwarded.  Similarly, although repl uses a
+
+reply template to construct the draft being composed, it also may use a display
+
+template to format the body of the message being replied-to for enclosure in the
+
+reply.  Furthermore, the post program may use a display template to format the
+
+body of a blind-carbon-copy.  An example of a display template used for formatting
+
+forwarded messages is shown in Figure 6.
+
+
+        As with reply templates, display templates can offer a lot of functionality.
+
+For example, the one line display template:
+
+
+           body:nocomponent,overflowtext=,overflowoffset=0,width=10000
+
+
+can be used to extract the body of a message, while ignoring the headers.  Hence,
+
+if a shar archive arrived in the mail, a convenient way to unpack it, assuming the
+
+above display template was called mhl.body     , would be:
+
+
+           show -form mhl.body _ sh
+
+
+
+        The biggest win with display templates, of course, is that all those annoying
+
+header lines which mailers everywhere generate can be simply and easily filtered
+
+out.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             17
+
+
+Modularity versus Monolithicity
+
+        Since MH is a set of programs which perform separate tasks, as opposed to
+
+being a single, monolithic program, the power of the shell is used directly to aid in
+
+mail-handling.  One powerful capability which this design achieves is the ability to
+
+extend the MH command set, by developing shell scripts which use the standard
+
+MH programs to accomplish complicated or specialized tasks.
+
+
+        For  example,  in  the  MH  distribution  there  is  a  shell  script  called  mpick
+
+(shown in Figure 7) which tries to locate all the messages which pertain to a given
+
+discussion, by looking at the ``Message-ID:''           and ``In-reply-to:''           headers,
+
+to find matching message-ids.8
+
+
+        Unfortunately, some parts of MH are somewhat monolithic.  An example of
+
+this is the What  now?  prompt.  There are only a few options at this prompt, and
+
+one cannot give a normal shell command.  Some MH users seem to feel that more
+
+options should be added to the What  now?  prompt, such as an insert-file option.  It
+
+was argued that just about any editor would allow you to insert a file, and another
+
+What  now?  option was not needed.  These users persisted, however, so the problem
+
+was solved, by writing a trivial shell script "editor" (see Figure 8) which could be
+
+invoked by the edit option:
+
+
+           What  now? edit append filename
+
+
+
+        A better interface at this point is really needed, however.  One possibility is to
+
+simply pass any unrecognized commands on to a shell for interpretation, supplying
+
+the  path  name  of  the  draft  file  as  an  argument.  A  solution  which  shows  more
+
+promise is to give you a sub-shell instead of the What  now?  prompt,  and setup
+
+certain envariables so that the MH commands would act upon the draft   by default.
+
+For example, show with no `msgs'     arguments would show the draft instead of the
+
+current message.  This alternative has recently been implemented and is under
+
+testing.
+
+
+
+The MH Distribution
+
+        The  mh.5  distribution  is  now  briefly  described,  both  in  terms  of  static
+
+configuration methods and dynamic tailoring.  Appendix B describes the mechanics
+
+of receiving an mh.5 distribution.
+
+
+
+_____________________________________
+8  Note that the shell scripts included in the MH distribution are written for the Bourne shell, and
+
+have a `:' as the first character of the first line, so they will be portable to all versions of UNIX, not
+just those which support the Berkeley `# !' enhancement.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             18
+_______________________________________________________________________________________________________________
+
+:  'mpick  -  relate  messages  /mtr'
+PATH=:/bin:/usr/bin:/usr/ucb:/usr/local:/usr/local/lib/mh;  export  PATH
+F=""  M=""  S=""
+
+
+for  A  in  $*
+do
+      case  $A  in
+           -*)       S="$S  $A"  ;;
+
+
+           +*_@*)   case  $F  in
+                           "")   F=$A  ;;
+                           *)    echo  "mpick:  only  one  folder  at  a  time"  1>&2
+                                  exit  1  ;;
+                      esac  ;;
+
+
+           *)        M="$M  $A"  ;;
+      esac
+done
+
+
+S="$S  -sequence  hits  -list  -nozero"
+
+
+if  mark  $F  all  -add  -sequence  hits;
+      then  mark  $F  all  -delete  -sequence  hits;
+      else  exit  1;
+fi
+
+
+for  A  in  $-M-cur"
+do
+      for  C  in  `mhpath  $F  $A`
+      do
+           if  [  -r  $C  ];
+                then
+                      I=`mhl  -form  mhl.msgid  $C`;
+                      case  $I  in
+                           "")   echo  "no  message-id  in  message  `basename  $C`"  1>&2  ;;
+                           *)    pick  --in-reply-to  "$I"  $S  ;;
+                      esac
+                else
+                      echo  "message  $A  doesn't  exist"  1>&2;  exit  1;
+           fi
+      done
+done
+
+
+exit  0
+
+
+                                                 Figure 7
+
+____________________________________________The_mpick_Script___________________________________________________
+
+
+
+Configurable MH
+
+        The  MH  distribution  currently  runs  on  a  large  number  of  different  UNIX
+
+versions, ranging from MicroSoft XENIX to Berkeley 4.2bsd.  All the code which
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             19
+_______________________________________________________________________________________________________________
+
+:  'append  -  stupid  append  editor  for  MH  -  /jlr'
+case  $#  in
+    1_2)  case  $#  in
+                1)  F=$1;  echo  -n  "Append  file:  "  1>&2;  read  A  ;;
+                2)  F=$2;  A=$1  ;;
+           esac
+           cat  $A  <  /dev/null  >>  $F  ;;
+       *)  echo  "append:  arg  count"  1>&2  ;  exit  1  ;;
+esac
+exit
+
+
+                                                 Figure 8
+
+___________________________________________The_append_Editor___________________________________________________
+
+_______________________________________________________________________________________________________________
+
+bin       /usr/local
+bboards  on
+editor   /usr/local/prompter
+etc       /usr/local/lib/mh
+mail      /usr/spool/mail
+manuals  local
+mts       sendmail/smtp
+news      off
+options  BSD42
+options  MHE  NETWORK
+options  UCI
+
+
+                                                 Figure 9
+
+___________________________________Sample_MH_Configuration_File________________________________________________
+
+
+
+is specific to a particular target environment is enabled via the C-preprocessor
+
+``# ifdef''       mechanism, so compilation under different versions of UNIX is trivial.
+
+There are, however, a large number of compile-time options which may vary from
+
+site to site, so an automated configuration method was needed.
+
+
+        The MH-installer must create a configuration file,  which contains a list of
+
+the compile-time options and the values which are desired for them.  Compile-time
+
+options include the installation location for MH, what kind of message transport
+
+system is to be used, and the default editor for the installation.  An example of
+
+such a configuration file is shown in Figure 9.
+
+
+        After creating this file (several examples are included in the distribution), the
+
+installer runs the mhconfig program, which customizes the Makefile    s and some of
+
+the programs, for that site's particular installation.  No hand-editing of any source
+
+code should be necessary, under normal circumstances.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             20
+_______________________________________________________________________________________________________________
+
+mmdfldir:          /usr/spool/mail
+mmdflfil:
+mmdelim1:          "001"001"001"001"n
+mmdelim2:          "001"001"001"001"n
+mmailid:           0
+lockstyle:        0
+lockldir:
+
+
+hostable:          /usr/local/lib/mh/hosts
+servers:           localhost  "01localnet
+
+
+                                                Figure 10
+
+_______________________________________Sample_MTS_Tailor_File__________________________________________________
+
+
+
+Interface to the Message Transport System
+
+        MH will run with a number of message transport systems, including SendMail,
+
+MMDF-II, and a small stand-alone system.  One flexible method of posting mail
+
+is through an SMTP connection.  There are a couple of major wins in using this
+
+configuration:  First, none of the MH programs need to know where the interface
+
+programs to the message transport system are located, which makes them easier
+
+to move between systems.  Second, mail can be posted on relay hosts, and the local
+
+host of an MH user may not need a message transport system at all (as alluded to
+
+in the preceeding discussion on the POP).
+
+
+        Those parts of MH which interact with the local message transport agent
+
+read additional tailoring information when they start.9  This information includes
+
+the location of standard and alternate maildrops, maildrop delimiter strings, the
+
+locking  directory  and  locking  style,  and  other  tailoring  information  specific  for
+
+the particular message transport system in use (e.g., the default server search-list
+
+when mail is posted with the SMTP). In most cases, by using a tailor file, each site
+
+running a similar MH configuration is able to simply transfer MH binaries between
+
+hosts.  An example of such a tailor file is shown in Figure 10.
+
+
+        A  continuing  question  which  is  often  raised  is  how  intelligent  should  user
+
+agents (like MH and UCB Mail ) be with respect to the environment in which they
+
+operate.  At present, MH likes to determine the official hostnames for addresses
+
+when posting mail.  Many argue that this is improper or unnecessary behavior
+
+for  a  user  agent,  and  that  the  local  message  transport  agent  should  handle
+
+these  functions.   Unfortunately,  this  implies  that  the  message  transport  agent
+
+should munge headers when mail is posted to remove local host aliases and only
+
+permit address fields with fully-qualified addresses.  Sadly, neither SendMail nor
+
+MMDF-II  really  gets  this  right  (flames  to  /dev/null     please).   The  current  MH
+
+maintainers believe that the resolution of host aliases to official names should be
+
+a well-supported interface with the local message transport agent.  However,  to
+
+_____________________________________
+9  This simple facility is based on a more extensive tailoring capability found in MMDF-II.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             21
+
+
+provide equal time to those who hold opposite views, MH supports a configuration
+
+option called ``DUMB''       which disables MH's attempts to resolve addresses into
+
+fully-qualified strings.
+
+
+
+Concluding Remarks
+
+        While MH has undergone significant development since the original Rand
+
+release, the authors have tried to keep the fundamental concepts of MH unchanged.
+
+The authors have continually had to battle against well-meaning MH users who
+
+wanted to make MH more like other (less powerful) user agents.  More and more
+
+"features"  were  often  suggested  for  MH,  usually  at  the  expense  of  making  MH
+
+less  general,  and  more  specific.  In  nearly  all  cases,  the  "features"  which  these
+
+users wanted were already present in MH in a slightly different form, or could be
+
+realized by simply writing a short shell script.  A classic example is the repeated
+
+requests  by  one  user  to  have  dist  take  a  list  of  messages  rather  than  a  single
+
+message and distribute each one of them in turn.  A simple shell script which called
+
+dist repeatedly, perhaps with "canned" arguments so the user typed in addressing
+
+information only once, would easily meet this request.
+
+
+        A number of MH comands have a large number of options.  When adding
+
+options, the authors have tried to make the options general, while still accomodating
+
+the  requests  of  specific  users.   An  example  of  a  specific  request  which  was
+
+implemented  as  a  general  feature  is  the  ``Previous-Sequence''              profile  entry
+
+(mentioned above).  If you use this profile entry, every MH command is forced to
+
+write out context    changes, making every command somewhat slower.  Since only a
+
+few users wanted this capability, it was implemented in such a way that users who
+
+didn't want it, didn't have to pay the cost of slowing down every MH command.
+
+
+        MH has a powerful tailoring capability provided by the .mh_profile    .  Using
+
+profile entries, users may customize their own environment without affecting others.
+
+Novice users often take advantage of the MH-tailoring capabilities to try to make
+
+MH work similarly to other user agents they've used.  This has the advantage of
+
+allowing them to quickly begin using MH to handle their mail.  However, since these
+
+novice users don't take advantange of all the capabilities of MH, they frequently
+
+will complain about things they think can't be done with MH, or could be done
+
+"better" some other way.  Fortunately,  as these users become more experienced
+
+with  both  MH  and  UNIX,  they  can  modify  their  environment  to  take  better
+
+advantage of all of MH's capabilities.  Novice MH users who see features lacking
+
+are encouraged to take a better look at what MH can do, instead of trying to make
+
+MH into something it isn't.  This may sound rather inflammatory, but it would
+
+really be a much nicer world for us all if users of software systems would read the
+
+manual prior to asking questions.
+
+
+        For  a  moment,  let's  consider  the  evolution  of  one  MH  feature  which  has
+
+proved  itself  to  be  very  useful.  As  users  began  employing  MH  to  handle  their
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             22
+
+
+mail, the number of messages that could be processed in a given amount of time
+
+increased greatly.  As the volume of messages increased however, it became clear
+
+that  some  MH  operations  were  too  slow,  in  particular  the  interaction  with  the
+
+(slow) message transport system.  To overcome this problem, the push option was
+
+added at the What  now?  prompt.  Originally, this option was hidden from novice
+
+users and did little more than send the message in the background:  any output
+
+generated by the background send process would be printed asyncronously on the
+
+terminal.  If a message failed posting with the message transport system, it would
+
+simply be left in the draft   file.
+
+
+        Gradually, other features were added to push.  Since users wanted to be able
+
+to send more than one draft at a time,  push was changed to optionally rename
+
+the draft file before posting it.  (This is what the hidden `-unique'       option does.)
+
+Having message transport system diagnostics written asyncronously on the user's
+
+terminal was annoying, so push was made to intercept these diagnostics, and mail
+
+the user a report containing them.  Although the diagnostic report mailed back by
+
+push contains the name of the draft which failed, a useful added feature was the
+
+ability to have push include the failed draft as well.  Eventually, the draft-folder
+
+mechanism  was  implemented  to  make  handling  multiple  message  drafts  much
+
+easier.
+
+
+TODO
+
+        There are, no doubt, a number of improvements which could be made to MH.
+
+At the present time, what further development should MH suffer?  Although not
+
+by any means inclusive, here's a list:
+
+
+           1.  Performance Enhancements
+
+               Hardware  gets  faster  all  the  time,  but  people  always  complain  that
+
+               software is too slow.  Owing to its user interface style, MH is somewhat
+
+               slower than monolithic programs like UCB Mail.  It would be nice if MH
+
+               could be tuned or accelerated somehow.
+
+
+           2.  Port to System 5
+
+               MH  runs  on  4.2bsd  UNIX  and  Version  7  variants.  It  should  not  be
+
+               difficult to port MH to a SYS5 environment.  This should significantly
+
+               increase the number of hosts on which MH can run.  The authors, lacking
+
+               a SYS5 machine (and experience with SYS5) to perform the port, are
+
+               actively seeking a System 5 guru to attempt this feat.
+
+
+           3.  Interface to the Network News
+
+               Not all sites that run MH are in the ARPA Internet, and as such the
+
+               UCI BBoards facility may not be of much use to them.  A good MH
+
+               interface to the network news would allow users on hosts with a news
+
+               feed to employ the same interface for reading and sending both mail
+
+               and news.
+Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             23
+
+
+         4.  Programmed Instruction for Beginners
+
+             The complexity of MH is often intimidating to new users.  It would be
+
+             nice to develop a set of learn lessons for those users who don't like man
+
+             pages and non-interactive tutorials.
+
+
+         5.  Message List Expansion
+
+             At  present,  when  a  list  of  messages  is  given  to  an  MH  command,  it
+
+             expands the list and processes each message in numerical order rather
+
+             than the order in which the messages were given (e.g., ``show 2 1''
+
+             show s message 1 and then message 2).  It would be nice if MH processed
+
+             messages in the order they were given.
+
+
+         6.  Context Changes
+
+             In nearly all cases, an MH command does not write out context changes
+
+             until it is about to exit successfully.  There is some controversy as to
+
+             whether this is the correct behavior in all cases.  Some argue that once
+
+             an MH command has fully parsed its argument list, the context should
+
+             be updated.
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             24
+
+
+                                               References
+
+
+
+[DCome83]        D.  Comer.   The  Computer  Science  Research  Network  CSnet:  A
+
+                 History  and  Status  Report.  Communications  of  the  ACM  26,  10
+
+                 (October, 1983), 747-753.
+
+
+
+[DCroc79]        D.H.  Crocker,  E.S.  Szurkowski,  D.J.  Farber.   An  Internetwork
+
+                 Memo  Distribution  Facility  _  MMDF.  Appearing  in  Proceedings,
+
+                 Sixth Data Communications Symposium, Asilomar, 1979, pp. 18-25.
+
+
+
+[DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
+
+                 Messages.  Request  for  Comments  822.  ARPA  Internet  Network
+
+                 Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DKing84]        D.P.  Kingston,  III.   MMDFII:  A  Technical  Review.  Appearing  in
+
+                 Proceedings  Usenix  Summer  '84  Conference,  Salt  Lake  City,  Utah,
+
+                 1984, pp. 32-41.
+
+
+
+[EAllm83]        E.  Allman.    SENDMAIL  _  An  Internetwork  Mail  Router.
+
+                 Britton-Lee, Inc., Berkeley, California (July, 1983).
+
+
+
+[IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
+
+                 Appearing in Internet Protocol Transition Workbook, ARPA Internet
+
+                 Network Information Center (NIC), SRI International, 1981.
+
+
+
+[JReyn84]        J.K.  Reynolds.   Post  Office  Protocol.  Request  for  Comments  918.
+
+                 ARPA Internet Network Information Center (NIC), SRI International
+
+                 (October, 1984).
+
+
+
+[MButl85]        M. Butler,  J.B. Postel,  et. al.   Post Office Protocol - Version 2.
+
+                 Request  for  Comments  937.  ARPA  Internet  Network  Information
+
+                 Center (NIC), SRI International (February, 1985).
+
+
+
+[MRose84a]       M.T.  Rose.   The  Rand  MH  Message  Handling  System:  The  UCI
+
+                 BBoards Facility. Department of Computer and Information Sciences,
+
+                 University of Delaware (October, 1984).
+
+
+
+[MRose85b]       M.T.  Rose,  E.A.  Stefferud.   Proposed  Standard  for  Message
+
+                 Encapsulation. Request for Comments 934. ARPA Internet Network
+
+                 Information Center (NIC), SRI International (January, 1985).
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             25
+
+
+[SMTP]           Simple  Mail  Transfer  Protocol.  Request  for  Comments  821.  ARPA
+
+                 Internet  Network  Information  Center  (NIC),  SRI  International
+
+                 (August, 1982).
+
+
+
+[TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
+
+                 1778). Appearing in Internet Protocol Transition Workbook, ARPA
+
+                 Internet Network Information Center (NIC), SRI International, 1981.
+
+
+                                                     Appendix  A
+
+                                                  MH  Commands
+
+
+
+               MH is composed of several UNIX programs, which in theory are fairly simple
+
+       and single-purposed.  These commands are functionally grouped below:
+
+
+                                                    Composing_Mail_________
+
+     comp:     compose a message
+
+               A program to originate a message.  Usually, a special prompting editor front-
+
+               end, prompter, is used to fill-in a composition template with the addressees
+
+               of the message, subject, and so forth.
+
+
+       dist :  redistribute a message to additional addresses
+
+               A program that re-enters a message previously received by the user into the
+
+               message transport system.  Only new addresses are added; the body of the
+
+               message is not changed in any way.
+
+
+      forw :   forward messages
+
+               A program that encapsulates one or more messages in a new message draft.
+
+               In addition, the user may add initial and/or closing comments.
+
+
+       repl :  reply to a message
+
+               A program that constructs a reply to a message using a reply template.  The
+
+               template mechanism has sufficient generality to permit the user to "program"
+
+               the  form  of  the  reply  draft  based  on  the  contents  of  the  message  being
+
+               replied-to.
+
+
+      send :   send a message
+
+               A  program  that  posts  a  draft  with  the  message  transport  system.   The
+
+               send program is usually invoked by one of the four preceding programs, and
+
+               performs simple front-end pre-processing prior to invoking the post program.
+
+               For  example,  if  invoked  in  push'd  mode,  send  will  immediately  relinquish
+
+               control of the user's terminal and post the message in the background.  If
+
+               the posting fails, send will send back a failure notice to the user.  If the user
+
+               had push'd the sending of the draft, then by default the draft being sent is
+
+               encapsulated in the failure notice.  This permits easy burst'ing of the failure
+
+               notice to retrieve the original draft.  Otherwise, if the posting was successful,
+
+               the draft is marked as having been sent.
+
+
+whatnow :      prompting front-end for send
+
+               A program which is called by comp, et.  al., after the initial draft has been
+
+
+
+                                                             26
+           Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             27
+
+
+                 generated.  The  MH  user  can  specify  a  different  whatnow  program,  which
+
+                 yields considerable extensibility.
+
+
+      whom:      report to whom a message would go
+
+                 A program which examines the addresses of the draft and expands all user-
+
+                 defined aliases contained therein.  Optionally,  whom may actually interact
+
+                 with  the  message  transport  system  to  determine  the  validity  of  the  final
+
+                 addresses.  This program is also usually invoked by comp, et. al.
+
+
+                                                        Posting_Mail______
+
+           ali : list mail aliases
+
+                 A simple front-end to the MH aliasing mechanism.
+
+
+           ap:   parse addresses 822-style
+
+                 A  useful  debugging  tool  for  PostMasters  who  wish  to  examine  how  MH
+
+                 interprets an Internet address.
+
+
+    conflict :   search for alias/password conflicts
+
+                 Another program used by system administrators to check the consistency of
+
+                 MH alias files, and portions of the local message transport agent.
+
+
+install-mh:      initialize the MH environment
+
+                 A program which is automatically executed the first time a user issues an MH
+
+                 command.  This program performs once-only initialization of the user's MH
+
+                 environment.
+
+
+    mhmail :     send or read mail
+
+                 A simple program generally used by other programs to generate messages.
+
+                 The mhmail command is similar in purpose to the old BellMail program.
+
+
+         post :  deliver a message
+
+                 A  complex  MH  back-end  that  interacts  with  the  local  message  transport
+
+                 agent to enter messages through the posting slot.  (See the description of send
+
+                 above).
+
+
+                                                        Reading_Mail_______
+
+          inc:   incorporate new mail
+
+                 A program that interacts with the local message transport agent to retrieve
+
+                 messages from the user's maildrop.
+
+
+    msgchk :     check for waiting mail
+
+                 A program which reports the status of mail waiting in the user's maildrop.
+
+
+        show :   show (list) messages
+
+                 A program which lists messages to its standard output (usually the user's
+
+                 terminal), possibly invoking another program to do the actual listing.  Most
+
+                 users of MH have show automatically call the mhl program to format the
+      Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             28
+
+
+            message.   The  next  and  prev  programs  are  simply  ``show next''         and
+
+            ``show prev''        , respectively.
+
+
+    mhl :   produce formatted listings of MH messages
+
+            A program which displays a message as directed by a template.  This permits
+
+            the user to filter out uninteresting headers and re-arrange other headers to a
+
+            particular preference.  In addition to being invoked by show, the mhl program
+
+            is optionally also invoked by forw to format each message being forwarded;
+
+            invoked  by  repl  to  format  the  body  of  a  message  being  replied-to,  if  that
+
+            message is being included in the reply draft; and, invoked by post to format
+
+            a message being sent as a blind-carbon-copy.
+
+
+   rmm:     remove messages
+
+            A program that removes messages from an MH folder, optionally running a
+
+            user-defined program instead of deleting them.  If no program is given, the
+
+            messages are "softly" removed, so they may possibly be recovered later.
+
+
+   scan:    produce a one-line-per-message scan listing
+
+            A program that generates a scan listing for messages.  Each line of the listing
+
+            contains date, source, subject, and possibly the initial body of the message.
+
+
+                                                 Folder_Handling_______
+
+ folder :   set/list current folder/message
+
+            A program used to list information concerning the current folder, or set the
+
+            current folder and/or message.
+
+
+folders :   list all folders
+
+            A program to list information on all folders (actually, just a special case of
+
+            the folder command).  Since the MH folder structure may be recursive, the
+
+            user can indicate that folders should recursively examine all folders.
+
+
+   refile:  file message(s) in (an)other folder(s)
+
+            A program to move (or copy) messages from a source folder to one or more
+
+            destination folders.
+
+
+    rmf :   remove folder
+
+            A program that deletes a folder and all messages therein.
+
+
+                                                Message_Selection_______
+
+   anno:    annotate messages
+
+            A  program  to  arbitrarily  annotate  messages.  If  the  user  so  desires,  after
+
+            distributing,  forwarding,  or  replying-to  a  message,  MH  will  automatically
+
+            attach an annotation to the original message indicating the date and addresses.
+
+
+  mark :    mark messages
+
+            A program to manipulate user-defined sequences (lists of messages).  Usually,
+
+            mark is not employed directly by the MH user.
+       Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             29
+
+
+     pick :  select messages by content
+
+             A  program  to  examine  a  list  of  messages  and  choose  those  which  meet
+
+             a  particular  selection  criterion.  The  pick  program  is  often  used  in  UNIX
+
+             back-quoted operations to pass message sequences to other MH commands.
+
+
+  sortm:     sort messages
+
+             A program to sort a list of messages according to the date given in a particular
+
+             field.
+
+
+                                           Distribution_List_Handling__________
+
+      bbc:   check on BBoards
+
+             A  front-end  to  run  msh  on  a  list  of  distribution  lists  which  the  user  isn't
+
+             current on.
+
+
+      bbl :  manage a BBoard
+
+             A  (depreciated)  program  used  to  manually  manage  the  local  archives  of
+
+             a  distribution  list.  These  functions  (archiving,  expunging)  are  performed
+
+             automatically by MH.
+
+
+   burst :   explode digests into messages
+
+             A program used to decapsulate messages from ARPA Internet digests.  In
+
+             addition,  messages  which  have  been  encapsulated  during  forwarding  (i.e.,
+
+             with forw ) can also be decapsulated using burst.10
+
+
+     msh:    MH shell (and BBoard reader)
+
+             A  monolithic  program  used  to  implement  MH  commands  on  messages
+
+             arranged in a single file (maildrop format).  Useful since distribution lists are
+
+             kept in this format to minimize consumption of system resources.
+
+
+    pack :   compress a folder into a single file
+
+             A program which takes messages stored in MH format and places them in a
+
+             single file (using the same format known by msh).
+
+
+                                      Interface_to_the_UNIX_File_System_____________
+
+mhpath:      print full pathnames of MH messages and folders
+
+             A program which maps MH-style names into the UNIX file naming convention.
+
+
+
+     _____________________________________
+    10  Similarly, blind-carbon-copies may be decapsulated, though only socially mature users should do
+
+     so.
+
+
+                                              Appendix  B
+
+                                     Distribution  Mechanics
+
+
+
+        The mh.5 distribution is available in two forms:
+
+
+           1.  Anonymous FTP
+
+               If  you  can  FTP  to  the  ARPA  Internet,  use  anonymous  FTP  to  the
+
+               ARPAnet host UDel-Huey [10.2.0.96] and retrieve the file portal/mh.5-
+
+               tar.  This is a tar image of size 2.1 MB (approximately).
+
+
+           2.  9-track tape, 1600 bpi, tar format
+
+               Otherwise, you can send $ 50.00 to the address below.  This covers the
+
+               cost of a magtape,  handling,  and shipping.  In addition,  you'll get a
+
+               laser-printed hard-copy of the MH documentation.  The documentation
+
+               includes installation guide, MH Tutorial, MH User's Manual, changes
+
+               document (from mh.4 to mh.5), and BBoards Manual.
+
+
+               If you go with this option, be sure to include your USPS address with
+
+               your check.  Checks should be made payable to
+
+
+                                 Regents of the University of California
+
+
+               It's also a good idea (though not mandatory) to send a computer mail
+
+               message to Bug-MH@UCI when you send your check via USPS to ensure
+
+               minimal turn-around time.  The distribution address is:
+
+
+                   Support Group
+
+                   Attn:  MH Distribution
+
+                   Department of Information and Computer Science
+
+                   University of California, Irvine
+
+                   Irvine, CA 92717
+
+
+
+                   714/856-6852
+
+
+
+               Sadly, if you just want the hard-copies of the documentation, you still
+
+               have to pay the $ 50.00.  The tar image has the documentation source
+
+               (the man is in ROFF format, but the rest are in TEX format).
+
+
+In addition,  there is some hope that mh.5,  or a successor,  might be found in a
+
+future 4.x Berkeley distribution.
+
+
+
+                                                      30
+  Reprinted from Proceedings, Summer Usenix Conference and Exhibition, Portland, Oregon, June, 1985             31
+
+
+        Although MH is not "supported" per se, it does have a bug reporting address.
+
+Normally, the address Bug-MH@UCI is used to report bugs and bug fixes.  There are
+
+however, two discussion groups which concern themselves with MH:
+
+
+           1.  MH-Users@UCI
+
+               A discussion group for the MH user community at large.  Appropriate
+
+               topics include:  questions about how to use MH, tips on MH usage, and
+
+               exchange of MH shell scripts.  All requests to be added to or deleted
+
+               from this list, along with problems, questions and suggestions, should
+
+               be sent to MH-Users-Request@UCI.
+
+
+           2.  MH-Workers@UCI
+
+               A discussion group for MH maintainers and experts.  Appropriate topics
+
+               include:  questions on how to configure MH, tips on MH configuration,
+
+               exchange of MH bug reports (and fixes).  All requests to be added to or
+
+               deleted from this list, along with problems, questions and suggestions,
+
+               should be sent to MH-Workers-Request@UCI.
+
+
+The ``UCI''      host is also known as ``ucivax''      , so a possible UUCP path might
+
+be : : :!ucbvax!ucivax!bug-mh.
+
+
+        Updates to MH are published on the MH-Workers list in the form of context
+
+diffs, and the appropriate distribution images are updated as well.
+
+
+
+
+                                                Contents
+
+
+
+                                                                                                         Page
+
+Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+The MH Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
+
+        The MH Environs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       3
+
+        An MH Transcript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
+
+Some MH Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
+
+        Message Sequences and Selection  . . . . . . . . . . . . . . . . . . . . . . .       5
+
+        Draft Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       7
+
+        BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       8
+
+        Bursting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+        Distributed Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      11
+
+User Interface Issues in MH  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
+
+        Creeping Featurism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
+
+        Templates versus Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . .      13
+
+        Modularity versus Monolithicity . . . . . . . . . . . . . . . . . . . . . . . .      17
+
+The MH Distribution  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      17
+
+        Configurable MH  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      18
+
+        Interface to the Message Transport System  . . . . . . . . . . . . . . . . .      20
+
+Concluding Remarks  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      21
+
+        TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      22
+
+References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      24
+
+Appendix A: MH Commands  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      26
+
+Appendix B: Distribution Mechanics. . . . . . . . . . . . . . . . . . . . . . . . .      30
+
+
+
+_____________________________________
+This document (version #1.43) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+                                                       i
diff --git a/docs/historical/trusted.pdf b/docs/historical/trusted.pdf
new file mode 100644
index 0000000..3398763
Binary files /dev/null and b/docs/historical/trusted.pdf differ
diff --git a/docs/historical/trusted.txt b/docs/historical/trusted.txt
new file mode 100644
index 0000000..aea5b71
--- /dev/null
+++ b/docs/historical/trusted.txt
@@ -0,0 +1,2283 @@
+
+
+
+
+                                 Design  of  the  TTI  Prototype
+
+                                         Trusted  Mail  Agent
+
+
+                                             Marshall T. Rosey
+
+                                               David J. Farber
+
+                                            Stephen T. Walker
+
+
+
+                                                  Abstract
+
+
+               The design of the TTI  prototype Trusted Mail Agent (TMA)
+
+               is discussed.  This agent interfaces between two entities:  a key
+
+               distribution  center  (KDC)  and  a  user  agent  (UA).  The  KDC
+
+               manages keys for the encryption of text messages, which two
+
+               subscribers to a key distribution service (KDS) may exchange.
+
+               The TMA is independent of any underlying message transport
+
+               system.
+
+
+               Subscribers  to  the  KDC  are  known  by  unique  identifiers,
+
+               known as IDs.  In addition to distributing keys, the KDC also
+
+               offers  a  simple  directory  lookup  service,  in  which  the  "real-
+
+               world" name of a subscriber may be mapped to an ID, or the
+
+               inverse mapping may be performed.
+
+
+               This  document  details  three  software  components:   first_,  a
+
+               prototype  key  distribution  service,  which  has  been  running
+
+               in  a  TCP/IP  environment  since  December,  1984;  second____,  a
+
+               prototype trusted mail agent; and, third___, modifications to an
+
+               existing UA, the Rand MH Message Handling system, which
+
+               permit interaction with the prototype TMA.
+
+
+
+________________________________________
+y All three authors are with Trusted Technologies, Incorporated, POB 45, Glenwood, MD 21738,
+
+USA. Telephone: 301/854-6889. In addition, Professor Farber is with the University of Delaware.
+
+
+                                 Design  of  the  TTI  Prototype
+
+                                         Trusted  Mail  Agent
+
+
+
+Introduction
+
+       Initially, a brief model of a user community employing a trusted mail service
+
+is introduced.  Following this introduction, a prototype system is described which
+
+attempts to meet the needs of a user community.  Finally, open issues are discussed,
+
+which are currently not satisfied by the prototype system or its model of operation.
+
+
+       Two  or  more  entities,  called  users,  wish  to  communicate  in  a  secure
+
+environment.  Depending  on  their  available  resources,  different  levels  of  security
+
+are possible.  At the extreme, two parties with substantial resources may wish to
+
+communicate in a fashion which prevents any third parties, known as adversaries,
+
+from  observing  their  communication.   At  this  level,  not  only  is  an  adversary
+
+unable  to  capture  the  communication  for  analysis,  but  in  fact,  the  adversary  is
+
+unaware  that  any  communication  is  occurring  at  all.  In  most  applications,  this
+
+level of security is prohibitively expensive.  A more economic method is to translate
+
+messages into a form which is useless to an adversary and then to communicate
+
+those messages on an insecure medium.
+
+
+       This latter method requires the two users to have some sort of key with which
+
+to "lock" the plaintext into ciphertext when transmitting,  and then to "unlock"
+
+the ciphertext back into useful form when receiving.  Hence, there are two central
+
+issues to deal with:  first_, keys must be generated, distributed, and maintained in
+
+a secure fashion;  and, second____, the keys must be "intricate" enough so that sense
+
+can't be made out of the ciphertext without knowledge of the key.  The first part
+
+is  handled  by  a  key  distribution  center  (KDC),  which  maintains  a  list  of  users
+
+and a set of keys for each pair of users.  The second part relies on sophisticated
+
+encryption  and  decryption  algorithms.  It  is  beyond  the  scope  of  this  paper  to
+
+describe cryptographic techniques in detail.  For a detailed survey of this area, the
+
+reader should consult [VVoyd83].
+
+
+       In  the  context  of  our  discussion  (using  the  terminology  of  [X.400]),  the
+
+medium used to transport is supplied by a message transport system (MTS), which
+
+is composed of one or more message transport agents (MTAs).  Usually, the entire
+
+MTS  is  distributed  in  nature,  and  not  under  a  single  administrative  entity;  in
+
+contrast, an MTA is usually controlled by a single administration and resides in a
+
+particular domain.  At every end-point in the medium, a user agent (UA) acts on
+
+behalf of a user and interfaces to a local MTA. This model is briefly summarized in
+
+Figure 1.
+
+
+
+ Copyright fcl1985, IFIP TC-6                                                                                       1
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                2
+______________________________________________________________________________________________________________________
+
+
+
+                UA                                                                                UA
+
+
+
+   POSTING                                                                                            RECEIPT
+
+
+
+                                                        MTS
+
+
+
+               MTA                  MTA                  : : :                : : :              MTA
+
+                                                              RELAYING
+
+
+
+                                                    Figure 1
+
+_______________________________________________The_MTS_Model__________________________________________________________
+
+
+
+       A message, in our context, consists of two parts:  the headers and the body.
+
+The  headers  are  rigorously  structured;  they  contain  addressing  information  and
+
+other  forms  useful  to  a  UA.  The  body  is  freely  formatted  and  is  usually  not
+
+meaningful to a UA.
+
+
+       When  a  message  is  sent  from  one  user  to  another,  the  following  activities
+
+occur:  The originating user indicates to the UA the address of the recipient;  the
+
+UA  then  posts  the  message  through  a  posting  slot  to  an  MTA,  which  involves
+
+a  posting  protocol  in  which  the  validity  of  the  address  and  the  syntax  of  the
+
+message  are  considered.  Upon  successful  completion  of  the  protocol,  the  MTA
+
+accepts responsibility for delivering the message, or if delivery fails, to inform the
+
+originating user of the failure.  The MTA then decides if it can deliver the message
+
+directly  to  the  recipient;  if  so,  it  delivers  the  message  through  a  delivery  slot  to
+
+the recipient's UA, using a delivery protocol.  If not, it contacts an adjacent MTA,
+
+closer to the recipient, and negotiates its transfer (using a protocol similar to the
+
+posting protocol).  This process repeats until an MTA is able to deliver the message,
+
+or an MTA determines that the message can't be delivered.  In this latter case, a
+
+failure notice is sent to the originating user.
+
+
+       It is important to note that there are two mappings which occur here.  The
+
+first, which is performed implicitly by the originating user, maps the name of the
+
+recipient into the recipient's address; the second, which is performed explicitly by
+
+the MTS, maps the address of the recipient into a route to get from the originator's
+
+MTA to the recipient's MTA. These mappings are depicted in Figure 2.
+
+
+       Obviously, there is no guarantee that the MTS can be made secure, in any
+
+sense of the word.  This is particularly true if it is under several administrations.
+
+Regardless  of  the  number  of  administrations  in  the  MTS,  this  problem  quickly
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                3
+______________________________________________________________________________________________________________________
+
+
+
+         user                                                                                           user
+
+
+
+            name   ! address
+
+
+
+          UA                                                                                            UA
+
+
+
+                                                        MTS
+            address   ! route
+
+
+
+         MTA                    MTA                      : : :                   : : :                 MTA
+
+
+
+                                                    Figure 2
+
+______________________________________Mappings_in_the_MTS_model_______________________________________________________
+
+
+
+degenerates to a problem of Byzantine generals[LLamp82].  Further, trying to secure
+
+each MTA in the path that a message travels is equally questionable.
+
+
+       To  support  secure  communications  in  this  environment,  a  new  entity,  the
+
+trusted mail agent (TMA) is introduced into our model.  A solution is to have the
+
+UA interact with this entity both when posting a message and when taking delivery
+
+of a message.  The UA first contacts a TMA to encrypt the body of the message for
+
+the recipient, prior to pushing it through the posting slot.  Upon receipt from the
+
+destination MTA, the UA examines the message and contacts the TMA to decipher
+
+the body of the message from the source.  An overview of the relationship between
+
+the standard MTS model and the augmentations made for the Trusted Mail1  system
+
+is shown in Figure 3.
+
+
+       To  achieve  these  tasks,  the  TMA  interacts  with  a  key  distribution  service
+
+(KDS), which manages keys between pairwise users.  At this point, a third mapping
+
+takes place:  the UA must be able to map addresses into the identifier(s) by which
+
+the  originator  and  recipient  are  known  by  the  TMA  and  KDS.  These  identifiers
+
+are  known  as  KDS  IDs,  or  simply  IDs.  Usually,  a  fourth  mapping  also  occurs,
+
+________________________________________
+1  Trusted Mail is a trademark of Trusted Technologies, Incorporated.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                4
+______________________________________________________________________________________________________________________
+
+
+
+          UA                    TMA                     KDS                     TMA                     UA
+
+
+
+                                                        MTS
+
+
+
+         MTA                    MTA                      : : :                   : : :                 MTA
+
+
+
+                                                    Figure 3
+
+____________________________________Modifications_to_the_MTS_model____________________________________________________
+
+
+
+which maps the ID of a user into the name of a user.  In our context, there is an
+
+exact one-to-one mapping between the name of a user and the ID of that user.  In
+
+contrast,  there may be a one-to-many mapping between the name of a user and
+
+that user's address in the MTS. Further, there are usually many different routes
+
+which a message may traverse when going from an originating user to a recipient
+
+user.
+
+
+       The TMA is said to be trusted because it can be relied on to perform only
+
+those  actions  specifically  requested  by  the  user.   In  the  context  of  this  paper,
+
+this  means,  given  proper  construction  and  maintenance  of  the  TMA,  that  the
+
+software will communicate with the KDC in some secure fashion to negotiate key
+
+relationships and that it will not disclose those key relationships to other parties.
+
+Furthermore, the body of mail messages exchanged between users which employ a
+
+trusted mail agent will be unintelligible to other parties.  Finally, a recipient of a
+
+message receives authenticated information from the trusted mail agent as to the
+
+identify of the sender.
+
+
+       Hence, when each user employs a TMA, end-to-end encryption occurs at the
+
+UA level (to avoid any problems with malicious MTAs).2  Any adversary listening
+
+in on the MTS, may observe messages, but make no sense out of them (other than
+
+rudimentary traffic analysis).  Note, however, that since the medium itself is not
+
+secure, an adversary may still introduce new messages, corrupt messages, or remove
+
+
+________________________________________
+2  Note that in the scope of this system, the end-points are the user agents, not the hosts they reside
+
+on. In fact, it may very well be the case that the user agent and the local message transport agent
+do not reside on the same host.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                5
+
+
+messages, as they traverse the MTS. In the first two cases, however, the recipient
+
+would be suspicious because the adversary lacks the encrypting key employed by
+
+the source user.  In the third case, the source user can retransmit the message after
+
+a suitable time.  Of course, there is no built-in retransmission policy _ this aspect
+
+depends on the user's sending mail and is beyond the scope of the system.
+
+
+       It  is  important  to  understand  the  target  community  for  the  Trusted  Mail
+
+system  described  herein.  In  particular,  the  TMA  is  intended  for  a  commercial
+
+and  not  a  military  environment.   This  distinction  is  important,  since  it  is  the
+
+fundamental assumption of this paper that the latter community has much stricter
+
+requirements  than  the  former.  Because  of  this,  the  prototype  system  is  able  to
+
+make certain simplifying assumptions which permit it to operate in a mode which
+
+is less secure than military applications would permit.  Although these issues are
+
+explored in greater detail at the end of the paper, for the moment recall that, like
+
+most qualities, trustedness is not absolute:  there are varying degrees of trustedness,
+
+and as a system becomes more trusted, it becomes more expensive, in some sense,
+
+to operate and maintain.
+
+
+       It is perhaps instructive at this point to consider why the introduction of a key
+
+distribution center is appropriate in this environment,  and why the fundamental
+
+assumption that trusted mail agents do not directly communicate with each other
+
+is  necessary.  Although  a  user  agent  is  able  to  converse  with  the  local  message
+
+transport agent in real-time, it is frequently not able to communicate with other
+
+user agents in real-time.  Furthermore, considering the vast problems and overhead
+
+of trying to establish secure communications from "scratch" (a problem far beyond
+
+the scope of this paper), it is would not be a good idea to try and communicate
+
+key relationships with other user agents, even if it were always possible to do so.
+
+In  addition,  by  separating  the  trusted  aspects  of  the  message  transport  system
+
+from the system itself, many other advantages can be seen.  These are presented in
+
+greater detail at the end of the paper.
+
+
+       The discussion thus far has considered only a single recipient.  In practice, a
+
+user might wish to send to several others, using a different key for each.  Hence each
+
+copy of the message is encrypted differently, depending on the particular recipient
+
+in question.  Note that this has the effect of un-bundling message transfer in the
+
+MTS, as advanced MTAs tend to keep only a single copy of the message for any
+
+number of recipients in order to save both cpu, disk, and I/O resources.
+
+
+       For example, in some existing mail systems, if a message was sent to n users
+
+on a remote system, then the n addresses would be sent from the source MTA to
+
+the remote MTA along with one copy of the message.  Upon delivery, the remote
+
+MTA would deliver a copy to each of the n recipients, but the virtual wire between
+
+the source MTA and the recipient MTA was burdened with only one copy of the
+
+message.  But in a secure environment, since a different key is used by the source
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                6
+
+
+user when communicating with each of the n recipients, n different messages will
+
+be posted with the local MTA, and the advantages of recipient bundling are lost.
+
+
+       Along  these  lines  however,  private  discussion  groups  may  wish  to  avoid
+
+this  problem  by  establishing  access  to  a  single  ID  for  their  use.  In  this  case,  a
+
+subscriber  to  the  KDS  may  actually  have  more  than  one  ID,  one  for  "personal"
+
+use and one for each discussion group.  The appropriate ID is used when posting
+
+messages to the discussion group.  Naturally the administrative policy for deciding
+
+who is allowed to use the KDS ID of a discussion group is left to the moderator
+
+of  the  group.  Observant  readers  will  note  that  this  vastly  decreases  the  aspect
+
+of  secure  communications  for  the  discussion  group.   This  method  is  suggested
+
+as a compromise which permits the bundling of messages for multiple recipients
+
+to  reduce  MTS  traffic.   The  price  is  high  however,  as  a  compromise  on  behalf
+
+of any member of the discussion group compromises the entire group.  For large
+
+discussion groups and a bandwidth limited MTS, this price may be worth paying.
+
+The prototype implementation of the TMA supports multiple recipients but not
+
+multiple KDS IDs.
+
+
+       Having described this environment for communication, the designs of a KDS
+
+and  TMA  which  form  the  heart  of  the  TTI  Trusted  Mail  system  are  discussed.
+
+The  prototype  system  was  developed  on  a  VAX3 -11/780  running  4.2bsd  UNIX4 .
+
+The system is based on the ansi draft[FIKM] for financial key management,  but
+
+diverges somewhat in operation owing to the differences between the electronic mail
+
+(CBMS) and electronic funds (EFT) environments.  Note however that the ansi
+
+data encryption algorithm[DEA, FIPS46] is used in the current implementation.  A
+
+public-key cipher system was not considered as the basis for the prototype since,
+
+to the authors' knowledge, an open standard for a public-key system has yet to be
+
+adopted by the commercial community.  In contrast, the ansi draft for financial key
+
+management appears to be receiving wide support from the commercial community.
+
+
+       In the description that follows, a large number of acronyms are employed to
+
+denote commonly used terms.  In order to aid the reader, these are summarized in
+
+Table 1.
+
+
+
+The Key Distribution Service
+
+       The prototype version of the KDS was designed to provide key distribution
+
+services  for  user  agents  under  both  the  same  or  different  administrations.  As  a
+
+result,  the  means  by  which  a  trusted  mail  agent  connects  to  a  key  distribution
+
+server is quite flexible.  For example,  the prototype system supports connections
+
+via standard terminal lines, dial-ups (e.g., over a toll-free 800 number), UNIX pipes,
+
+and  over  TCP  sockets[IP, TCP].  In  the  interests  of  simplicity,  for  the  remainder
+
+of this paper, a TCP/IP model of communication is used.  Initially, a server on a
+
+________________________________________
+3  VAX is a trademark of Digital Equipment Corporation.
+4  UNIX is a trademark of AT&T Bell Laboratories.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                7
+______________________________________________________________________________________________________________________
+              ______________________________________________________________________________________________
+
+              __Abbrev.________________________________Term_____________________________Context_______________
+
+              _    CBC         _ Cipher Block Chaining                                 _    DES        _
+              _   CBMS         _ Computer Based Message System                         _               _
+              _    CKD         _ Key Distribution Center                               _    EFT        _
+              _    CKS         _ Checksumming                                          _    DES        _
+              _    CSM         _ Cryptographic Service Message                         _               _
+              _    DEA         _ Data Encryption Algorithm                             _               _
+              _    DES         _ Data Encryption Standard                              _               _
+              _    DSM         _ Disconnect Service Message                            _   MCL         _
+              _    ECB         _ Electronic Code Book                                  _    DES        _
+              _    EFT         _ Electronic Funds Transfer                             _               _
+              _     IDK        _ Key Identifier                                        _    CSM        _
+              _      ID        _ Identifier                                            _    KDS        _
+              _      IP        _ Internet Protocol                                     _               _
+              _      IV        _ Initialization Vector                                 _    CSM        _
+              _     KA         _ Authentication Key                                    _    CSM        _
+              _    KDC         _ Key Distribution Center                               _  CBMS         _
+              _    KDS         _ Key Distribution Server                               _  CBMS         _
+              _     KD         _ Data-encrypting Key                                   _    CSM        _
+              _     KK         _ Key-encrypting Key                                    _    CSM        _
+              _    MAC         _ Message Authentication Code                           _    CSM        _
+              _    MCL         _ Message Class                                         _    CSM        _
+              _     MH         _ The Rand Message Handling System                      _               _
+              _    MIC         _ Message Integrity Code                                _    CSM        _
+              _     MK         _ Master Key                                            _    CSM        _
+              _    MTA         _ Message Transport Agent                               _  CBMS         _
+              _    MTS         _ Message Transport System                              _  CBMS         _
+              _    ORG         _ Message Originator                                    _    CSM        _
+              _    RCV         _ Message Receiver                                      _    CSM        _
+              _     RIU        _ Request Identified User                               _   MCL         _
+              _     RSI        _ Request Service Initialization                        _   MCL         _
+              _     RUI        _ Request User Identification                           _   MCL         _
+              _    TCP         _ Transmission Control Protocol                         _               _
+              _    TMA         _ Trusted Mail Agent                                    _  CBMS         _
+              _     TTI        _ Trusted Technologies, Inc.                            _               _
+              ______UA___________User_Agent_______________________________________________CBMS____________
+
+
+                                                     Table 1
+
+____________________________________Abbreviations_used_in_this_paper__________________________________________________
+
+
+
+well-known service host in the ARPA Internet community listens for connections
+
+on a well-known port.5  As each connection is established, it services one or more
+
+transactions over the lifetime of the session.  When all transactions for a session
+
+have been made, the connection is closed.  If the necessary locking operations are
+
+performed by the server to avoid the usual database problems, then more than one
+
+connection may be in progress simultaneously.  Of course, a time-out facility should
+
+________________________________________
+5  The term well known in this context means that the location of the service is known a priori to
+
+the clients.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                8
+
+
+also be employed to prevent a rogue agent from monopolizing the key distribution
+
+server.
+
+
+       Once a session has been started, the client (a.k.a. TMA) initiates transactions
+
+with  the  server  (a.k.a.  KDS).  Each  transaction  consists  of  the  exchange  of  two
+
+or  three  cryptographic  service  messages  (CSMs):   the  client  sends  a  request,
+
+the  server  attempts  to  honor  the  request  and  sends  a  response,  and,  if  the
+
+server  responded  positively,  the  client  then  acknowledges  the  transaction.   By
+
+exchanging these cryptographic service messages, the KDS and the TMA are able
+
+to communicate key relationships.  Obviously,  the relationships themselves must
+
+be transmitted in encrypted form.6  Hence, not only are key relationships between
+
+two TMAs communicated,  but key relationships between the KDS and the TMA
+
+are communicated as well.
+
+
+       This leads us to consider the key relationships that exist between a TMA and
+
+the KDS. A client usually has three keys dedicated for use with the server.  The
+
+first is the master  key (denoted MK), which has an infinite cryptoperiod,  and is
+
+rarely used.  This key is distributed manually.  The second is the key-encrypting key
+
+(denoted KK), which has a shorter cryptoperiod.  Whenever a KK is transmitted
+
+to the TMA, it is encrypted with the master key.  The third is the authentication
+
+key (denoted KA), which is used to authenticate transactions that do not contain
+
+data  keys  (a  count  field  is  also  used  to  avoid  play-back  attacks).   Whenever  a
+
+KA  is  transmitted  to  the  TMA,  it  is  encrypted  with  the  key-encrypting  key.
+
+When transactions contain keys, an associated count field is included to indicate
+
+the  number  of  keys  encrypted  with  the  key-encrypting  key  used.  Although  not
+
+used by the prototype implementation, a production system would employ audit
+
+mechanisms to monitor usage histories.
+
+
+       Currently four types of requests are honored by the KDS: two key relationship
+
+primitives, and two name service primitives.  The type is indicated by the message
+
+class  (MCL)  of  the  first  cryptographic  service  message  sent  in  the  transaction.
+
+As  each  message  class  is  discussed,  the  appropriate  datastructures  used  by  the
+
+KDS  are  introduced.  Space  considerations  prevent  a  detailed  description  of  the
+
+information exchanged in each transaction.  Appendix B of this paper presents a
+
+short example of an interaction between the KDS and a TMA.
+
+
+       The first two requests are used to create (or retrieve) key relationships, and
+
+to destroy key relationships:
+
+
+       The  request  service  initialization  (RSI)  message  class  is  used  to  establish
+
+a  key-encrypting  key  (KK)  relationship  between  the  TMA  and  another  TMA,  or
+
+between the TMA and the KDS. As implied by the name, a key-encrypting key is
+
+
+
+________________________________________
+6  Otherwise an adversary could simply impersonate a TMA and ask for the desired key relationships.
+
+Similarly, this also prevents an adversary from successfully impersonating a key distribution server.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                9
+
+
+used to cipher keys which are used to cipher data exchanged between peers.  These
+
+other keys are called data keys (KDs).
+
+
+       The disconnect  service  message (DSM) message class is used to discontinue
+
+a KK-relationship between the TMA and another TMA, or between the TMA and
+
+the  KDS.  This  prevents  keys  which  are  felt  to  have  been  compromised,  or  are
+
+vulnerable  to  compromise,  from  receiving  further  use  in  the  system.  It  should
+
+be noted that, owing to mail messages (not CSMs) in transit, a discontinued key
+
+relationship may be needed to decipher the key used to encipher a mail message.
+
+The prototype KDS supports this capability.
+
+
+       In  addition  to  maintaining  an  MK/KK/KA  triple  for  each  TMA,  the  KDS
+
+also remembers KK-relationships between TMAs.  The reason for this stems from a
+
+fundamental difference between the electronic funds transfer and computer-based
+
+message system worlds.  The KDS assumes that no two arbitrarily chosen TMAs can
+
+communicate in real-time, and as a result, TMAs do not exchange cryptographic
+
+service messages.  (See Appendix C for a more detailed discussion.)  This means
+
+that  when  a  TMA  establishes  a  KK-relationship  with  another  TMA,  the  former
+
+TMA  may  start  using  the  KK  before  the  latter  TMA  knows  of  the  new  KK-
+
+relationship.  In fact, it is quite possible for a KK-relationship to be established,
+
+used, and then discontinued, all unilaterally on the part of one TMA. It is up to
+
+the  KDS  to  retain  old  cryptographic  material  (possibly  for  an  indefinite  period
+
+of time), and aid the latter TMA in reconstructing KK-relationships as the need
+
+arises.  Naturally, discontinued KKs are not used to encode any new information,
+
+but rather to decode old information.  (Again, refer to Appendix C for additional
+
+details.)
+
+
+       The other two requests are used to query the directory service aspects of the
+
+key distribution server:
+
+
+       The  request  user  identification  (RUI)  message  class  is  used  to  identify  a
+
+subscriber to the KDS. Both the KDS and TMA are independent of any underlying
+
+mail  transport  system  (MTS).  As  a  result,  a  subscriber  to  the  KDS  is  known
+
+by  two  unique  attributes:  a  "real-world"  name,  and  a  KDS  identifier  (ID).  The
+
+user  of  a  mail  system,  or  the  UA,  is  responsible  for  mapping  an  MTS-specific
+
+address (e.g., MRose@UDEL.ARPA) to the person associated with that maildrop (e.g.,
+
+``Marshall T. Rose''              ).  When conversing with the KDS, the TMA uses the KDS
+
+ID  of  another  user  to  reference  that  person's  TMA.  Since  it  is  inconvenient  to
+
+remember  the  IDs  (as  opposed  to  people's  names),  the  KDS  provides  the  RUI
+
+message  class  to  permit  a  TMA  to  query  the  mapping  between  names  and  IDs.
+
+If the KDS cannot return an exact match, it may respond with a list of possible
+
+matches (if the identifying information given was ambiguous), or it may respond
+
+with a response that there is no matching user.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              10
+
+
+       Finally, the request identified user (RIU) message class performs the inverse
+
+operation:  given a KDS ID, a "real-world" name is returned.  This request is useful
+
+for disambiguating unsuccessful RUI requests and in boot-strapping a TMA.
+
+
+       The KDS maintains two directories:  a private directory and a public directory.
+
+The private directory contains all information on all clients to the KDS. The public
+
+directory  is  a  subset  of  this,  and  is  used  by  the  KDS  when  processing  RUI  and
+
+RIU requests.7  As a result, certain clients of the KDS may have unlisted IDs and
+
+names.
+
+
+
+The Trusted Mail Agent
+
+       The prototype version of the TMA was designed to interface directly to the
+
+user  agent  in  order  to  maximize  transparency  to  the  user.  In  present  form,  the
+
+TMA is available as a load-time library under 4.2bsd UNIX, although efforts are
+
+currently underway to transport the TMA to a PC-based environment.
+
+
+       The software modules which compose the TMA contain a rich set of interfaces
+
+to the KDS. In addition, the TMA manages a local database, so responses from the
+
+KDS may be cached and used at a later time.  In all cases, the KDS is consulted
+
+only if the information is not present in the TMA database, or if the information
+
+in question has expired (e.g., KK-relationships).  This caching activity minimizes
+
+connections to the KDS. Although connections are relatively cheap in the ARPA
+
+Internet, substantial savings are achieved for PCs which contact the KDS over a
+
+public phone network (dial-up) connection.
+
+
+       The  TMA  performs  mappings  between  pairs  of  the  following  objects:  user
+
+names, KDS IDs, and MTS addresses.  The TMA considers all trusted mail agents,
+
+including itself, as a user name, KDS ID, and one or more MTS addresses.  Although
+
+the  TMA  does  not  interpret  addresses  itself,  in  order  to  simplify  mail  handling,
+
+the TMA remembers the relationship between these objects so the user enters this
+
+information only once.
+
+
+       Initially, when a TMA is booted, the user supplies it with the master key and
+
+the user's KDS ID. Both of these quantities are assigned by the personnel at the
+
+key distribution center, and subsequently transmitted to the user via an alternate,
+
+bonded service.8  The TMA connects with the KDS and verifies its identity.  From
+
+this point on, the TMA manages its KK-relationships between the KDS and other
+
+TMAs without user intervention.
+
+
+       The current implementation of the TMA assumes a "general memo framework"
+
+in the context of the Standards for ARPA Internet Text Messages[DCroc82]:
+
+
+
+________________________________________
+7  In the prototype implementation, the two directories are, for the moment, identical.
+8  In this fashion, the problems of boot-strapping over an unsecure medium are avoided.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              11
+
+
+           1.  A message consists of two parts:  the headers and the body.  A blank line
+
+               separates the headers from the body.
+
+
+           2.  Each  (virtual)  line  in  the  headers  consists  of  a  keyword/value  pair,
+
+               in  which  the  keyword  is  separated  from  the  value  by  a  colon  (:).
+
+               The  headers  are  rigorously  structured  in  the  sense  that  they  contain
+
+               addressing and other information useful to a user agent.
+
+
+           3.  The  body  is  freely  formatted  and  must  not  be  meaningful  to  a  user
+
+               agent.  However,  as  will  be  seen  momentarily,  the  body  of  encrypted
+
+               messages must have an initial fixed format which the TMA enforces.
+
+
+This  format  is  widely  called  "822"  after  the  number  assigned  to  the  defining
+
+report[DCroc82].9
+
+
+       To support the cipher activities described below, the TMA contains internal
+
+routines  to  perform  the  following  DES  functions:  electronic  code  book  (ECB)
+
+for  key  encryption,  cipher  block  chaining  (CBC)  for  mail  message  encryption,
+
+checksumming (CKS) for mail message and CSM authentication.  Readers interested
+
+in these different modes of operation for the DES should consult [FIPS81].
+
+
+Encrypting Mail
+
+       To  encipher  a  message,  the  method  used  is  a  straightforward  adaptation
+
+of the standard encrypting/authentication techniques (though the terminology is
+
+tedious).  Consider the following notation:
+
+
+     ax (s):   the  checksum  of  the  string  s  using  the  key  x  (DEA  checksumming
+
+               authentication)
+
+
+  ax+y  (s):   the  checksum  of  the  string  s  using  the  exclusive-or  of  the  two  keys  x
+
+               and y
+
+
+     ex (y):   the encryption of the key y  using the key x (DEA electronic code book
+
+               encryption)
+
+
+   ex;y (s):   the encryption of the string s using the key x and initialization vector
+
+               y (DEA cipher block chaining encryption)
+
+
+           h:  the headers of the message
+
+
+       and,
+
+
+           b:  the body of the message
+
+
+
+________________________________________
+9  Although an 822-style framework is employed by the TMA prototype, the 822 ``Encrypted:''
+
+header  is  not  currently  present  in  encrypted  messages.   This  is  due  to  a  design  decision  which
+assumes  that  nothing  in  the  headers  of  a  message  is  sacred  to  the  transport  system,  and  that
+"helpful" munging might occur at any time. In the real world, such helpfulness is often a problem.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              12
+
+
+For each message to be encrypted, a data key, initialization vector, authentication
+
+key (KD/IV/KA) triple is generated by a random process.  (It goes without saying
+
+that the integrity of the system depends on the process being random).  Then, for
+
+each  user  to  receive  a  copy  of  the  encrypted  message,  the  following  actions  are
+
+taken:
+
+
+       First,  the  headers  of  the  message  are  output  in  the  clear.  Then,  a  banner
+
+string, i, is constructed and placed at the beginning of the body of the message:
+
+
+           ENCRYPTED  MESSAGE:  TTI  TMA
+
+
+which  identifies  the  message  as  being  encrypted  by  the  TTI  TMA.  Following
+
+the  banner  string  is  a  structure,  m,  which  takes  on  the  syntax  and  most  of  the
+
+semantics of a cryptographic service message:
+
+
+            MCL/      MAIL
+
+            RCV/      rcvid
+
+            ORG/      orgid
+
+             IDK/     kkid
+
+              KD/     ekk (ka)
+
+              KD/     ekk (kd)
+
+               IV/    ekd (iv)
+
+            MIC/      aka (b)
+
+           MAC/       akd+ka   (m)
+
+
+After  this,  the  encrypted  body  is  output,  ekd;iv (b).  In  short,  the  entire  output
+
+consists of
+
+                                           h + i + m + ekd;iv (b):
+
+
+
+       The purpose of the structure m is many-fold.  The MCL field indicates the
+
+structure  m's  type;  currently  only  the  type  MAIL  is  generated  and  understood.
+
+The RCV and ORG fields identify the intended recipient of the message and the
+
+originator.  The IDK field identifies the key-encrypting key, KK, used to encrypt
+
+the next two fields.  The first KD field has the encrypted authentication key, KA,
+
+used  to  calculate  the  MIC  of  the  plaintext  of  the  body  of  the  message.   After
+
+the body of the message is deciphered, aka (b) is calculated and compared to the
+
+value of the MIC field.  Hence, the MIC field authenticates the message body.  The
+
+second KD field has the encrypted data encrypting key, KD, which along with the
+
+encrypted initialization vector in the IV field was used to generate the ciphertext
+
+of the body.  Finally, the MAC field authenticates the m structure itself.  The use
+
+of a data key, initialization vector, authentication key (KD/IV/KA) triple permits
+
+us to perform key distribution in a hierarchical fashion and allows the system to
+
+use a KK-relationship over a longer cryptoperiod without fear of compromise.
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              13
+
+
+        The TMA provides three primary interfaces to a UA to send encrypted mail:
+
+ the  first  takes  a  file-descriptor  to  a  message  and  returns  a  structure  g  (called  a
+
+ group) describing the ciphertext version of the body (this structure contains a KD,
+
+ IV,  and  KA  generated  at  random,  along  with  a  file-descriptor  to  the  plaintext
+
+ headers, a file-descriptor to the ciphertext body, and the checksum of the plaintext
+
+ body);  the  second  takes  a  user  entry  (or  MTS  address)  and  g,  and  returns  a
+
+ file-descriptor to the encrypted message for that user (or MTS address); the third
+
+ takes g  and performs clean-up operations.  The chief advantage to this scheme of
+
+ encryption is that if the message is to be sent to more than one recipient, then the
+
+ MIC and the encrypted body need only be calculated once, since the KD, IV, and
+
+ KA  remain  constant  (only  the  KK's  change  with  each  recipient,  hence  for  each
+
+ copy of the encrypted message, only the structure m need be re-calculated).
+
+
+        There are, however, a few subtleties involved:  first_, the MTS usually accepts
+
+ only 7-bit characters, so the encrypted text is exploded to consist of only printable
+
+ characters;10  second____,  since  the  MTS  may  impose  limits  on  the  length  of  a  line,
+
+ each  line  of  output  is  limited  to  64  characters;  and,  third___,  since  the  body  may
+
+ require  trailing  padding,  during  encryption  one  last  unit  of  8  bytes  is  written
+
+ (and encrypted), naming the number of characters (presently, nulls) padded in the
+
+ previous 8 bytes (0 : : :7).
+
+
+ Decrypting Mail
+
+        To decipher a message, the method is also straightforward:  The headers are
+
+ output in the clear.  The banner string is essentially ignored, and the structure m
+
+ is consulted to identify the correct key-encrypting key.  The TMA checks to see if
+
+ it knows of that KK. If not,  it asks the KDS to supply it.  From that point,  the
+
+ KA, KD, and IV are deciphered.  The m structure is then authenticated.  With the
+
+ correct key,  the remainder of the body is deciphered,  and all except for the last
+
+ 16 bytes are output.  The last 8 bytes indicate how many of the previous 8 bytes
+
+ should be output.  So, the appropriate number of bytes is output, and the plaintext
+
+ body is authenticated and compared to the MIC. Needless to say, as the body is
+
+ deciphered, it is imploded back to 8-bit characters and lines are restored to their
+
+ previous  lengths.  To  indicate  that  the  message  was  correctly  deciphered,  a  new
+
+ header of the form
+
+
+            X-KDS-ID:  orgid  (originator's  name)
+
+
+ is appended to the headers of the message.  Note that this provides an authentication
+
+ mechanism.  Note, further, that the UA did not have to know the identity of the
+
+ sender of the message.
+
+
+
+ ________________________________________
+10  As a rule, in all CSMs, when encrypted information is transmitted, it is exploded after encryption
+
+ by the sender, and imploded prior to decryption by the receiver.
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              14
+
+
+ Modifications to MH
+
+        MH  is  a  public  domain  UA  for  UNIX,  which  is  widely  used  in  dealing  with
+
+ both a large number of electronic mail application and a large number of messages.
+
+ Although this document does not intend to describe MH, parts of the system are
+
+ described  as  they  relate  to  the  TMA.  Readers  interested  in  MH  should  consult
+
+ either the user's manual[MRose85a] for a detailed description, or [MRose85d] for a
+
+ higher-level description.
+
+
+        To modify MH in order to make use of a TMA, three programs were changed
+
+ (with  a  high  degree  of  transparency  to  the  user),  and  two  new  programs  were
+
+ introduced.
+
+
+        In  MH,  when  a  user  wishes  to  send  a  composed  draft  (which  may  be  an
+
+ entirely new message, a re-distribution of a message, a forwarding of messages, or
+
+ a reply to a message), the user invokes the send program.  This program performs
+
+ some minor front-end work for a program called post which actually interacts with
+
+ the MTS. A new option to the send and post programs, the `-encrypt'        switch, is
+
+ introduced.  If the user indicates
+
+
+            send -encrypt
+
+
+ then post encrypts the messages it sends.
+
+
+        When  sending  an  encrypted  message,  post  first  checks  that  each  addressee
+
+ has a mapping to a KDS ID during address verification.  Then, instead of batching
+
+ all addresses for a message in a single posting transaction, for each addressee, post
+
+ consults  the  TMA  for  the  appropriately  encrypted  text  and  posts  that  instead.
+
+ (Appendix A discusses the reasons for this more fully.)  Hence, assuming the user
+
+ has  established  mappings  between  MTS  addresses  and  KDS  IDs,  the  TMA  does
+
+ all the work necessary to encrypt the message,  including contacting the KDS as
+
+ necessary.11
+
+
+        In MH, when a user is notified that new mail has arrived, the inc program is
+
+ run.  As each message is incorporated into the user's message handling area, a scan
+
+ (one-line) listing of the message is generated.
+
+
+        By default, the inc program upon detecting one or more encrypted messages,
+
+ after the scanning process, asks the TMA to decipher the message, and if successful,
+
+ scans the deciphered messages.  This action can be inhibited with the `-nodecrypt'
+
+ switch.  Hence,  if  the  user  wishes  to  retain  messages  in  encrypted  form,  inc  can
+
+ be told to note the presence of encrypted messages, but otherwise not to process
+
+ them.  By using the MH user profile mechanism, inc can be easily customized to
+
+ ________________________________________
+11  Once  the  TMA  establishes  a  connection  to  the  KDS,  it  retains  that  connection  until  the  UA
+
+ terminates.  This is done to minimize connections to the KDS. In the context of MH, since the
+ trusted mail agent is active over the lifetime of an invocation of a program such as post, this means
+ that the connection is terminated just before the program terminates.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              15
+
+
+reflect the user's tastes.  Again, the actions of the TMA are transparent to the user.
+
+In fact, if encrypted mail is received from users unknown to the TMA, it queries
+
+the KDS as to their identity prior to retrieving the KK-relationship.
+
+
+       If  inc  fails  to  decrypt  a  message  for  some  reason,  or  if  inc  was  told  not  to
+
+decrypt a message, the decipher program can be used.  This simple program merely
+
+deciphers each message given in its argument list.  The decipher program can be
+
+given the `-insitu'        switch, which directs it to replace the ciphertext version of
+
+the message with the plaintext version;  or, the `-noinsitu'         switch can be used
+
+indicating that the ciphertext version of the message should be left untouched and
+
+the plaintext version should be listed on the standard output.
+
+
+       Finally, the tma program is used to manipulate the TMA database, containing
+
+commands to boot the database, add new users to the database, and to establish
+
+mappings between addresses and users in the TMA database.  This program can
+
+also be used to disconnect KKs between other TMAs,  and the KK/KA between
+
+itself and the KDS.
+
+
+       Appendix A of this paper contains a transcript of an MH session.
+
+
+
+Remarks
+
+       We now consider the merit of the system described.  After presenting some
+
+of the basic strengths of the system and a few unresolved questions, the discussion
+
+centers on the simplifying assumptions made by the system, and how these can be
+
+defended in a non-military environment.
+
+
+Strengths
+
+       It  can  be  argued  that  the  prototype  system  (and  the  augmented  model  in
+
+which it finds its basis) present many strengths.
+
+
+       Perhaps the most important is the high-level of independence from the MTS
+
+enjoyed  by  the  system.   As  a  result,  since  the  TMA  does  not  interact  directly
+
+with  the  MTS,  it  can  be  made  to  be  completely  free  from  any  MTS-specific
+
+attributes,  such  as  naming,  addressing,  and  routing  conventions.  Furthermore,
+
+when interfacing a Trusted Mail system, no modifications need be made to the MTS
+
+or local MTA.
+
+
+       In addition to the systems-level advantage to this scheme, users of the system
+
+profit as well, since many disjoint MTSs can be employed by a user with a single
+
+TMA. This reduces the number of weaknesses in the system and allows a user to
+
+keep a single database of "trusted" correspondents.  It should also make analysis
+
+and verification of the TMA easier.
+
+
+       Of course from the user-viewpoint, once the TMA has been initially booted,
+
+all key management is automatic.  Not only does this reduce the risk of compromise
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              16
+
+
+ of  cryptographic  material  (given  proper  construction  and  maintenance  of  the
+
+ TMA), but it relieves the user of a tedious and error-prone task.
+
+
+        Finally, although the KDS described herein is used to support Trusted Mail,
+
+ other applications which require key management, could employ the services offered
+
+ by the key distribution center.
+
+
+ Open Questions
+
+        At  present,  there  are  many  restrictions  on  the  prototype  implementation
+
+ described.   Some  of  these  result  from  that  fact  that  the  implementation  is  a
+
+ prototype  and  not  a  production  system.   Others  deal  with  more  fundamental
+
+ issues.
+
+
+        In terms of the TMA, the expiration delay for keys is hard-wired in; it should
+
+ be user-settable.  In the prototype version, the KK and KA with the KDS are good
+
+ for  2  days  or  10  uses  (whichever  comes  first),  while  a  KK  for  use  with  another
+
+ TMA is good for 1 day or 5 uses.  In actual practice, keys with long cryptoperiods
+
+ might be good for 6 months or 100 uses, while keys with short cryptoperiods might
+
+ be good for 1 month or 25 uses.  The choice of actual values is an open question
+
+ beyond the scope of prototype system.12   In many respects, this issue is a classic
+
+ trade-off:  with  relatively  small  cryptoperiods,  an  adversary  has  less  chance  of
+
+ breaking a key, but with longer cryptoperiods less connections have to be made to
+
+ the key distribution server.
+
+
+        A  fundamental  issue,  owing  to  differences  between  the  EFT  and  CBMS
+
+ environments, is that the KDS implements only a subset of the ansi draft and the
+
+ semantics of certain operations have changed somewhat.  It would be nice to unify
+
+ the CBMS and EFT views of a key distribution center (in the former environment,
+
+ the center is called a KDC, while in the latter environment,  the center is known
+
+ as  a  CKD).  Appendix  C  of  this  paper  discusses  the  differences  between  the  two
+
+ perspectives in greater detail.
+
+
+        At  present,  the  relationship  between  errors  in  the  TMA  and  the  posting
+
+ process is an open question.  For example, if an address doesn't have a mapping in
+
+ the TMA database, post treats this as an address verification error.  This prevents
+
+ the draft from being posted.  The philosophy of the UA is unclear at this point,
+
+ with respect to how recovery should occur.  A second area, also in question, deals
+
+ with the way in which plaintext and ciphertext versions of a message are present
+
+ in a system.  Clearly,  it is a bad idea to make both versions available,  but since
+
+ the TMA doesn't try to concern itself with first party observation, there seems to
+
+ be little possibility of preventing this behavior.  The best that can be done, at this
+
+ stage, is simply to choose a consistent policy that user's should attempt to adhere
+
+
+
+ ________________________________________
+12  The current values were chosen by guess work.  Although not necessarily technically sound, the
+
+ small numbers were very good for debugging purposes.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              17
+
+
+to.  The software can help somewhat in implementing this policy, but it certainly
+
+can't circumvent the user.
+
+
+       The prototype is built on the assumption that a single key distribution server
+
+is present.  Since the ansi draft[FIKM] makes provisions for key translation centers,
+
+the Trusted Mail prototype should perhaps be made to operate in a more diverse
+
+environment.  Until the issues become clearer, this remains open.
+
+
+       Finally, for distribution lists, a large number of people would need to share
+
+the same KDS ID. The current implementation doesn't support this.  Each TMA
+
+database  is  for  a  particular  ID.  A  user  with  multiple  IDs  would  need  multiple
+
+databases, or the database should be re-organized.
+
+
+Weaknesses
+
+       As pointed out earlier, this prototype system situates itself in a commercial,
+
+not  military,  environment.   With  respect  to  this  decision,  several  aspects  of
+
+the  system  are  now  discussed,  which  we  feel  are  acceptable  in  a  commercial
+
+environment, but which would be considered weaknesses in a military environment:
+
+
+   1.  Traffic Flow
+
+       The  prototype  TMA  makes  no  attempt  whatsoever  to  prevent  or  confuse
+
+       traffic analysis by augmenting traffic flow.
+
+
+   2.  The Database of KDS Subscribers
+
+       Since  information  returned  by  the  request  user  identification  (RUI)  and
+
+       request  identified  user  (RIU)  MCLs  are  returned  in  the  clear,  this  allows
+
+       an  adversary  to  ascertain  subscribers  to  the  KDS,  and  perhaps  deduce
+
+       some information about the system.  Without knowledge of the master key
+
+       however, an adversary could not impersonate a subscriber though.  Still, in
+
+       the  military  sense,  this  is  a  weakness.  However,  all  this  assumes  that  the
+
+       database maintained by the KDS accurately reflects the real-world.
+
+
+   3.  Multiple Recipients
+
+       It is possible, though not proven to the authors' knowledge, that the scheme
+
+       used to avoid encrypting the body of a message more than once for multiple
+
+       recipients  might  permit  one  of  the  recipients  who  is  also  an  adversary  to
+
+       compromise the key relationship between the sender and another recipient.
+
+
+       The scenario goes like this:  When a message is being prepared for encryption,
+
+       a single KD/IV/KA triple is generated to encrypt the body.  Since the sender
+
+       has  a  different  key  relationship  with  each  recipient,  each  message  sent  is
+
+       different,  since the structure m depends not only on the KD/IV/KA triple
+
+       but also on the key relation between the sender and a particular recipient.
+
+       Now suppose that one of the recipients, r1 , in addition to receiving the copy
+
+       of  the  message  meant  for  him/her  also  intercepts  a  copy  of  the  message
+
+       destined  for  another  recipient,  r2 .  At  this  point,  the  recipient  r1  has  both
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              18
+
+
+       the plaintext and ciphertext version of the body, the plaintext version of the
+
+       KD/IV/KA triple, and the ciphertext version of the KD/IV/KA triple that
+
+       was generated using the key relationship between the sender and the recipient
+
+       r2 .  The  question  is:  can  r1  now  deduce  the  key  relationship  between  the
+
+       sender and r2 ?
+
+
+       If so, then the way that the TMA attempts to minimize the use of encryption
+
+       resources is a weakness.  But,  even if this is possible,  given relatively short
+
+       cryptoperiods  for  key  relationships  between  TMA  peers,  this  becomes  a
+
+       non-problem.
+
+
+   4.  Discussion Groups
+
+       As discussed earlier, the proposed method of associating a single KDS ID with
+
+       the membership of a discussion group does introduce a significant weakness
+
+       for  the  security  of  messages  sent  to  the  discussion  group.  Since  the  TMA
+
+       does  not  assume  a  general  broadcast  facility,  it  appears  that  there  are  no
+
+       good solutions to the problem of discussion group traffic.  Of course, it is easy
+
+       enough to simply send to each member of the group.
+
+
+       For  the  sake  of  argument,  let's  assume  that  the  discussion  group  has  n
+
+       members.  Now,  since  a  different  key  relationship  would  exist  between  the
+
+       sender and each of the n recipients,  the structure m would be different for
+
+       each  recipient  and  so  a  different  message  would  have  to  be  sent  to  each
+
+       recipient.  To make matters worse,  if one rejects the way the TMA handles
+
+       multiple  recipients,  not  only  does  the  MTS  get  burdened  with  n  different
+
+       messages, but the sender's TMA gets burdened by having to encrypt the body
+
+       of the message n times.  For meaningful values of n (say on the order of 500,
+
+       or even 25), the amount of resources required for any trusted discussion group
+
+       are simply too costly.
+
+
+Compromises, Compromises
+
+       Each  of  the  possible  weaknesses  discussed  above  represent  a  compromise
+
+between the expense of the system and the level of security it can provide.
+
+
+       The  first  two  areas,  if  addressed  by  the  TMA,  could  result  in  much  less
+
+background information being available to an adversary.  In an application where it
+
+is important that an adversary not know who is talking to whom, or who can talk
+
+at all,  this is very important.  It is the authors' position that in the commercial
+
+environment, this issue is not paramount.  By ignoring the issue of traffic flow, the
+
+TMA has a lot less work to do and the MTS is kept clear of "useless" messages.
+
+By keeping the information returned by the RUI and RIU MCLs in the clear, the
+
+complexity of the TMA is significantly reduced.
+
+
+       The  second  two  areas,  if  addressed  by  the  TMA,  could  result  in  a  lesser
+
+probability  of  traffic  being  deciphered  by  an  adversary.   Regardless  of  the
+
+application,  this  is  always  extremely  important.   However,  the  authors'  feel
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              19
+
+
+that  the  compromise  made  by  the  TMA  in  these  two  issues  is  not  substantial,
+
+and  does  not  result  in  an  explicit  weakness  when  a  message  is  sent  to  multiple
+
+recipients (note that when there is only a single recipient of a message, these two
+
+policies  can  not  introduce  weaknesses).  In  return,  efficient  use  can  be  made  of
+
+both the MTS and the TMA when messages are being sent to multiple recipients.
+
+Given scarce resources or large numbers of recipients, this approach may prove to
+
+be quite winning.
+
+
+       Of course, much work remains to be done to prove the success of the TMA in
+
+all four of these areas.
+
+
+
+Acknowledgements
+
+       The  prototype  implementation  described  herein  utilizes  a  public  domain
+
+implementation of the DES algorithm[DEA] which was originally implemented by
+
+James J. Gillogly in May, 1977 (who at that time was with the Rand Corporation,
+
+and  is  now  affiliated  with  Gillogly  Software).   Interfaces  to  Dr.  Gillogly's
+
+implementation were subsequently coded by Richard W. Outerbridge in September,
+
+1984 (who at that time was with the Computer Systems Research Institute at the
+
+University of Toronto, and is now affiliated with Perle Systems, Incorporated).
+
+
+       The  authors  would  like  to  acknowledge  Dennis  Branstad,  Elaine  Barker,
+
+and  David  Balensen  of  the  National  Bureau  of  Standards  for  their  comments
+
+on  the  prototype  system  and  insights  on  the  ANSI  draft[FIKM].  In  particular,
+
+Dr. Branstad originally suggested the method used for encrypting a single message
+
+for multiple recipients under different keys.
+
+
+       The authors (and all those who have read this paper) would like to thank Willis
+
+H. Ware of the Rand Corporation, and Jonathon B. Postel of the USC/Information
+
+Sciences  Institute.  Their  extensive  comments  resulted  in  a  much  more  readable
+
+paper.  In  addition,  the  authors  would  like  to  thank  Dr.  Stephen  P.  Smith  and
+
+Major Douglas A. Brothers for their insightful comments.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              20
+
+
+                                                 References
+
+
+
+[DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
+
+                 Messages.  Request  for  Comments  822.  ARPA  Internet  Network
+
+                 Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DEA]            Data  Encryption  Algorithm,  X3.92-1981,  American  National
+
+                 Standards Institute, 1981.
+
+
+
+[FIKM]           Financial Institution Key Management, X9.17-198_  (draft), American
+
+                 National Standards Institute, 198_.
+
+
+
+[FIPS46]         Data Encryption Standard, Federal Information Processing Standards,
+
+                 Publication 46, 1977.
+
+
+
+[FIPS81]         DES Modes of Operation, Federal Information Processing Standards,
+
+                 Publication 81, 1980.
+
+
+
+[IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
+
+                 Appearing in Internet Protocol Transition Workbook, ARPA Internet
+
+                 Network Information Center (NIC), SRI International, 1981.
+
+
+
+[LLamp82]        L. Lamport, R. Shostak, M. Pease.  The Byzantine Generals Problem.
+
+                 ACM Transactions on Programming Languages and Systems 4  (July,
+
+                 1982), 382-401.
+
+
+
+[MRose85a]       M.T. Rose,  J.L. Romine.  The Rand MH Message Handling System:
+
+                 User's Manual. UCI Version. Department of Information and Computer
+
+                 Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85d]       M.T. Rose, E.A. Stefferud, J.N. Sweet.  MH: A Multifarious User
+
+                 Agent. Computer Networks (to appear).
+
+
+
+[TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
+
+                 1778).  Appearing  in  Internet  Protocol  Transition  Workbook,  ARPA
+
+                 Internet Network Information Center (NIC), SRI International, 1981.
+
+
+
+[VVoyd83]        V.L.  Voydock,  S.T.  Kent.   Security  Mechanisms  in  High-Level
+
+                 Network Protocols. Computing Surveys 15, 2 (June, 1983), 135-171.
+
+
+
+[X.400]          Message  Handling  Systems:   System  Model-Service  Elements,
+
+                 Recommendation  X.400,  International  Telegraph  and  Telephone
+
+                 Consultative Committee (CCITT).
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              21
+ ______________________________________________________________________________________________________________________
+
+  1    %  tma  -add  -user  "UCI  Portal"  uci@udel-dewey
+  2    3:  "UCI  Portal"
+  3         uci@udel-dewey
+  4
+  5    %  comp
+  6    To:  uci
+  7    Fcc:  +outbox
+  8    Subject:  test  message
+  9    --------
+10     mumble,  mumble.
+11     ^D
+12
+13     What  now?  send  -encrypt
+14      --  Address  Verification  --
+15        --  Local  Recipients  --
+16        uci:  address  ok
+17      --  Address  Verification  Successful  --
+18      --  Posting  for  All  Recipients  --
+19        --  Local  Recipients  --
+20        uci:  address  ok
+21      --  Recipient  Copies  Posted  --
+22      --  Filing  Folder  Copies  --
+23        Fcc  outbox:  folder  ok
+24      --  Folder  Copies  Filed  --
+25     Message  Processed
+
+
+                                                     Figure 4
+
+ __________________________________________Sending_Encrypted_Mail______________________________________________________
+
+
+
+ Appendix A: An MH Session
+
+        In  the  following,  the  user  ``Marshall T. Rose''                logged  onto  host
+
+ ``udel-dewey''          , wishes to send a message to a user known as the ``UCI Portal''
+
+ (a system maintenance account).  As shown in Figure 4, line 1, the user first estab-
+
+ lishes a mapping between the name ``UCI Portal''           and the address uci@udel-
+
+ dewey.  Once this mapping is performed, it remains in effect until the user indicates
+
+ otherwise  to  the  TMA.  When  the  tma  program  is  invoked,  it  consults  the  TMA
+
+ database to see if that user is known.  If not,  it contacts the KDS to ask for the
+
+ KDS ID associated with the user.  If the response is successful (in this case,  the
+
+ KDS ID is ``3''    ), then the TMA updates its database.  The tma program indicates
+
+ in its output the KDS ID associated with the user, along with all known addresses
+
+ (in this case, only one).  So, once the name to address mapping has been described
+
+ the user, the user agent, MH, deals only with the address, while the trusted mail
+
+ agent deals with the name and KDS ID aspects of the user.
+
+
+        Next, the comp program is invoked to compose a new draft on line 5.  The
+
+ user addresses the local user ``uci''      in the To:  field, and indicates that a plaintext
+
+ copy  should  be  kept  in  the  folder  ``+outbox''       .  After  entering  the  subject  and
+
+ text of the draft,  the user enters What  now?  level on line 13.  At this point,  the
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              22
+______________________________________________________________________________________________________________________
+
+ 1    %  inc
+ 2    Incorporating  new  mail  into  inbox...
+ 3
+ 4        1+E02/28  0227-EST  mrose                   test  message   <<ENCRYPTED  MESSAGE:  TTI
+ 5
+ 6    Incorporating  encrypted  mail  into  inbox...
+ 7
+ 8        1+  02/28  0227-EST  mrose                   test  message   <<mumble,  mumble.  >>
+
+
+                                                    Figure 5
+
+________________________________________Receiving_Encrypted_Mail______________________________________________________
+
+
+
+user  directs  MH  to  send  the  draft  in  encrypted  form.   The  resulting  output  is
+
+verbose (a default for send for this user) but instructive.  Initially, all addresses in
+
+the draft are verified on lines 14 to 17.  Two forms of verification occur:  first, the
+
+MTS is asked to verify the address as much as possible.  For local addresses, the
+
+MTS decides if the name has a maildrop associated with it.  For remote addresses,
+
+the MTS decides if the host is known to it.  The second type of verification occurs
+
+with the TMA. For all addresses, the TMA is asked if it can find a mapping from
+
+the address to a KDS ID.
+
+
+       The  reason  MH  goes  to  all  this  trouble  is  a  philosophical  issue.  Since  the
+
+copy of the encrypted draft is different for each recipient, post tries to verify that
+
+all  recipients  can  be  successfully  posted  prior  to  actually  posting  the  different
+
+ciphertext versions of the draft.  This behavior is not optimal in terms of cycles,
+
+but is perhaps "correct" from a UA perspective.
+
+
+       Finally, the draft is actually posted, and the folder carbon-copy is filed.
+
+
+       Some time later, the UCI portal is informed that new mail has arrived.  As
+
+shown  in  Figure  5,  the  inc  program  is  run.  The  ``E''    prior  to  the  date  of  the
+
+message indicates that inc has detected the message to be encrypted.  Since the
+
+user did not inhibit inc from deciphering the message, it proceeds to do so.
+
+
+       Finally,  it  may  be  instructive  to  see  what  the  encrypted  message  looked
+
+like  when  it  was  delivered  to  the  portal's  maildrop,  and  the  final  message  after
+
+deciphering.  Figures 6 and 7 show these respectively.  In particular, note that the
+
+``X-KDS-ID:''          field has been introduced in Figure 7 after successfully deciphering
+
+the message.  The presence of this field authenticates the sender of the message.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              23
+______________________________________________________________________________________________________________________
+
+Received:  From  localhost.DELAWARE  by  udel-dewey.DELAWARE  id  a022713
+              ;28  Feb  85  2:27  EST
+To:  uci@udel-dewey
+Subject:  test  message
+Date:  28  Feb  85  02:27:16  EST  (Thu)
+Message-ID:  <4057.478423636@udel-dewey>
+From:  mrose@udel-dewey
+
+
+ENCRYPTED  MESSAGE:  TTI  TMA
+(
+MCL/MAIL
+RCV/3
+ORG/17
+IDK/850228072730
+KD/e36813a3882eebd1
+KD/fa8b8ac657476669
+IV/Ef9d283565431b103
+MIC/fdb927fb
+MAC/50e9de30
+)
+a13774f652d844762c4fc03c2f4e201b9d2f57eadb00546c
+
+
+                                                    Figure 6
+
+______________________________________Message_Prior_to_Decryption_____________________________________________________
+
+______________________________________________________________________________________________________________________
+Received:  From  localhost.DELAWARE  by  udel-dewey.DELAWARE  id  a022713
+              ;28  Feb  85  2:27  EST
+To:  uci@udel-dewey
+Subject:  test  message
+Date:  28  Feb  85  02:27:16  EST  (Thu)
+Message-ID:  <4057.478423636@udel-dewey>
+From:  mrose@udel-dewey
+X-KDS-ID:  17  (Marshall  T.  Rose)
+
+
+mumble,  mumble.
+
+
+                                                    Figure 7
+
+________________________________________Message_After_Decryption______________________________________________________
+
+
+
+Appendix B: A Short Exchange
+
+       The simple nature of the interchange between the user and MH in Appendix A
+
+completely hides any interactions between the TMA and the KDS. Let us briefly
+
+examine  an  exchange  that  might  occur  after  the  destination  TMA  receives  the
+
+message shown in Figure 6.
+
+
+       To  begin,  the  TMA  must  ascertain  what  it  knows  about  the  sender  of  the
+
+message,  which  claims  to  have  a  KDS  ID  of  17.   That  is,  the  TMA  must  first
+
+consider what key relationships it has with the sender.  For the sake of argument,
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              24
+ ______________________________________________________________________________________________________________________
+
+  1    <---  (
+  2    <---  MCL/RIU
+  3    <---  RCV/17
+  4    <---  ORG/3
+  5    <---  KDC/TTI
+  6    <---  EDC/1a1fbbba
+  7    <---  )
+  8    --->  (
+  9    --->  MCL/RTR
+10     --->  RCV/17
+11     --->  ORG/3
+12     --->  CTA/1
+13     --->  USR/"Marshall  T.  Rose"
+14     --->  KDC/TTI
+15     --->  MAC/2ebde134
+16     --->  EDC/96b183de
+17     --->  )
+18     <---  (
+19     <---  MCL/ACK
+20     <---  RCV/17
+21     <---  ORG/3
+22     <---  KDC/TTI
+23     <---  EDC/59a8ddcc
+24     <---  )
+
+
+                                                     Figure 8
+
+ __________________________________________Ascertaining_the_Sender_____________________________________________________
+
+
+
+ suppose that this purported subscriber is unknown to the TMA. In this case, the
+
+ first step it must undertake is to ascertain the validity of this subscriber.
+
+
+        As  shown  in  Figure  8  on  lines  1-7,  the  TMA  does  this  by  establishing  a
+
+ connection  to  the  KDS  and  issuing  an  request  identified  user  (RUI)  MCL.13  If
+
+ the response by the KDS is positive,  the TMA will use the information returned
+
+ when generating the ``X-KDS-ID:''           field for authentication.  The response CSM
+
+ returned  by  the  KDS  includes  an  authentication  checksum  (the  MAC  field  on
+
+ line 15) and a transaction count (the CTA field on line 12) to prevent spoofing by a
+
+ process pretending to be the KDS. The TMA then acknowledges that the response
+
+ from the server was acceptable on lines 18-24.
+
+
+        The next step is to ascertain the actual key relationship used to encrypt the
+
+ structure  m,  which  appears  after  the  identifying  string.  The  TMA  consults  the
+
+
+ ________________________________________
+13  In point of fact, the very first thing that the TMA does after connecting to the KDS is verify
+
+ that  the  key  relationships  between  the  KDS  and  the  TMA  are  valid  (have  not  expired).   If  the
+ key relationship between the two has expired, the TMA issues a request service initialization RSI
+ MCL to establish a new key relationship. This relationship contains a key-encrypting key (KK) and
+ an authentication key (KA). Once a valid key relationship exists between the KDS and the TMA,
+ transactions concerning other key relationships may take place.
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              25
+ ______________________________________________________________________________________________________________________
+
+  1    <---  (
+  2    <---  MCL/RSI
+  3    <---  RCV/17
+  4    <---  ORG/3
+  5    <---  IDK/850228072730
+  6    <---  KDC/TTI
+  7    <---  SVR/KD.IV.KK
+  8    <---  EDC/83679e14
+  9    <---  )
+10     --->  (
+11     --->  MCL/RTR
+12     --->  RCV/17
+13     --->  ORG/3
+14     --->  KK/095f9d6b87f57871
+15     --->  CTA/2
+16     --->  KD/527fbb5593efd318
+17     --->  KD/1dcab338be1e7a09
+18     --->  IV/E02db5e598b2823ae
+19     --->  EDK/850618075332
+20     --->  KDC/TTI
+21     --->  MAC/12cbbdf5
+22     --->  EDC/8cd0c4a8
+23     --->  )
+24     <---  (
+25     <---  MCL/ACK
+26     <---  RCV/17
+27     <---  ORG/3
+28     <---  KDC/TTI
+29     <---  EDC/59a8ddcc
+30     <---  )
+
+
+                                                     Figure 9
+
+ __________________________________Ascertaining_the_Key_Relationship___________________________________________________
+
+
+
+ IDK field in m, and if this relationship is unknown to it, then the KDS is asked to
+
+ disclose the key relationship.
+
+
+        As shown in Figure 9 on lines 1-9, This is done by issuing a request service
+
+ initialization (RSI) MCL and specifying the particular key relationship of interest.
+
+ The  KDS  consults  its  database,  and  if  the  exact  key  relationship  between  the
+
+ two  indicated  TMAs  can  be  ascertained,  it  returns  this  information.   The  key
+
+ relationship  is  encrypted  using  the  key  relationship  between  the  KDS  and  the
+
+ TMA, and the usual count and authentication fields are included.
+
+
+        Once the TMA knows the key relationship used to encrypt the structure m,
+
+ it can decider the structure and ascertain the KD/IV/KA triple used to encrypt
+
+ the body of the message.
+  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              26
+
+
+ Appendix C: Differences between the ANSI and TTI drafts
+
+        The differences between the ansi draft standard for financial institution key
+
+ management,  and  the  TTI  draft's  specification  for  trusted  mail  handling,  are
+
+ considered.
+
+
+        The concept of a key distribution center (CKD in the ansi draft, KDC in the
+
+ TTI  draft) environment differs.  In the ansi draft, only one party talks to the key
+
+ distribution  server  (KDS);  in  the  TTI  draft,  both  parties  talk  to  the  KDS.  This
+
+ leads  to  a  number  of  differences  in  the  two  protocols.  The  reason  for  this  shift
+
+ in the TTI  draft is somewhat subtle:  although both parties can talk to the KDS,
+
+ the mail transfer system (MTS) environment is such that both user agents (UAs)
+
+ are unable to contact each other in real-time.  Hence, a detailed two-way protocol
+
+ between them is prohibitively expensive.14
+
+
+        Before discussing the differences between the two drafts, let us consider the
+
+ differences in the two environments:  in the electronic mail environment, the two
+
+ end-to-end  peers  need  not  be  simultaneously  online.  Electronic  mail  relies  on  a
+
+ communication  service  with  potentially  large  delays  in  transit  between  message
+
+ transfer agents (MTAs).  A basic concept of "mail" is that an originator must release
+
+ the enveloped message to a "transfer agent" before delivery can be attempted to a
+
+ recipient.  In contrast, in the electronic funds environment, the two peers make use
+
+ of a virtual-circuit service.  This means that they can synchronize much easier and
+
+ inter-operate in a more direct fashion.
+
+
+        Service protocols are based on the notion of requests and responses.  A client
+
+ issues a request to a server, the server processes the request and returns a response.
+
+ Depending on the complexity of the protocol, the client may now respond to the
+
+ server's message, or might issue a new request, or might terminate the connection.
+
+
+        As  delays  in  the  network  increase,  along  with  the  possibility  of  loss  or
+
+ corruption  or  re-ordering  of  messages,  it  becomes  more  difficult  to  implement  a
+
+ service  protocol.   In  the  case  of  a  high-level  protocol  making  use  of  a  virtual-
+
+ circuit service, most problems can be ignored, as the virtual-circuit service masks
+
+ out  problems  in  the  network  by  using  sequences,  positive  (and/or  negative)
+
+ acknowledgments, windows, and so on.
+
+
+        Sadly,  electronic  mail  cannot  utilize  a  virtual-circuit  throughout  the  MTS
+
+ (although individual MTA-wise connections are (in theory) virtual-circuit based).
+
+ This means that implementing a real-time or interactive service protocol between
+
+ two endpoints (a.k.a. UAs) in the MTS is very difficult.  As a result, the complexity
+
+ of  an  end-to-end  protocol  in  the  MTS  (in  terms  of  requests  and  responses)  is
+
+ severely  constrained.  For  all  practical  purposes,  an  MTA  can  assume  datagram
+
+ service and nothing else:  messages might be re-ordered; messages might not reach
+
+ ________________________________________
+14  In the words of Einar A. Stefferud:  "Every interesting connection has at least two end-points _
+
+ connections with only one end-point are always uninteresting."
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              27
+
+
+their destination; messages might be corrupted (though this is unlikely); in cases
+
+of failure, a notice might be generated, or might not.
+
+
+       In terms of the environment in which cryptographic service messages (CSMs)
+
+must flow, the high degree of delay and uncertainty make the implementation of a
+
+complex end-to-end protocol between UAs prohibitively expensive.  Hence, a KDC
+
+is needed, to which each UA can connect using a virtual-circuit service, at posting
+
+and  delivery  time.  The  TTI  draft  terms  such  a  user  agent  a  trusted  mail  agent
+
+(TMA). Since both TMAs can connect to the KDS at different times using different
+
+media, the KDS maintains state information about the key relationships between
+
+different TMAs and manages those relationships appropriately.  Since connections
+
+to the KDS can be expensive in terms of resources, each TMA caches information
+
+received from the KDS appropriately.
+
+
+       That's the gist of the argument as to why the TTI  draft differs from the ansi
+
+draft.  It might be possible to include CSMs in the messages which UAs exchange,
+
+but management of these CSMs can not be done reliably or in a straightforward
+
+fashion owing to the datagram nature of the service offered by the MTS. Finally, it
+
+should be noted that in the TTI  draft, the KDS never initiates a connection with
+
+a TMA, rather it is the TMAs which connect to the KDS.
+
+
+       In the following, the differences between the two drafts are highlighted.  Minor
+
+differences between the two are not discussed.
+
+
+       In the ansi draft, x 4:2 (p. 22) discusses the requirements for the automated
+
+key management architecture.  The TTI  draft has somewhat more "depth", since
+
+the  ansi  draft  does  not  make  use  of  a  master  key  (MK)  to  fully  automate  the
+
+distribution of key-encrypting keys (KK).
+
+
+       The ansi draft states that once a KK-relationship is discontinued by either
+
+of  that  pair,  the  relation  is  not  to  be  re-used  for  any  subsequent  activity.  This
+
+can't be guaranteed in the prototype implementation.  If one of the TMAs wishes
+
+to discontinue a key, not only does it have to inform the KDS, but the other TMA
+
+as well.  Since the TTI  draft does not permit CSMs between TMA-peers, the latter
+
+action doesn't seem possible.  However, there is a solution.  Whenever a message is
+
+deciphered, the TMA checks the effective date of the key used to encrypt a message
+
+it has received, and if the key is newer than the one it currently uses, it considers
+
+the older key to be discontinued.
+
+
+       Furthermore,  although  the  environment  in  the  TTI  draft  is  that  of  a  key
+
+distribution center, the notion of an ultimate recipient is not present, since all clients
+
+connect to the KDS at one time or another.  In addition, the differences between
+
+the  environs  envisioned  by  the  two  drafts  become  even  more  pronounced  when
+
+one considers that the KDS distributes key-encrypting keys to TMAs, although the
+
+ansi draft specifically prohibits this.
+ Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              28
+
+
+       Finally,  there  is  another  important  technical  difference  between  the  two
+
+drafts:  every  request  to  the  KDS  by  the  TMA  results  in  a  specifically  defined
+
+response from the KDS to the TMA. Furthermore, if the KDS responds in a positive
+
+manner, then the TMA acknowledges this.  This three-way interaction is used to
+
+ensure consistency between the states of the KDS and the TMA. The ansi draft
+
+does not require such behavior, and might profit from some finite-state analysis to
+
+ascertain unsafe (in terms of correctness) states which are reachable.
+
+
+
+
+                                                   Contents
+
+
+
+                                                                                                               Page
+
+ Introduction .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
+ *.        1
+
+ The Key Distribution Service  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        6
+
+ The Trusted Mail Agent  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      10
+
+        Encrypting Mail .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      11
+
+        Decrypting Mail .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      13
+
+ Modifications to MH  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      14
+
+ Remarks .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . *
+ * .      15
+
+        Strengths  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .*
+ *      15
+
+        Open Questions  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      16
+
+        Weaknesses .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .   *
+ *   17
+
+        Compromises, Compromises.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      18
+
+ Acknowledgements .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      19
+
+ References .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . *
+ * .      20
+
+ Appendix A: An MH Session  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      21
+
+ Appendix B: A Short Exchange .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      23
+
+ Appendix C: Differences between the ANSI and TTI drafts  .  .  .  .  .  .  .  .  .  .      26
+
+
+
+ ________________________________________
+This document (version #2.60) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+                                                                                                                     i
diff --git a/docs/historical/tutorial.pdf b/docs/historical/tutorial.pdf
new file mode 100644
index 0000000..97b088c
Binary files /dev/null and b/docs/historical/tutorial.pdf differ
diff --git a/docs/historical/tutorial.txt b/docs/historical/tutorial.txt
new file mode 100644
index 0000000..f7c3f45
--- /dev/null
+++ b/docs/historical/tutorial.txt
@@ -0,0 +1,1389 @@
+
+
+
+
+                     The  Rand  MH  Message  Handling  System:
+
+
+
+                                                 Tutorial
+
+
+                                           Marshall T. Rosey
+
+                                             Jerry N. Sweetz
+
+                                  Wed May 21 21:04:08 PDT 1986
+
+
+
+                                                Abstract
+
+
+               This document introduces the UCI version of the Rand MH
+
+               system to novice users.  In particular, this tutorial discusses
+
+               how to read, send, reply to, and review mail; aspects of the
+
+               MH user profile affecting these activities; and other reference
+
+               works on MH.
+
+
+                      Although this document is based on the standard MH
+
+               user  manual[MRose85a],  this  document  is  meant  to  supple-
+
+               ment, not supersede, that lengthier work.
+
+
+                      Comments concerning this documentation should be ad-
+
+               dressed to the Internet mailbox Bug-MH@ICS.UCI.EDU.
+
+
+
+_____________________________________
+Computer Mail: y MRose@NRTC.NORTHROP.COM, z JSweet@ICS.UCI.EDU.
+
+
+                     The  Rand  MH  Message  Handling  System:
+
+
+
+                                                 Tutorial
+
+
+
+Acknowledgements
+
+        The MH system described herein is based on the original Rand MH system.
+
+It has been extensively developed (perhaps too much so) by Marshall Rose and
+
+John Romine at the University of California, Irvine.  Einar Stefferud, Jerry Sweet,
+
+and Terry Domae provided numerous suggestions to improve the UCI version of
+
+MH.
+
+
+        Parts  of  this  document  are  taken  from  a  Rand  tutorial  [SPayn85]  by  Sue
+
+Payne.
+
+
+
+Disclaimer
+
+        The  Regents  of  the  University  of  California  issue  the  following  disclaimer
+
+concerning the UCI version of MH:
+
+
+
+       "Although each program has been tested by its contributor, no warranty, express or
+        implied, is made by the contributor or the University of California, as to the accuracy
+        and functioning of the program and related program material, nor shall the fact of
+        distribution constitute any such warranty, and no responsibility is assumed by the
+        contributor or the University of California in connection herewith."
+
+
+
+Scope
+
+        This document assumes that you have no knowledge of MH. However, to use
+
+MH you should have some familiarity with the UNIX1 operating system, particularly
+
+with the way commands are given,  how files are named,  the jargon (e.g.  shell,
+
+argument, home directory, pathname), and how to use a text editor (such as ex, vi,
+
+or emacs ).
+
+
+        This tutorial covers only basic material.  For additional information about
+
+MH, consult the User's Manual [MRose85a].  Other documents of possible interest
+
+to you include The UCI BBoards Facility [MRose84] and the MH Administrator's
+
+Guide [MRose85b].
+
+
+
+_____________________________________
+1  UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+                                                       1
+                                                                                                              2
+
+
+How To Use This Tutorial
+
+        Different  typefaces  and  symbols  are  used  in  this  document  to  denote  the
+
+kinds of things you (the user) must type on your keyboard.
+
+
+           1.  The names of programs are given in text italics:
+
+
+                                  comp
+
+
+           2.  Arguments to programs are given in typewriter  style, delimited by
+
+               single-quotes:
+
+
+                                  `msgs'
+
+
+           3.  UNIX pathnames are given in slanted roman:
+
+
+                                  /usr/uci/
+
+
+           4.  Text giving a full example is presented in typewriter  style:
+
+
+                   comp -editor vi
+
+
+               The "  " glyph is used to indicate an explicit space (the kind you make
+
+               with the space bar on your keyboard).
+
+
+
+Introduction
+
+        With MH you can send messages to other people on your system and read
+
+messages  that  other  people  send  to  you.  Depending  on  how  things  have  been
+
+set up on your system, it may be possible for you to send messages to people on
+
+remote systems.  You can also reply to messages that you have received, review
+
+them, organize them in folders, and delete them.
+
+
+        MH differs from other mail programs in that it is composed of many small
+
+programs instead of just one very large program.  Among new users this sometimes
+
+causes some confusion along the lines of "what program do I run?"  With MH, you
+
+use the shell to invoke one program at a time.  This means that when you handle
+
+mail, the entire power of the shell is at your disposal in addition to the facilities
+
+that MH provides.  In the beginning, this may not make much sense or may not
+
+seem important.  However, we have found that as new users of MH gain experience,
+
+they find this style of interface to be very useful.
+                                                                                                              3
+
+
+Summary
+
+        The most minimal list of MH commands that you can get by with is:
+
+
+         inc   - incorporate mail (get new mail)
+
+
+       show    - show the first message
+
+
+        next   - show the next message
+
+
+        prev   - show the previous message
+
+
+       comp    - compose a new message to send
+
+
+         repl  - reply to a received message
+
+
+        Comp and repl give enough prompting possibly to get you along.  However,
+
+it is suggested that you take the time to peruse this tutorial before leaping into
+
+things.
+
+
+
+Messages and Folders
+
+        A  message  takes  the  form  of  a  memorandum,  and  is  composed  of  two
+
+major parts:  a header, which contains such information as ``To''     and ``From''
+
+addresses, ``Subject''       , ``Date''     , etc.; and the body, which is the actual text of
+
+the message.  Each component in the header starts with a keyword followed by a
+
+colon and additional information.  For example, in the message:
+
+
+           Date:   10  Oct  84  17:41:14  EDT  (Wed)
+
+           To:   News@udel-dewey
+
+           Subject:   UCI  Software  Talk
+
+           From:   UCI  Portal  (agent:   Marshall  Rose)  <uci@udel-dewey>
+
+
+
+           This  is  the  text.
+
+
+there are four header items, and one line of text in the body.  Note that a blank
+
+line separates the body from the headers.
+
+
+        MH stores a message as an ordinary file in a UNIX directory.  This directory is
+
+called a folder.  If you choose to keep and organize your messages, you may create
+
+as many folders as you wish.  There is no limit as to the number of messages in a
+
+folder.  Typically messages are numbered from 1 up.  All of your personal folders,
+
+along with some other information that MH needs to know, are kept in a special
+
+directory called Mail    under your home directory.  Normally,  MH manages these
+
+files and directories automatically, so you needn't muck around with them directly
+
+unless you really want to.
+                                                                                                              4
+
+
+        You won't have any folders until somebody sends mail to you, as a rule.  If
+
+you are anxious to try out MH, but no one has sent you mail yet, try sending mail
+
+to yourself to start out with.
+
+
+
+Reading New Mail
+
+        When you are notified that you have mail (usually when you log in), perhaps
+
+with the message
+
+
+           You  have  mail.
+
+
+then you know that messages are waiting in your maildrop.  To read these messages,
+
+you first have to incorporate the mail into your "in-box" by typing the command:
+
+
+           inc
+
+
+This incorporates the new mail from your mail drop to your in-box,  which is a
+
+folder named (naturally enough) `+inbox'     .  As inc incorporates your new mail, it
+
+generates a scan listing of the mail:
+
+Incorporating  new  mail  into  inbox...
+
+2 +   10/10    WESTINE% USC-ISIF       RFC  916  Now  Available          <<A  new  Request  for  Co
+3     10/10    G  B  Reilly            Gosling  EMACS  manual            <<Marshall,  I  am  lookin
+4     10/11    WESTINE% USC-ISIF       Internet  Monthly  Report
+
+
+Each  time  inc  is  invoked,  any  new  messages  are  added  to  the  end  of  your
+
+``+inbox''        folder.
+
+
+        To read the first message, use the show command:
+
+
+           show
+
+
+This displays the current message.  To read each subsequent message, use the next
+
+command:
+
+
+           next
+
+
+If you want to back up, the command prev shows the previous message.  Another
+
+way to read your messages is to name them all at once:
+
+
+           show all
+
+
+This command displays them all, one after the other.  The `all'    argument to show
+
+above might also be replaced with `next'     or `prev'    , as in
+
+
+           show next
+
+           show prev
+
+
+which are respectively equivalent to the next and prev commands.
+                                                                                                              5
+
+
+        If you have had occasion to type inc more than once, then you will find that
+
+``show all''         is showing not only the new messages, but also the old messages
+
+that you've already seen.  Therefore, you might find it better to use
+
+
+           show cur-last
+
+
+instead.  This command displays messages from the current message (`cur'   ) to the
+
+last message (`last'    ).  Each time inc is invoked, it makes the first new message the
+
+current message.  It should be noted here that the name `all'    given in a previous
+
+example is equivalent to the message range `first-last'        , where `first'      is the
+
+name of the first message in `+inbox'     .  Also, ``show''      by itself is equivalent to
+
+
+           show cur
+
+
+
+        As mentioned earlier, with the UNIX shell as your interface to MH, it becomes
+
+easy to list a message on a line printer or to another file.  For example,
+
+
+           show all _ lpr
+
+
+lists all the messages in the current folder to the line printer.
+
+
+        To  summarize,  the  preceding  has  introduced  these  important  concepts:
+
+folders  (in  particular,  the  `+inbox'      folder),  messages,  message  names  (e.g.
+
+`prev'    , `next'    , `cur'   , `last'    ), and message ranges (e.g.  `cur-last'      , `all'   ).
+
+More will be said about folders and messages in succeeding sections.
+
+
+
+Sending Messages
+
+        To  send  a  message,  you  compose  a  message  draft,  either  by  replying  to  a
+
+message that someone sent to you, or by creating a draft from scratch.  The send
+
+command is used after completing the final draft of a message, in the same way
+
+that you mail a paper letter only after you are finished writing it.  This is a common
+
+source of confusion among new MH users who may have had experience with other
+
+mail systems.
+
+
+        This section discusses how to originate messages and how to reply to messages
+
+that were previously received, along with a word or two about addresses.
+
+
+Originating Messages
+
+        To create a message draft from scratch, use the comp program.  You will be
+
+prompted for the header components and then the body of the message.  If you
+
+make a mistake, you may correct it later with a text editor.  The draft will be sent
+
+only if you give an explicit send command, so you do not have to worry about the
+
+draft getting away from you prematurely.
+
+
+        To start, you simply type:
+
+
+           comp
+                                                                                                              6
+
+
+        To: First, the prompt `To:'    appears.  Here you type the address of the person
+
+to whom you wish the message sent.  If this person is on the same computer system
+
+as you, then that person's login ID should serve as the address (e.g.  `mrose'     or
+
+`jsweet'     ).
+
+
+        Here we digress briefly to discuss addresses.  A full discussion of addresses
+
+is  beyond  the  scope  of  this  tutorial,  but  it  should  be  mentioned  that  there
+
+are  other  kinds  of  addresses  besides  login  IDs.   To  send  messages  to  people
+
+on  remote  systems,  the  usual  way  is  to  type  `login-id@host'          in  the  `To:'
+
+component, as in `MRose@UCI-ICSA'          .  Examples of `host'     names at UCI include
+
+`uci-icsa'       , `uci-icse'      , and `uci-cip1'      .  Upper and lower case letters may be
+
+used interchangeably.  Sometimes a person's last name (e.g.  `Rose'   , `Sweet'     ) can
+
+be used instead of a login ID, but this cannot be relied upon in a world without
+
+unique surnames.
+
+
+        cc:  After you have given an address to the `To:'    prompt, you are prompted
+
+for  the  `cc:'    ("carbon  copy"-an  archaism)  address.  It  is  customary,  but  not
+
+required, to put your own address here so that you get a copy of the message when
+
+it is sent.
+
+
+        To put more than one address in the `To:'    and `cc:'    components, just use
+
+a comma (",") between each address on a line.
+
+
+        Subject:  The third prompt is for the `Subject:'        component.  Here a line
+
+of any descriptive text will do.  Once you have typed a line of text, a dashed line
+
+is printed, and you are then expected to type the body of the message.  End the
+
+body with EOT (usually CTRL-D).
+
+
+        An example of a complete message draft, as it appears on your screen, might
+
+be:
+
+
+           To:   News
+
+           cc:   farber,  mrose
+
+           Subject:   UCI  Software  Talk
+
+           --------
+
+           A  presentation  on  the  UCI  software  suite,  including
+
+           the  Rand/UCI  Mail  Handling  System  (MH),  will  be  given
+
+           in  CS220  on  October  31st  at  2:30  PM.  Refreshments
+
+           will  be  served  afterward.
+
+
+
+           /mtr
+
+           ^D
+
+
+(The "^D" does not appear in the draft.)
+                                                                                                              7
+
+
+        At this point, you are asked
+
+
+           What now?
+
+
+This is known as being at What  now?  level.  For now, there are probably only four
+
+options that will interest you:
+
+
+         edit  - edit the draft
+
+
+          list - list the draft on your screen
+
+
+        quit   - quit, without sending the draft
+
+
+        send   - send the draft, then quit
+
+
+
+All of these options take various arguments, but only edit really needs an argument.
+
+
+        Edit:  The edit option will let you edit the draft before sending it.  If your
+
+favorite text editor is vi, then you would use the edit option as:
+
+
+           edit vi
+
+
+Just specifying edit with no argument will only let you append text to the body
+
+of the message draft.  Another editor (e.g.  vi, ex, emacs ) should really be run to
+
+finish the draft up.  When you leave the editor, you will come back to the What
+
+now?  level, where you can re-edit the draft, send it, list it, or simply quit without
+
+sending the draft at all.
+
+
+        Caution:  while in the editor, you should not delete colons in the headers or
+
+change the spelling of `To:'   , `cc:'   , or `Subject:'      ; and do not leave blank lines
+
+between these lines.  Feel free to change the addresses that you typed previously, or
+
+to add these lines if they are missing.  Do not delete the dashes that separate the
+
+header lines from the text of the message.  You should not add additional header
+
+lines unless you understand precisely what you are doing.  This means particularly
+
+that you should not type or fill in a `From:'      line.  When the message is sent, the
+
+system automatically adds this line.  Also, you should not type a `Date:'      line in
+
+the header.  When the message is sent, the system automatically adds the current
+
+date and time.
+
+
+        Quit:  If you quit without sending the draft, the draft is saved in a file called
+
+Mail/draft      under your home directory.  This file can be recalled later using the
+
+`-use'     argument to comp:
+
+
+           comp -use
+
+
+The What  now?  level will permit you to do further editing and to send the final
+
+draft when you are ready.
+                                                                                                              8
+
+
+        Send:  When it is time to send the draft on its way, use the send option by
+
+itself.  If there are any problems with the draft (for example, if one or more of the
+
+people whom you specified in the `To:'    and `cc:'    components do not exist) then
+
+you will be notified at this time.
+
+
+Replying to Messages
+
+        To reply to a message, use the repl command.  For example,
+
+
+           repl
+
+
+creates a reply to the current message.  You may also reply to a specific message
+
+(other than the current one) by giving a message number (e.g.  `1' , `4'  , etc.)  or a
+
+message name (e.g.  `first'    , `last'    , `prev'    ):
+
+
+           repl prev
+
+
+We haven't really introduced message numbers yet.  They will be discussed in the
+
+next section.
+
+
+        The process of replying to a message is very similar to composing a message
+
+from  scratch  (see  the  previous  section),  but  repl  conveniently  constructs  and
+
+displays the header of the reply draft for you.  You need only type in the text of
+
+the reply.  An EOT (usually CTRL-D) indicates that you are done typing.  If you
+
+make a mistake, you may correct it later with a text editor.  The draft will be sent
+
+only if you give an explicit send command, so you do not have to worry about the
+
+draft getting away from you prematurely.
+
+
+        An example of a complete reply draft, as it appears on your screen might be:
+
+
+           To:   MRose
+
+           cc:   JSweet
+
+           Subject:   Re:   UCI  Software  Talk
+
+           In-reply-to:   Your  message  of  10  Oct  84  18:15:08  PDT  (Wed).
+
+           --------
+
+           I'll  be  there.
+
+           -jns
+
+           ^D
+
+
+(The "^D" does not appear in the draft.)
+
+
+        At this point, you are asked
+
+
+           What now?
+
+
+This is known as being at What  now?  level.  Refer to the previous section regarding
+
+how to edit, display, or send the draft at this point.
+                                                                                                              9
+
+
+        As with comp, if you quit without sending the reply draft, the draft is saved
+
+in a file called Mail/draft     under your home directory.  This file can be recalled later
+
+using the `-use'     argument to comp:
+
+
+           comp -use
+
+
+The What  now?  level will permit you to do further editing and to send the final
+
+draft when you are ready.
+
+
+
+Scanning Messages
+
+        The scan listing created by inc shows the message number, the date on which
+
+the  message  was  sent,  the  sender,  and  the  subject  of  the  message.  If  there  is
+
+sufficient space remaining on the line, the beginning of the text of the message is
+
+displayed as well, preceded by two left angle brackets (" <<").  An example of a
+
+scan listing is:
+
+    1+   10/10     WESTINE% USC-ISIF       RFC  916  Now  Available          <<A  new  Request  for  Co
+    2    10/10     G  B  Reilly            Gosling  EMACS  manual            <<Marshall,  I  am  lookin
+    3    10/11     WESTINE% USC-ISIF       Internet  Monthly  Report
+
+
+Note that all messages have message numbers.
+
+
+        To generate your own scan listing, use the scan program.  Typing simply
+
+
+           scan
+
+
+will list all the messages in the current folder.  To scan a subset of these messages,
+
+you can specify the numbers of the messages that you consider interesting, e.g.,
+
+
+           scan 2 3
+
+
+Message names may be specified in addition to discrete message numbers.  The
+
+built-in message names recognized by MH are:
+
+
+         all_: all messages in the folder (`first-last'        )
+
+
+       first_: the first message in the folder
+
+
+        last_: the last message in the folder
+
+
+       prev__: the message immediately before the current message
+
+
+        cur__: the current message
+
+
+       next__: the message immediately after the current message
+                                                                                                            10
+
+
+        Message ranges may be specified in addition to discrete message numbers or
+
+names by separating the beginning and final message numbers with a dash ("-").
+
+For example,
+
+
+           scan 5-10
+
+
+scans messages 5 through 10 inclusive.  A range of messages may also be specified
+
+by separating a beginning message number and a relative number of messages with
+
+a colon (":").  For example,
+
+
+           scan last:3
+
+
+scans the last three messages in the folder.  Similarly,
+
+
+           scan first:3
+
+
+scans the first three messages in the folder;
+
+
+           scan next:3
+
+
+scans the next three messages;
+
+
+           scan cur:3
+
+
+scans the three messages beginning from the current message;
+
+
+           scan 100:4
+
+
+scans four messages beginning from message number 100.
+
+
+        To  summarize,  the  important  concepts  that  have  been  discussed  in  the
+
+section are:  message ranges, message numbers, and message names.  When an MH
+
+command is described as taking a `msg'     argument,  it accepts either a message
+
+name or a message number.  Most MH commands are described as taking `msgs'
+
+arguments, meaning that more than one message or message range is accepted.
+
+
+
+Deleting Messages
+
+        To delete a message,  use the rmm program.  By default,  rmm deletes the
+
+current message, but you can give rmm a list of messages to be removed as well.
+
+There is no corresponding "unrmm" program, but clever users with a need will
+
+find out how to change the way rmm works so that it simply moves messages to
+
+another folder (say, `+wastebasket'         ).
+                                                                                                            11
+
+
+Filing Messages
+
+        The possibility of having folders other than ``+inbox''       has been mentioned
+
+previously.  The methods for moving messages between folders and manipulating
+
+folders are discussed here.
+
+
+        The  refile  command  moves  messages  from  a  source  folder  to  one  or  more
+
+destination  folders.  By default,  the current message is moved from the current
+
+folder (typically `+inbox'     ) to another folder specified as an argument to refile.
+
+For example,
+
+
+           refile +todo
+
+
+moves the current message from the current folder to the folder ``+todo''      .  To
+
+move messages from a folder other than the current folder, use the `-src  +folder'
+
+switch, as in
+
+
+           refile -src +todo last +save +notes
+
+
+which moves the last message in the ``+todo''       folder to the folders ``+save''
+
+and ``+notes''      .  Note that this operation is a move, not a copy; it removes the
+
+message from the source folder.  To keep a copy in the source folder as well, use the
+
+`-link'      switch
+
+
+           refile -link -src +todo last +save +notes
+
+
+
+        Whenever a folder argument is given to an MH command, that folder becomes
+
+the current folder.  To find out which folder is current, use the command
+
+
+           folder
+
+
+The inc command sets the current folder back to `+inbox'      by default.  To find out
+
+about all of a user's folders, use the command
+
+
+           folders
+
+
+Since folders can contain other folders, the command
+
+
+           folders -recurse
+
+
+will recursively examine each folder for you.
+
+
+        To set the current folder, without doing anything else, use the folder program
+
+with a folder argument.  Hence,
+
+
+           folder +inbox
+
+
+makes ``+inbox''       the current folder.
+                                                                                                                   12
+
+
+               After a using rmm and refile on a folder a number of times, there tend to be
+
+       gaps in the numbering sequence.  To compress the numbers for the all messages in
+
+       a folder, use
+
+
+                  folder -pack
+
+
+
+       The Profile
+
+               You  can  customize  the  MH  environment  by  editing  your  .mh_profile    file.
+
+       Although there are lots of options, here are the most useful:
+
+
+           Editor___: lists the default editor that comp and repl should use.  The default is
+
+
+                          editor: prompter
+
+
+                      but another editor might be preferred.
+
+
+     editor-next____: lists the editor that should be used after the last edit with editor.  Hence,
+
+                      if you have a profile entry
+
+
+                          prompter-next: vi
+
+
+                      after editing a draft with prompter, and being at What  now?  level, you
+
+                      could say ``edit''      (instead of ``edit  vi''      ) to continue to edit the
+
+                      draft with vi.
+
+
+   Msg-Protect________:Whenever MH creates a message (for example,  with inc),  this is the
+
+                      octal protection mode that the message is created with.  The default is
+
+
+                          Msg-Protect: 644
+
+
+                      This  protection  mode  permits  all  other  users  on  the  system  to  read
+
+                      your  messages.  To  maintain  privacy,  the  mode  600  should  be  used.
+
+                      Note that changing the mode in the profile does not change the modes
+
+                      of messages that have been created already.  Use the UNIX command
+
+                      chmod to change the modes of your existing messages.
+
+
+Folder-Protect______________:Whenever  MH  creates  a  folder  (for  example,  with  refile),  this  is  the
+
+                      octal mode that the folder is created with.  The default is
+
+
+                          Folder-Protect: 711
+
+
+                      This mode permits other users on the system to make access to specific
+
+                      messages in your folders.  To maintain stricter privacy, the mode 700
+
+                      should be used.
+                                                                                                            13
+
+
+  program____: Each MH program that reads user's .mh_profile     file looks for an entry
+
+               beginning  with  its  own  name  to  determine  its  initial  defaults.   For
+
+               example, if you want the default editor for repl to be emacs, the line
+
+
+                   repl: -editor emacs
+
+
+               is sufficient.  Command line arguments tend to override profile settings.
+
+               Given the profile setting for repl above, if you invoked repl with
+
+
+                   repl -editor vi
+
+
+               repl would use the vi editor instead of emacs.
+
+
+signature____: When MH posts mail for you,  it looks for this profile entry for your
+
+               "real world" name.  For example,
+
+
+                   signature: Marshall Rose
+
+
+               The contents of the ``signature:''          entry in the profile should be a
+
+               simple phrase, with no embedded periods (e.g.  "Marshall T. Rose").
+
+
+
+Note that your profile resembles the header portion of a message.  Be sure that it is
+
+properly formatted by placing a colon after each entry name, and keep each entry
+
+on a single line.
+
+
+
+Conventions
+
+        Now let's summarize the conventions that MH programs use:
+
+
+           1.  Any MH command that deals with messages can be given a `+folder'
+
+               argument  to  say  which  folder  to  use.  However,  only  one  `+folder'
+
+               argument may be given per command in most cases.
+
+
+           2.  If an MH command accepts a `msgs'     argument, then any number of
+
+               messages can be given to the command.  The MH command will expand
+
+               all  the  ranges  and  process  each  message,  starting  with  the  lowest
+
+               numbered  one  and  working  its  way  to  the  message  with  the  highest
+
+               number.
+
+
+           3.  If an MH command accepts a `msg'    argument, then at most one message
+
+               can be given.
+
+
+           4.  Switches  (options)  to  MH  commands  start  with  a  dash.  Unlike  the
+
+               standard  UNIX  convention,  each  switch  consists  of  more  than  one
+
+               character, for example `-header'      .  To minimize typing, only a unique
+
+               abbreviation of the switch need be typed; thus for `-header'      , `-hea'
+
+               is probably sufficient, depending on the other switches accepted by the
+
+               command.
+                                                                                                                 14
+
+
+                5.  All  MH  commands  have  a  `-help'     switch,  which  must  be  spelled
+
+                    out fully.  When an MH command encounters the `-help'      switch, it
+
+                    prints  out  the  syntax  of  the  command,  the  switches  that  it  accepts,
+
+                    and version information.  In the list of switches, parentheses indicate
+
+                    required characters.  For example, all `-help'      switches will appear as
+
+                    `-(help)'      , indicating that no abbreviation is accepted.
+
+
+                6.  Many MH switches have both on and off forms, such as `-format'       and
+
+                    `-noformat'       .  In these cases, the last occurrence of the switch on the
+
+                    command line determines the setting of the option.
+
+
+                7.  All MH commands that read your MH profile operate the same way:
+
+                    first_, the profile is consulted for an entry matching the name with which
+
+                    the command was invoked; second___, if such an entry was found, then the
+
+                    command immediately uses the arguments listed; third__, any arguments
+
+                    on the command line are then interpreted.  Since most switches have
+
+                    both on and off forms, it's easy to customize the default options for each
+
+                    MH command in the .mh_profile    , and to override those defaults on the
+
+                    command line.
+
+
+
+     Online Documentation
+
+             Each  MH  program  has  its  own  UNIX  manual  entry.  For  example,  to  get
+
+     information about comp, type
+
+
+                man comp
+
+
+     The manual entry for mh(1) lists all MH commands, while the manual entry for
+
+     mh-chart (1) lists the syntax and switches for all MH commands.
+
+
+             In addition, here are a few other manual entries might be found useful:
+
+
+   mh-alias (5)     to find out how aliases in MH work;
+
+
+   mh-mail (5)      to find out how MH stores and interprets messages (this manual entry
+
+                    explains all of the standard header components);
+
+
+mh-profile(5)       to find out about the MH user-environment.
+
+
+             The  manual  pages  for  MH  are  in  the  standard  UNIX  format,  but  contain
+
+     additional sections unique to MH. Here's a summary of the sections one might find
+
+     in an MH manual entry:
+
+
+          Name      command name and one-line description.
+
+
+     Synopsis       syntax of the command.
+
+                    All commands accept a `-help'      switch.
+                                                                                                                  15
+
+
+Description          semantics of the command.
+
+
+            Files    files used by the command
+
+                     Almost always this includes .mh_profile    .
+
+
+       Profile       entries in the .mh_profile     used by the command;
+
+Components           these do not include the profile entry for the command itself.
+
+
+     See Also        other UNIX manual entries (usually MH programs) that are related to
+
+                     this command.
+
+
+     Defaults        default arguments for the command
+
+                     If  the  command  takes  a  `+folder'      argument,  this  defaults  to  the
+
+                     current folder.  If the command takes a `msg'     argument, this defaults
+
+                     to the current message.  If the command takes a `msgs'     argument, this
+
+                     defaults to the current message or all messages, depending on which one
+
+                     makes more sense.
+
+
+      Context        changes to your MH context made by the command.
+
+
+           Hints     Helpful hints discussing the easy way to do things.
+
+
+       History       A historical perspective on why MH works the way it does.
+
+
+            Bugs     Too embarrassing to mention.
+
+                     Just kidding.
+
+
+
+      Obviously, not all MH manual entries may have all of these sections.
+
+
+
+      Reporting Problems
+
+              If problems are encountered with an MH program, the problems should be
+
+      reported to the local maintainers of MH. When doing this, the name of the program
+
+      should be reported, along with the version information for the program.  To find
+
+      out what version of an MH program is being run,  invoke the program with the
+
+      `-help'      switch.  In addition to listing the syntax of the command, the program
+
+      will list information pertaining to its version.  This information includes the version
+
+      of MH, the host it was generated on, the date the program was loaded, and the
+
+      configuration options in effect when MH was generated.  For example,
+
+
+                 version:   MH  6.1  #1[UCI]  (gremlin)  of  Wed  Nov  6  01:13:53  PST  1985
+
+                 options:   [BSD42]  [MHE]  [NETWORK]  [SENDMTS]  [MMDFII]  [SMTP]  [POP]
+
+
+      The  ``6.1 # 1[UCI]''          indicates  that  the  program  is  from  the  UCI  mh.6
+
+      version  of  MH.  The  program  was  generated  on  the  host  ``gremlin''        on
+
+      ``Wed  Nov  6  01:13:53  PST  1985''              .  It's usually a good idea to send the output
+
+      of the `-help'      switch along with your report.
+                                                                                                            16
+
+
+        If there is no local MH maintainer, try the address Bug-MH. If that fails, use
+
+the Internet mailbox Bug-MH@UCI.ARPA.
+
+
+
+More on MH
+
+        There are myriad aspects of MH that this tutorial hasn't touched upon.  Here
+
+are a few to whet your appetite:
+
+
+           1.  user-defined sequences
+
+               Define meaningful message names and shorten type-in considerably (see
+
+               pick (1) for details).
+
+
+           2.  draft folders
+
+               Maintain a folder of drafts so that more than one draft can be edited
+
+               at a time,  and allow a draft to be edited over several UNIX sessions
+
+               independently of other drafts (see the Advanced Features section of
+
+               the MH user's manual for details).
+
+
+           3.  draft pushing
+
+               Post a draft in the background and immediately free your terminal for
+
+               other activities (see the Advanced Features section of the MH user's
+
+               manual for details).
+
+
+           4.  aliases
+
+               Maintain one or more alias files containing the addresses of the people
+
+               frequently (or infrequently) sent to.  This lets you shorten type-in of
+
+               addressees and saves you from looking up their addresses all the time.
+
+               (see mh-alias (5) for details).
+                                                                                                            17
+
+
+                                               References
+
+
+
+[MRose84]        M.T.  Rose.   The  Rand  MH  Message  Handling  System:  The  UCI
+
+                 BBoards Facility. Department of Computer and Information Sciences,
+
+                 University of Delaware (October, 1984).
+
+
+
+[MRose85a]       M.T. Rose, J.L. Romine.  The Rand MH Message Handling System:
+
+                 User's Manual. UCI Version. Department of Information and Computer
+
+                 Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85b]       M.T. Rose.  The Rand MH Message Handling System: Administrator's
+
+                 Guide. UCI Version, MH Classic. Northrop Corporation, Research and
+
+                 Technology Center (July, 1985).
+
+
+
+[SPayn85]        S.  Payne   MH5:  Electronic  Mail.  Rand  Note  #N-2281-RCC.  The
+
+                 Rand Computation Center, Rand, 1700 Main St., Santa Monica, CA
+
+                 90406-2138 (May, 1985).
+
+
+
+
+                                                 Contents
+
+
+
+                                                                                                          Page
+
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       1
+
+ How To Use This Tutorial  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
+
+ Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2
+
+ Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       3
+
+ Messages and Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       3
+
+ Reading New Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       4
+
+ Sending Messages  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
+
+         Originating Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
+
+         Replying to Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       8
+
+ Scanning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       9
+
+ Deleting Messages  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      10
+
+ Filing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      11
+
+ The Profile  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
+
+ Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      13
+
+ Online Documentation  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      14
+
+ Reporting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      15
+
+ More on MH  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      16
+
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      17
+
+
+
+ _____________________________________
+This document (version #2.8) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+                                                        i