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

[mmh] / docs / historical / ADMIN.txt

                                            _\bd_\bi_\bs_\bc_\ba_\br_\bd _\bt_\bh_\bi_\bs _\bp_\ba_\bg_\be




                                               The RAND _\bM_\bH
                                             Message Handling
                                                 System:
                                          Administrator's Guide

                                               UCI Version


                                            November 30, 1993
                                              6.8.3 #1[UCI]


















































                                             _\b1. _\bI_\bN_\bT_\bR_\bO_\bD_\bU_\bC_\bT_\bI_\bO_\bN







                 _\bS_\bc_\bo_\bp_\be _\bo_\bf _\bt_\bh_\bi_\bs _\bd_\bo_\bc_\bu_\bm_\be_\bn_\bt

                      This is the Administrator's Guide to _\bM_\bH.  If you don't maintain  an
                 _\bM_\bH  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:



                           _\bT_\bh_\bi_\bs _\bd_\bo_\bc_\bu_\bm_\be_\bn_\bt _\bw_\bi_\bl_\bl _\bn_\be_\bv_\be_\br _\bc_\bo_\bn_\bt_\ba_\bi_\bn _\ba_\bl_\bl _\bt_\bh_\be _\bi_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn
                                         _\by_\bo_\bu _\bn_\be_\be_\bd _\bt_\bo _\bm_\ba_\bi_\bn_\bt_\ba_\bi_\bn _\bM_\bH.

                         _\bF_\bu_\br_\bt_\bh_\be_\br_\bm_\bo_\br_\be, _\bt_\bh_\bi_\bs _\bd_\bo_\bc_\bu_\bm_\be_\bn_\bt _\bw_\bi_\bl_\bl _\bn_\be_\bv_\be_\br _\bc_\bo_\bn_\bt_\ba_\bi_\bn _\be_\bv_\be_\br_\by_\bt_\bh_\bi_\bn_\bg
                                       _\bI _\bk_\bn_\bo_\bw _\ba_\bb_\bo_\bu_\bt _\bm_\ba_\bi_\bn_\bt_\ba_\bi_\bn_\bi_\bn_\bg _\bM_\bH.



                 _\bM_\bH, and mailsystems in general, are more complex than most people  real-
                 ize.   A  combination of experience, intuition, and tenacity is required
                 to maintain _\bM_\bH properly.  This document can provide only guidelines  for
                 bringing  up  an  _\bM_\bH  system  and maintaining it.  There is a sufficient
                 amount of customization possible that not all events or problems can  be
                 forseen.



                 _\bS_\bu_\bm_\bm_\ba_\br_\by

                      During _\bM_\bH generation, you specify several  configuration  constants
                 to  the _\bm_\bh_\bc_\bo_\bn_\bf_\bi_\bg 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  _\bm_\bh-_\bg_\be_\bn (8)  describes  all  the static configuration
                 directives.

                      However,  when  you  install  _\bM_\bH  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   _\bM_\bH,   you'll   want   to   edit   the
                 /usr/local/lib/mh/mtstailor  file.   This  file  fine-tunes  the  way _\bM_\bH
                 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 _\bU_\bU_\bC_\bP 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  _\bM_\bH  source  tree.
                 Section 6 talks (a little bit) about that.

                      The last two sections describe a few hidden features in _\bM_\bH, and the
                 configuration options that were in effect when this guide was generated.

                      After _\bM_\bH is installed, you should define the  address  "Bug-MH"  to
                 map to either you or the _\bP_\bo_\bs_\bt_\bM_\ba_\bs_\bt_\be_\br at your site.

                      In addition, if you want to tailor  the  behavior  of  _\bM_\bH  for  new
                 users,  you  can  create and edit the file /usr/local/lib/mh/mh.profile.
                 When the _\bi_\bn_\bs_\bt_\ba_\bl_\bl-_\bm_\bh program is run for a user, if this file  exists,  it
                 will copy it into the user's .mh_profile file.






































                                           _\b2. _\bT_\bH_\bE _\bM_\bT_\bS _\bI_\bN_\bT_\bE_\bR_\bF_\bA_\bC_\bE





                      The    file    /usr/local/lib/mh/mtstailor    customizes    certain
                 host-specific  parameters  of  _\bM_\bH related primarily to interactions with
                 the  transport  system.   The  parameters  in  this  file  override  the
                 compiled-in  defaults given during _\bM_\bH configuration.  Rather than recom-
                 piling _\bM_\bH 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  _\bc_\bo_\bn_\bf_\bl_\bi_\bc_\bt (8)  program  each  morning
                 under _\bc_\br_\bo_\bn.  The following line usually suffices:

                      00 05 * * * /usr/local/lib/mh/conflict -mail PostMaster



































                                              -3-









            MH-TAILOR(5)                      -4-                       MH-TAILOR(5)


            _\bN_\bA_\bM_\bE
                 mh-tailor, mtstailor - system customization for MH message handler


            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /_\bu_\bs_\br/_\bl_\bo_\bc_\ba_\bl/_\bl_\bi_\bb/_\bm_\bh/_\bm_\bt_\bs_\bt_\ba_\bi_\bl_\bo_\br

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The file /usr/local/lib/mh/mtstailor defines run-time  options  for
                 those  _\bM_\bH  programs  which interact (in some form) with the message
                 transport system.  At present, these (user) programs are: _\ba_\bp,  _\bc_\bo_\bn_\b-
                 _\bf_\bl_\bi_\bc_\bt, _\bi_\bn_\bc, _\bm_\bs_\bg_\bc_\bh_\bk, _\bm_\bs_\bh, _\bp_\bo_\bs_\bt, _\br_\bc_\bv_\bd_\bi_\bs_\bt, and _\br_\bc_\bv_\bp_\ba_\bc_\bk.

                 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 _\bM_\bH considers local.  If not  set,  depending  on
                      the  version  of UNIX you're running, _\bM_\bH will query the system
                      for this value (e.g., <whoami.h>,  gethostname,  etc.).   This
                      has  no  equivalent  in the _\bM_\bH 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 _\bM_\bH 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 _\bU_\bU_\bC_\bP "domain".  If not  set,
                      depending on the version of UNIX you're running, _\bM_\bH will query
                      the system for this value.  This has no equivalent in  the  _\bM_\bH
                      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 _\bM_\bH 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 _\bM_\bH 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 _\bM_\bH 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  _\bB_\be_\bl_\bl_\bM_\ba_\bi_\bl  locking  is used.  A value of "1" means to
                      use _\bB_\be_\bl_\bl_\bM_\ba_\bi_\bl locking always (the name of the lock is based  on
                      the  file  name).   A  value  of "2" means to use _\bM_\bM_\bD_\bF 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 ._\bm_\ba_\bi_\bl_\bd_\be_\bl_\bi_\bv_\be_\br_\by  file.   See
                      _\bm_\bh_\bo_\bo_\bk (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.

              _\bM_\ba_\bi_\bl _\bF_\bi_\bl_\bt_\be_\br_\bi_\bn_\bg

                 These  options  are  only  available  if  you  compiled   _\bM_\bH   with
                 "options MF".

                 uucpchan: name of _\bU_\bU_\bC_\bP channel
                      Usually "UUCP".  This has no equivalent in the  _\bM_\bH  configura-
                      tion file.

                 uucpldir: /usr/spool/mail
                      The name of the directory where _\bU_\bU_\bC_\bP maildrops are kept.  This
                      has no equivalent in the _\bM_\bH configuration file.

                 uucplfil:
                      The name of the maildrop file  in  the  directory  where  _\bU_\bU_\bC_\bP
                      maildrops  are  kept.  If this is empty, the user's login name
                      is used.  This has no equivalent in the _\bM_\bH configuration file.

                 umincproc: /usr/local/lib/mh/uminc
                      The path to the program that filters _\bU_\bU_\bC_\bP-style  maildrops  to
                      _\bM_\bM_\bD_\bF-style maildrops.

              _\bS_\bt_\ba_\bn_\bd-_\bA_\bl_\bo_\bn_\be _\bD_\be_\bl_\bi_\bv_\be_\br_\by

                 These options are only available if you compiled _\bM_\bH 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 _\bm_\bk_\bt_\be_\bm_\bp template for storing from lines.

                 msgtmp: /tmp/rml.m.XXXXXX
                      The _\bm_\bk_\bt_\be_\bm_\bp 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 _\bm_\bk_\bt_\be_\bm_\bp 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.

              _\bT_\bh_\be `/_\bs_\bm_\bt_\bp' _\bM_\bT_\bS _\bS_\bu_\bf_\bf_\bi_\bx

                 These options are only  available  if  you  compiled  _\bM_\bH  with  the
                 "/smtp" suffix to your "mts:" configuration.

                 hostable: /usr/local/lib/mh/hosts
                      The exceptions file for /etc/hosts used by _\bp_\bo_\bs_\bt 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).

              _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl

                 This option is only available if you compiled _\bM_\bH to use _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl as
                 your delivery agent (i.e., "mts: sendmail").

                 sendmail: /usr/lib/sendmail
                      The pathname to the _\bs_\be_\bn_\bd_\bm_\ba_\bi_\bl program.

              _\bP_\bo_\bs_\bt _\bO_\bf_\bf_\bi_\bc_\be _\bP_\br_\bo_\bt_\bo_\bc_\bo_\bl


            [mh.6]                           MH.6.8                      UCI version









            MH-TAILOR(5)                      -8-                       MH-TAILOR(5)


                 This option is only available if you compiled _\bM_\bH with  POP  support
                 enabled (i.e., "pop: on").

                 pophost:
                      The name of the default POP service host.  If this is not set,
                      then _\bM_\bH looks in the standard maildrop areas for waiting mail,
                      otherwise the named POP service host is consulted.

              _\bB_\bB_\bo_\ba_\br_\bd_\bs _\bD_\be_\bl_\bi_\bv_\be_\br_\by

                 This  option  is  only  available   if   you   compiled   _\bM_\bH   with
                 "bbdelivery: on".

                 bbdomain:
                      The local BBoards domain (a UCI hack).

              _\bB_\bB_\bo_\ba_\br_\bd_\bs & _\bT_\bh_\be _\bP_\bO_\bP

                 These  options  are  only  available  if  you  compiled   _\bM_\bH   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.

              _\bB_\bB_\bo_\ba_\br_\bd_\bs & _\bT_\bh_\be _\bN_\bN_\bT_\bP

                 This  option  is  only  available   if   you   compiled   _\bM_\bH   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.

              _\bF_\bi_\bl_\be _\bL_\bo_\bc_\bk_\bi_\bn_\bg

                 A few words on locking: _\bM_\bH 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, _\bM_\bH assumes you have the _\bf_\bl_\bo_\bc_\bk  system  call.
                 On  other systems: define FLOCK if you want to use the _\bf_\bl_\bo_\bc_\bk system
                 call; define LOCKF if you want to use the  _\bl_\bo_\bc_\bk_\bf  system  call;  or
                 define  FCNTL  if you want to use the _\bf_\bc_\bn_\bt_\bl system call for kernel-
                 level locking.  If you haven't configured _\bM_\bH  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 _\bM_\bH,  you  should  see
                 how locking is done at your site, and set the appropriate values.

            _\bF_\bi_\bl_\be_\bs
                 /usr/local/lib/mh/mtstailor         tailor file


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 mh-gen(8), mh-mts(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 As listed above


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None












            [mh.6]                           MH.6.8                      UCI version









            MH-MTS(8)                         -10-                         MH-MTS(8)


            _\bN_\bA_\bM_\bE
                 mh-mts - the MH interface to the message transport system

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 SendMail

                 Zmailer

                 MMDF (any release)

                 stand-alone

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 _\bM_\bH can use a wide range of message  transport  systems  to  deliver
                 mail.   Although the _\bM_\bH 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 _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl, _\bM_\bH always uses the SMTP  to  post
                 mail.   Depending  on the _\bM_\bH configuration, _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl may be invoked
                 directly (via a _\bf_\bo_\br_\bk and an _\be_\bx_\be_\bc), or _\bM_\bH may open a TCP/IP  connec-
                 tion to the SMTP server on the localhost.

                 When communicating with _\bz_\bm_\ba_\bi_\bl_\be_\br, the _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl compatibility program
                 is  required  to  be  installed  in /usr/lib.  _\bM_\bH communicates with
                 _\bz_\bm_\ba_\bi_\bl_\be_\br  by  using  the  SMTP.   It  does  this  by  invoking   the
                 /usr/lib/sendmail  compatibility  program  directly, with the `-bs'
                 option.

                 When communicating with _\bM_\bM_\bD_\bF, normally _\bM_\bH uses the  "mm_"  routines
                 to  post  mail.   However,  depending  on  the _\bM_\bH configuration, _\bM_\bH
                 instead may open a TCP/IP connection to  the  SMTP  server  on  the
                 localhost.

                 When using the stand-alone system (NOT  recommended),  _\bM_\bH  delivers
                 local  mail  itself  and queues _\bU_\bU_\bC_\bP 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 _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl
                 or _\bM_\bM_\bD_\bF with the SMTP option.  This gives greater flexibility.   To
                 enable this option you append the /smtp suffix to the mts option in
                 the _\bM_\bH configuration.  This yields two primary  advantages:  First,
                 you  don't  have to know where _\bs_\bu_\bb_\bm_\bi_\bt or _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl live.  This means
                 that _\bM_\bH binaries (e.g., _\bp_\bo_\bs_\bt ) 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 _\bM_\bM_\bD_\bF or _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl on your local host.  Big win in
                 conserving cycles and disk space.  Since _\bM_\bH 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 _\bM_\bM_\bD_\bF
                 or _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl.  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, _\bM_\bH 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, _\bM_\bH ignores the hosts file altogether).

            _\bF_\bi_\bl_\be_\bs
                 /usr/local/lib/mh/mtstailor         tailor file


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 _\bM_\bM_\bD_\bF-_\bI_\bI: _\bA _\bT_\be_\bc_\bh_\bn_\bi_\bc_\ba_\bl _\bR_\be_\bv_\bi_\be_\bw, Proceedings, Usenix Summer '84 Confer-
                 ence
                 _\bS_\bE_\bN_\bD_\bM_\bA_\bI_\bL -- _\bA_\bn _\bI_\bn_\bt_\be_\br_\bn_\be_\bt_\bw_\bo_\br_\bk _\bM_\ba_\bi_\bl _\bR_\bo_\bu_\bt_\be_\br
                 mh-tailor(8), post(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None


            _\bB_\bu_\bg_\bs
                 The /usr/local/lib/mh/mtstailor file ignores the information in the
                 _\bM_\bM_\bD_\bF-_\bI_\bI tailoring file.  It should not.








                 [mh.6]                           MH.6.8                      UCI version












                                                _\b3. _\bB_\bB_\bO_\bA_\bR_\bD_\bS





                      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".


                 _\bB_\bB_\bo_\ba_\br_\bd _\bD_\be_\bl_\bi_\bv_\be_\br_\by

                      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 _\bM_\bH 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 _\bM_\bH.
                 By  using  this  file,  users of _\bM_\bH 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 _\bb_\bb_\bt_\ba_\br 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).


                 _\bB_\bB_\bo_\ba_\br_\bd_\bs _\bw_\bi_\bt_\bh _\bt_\bh_\be _\bP_\bO_\bP

                      If you configured _\bM_\bH with "bboards: pop" and "pop: on", then the _\bM_\bH
                 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 _\bb_\bb_\bc
                 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").


                 _\bB_\bB_\bo_\ba_\br_\bd_\bs _\bw_\bi_\bt_\bh _\bt_\bh_\be _\bN_\bN_\bT_\bP

                      If you configured _\bM_\bH with "bboards: nntp" and "pop: on",  then  the
                 _\bM_\bH  user  is  allowed to read the Network News on a server machine using
                 the standard _\bb_\bb_\bc 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 _\bb_\bb_\bc 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)


            _\bN_\bA_\bM_\bE
                 BBoards - BBoards database

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/spool/bboards/BBoards

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The BBoards database contains for each BBoard the following  infor-
                 mation:

                 _\bf_\bi_\be_\bl_\bd               _\bv_\ba_\bl_\bu_\be
                 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 _\bp_\ba_\bs_\bs_\bw_\bd (5) file,
                                     or groupnames preceded by `=' from the
                                     _\bg_\br_\bo_\bu_\bp (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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/bboards/BBoards          BBoards database


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bbaka(8), bbexp(8), bboards (8), bbtar(8)


            _\bB_\bu_\bg_\bs
                 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 _\bv_\bi_\bb_\bb program
                 is needed.


            [mh.6]                           MH.6.8                      UCI version









            BBOARDS(5)                        -16-                        BBOARDS(5)


            _\bN_\bA_\bM_\bE
                 bbaka - generate an alias list for BBoards

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/spool/bboards/bbaka [system]

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bb_\bb_\ba_\bk_\ba program reads the BBoards database and  produces  on  its
                 standard output a file suitable for inclusion in either the _\bM_\bM_\bD_\bF-_\bI_\bI
                 aliases file (if the argument `system' is given).  If the  argument
                 is  not  given,  then  _\bb_\bb_\ba_\bk_\ba produces on its standard output a file
                 suitable for becoming the /usr/local/lib/mh/BBoardsAliases file.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/bboards/BBoards          BBoards database
                 /usr/local/lib/mh/BBoardsAliases    BBoards aliases file for _\bM_\bH


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bboards(5)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None




















            [mh.6]                           MH.6.8                      UCI version









            BBEXP(8)                          -17-                          BBEXP(8)


            _\bN_\bA_\bM_\bE
                 bbexp - expunge the BBoards area

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/spool/bboards/bbexp [-_\bf_\bi_\br_\bs_\bt-_\bm_\be_\bt_\br_\bi_\bc] [-_\bs_\be_\bc_\bo_\bn_\bd-_\bm_\be_\bt_\br_\bi_\bc]
                      [bboards ...]

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bb_\bb_\be_\bx_\bp program reads the  BBoards  database  and  calls  _\bm_\bs_\bh  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 _\bB_\bB_\bo_\ba_\br_\bd_\bs (5) file says.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/bboards/BBoards          BBoards database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 msh(1), bboards(5)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None
















            [mh.6]                           MH.6.8                      UCI version









            BBOARDS(8)                        -18-                        BBOARDS(8)


            _\bN_\bA_\bM_\bE
                 bboards - BBoards channel/mailer

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/mmdf/chans/bboards fd1 fd2 [y]

                 /usr/local/lib/mh/sbboards bboard ...

                 /usr/local/lib/mh/sbboards file maildrop directory bboards.bboard

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 For _\bM_\bM_\bD_\bF, the BBoards channel delivers mail to the BBoards  system.
                 For  _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl and stand-alone _\bM_\bH, the SBBoards mailer performs this
                 task.

                 For each address given, these programs consult the _\bb_\bb_\bo_\ba_\br_\bd_\bs (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 _\bs_\bb_\bb_\bo_\ba_\br_\bd_\bs running under stand-alone _\bM_\bH,
                 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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/local/lib/mh/mtstailor         tailor file
                 /usr/spool/bboards/BBoards          BBoards database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bboards(5), bbaka(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None






            [mh.6]                           MH.6.8                      UCI version









            BBTAR(8)                          -19-                          BBTAR(8)


            _\bN_\bA_\bM_\bE
                 bbtar - generate the names of archive files to be put to tape

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/spool/bboards/bbtar [private] [public]

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bb_\bb_\bt_\ba_\br 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 _\bt_\ba_\br (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 _\bb_\bb_\be_\bx_\bp (8).

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/bboards/BBoards          BBoards database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bboards(5), bbexp(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None








                 [mh.6]                           MH.6.8                      UCI version












                                                  _\b4. _\bP_\bO_\bP





                      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 _\bM_\bH 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 _\bM_\bH 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 _\bi_\bn_\bc
                 and _\bm_\bs_\bg_\bc_\bh_\bk 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
                 _\bM_\bH,      consult      the      files     support/pop/rfc1081.txt     and
                 support/pop/rfc1082.txt which describe the _\bM_\bH version of the POP: POP3.

                      For POP service hosts, you need to run  a  daemon,  _\bp_\bo_\bp_\bd (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 _\bM_\bH POP will try to use, and
                 defaults to the name "pop".

                      To generate _\bM_\bH to use newer assigned port number, in your _\bM_\bH 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  _\bp_\ba_\bs_\bs_\bw_\bd (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  _\bB_\bB_\bo_\ba_\br_\bd_\bs (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.  _\bM_\bH comes with a
                 program, _\bp_\bo_\bp_\ba_\bk_\ba (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 (_\bm_\bh._\b6
                 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 (_\bi_\bn_\bc,  _\bm_\bs_\bg_\bc_\bh_\bk,  and  possibly  _\bb_\bb_\bc )
                 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  _\bs_\be_\bt_\bu_\bi_\bd 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 _\bp_\ba_\bs_\bs_\bw_\bd (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 _\bp_\bo_\bp_\ba_\bk_\ba 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 _\bp_\ba_\bs_\bs_\bw_\bd (5) is consulted; under the second method, the con-
                 tents of the password field for the subscriber's entry  in  the  _\bp_\bo_\bp (5)
                 file is consulted.  (To set this field, the _\bp_\bo_\bp_\bw_\br_\bd (8) program is used.)

                      If you are allowing  RPOP,  under  the  first  method,  the  user's
                 ._\br_\bh_\bo_\bs_\bt_\bs  file is consulted; under the second method, the contents of the
                 network address field for the subscriber's entry in the _\bp_\bo_\bp (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 _\bp_\bo_\bp_\ba_\bu_\bt_\bh (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)


            _\bN_\bA_\bM_\bE
                 POP - POP database of subscribers

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/spool/pop/POP

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The POP database has exactly the same  format  as  the  _\bB_\bB_\bo_\ba_\br_\bd_\bs (5)
                 database,  although  many  fields are unused.  Currently, only four
                 fields are examined:

                 _\bf_\bi_\be_\bl_\bd               _\bv_\ba_\bl_\bu_\be
                 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 _\bp_\bo_\bp_\bw_\br_\bd 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 _\br_\be_\bc_\be_\bi_\bv_\bi_\bn_\bg mail, set the primary
                 file name to the empty string.  To prevent a  POP  subscriber  from
                 _\bp_\bi_\bc_\bk_\bi_\bn_\bg-_\bu_\bp 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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/pop/POP                  POP database

            [mh.6]                           MH.6.8                      UCI version









            POP(5)                            -24-                            POP(5)


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bboards(5), pop(8), popaka(8), popd(8), popwrd(8)


            _\bB_\bu_\bg_\bs
                 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 _\bv_\bi_\bp_\bo_\bp program
                 is needed.











































            [mh.6]                           MH.6.8                      UCI version









            POP(8)                            -25-                            POP(8)


            _\bN_\bA_\bM_\bE
                 pop - POP channel/mailer

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/mmdf/chans/pop fd1 fd2 [y]

                 /usr/local/lib/mh/spop POP-subscriber ...

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 For _\bM_\bM_\bD_\bF-_\bI_\bI, the POP channel delivers mail to the  POP  spool  area
                 for  later  retrieval  by  POP subscribers.  For _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl, the SPOP
                 mailer performs this task.

                 For each address given, these programs consult the _\bp_\bo_\bp (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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/local/lib/mh/mtstailor         tailor file
                 /usr/spool/pop/POP                  POP database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 bboards(5), bbaka(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None















            [mh.6]                           MH.6.8                      UCI version









            POPAKA(8)                         -26-                         POPAKA(8)


            _\bN_\bA_\bM_\bE
                 popaka - generate POP entries for SendMail or MMDF-II alias file

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/local/lib/mh/popaka

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bp_\bo_\bp_\ba_\bk_\ba program reads the POP database and produces on its stan-
                 dard  output  a  file  suitable  for  inclusion  in the SendMail or
                 _\bM_\bM_\bD_\bF-_\bI_\bI aliases file.  The contents of this file  divert  mail  for
                 POP subscribers to the POP channel.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/pop/POP                  POP database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 pop(5)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None






















            [mh.6]                           MH.6.8                      UCI version









            POPAUTH(8)                        -27-                        POPAUTH(8)


            _\bN_\bA_\bM_\bE
                 popauth - manipulate POP authorization DB

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 popauth [-init] [-list] [-user name] [-help]

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bp_\bo_\bp_\ba_\bu_\bt_\bh 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.  _\bp_\bo_\bp_\ba_\bu_\bt_\bh is useful only when the APOP configuration  option  is
                 defined.   (This  configuration  option defines the name of the POP
                 authorization DB.)

                 Under normal usage, _\bp_\bo_\bp_\ba_\bu_\bt_\bh prompts for a new secret, just like the
                 _\bp_\ba_\bs_\bs_\bw_\bd  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).

            _\bF_\bi_\bl_\be_\bs
                 /etc/pop.auth.*                     POP authorization DB


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 popd(8)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None








            [mh.6]                           MH.6.8                      UCI version









            POPD(8)                           -28-                           POPD(8)


            _\bN_\bA_\bM_\bE
                 popd - the POP server

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/etc/popd [-p portno] (under /etc/rc.local)

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bp_\bo_\bp_\bd 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 _\bp_\bo_\bp_\ba_\bu_\bt_\bh(8) for more details.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/pop/POP                  POP database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 _\bP_\bo_\bs_\bt _\bO_\bf_\bf_\bi_\bc_\be _\bP_\br_\bo_\bt_\bo_\bc_\bo_\bl - _\bv_\be_\br_\bs_\bi_\bo_\bn _\b3 (aka RFC-1081),
                 _\bP_\bo_\bs_\bt _\bO_\bf_\bf_\bi_\bc_\be  _\bP_\br_\bo_\bt_\bo_\bc_\bo_\bl  -  _\bv_\be_\br_\bs_\bi_\bo_\bn  _\b3:  _\bE_\bx_\bt_\be_\bn_\bd_\be_\bd  _\bs_\be_\br_\bv_\bi_\bc_\be  _\bo_\bf_\bf_\be_\br_\bi_\bn_\bg_\bs
                 (RFC-1082),
                 pop(5)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None












            [mh.6]                           MH.6.8                      UCI version









            POPD(8)                           -29-                           POPD(8)


            _\bH_\bi_\bs_\bt_\bo_\br_\by
                 For historical reasons, the _\bM_\bH 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)


            _\bN_\bA_\bM_\bE
                 popwrd - set password for a POP subscriber

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/local/lib/mh/popwrd POP-subscriber

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The _\bp_\bo_\bp_\bw_\br_\bd 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 _\bp_\ba_\bs_\bs_\bw_\bd (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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/pop/POP                  POP database


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 pop(5)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None


            _\bB_\bu_\bg_\bs
                 Although _\bp_\bo_\bp_\bw_\br_\bd does locking against other invocations  of  _\bp_\bo_\bp_\bw_\br_\bd,
                 editor  locking for the POP database in general is not implemented.
                 A _\bv_\bi_\bp_\bo_\bp program is needed.











                 [mh.6]                           MH.6.8                      UCI version












                                            _\b5. _\bM_\bA_\bI_\bL _\bF_\bI_\bL_\bT_\bE_\bR_\bI_\bN_\bG





                      There was a time when users on a UNIX host might have had two mail-
                 drops:  one  from  _\bM_\bM_\bD_\bF  and the other from _\bU_\bU_\bC_\bP.  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 _\bm_\ba_\bi_\bl _\bf_\bi_\bl_\bt_\be_\br_\bi_\bn_\bg was developed that allowed
                 sophisticated munging and relaying between the two pseudo-domains.

                      _\bM_\bH will perform mail filtering, transparently, if given the MF con-
                 figuration  option.   However,  with  the advent of _\bS_\be_\bn_\bd_\bM_\ba_\bi_\bl and further
                 maturation of _\bM_\bM_\bD_\bF, _\bM_\bH 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 _\bi_\bs difficult.
































                                              -31-









            MF(1)                             -32-                             MF(1)


            _\bN_\bA_\bM_\bE
                 muinc, musift, uminc, umsift - mail filters

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 /usr/local/lib/mh/muinc

                 /usr/local/lib/mh/musift [files ...]

                 /usr/local/lib/mh/uminc

                 /usr/local/lib/mh/umsift [files ...]

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 The mail filters are a set of programs that filter  mail  from  one
                 format  to another.  In particular, _\bU_\bU_\bC_\bP- and _\bM_\bM_\bD_\bF-style mail files
                 are handled.

                 _\bm_\bu_\bi_\bn_\bc filters mail from the user's _\bM_\bM_\bD_\bF maildrop  into  the  user's
                 _\bU_\bU_\bC_\bP  maildrop;  similarly, _\bu_\bm_\bi_\bn_\bc filters mail from the user's _\bU_\bU_\bC_\bP
                 maildrop into the user's _\bM_\bM_\bD_\bF maildrop.  These two programs respect
                 each system's maildrop locking protocols.

                 _\bm_\bu_\bs_\bi_\bf_\bt 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 _\bU_\bU_\bC_\bP format.  The files (or standard input) are  expected
                 to  be  in  _\bM_\bM_\bD_\bF format.  _\bu_\bm_\bs_\bi_\bf_\bt does the same thing filtering _\bU_\bU_\bC_\bP
                 formatted files (or input), and places the _\bM_\bM_\bD_\bF 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.

            _\bF_\bi_\bl_\be_\bs
                 /usr/spool/mail/                    UUCP spool area for maildrops
                 /usr/spool/mail/$USER               Location of standard maildrop


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 _\bP_\br_\bo_\bp_\bo_\bs_\be_\bd _\bS_\bt_\ba_\bn_\bd_\ba_\br_\bd _\bf_\bo_\br _\bM_\be_\bs_\bs_\ba_\bg_\be _\bH_\be_\ba_\bd_\be_\br _\bM_\bu_\bn_\bg_\bi_\bn_\bg (aka RFC-886),
                 inc(1)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs


            _\bC_\bo_\bn_\bt_\be_\bx_\bt

            [mh.6]                           MH.6.8                      UCI version









            MF(1)                             -33-                             MF(1)


            _\bB_\bu_\bg_\bs
                 Numerous; protocol translation is very difficult.



















































            [mh.6]                           MH.6.8                      UCI version









            RMAIL(8)                          -34-                          RMAIL(8)


            _\bN_\bA_\bM_\bE
                 rmail - UUCP interface to mail

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 rmail address ...

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 _\bR_\bm_\ba_\bi_\bl is intended as a replacement for those systems without  _\bS_\be_\bn_\bd_\b-
                 _\bM_\ba_\bi_\bl  or  _\bM_\bM_\bD_\bF.   It  is  normally  invoked by _\bu_\bu_\bx on behalf of the
                 remote _\bU_\bU_\bC_\bP site.  For each address, it decides where to  send  it:
                 either locally, via another _\bU_\bU_\bC_\bP link, or via the Internet.

                 _\bR_\bm_\ba_\bi_\bl 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.

            _\bF_\bi_\bl_\be_\bs
                 /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


            _\bP_\br_\bo_\bf_\bi_\bl_\be _\bC_\bo_\bm_\bp_\bo_\bn_\be_\bn_\bt_\bs
                 None


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 mf(1)


            _\bD_\be_\bf_\ba_\bu_\bl_\bt_\bs
                 None


            _\bC_\bo_\bn_\bt_\be_\bx_\bt
                 None













                 [mh.6]                           MH.6.8                      UCI version












                                              _\b6. _\bM_\bH _\bH_\bA_\bC_\bK_\bI_\bN_\bG





                      Finally, here's a little information on modifying the  _\bM_\bH  sources.
                 A word of advice however:


                                                  _\bD_\bO_\bN'_\bT



                 If you really want new _\bM_\bH capabilities, write a  shell  script  instead.
                 After all, that's what UNIX is all about, isn't it?

                      Here's the organization of the _\bM_\bH 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 _\bM_\bH
                      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)


            _\bN_\bA_\bM_\bE
                 mh-hack - how to hack MH

            _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
                 big hack attack

            _\bD_\bE_\bS_\bC_\bR_\bI_\bP_\bT_\bI_\bO_\bN

                 This is a description of how one can modify the _\bM_\bH system.  The  _\bM_\bH
                 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 _\bM_\bH 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 _\bM_\bH.  See _\bm_\bh-_\bg_\be_\bn(_\b8) for
                      instructions on how to do this (basically, you want  "mhconfig
                      MH").

                 ADDING A NEW SUBROUTINE
                      Suppose you want to create a new _\bM_\bH 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 _\bl_\bi_\bn_\bt.
                      At this point you can re-configure _\bM_\bH.

                 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 _\bm_\bh_\bc_\bo_\bn_\bf_\bi_\bg.

            _\bF_\bi_\bl_\be_\bs
                 Too numerous to mention.  Honest.


            _\bS_\be_\be _\bA_\bl_\bs_\bo
                 mh-gen(8)

            [mh.6]                           MH.6.8                      UCI version









            MH-HACK(8)                        -37-                        MH-HACK(8)


            _\bB_\bu_\bg_\bs
                 Hacking is an art, but most programmers are butchers, not artists.



















































                 [mh.6]                           MH.6.8                      UCI version












                                            _\b7. _\bH_\bI_\bD_\bD_\bE_\bN _\bF_\bE_\bA_\bT_\bU_\bR_\bE_\bS





                      The capabilities discussed here should not be used on a  production
                 basis,  as they are either experimental, are useful for debugging _\bM_\bH, or
                 are otherwise not recommended.



                 _\bD_\be_\bb_\bu_\bg _\bF_\ba_\bc_\bi_\bl_\bi_\bt_\bi_\be_\bs

                      The _\bm_\ba_\br_\bk command has a `-debug' switch which essentially prints out
                 all the internal _\bM_\bH data structures for the folder you're looking at.

                      The _\bp_\bo_\bs_\bt 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, _\bs_\be_\bn_\bd has a `-debug'  switch
                 which gets passed to _\bp_\bo_\bs_\bt.

                      Some _\bM_\bH 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



                 _\bF_\bo_\br_\bw_\ba_\br_\bd_\bi_\bn_\bg _\bM_\ba_\bi_\bl

                      The _\bf_\bo_\br_\bw and _\bm_\bh_\bl 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  _\bm_\bh_\bl  filter
                 file.



                 _\bS_\be_\bn_\bd

                      The _\bs_\be_\bn_\bd 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  _\bD_\bc_\bc:
                 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).



                 _\bP_\bo_\bs_\bt_\bi_\bn_\bg _\bM_\ba_\bi_\bl

                      If you're running a version of _\bM_\bH which talks directly to  an  _\bS_\bM_\bT_\bP
                 server  (or  perhaps an advanced _\bM_\bM_\bD_\bF submit process), there are lots of
                 interesting switches for your amusement which _\bs_\be_\bn_\bd and _\bp_\bo_\bs_\bt understand:
                      -mail         Use the _\bM_\bA_\bI_\bL command (default)
                      -saml         Use the _\bS_\bA_\bM_\bL command
                      -send         Use the _\bS_\bE_\bN_\bD command
                      -soml         Use the _\bS_\bO_\bM_\bL command
                      -snoop        Watch the _\bS_\bM_\bT_\bP transaction
                      -client host  Claim to be "host" when posting mail
                      -server host  Post mail with "host"

                      The last switch is to be useful when _\bM_\bH 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 _\bw_\bh_\bo_\bm command understands the last three
                 switches.










































                                         _\b8. _\bC_\bO_\bN_\bF_\bI_\bG_\bU_\bR_\bA_\bT_\bI_\bO_\bN _\bO_\bP_\bT_\bI_\bO_\bN_\bS





                      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-












                                                 _\bC_\bO_\bN_\bT_\bE_\bN_\bT_\bS




                 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




                                       _\bF_\bi_\br_\bs_\bt _\bE_\bd_\bi_\bt_\bi_\bo_\bn:

                                         _\bM_\bH _\bC_\bl_\ba_\bs_\bs_\bi_\bc

                      (_\bN_\bo_\bt _\bt_\bo _\bb_\be _\bc_\bo_\bn_\bf_\bu_\bs_\be_\bd _\bw_\bi_\bt_\bh _\ba _\bw_\be_\bl_\bl-_\bk_\bn_\bo_\bw_\bn _\bs_\bo_\bf_\bt _\bd_\br_\bi_\bn_\bk)







                                      November 30, 1993















                                        6.8.3 #1[UCI]