Customized generic SPECS/build-nmh-cygwin for nmh.

[mmh] / docs / historical / ADMIN-19910201.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


                                   February 1, 1991
                                    6.7.1a #6[UCI]




































\e9\e9












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



\e9


\e9       _\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.



\e9       _\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.

\e9









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























\e9
\e9












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



\e9
            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



































\e9                                    -3-









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


  _\bN_\bA_\bM_\bE
       /usr/local/lib/mh/mtstailor - system customization for  MH  message
  system

  _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
       any _\bM_\bH command that interacts with the MTS

  _\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.

       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 have this value set to the name of the POP service host.

       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.

       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>

  [mh.6]                           MH.6.7                      UCI version









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


            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  _\bf_\bl_\bo_\bc_\bk  if  available,  or _\bl_\bo_\bc_\bk_\bf if LOCKF was defined when
            building _\bM_\bH.  On non-BSD42 systems, 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
            doesn't  have the _\bf_\bl_\bo_\bc_\bk or _\bl_\bo_\bc_\bk_\bf 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 ._\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")
            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

  [mh.6]                           MH.6.7                      UCI version









  MH-TAILOR(5)                      -6-                       MH-TAILOR(5)


            _\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
            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 sent 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.

  [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).

    _\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

       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

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

    _\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
       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 _\bM_\bH, the _\bl_\bo_\bc_\bk_\bf syscall is used,  otherwise  the
       _\bf_\bl_\bo_\bc_\bk 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 _\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


\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  MH-TAILOR(5)                      -9-                       MH-TAILOR(5)


  _\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





































\e9
\e9  [mh.6]                           MH.6.7                      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

       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 _\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
       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

  [mh.6]                           MH.6.7                      UCI version









  MH-MTS(8)                         -11-                         MH-MTS(8)


       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.














\e9
\e9       [mh.6]                           MH.6.7                      UCI version












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



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


\e9       _\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/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 _\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/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 _\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/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 _\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).


\e9       _\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

\e9









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


\e9       _\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.






























\e9









  BBOARDS(5)                        -15-                        BBOARDS(5)


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

  _\bS_\bY_\bN_\bO_\bP_\bS_\bI_\bS
       /usr/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/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.
\e9
\e9  [mh.6]                           MH.6.7                      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/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/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


















\e9
\e9  [mh.6]                           MH.6.7                      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/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/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















\e9
\e9  [mh.6]                           MH.6.7                      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/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




\e9
\e9  [mh.6]                           MH.6.7                      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/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/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






\e9
\e9       [mh.6]                           MH.6.7                      UCI version












                                        _\b4. _\bP_\bO_\bP



\e9
            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" (ver. 1) protocol.  The configuration option  "POPSERVICE"  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).



\e9                                         -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).

            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 ._\br_\bh_\bo_\bs_\bt_\bs file in the case of  POP  subscribers











                                         -22-


       being  UNIX logins, or zero the contents of network address field of the
  _\bp_\bo_\bp (5) file for the desired POP subscribers.

















































\e9
\e9









  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.


\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  POP(5)                            -24-                            POP(5)


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


  _\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.





































\e9
\e9  [mh.6]                           MH.6.7                      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













\e9
\e9  [mh.6]                           MH.6.7                      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




















\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  POPD(8)                           -27-                           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,  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.

  _\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


  _\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).





\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  POPWRD(8)                         -28-                         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.









\e9
\e9       [mh.6]                           MH.6.7                      UCI version












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



\e9
            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.
































\e9                                    -29-









  MF(1)                             -30-                             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


\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  MF(1)                             -31-                             MF(1)


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


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














































\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  RMAIL(8)                          -32-                          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











\e9
\e9       [mh.6]                           MH.6.7                      UCI version












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



\e9
            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











\e9                                    -33-









  MH-HACK(8)                        -34-                        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.



\e9
\e9  [mh.6]                           MH.6.7                      UCI version









  MH-HACK(8)                        -35-                        MH-HACK(8)


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


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













































\e9
\e9       [mh.6]                           MH.6.7                      UCI version












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



\e9
            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.



\e9       _\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



\e9       _\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.



\e9       _\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

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



\e9       _\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.



























\e9












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



\e9
            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
       ________________________________________________________________________

































\e9                                         -38-












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




       Section

          1.  INTRODUCTION ...............................................    1
\e9            Scope of this document .......................................    1
\e9            Summary ......................................................    1

          2.  THE MTS INTERFACE ..........................................    3
               MH-TAILOR .................................................    4
               MH-MTS ....................................................   10

          3.  BBOARDS ....................................................   12
\e9            BBoard Delivery ..............................................   12
\e9            BBoards with the POP .........................................   13
\e9            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
\e9            Debug Facilities .............................................   36
\e9            Forwarding Mail ..............................................   36
\e9            Send .........................................................   36
\e9            Posting Mail .................................................   37

          8.  CONFIGURATION OPTIONS ......................................   38


\e9























\e9                               THE RAND MH

\e9                            MESSAGE HANDLING

\e9                                 SYSTEM:

\e9                          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)







                            February 1, 1991

                             6.7.1a #6[UCI]

































































\e9
\e9