[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated
|
From: |
David Levine |
|
Subject: |
[Nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 9b152e23db633c49c43313a2ef26ebc0951cc874 |
|
Date: |
Wed, 29 Feb 2012 04:06:44 +0000 |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The nmh Mail Handling System".
The branch, master has been updated
via 9b152e23db633c49c43313a2ef26ebc0951cc874 (commit)
from 2def1ef7c06766912f6eea1a9ab31b492d82173a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=9b152e23db633c49c43313a2ef26ebc0951cc874
commit 9b152e23db633c49c43313a2ef26ebc0951cc874
Author: David Levine <address@hidden>
Date: Tue Feb 28 22:05:55 2012 -0600
Added docs/historical/. See README for where they were found.
diff --git a/docs/historical/ADMIN-19910201.txt
b/docs/historical/ADMIN-19910201.txt
new file mode 100644
index 0000000..47fde0d
--- /dev/null
+++ b/docs/historical/ADMIN-19910201.txt
@@ -0,0 +1,2729 @@
+
+
+
+
+
+
+
+
+ _d_i_s_c_a_r_d _t_h_i_s
_p_a_g_e
+
+
+
+
+ The RAND _M_H
+ Message Handling
+ System:
+ Administrator's Guide
+
+ UCI Version
+
+
+ February 1, 1991
+ 6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+99
+
+
+
+
+
+
+
+
+
+
+
+
+ _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+9
+
+
+9 _S_c_o_p_e _o_f _t_h_i_s _d_o_c_u_m_e_n_t
+
+ This is the Administrator's Guide to _M_H. If you don't
maintain an
+ _M_H system, don't read this; the information is entirely too
technical.
+ If you are a maintainer, then read this guide until you understand it,
+ follow the advice it gives, and then forget about the guide.
+
+ Before continuing, I'll point out two facts:
+
+
+
+ _T_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l
_n_e_v_e_r _c_o_n_t_a_i_n _a_l_l _t_h_e
_i_n_f_o_r_m_a_t_i_o_n
+ _y_o_u _n_e_e_d _t_o
_m_a_i_n_t_a_i_n _M_H.
+
+ _F_u_r_t_h_e_r_m_o_r_e, _t_h_i_s
_d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n
_e_v_e_r_y_t_h_i_n_g
+ _I _k_n_o_w _a_b_o_u_t
_m_a_i_n_t_a_i_n_i_n_g _M_H.
+
+
+
+ _M_H, and mailsystems in general, are more complex than most people
real-
+ ize. A combination of experience, intuition, and tenacity is required
+ to maintain _M_H properly. This document can provide only guidelines
for
+ bringing up an _M_H system and maintaining it. There is a
sufficient
+ amount of customization possible that not all events or problems can be
+ forseen.
+
+
+
+9 _S_u_m_m_a_r_y
+
+ During _M_H generation, you specify several configuration
constants
+ to the _m_h_c_o_n_f_i_g program. These directives take into
consideration such
+ issues as hardware and operating system dependencies in the source code.
+ They also factor out some major mailsystem administrative decisions that
+ are likely to be made consistantly at sites with more than one host.
+ The manual entry _m_h-_g_e_n (8) describes all the static
configuration
+ directives.
+
+ However, when you install _M_H you may wish to make
some
+ site-specific or host-specific changes which aren't hardware or even
+ software related. Rather, they are administrative decisions. That's
+ what this guide is for: it describes all of the dynamically tailorable
+ directives.
+
+9
+
+
+
+
+
+
+
+
+
+ -2-
+
+
+ Usually, after installing _M_H, you'll want to edit
the
+ /usr/local/lib/mh/mtstailor file. This file fine-tunes the way
_M_H
+ interacts with the message transport system (MTS). Section 2 talks
+ about the MTS interface and MTS tailoring.
+
+ After that, if you're running the UCI BBoards facility, or the POP
+ facility, you'll need to know how to maintain those systems. Sections 3
+ and 4 talk about these.
+
+ If for some reason you're not running an MTS that can handle both
+ Internet and _U_U_C_P traffic, you should read-up on mail
filtering in Sec-
+ tion 5. Although this is considered "old technology" now, the mechan-
+ isms described in Section 5 were really quite useful when first intro-
+ duced way back in 1981.
+
+ Finally, you may want to know how to modify the _M_H source
tree.
+ Section 6 talks (a little bit) about that.
+
+ The last two sections describe a few hidden features in _M_H,
and the
+ configuration options that were in effect when this guide was generated.
+
+ After _M_H is installed, you should define the address
"Bug-MH" to
+ map to either you or the _P_o_s_t_M_a_s_t_e_r at your site.
+
+ In addition, if you want to tailor the behavior of _M_H for
new
+ users, you can create and edit the file /usr/local/lib/mh/mh.profile.
+ When the _i_n_s_t_a_l_l-_m_h program is run for a user, if
this file exists, it
+ will copy it into the user's .mh_profile file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _2. _T_H_E _M_T_S
_I_N_T_E_R_F_A_C_E
+
+
+
+9
+ The file /usr/local/lib/mh/mtstailor customizes certain
+ host-specific parameters of _M_H related primarily to interactions
with
+ the transport system. The parameters in this file override the
+ compiled-in defaults given during _M_H configuration. Rather than
recom-
+ piling _M_H on each host to make minor customizations, it is easier
simply
+ to modify the mtstailor file. All hosts at a given site normally use
+ the same mtstailor file, though this need not be the case.
+
+ It is a good idea to run the _c_o_n_f_l_i_c_t (8)
program each morning
+ under _c_r_o_n. The following line usually suffices:
+
+ 00 05 * * * /usr/local/lib/mh/conflict -mail PostMaster
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 -3-
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -4- MH-TAILOR(5)
+
+
+ _N_A_M_E
+ /usr/local/lib/mh/mtstailor - system customization for MH message
+ system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command that interacts with the MTS
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The file /usr/local/lib/mh/mtstailor defines run-time options for
+ those _M_H programs which interact (in some form) with the message
+ transport system. At present, these (user) programs are: _a_p,
_c_o_n_-
+ _f_l_i_c_t, _i_n_c, _m_s_g_c_h_k, _m_s_h,
_p_o_s_t, _r_c_v_d_i_s_t, and _r_c_v_p_a_c_k.
+
+ The options available along with default values and a description
+ of their meanings are listed below:
+
+ localname:
+ The host name _M_H considers local. If not set, depending on
+ the version of UNIX you're running, _M_H will query the system
+ for this value (e.g., <whoami.h>, gethostname, etc.). This
+ has no equivalent in the _M_H configuration file. POP client
+ hosts have this value set to the name of the POP service host.
+
+ systemname:
+ The name of the local host in the _U_U_C_P "domain". If not
set,
+ depending on the version of UNIX you're running, _M_H will query
+ the system for this value. This has no equivalent in the _M_H
+ configuration file.
+
+ mmdfldir: /usr/spool/mail
+ The directory where maildrops are kept. If this is empty, the
+ user's home directory is used. This overrides the "mail"
+ field in the _M_H configuration file.
+
+ mmdflfil:
+ The name of the maildrop file in the directory where maildrops
+ are kept. If this is empty, the user's login name is used.
+ This overrides the "mail" field in the _M_H configuration file.
+
+ mmdelim1: \001\001\001\001\n
+ The beginning-of-message delimiter for maildrops.
+
+ mmdelim2: \001\001\001\001\n
+ The end-of-message delimiter for maildrops.
+
+ mmailid: 0
+ If non-zero, then support for MMailids in /etc/passwd is
+ enabled. Basically, the pw_gecos field in the password file
+ is of the form
+
+ My Full Name <mailid>
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -5- MH-TAILOR(5)
+
+
+ The _M_H internal routines that deal with user and full names
+ will return "mailid" and "My Full Name" respectively.
+
+ lockstyle: 0
+ The locking-discipline to perform. A value of "0" means to
+ use _f_l_o_c_k if available, or _l_o_c_k_f if LOCKF
was defined when
+ building _M_H. On non-BSD42 systems, standard
_B_e_l_l_M_a_i_l locking
+ is used. A value of "1" means to use _B_e_l_l_M_a_i_l
locking always
+ (the name of the lock is based on the file name). A value of
+ "2" means to use _M_M_D_F locking always (the name of the
lock is
+ based on device/inode pairs).
+
+ lockldir:
+ The name of the directory for making locks. If your system
+ doesn't have the _f_l_o_c_k or _l_o_c_k_f syscalls,
then this directory
+ is used when creating locks. If the value is empty, then the
+ directory of the file to be locked is used.
+
+ maildelivery: /usr/local/lib/mh/maildelivery
+ The name of the system-wide default
._m_a_i_l_d_e_l_i_v_e_r_y file. See
+ _m_h_o_o_k (1) for the details.
+
+ everyone: 200
+ The highest user-id which should NOT receive mail addressed to
+ "everyone".
+
+ noshell:
+ If set, then each user-id greater than "everyone" that has a
+ login shell equivalent to the given value (e.g., "/bin/csh")
+ indicates that mail for "everyone" should not be sent to them.
+ This is useful for handling admin, dummy, and guest logins.
+
+ _M_a_i_l _F_i_l_t_e_r_i_n_g
+
+ These options are only available if you compiled _M_H with
+ "options MF".
+
+ uucpchan: name of _U_U_C_P channel
+ Usually "UUCP". This has no equivalent in the _M_H configura-
+ tion file.
+
+ uucpldir: /usr/spool/mail
+ The name of the directory where _U_U_C_P maildrops are kept.
This
+ has no equivalent in the _M_H configuration file.
+
+ uucplfil:
+ The name of the maildrop file in the directory where
_U_U_C_P
+ maildrops are kept. If this is empty, the user's login name
+ is used. This has no equivalent in the _M_H configuration file.
+
+ umincproc: /usr/local/lib/mh/uminc
+ The path to the program that filters _U_U_C_P-style maildrops
to
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -6- MH-TAILOR(5)
+
+
+ _M_M_D_F-style maildrops.
+
+ _S_t_a_n_d-_A_l_o_n_e _D_e_l_i_v_e_r_y
+
+ These options are only available if you compiled _M_H to use stand-
+ alone delivery (i.e., "mts: mh").
+
+ mailqdir: /usr/spool/netmail
+ The directory where network mail is queued.
+
+ tmailqdir: /usr/tmp
+ The directory where network mail queue files are built.
+
+ syscpy: 1
+ If ON, unauthorized mail is copied to the overseer.
+
+ overseer: root
+ The user that receives reports of unauthorized mail.
+
+ mailer: root
+ The user acting for the mail system.
+
+ fromtmp: /tmp/rml.f.XXXXXX
+ The _m_k_t_e_m_p template for storing from lines.
+
+ msgtmp: /tmp/rml.m.XXXXXX
+ The _m_k_t_e_m_p template for storing the rest of the
message.
+
+ errtmp: /tmp/rml.e.XXXXXX
+ The _m_k_t_e_m_p template for storing error messages
from other
+ mailers.
+
+ tmpmode: 0600
+ The octal mode which temporary files are set to.
+
+ okhosts: /usr/local/lib/mh/Rmail.OKHosts
+ A file containing a list of hosts that can sent ARPAnet mail.
+
+ okdests: /usr/local/lib/mh/RMail.OKDests
+ A file containing a list of hosts that can always receive
+ mail.
+
+ _T_h_e `/_s_m_t_p' _M_T_S _S_u_f_f_i_x
+
+ These options are only available if you compiled _M_H with the
+ "/smtp" suffix to your "mts:" configuration.
+
+ hostable: /usr/local/lib/mh/hosts
+ The exceptions file for /etc/hosts used by _p_o_s_t to try to
find
+ official names. The format of this file is quite simple:
+
+ 1. Comments are surrounded by sharp (`#') and newline.
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -7- MH-TAILOR(5)
+
+
+ 2. Words are surrounded by whitespace.
+ 3. The first word on the line is the official name of a
+ host.
+ 4. All words following the official names are aliases for
+ that host.
+
+ servers: localhost \01localnet
+ A lists of hosts and networks which to look for SMTP servers
+ when posting local mail. It turns out this is a major win for
+ hosts which don't run an message transport system. The value
+ of "servers" should be one or more items. Each item is the
+ name of either a host or a net (in the latter case, precede
+ the name of the net by a \01). This list is searched when
+ looking for a smtp server to post mail. If a host is present,
+ the SMTP port on that host is tried. If a net is present, the
+ SMTP port on each host in that net is tried. Note that if you
+ are running with the BIND code, then any networks specified
+ are ignored (sorry, the interface went away under BIND).
+
+ _S_e_n_d_M_a_i_l
+
+ This option is only available if you compiled _M_H to use
_S_e_n_d_M_a_i_l as
+ your delivery agent (i.e., "mts: sendmail").
+
+ sendmail: /usr/lib/sendmail
+ The pathname to the _s_e_n_d_m_a_i_l program.
+
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+ This option is only available if you compiled _M_H with POP support
+ enabled (i.e., "pop: on").
+
+ pophost:
+ The name of the default POP service host. If this is not set,
+ then _M_H looks in the standard maildrop areas for waiting mail,
+ otherwise the named POP service host is consulted.
+
+ _B_B_o_a_r_d_s _D_e_l_i_v_e_r_y
+
+ This option is only available if you compiled _M_H with
+ "bbdelivery: on".
+
+ bbdomain:
+ The local BBoards domain (a UCI hack).
+
+ _B_B_o_a_r_d_s & _T_h_e _P_O_P
+
+ These options are only available if you compiled _M_H with
+ "bboards: pop" and "pop: on".
+
+ popbbhost:
+ The POP service host which also acts as a BBoard server. This
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -8- MH-TAILOR(5)
+
+
+ variable should be set on the POP BBoards client host.
+
+ popbbuser:
+ The guest account on the POP/BB service host. This should be
+ a different login ID than either the POP user or the BBoards
+ user. (The user-id "ftp" is highly recommended.) This vari-
+ able should be set on both the POP BBoards client and service
+ hosts.
+
+ popbblist: /usr/local/lib/mh/hosts.popbb
+ A file containing of lists of hosts that are allowed to use
+ the POP facility to access BBoards using the guest account.
+ If this file is not present, then no check is made. This
+ variable should be set on the POP BBoards service host.
+
+ _B_B_o_a_r_d_s & _T_h_e _N_N_T_P
+
+ This option is only available if you compiled _M_H with
+ "bboards: nntp" and "pop: on".
+
+ nntphost:
+ The host which provides the NNTP service. This variable
+ should be set on the NNTP BBoards client host.
+
+ _F_i_l_e _L_o_c_k_i_n_g
+
+ A few words on locking: _M_H has a flexible locking system for making
+ locks on files. There are two mtstailor variables you should be
+ aware of "lockstyle" and "lockldir". The first controls the method
+ of locking, the second says where lock files should be created.
+ The "lockstyle" variable can take on three values: 0, 1, 2. A
+ value of 0 is useful on BSD42 systems. If you included the LOCKF
+ option when building _M_H, the _l_o_c_k_f syscall is used,
otherwise the
+ _f_l_o_c_k syscall is used. If you're not on a 4.2BSD system, a
locking
+ style of 0 is considered the same as locking style 1.
+
+ A value of 1 or 2 specifies that a file should be created whose
+ existence means "locked" and whose non-existence means "unlocked".
+ A value of 1 says to construct the lockname by appending ".lock" to
+ the name of the file being locked. A value of 2 says to construct
+ the lockname by looking at the device and inode numbers of the file
+ being locked. If the "lockldir" variable is not specified, lock
+ files will be created in the directory where the file being locked
+ resides. Otherwise, lock files will be created in the directory
+ specified by "lockldir". Prior to installing _M_H, you should see
+ how locking is done at your site, and set the appropriate values.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -9- MH-TAILOR(5)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mh-gen(8), mh-mts(8)
+
+
+ _D_e_f_a_u_l_t_s
+ As listed above
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MTS(8) -10- MH-MTS(8)
+
+
+ _N_A_M_E
+ mh-mts - the MH interface to the message transport system
+
+ _S_Y_N_O_P_S_I_S
+ SendMail
+
+ MMDF (any release)
+
+ stand-alone
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H can use a wide range of message transport systems to deliver
+ mail. Although the _M_H administrator usually doesn't get to choose
+ which MTS to use (since it's already in place), this document
+ briefly describes the interfaces.
+
+ When communicating with _S_e_n_d_M_a_i_l, _M_H always uses
the SMTP to post
+ mail. Depending on the _M_H configuration,
_S_e_n_d_M_a_i_l may be invoked
+ directly (via a _f_o_r_k and an _e_x_e_c), or _M_H may open a
TCP/IP connec-
+ tion to the SMTP server on the localhost.
+
+ When communicating with _M_M_D_F, normally _M_H uses the "mm_"
routines
+ to post mail. However, depending on the _M_H configuration,
_M_H
+ instead may open a TCP/IP connection to the SMTP server on the
+ localhost.
+
+ When using the stand-alone system (NOT recommended), _M_H delivers
+ local mail itself and queues _U_U_C_P and network mail. The
network
+ mail portion will probably have to be modified to reflect the local
+ host's tastes, since there is no well-known practice in this area
+ for all types of UNIX hosts.
+
+ If you are running a UNIX system with TCP/IP networking, then it is
+ felt that the best interface is achieved by using either
_S_e_n_d_M_a_i_l
+ or _M_M_D_F with the SMTP option. This gives greater flexibility.
To
+ enable this option you append the /smtp suffix to the mts option in
+ the _M_H configuration. This yields two primary advantages: First,
+ you don't have to know where _s_u_b_m_i_t or
_S_e_n_d_M_a_i_l live. This means
+ that _M_H binaries (e.g., _p_o_s_t ) don't have to have this
information
+ hard-coded, or can run different programs altogether; and, second,
+ you can post mail with the server on different systems, so you
+ don't need either _M_M_D_F or _S_e_n_d_M_a_i_l on your
local host. Big win in
+ conserving cycles and disk space. Since _M_H supports the notion of
+ a server search-list in this respect, this approach can be tolerant
+ of faults. Be sure to set "servers:" as described in mh-tailor(8)
+ if you use this option.
+
+ There are four disadvantages to using the SMTP option: First, only
+ UNIX systems with TCP/IP are supported. Second, you need to have
+ an SMTP server running somewhere on any network your local host can
+ reach. Third, this bypasses any authentication mechanisms in
_M_M_D_F
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MTS(8) -11- MH-MTS(8)
+
+
+ or _S_e_n_d_M_a_i_l. Fourth, the file /etc/hosts is used
for hostname
+ lookups (although there is an exception file). In response to
+ these disadvantages though: First, there's got to be an SMTP server
+ somewhere around if you're in the Internet or have a local network.
+ Since the server search-list is very general, a wide-range of
+ options are possible. Second, SMTP should be fixed to have authen-
+ tication mechanisms in it, like POP. Third, _M_H won't choke on mail
+ to hosts whose official names it can't verify, it'll just plug
+ along (and besides if you enable the BERK or DUMB configuration
+ options, _M_H ignores the hosts file altogether).
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _M_M_D_F-_I_I: _A _T_e_c_h_n_i_c_a_l
_R_e_v_i_e_w, Proceedings, Usenix Summer '84 Confer-
+ ence
+ _S_E_N_D_M_A_I_L -- _A_n _I_n_t_e_r_n_e_t_w_o_r_k
_M_a_i_l _R_o_u_t_e_r
+ mh-tailor(8), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The /usr/local/lib/mh/mtstailor file ignores the information in the
+ _M_M_D_F-_I_I tailoring file. It should not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _3. _B_B_O_A_R_D_S
+
+
+
+9
+ The UCI BBoards facility has two aspects: message reading, and mes-
+ sage delivery. The configuration directives applicable to BBoards are
+ "bboards: on/off/pop/nntp" and "bbdelivery: on/off".
+
+
+9 _B_B_o_a_r_d _D_e_l_i_v_e_r_y
+
+ If you enabled BBoards delivery ("bbdelivery: on") during confi-
+ guration, then the initial environment for bboards delivery was set-up
+ during installation. A BBoard called "system" is established, which is
+ the BBoard for general discussion.
+
+ To add more BBoards, become the "bboards" user, and edit the
+ /usr/bboards/BBoards file. The file support/bboards/Example is a copy
+ of the /usr/bboards/BBoards file that we use at UCI. When you add a
+ BBoard, you don't have to create the files associated with it, the
+ BBoards delivery system will do that automatically.
+
+ Private BBoards may be created. To add the fictitious private
+ BBoard "hacks", add the appropriate entry to the BBoards file, create
+ the empty file /usr/bboards/hacks.mbox (or whatever), change the mode of
+ this file to 0640, and change the group of the file to be the groupid of
+ the people that you want to be able to read it. Also be sure to add the
+ "bboards" user to this group (in /etc/group), so the archives can be
+ owned correctly.
+
+ By using the special INVIS flag for a BBoard, special purpose
+ BBoards may be set-up which are invisible to the _M_H user. For
example,
+ if a site distributes a BBoard both locally to a number of machines and
+ to a number of distant machines. It might be useful to have two distri-
+ bution lists: one for all machines on the list, and the other for local
+ machines only. This is actually very simple to do. For the main list,
+ put the standard entry of information in the /usr/bboards/BBoards file,
+ with the complete distribution list. For the local machines list, and
+ add a similar entry to the /usr/bboards/BBoards file. All the fields
+ should be the same except three: the BBoard name should reflect a local
+ designation (e.g., "l-hacks"), the distribution list should contain only
+ machines at the local site, and the flags field should contain the INVIS
+ flag. Since the two entries share the same primary and archive files,
+ messages sent to either list are read by local users, while only thoses
+ messages sent to the main list are read by all users.
+
+ Two automatic facilities for dealing with BBoards exist: automatic
+ archiving and automatic aliasing. The file support/bboards/crontab con-
+ tains some entries that you should add to your /usr/lib/crontab file to
+ run the specified programs at times that are convenient for you. The
+
+ -12-
+
+
+
+
+
+
+
+
+
+ -13-
+
+
+ bboards.daily file is run once a day and generates an alias file for
_M_H.
+ By using this file, users of _M_H can use, for example,
"unix-wizards"
+ instead of "address@hidden" when they want to send a message to
+ the "unix-wizards" discussion group. This is a major win, since you
+ just have to know the name of the group, not the address where it's
+ located.
+
+ The bboards.weekly file is run once a week and handles old messages
+ (those received more than 12 days ago) in the BBoards area. In short,
+ those BBoards which are marked for automatic archiving will have their
+ old messages placed in the /usr/bboards/archive/ area, or have their old
+ messages removed. Not only does this make BBoards faster to read, but
+ it conveniently partitions the new messages from the old messages so you
+ can easily put the old messages on tape and then remove them. It turns
+ out that this automatic archiving capability is also a major win.
+
+ At UCI, our policy is to save archived messages on tape (every two
+ months or so). We use a program called _b_b_t_a_r to implement
our particu-
+ lar policy. Since some BBoards are private (see above), we save the
+ archives on two tapes: one containing the world-readable archives (this
+ tape is read-only accessible to all users by calling the operator), and
+ the other containing the non-world-readable ones (this tape is kept
+ locked-up somewhere).
+
+
+9 _B_B_o_a_r_d_s _w_i_t_h _t_h_e _P_O_P
+
+ If you configured _M_H with "bboards: pop" and "pop: on", then
the _M_H
+ user is allowed to read BBoards on a server machine instead of the local
+ host (thus saving disk space). For completely transparent behavior, the
+ administrator may set certain variables in the mtstailor file on the
+ client host. The variable "popbbhost" indicates the host where BBoards
+ are kept (it doesn't have to be the POP service host, but this host must
+ run both a POP server and the BBoards system). The variable "popbbuser"
+ indicates the guest account on this host for BBoards. This username
+ should not be either the POP user or the BBoards user. Usually the
+ anonymous FTP user (ftp) is the best choice. Finally, the variable
+ "popbblist" indicates the name of a file which contains a list of hosts
+ (one to a line, official host names only) which should be allowed to use
+ the POP facility to access BBoards via the guest account. (If the file
+ is not present, then no check is made.)
+
+ The "popbbuser" variable should be set on both the client and ser-
+ vice host. The "popbbhost" variable need be set only on the client host
+ (the value, of course, is the name of the service host). The
+ "popbblist" variable need be set only on the service host.
+
+ Finally, on the client host, if a POP service host is not expli-
+ citly given by the user (i.e., "popbbhost" is implicitly used), then
_b_b_c
+ will explicitly check the local host prior to contacting the service
+ host. This allows each POP client host to have a few local BBoards
+
+9
+
+
+
+
+
+
+
+
+
+ -14-
+
+
+ (e.g., each host could have one called "system"), and then have the POP
+ service host used for all the rest (a site-wide BBoard might be known as
+ "general").
+
+
+9 _B_B_o_a_r_d_s _w_i_t_h _t_h_e _N_N_T_P
+
+ If you configured _M_H with "bboards: nntp" and "pop: on", then
the
+ _M_H user is allowed to read the Network News on a server machine
using
+ the standard _b_b_c command. For completely transparent
behavior, the
+ administrator may set the "nntphost" variable in the mtstailor file to
+ indicate the host where the Network News is kept. The "nntphost" vari-
+ able should be set only on the client host Finally, on the client host,
+ if an NNTP service host is not explicitly given by the user (i.e.,
+ "nntphost" is implicitly used), then _b_b_c will explicitly check
the local
+ host prior to contacting the service host. This allows each NNTP client
+ host to have a few local BBoards (e.g., each host could have one called
+ "system"), and then have the NNTP service host used for to read the Net-
+ work News.
+
+ Reading BBoards via the POP and via the NNTP are mutually
+ exclusive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+
+
+
+
+
+
+
+
+
+ BBOARDS(5) -15- BBOARDS(5)
+
+
+ _N_A_M_E
+ BBoards - BBoards database
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bboards/BBoards
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The BBoards database contains for each BBoard the following infor-
+ mation:
+
+ _f_i_e_l_d _v_a_l_u_e
+ name the name of the BBoard
+ aliases local aliases for the BBoard
+ (separated by commas)
+ primary file the .mbox file
+ encrypted password leadership password
+ leaders local list maintainers (separated by commas)
+ usernames from the _p_a_s_s_w_d (5) file,
+ or groupnames preceded by `=' from the
+ _g_r_o_u_p (5) file
+ network address the list address
+ request address the list maintainer's address
+ relay the host acting as relay for the local domain
+ distribution sites (separated by commas)
+ flags special flags (see <bboards.h>)
+
+ This is an ASCII file. Each field within each BBoard's entry is
+ separated from the next by a colon. Each BBoard entry is separated
+ from the next by a new-line. If the password field is null, no
+ password is demanded; if it contains a single asterisk, then no
+ password is valid.
+
+ This file resides in the home directory of the login "bboards".
+ Because of the encrypted passwords, it can and does have general
+ read permission.
+
+ _F_i_l_e_s
+ /usr/bboards/BBoards BBoards database
+
+
+ _S_e_e _A_l_s_o
+ bbaka(8), bbexp(8), bboards (8), bbtar(8)
+
+
+ _B_u_g_s
+ A binary indexed file format should be available for fast access.
+
+ Appropriate precautions must be taken to lock the file against
+ changes if it is to be edited with a text editor. A _v_i_b_b
program
+ is needed.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBOARDS(5) -16- BBOARDS(5)
+
+
+ _N_A_M_E
+ bbaka - generate an alias list for BBoards
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bboards/bbaka [system]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_a_k_a program reads the BBoards database and produces
on its
+ standard output a file suitable for inclusion in either the
_M_M_D_F-_I_I
+ aliases file (if the argument `system' is given). If the argument
+ is not given, then _b_b_a_k_a produces on its standard output
a file
+ suitable for becoming the /usr/local/lib/mh/BBoardsAliases file.
+
+ _F_i_l_e_s
+ /usr/bboards/BBoards BBoards database
+ /usr/local/lib/mh/BBoardsAliases BBoards aliases file for _M_H
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBEXP(8) -17- BBEXP(8)
+
+
+ _N_A_M_E
+ bbexp - expunge the BBoards area
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bboards/bbexp [-_f_i_r_s_t-_m_e_t_r_i_c]
[-_s_e_c_o_n_d-_m_e_t_r_i_c] [bboards ...]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_e_x_p program reads the BBoards database and calls
_m_s_h to
+ archive the named BBoards (or all BBoards if none are specified).
+
+ The first-metric (which defaults to 12) gives the age in days of
+ the "BB-Posted:" field for messages which should be expunged. The
+ second-metric (which defaults to 20) gives the age in days of the
+ "Date:" field for messages which should be expunged. Any message
+ which meets either metric will be either archived or removed,
+ depending on what the _B_B_o_a_r_d_s (5) file says.
+
+ _F_i_l_e_s
+ /usr/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ msh(1), bboards(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBOARDS(8) -18- BBOARDS(8)
+
+
+ _N_A_M_E
+ bboards - BBoards channel/mailer
+
+ _S_Y_N_O_P_S_I_S
+ /usr/mmdf/chans/bboards fd1 fd2 [y]
+
+ /usr/local/lib/mh/sbboards bboard ...
+
+ /usr/local/lib/mh/sbboards file maildrop directory bboards.bboard
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ For _M_M_D_F, the BBoards channel delivers mail to the BBoards
system.
+ For _S_e_n_d_M_a_i_l and stand-alone _M_H, the SBBoards
mailer performs this
+ task.
+
+ For each address given, these programs consult the
_b_b_o_a_r_d_s (5) file
+ to ascertain information about the BBoard named by the address.
+ The programs then perform local delivery, if appropriate. After
+ that, with the exception of _s_b_b_o_a_r_d_s running under
stand-alone _M_H,
+ the programs perform redistribution, if appropriate.
+
+ For redistribution, the return address is set to be the request
+ address at the local host, so bad addresses down the line return to
+ the nearest point of authority. If any failures occur during
+ redistribution, a mail message is sent to the local request
+ address.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbaka(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBTAR(8) -19- BBTAR(8)
+
+
+ _N_A_M_E
+ bbtar - generate the names of archive files to be put to tape
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bboards/bbtar [private] [public]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_t_a_r program reads the BBoards database and produces
on its
+ standard output the names of BBoards archives which should be put
+ to tape, for direct use in a _t_a_r (1) command.
+
+ If the argument `private' is given, only private BBoards are con-
+ sidered. If the argument `public' is given, only public BBoards
+ are considered. This lets the BBoards administrator write two
+ tapes, one for general read-access (the public BBoards), and one
+ for restricted access. The default is all BBoards
+
+ For example:
+
+ cd archive # change to the archive directory
+ tar cv `bbtar private` # save all private BBoard archives
+
+ After the archives have been saved to tape, they are usually
+ removed. The archives are then filled again, usually automatically
+ by cron jobs which run _b_b_e_x_p (8).
+
+ _F_i_l_e_s
+ /usr/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbexp(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _4. _P_O_P
+
+
+
+9
+ For POP (Post Office Protocol) client hosts, you need to edit the
+ /usr/local/lib/mh/mtstailor file to know about two hosts: the SMTP ser-
+ vice host and the POP service host. Normally, these are the same.
+ Change the "localname" field of the mtstailor file of _M_H in the
file to
+ be the name of the POP service host. This makes replies to mail gen-
+ erated on the POP client host possible, since _M_H will consider
use the
+ hostname of the POP service host as the local hostname for outgoing
+ mail. Also set the value of "pophost" to this value. This tells
_i_n_c
+ and _m_s_g_c_h_k to use POP instead of looking for mail
locally. Finally,
+ make sure the value of "servers" includes the name of the SMTP service
+ host. The recommended value for "servers" is:
+
+ servers: SMTP-service-host localhost \01localnet
+
+ If you want more information on the Post Office Protocol used by
+ _M_H, consult the files support/pop/rfc1081.txt
and
+ support/pop/rfc1082.txt which describe the _M_H version of the POP:
POP3.
+
+ For POP service hosts, you need to run a daemon, _p_o_p_d
(8). The
+ daemon should start at multi-user boot time, so adding the lines:
+
+ if [ -f /etc/popd ]; then
+ /etc/popd & echo -n ' pop' >/dev/console
+ fi
+
+ to the /etc/rc.local file is sufficient.
+
+ The port assigned to the POP3 protocol is "110". For historical
+ reasons, many sites are using port "109" which is the port assigned to
+ the "POP" (ver. 1) protocol. The configuration option "POPSERVICE" is
+ the name of the port number that _M_H POP will try to use, and
defaults to
+ the name "pop".
+
+ To generate _M_H to use newer assigned port number, in your
_M_H config
+ file, add:
+
+ options POPSERVICE='"pop3"'
+
+ And on both the POP client and service hosts, you need to define the
+ port that the POP service uses. Add the line:
+
+ pop3 110/tcp
+
+ to the /etc/services file (if it's not already there).
+
+
+
+9 -20-
+
+
+
+
+
+
+
+
+
+ -21-
+
+
+ There are two ways to administer POP: In "naive" mode, each user-id
+ in the _p_a_s_s_w_d (5) file is considered a POP subscriber.
No changes are
+ required for the mailsystem on the POP service host. However, this
+ method requires that each POP subscriber have an entry in the password
+ file. The POP server will fetch the user's mail from wherever maildrops
+ are kept on the POP service host. This means that if maildrops are kept
+ in the user's home directory, then each POP subscriber must have a home
+ directory.
+
+ In "smart" mode (enabled via "DPOP" being given as a configuration
+ option), the list of POP subscribers and the list of login users are
+ completely separate name spaces. A separate database (simple file simi-
+ lar to the _B_B_o_a_r_d_s (5) file) is used to record
information about each
+ POP subscriber. Unfortunately, the local mailsystem must be changed to
+ reflect this. This requires two changes (both of which are simple):
+ First, the aliasing mechanism is augmented so that POP subscriber
+ addresses are diverted to a special delivery mechanism. _M_H comes
with a
+ program, _p_o_p_a_k_a (8), which generates the additional
information to be
+ put in the mailsystem's alias file. Second, a special POP channel (for
+ MMDF-II) or POP mailer (for SendMail) performs the actual delivery
(_m_h._6
+ supplies both). All it really does is just place the mail in the POP
+ spool area.
+
+ These two different philosophies are not compatible on the same POP
+ service host: one or the other, but not both may be run. Clever mail-
+ system people will note that the POP mechanism is really a special case
+ of the more general BBoards mechanism.
+
+ In addition, there is one user-visible difference, which the
+ administrator controls the availability of. The difference is whether
+ the POP subscriber must supply a password to the POP server: The first
+ method uses the standard ARPA technique of sending a username and a
+ password. The appropriate programs (_i_n_c, _m_s_g_c_h_k,
and possibly _b_b_c )
+ will prompt the user for this information.
+
+ The second method (which is enabled via "RPOP" being given as a
+ configuration option) uses the Berkeley UNIX reserved port method for
+ authentication. This requires that the two or three mentioned above
+ programs be _s_e_t_u_i_d to root. (There are no known holes in
any of these
+ programs.)
+
+ To add a POP subscriber, for the first method, one simply follows
+ the usual procedures for adding a new user, which eventually results in
+ adding a line to the _p_a_s_s_w_d (5) file; for the second
method, one must
+ edit the POP database file (kept in the home directory of the POP user),
+ and then run the _p_o_p_a_k_a program. The output of this
program is placed
+ in the aliases file for the transport system (e.g., /usr/lib/aliases for
+ SendMail).
+
+ These two different philosophies are compatible on the same POP
+ service host: to selectively disable RPOP for hosts which aren't
+ trusted, either modify the ._r_h_o_s_t_s file in the case of POP
subscribers
+
+
+
+
+
+
+
+
+
+
+
+ -22-
+
+
+ being UNIX logins, or zero the contents of network address field of the
+ _p_o_p (5) file for the desired POP subscribers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ POP(5) -23- POP(5)
+
+
+ _N_A_M_E
+ POP - POP database of subscribers
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/pop/POP
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The POP database has exactly the same format as the
_B_B_o_a_r_d_s (5)
+ database, although many fields are unused. Currently, only four
+ fields are examined:
+
+ _f_i_e_l_d _v_a_l_u_e
+ name the POP subscriber
+ primary file the maildrop for the POP subscriber
+ (relative to the POP directory)
+ encrypted password the POP subscriber's password
+ network address the remote user allowed to RPOP
+
+ This is an ASCII file. Each field within each POP subscriber's
+ entry is separated from the next by a colon. Each POP subscriber
+ is separated from the next by a new-line. If the password field is
+ null, then no password is valid.
+
+ To add a new POP subscriber, edit the file adding a line such as
+
+ mrose::mrose:::::::0
+
+ Then, use _p_o_p_w_r_d to set the password for the POP
subscriber. If
+ you wish to allow POP subscribers to access their maildrops without
+ supplying a password (by using privileged ports), fill-in the net-
+ work address field, as in:
+
+ mrose::mrose:::address@hidden::::0
+
+ which permits "address@hidden" 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::address@hidden,address@hidden::::
+
+ To disable a POP subscriber from _r_e_c_e_i_v_i_n_g mail,
set the primary
+ file name to the empty string. To prevent a POP subscriber from
+ _p_i_c_k_i_n_g-_u_p mail, set the encrypted password to "*"
and set the net-
+ work address to the empty string.
+
+ This file resides in home directory of the login "pop". Because of
+ the encrypted passwords, it can and does have general read permis-
+ sion.
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POP(5) -24- POP(5)
+
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), pop(8), popaka(8), popd(8), popwrd(8)
+
+
+ _B_u_g_s
+ A binary indexed file format should be available for fast access.
+
+ Appropriate precautions must be taken to lock the file against
+ changes if it is to be edited with a text editor. A _v_i_p_o_p
program
+ is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POP(8) -25- POP(8)
+
+
+ _N_A_M_E
+ pop - POP channel/mailer
+
+ _S_Y_N_O_P_S_I_S
+ /usr/mmdf/chans/pop fd1 fd2 [y]
+
+ /usr/local/lib/mh/spop POP-subscriber ...
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ For _M_M_D_F-_I_I, the POP channel delivers mail to the POP
spool area
+ for later retrieval by POP subscribers. For
_S_e_n_d_M_a_i_l, the SPOP
+ mailer performs this task.
+
+ For each address given, these programs consult the _p_o_p (5) file
to
+ obtain information about the POP-subscriber named by the address.
+ The programs then deliver the message to the spool area for the
+ POP-subscriber.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbaka(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POPAKA(8) -26- POPAKA(8)
+
+
+ _N_A_M_E
+ popaka - generate POP entries for SendMail or MMDF-II alias file
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/popaka
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_a_k_a program reads the POP database and produces on
its stan-
+ dard output a file suitable for inclusion in the SendMail or
+ _M_M_D_F-_I_I aliases file. The contents of this file divert
mail for
+ POP subscribers to the POP channel.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POPD(8) -27- POPD(8)
+
+
+ _N_A_M_E
+ popd - the POP server
+
+ _S_Y_N_O_P_S_I_S
+ /usr/etc/popd [-p portno] (under /etc/rc.local)
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_d server implements the Post Office protocol, as
described
+ in RFC1081 and RFC1082. Basically, the server listens on the TCP
+ port named "pop" for connections and enters the POP upon establish-
+ ing a connection. The `-p' option overrides the default TCP port.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3: _E_x_t_e_n_d_e_d _s_e_r_v_i_c_e
_o_f_f_e_r_i_n_g_s
+ (RFC-1082),
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ For historical reasons, the _M_H POP defaults to using the port named
+ "pop" (109) instead of its newly assigned port named "pop3" (110).
+ See the POPSERVICE configuration option for more details.
+
+ Previous versions of the server (10/28/84) had the restriction that
+ the POP client may retrieve messages for login users only. This
+ restriction has been lifted, and true POB support is available
+ (sending mail to a mailbox on the POP service host which does not
+ map to a user-id in the password file).
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POPWRD(8) -28- POPWRD(8)
+
+
+ _N_A_M_E
+ popwrd - set password for a POP subscriber
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/popwrd POP-subscriber
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_w_r_d program lets the super-user or the master POP
user or a
+ "leader" of a POP subscriber change the password field for the POP
+ subscriber in the POP database. This program is very similar to
+ the _p_a_s_s_w_d (1) program.
+
+ Since only the super-user and the master POP user may change any
+ other fields of the POP database (using an ordinary editor), it is
+ possible for the system administrator to delegate responsibility to
+ others to manage groups of POP subscribers.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Although _p_o_p_w_r_d does locking against other invocations of
_p_o_p_w_r_d,
+ editor locking for the POP database in general is not implemented.
+ A _v_i_p_o_p program is needed.
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _5. _M_A_I_L _F_I_L_T_E_R_I_N_G
+
+
+
+9
+ There was a time when users on a UNIX host might have had two mail-
+ drops: one from _M_M_D_F and the other from _U_U_C_P. This
was really a bad
+ problem since it prevented using a single user-interface on all of your
+ mail. Furthermore, if you wanted to send a message to addresses on dif-
+ ferent mailsystems, you couldn't send just one message. To solve all
+ these problems, the notion of _m_a_i_l _f_i_l_t_e_r_i_n_g
was developed that allowed
+ sophisticated munging and relaying between the two pseudo-domains.
+
+ _M_H will perform mail filtering, transparently, if given the MF
con-
+ figuration option. However, with the advent of
_S_e_n_d_M_a_i_l and further
+ maturation of _M_M_D_F, _M_H doesn't really need to do this
anymore, since
+ these message transport agents handle it.
+
+ The mail-filtering stuff is too complicated. It should be simpler,
+ but, protocol translation really _i_s difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 -29-
+
+
+
+
+
+
+
+
+
+ MF(1) -30- MF(1)
+
+
+ _N_A_M_E
+ muinc, musift, uminc, umsift - mail filters
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/muinc
+
+ /usr/local/lib/mh/musift [files ...]
+
+ /usr/local/lib/mh/uminc
+
+ /usr/local/lib/mh/umsift [files ...]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The mail filters are a set of programs that filter mail from one
+ format to another. In particular, _U_U_C_P- and
_M_M_D_F-style mail files
+ are handled.
+
+ _m_u_i_n_c filters mail from the user's _M_M_D_F maildrop
into the user's
+ _U_U_C_P maildrop; similarly, _u_m_i_n_c filters mail from
the user's _U_U_C_P
+ maildrop into the user's _M_M_D_F maildrop. These two programs
respect
+ each system's maildrop locking protocols.
+
+ _m_u_s_i_f_t filters each file on the command line (or the
standard input
+ if no arguments are given), and places the result on the standard
+ output in _U_U_C_P format. The files (or standard input) are
expected
+ to be in _M_M_D_F format. _u_m_s_i_f_t does the same
thing filtering _U_U_C_P
+ formatted files (or input), and places the _M_M_D_F formatted
result on
+ the standard output. No locking protocols are used by these pro-
+ grams.
+
+ If the files aren't in the expected format, the mail filters will
+ try to recover. In really bad cases, you may lose big.
+
+ _F_i_l_e_s
+ /usr/spool/mail/ UUCP spool area for maildrops
+ /usr/spool/mail/$USER Location of standard maildrop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _H_e_a_d_e_r _M_u_n_g_i_n_g (aka RFC-886),
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MF(1) -31- MF(1)
+
+
+ _C_o_n_t_e_x_t
+
+
+ _B_u_g_s
+ Numerous; protocol translation is very difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RMAIL(8) -32- RMAIL(8)
+
+
+ _N_A_M_E
+ rmail - UUCP interface to mail
+
+ _S_Y_N_O_P_S_I_S
+ rmail address ...
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_a_i_l is intended as a replacement for those systems without
_S_e_n_d_-
+ _M_a_i_l or _M_M_D_F. It is normally invoked by
_u_u_x on behalf of the
+ remote _U_U_C_P site. For each address, it decides where to send
it:
+ either locally, via another _U_U_C_P link, or via the Internet.
+
+ _R_m_a_i_l implements a crude access control facility by
consulting the
+ files Rmail.OkHosts and Rmail.OkDests in the /usr/local/lib/mh/
+ directory. Hosts listed in the former file can send messages to
+ anywhere they please. Hosts listed in the latter file can receive
+ messages from anywhere. Note that a host listed in the first file
+ is implicitly listed in the second file.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/local/lib/mh/Rmail.OkHosts list of privileged hosts
+ /usr/local/lib/mh/Rmail.OkDests list of privileged destinations
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mf(1)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _6. _M_H _H_A_C_K_I_N_G
+
+
+
+9
+ Finally, here's a little information on modifying the _M_H
sources.
+ A word of advice however:
+
+
+ _D_O_N'_T
+
+
+
+ If you really want new _M_H capabilities, write a shell script
instead.
+ After all, that's what UNIX is all about, isn't it?
+
+ Here's the organization of the _M_H source tree.
+
+ conf/ configurator tree
+ config/ compiled configuration constants
+ dist/ distributor
+ doc/ manual entries
+ h/ include files
+ miscellany/ various sundries
+ mts/ MTS-specific areas
+ mh/ standalone delivery
+ mmdf/ MMDF-I, MMDF-II
+ sendmail/ SendMail, SMTP
+ papers/ papers about _M_H
+ sbr/ subroutines
+ support/ support programs and files
+ bboards/ UCI BBoards facility
+ general/ templates
+ pop/ POP facility
+ tma/ Trusted Mail Agent (not present in all distributions)
+ uip/ programs
+ zotnet/ MTS-independent areas
+ bboards/ UCI BBoards facility
+ mf/ Mail Filtering
+ mts/ MTS constants
+ tws/ date routines
+
+
+
+
+
+
+
+
+
+
+
+9 -33-
+
+
+
+
+
+
+
+
+
+ MH-HACK(8) -34- MH-HACK(8)
+
+
+ _N_A_M_E
+ mh-hack - how to hack MH
+
+ _S_Y_N_O_P_S_I_S
+ big hack attack
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This is a description of how one can modify the _M_H system. The
_M_H
+ distribution has a lot of complex inter-relations, so before you go
+ modifying any code, you should read this and understand what is
+ going on.
+
+ ADDING A NEW PROGRAM
+ Suppose you want to create a new _M_H command called "pickle".
+ First, create and edit "pickle.c" in the uip/ directory. Next
+ edit conf/makefiles/uip to include "pickle". This file has
+ directions at the end of it which explain how it should be
+ modified. Next, update any documentation (described below).
+ At this point you can re-configure _M_H. See
_m_h-_g_e_n(_8) for
+ instructions on how to do this (basically, you want "mhconfig
+ MH").
+
+ ADDING A NEW SUBROUTINE
+ Suppose you want to create a new _M_H routine called "pickle".
+ First, create and edit "pickle.c" in the sbr/ directory. Next
+ edit conf/makefiles/sbr to include "pickle". This file has
+ directions at the end of it which explain how it should be
+ modified. You should modify config/mh.h to define "pickle
+ ();". Similarly, sbr/llib-lsbr should be modified for
_l_i_n_t.
+ At this point you can re-configure _M_H.
+
+ UPDATING DOCUMENTATION
+ Edit whatever files you want in conf/doc/. When documenting a
+ new program, such as "pickle", you should create a manual page
+ with the name "pickle.rf". The file conf/doc/template has a
+ manual page template that you can use. If you are documenting
+ a new program, then you should also update three other files:
+ The file conf/doc/mh.rf should be modified to include the
+ ".NA" section from "pickle.rf". The file conf/doc/mh-chart.rf
+ should be modified to include the ".SY" section from
+ "pickle.rf". Finally, the file conf/doc/MH.rf should be modi-
+ fied to include a ".so pickle.me". Naturally, none of these
+ changes will be reflected in the configuration until you actu-
+ ally run _m_h_c_o_n_f_i_g.
+
+ _F_i_l_e_s
+ Too numerous to mention. Honest.
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-HACK(8) -35- MH-HACK(8)
+
+
+ _S_e_e _A_l_s_o
+ mh-gen(8)
+
+
+ _B_u_g_s
+ Hacking is an art, but most programmers are butchers, not artists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _7. _H_I_D_D_E_N
_F_E_A_T_U_R_E_S
+
+
+
+9
+ The capabilities discussed here should not be used on a production
+ basis, as they are either experimental, are useful for debugging
_M_H, or
+ are otherwise not recommended.
+
+
+
+9 _D_e_b_u_g _F_a_c_i_l_i_t_i_e_s
+
+ The _m_a_r_k command has a `-debug' switch which essentially
prints out
+ all the internal _M_H data structures for the folder you're looking
at.
+
+ The _p_o_s_t command has a `-debug' switch which does
everything but
+ actually post the message for you. Instead of posting the draft, it
+ sends it to the standard output. Similarly, _s_e_n_d has a
`-debug' switch
+ which gets passed to _p_o_s_t.
+
+ Some _M_H commands look at envariables to determine debug-mode
opera-
+ tion of certain new facilities. The current list of envariables is:
+
+ MHFDEBUG OVERHEAD facility
+ MHLDEBUG mhl
+ MHPDEBUG pick
+ MHPOPDEBUG POP transactions
+ MHVDEBUG window management transactions
+ MHWDEBUG alternate-mailboxes
+
+
+
+9 _F_o_r_w_a_r_d_i_n_g _M_a_i_l
+
+ The _f_o_r_w and _m_h_l commands have two switches,
`-dashmunging' and
+ `-nodashmunging' which enable or disable the prepending of `- ' in for-
+ warded messages. To use `-nodashmunging', you must use an _m_h_l
filter
+ file.
+
+
+
+9 _S_e_n_d
+
+ The _s_e_n_d command has two switches, `-unique' and
`-nounique', which
+ are useful to certain individuals who, for obscure reasons, do not use
+ draft-folders.
+
+ "Distribution Carbon Copy" addresses may be specified in the
_D_c_c:
+ header. This header is removed before posting the message,and a copy of
+
+ -36-
+
+
+
+
+
+
+
+
+
+ -37-
+
+
+ the message is distributed to each listed address. This could be con-
+ sidered a form of Blind Carbon Copy which is best used for sending to an
+ address which would never reply (such as an auto-archiver).
+
+
+
+9 _P_o_s_t_i_n_g _M_a_i_l
+
+ If you're running a version of _M_H which talks directly to an
_S_M_T_P
+ server (or perhaps an advanced _M_M_D_F submit process), there
are lots of
+ interesting switches for your amusement which _s_e_n_d and
_p_o_s_t understand:
+ -mail Use the _M_A_I_L command (default)
+ -saml Use the _S_A_M_L command
+ -send Use the _S_E_N_D command
+ -soml Use the _S_O_M_L command
+ -snoop Watch the _S_M_T_P transaction
+ -client host Claim to be "host" when posting mail
+ -server host Post mail with "host"
+
+ The last switch is to be useful when _M_H resides on small
worksta-
+ tions (or PC:s) in a network--they can post their outgoing mail with a
+ local relay, and reduce the load on the local system. On POP client
+ hosts, the `-server host' switch is defaulted appropriately using the
+ SMTP search-list mechanism. The _w_h_o_m command understands the
last three
+ switches.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _8. _C_O_N_F_I_G_U_R_A_T_I_O_N
_O_P_T_I_O_N_S
+
+
+
+9
+ This manual was generated with the following configuration options
+ in effect:
+
+
+ ________________________________________________________________________
+
+ Generation Date February 1, 1991
+ Primary Directory /usr/local/
+ Secondary Directory /usr/local/lib/mh/
+ Maildrop Location /usr/spool/mail/$USER
+ POP Support Enabled
+ BBoards using NNTP Enabled
+ Transport System MMDF-II with SMTP
+ ________________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 -38-
+
+
+
+
+
+
+
+
+
+
+
+
+ _C_O_N_T_E_N_T_S
+
+
+
+
+ Section
+
+ 1. INTRODUCTION ............................................... 1
+9 Scope of this document .......................................
1
+9 Summary ......................................................
1
+
+ 2. THE MTS INTERFACE .......................................... 3
+ MH-TAILOR ................................................. 4
+ MH-MTS .................................................... 10
+
+ 3. BBOARDS .................................................... 12
+9 BBoard Delivery ..............................................
12
+9 BBoards with the POP .........................................
13
+9 BBoards with the NNTP ........................................
14
+ BBOARDS ................................................... 15
+ BBAKA ..................................................... 16
+ BBEXP ..................................................... 17
+ BBOARDS ................................................... 18
+ BBTAR ..................................................... 19
+
+ 4. POP ........................................................ 20
+ POP ....................................................... 23
+ POP ....................................................... 25
+ POPAKA .................................................... 26
+ POPD ...................................................... 27
+ POPWRD .................................................... 28
+
+ 5. MAIL FILTERING ............................................. 29
+ MF ........................................................ 30
+ RMAIL ..................................................... 32
+
+ 6. MH HACKING ................................................. 33
+ MH-HACK ................................................... 34
+
+ 7. HIDDEN FEATURES ............................................ 36
+9 Debug Facilities .............................................
36
+9 Forwarding Mail ..............................................
36
+9 Send .........................................................
36
+9 Posting Mail .................................................
37
+
+ 8. CONFIGURATION OPTIONS ...................................... 38
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 THE RAND MH
+
+9 MESSAGE HANDLING
+
+9 SYSTEM:
+
+9 ADMINISTRATOR'S GUIDE
+
+
+
+
+
+
+ UCI Version
+
+
+
+
+
+ Marshall T. Rose
+
+
+
+
+ _F_i_r_s_t _E_d_i_t_i_o_n:
+
+ _M_H _C_l_a_s_s_i_c
+
+ (_N_o_t _t_o _b_e _c_o_n_f_u_s_e_d _w_i_t_h _a
_w_e_l_l-_k_n_o_w_n _s_o_f_t _d_r_i_n_k)
+
+
+
+
+
+
+
+ February 1, 1991
+
+ 6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
diff --git a/docs/historical/ADMIN.pdf b/docs/historical/ADMIN.pdf
new file mode 100644
index 0000000..f716c79
Binary files /dev/null and b/docs/historical/ADMIN.pdf differ
diff --git a/docs/historical/ADMIN.txt b/docs/historical/ADMIN.txt
new file mode 100644
index 0000000..8e4cda8
--- /dev/null
+++ b/docs/historical/ADMIN.txt
@@ -0,0 +1,2904 @@
+
+
+
+
+
+
+
+
+ _d_i_s_c_a_r_d _t_h_i_s
_p_a_g_e
+
+
+
+
+ The RAND _M_H
+ Message Handling
+ System:
+ Administrator's Guide
+
+ UCI Version
+
+
+ November 30, 1993
+ 6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _1.
_I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+
+
+ _S_c_o_p_e _o_f _t_h_i_s _d_o_c_u_m_e_n_t
+
+ This is the Administrator's Guide to _M_H. If you
don't maintain an
+ _M_H system, don't read this; the information is entirely
too technical.
+ If you are a maintainer, then read this guide until you
understand it,
+ follow the advice it gives, and then forget about the guide.
+
+ Before continuing, I'll point out two facts:
+
+
+
+ _T_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l
_n_e_v_e_r _c_o_n_t_a_i_n _a_l_l _t_h_e
_i_n_f_o_r_m_a_t_i_o_n
+ _y_o_u _n_e_e_d _t_o
_m_a_i_n_t_a_i_n _M_H.
+
+ _F_u_r_t_h_e_r_m_o_r_e, _t_h_i_s
_d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n
_e_v_e_r_y_t_h_i_n_g
+ _I _k_n_o_w _a_b_o_u_t
_m_a_i_n_t_a_i_n_i_n_g _M_H.
+
+
+
+ _M_H, and mailsystems in general, are more complex than
most people real-
+ ize. A combination of experience, intuition, and tenacity
is required
+ to maintain _M_H properly. This document can provide only
guidelines for
+ bringing up an _M_H system and maintaining it. There
is a sufficient
+ amount of customization possible that not all events or
problems can be
+ forseen.
+
+
+
+ _S_u_m_m_a_r_y
+
+ During _M_H generation, you specify several
configuration constants
+ to the _m_h_c_o_n_f_i_g program. These directives
take into consideration such
+ issues as hardware and operating system dependencies in the
source code.
+ They also factor out some major mailsystem administrative
decisions that
+ are likely to be made consistantly at sites with more than
one host.
+ The manual entry _m_h-_g_e_n (8) describes all the
static configuration
+ directives.
+
+ However, when you install _M_H you may wish
to make some
+ site-specific or host-specific changes which aren't
hardware or even
+ software related. Rather, they are administrative
decisions. That's
+ what this guide is for: it describes all of the dynamically
tailorable
+ directives.
+
+
+
+
+
+
+
+
+
+
+
+
+ -2-
+
+
+ Usually, after installing _M_H, you'll want
to edit the
+ /usr/local/lib/mh/mtstailor file. This file fine-tunes
the way _M_H
+ interacts with the message transport system (MTS).
Section 2 talks
+ about the MTS interface and MTS tailoring.
+
+ After that, if you're running the UCI BBoards facility,
or the POP
+ facility, you'll need to know how to maintain those systems.
Sections 3
+ and 4 talk about these.
+
+ If for some reason you're not running an MTS that can
handle both
+ Internet and _U_U_C_P traffic, you should read-up on
mail filtering in Sec-
+ tion 5. Although this is considered "old technology" now,
the mechan-
+ isms described in Section 5 were really quite useful when
first intro-
+ duced way back in 1981.
+
+ Finally, you may want to know how to modify the _M_H
source tree.
+ Section 6 talks (a little bit) about that.
+
+ The last two sections describe a few hidden features in
_M_H, and the
+ configuration options that were in effect when this guide was
generated.
+
+ After _M_H is installed, you should define the
address "Bug-MH" to
+ map to either you or the _P_o_s_t_M_a_s_t_e_r at
your site.
+
+ In addition, if you want to tailor the behavior of
_M_H for new
+ users, you can create and edit the file
/usr/local/lib/mh/mh.profile.
+ When the _i_n_s_t_a_l_l-_m_h program is run for a
user, if this file exists, it
+ will copy it into the user's .mh_profile file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _2. _T_H_E _M_T_S
_I_N_T_E_R_F_A_C_E
+
+
+
+
+
+ The file /usr/local/lib/mh/mtstailor customizes
certain
+ host-specific parameters of _M_H related primarily to
interactions with
+ the transport system. The parameters in this file
override the
+ compiled-in defaults given during _M_H configuration.
Rather than recom-
+ piling _M_H on each host to make minor customizations, it
is easier simply
+ to modify the mtstailor file. All hosts at a given site
normally use
+ the same mtstailor file, though this need not be the case.
+
+ It is a good idea to run the _c_o_n_f_l_i_c_t
(8) program each morning
+ under _c_r_o_n. The following line usually suffices:
+
+ 00 05 * * * /usr/local/lib/mh/conflict -mail PostMaster
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -3-
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -4-
MH-TAILOR(5)
+
+
+ _N_A_M_E
+ mh-tailor, mtstailor - system customization for MH message
handler
+
+
+ _S_Y_N_O_P_S_I_S
+
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_m_t_s_t_a_i_l_o_r
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The file /usr/local/lib/mh/mtstailor defines run-time
options for
+ those _M_H programs which interact (in some form) with
the message
+ transport system. At present, these (user) programs are:
_a_p, _c_o_n_-
+ _f_l_i_c_t, _i_n_c, _m_s_g_c_h_k, _m_s_h,
_p_o_s_t, _r_c_v_d_i_s_t, and _r_c_v_p_a_c_k.
+
+ Each option should be given on a single line. Blank
lines and
+ lines which begin with `#' are ignored. The options
available
+ along with default values and a description of their
meanings are
+ listed below:
+
+ localname:
+ The host name _M_H considers local. If not set,
depending on
+ the version of UNIX you're running, _M_H will query
the system
+ for this value (e.g., <whoami.h>, gethostname, etc.).
This
+ has no equivalent in the _M_H configuration file.
POP client
+ hosts should set this value to the name of the POP
service
+ host.
+
+ localdomain:
+ If this is set, a `.' followed by this string will be
appended
+ to your host name. This might be useful for sites
where the
+ host name returned by the system (e.g., <whoami.h>,
gethost-
+ name, etc.), is not a "fully qualified domain name"
(i.e.,
+ does not contain a `.').
+
+ clientname:
+ The host name _M_H will give in the SMTP HELO (and
EHLO) com-
+ mand, when posting mail. If not set, no HELO command
will be
+ given. Although the HELO command is required by RFC
821, many
+ SMTP servers do not require it.
+
+ Early versions of SendMail will fail if the host name
given in
+ the HELO command is the local host; later versions of
SendMail
+ will complain if you omit the HELO command. If you run
Send-
+ Mail, find out what your system expects and set this
field
+ accordingly.
+
+ systemname:
+ The name of the local host in the _U_U_C_P "domain".
If not set,
+ depending on the version of UNIX you're running, _M_H
will query
+ the system for this value. This has no equivalent in
the _M_H
+ configuration file.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -5-
MH-TAILOR(5)
+
+
+ mmdfldir: /usr/spool/mail
+ The directory where maildrops are kept. If this is
empty, the
+ user's home directory is used. This overrides the
"mail"
+ field in the _M_H configuration file.
+
+ mmdflfil:
+ The name of the maildrop file in the directory where
maildrops
+ are kept. If this is empty, the user's login name is
used.
+ This overrides the "mail" field in the _M_H
configuration file.
+
+ mmdelim1: \001\001\001\001\n
+ The beginning-of-message delimiter for maildrops.
+
+ mmdelim2: \001\001\001\001\n
+ The end-of-message delimiter for maildrops.
+
+ mmailid: 0
+ If non-zero, then support for MMailids in
/etc/passwd is
+ enabled. Basically, the pw_gecos field in the
password file
+ is of the form
+
+ My Full Name <mailid>
+
+ The _M_H internal routines that deal with user and
full names
+ will return "mailid" and "My Full Name" respectively.
+
+ lockstyle: 0
+ The locking discipline to perform. A value of "0"
means to
+ use kernel-level locking if available. (See below
for more
+ details.) On systems compiled without kernel-level
locking,
+ standard _B_e_l_l_M_a_i_l locking is used. A
value of "1" means to
+ use _B_e_l_l_M_a_i_l locking always (the name of
the lock is based on
+ the file name). A value of "2" means to use
_M_M_D_F locking
+ always (the name of the lock is based on device/inode
pairs).
+
+ lockldir:
+ The name of the directory for making locks. If your
system
+ isn't configured to use kernel-level locking, then this
direc-
+ tory is used when creating locks. If the value is
empty, then
+ the directory of the file to be locked is used.
+
+ maildelivery: /usr/local/lib/mh/maildelivery
+ The name of the system-wide default
._m_a_i_l_d_e_l_i_v_e_r_y file. See
+ _m_h_o_o_k (1) for the details.
+
+ everyone: 200
+ The highest user-id which should NOT receive mail
addressed to
+ "everyone".
+
+ noshell:
+ If set, then each user-id greater than "everyone" that
has a
+ login shell equivalent to the given value (e.g.,
"/bin/csh")
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -6-
MH-TAILOR(5)
+
+
+ indicates that mail for "everyone" should not be sent to
them.
+ This is useful for handling admin, dummy, and guest
logins.
+
+ _M_a_i_l _F_i_l_t_e_r_i_n_g
+
+ These options are only available if you compiled
_M_H with
+ "options MF".
+
+ uucpchan: name of _U_U_C_P channel
+ Usually "UUCP". This has no equivalent in the _M_H
configura-
+ tion file.
+
+ uucpldir: /usr/spool/mail
+ The name of the directory where _U_U_C_P maildrops
are kept. This
+ has no equivalent in the _M_H configuration file.
+
+ uucplfil:
+ The name of the maildrop file in the directory where
_U_U_C_P
+ maildrops are kept. If this is empty, the user's
login name
+ is used. This has no equivalent in the _M_H
configuration file.
+
+ umincproc: /usr/local/lib/mh/uminc
+ The path to the program that filters _U_U_C_P-style
maildrops to
+ _M_M_D_F-style maildrops.
+
+ _S_t_a_n_d-_A_l_o_n_e _D_e_l_i_v_e_r_y
+
+ These options are only available if you compiled _M_H to
use stand-
+ alone delivery (i.e., "mts: mh").
+
+ mailqdir: /usr/spool/netmail
+ The directory where network mail is queued.
+
+ tmailqdir: /usr/tmp
+ The directory where network mail queue files are built.
+
+ syscpy: 1
+ If ON, unauthorized mail is copied to the overseer.
+
+ overseer: root
+ The user that receives reports of unauthorized mail.
+
+ mailer: root
+ The user acting for the mail system.
+
+ fromtmp: /tmp/rml.f.XXXXXX
+ The _m_k_t_e_m_p template for storing from lines.
+
+ msgtmp: /tmp/rml.m.XXXXXX
+ The _m_k_t_e_m_p template for storing the rest of
the message.
+
+ errtmp: /tmp/rml.e.XXXXXX
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -7-
MH-TAILOR(5)
+
+
+ The _m_k_t_e_m_p template for storing error
messages from other
+ mailers.
+
+ tmpmode: 0600
+ The octal mode which temporary files are set to.
+
+ okhosts: /usr/local/lib/mh/Rmail.OKHosts
+ A file containing a list of hosts that can send ARPAnet
mail.
+
+ okdests: /usr/local/lib/mh/RMail.OKDests
+ A file containing a list of hosts that can always
receive
+ mail.
+
+ _T_h_e `/_s_m_t_p' _M_T_S _S_u_f_f_i_x
+
+ These options are only available if you compiled _M_H
with the
+ "/smtp" suffix to your "mts:" configuration.
+
+ hostable: /usr/local/lib/mh/hosts
+ The exceptions file for /etc/hosts used by _p_o_s_t
to try to find
+ official names. The format of this file is quite simple:
+
+ 1. Comments are surrounded by sharp (`#') and
newline.
+ 2. Words are surrounded by white space.
+ 3. The first word on the line is the official name
of a
+ host.
+ 4. All words following the official names are
aliases for
+ that host.
+
+ servers: localhost \01localnet
+ A lists of hosts and networks which to look for SMTP
servers
+ when posting local mail. It turns out this is a major
win for
+ hosts which don't run an message transport system. The
value
+ of "servers" should be one or more items. Each item
is the
+ name of either a host or a net (in the latter case,
precede
+ the name of the net by a \01). This list is
searched when
+ looking for a smtp server to post mail. If a host is
present,
+ the SMTP port on that host is tried. If a net is
present, the
+ SMTP port on each host in that net is tried. Note that
if you
+ are running with the BIND code, then any networks
specified
+ are ignored (sorry, the interface went away under BIND).
+
+ _S_e_n_d_M_a_i_l
+
+ This option is only available if you compiled _M_H to use
_S_e_n_d_M_a_i_l as
+ your delivery agent (i.e., "mts: sendmail").
+
+ sendmail: /usr/lib/sendmail
+ The pathname to the _s_e_n_d_m_a_i_l program.
+
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -8-
MH-TAILOR(5)
+
+
+ This option is only available if you compiled _M_H with
POP support
+ enabled (i.e., "pop: on").
+
+ pophost:
+ The name of the default POP service host. If this is
not set,
+ then _M_H looks in the standard maildrop areas for
waiting mail,
+ otherwise the named POP service host is consulted.
+
+ _B_B_o_a_r_d_s _D_e_l_i_v_e_r_y
+
+ This option is only available if you compiled
_M_H with
+ "bbdelivery: on".
+
+ bbdomain:
+ The local BBoards domain (a UCI hack).
+
+ _B_B_o_a_r_d_s & _T_h_e _P_O_P
+
+ These options are only available if you compiled
_M_H with
+ "bboards: pop" and "pop: on".
+
+ popbbhost:
+ The POP service host which also acts as a BBoard server.
This
+ variable should be set on the POP BBoards client host.
+
+ popbbuser:
+ The guest account on the POP/BB service host. This
should be
+ a different login ID than either the POP user or the
BBoards
+ user. (The user-id "ftp" is highly recommended.) This
vari-
+ able should be set on both the POP BBoards client and
service
+ hosts.
+
+ popbblist: /usr/local/lib/mh/hosts.popbb
+ A file containing of lists of hosts that are allowed
to use
+ the POP facility to access BBoards using the guest
account.
+ If this file is not present, then no check is made.
This
+ variable should be set on the POP BBoards service host.
+
+ _B_B_o_a_r_d_s & _T_h_e _N_N_T_P
+
+ This option is only available if you compiled
_M_H with
+ "bboards: nntp" and "pop: on".
+
+ nntphost:
+ The host which provides the NNTP service. This
variable
+ should be set on the NNTP BBoards client host.
+
+ _F_i_l_e _L_o_c_k_i_n_g
+
+ A few words on locking: _M_H has a flexible locking system
for making
+ locks on files. There are two mtstailor variables you
should be
+ aware of "lockstyle" and "lockldir". The first controls the
method
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-TAILOR(5) -9-
MH-TAILOR(5)
+
+
+ of locking, the second says where lock files should be
created.
+
+ The "lockstyle" variable can take on three values: 0, 1,
2. A
+ value of 0 is useful on systems with kernel-level locking.
If you
+ are on a BSD42 system, _M_H assumes you have the
_f_l_o_c_k system call.
+ On other systems: define FLOCK if you want to use the
_f_l_o_c_k system
+ call; define LOCKF if you want to use the _l_o_c_k_f
system call; or
+ define FCNTL if you want to use the _f_c_n_t_l system
call for kernel-
+ level locking. If you haven't configured _M_H to use
kernel-level
+ locking, a locking style of 0 is considered the same as
locking
+ style 1.
+
+ A value of 1 or 2 specifies that a file should be created
whose
+ existence means "locked" and whose non-existence means
"unlocked".
+ A value of 1 says to construct the lockname by appending
".lock" to
+ the name of the file being locked. A value of 2 says to
construct
+ the lockname by looking at the device and inode numbers of
the file
+ being locked. If the "lockldir" variable is not
specified, lock
+ files will be created in the directory where the file being
locked
+ resides. Otherwise, lock files will be created in the
directory
+ specified by "lockldir". Prior to installing _M_H, you
should see
+ how locking is done at your site, and set the appropriate
values.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mh-gen(8), mh-mts(8)
+
+
+ _D_e_f_a_u_l_t_s
+ As listed above
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MTS(8) -10-
MH-MTS(8)
+
+
+ _N_A_M_E
+ mh-mts - the MH interface to the message transport system
+
+ _S_Y_N_O_P_S_I_S
+ SendMail
+
+ Zmailer
+
+ MMDF (any release)
+
+ stand-alone
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H can use a wide range of message transport systems
to deliver
+ mail. Although the _M_H administrator usually doesn't get
to choose
+ which MTS to use (since it's already in place), this
document
+ briefly describes the interfaces.
+
+ When communicating with _S_e_n_d_M_a_i_l, _M_H
always uses the SMTP to post
+ mail. Depending on the _M_H configuration,
_S_e_n_d_M_a_i_l may be invoked
+ directly (via a _f_o_r_k and an _e_x_e_c), or _M_H
may open a TCP/IP connec-
+ tion to the SMTP server on the localhost.
+
+ When communicating with _z_m_a_i_l_e_r, the
_S_e_n_d_M_a_i_l compatibility program
+ is required to be installed in /usr/lib. _M_H
communicates with
+ _z_m_a_i_l_e_r by using the SMTP. It does this
by invoking the
+ /usr/lib/sendmail compatibility program directly, with the
`-bs'
+ option.
+
+ When communicating with _M_M_D_F, normally _M_H uses
the "mm_" routines
+ to post mail. However, depending on the _M_H
configuration, _M_H
+ instead may open a TCP/IP connection to the SMTP server
on the
+ localhost.
+
+ When using the stand-alone system (NOT recommended), _M_H
delivers
+ local mail itself and queues _U_U_C_P and network
mail. The network
+ mail portion will probably have to be modified to reflect the
local
+ host's tastes, since there is no well-known practice in
this area
+ for all types of UNIX hosts.
+
+ If you are running a UNIX system with TCP/IP networking, then
it is
+ felt that the best interface is achieved by using either
_S_e_n_d_M_a_i_l
+ or _M_M_D_F with the SMTP option. This gives greater
flexibility. To
+ enable this option you append the /smtp suffix to the mts
option in
+ the _M_H configuration. This yields two primary
advantages: First,
+ you don't have to know where _s_u_b_m_i_t or
_S_e_n_d_M_a_i_l live. This means
+ that _M_H binaries (e.g., _p_o_s_t ) don't have to have
this information
+ hard-coded, or can run different programs altogether; and,
second,
+ you can post mail with the server on different systems,
so you
+ don't need either _M_M_D_F or _S_e_n_d_M_a_i_l
on your local host. Big win in
+ conserving cycles and disk space. Since _M_H supports the
notion of
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MTS(8) -11-
MH-MTS(8)
+
+
+ a server search-list in this respect, this approach can be
tolerant
+ of faults. Be sure to set "servers:" as described in
mh-tailor(8)
+ if you use this option.
+
+ There are four disadvantages to using the SMTP option: First,
only
+ UNIX systems with TCP/IP are supported. Second, you need
to have
+ an SMTP server running somewhere on any network your local
host can
+ reach. Third, this bypasses any authentication mechanisms
in _M_M_D_F
+ or _S_e_n_d_M_a_i_l. Fourth, the file /etc/hosts
is used for hostname
+ lookups (although there is an exception file). In
response to
+ these disadvantages though: First, there's got to be an SMTP
server
+ somewhere around if you're in the Internet or have a local
network.
+ Since the server search-list is very general, a
wide-range of
+ options are possible. Second, SMTP should be fixed to have
authen-
+ tication mechanisms in it, like POP. Third, _M_H won't
choke on mail
+ to hosts whose official names it can't verify, it'll
just plug
+ along (and besides if you enable the BERK or DUMB
configuration
+ options, _M_H ignores the hosts file altogether).
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _M_M_D_F-_I_I: _A _T_e_c_h_n_i_c_a_l
_R_e_v_i_e_w, Proceedings, Usenix Summer '84 Confer-
+ ence
+ _S_E_N_D_M_A_I_L -- _A_n
_I_n_t_e_r_n_e_t_w_o_r_k _M_a_i_l _R_o_u_t_e_r
+ mh-tailor(8), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The /usr/local/lib/mh/mtstailor file ignores the information
in the
+ _M_M_D_F-_I_I tailoring file. It should not.
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _3. _B_B_O_A_R_D_S
+
+
+
+
+
+ The UCI BBoards facility has two aspects: message
reading, and mes-
+ sage delivery. The configuration directives applicable to
BBoards are
+ "bboards: on/off/pop/nntp" and "bbdelivery: on/off".
+
+
+ _B_B_o_a_r_d _D_e_l_i_v_e_r_y
+
+ If you enabled BBoards delivery ("bbdelivery: on")
during confi-
+ guration, then the initial environment for bboards delivery
was set-up
+ during installation. A BBoard called "system" is
established, which is
+ the BBoard for general discussion.
+
+ To add more BBoards, become the "bboards" user, and
edit the
+ /usr/spool/bboards/BBoards file. The file
support/bboards/Example is a
+ copy of the /usr/spool/bboards/BBoards file that we use at
UCI. When
+ you add a BBoard, you don't have to create the files
associated with it,
+ the BBoards delivery system will do that automatically.
+
+ Private BBoards may be created. To add the
fictitious private
+ BBoard "hacks", add the appropriate entry to the BBoards
file, create
+ the empty file /usr/spool/bboards/hacks.mbox (or whatever),
change the
+ mode of this file to 0640, and change the group of the
file to be the
+ groupid of the people that you want to be able to read it.
Also be sure
+ to add the "bboards" user to this group (in /etc/group), so
the archives
+ can be owned correctly.
+
+ By using the special INVIS flag for a BBoard,
special purpose
+ BBoards may be set-up which are invisible to the _M_H
user. For example,
+ if a site distributes a BBoard both locally to a number of
machines and
+ to a number of distant machines. It might be useful to have
two distri-
+ bution lists: one for all machines on the list, and the other
for local
+ machines only. This is actually very simple to do. For the
main list,
+ put the standard entry of information in the
/usr/spool/bboards/BBoards
+ file, with the complete distribution list. For the local
machines list,
+ and add a similar entry to the /usr/spool/bboards/BBoards
file. All the
+ fields should be the same except three: the BBoard name
should reflect a
+ local designation (e.g., "l-hacks"), the distribution list
should con-
+ tain only machines at the local site, and the flags field
should contain
+ the INVIS flag. Since the two entries share the same
primary and
+ archive files, messages sent to either list are read by
local users,
+ while only thoses messages sent to the main list are read by
all users.
+
+ Two automatic facilities for dealing with BBoards exist:
automatic
+ archiving and automatic aliasing. The file
support/bboards/crontab con-
+ tains some entries that you should add to your
/usr/lib/crontab file to
+ run the specified programs at times that are convenient
for you. The
+
+ -12-
+
+
+
+
+
+
+
+
+
+ -13-
+
+
+ bboards.daily file is run once a day and generates an alias
file for _M_H.
+ By using this file, users of _M_H can use, for example,
"unix-wizards"
+ instead of "address@hidden" when they want to send a
message to
+ the "unix-wizards" discussion group. This is a major
win, since you
+ just have to know the name of the group, not the address
where it's
+ located.
+
+ The bboards.weekly file is run once a week and handles
old messages
+ (those received more than 12 days ago) in the BBoards area.
In short,
+ those BBoards which are marked for automatic archiving will
have their
+ old messages placed in the /usr/spool/bboards/archive/
area, or have
+ their old messages removed. Not only does this make BBoards
faster to
+ read, but it conveniently partitions the new messages from
the old mes-
+ sages so you can easily put the old messages on tape and
then remove
+ them. It turns out that this automatic archiving
capability is also a
+ major win.
+
+ At UCI, our policy is to save archived messages on tape
(every two
+ months or so). We use a program called _b_b_t_a_r to
implement our particu-
+ lar policy. Since some BBoards are private (see above), we
save the
+ archives on two tapes: one containing the world-readable
archives (this
+ tape is read-only accessible to all users by calling the
operator), and
+ the other containing the non-world-readable ones (this
tape is kept
+ locked-up somewhere).
+
+
+ _B_B_o_a_r_d_s _w_i_t_h _t_h_e _P_O_P
+
+ If you configured _M_H with "bboards: pop" and "pop:
on", then the _M_H
+ user is allowed to read BBoards on a server machine instead
of the local
+ host (thus saving disk space). For completely transparent
behavior, the
+ administrator may set certain variables in the mtstailor
file on the
+ client host. The variable "popbbhost" indicates the host
where BBoards
+ are kept (it doesn't have to be the POP service host, but
this host must
+ run both a POP server and the BBoards system). The variable
"popbbuser"
+ indicates the guest account on this host for BBoards.
This username
+ should not be either the POP user or the BBoards user.
Usually the
+ anonymous FTP user (ftp) is the best choice. Finally,
the variable
+ "popbblist" indicates the name of a file which contains a
list of hosts
+ (one to a line, official host names only) which should be
allowed to use
+ the POP facility to access BBoards via the guest account.
(If the file
+ is not present, then no check is made.)
+
+ The "popbbuser" variable should be set on both the
client and ser-
+ vice host. The "popbbhost" variable need be set only on the
client host
+ (the value, of course, is the name of the service
host). The
+ "popbblist" variable need be set only on the service host.
+
+ Finally, on the client host, if a POP service host is
not expli-
+ citly given by the user (i.e., "popbbhost" is implicitly
used), then _b_b_c
+ will explicitly check the local host prior to contacting
the service
+ host. This allows each POP client host to have a few
local BBoards
+
+
+
+
+
+
+
+
+
+
+
+ -14-
+
+
+ (e.g., each host could have one called "system"), and then
have the POP
+ service host used for all the rest (a site-wide BBoard might
be known as
+ "general").
+
+
+ _B_B_o_a_r_d_s _w_i_t_h _t_h_e _N_N_T_P
+
+ If you configured _M_H with "bboards: nntp" and "pop:
on", then the
+ _M_H user is allowed to read the Network News on a
server machine using
+ the standard _b_b_c command. For completely
transparent behavior, the
+ administrator may set the "nntphost" variable in the
mtstailor file to
+ indicate the host where the Network News is kept. The
"nntphost" vari-
+ able should be set only on the client host Finally, on the
client host,
+ if an NNTP service host is not explicitly given by the
user (i.e.,
+ "nntphost" is implicitly used), then _b_b_c will
explicitly check the local
+ host prior to contacting the service host. This allows each
NNTP client
+ host to have a few local BBoards (e.g., each host could have
one called
+ "system"), and then have the NNTP service host used for to
read the Net-
+ work News.
+
+ Reading BBoards via the POP and via the NNTP
are mutually
+ exclusive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BBOARDS(5) -15-
BBOARDS(5)
+
+
+ _N_A_M_E
+ BBoards - BBoards database
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/bboards/BBoards
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The BBoards database contains for each BBoard the following
infor-
+ mation:
+
+ _f_i_e_l_d _v_a_l_u_e
+ name the name of the BBoard
+ aliases local aliases for the BBoard
+ (separated by commas)
+ primary file the .mbox file
+ encrypted password leadership password
+ leaders local list maintainers (separated by
commas)
+ usernames from the _p_a_s_s_w_d (5)
file,
+ or groupnames preceded by `=' from the
+ _g_r_o_u_p (5) file
+ network address the list address
+ request address the list maintainer's address
+ relay the host acting as relay for the local
domain
+ distribution sites (separated by commas)
+ flags special flags (see <bboards.h>)
+
+ This is an ASCII file. Each field within each BBoard's
entry is
+ separated from the next by a colon. Each BBoard entry is
separated
+ from the next by a new-line. If the password field is
null, no
+ password is demanded; if it contains a single asterisk,
then no
+ password is valid.
+
+ This file resides in the home directory of the login
"bboards".
+ Because of the encrypted passwords, it can and does have
general
+ read permission.
+
+ _F_i_l_e_s
+ /usr/spool/bboards/BBoards BBoards database
+
+
+ _S_e_e _A_l_s_o
+ bbaka(8), bbexp(8), bboards (8), bbtar(8)
+
+
+ _B_u_g_s
+ A binary indexed file format should be available for fast
access.
+
+ Appropriate precautions must be taken to lock the file
against
+ changes if it is to be edited with a text editor. A
_v_i_b_b program
+ is needed.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(5) -16-
BBOARDS(5)
+
+
+ _N_A_M_E
+ bbaka - generate an alias list for BBoards
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/bboards/bbaka [system]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_a_k_a program reads the BBoards database and
produces on its
+ standard output a file suitable for inclusion in either the
_M_M_D_F-_I_I
+ aliases file (if the argument `system' is given). If the
argument
+ is not given, then _b_b_a_k_a produces on its
standard output a file
+ suitable for becoming the /usr/local/lib/mh/BBoardsAliases
file.
+
+ _F_i_l_e_s
+ /usr/spool/bboards/BBoards BBoards database
+ /usr/local/lib/mh/BBoardsAliases BBoards aliases file for
_M_H
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBEXP(8) -17-
BBEXP(8)
+
+
+ _N_A_M_E
+ bbexp - expunge the BBoards area
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/bboards/bbexp
[-_f_i_r_s_t-_m_e_t_r_i_c] [-_s_e_c_o_n_d-_m_e_t_r_i_c]
+ [bboards ...]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_e_x_p program reads the BBoards database and
calls _m_s_h to
+ archive the named BBoards (or all BBoards if none are
specified).
+
+ The first-metric (which defaults to 12) gives the age in
days of
+ the "BB-Posted:" field for messages which should be
expunged. The
+ second-metric (which defaults to 20) gives the age in days
of the
+ "Date:" field for messages which should be expunged. Any
message
+ which meets either metric will be either archived or
removed,
+ depending on what the _B_B_o_a_r_d_s (5) file says.
+
+ _F_i_l_e_s
+ /usr/spool/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ msh(1), bboards(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(8) -18-
BBOARDS(8)
+
+
+ _N_A_M_E
+ bboards - BBoards channel/mailer
+
+ _S_Y_N_O_P_S_I_S
+ /usr/mmdf/chans/bboards fd1 fd2 [y]
+
+ /usr/local/lib/mh/sbboards bboard ...
+
+ /usr/local/lib/mh/sbboards file maildrop directory
bboards.bboard
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ For _M_M_D_F, the BBoards channel delivers mail to the
BBoards system.
+ For _S_e_n_d_M_a_i_l and stand-alone _M_H, the
SBBoards mailer performs this
+ task.
+
+ For each address given, these programs consult the
_b_b_o_a_r_d_s (5) file
+ to ascertain information about the BBoard named by the
address.
+ The programs then perform local delivery, if appropriate.
After
+ that, with the exception of _s_b_b_o_a_r_d_s running
under stand-alone _M_H,
+ the programs perform redistribution, if appropriate.
+
+ For redistribution, the return address is set to be the
request
+ address at the local host, so bad addresses down the line
return to
+ the nearest point of authority. If any failures occur
during
+ redistribution, a mail message is sent to the local
request
+ address.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbaka(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBTAR(8) -19-
BBTAR(8)
+
+
+ _N_A_M_E
+ bbtar - generate the names of archive files to be put to tape
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/bboards/bbtar [private] [public]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _b_b_t_a_r program reads the BBoards database and
produces on its
+ standard output the names of BBoards archives which should
be put
+ to tape, for direct use in a _t_a_r (1) command.
+
+ If the argument `private' is given, only private BBoards are
con-
+ sidered. If the argument `public' is given, only public
BBoards
+ are considered. This lets the BBoards administrator
write two
+ tapes, one for general read-access (the public BBoards),
and one
+ for restricted access. The default is all BBoards
+
+ For example:
+
+ cd archive # change to the archive directory
+ tar cv `bbtar private` # save all private BBoard
archives
+
+ After the archives have been saved to tape, they are
usually
+ removed. The archives are then filled again, usually
automatically
+ by cron jobs which run _b_b_e_x_p (8).
+
+ _F_i_l_e_s
+ /usr/spool/bboards/BBoards BBoards database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbexp(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _4. _P_O_P
+
+
+
+
+
+ For POP (Post Office Protocol) client hosts, you need to
edit the
+ /usr/local/lib/mh/mtstailor file to know about two hosts:
the SMTP ser-
+ vice host and the POP service host. Normally, these are
the same.
+ Change the "localname" field of the mtstailor file of _M_H
in the file to
+ be the name of the POP service host. This makes replies to
mail gen-
+ erated on the POP client host possible, since _M_H will
consider use the
+ hostname of the POP service host as the local hostname
for outgoing
+ mail. Also set the value of "pophost" to this value.
This tells _i_n_c
+ and _m_s_g_c_h_k to use POP instead of looking for
mail locally. Finally,
+ make sure the value of "servers" includes the name of the
SMTP service
+ host. The recommended value for "servers" is:
+
+ servers: SMTP-service-host localhost \01localnet
+
+ If you want more information on the Post Office
Protocol used by
+ _M_H, consult the files
support/pop/rfc1081.txt and
+ support/pop/rfc1082.txt which describe the _M_H version of
the POP: POP3.
+
+ For POP service hosts, you need to run a daemon,
_p_o_p_d (8). The
+ daemon should start at multi-user boot time, so adding the
lines:
+
+ if [ -f /etc/popd ]; then
+ /etc/popd & echo -n ' pop'
>/dev/console
+ fi
+
+ to the /etc/rc.local file is sufficient.
+
+ The port assigned to the POP3 protocol is "110". For
historical
+ reasons, many sites are using port "109" which is the port
assigned to
+ the "POP" (version 1 and 2) protocol. The configuration
option "POPSER-
+ VICE" is the name of the port number that _M_H POP will
try to use, and
+ defaults to the name "pop".
+
+ To generate _M_H to use newer assigned port number, in
your _M_H config
+ file, add:
+
+ options POPSERVICE='"pop3"'
+
+ And on both the POP client and service hosts, you need to
define the
+ port that the POP service uses. Add the line:
+
+ pop3 110/tcp
+
+ to the /etc/services file (if it's not already there).
+
+
+
+ -20-
+
+
+
+
+
+
+
+
+
+ -21-
+
+
+ There are two ways to administer POP: In "naive" mode,
each user-id
+ in the _p_a_s_s_w_d (5) file is considered a POP
subscriber. No changes are
+ required for the mailsystem on the POP service host.
However, this
+ method requires that each POP subscriber have an entry in
the password
+ file. The POP server will fetch the user's mail from
wherever maildrops
+ are kept on the POP service host. This means that if
maildrops are kept
+ in the user's home directory, then each POP subscriber must
have a home
+ directory.
+
+ In "smart" mode (enabled via "DPOP" being given as a
configuration
+ option), the list of POP subscribers and the list of
login users are
+ completely separate name spaces. A separate database (simple
file simi-
+ lar to the _B_B_o_a_r_d_s (5) file) is used to
record information about each
+ POP subscriber. Unfortunately, the local mailsystem must be
changed to
+ reflect this. This requires two changes (both of which
are simple):
+ First, the aliasing mechanism is augmented so that POP
subscriber
+ addresses are diverted to a special delivery mechanism.
_M_H comes with a
+ program, _p_o_p_a_k_a (8), which generates the
additional information to be
+ put in the mailsystem's alias file. Second, a special POP
channel (for
+ MMDF-II) or POP mailer (for SendMail) performs the actual
delivery (_m_h._6
+ supplies both). All it really does is just place the mail
in the POP
+ spool area.
+
+ These two different philosophies are not compatible on
the same POP
+ service host: one or the other, but not both may be run.
Clever mail-
+ system people will note that the POP mechanism is really a
special case
+ of the more general BBoards mechanism.
+
+ In addition, there is one user-visible difference,
which the
+ administrator controls the availability of. The difference
is whether
+ the POP subscriber must supply a password to the POP server:
The first
+ method uses the standard ARPA technique of sending a
username and a
+ password. The appropriate programs (_i_n_c,
_m_s_g_c_h_k, and possibly _b_b_c )
+ will prompt the user for this information.
+
+ The second method (which is enabled via "RPOP" being
given as a
+ configuration option) uses the Berkeley UNIX reserved port
method for
+ authentication. This requires that the two or three
mentioned above
+ programs be _s_e_t_u_i_d to root. (There are no
known holes in any of these
+ programs.)
+
+ To add a POP subscriber, for the first method, one
simply follows
+ the usual procedures for adding a new user, which eventually
results in
+ adding a line to the _p_a_s_s_w_d (5) file; for the
second method, one must
+ edit the POP database file (kept in the home directory of the
POP user),
+ and then run the _p_o_p_a_k_a program. The output of
this program is placed
+ in the aliases file for the transport system (e.g.,
/usr/lib/aliases for
+ SendMail).
+
+ Authentication for POP subscribers differs depending
on the two
+ methods. When the user supplies a password for the POP
session: under
+ the first method, the contents of the password field for
the user's
+
+
+
+
+
+
+
+
+
+
+
+ -22-
+
+
+ entry in the _p_a_s_s_w_d (5) is consulted; under the
second method, the con-
+ tents of the password field for the subscriber's entry in
the _p_o_p (5)
+ file is consulted. (To set this field, the
_p_o_p_w_r_d (8) program is used.)
+
+ If you are allowing RPOP, under the first method,
the user's
+ ._r_h_o_s_t_s file is consulted; under the second
method, the contents of the
+ network address field for the subscriber's entry in the
_p_o_p (5) file is
+ consulted.
+
+ In addition, a third authentication scheme is available.
When the
+ APOP configuration option is given, e.g.,
+
+ options APOP='"/etc/pop.auth"'
+
+ In this case, the server also allows a client to supply
authentication
+ credentials to provide for origin authentication and reply
protection,
+ but which do not involve sending a password in the clear over
the net-
+ work. A POP authorization DB, having as its name the value
of APOP con-
+ figuration option, is used to keep track of this information.
This file
+ is created and manipulated by the _p_o_p_a_u_t_h
(8) program. Because this
+ file contains secret information, it must be protected mode
0600 and
+ owned by the super-user. Hence, your first step after
installing the
+ software is to issue
+
+ # popauth -init
+
+ which creates and initalizes the POP authorization DB.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ POP(5) -23-
POP(5)
+
+
+ _N_A_M_E
+ POP - POP database of subscribers
+
+ _S_Y_N_O_P_S_I_S
+ /usr/spool/pop/POP
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The POP database has exactly the same format as the
_B_B_o_a_r_d_s (5)
+ database, although many fields are unused. Currently,
only four
+ fields are examined:
+
+ _f_i_e_l_d _v_a_l_u_e
+ name the POP subscriber
+ primary file the maildrop for the POP subscriber
+ (relative to the POP directory)
+ encrypted password the POP subscriber's password
+ network address the remote user allowed to RPOP
+
+ This is an ASCII file. Each field within each POP
subscriber's
+ entry is separated from the next by a colon. Each POP
subscriber
+ is separated from the next by a new-line. If the password
field is
+ null, then no password is valid.
+
+ To add a new POP subscriber, edit the file adding a line such
as
+
+ mrose::mrose:::::::0
+
+ Then, use _p_o_p_w_r_d to set the password for the POP
subscriber. If
+ you wish to allow POP subscribers to access their maildrops
without
+ supplying a password (by using privileged ports), fill-in the
net-
+ work address field, as in:
+
+ mrose::mrose:::address@hidden::::0
+
+ which permits "address@hidden" 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::address@hidden,address@hidden::::
+
+ To disable a POP subscriber from
_r_e_c_e_i_v_i_n_g mail, set the primary
+ file name to the empty string. To prevent a POP subscriber
from
+ _p_i_c_k_i_n_g-_u_p mail, set the encrypted password
to "*" and set the net-
+ work address to the empty string.
+
+ This file resides in home directory of the login "pop".
Because of
+ the encrypted passwords, it can and does have general read
permis-
+ sion.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POP(5) -24-
POP(5)
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), pop(8), popaka(8), popd(8), popwrd(8)
+
+
+ _B_u_g_s
+ A binary indexed file format should be available for fast
access.
+
+ Appropriate precautions must be taken to lock the file
against
+ changes if it is to be edited with a text editor. A
_v_i_p_o_p program
+ is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POP(8) -25-
POP(8)
+
+
+ _N_A_M_E
+ pop - POP channel/mailer
+
+ _S_Y_N_O_P_S_I_S
+ /usr/mmdf/chans/pop fd1 fd2 [y]
+
+ /usr/local/lib/mh/spop POP-subscriber ...
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ For _M_M_D_F-_I_I, the POP channel delivers mail to the
POP spool area
+ for later retrieval by POP subscribers. For
_S_e_n_d_M_a_i_l, the SPOP
+ mailer performs this task.
+
+ For each address given, these programs consult the _p_o_p
(5) file to
+ obtain information about the POP-subscriber named by the
address.
+ The programs then deliver the message to the spool area
for the
+ POP-subscriber.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ bboards(5), bbaka(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POPAKA(8) -26-
POPAKA(8)
+
+
+ _N_A_M_E
+ popaka - generate POP entries for SendMail or MMDF-II alias
file
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/popaka
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_a_k_a program reads the POP database and
produces on its stan-
+ dard output a file suitable for inclusion in the
SendMail or
+ _M_M_D_F-_I_I aliases file. The contents of this file
divert mail for
+ POP subscribers to the POP channel.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POPAUTH(8) -27-
POPAUTH(8)
+
+
+ _N_A_M_E
+ popauth - manipulate POP authorization DB
+
+ _S_Y_N_O_P_S_I_S
+ popauth [-init] [-list] [-user name] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_a_u_t_h program allows a POP-subscriber to
change the secret
+ value used to generate their authentication credentials. In
addi-
+ tion, the super-user or master POP user may use this
program to
+ either initialize the database or to print public
information from
+ it. _p_o_p_a_u_t_h is useful only when the APOP
configuration option is
+ defined. (This configuration option defines the name of
the POP
+ authorization DB.)
+
+ Under normal usage, _p_o_p_a_u_t_h prompts for a new
secret, just like the
+ _p_a_s_s_w_d program. It then updates the POP
authorization DB accord-
+ ingly.
+
+ With the `-init' switch, the super-user or master POP
user can
+ create a new (or zero the existing) POP authorization DB.
+
+ With the `-list' switch, the super-user or master POP
user can
+ print out public information about the named subscriber
(or all
+ subscribers).
+
+ _F_i_l_e_s
+ /etc/pop.auth.* POP authorization DB
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ popd(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POPD(8) -28-
POPD(8)
+
+
+ _N_A_M_E
+ popd - the POP server
+
+ _S_Y_N_O_P_S_I_S
+ /usr/etc/popd [-p portno] (under /etc/rc.local)
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_d server implements the Post Office Protocol
(version 3), as
+ described in RFC1081 and RFC1082. Basically, the server
listens on
+ the TCP port named "pop" for connections and enters the POP
upon
+ establishing a connection. The `-p' option overrides the
default
+ TCP port. If the POP2 configuration option is defined,
then the
+ server also implements version 2 of the protocol. If the
APOP con-
+ figuration option is defined, then the server supports a
non-
+ standard mechanism for identity-establishment in which
authentica-
+ tion credentials are used to provide for origin
authentication and
+ reply protection, but which do not involve sending a
password in
+ the clear over the network. See _p_o_p_a_u_t_h(8) for
more details.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3: _E_x_t_e_n_d_e_d _s_e_r_v_i_c_e
_o_f_f_e_r_i_n_g_s
+ (RFC-1082),
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POPD(8) -29-
POPD(8)
+
+
+ _H_i_s_t_o_r_y
+ For historical reasons, the _M_H POP defaults to using the
port named
+ "pop" (109) instead of its newly assigned port named "pop3"
(110).
+ See the POPSERVICE configuration option for more details.
+
+ Previous versions of the server (10/28/84) had the
restriction that
+ the POP client may retrieve messages for login users only.
This
+ restriction has been lifted, and true POB support is
available
+ (sending mail to a mailbox on the POP service host which
does not
+ map to a user-id in the password file).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POPWRD(8) -30-
POPWRD(8)
+
+
+ _N_A_M_E
+ popwrd - set password for a POP subscriber
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/popwrd POP-subscriber
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _p_o_p_w_r_d program lets the super-user or the
master POP user or a
+ "leader" of a POP subscriber change the password field for
the POP
+ subscriber in the POP database. This program is very
similar to
+ the _p_a_s_s_w_d (1) program.
+
+ Since only the super-user and the master POP user may
change any
+ other fields of the POP database (using an ordinary editor),
it is
+ possible for the system administrator to delegate
responsibility to
+ others to manage groups of POP subscribers.
+
+ _F_i_l_e_s
+ /usr/spool/pop/POP POP database
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ pop(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Although _p_o_p_w_r_d does locking against other
invocations of _p_o_p_w_r_d,
+ editor locking for the POP database in general is not
implemented.
+ A _v_i_p_o_p program is needed.
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _5. _M_A_I_L
_F_I_L_T_E_R_I_N_G
+
+
+
+
+
+ There was a time when users on a UNIX host might have
had two mail-
+ drops: one from _M_M_D_F and the other from
_U_U_C_P. This was really a bad
+ problem since it prevented using a single user-interface on
all of your
+ mail. Furthermore, if you wanted to send a message to
addresses on dif-
+ ferent mailsystems, you couldn't send just one message. To
solve all
+ these problems, the notion of _m_a_i_l
_f_i_l_t_e_r_i_n_g was developed that allowed
+ sophisticated munging and relaying between the two
pseudo-domains.
+
+ _M_H will perform mail filtering, transparently, if
given the MF con-
+ figuration option. However, with the advent of
_S_e_n_d_M_a_i_l and further
+ maturation of _M_M_D_F, _M_H doesn't really need to do
this anymore, since
+ these message transport agents handle it.
+
+ The mail-filtering stuff is too complicated. It should
be simpler,
+ but, protocol translation really _i_s difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -31-
+
+
+
+
+
+
+
+
+
+ MF(1) -32-
MF(1)
+
+
+ _N_A_M_E
+ muinc, musift, uminc, umsift - mail filters
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/muinc
+
+ /usr/local/lib/mh/musift [files ...]
+
+ /usr/local/lib/mh/uminc
+
+ /usr/local/lib/mh/umsift [files ...]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The mail filters are a set of programs that filter mail
from one
+ format to another. In particular, _U_U_C_P- and
_M_M_D_F-style mail files
+ are handled.
+
+ _m_u_i_n_c filters mail from the user's _M_M_D_F
maildrop into the user's
+ _U_U_C_P maildrop; similarly, _u_m_i_n_c filters
mail from the user's _U_U_C_P
+ maildrop into the user's _M_M_D_F maildrop. These two
programs respect
+ each system's maildrop locking protocols.
+
+ _m_u_s_i_f_t filters each file on the command line (or
the standard input
+ if no arguments are given), and places the result on the
standard
+ output in _U_U_C_P format. The files (or standard input)
are expected
+ to be in _M_M_D_F format. _u_m_s_i_f_t does the
same thing filtering _U_U_C_P
+ formatted files (or input), and places the _M_M_D_F
formatted result on
+ the standard output. No locking protocols are used by
these pro-
+ grams.
+
+ If the files aren't in the expected format, the mail filters
will
+ try to recover. In really bad cases, you may lose big.
+
+ _F_i_l_e_s
+ /usr/spool/mail/ UUCP spool area for
maildrops
+ /usr/spool/mail/$USER Location of standard
maildrop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _H_e_a_d_e_r _M_u_n_g_i_n_g (aka RFC-886),
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+
+
+ _C_o_n_t_e_x_t
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MF(1) -33-
MF(1)
+
+
+ _B_u_g_s
+ Numerous; protocol translation is very difficult.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMAIL(8) -34-
RMAIL(8)
+
+
+ _N_A_M_E
+ rmail - UUCP interface to mail
+
+ _S_Y_N_O_P_S_I_S
+ rmail address ...
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_a_i_l is intended as a replacement for those
systems without _S_e_n_d_-
+ _M_a_i_l or _M_M_D_F. It is normally invoked
by _u_u_x on behalf of the
+ remote _U_U_C_P site. For each address, it decides where
to send it:
+ either locally, via another _U_U_C_P link, or via the
Internet.
+
+ _R_m_a_i_l implements a crude access control facility by
consulting the
+ files Rmail.OkHosts and Rmail.OkDests in the
/usr/local/lib/mh/
+ directory. Hosts listed in the former file can send
messages to
+ anywhere they please. Hosts listed in the latter file can
receive
+ messages from anywhere. Note that a host listed in the first
file
+ is implicitly listed in the second file.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/local/lib/mh/Rmail.OkHosts list of privileged hosts
+ /usr/local/lib/mh/Rmail.OkDests list of privileged
destinations
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mf(1)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _6. _M_H _H_A_C_K_I_N_G
+
+
+
+
+
+ Finally, here's a little information on modifying the
_M_H sources.
+ A word of advice however:
+
+
+ _D_O_N'_T
+
+
+
+ If you really want new _M_H capabilities, write a shell
script instead.
+ After all, that's what UNIX is all about, isn't it?
+
+ Here's the organization of the _M_H source tree.
+
+ conf/ configurator tree
+ config/ compiled configuration constants
+ dist/ distributor
+ doc/ manual entries
+ h/ include files
+ miscellany/ various sundries
+ mts/ MTS-specific areas
+ mh/ standalone delivery
+ mmdf/ MMDF-I, MMDF-II
+ sendmail/ SendMail, SMTP
+ papers/ papers about _M_H
+ sbr/ subroutines
+ support/ support programs and files
+ bboards/ UCI BBoards facility
+ general/ templates
+ pop/ POP facility
+ tma/ Trusted Mail Agent (not present in all
distributions)
+ uip/ programs
+ zotnet/ MTS-independent areas
+ bboards/ UCI BBoards facility
+ mf/ Mail Filtering
+ mts/ MTS constants
+ tws/ date routines
+
+
+
+
+
+
+
+
+
+
+
+ -35-
+
+
+
+
+
+
+
+
+
+ MH-HACK(8) -36-
MH-HACK(8)
+
+
+ _N_A_M_E
+ mh-hack - how to hack MH
+
+ _S_Y_N_O_P_S_I_S
+ big hack attack
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This is a description of how one can modify the _M_H
system. The _M_H
+ distribution has a lot of complex inter-relations, so before
you go
+ modifying any code, you should read this and understand
what is
+ going on.
+
+ ADDING A NEW PROGRAM
+ Suppose you want to create a new _M_H command called
"pickle".
+ First, create and edit "pickle.c" in the uip/ directory.
Next
+ edit conf/makefiles/uip to include "pickle". This
file has
+ directions at the end of it which explain how it
should be
+ modified. Next, update any documentation (described
below).
+ At this point you can re-configure _M_H. See
_m_h-_g_e_n(_8) for
+ instructions on how to do this (basically, you want
"mhconfig
+ MH").
+
+ ADDING A NEW SUBROUTINE
+ Suppose you want to create a new _M_H routine called
"pickle".
+ First, create and edit "pickle.c" in the sbr/ directory.
Next
+ edit conf/makefiles/sbr to include "pickle". This
file has
+ directions at the end of it which explain how it
should be
+ modified. You should modify config/mh.h to define
"pickle
+ ();". Similarly, sbr/llib-lsbr should be modified for
_l_i_n_t.
+ At this point you can re-configure _M_H.
+
+ UPDATING DOCUMENTATION
+ Edit whatever files you want in conf/doc/. When
documenting a
+ new program, such as "pickle", you should create a
manual page
+ with the name "pickle.rf". The file conf/doc/template
has a
+ manual page template that you can use. If you are
documenting
+ a new program, then you should also update three other
files:
+ The file conf/doc/mh.rf should be modified to
include the
+ ".NA" section from "pickle.rf". The file
conf/doc/mh-chart.rf
+ should be modified to include the ".SY" section
from
+ "pickle.rf". Finally, the file conf/doc/MH.rf should be
modi-
+ fied to include a ".so pickle.me". Naturally, none of
these
+ changes will be reflected in the configuration until you
actu-
+ ally run _m_h_c_o_n_f_i_g.
+
+ _F_i_l_e_s
+ Too numerous to mention. Honest.
+
+
+ _S_e_e _A_l_s_o
+ mh-gen(8)
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-HACK(8) -37-
MH-HACK(8)
+
+
+ _B_u_g_s
+ Hacking is an art, but most programmers are butchers, not
artists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _7. _H_I_D_D_E_N
_F_E_A_T_U_R_E_S
+
+
+
+
+
+ The capabilities discussed here should not be used on a
production
+ basis, as they are either experimental, are useful for
debugging _M_H, or
+ are otherwise not recommended.
+
+
+
+ _D_e_b_u_g _F_a_c_i_l_i_t_i_e_s
+
+ The _m_a_r_k command has a `-debug' switch which
essentially prints out
+ all the internal _M_H data structures for the folder you're
looking at.
+
+ The _p_o_s_t command has a `-debug' switch which
does everything but
+ actually post the message for you. Instead of posting
the draft, it
+ sends it to the standard output. Similarly, _s_e_n_d has
a `-debug' switch
+ which gets passed to _p_o_s_t.
+
+ Some _M_H commands look at envariables to determine
debug-mode opera-
+ tion of certain new facilities. The current list of
envariables is:
+
+ MHFDEBUG OVERHEAD facility
+ MHLDEBUG mhl
+ MHPDEBUG pick
+ MHPOPDEBUG POP transactions
+ MHVDEBUG window management transactions
+ MHWDEBUG alternate-mailboxes
+
+
+
+ _F_o_r_w_a_r_d_i_n_g _M_a_i_l
+
+ The _f_o_r_w and _m_h_l commands have two
switches, `-dashmunging' and
+ `-nodashmunging' which enable or disable the prepending of
`- ' in for-
+ warded messages. To use `-nodashmunging', you must use an
_m_h_l filter
+ file.
+
+
+
+ _S_e_n_d
+
+ The _s_e_n_d command has two switches, `-unique' and
`-nounique', which
+ are useful to certain individuals who, for obscure reasons,
do not use
+ draft-folders.
+
+ "Distribution Carbon Copy" addresses may be specified in
the _D_c_c:
+ header. This header is removed before posting the
message,and a copy of
+ the message is distributed to each listed address. This
could be
+
+ -38-
+
+
+
+
+
+
+
+
+
+ -39-
+
+
+ considered a form of Blind Carbon Copy which is best used for
sending to
+ an address which would never reply (such as an auto-archiver).
+
+
+
+ _P_o_s_t_i_n_g _M_a_i_l
+
+ If you're running a version of _M_H which talks
directly to an _S_M_T_P
+ server (or perhaps an advanced _M_M_D_F submit
process), there are lots of
+ interesting switches for your amusement which _s_e_n_d
and _p_o_s_t understand:
+ -mail Use the _M_A_I_L command (default)
+ -saml Use the _S_A_M_L command
+ -send Use the _S_E_N_D command
+ -soml Use the _S_O_M_L command
+ -snoop Watch the _S_M_T_P transaction
+ -client host Claim to be "host" when posting mail
+ -server host Post mail with "host"
+
+ The last switch is to be useful when _M_H resides on
small worksta-
+ tions (or PC:s) in a network--they can post their outgoing
mail with a
+ local relay, and reduce the load on the local system. On
POP client
+ hosts, the `-server host' switch is defaulted
appropriately using the
+ SMTP search-list mechanism. The _w_h_o_m command
understands the last three
+ switches.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _8.
_C_O_N_F_I_G_U_R_A_T_I_O_N _O_P_T_I_O_N_S
+
+
+
+
+
+ This manual was generated with the following
configuration options
+ in effect:
+
+
+
________________________________________________________________________
+
+ Generation Date November 30, 1993
+ Primary Directory /usr/local/
+ Secondary Directory /usr/local/lib/mh/
+ Maildrop Location /usr/spool/mail/$USER
+ Transport System SendMail
+
________________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -40-
+
+
+
+
+
+
+
+
+
+
+
+
+ _C_O_N_T_E_N_T_S
+
+
+
+
+ Section
+
+ 1. INTRODUCTION
............................................... 1
+ Scope of this document
....................................... 1
+ Summary
...................................................... 1
+
+ 2. THE MTS INTERFACE
.......................................... 3
+ MH-TAILOR
................................................. 4
+ MH-MTS
.................................................... 10
+
+ 3. BBOARDS
.................................................... 12
+ BBoard Delivery
.............................................. 12
+ BBoards with the POP
......................................... 13
+ BBoards with the NNTP
........................................ 14
+ BBOARDS
................................................... 15
+ BBAKA
..................................................... 16
+ BBEXP
..................................................... 17
+ BBOARDS
................................................... 18
+ BBTAR
..................................................... 19
+
+ 4. POP
........................................................ 20
+ POP
....................................................... 23
+ POP
....................................................... 25
+ POPAKA
.................................................... 26
+ POPAUTH
................................................... 27
+ POPD
...................................................... 28
+ POPWRD
.................................................... 30
+
+ 5. MAIL FILTERING
............................................. 31
+ MF
........................................................ 32
+ RMAIL
..................................................... 34
+
+ 6. MH HACKING
................................................. 35
+ MH-HACK
................................................... 36
+
+ 7. HIDDEN FEATURES
............................................ 38
+ Debug Facilities
............................................. 38
+ Forwarding Mail
.............................................. 38
+ Send
......................................................... 38
+ Posting Mail
................................................. 39
+
+ 8. CONFIGURATION OPTIONS
...................................... 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ THE RAND MH
+
+
+ MESSAGE HANDLING
+
+
+ SYSTEM:
+
+
+ ADMINISTRATOR'S GUIDE
+
+
+
+
+
+
+ UCI Version
+
+
+
+
+
+ Marshall T. Rose
+
+
+
+
+ _F_i_r_s_t _E_d_i_t_i_o_n:
+
+ _M_H _C_l_a_s_s_i_c
+
+ (_N_o_t _t_o _b_e _c_o_n_f_u_s_e_d
_w_i_t_h _a _w_e_l_l-_k_n_o_w_n _s_o_f_t _d_r_i_n_k)
+
+
+
+
+
+
+
+ November 30, 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/MH-19910201.txt b/docs/historical/MH-19910201.txt
new file mode 100644
index 0000000..28701cb
--- /dev/null
+++ b/docs/historical/MH-19910201.txt
@@ -0,0 +1,11145 @@
+
+
+
+
+
+
+
+
+ _d_i_s_c_a_r_d _t_h_i_s
_p_a_g_e
+
+
+
+
+ The RAND _M_H
+ Message Handling System:
+ User's Manual
+
+ UCI Version
+
+
+ February 1, 1991
+ 6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+99
+
+
+
+
+
+
+
+
+
+
+
+
+ _1. _I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+9
+ Although people can travel cross-country in hours and can reach
+ others by telephone in seconds, communications still depend heavily upon
+ paper, most of which is distributed through the mails.
+
+ There are several major reasons for this continued dependence on
+ written documents. First, a written document may be proofread and
+ corrected prior to its distribution, giving the author complete control
+ over his words. Thus, a written document is better than a telephone
+ conversation in this respect. Second, a carefully written document is
+ far less likely to be misinterpreted or poorly translated than a phone
+ conversation. Third, a signature offers reasonable verification of
+ authorship, which cannot be provided with media such as telegrams.
+
+ However, the need for fast____, accurate, and reproducible
document
+ distribution is obvious. One solution in widespread use is the telefax.
+ Another that is rapidly gaining popularity is electronic mail. Elec-
+ tronic mail is similar to telefax in that the data to be sent are digi-
+ tized, transmitted via phone lines, and turned back into a document at
+ the receiver. The advantage of electronic mail is in its compression
+ factor. Whereas a telefax must scan a page in very fine lines and send
+ all of the black and white information, electronic mail assigns charac-
+ ters fixed codes which can be transmitted as a few bits of information.
+ Telefax presently has the advantage of being able to transmit an arbi-
+ trary page, including pictures, but electronic mail is beginning to deal
+ with this problem. Electronic mail also integrates well with current
+ directions in office automation, allowing documents prepared with
+ sophisticated equipment at one site to be quickly transferred and
+ printed at another site.
+
+ Currently, most electronic mail is intraorganizational, with mail
+ transfer remaining within one computer. As computer networking becomes
+ more common, however, it is becoming more feasible to communicate with
+ anyone whose computer can be linked to your own via a network.
+
+ The pioneering efforts on general-purpose electronic mail were by
+ organizations using the DoD ARPAnet[1]. The capability to send messages
+ between computers existed before the ARPAnet was developed, but it was
+ used only in limited ways. With the advent of the ARPAnet, tools began
+ to be developed which made it convenient for individuals or organiza-
+ tions to distribute messages over broad geographic areas, using diverse
+ computer facilities. The interest and activity in message systems has
+ now reached such proportions that steps have been taken within the DoD
+ to coordinate and unify the development of military message systems.
+ The use of electronic mail is expected to increase dramatically in the
+ next few years. The utility of such systems in the command and control
+ and intelligence environments is clear, and applications in these areas
+
+9
+
+
+
+
+
+
+
+
+
+ -2-
+
+
+ will probably lead the way. As the costs for sending and handling elec-
+ tronic messages continue their rapid decrease, such uses can be expected
+ to spread rapidly into other areas and, of course, will not be limited
+ to the DoD.
+
+ A message system provides tools that help users (individuals or
+ organizations) deal with messages in various ways. Messages must be
+ composed, sent, received, stored, retrieved, forwarded, and replied to.
+ Today's best interactive computer systems provide a variety of word-
+ processing and information handling capabilities. The message handling
+ facilities should be well integrated with the rest of the system, so as
+ to be a graceful extension of overall system capability.
+
+ The message system described in this report, _M_H, provides
most of
+ the features that can be found in other message systems and also incor-
+ porates some new ones. It has been built on the UNIX time-sharing sys-
+ tem[2], a popular operating system for the DEC PDP-11[1] and VAX-11
+ classes of computers. A "secure" operating system similar to UNIX is
+ currently being developed[3], and that system will also run _M_H.
+
+ This report provides a complete description of _M_H and thus
may
+ serve as a user's manual, although parts of the report will be of
+ interest to non-users as well. Sections 2 and 3, the Overview and
+ Tutorial, present the key ideas of _M_H and will give those not
familiar
+ with message systems an idea of what such systems are like.
+
+ _M_H consists of a set of commands which use some special files
and
+ conventions. The final section is divided into three parts. The first
+ part covers the information a user needs to know in addition to the com-
+ mands. Then, each of the _M_H commands is described in detail.
Finally,
+ other obscure details are revealed. A summary of the commands is given
+ in Appendix A, and the syntax of message sequences is given in Appendix
+ B.
+
+ A novel approach has been taken in the design of _M_H.
Instead of
+ creating a large subsystem that appears as a single command to the user
+ (such as MS[4]), _M_H is a collection of separate commands which are
run
+ as separate programs. The file and directory system of UNIX are used
+ directly. Messages are stored as individual files (datasets), and col-
+ lections of them are grouped into directories. In contrast, most other
+ message systems store messages in a complicated data structure within a
+ monolithic file. With the _M_H approach, UNIX commands can be
interleaved
+ with commands invoking the functions of the message handler. Con-
+ versely, existing UNIX commands can be used in connection with messages.
+ For example, all the usual UNIX editing, text-formatting, and printing
+ facilities can be applied directly to individual messages. MH, there-
+ fore, consists of a relatively small amount of new code; it makes
+
+
+9 [1] PDP and VAX are trademarks of Digital Equipment Corporation.
+
+
+9
+
+
+
+
+
+
+
+
+
+ -3-
+
+
+ extensive use of other UNIX software to provide the capabilities found
+ in other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _2. _O_V_E_R_V_I_E_W
+
+
+
+9
+ There are three main aspects of _M_H : the way messages
are
+ stored (the message database), the user's profile (which directs how
+ certain actions of the message handler take place), and the commands for
+ dealing with messages.
+
+ Under _M_H, each message is stored as a separate file. A user
can
+ take any action with a message that he could with an ordinary file in
+ UNIX. A UNIX directory in which messages are stored is called a folder.
+ Each folder contains some standard entries to support the message-
+ handling functions. The messages in a folder have numerical names.
+ These folders (directories) are entries in a particular directory path,
+ described in the user profile, through which _M_H can find message
fold-
+ ers. Using the UNIX "link" facility, it is possible for one copy of a
+ message to be "filed" in more than one folder, providing a message index
+ facility. Also, using the UNIX tree-structured file system, it is pos-
+ sible to have a folder within a folder, nested arbitrarily deep, and
+ have the full power of the _M_H commands available.
+
+ Each user of _M_H has a user profile, a file in his $HOME
(initial
+ login) directory called ._m_h__p_r_o_f_i_l_e. This
profile contains several
+ pieces of information used by the _M_H commands: a path name to the
direc-
+ tory that contains the message folders and parameters that tailor
_M_H
+ commands to the individual user's requirements. There is also another
+ file, called the user context, which contains information concerning
+ which folder the user last referenced (the "current" folder). It also
+ contains most of the necessary state information concerning how the user
+ is dealing with his messages, enabling _M_H to be implemented as a
set of
+ individual UNIX commands, in contrast to the usual approach of a monol-
+ ithic subsystem.
+
+ In _M_H, incoming mail is appended to the end of a file in a
system
+ spooling area for the user. This area is called the mail drop direc-
+ tory, and the file is called the user's mail drop. Normally when the
+ user logins in, s/he is informed of new mail (or the _M_H program
_m_s_g_c_h_k
+ may be run). The user adds the new messages to his/her collection of
_M_H
+ messages by invoking the command _i_n_c. The _i_n_c
(incorporate) command
+ adds the new messages to a folder called "inbox", assigning them names
+ which are consecutive integers starting with the next highest integer
+ available in inbox. _i_n_c also produces a _s_c_a_n summary of
the messages
+ thus incorporated. A folder can be compacted into a single file, for
+ easy storage, by using the _p_a_c_k_f command. Also, messages
within a
+ folder can be sorted by date and time with the _s_o_r_t_m command.
+
+
+ There are four commands for examining the messages in a folder:
+ _s_h_o_w, _p_r_e_v, _n_e_x_t, and _s_c_a_n. The
_s_h_o_w command displays a message in a
+
+9 -4-
+
+
+
+
+
+
+
+
+
+ -5-
+
+
+ folder, _p_r_e_v displays the message preceding the current
message, and
+ _n_e_x_t displays the message following the current message.
_M_H lets the
+ user choose the program that displays individual messages. A special
+ program, _m_h_l, can be used to display messages according to the
user's
+ preferences. The _s_c_a_n command summarizes the messages in a
folder, nor-
+ mally producing one line per message, showing who the message is from,
+ the date, the subject, etc.
+
+ The user may move a message from one folder to another with the
+ command _r_e_f_i_l_e. Messages may be removed from a folder by
means of the
+ command _r_m_m. In addition, a user may query what the current
folder is
+ and may specify that a new folder become the current folder, through the
+ command _f_o_l_d_e_r. All folders may be summarized with the
_f_o_l_d_e_r_s command.
+ A message folder (or subfolder) may be removed by means of the command
+ _r_m_f.
+
+ A set of messages based on content may be selected by use of the
+ command _p_i_c_k. This command searches through messages in a
folder and
+ selects those that match a given set of criteria. These messages are
+ then bound to a "sequence" name for use with other _M_H commands.
The
+ _m_a_r_k command manipulates these sequences.
+
+ There are five commands enabling the user to create new messages
+ and send them: _c_o_m_p, _d_i_s_t, _f_o_r_w, _r_e_p_l,
and _s_e_n_d. The _c_o_m_p command pro-
+ vides the facility for the user to compose a new message; _d_i_s_t
redistri-
+ butes mail to additional addressees; _f_o_r_w enables the user
to forward
+ messages; and _r_e_p_l facilitates the generation of a reply to an
incoming
+ message. The last three commands may optionally annotate the original
+ message. Messages may be arbitrarily annotated with the _a_n_n_o
command.
+ Once a draft has been constructed by one of the four above composition
+ programs, a user-specifiable program is run to query the user as to the
+ disposition of the draft prior to sending. _M_H provides the simple
_w_h_a_t_-
+ _n_o_w program to start users off. If a message is not sent
directly by
+ one of these commands, it may be sent at a later time using the command
+ _s_e_n_d. _M_H allows the use of any UNIX editor when composing
a message.
+ For rapid entry, a special editor, _p_r_o_m_p_t_e_r, is
provided. For programs,
+ a special mail-sending program, _m_h_m_a_i_l, is provided.
+
+ _M_H supports a personal aliasing facility which gives users
the
+ capability to considerably shorten address typein and use meaningful
+ names for addresses. The _a_l_i program can be used to query _M_H
as to the
+ expansion of a list of aliases. After composing a message, but prior to
+ sending, the _w_h_o_m command can be used to determine exactly who
a message
+ would go to.
+
+ _M_H provides a natural interface for telling the user's shell
the
+ names of _M_H messages and folders. The _m_h_p_a_t_h
program achieves this
+ capability.
+
+ Finally, _M_H supports the UCI BBoards facility. _b_b_c can
be used to
+ query the status of a group of BBoards, while _m_s_h can be used
to read
+ them. The _b_u_r_s_t command can be used to "shred" digests of
messages into
+
+
+
+
+
+
+
+
+
+
+
+ -6-
+
+
+ individual messages.
+
+ All of the elements summarized above are described in more detail
+ in the following sections. Many of the normal facilities of UNIX pro-
+ vide additional capabilities for dealing with messages in various ways.
+ For example, it is possible to print messages on the line-printer
+ without requiring any additional code within _M_H . Using standard
UNIX
+ facilities, any terminal output can be redirected to a file for repeated
+ or future viewing. In general, the flexibility and capabilities of the
+ UNIX interface with the user are preserved as a result of the integra-
+ tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _3. _T_U_T_O_R_I_A_L
+
+
+
+9
+ This tutorial provides a brief introduction to the _M_H
commands. It
+ should be sufficient to allow the user to read his mail, do some simple
+ manipulations of it, and create and send messages.
+
+ A message has two major pieces: the header and the body. The body
+ consists of the text of the message (whatever you care to type in). It
+ follows the header and is separated from it by an empty line. (When you
+ compose a message, the form that appears on your terminal shows a line
+ of dashes after the header. This is for convenience and is replaced by
+ an empty line when the message is sent.) The header is composed of
+ several components, including the subject of the message and the person
+ to whom it is addressed. Each component starts with a name and a colon;
+ components must not start with a blank. The text of the component may
+ take more than one line, but each continuation line must start with a
+ blank. Messages typically have "To:", "cc:", and "Subject:" components.
+ When composing a message, you should include the "To:" and "Subject:"
+ components; the "cc:" (for people you want to send copies to) is not
+ necessary.
+
+ The basic _M_H commands are _i_n_c, _s_c_a_n,
_s_h_o_w, _n_e_x_t, _p_r_e_v, _r_m_m, _c_o_m_p,
+ and _r_e_p_l. These are described below.
+
+ _i_n_c
+
+ When you get the message "You have mail", type the command
_i_n_c.
+ You will get a "scan listing" such as:
+
+ 7+ 7/13 Cas revival of measurement work
+ 8 10/ 9 Norm NBS people and publications
+ 9 11/26 To:norm question <<Are there any functions
+
+ This shows the messages you received since the last time you exe-
+ cuted this command (_i_n_c adds these new messages to your inbox
folder).
+ You can see this list again, plus a list of any other messages you have,
+ by using the _s_c_a_n command.
+
+ _s_c_a_n
+
+ The scan listing shows the message number, followed by the date and
+ the sender. (If you are the sender, the addressee in the "To:" com-
+ ponent is displayed. You may send yourself a message by including your
+ name among the "To:" or "cc:" addressees.) It also shows the message's
+ subject; if the subject is short, the first part of the body of the mes-
+ sage is included after the characters <<.
+
+
+
+9 -7-
+
+
+
+
+
+
+
+
+
+ -8-
+
+
+ _s_h_o_w
+
+ This command shows the current message, that is, the first one of
+ the new messages after an _i_n_c. If the message is not specified
by name
+ (number), it is generally the last message referred to by an _M_H
command.
+ For example,
+
+
+ _s_h_o_w 5 will show message 5.
+
+
+ You can use the show command to copy a message or print a message.
+
+
+ _s_h_o_w > _x will copy the message to file x.
+ _s_h_o_w | _l_p_r will print the message, using the
_l_p_r command.
+ _n_e_x_t will show the message that follows the current
message.
+ _p_r_e_v will show the message previous to the current
message.
+ _r_m_m will remove the current message.
+ _r_m_m _3 will remove message 3.
+
+
+ _c_o_m_p
+
+ The _c_o_m_p command puts you in the editor to write or edit a
message.
+ Fill in or delete the "To:", "cc:", and "Subject:" fields, as appropri-
+ ate, and type the body of the message. Then exit normally from the edi-
+ tor. You will be asked "What now?". Type a carriage return to see the
+ options. Typing send will cause the message to be sent; typing quit
+ will cause an exit from _c_o_m_p, with the message draft saved.
+
+ If you quit without sending the message, it will be saved in a file
+ called <name>/Mail/draft (where <name> is your $HOME directory). You
+ can resume editing the message later with "comp -use"; or you can send
+ the message later, using the _s_e_n_d command.
+
+ _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+ This command uses a different editor and is useful for preparing
+ "quick and dirty" messages. It prompts you for each component of the
+ header. Type the information for that component, or type a carriage
+ return to omit the component. After that, type the body of the message.
+ Backspacing is the only form of editing allowed with this editor. When
+ the body is complete, type a carriage return followed by <EOT> (usually
+ <CTRL-D>). This completes the initial preparation of the message; from
+ then on, use the same procedures as with _c_o_m_p (above).
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ -9-
+
+
+ _r_e_p_l
+ _r_e_p_l n
+
+ This command makes up an initial message form with a header that is
+ appropriate for replying to an existing message. The message being
+ answered is the current message if no message number is mentioned, or n
+ if a number is specified. After the header is completed, you can finish
+ the message as in _c_o_m_p (above).
+
+ This is enough information to get you going using _M_H. There
are
+ more commands, and the commands described here have more features. Sub-
+ sequent sections explain _M_H in complete detail. The system is
quite
+ powerful if you want to use its sophisticated features, but the forego-
+ ing commands suffice for sending and receiving messages.
+
+ There are numerous additional capabilities you may wish to explore.
+ For example, the _p_i_c_k command will select a subset of messages
based on
+ specified criteria such as sender and/or subject. Groups of messages
+ may be designated, as described in Sec. IV, under Message Naming. The
+ file ._m_h__p_r_o_f_i_l_e can be used to tailor your use of
the message system to
+ your needs and preferences, as described in Sec. IV, under The User Pro-
+ file. In general, you may learn additional features of the system
+ selectively, according to your requirements, by studying the relevant
+ sections of this manual. There is no need to learn all the details of
+ the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _4. _D_E_T_A_I_L_E_D
_D_E_S_C_R_I_P_T_I_O_N
+
+
+
+9
+ This section describes the _M_H system in detail, including the
com-
+ ponents of the user profile, the conventions for message naming, and
+ some of the other _M_H conventions. Readers who are generally
familiar
+ with computer systems will be able to follow the principal ideas,
+ although some details may be meaningful only to those familiar with
+ UNIX.
+
+
+9 _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+ The first time an _M_H command is issued by a new user, the
system
+ prompts for a "Path" and creates an _M_H "profile".
+
+ Each _M_H user has a profile which contains tailoring
information for
+ each individual program. Other profile entries control the _M_H
path
+ (where folders and special files are kept), folder and message protec-
+ tions, editor selection, and default arguments for each _M_H
program.
+ Each user of _M_H also has a context file which contains current
state
+ information for the _M_H package (the location of the context file is
kept
+ in the user's _M_H directory, or may be named in the user profile).
When
+ a folder becomes the current folder, it is recorded in the user's con-
+ text. (Other state information is kept in the context file, see the
+ manual entry for _m_h-_p_r_o_f_i_l_e (5) for more details.)
In general, the term
+ "profile entry" refer to entries in either the profile or context file.
+ Users of _M_H needn't worry about the distinction, _M_H handles
these things
+ automatically.
+
+ The _M_H profile is stored in the file
._m_h__p_r_o_f_i_l_e in the user's
+ $HOME directory[1]. It has the format of a message without any body.
+ That is, each profile entry is on one line, with a keyword followed by a
+ colon (:) followed by text particular to the keyword.
+ => _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t _h_a_v_e
_b_l_a_n_k _l_i_n_e_s.
+ The keywords may have any combination of upper and lower case. (See the
+ information of _m_h-_m_a_i_l later on in this manual for a
description of mes-
+ sage formats.)
+
+ For the average _M_H user, the only profile entry of
importance is
+ "Path". Path specifies a directory in which _M_H folders and
certain
+ files such as "draft" are found. The argument to this keyword must be a
+ legal UNIX path that names an existing directory. If this path is not
+
+
+9 [1] By defining the envariable $MH, you can specify an alternate
pro-
+ file to be used by _M_H commands.
+
+
+9 -10-
+
+
+
+
+
+
+
+
+
+ -11-
+
+
+ absolute (i.e., does not begin with a / ), it will be presumed to start
+ from the user's $HOME directory. All folder and message references
+ within _M_H will relate to this path unless full path names are used.
+
+ Message protection defaults to 644, and folder protection to 711.
+ These may be changed by profile entries "Msg-Protect" and "Folder-
+ Protect", respectively. The argument to these keywords is an octal
+ number which is used as the UNIX file mode[2].
+
+ When an _M_H program starts running, it looks through the user's
pro-
+ file for an entry with a keyword matching the program's name. For exam-
+ ple, when _c_o_m_p is run, it looks for a "comp" profile entry. If
one is
+ found, the text of the profile entry is used as the default switch set-
+ ting until all defaults are overridden by explicit switches passed to
+ the program as arguments. Thus the profile entry
+ "comp: -form standard.list" would direct _c_o_m_p to use
the file
+ "standard.list" as the message skeleton. If an explicit form switch is
+ given to the _c_o_m_p command, it will override the switch obtained
from the
+ profile.
+
+ In UNIX, a program may exist under several names, either by linking
+ or aliasing. The actual invocation name is used by an _M_H program
when
+ scanning for its profile defaults[3]. Thus, each _M_H program may
have
+ several names by which it can be invoked, and each name may have a dif-
+ ferent set of default switches. For example, if _c_o_m_p is
invoked by the
+ name _i_c_o_m_p, the profile entry "icomp" will control the
default switches
+ for this invocation of the _c_o_m_p program. This provides a
powerful
+ definitional facility for commonly used switch settings.
+
+ The default editor for editing within _c_o_m_p, _r_e_p_l,
_f_o_r_w, and _d_i_s_t,
+ is usually _p_r_o_m_p_t_e_r, but might be something else at
your site, such as
+ /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e. A different editor may
be used by specifying the
+ profile entry "Editor: ". The argument to "Editor" is the name of an
+ executable program or shell command file which can be found via the
+ user's $PATH defined search path, excluding the current directory. The
+ "Editor:" profile specification may in turn be overridden by a
+ `-editor <editor>' profile switch associated with _c_o_m_p,
_r_e_p_l, _f_o_r_w, or
+ _d_i_s_t. Finally, an explicit editor switch specified with any
of these
+ four commands will have ultimate precedence.
+
+
+
+9 [2] See _c_h_m_o_d (1) in the _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+ [3] Unfortunately, the shell does not preserve aliasing information
+ when calling a program, hence if a program is invoked by an alias dif-
+ ferent than its name, the program will examine the profile entry for
+ it's name, not the alias that the user invoked it as. The correct solu-
+ tion is to create a (soft) link in your $_H_O_M_E/_b_i_n
directory to the _M_H
+ program of your choice. By giving this link a different name, you can
+ use an alternate set of defaults for the command.
+
+
+9
+
+
+
+
+
+
+
+
+
+ -12-
+
+
+ During message composition, more than one editor may be used. For
+ example, one editor (such as _p_r_o_m_p_t_e_r ) may be used
initially, and a
+ second editor may be invoked later to revise the message being composed
+ (see the discussion of _c_o_m_p in Section 5 for details). A
profile entry
+ "<lasteditor>-next: <editor>" specifies the name of the editor to be
+ used after a particular editor. Thus "comp: -e prompter" causes the
+ initial text to be collected by _p_r_o_m_p_t_e_r, and
the profile entry
+ "prompter-next: ed" names ed as the editor to be invoked for the next
+ round of editing.
+
+ Some of the _M_H commands, such as _s_h_o_w, can be used on
message fold-
+ ers owned by others, if those folders are readable. However, you cannot
+ write in someone else's folder. All the _M_H command actions not
requir-
+ ing write permission may be used with a "read-only" folder.
+
+ Table 1 lists examples of some of the currently defined profile
+ entries, typical arguments, and the programs that reference the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ -13-
+
+
+ Table 1
+9 PROFILE COMPONENTS
+ ______________________________________________________
+
+ _M_H Programs that
+ Keyword and Argument use
Component9______________________________________________________
+9 Path: Mail All
+ Current-Folder: inbox Most
+ Editor: /usr/ucb/ex _c_o_m_p, _d_i_s_t,
_f_o_r_w, _r_e_p_l
+ Msg-Protect: 644 _i_n_c
+ Folder-Protect: 711 _i_n_c, _p_i_c_k,
_r_e_f_i_l_e
+ <program>: default switches All
+ prompter-next: ed _c_o_m_p, _d_i_s_t,
_f_o_r_w, _r_e_p_l
+ ______________________________________________________
+
+
+ Path should______ be present. Current-Folder is maintained
automatically
+ by many _M_H commands (see the Context sections of the individual
commands
+ in Sec. IV). All other entries are optional, defaulting to the values
+ described above.
+
+
+9 _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+ Messages may be referred to explicitly or implicitly when using
_M_H
+ commands. A formal syntax of message names is given in Appendix B, but
+ the following description should be sufficient for most _M_H users.
Some
+ details of message naming that apply only to certain commands are
+ included in the description of those commands.
+
+ Most of the _M_H commands accept arguments specifying one or
more
+ folders, and one or more messages to operate on. The use of the word
+ "msg" as an argument to a command means that exactly one message name
+ may be specified. A message name may be a number, such as 1, 33, or
+ 234, or it may be one of the "reserved" message names: first, last,
+ prev, next, and cur. (As a shorthand, a period (.) is equivalent to
+ cur.) The meanings of these names are straightforward: "first" is the
+ first message in the folder; "last" is the last message in the folder;
+ "prev" is the message numerically previous to the current message;
+ "next" is the message numerically following the current message; "cur"
+ (or ".") is the current message in the folder. In addition, _M_H
supports
+ user-defined-sequences; see the description of the _m_a_r_k command
for more
+ information.
+
+ The default in commands that take a "msg" argument is always "cur".
+
+ The word "msgs" indicates that several messages may be specified.
+ Such a specification consists of several message designations separated
+ by spaces. A message designation is either a message name or a message
+ range. A message range is a specification of the form name1-name2 or
+
+
+
+
+
+
+
+
+
+
+
+ -14-
+
+
+ name1:n, where name1 and name2 are message names and n is an integer.
+ The first form designates all the messages from name1 to name2
+ inclusive; this must be a non-empty range. The second form specifies up
+ to n messages, starting with name1 if name1 is a number, or first, cur,
+ or next, and ending with name1 if name1 is last or prev. This interpre-
+ tation of n is overridden if n is preceded by a plus sign or a minus
+ sign; +n always means up to n messages starting with name1, and -n
+ always means up to n messages ending with name1. Repeated specifica-
+ tions of the same message have the same effect as a single specification
+ of the message. Examples of specifications are:
+
+
+ 1 5 7-11 22
+ first 6 8 next
+ first-10
+ last:5
+
+
+ The message name "all" is a shorthand for "first-last", indicating
+ all of the messages in the folder.
+
+ In commands that accept "msgs" arguments, the default is either cur
+ or all, depending on which makes more sense.
+
+ In all of the _M_H commands, a plus sign preceding an argument
indi-
+ cates a folder name. Thus, "+inbox" is the name of the user's standard
+ inbox. If an explicit folder argument is given to an _M_H
command, it
+ will become the current folder (that is, the "Current-Folder:" entry in
+ the user's profile will be changed to this folder). In the case of the
+ _r_e_f_i_l_e command, which can have multiple output folders,
a new source
+ folder (other than the default current folder) is specified by
+ `-src +folder'.
+
+
+9 _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+ One very powerful feature of _M_H is that the _M_H commands
may be
+ issued from any current directory, and the proper path to the appropri-
+ ate folder(s) will be taken from the user's profile. If the _M_H
path is
+ not appropriate for a specific folder or file, the automatic prepending
+ of the _M_H path can be avoided by beginning a folder or file name
with /,
+ or with ./ or ../ component. Thus any specific absolute path may be
+ specified along with any path relative to the current working directory.
+
+ Arguments to the various programs may be given in any order, with
+ the exception of a few switches whose arguments must follow immediately,
+ such as `-src +folder' for _r_e_f_i_l_e.
+
+ Whenever an _M_H command prompts the user, the valid options
will be
+ listed in response to a <RETURN>. (The first of the listed options is
+ the default if end-of-file is encountered, such as from a command file.)
+
+9
+
+
+
+
+
+
+
+
+
+ -15-
+
+
+ A valid response is any _u_n_i_q_u_e abbreviation of one
of the listed
+ options.
+
+ Standard UNIX documentation conventions are used in this report to
+ describe _M_H command syntax. Arguments enclosed in brackets ([
]) are
+ optional; exactly one of the arguments enclosed within braces ({ }) must
+ be specified, and all other arguments are required. The use of ellipsis
+ dots (...) indicates zero or more repetitions of the previous item. For
+ example, "+folder ..." would indicate that one or more "+folder" argu-
+ ments is required and "[+folder ...]" indicates that 0 or more "+folder"
+ arguments may be given.
+
+ _M_H departs from UNIX standards by using switches that
consist of
+ more than one character, e.g. `-header'. To minimize typing, only a
+ unique abbreviation of a switch need be typed; thus, for `-header',
+ `-hea' is probably sufficient, depending on the other switches the com-
+ mand accepts. Each _M_H program accepts the switch `-help' (which
must be
+ spelled out fully) and produces a syntax description and a list of
+ switches. In the list of switches, parentheses indicate required char-
+ acters. For example, all `-help' switches will appear as "-(help)",
+ indicating that no abbreviation is accepted. Furthermore, the `-help'
+ switch tells the version of the _M_H program you invoked.
+
+ Many _M_H switches have both on and off forms, such as `-format'
and
+ `-noformat'. In many of the descriptions which follow, only one form is
+ defined; the other form, often used to nullify profile switch settings,
+ is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ -16-
+
+
+ _M_H _C_O_M_M_A_N_D_S
+
+ The _M_H package comprises several programs:
+
+ ali (1) - list mail aliases
+ anno (1) - annotate messages
+ bbc (1) - check on BBoards
+ bboards (1) - the UCI BBoards facility
+ burst (1) - explode digests into messages
+ comp (1) - compose a message
+ dist (1) - redistribute a message to additional addresses
+ folder (1) - set/list current folder/message
+ folders (1) - list all folders
+ forw (1) - forward messages
+ inc (1) - incorporate new mail
+ mark (1) - mark messages
+ mhl (1) - produce formatted listings of MH messages
+ mhmail (1) - send or read mail
+ mhook (1) - MH receive-mail hooks
+ mhpath (1) - print full pathnames of MH messages and folders
+ msgchk (1) - check for messages
+ msh (1) - MH shell (and BBoard reader)
+ next (1) - show the next message
+ packf (1) - compress a folder into a single file
+ pick (1) - select messages by content
+ prev (1) - show the previous message
+ prompter (1) - prompting editor front end
+ rcvstore (1) - incorporate new mail asynchronously
+ refile (1) - file messages in other folders
+ repl (1) - reply to a message
+ rmf (1) - remove folder
+ rmm (1) - remove messages
+ scan (1) - produce a one line per message scan listing
+ send (1) - send a message
+ show (1) - show (list) messages
+ sortm (1) - sort messages
+ vmh (1) - visual front-end to MH
+ whatnow (1) - prompting front-end for send
+ whom (1) - report to whom a message would go
+
+
+ These programs are described below. The form of the descriptions
+ conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ ALI(1) -17- ALI(1)
+
+
+ _N_A_M_E
+ ali - list mail aliases
+
+ _S_Y_N_O_P_S_I_S
+ ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_l_i searches the named mail alias files for each of the
given
+ _a_l_i_a_s_e_s. It creates a list of addresses for those
_a_l_i_a_s_e_s, and
+ writes that list on standard output. If the `-list' option is
+ specified, each address appears on a separate line; otherwise, the
+ addresses are separated by commas and printed on as few lines as
+ possible.
+
+ The `-user' option directs _a_l_i to perform its processing in
an
+ inverted fashion: instead of listing the addresses that each given
+ alias expands to, _a_l_i will list the aliases that expand to
each
+ given address. If the `-normalize' switch is given, _a_l_i will
try
+ to track down the official hostname of the address.
+
+ The file specified by the profile entry "Aliasfile:" and any addi-
+ tional alias files given by the `-alias aliasfile' switch will be
+ read. Each _a_l_i_a_s is processed as described in
_m_h-_a_l_i_a_s (5).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /etc/passwd List of users
+ /etc/group List of groups
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-nolist'
+ `-nonormalize'
+ `-nouser'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ ALI(1) -18- ALI(1)
+
+
+ _B_u_g_s
+ The `-user' option with `-nonormalize' is not entirely accurate, as
+ it does not replace local nicknames for hosts with their official
+ site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -19- ANNO(1)
+
+
+ _N_A_M_E
+ anno - annotate messages
+
+ _S_Y_N_O_P_S_I_S
+ anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_n_n_o annotates the specified messages in the named folder using
the
+ field and body. Annotation is optionally performed by _d_i_s_t,
_f_o_r_w,
+ and _r_e_p_l, to keep track of your distribution of, forwarding of,
and
+ replies to a message. By using _a_n_n_o, you can perform
arbitrary
+ annotations of your own. Each message selected will be annotated
+ with the lines
+
+ field: date
+ field: body
+
+ The `-nodate' switch inhibits the date annotation, leaving only the
+ body annotation. The `-inplace' switch causes annotation to be
+ done in place in order to preserve links to the annotated message.
+
+ The field specified should be a valid 822-style message field name,
+ which means that it should consist of alphanumerics (or dashes)
+ only. The body specified is arbitrary text.
+
+ If a `-component field' is not specified when _a_n_n_o is invoked,
_a_n_n_o
+ will prompt the user for the name of field for the annotation.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ dist (1), forw (1), repl (1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-date'
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -20- ANNO(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The first
+ message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBC(1) -21- BBC(1)
+
+
+ _N_A_M_E
+ bbc - check on BBoards
+
+ _S_Y_N_O_P_S_I_S
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile
rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+ [-host host] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _b_b_c is a BBoard reading/checking program that interfaces to
the
+ BBoard channel.
+
+ The _b_b_c program has three action switches which direct its
opera-
+ tion:
+
+ The `-read' switch invokes the _m_s_h program on the named
_B_B_o_a_r_d_s.
+ If you also specify the `-archive' switch, then _b_b_c will
invoke
+ the _m_s_h program on the archives of the named
_B_B_o_a_r_d_s. If no
+ _B_B_o_a_r_d_s are given on the command line, and you
specified
+ `-archive', _b_b_c will not read your `bboards' profile entry,
but
+ will read the archives of the "system" _B_B_o_a_r_d instead.
+
+ The `-check' switch types out status information for the named
+ _B_B_o_a_r_d_s. _b_b_c can print one of several messages
depending on the
+ status of both the BBoard and the user's reading habits. As with
+ each of these messages, the number given is the item number of the
+ last item placed in the BBoard. This number (which is marked in
+ the messages as the "BBoard-Id") is ever increasing. Hence, when
+ _b_b_c says "n items", it really means that the highest BBoard-Id
is
+ "n". There may, or may not actually be "n" items in the BBoard.
+ Some common messages are:
+
+ BBoard -- n items unseen
+ This message tells how many items the user has not yet
+ seen. When invoked with the `-quiet' switch, this is the
+ only informative line that _b_b_c will possibly print out.
+
+ BBoard -- empty
+ The BBoard is empty.
+
+ BBoard -- n items (none seen)
+ The BBoard has items in it, but the user hasn't seen any.
+
+ BBoard -- n items (all seen)
+ The BBoard is non-empty, and the user has seen everything
+ in it.
+
+ BBoard -- n items seen out of m
+ The BBoard has at most m-n items that the user has not
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBC(1) -22- BBC(1)
+
+
+ seen.
+
+ The `-topics' switch directs _b_b_c to print three items about
the
+ named _B_B_o_a_r_d_s: it's official name, the number of items
present, and
+ the date and time of the last update. If no _B_B_o_a_r_d_s
are named,
+ then all BBoards are listed. If the `-verbose' switch is given,
+ more information is output.
+
+ The `-quiet' switch specifies that _b_b_c should be silent if
no
+ _B_B_o_a_r_d_s are found with new information. The
`-verbose' switch
+ specifies that _b_b_c is to consider you to be interested in
_B_B_o_a_r_d_s
+ that you've already seen everything in.
+
+ To override the default _m_s_h_p_r_o_c and the profile entry,
use the
+ `-mshproc program' switch. Any arguments not understood by _b_b_c
are
+ passed to this program. The `-protocol' switch tells _b_b_c that
your
+ _m_s_h_p_r_o_c knows about the special _b_b_c protocol
for reporting back
+ information. _m_s_h (1), the default _m_s_h_p_r_o_c, knows
all about this.
+
+ The `-file BBoardsfile' switch tells _b_b_c to use a
non-standard
+ _B_B_o_a_r_d_s file when performing its calculations.
Similarly, the
+ `-user BBoardsuser' switch tells _b_b_c to use a non-standard
user-
+ name. Both of these switches are useful for debugging a new
+ _B_B_o_a_r_d_s or _P_O_P file.
+
+ If the local host is configured as an NNTP BBoards client, or if
+ the `-host host' switch is given, then _b_b_c will query the NNTP
ser-
+ vice host as to the status of the BBoards. For NNTP BBoards
+ clients, the `-user user' and the `-rpop' switches are ignored.
+
+ The `-rcfile rcfile' switch overrides the use of ._b_b_r_c
for
+ user-specific BBoards information. If the value given to the
+ switch is not absolute, (i.e., does not begin with a / ), it will
+ be presumed to start from the current working directory. If this
+ switch is not given (or the `-norcfile' switch is given), then
_b_b_c
+ consults the envariable $MHBBRC, and honors it similarly. If this
+ envariable is not set, then the file ._b_b_r_c in the user's
$HOME
+ directory is used.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard information
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBC(1) -23- BBC(1)
+
+
+ _S_e_e _A_l_s_o
+ bbl(1), bboards(1), msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-read'
+ `-noarchive'
+ `-protocol'
+ `bboards' defaults to "system"
+ `-file /usr/bboards/BBoards'
+ `-user bboards'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The `-user' switch takes effect only if followed by the `-file'
+ switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -24- BBOARDS(1)
+
+
+ _N_A_M_E
+ bboards - the UCI BBoards facility
+
+ _S_Y_N_O_P_S_I_S
+ bbc [-check] [-read] bboards ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The home directory of _b_b_o_a_r_d_s is where the BBoard system
is kept.
+ This documentation describes some of the nuances of the BBoard sys-
+ tem.
+
+ BBoards, BBoard-IDs
+ A BBoard is just a file containing a group of messages relat-
+ ing to the same topic. These files live in the ~bboards home
+ directory. Each message in a BBoard file has in its header
+ the line "BBoard-Id: n", where "n" is an ascending decimal
+ number. This id-number is unique for each message in a
+ BBoards file. It should NOT be confused with the message
+ number of a message, which can change as messages are removed
+ from the BBoard.
+
+ BBoard Handling
+ To read BBoards, use the _b_b_c and _m_s_h programs. The
_m_s_h com-
+ mand is a monolithic program which contains all the func-
+ tionality of _M_H in a single program. The `-check' switch to
+ _b_b_c lets you check on the status of BBoards, and the
`-read'
+ switch tells _b_b_c to invoke _m_s_h to read those BBoards.
+
+ Creating a BBoard
+ Both public, and private BBoards are supported. Contact the
+ mail address _P_o_s_t_M_a_s_t_e_r if you'd like to
have a BBoard
+ created.
+
+ BBoard addresses
+ Each BBoard has associated with it 4 addresses, these are (for
+ the ficticious BBoard called ``hacks''):
+ hacks : The Internet wide distribution list.
+ dist-hacks : The local BBoard.
+ hacks-request : The people responsible for the BBoard at the
+ Internet level.
+ local-hacks-request : The people responsible for the BBoard
+ locally.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard information
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -25- BBOARDS(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+ _S_e_e _A_l_s_o
+ bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ The default bboard is "system"
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BURST(1) -26- BURST(1)
+
+
+ _N_A_M_E
+ burst - explode digests into messages
+
+ _S_Y_N_O_P_S_I_S
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _B_u_r_s_t considers the specified messages in the named folder
to be
+ Internet digests, and explodes them in that folder.
+
+ If `-inplace' is given, each digest is replaced by the "table of
+ contents" for the digest (the original digest is removed).
_B_u_r_s_t
+ then renumbers all of the messages following the digest in the
+ folder to make room for each of the messages contained within the
+ digest. These messages are placed immediately after the digest.
+
+ If `-noinplace' is given, each digest is preserved, no table of
+ contents is produced, and the messages contained within the digest
+ are placed at the end of the folder. Other messages are not tam-
+ pered with in any way.
+
+ The `-quiet' switch directs _b_u_r_s_t to be silent about
reporting mes-
+ sages that are not in digest format.
+
+ The `-verbose' switch directs _b_u_r_s_t to tell the user the
general
+ actions that it is taking to explode the digest.
+
+ It turns out that _b_u_r_s_t works equally well on forwarded
messages
+ and blind-carbon-copies as on Internet digests, provided that the
+ former two were generated by _f_o_r_w or _s_e_n_d.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new message
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ inc(1), msh(1), pack(1)
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ BURST(1) -27- BURST(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-noquiet'
+ `-noverbose'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. If `-in-
+ place' is given, then the first message burst becomes the current
+ message. This leaves the context ready for a _s_h_o_w of the table
of
+ contents of the digest, and a _n_e_x_t to see the first message of
the
+ digest. If `-noinplace' is given, then the first message extracted
+ from the first digest burst becomes the current message. This
+ leaves the context in a similar, but not identical, state to the
+ context achieved when using `-inplace'.
+
+
+ _B_u_g_s
+ The _b_u_r_s_t program enforces a limit on the number of messages
which
+ may be _b_u_r_s_t from a single message. This number is on the
order of
+ 1000 messages. There is usually no limit on the number of messages
+ which may reside in the folder after the _b_u_r_s_ting.
+
+ Although _b_u_r_s_t uses a sophisticated algorithm to determine
where
+ one encapsulated message ends and another begins, not all digesti-
+ fying programs use an encapsulation algorithm. In degenerate
+ cases, this usually results in _b_u_r_s_t finding an encapsulation
boun-
+ dary prematurely and splitting a single encapsulated message into
+ two or more messages. These erroneous digestifying programs should
+ be fixed.
+
+ Furthermore, any text which appears after the last encapsulated
+ message is not placed in a seperate message by _b_u_r_s_t. In
the case
+ of digestified messages, this text is usally an "End of digest"
+ string. As a result of this possibly un-friendly behavior on the
+ part of _b_u_r_s_t, note that when the `-inplace' option is used,
this
+ trailing information is lost. In practice, this is not a problem
+ since correspondents usually place remarks in text prior to the
+ first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ COMP(1) -28- COMP(1)
+
+
+ _N_A_M_E
+ comp - compose a message
+
+ _S_Y_N_O_P_S_I_S
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_m_p is used to create a new message to be mailed. It
copies a
+ message form to the draft being composed and then invokes an editor
+ on the draft (unless `-noedit' is given, in which case the initial
+ edit is suppressed).
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "components" exists in the user's MH directory,
+ it will be used instead of this form. The file specified by
+ `-form formfile' will be used if given. You may also start
_c_o_m_p
+ using the contents of an existing message as the form. If you sup-
+ ply either a `+folder' or `msg' argument, that message will be used
+ as the form. You may not supply both a `-form formfile' and a
+ `+folder' or `msg' argument. The line of dashes or a blank line
+ must be left between the header and the body of the message for the
+ message to be identified properly when it is sent (see _s_e_n_d
(1)).
+ The switch `-use' directs _c_o_m_p to continue editing an
already
+ started message. That is, if a _c_o_m_p (or _d_i_s_t,
_r_e_p_l, or _f_o_r_w ) is
+ terminated without sending the draft, the draft can be edited again
+ via "comp -use".
+
+ If the draft already exists, _c_o_m_p will ask you as to the
disposi-
+ tion of the draft. A reply of quit will abort _c_o_m_p, leaving
the
+ draft intact; replace will replace the existing draft with the
+ appropriate form; list will display the draft; use will use the
+ draft for further composition; and refile +folder will file the
+ draft in the given folder, and give you a new draft with the
+ appropriate form. (The `+folder' argument to refile is required.)
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ The `-file file' switch says to use the named file as the message
+ draft.
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ COMP(1) -29- COMP(1)
+
+
+ The `-editor editor' switch indicates the editor to use for the
+ initial edit. Upon exiting from the editor, _c_o_m_p will invoke
the
+ _w_h_a_t_n_o_w program. See _w_h_a_t_n_o_w (1) for a
discussion of available
+ options. The invocation of this program can be inhibited by using
+ the `-nowhatnowproc' switch. (In truth of fact, it is the
_w_h_a_t_n_o_w
+ program which starts the initial edit. Hence, `-nowhatnowproc'
+ will prevent any edit from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/components The message skeleton
+ or <mh-dir>/components Rather than the standard skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new message
+ (draft)
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to the current message
+ `-nodraftfolder'
+ `-nouse'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then
_c_o_m_p uses a built-in _w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program. Hence, if
you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _c_o_m_p won't run
+ it.
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ DIST(1) -30- DIST(1)
+
+
+ _N_A_M_E
+ dist - redistribute a message to additional addresses
+
+ _S_Y_N_O_P_S_I_S
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_i_s_t is similar to _f_o_r_w. It prepares the specified
message for
+ redistribution to addresses that (presumably) are not on the origi-
+ nal address list.
+
+ The default message form contains the following elements:
+
+ Resent-To:
+ Resent-cc:
+
+ If the file named "distcomps" exists in the user's MH directory, it
+ will be used instead of this form. In either case, the file speci-
+ fied by `-form formfile' will be used if given. The form used will
+ be prepended to the message being resent.
+
+ If the draft already exists, _d_i_s_t will ask you as to the
disposi-
+ tion of the draft. A reply of quit will abort _d_i_s_t, leaving
the
+ draft intact; replace will replace the existing draft with a blank
+ skeleton; and list will display the draft.
+
+ Only those addresses in "Resent-To:", "Resent-cc:", and
+ "Resent-Bcc:" will be sent. Also, a "Resent-Fcc: folder" will be
+ honored (see _s_e_n_d (1)). Note that with _d_i_s_t, the draft
should con-
+ tain only "Resent-xxx:" fields and no body. The headers and the
+ body of the original message are copied to the draft when the mes-
+ sage is sent. Use care in constructing the headers for the redis-
+ tribution.
+
+ If the `-annotate' switch is given, the message being distributed
+ will be annotated with the lines:
+
+ Resent: date
+ Resent: addrs
+
+ where each address list contains as many lines as required. This
+ annotation will be done only if the message is sent directly from
+ _d_i_s_t. If the message is not sent immediately from
_d_i_s_t, "comp
+ -use" may be used to re-edit and send the constructed message, but
+ the annotations won't take place. The '-inplace' switch causes
+ annotation to be done in place in order to preserve links to the
+ annotated message.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ DIST(1) -31- DIST(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor' and
`-noedit'
+ switches. Note that while in the editor, the message being resent
+ is available through a link named "@" (assuming the default
_w_h_a_t_-
+ _n_o_w_p_r_o_c ). In addition, the actual pathname of the
message is
+ stored in the envariable $editalt, and the pathname of the folder
+ containing the message is stored in the envariable $mhfolder.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _d_i_s_t will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available options.
The invoca-
+ tion of this program can be inhibited by using the `-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w program
which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/distcomps The message skeleton
+ or <mh-dir>/distcomps Rather than the standard skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The mes-
+ sage distributed will become the current message.
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ DIST(1) -32- DIST(1)
+
+
+ _H_i_s_t_o_r_y
+ _D_i_s_t originally used headers of the form "Distribute-xxx:"
instead
+ of "Resent-xxx:". In order to conform with the ARPA Internet stan-
+ dard, RFC-822, the "Resent-xxx:" form is now used. _D_i_s_t
will
+ recognize "Distribute-xxx:" type headers and automatically convert
+ them to "Resent-xxx:".
+
+
+ _B_u_g_s
+ _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check the message
being distributed for
+ adherence to the transport standard, but _p_o_s_t called by
_s_e_n_d does.
+ The _p_o_s_t program will balk (and rightly so) at poorly
formatted
+ messages, and _d_i_s_t won't correct things for you.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then
_d_i_s_t uses a built-in _w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program. Hence, if
you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _d_i_s_t won't run
+ it.
+
+ If your current working directory is not writable, the link named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -33- FOLDER(1)
+
+
+ _N_A_M_E
+ folder, folders - set/list current folder/message
+
+ _S_Y_N_O_P_S_I_S
+ folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+ [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+ [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+ [-pop] [-help]
+
+ folders
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Since the _M_H environment is the shell, it is easy to lose track of
+ the current folder from day to day.
+
+ When _f_o_l_d_e_r is given the `-print' switch (the default), the
current
+ folder and/or message may be set, or all folders may be listed.
+ When a `+folder' argument is given, this corresponds to a "cd"
+ operation in the _C_S_h_e_l_l; when no `+folder' argument is
given, this
+ corresponds roughly to a "pwd" operation in the _C_S_h_e_l_l.
+
+ _F_o_l_d_e_r will list the current folder, the number of messages
in it,
+ the range of the messages (low-high), and the current message
+ within the folder, and will flag extra files if they exist. An
+ example of the output is:
+
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+
+ If a `+folder' and/or `msg' are specified, they will become the
+ current folder and/or message. Specifying `-all' will produce a
+ line for each folder in the user's MH directory, sorted alphabeti-
+ cally. These folders are preceded by the read-only folders, which
+ occur as "atr-cur-" entries in the user's _M_H context. For example,
+
+ Folder # of messages ( range ) cur msg (other files)
+ /fsd/rs/m/tacc has 35 messages ( 1- 35); cur= 23.
+ /rnd/phyl/Mail/EP has 82 messages ( 1-108); cur= 82.
+ ff has no messages.
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+ mh has 76 messages ( 1- 76); cur= 70.
+ notes has 2 messages ( 1- 2); cur= 1.
+ ucom has 124 messages ( 1-124); cur= 6; (others).
+ TOTAL= 339 messages in 7 folders
+
+ The "+" after inbox indicates that it is the current folder. The
+ "(others)" indicates that the folder `ucom' has files which aren't
+ messages. These files may either be sub-folders, or files that
+ don't belong under the MH file naming scheme.
+
+ The header is output if either an `-all' or a `-header' switch is
+ specified; it is suppressed by `-noheader'. Also, if
_f_o_l_d_e_r is
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -34- FOLDER(1)
+
+
+ invoked by a name ending with "s" (e.g., _f_o_l_d_e_r_s ),
`-all' is
+ assumed. A `-total' switch will produce only the summary line.
+
+ If a `+folder' and/or `msg' is given along with the `-all' switch,
+ _f_o_l_d_e_r will, in addition to setting the current folder
and/or mes-
+ sage, list the top-level folders for the current folder (with
+ `-norecurse') or list all folders under the current folder recur-
+ sively (with `-recurse').
+
+ If `-fast' is given, only the folder name (or names in the case of
+ `-all') will be listed. (This is faster because the folders need
+ not be read.)
+
+ The `-pack' switch will compress the message names in a folder,
+ removing holes in message numbering.
+
+ The `-recurse' switch will list each folder recursively. Use of
+ this option effectively defeats the speed enhancement of the
+ `-fast' option, since each folder must be searched for subfolders.
+ Nevertheless, the combination of these options is useful.
+
+ If the specified (or default) folder doesn't exist, the user will
+ be queried as to whether the folder should be created. When stan-
+ dard input is not a tty, the folder is created without any query.
+ (This is the easy way to create an empty folder for use later.)
+
+ The `-push' switch directs _f_o_l_d_e_r to push the current
folder onto
+ the _f_o_l_d_e_r-_s_t_a_c_k, and make the `+folder'
argument the current
+ folder. If `+folder' is not given, the current folder and the top
+ of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged. This
corresponds to the "pushd"
+ operation in the _C_S_h_e_l_l.
+
+ The `-pop' switch directs _f_o_l_d_e_r to discard the top
of the
+ _f_o_l_d_e_r-_s_t_a_c_k, after setting the current folder
to that value. No
+ `+folder' argument is allowed. This corresponds to the "popd"
+ operation in the _C_S_h_e_l_l. The `-push' switch and the
`-pop' switch
+ are mutually exclusive: the last occurrence of either one overrides
+ any previous occurrence of the other.
+
+ The `-list' switch directs _f_o_l_d_e_r to list the contents
of the
+ _f_o_l_d_e_r-_s_t_a_c_k. No `+folder' argument is allowed.
After a success-
+ ful `-push' or `-pop', the `-list' action is taken. This
+ corresponds to the "dirs" operation in the _C_S_h_e_l_l.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -35- FOLDER(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ Folder-Stack: To determine the folder stack
+ lsproc: Program to list the contents of a folder
+
+
+ _S_e_e _A_l_s_o
+ refile(1), mhpath(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to none
+ `-nofast'
+ `-noheader'
+ `-nototal'
+ `-nopack'
+ `-norecurse'
+ `-print' is the default if no `-list', `-push', or `-pop' is specified
+
+
+ _C_o_n_t_e_x_t
+ If `+folder' and/or `msg' are given, they will become the current
+ folder and/or message.
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the `-fast' switch prevented context
+ changes from occurring for the current folder. This is no longer
+ the case: if `+folder' is given, then _f_o_l_d_e_r will always
change the
+ current folder to that.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FORW(1) -36- FORW(1)
+
+
+ _N_A_M_E
+ forw - forward messages
+
+ _S_Y_N_O_P_S_I_S
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _F_o_r_w may be used to prepare a message containing other
messages.
+ It constructs the new message from the components file or
+ `-form formfile' (see _c_o_m_p ), with a body composed of
the
+ message(s) to be forwarded. An editor is invoked as in _c_o_m_p,
and
+ after editing is complete, the user is prompted before the message
+ is sent.
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "forwcomps" exists in the user's MH directory, it
+ will be used instead of this form. In either case, the file speci-
+ fied by `-form formfile' will be used if given.
+
+ If the draft already exists, _f_o_r_w will ask you as to the
disposi-
+ tion of the draft. A reply of quit will abort _f_o_r_w, leaving
the
+ draft intact; replace will replace the existing draft with a blank
+ skeleton; and list will display the draft.
+
+ If the `-annotate' switch is given, each message being forwarded
+ will be annotated with the lines
+
+ Forwarded: date
+ Forwarded: addrs
+
+ where each address list contains as many lines as required. This
+ annotation will be done only if the message is sent directly from
+ _f_o_r_w. If the message is not sent immediately from
_f_o_r_w,
+ "comp -use" may be used to re-edit and send the constructed mes-
+ sage, but the annotations won't take place. The '-inplace' switch
+ causes annotation to be done in place in order to preserve links to
+ the annotated message.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FORW(1) -37- FORW(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor' and
`-noedit'
+ switches.
+
+ Although _f_o_r_w uses the `-form formfile' switch to direct it how
to
+ construct the beginning of the draft, the `-filter filterfile',
+ `-format', and `-noformat' switches direct _f_o_r_w as to how each
for-
+ warded message should be formatted in the body of the draft. If
+ `-noformat' is specified, then each forwarded message is output
+ exactly as it appears. If `-format' or `-filter filterfile' is
+ specified, then each forwarded message is filtered (re-formatted)
+ prior to being output to the body of the draft. The filter file
+ for _f_o_r_w should be a standard form file for _m_h_l, as
_f_o_r_w will
+ invoke _m_h_l to format the forwarded messages. The default
message
+ filter (what you get with `-format') is:
+
+ width=80,overflowtext=,overflowoffset=10
+ leftadjust,compress,compwidth=9
+ Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ To:
+ cc:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+ If the file named "mhl.forward" exists in the user's MH directory,
+ it will be used instead of this form. In either case, the file
+ specified by `-filter filterfile' will be used if given. To sum-
+ marize: `-noformat' will reproduce each forwarded message exactly,
+ `-format' will use _m_h_l and a default filterfile, "mhl.forward",
to
+ format each forwarded message, and `-filter filterfile' will use
+ the named filterfile to format each forwarded message with _m_h_l.
+
+ Each forwarded message is separated with an encapsulation delimiter
+ and dashes in the first column of the forwarded messages will be
+ prepended with `- ' so that when received, the message is suitable
+ for bursting by _b_u_r_s_t (1). This follows the Internet
RFC-934
+ guidelines.
+
+ For users of _p_r_o_m_p_t_e_r (1), by specifying prompter's
`-prepend'
+ switch in the .mh_profile file, any commentary text is entered
+ before the forwarded messages. (A major win!)
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _f_o_r_w will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available options.
The invoca-
+ tion of this program can be inhibited by using the `-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w program
which starts
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FORW(1) -38- FORW(1)
+
+
+ the initial edit. Hence, `-nowhatnowproc' will prevent any edit
+ from occurring.)
+
+ The `-digest list', `-issue number', and `-volume number' switches
+ implement a digest facility for _M_H. Specifying these switches
+ enables and/or overloads the following escapes:
+
+ _T_y_p_e _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _c_o_m_p_o_n_e_n_t _d_i_g_e_s_t string Argument to
`-digest'
+ _f_u_n_c_t_i_o_n _c_u_r integer Argument to `-volume'
+ _f_u_n_c_t_i_o_n _m_s_g integer Argument to `-issue'
+
+ Consult the Advanced Features section of the _M_H User's Manual for
+ more information on making digests.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/forwcomps The message skeleton
+ or <mh-dir>/forwcomps Rather than the standard skeleton
+ /usr/local/lib/mh/digestcomps The message skeleton if `-digest'
is given
+ or <mh-dir>/digestcomps Rather than the standard skeleton
+ /usr/local/lib/mh/mhl.forward The message filter
+ or <mh-dir>/mhl.forward Rather than the standard filter
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter messages being forwarded
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noformat'
+ `-noinplace'
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ FORW(1) -39- FORW(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The first
+ message forwarded will become the current message.
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then
_f_o_r_w uses a built-in _w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program. Hence, if
you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _f_o_r_w won't run
+ it.
+
+ When _f_o_r_w is told to annotate the messages it forwards, it
doesn't
+ actually annotate them until the draft is successfully sent. If
+ from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h instead of
_s_e_n_d, it's possible to
+ confuse _f_o_r_w by re-ordering the file (e.g., by
using
+ `folder -pack') before the message is successfully sent. _D_i_s_t
and
+ _r_e_p_l don't have this problem.
+
+ To avoid prepending the leading dash characters in forwarded mes-
+ sages, there is a `-nodashmunging' option. See the "Hidden
+ Features" section of the _M_H
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ INC(1) -40- INC(1)
+
+
+ _N_A_M_E
+ inc - incorporate new mail
+
+ _S_Y_N_O_P_S_I_S
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-form formatfile] [-format string]
+ [-file name] [-silent] [-nosilent] [-truncate] [-notruncate]
+ [-width columns] [-host host] [-user user] [-pack file]
+ [-nopack] [-rpop] [-norpop] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _I_n_c incorporates mail from the user's incoming mail drop into an
_M_H
+ folder. If `+folder' isn't specified, the folder named "inbox" in
+ the user's _M_H directory will be used. The new messages being
+ incorporated are assigned numbers starting with the next highest
+ number in the folder. If the specified (or default) folder doesn't
+ exist, the user will be queried prior to its creation. As the mes-
+ sages are processed, a _s_c_a_n listing of the new mail is produced.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it will
+ be used as the protection on the newly created messages, otherwise
+ the _M_H default of 0644 will be used. During all operations on mes-
+ sages, this initially assigned protection will be preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a protection
on an
+ individual message, and its protection will be preserved
+ thereafter.
+
+ If the switch `-audit audit-file' is specified (usually as a
+ default switch in the profile), then _i_n_c will append a header
line
+ and a line per message to the end of the specified audit-file with
+ the format:
+
+ <<inc>> date
+ <scan line for first message>
+ <scan line for second message>
+ <etc.>
+
+ This is useful for keeping track of volume and source of incoming
+ mail. Eventually, _r_e_p_l, _f_o_r_w, _c_o_m_p, and
_d_i_s_t may also produce
+ audits to this (or another) file, perhaps with "Message-Id:" infor-
+ mation to keep an exact correspondence history. "Audit-file" will
+ be in the user's MH directory unless a full path is specified.
+
+ _I_n_c will incorporate even improperly formatted messages into
the
+ user's MH folder, inserting a blank line prior to the offending
+ component and printing a comment identifying the bad message.
+
+ In all cases, the user's mail drop will be zeroed, unless the
+ `-notruncate' switch is given.
+
+ If the profile entry "Unseen-Sequence" is present and non-empty,
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ INC(1) -41- INC(1)
+
+
+ then _i_n_c will add each of the newly incorporated messages to
each
+ sequence named by the profile entry. This is similar to the
+ "Previous-Sequence" profile entry supported by all _M_H commands
+ which take `msgs' or `msg' arguments. Note that _i_n_c will not
zero
+ each sequence prior to adding messages.
+
+ The interpretation of the `-form formatfile', `-format string', and
+ `-width columns' switches is the same as in _s_c_a_n (1).
+
+ By using the `-file name' switch, one can direct _i_n_c to
incorporate
+ messages from a file other than the user's maildrop. Note that the
+ name file will NOT be zeroed, unless the `-truncate' switch is
+ given.
+
+ If the envariable $MAILDROP is set, then _i_n_c uses it as the
loca-
+ tion of the user's maildrop instead of the default (the `-
+ file name' switch still overrides this, however). If this envari-
+ able is not set, then _i_n_c will consult the profile entry
"MailDrop"
+ for this information. If the value found is not absolute, then it
+ is interpreted relative to the user's _M_H directory. If the value
+ is not found, then _i_n_c will look in the standard system
location
+ for the user's maildrop.
+
+ The `-silent' switch directs _i_n_c to be quiet and not ask any
ques-
+ tions at all. This is useful for putting _i_n_c in the background
and
+ going on to other things.
+
+ If the local host is configured as a POP client, or if the
+ `-host host' switch is given, then _i_n_c will query the POP
service
+ host as to the status of mail waiting. The `-user user' switch may
+ be given to specify the name of the POP subscriber you wish to
+ check mail for on the POP service host. The `-rpop' switch uses
+ the UNIX _r_P_O_P (authentication done via trusted connections).
In
+ contrast, the `-norpop' switch uses the ARPA _P_O_P (in which case
_i_n_c
+ will prompt for a password).
+
+ If _i_n_c uses POP, then the `-pack file' switch is considered.
If
+ given, then _i_n_c simply uses the POP to _p_a_c_k_f (1) the
user's mail-
+ drop from the POP service host to the named file. This switch is
+ provided for those users who prefer to use _m_s_h to read their
mail-
+ drops.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ INC(1) -42- INC(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Folder-Protect: To set mode when creating a new folder
+ Msg-Protect: To set mode when creating a new message and
+ audit-file
+ Unseen-Sequence: To name sequences denoting unseen messages
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to "inbox"
+ `-noaudit'
+ `-changecur'
+ `-format' defaulted as described above
+ `-nosilent'
+ `-truncate' if `-file name' not given, `-notruncate' otherwise
+ `-width' defaulted to the width of the terminal
+ `-nopack'
+ `-rpop'
+
+
+ _C_o_n_t_e_x_t
+ The folder into which messages are being incorporated will become
+ the current folder. The first message incorporated will become the
+ current message, unless the `-nochangecur' option is specified.
+ This leaves the context ready for a _s_h_o_w of the first new
message.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a sin-
+ gle token by the shell that invokes _i_n_c. Therefore, one must
usu-
+ ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MARK(1) -43- MARK(1)
+
+
+ _N_A_M_E
+ mark - mark messages
+
+ _S_Y_N_O_P_S_I_S
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_a_r_k command manipulates message sequences by adding or
delet-
+ ing message numbers from folder-specific message sequences, or by
+ listing those sequences and messages. A message sequence is a key-
+ word, just like one of the "reserved" message names, such as
+ "first" or "next". Unlike the "reserved" message names, which have
+ a fixed semantics on a per-folder basis, the semantics of a message
+ sequence may be defined, modified, and removed by the user. Mes-
+ sage sequences are folder-specific, e.g., the sequence name "seen"
+ in the context of folder "+inbox" need not have any relation what-
+ soever to the sequence of the same name in a folder of a different
+ name.
+
+ Three action switches direct the operation of _m_a_r_k. These
switches
+ are mutually exclusive: the last occurrence of any of them over-
+ rides any previous occurrence of the other two.
+
+ The `-add' switch tells _m_a_r_k to add messages to sequences or
to
+ create a new sequence. For each sequence named via the
+ `-sequence name' argument (which must occur at least once) the mes-
+ sages named via `msgs' (which defaults to "cur" if no `msgs' are
+ given), are added to the sequence. The messages to be added need
+ not be absent from the sequence. If the `-zero' switch is speci-
+ fied, the sequence will be emptied prior to adding the messages.
+ Hence, `-add -zero' means that each sequence should be initialized
+ to the indicated messages, while `-add -nozero' means that each
+ sequence should be appended to by the indicated messages.
+
+ The `-delete' switch tells _m_a_r_k to delete messages from
sequences,
+ and is the dual of `-add'. For each of the named sequences, the
+ named messages are removed from the sequence. These messages need
+ not be already present in the sequence. If the `-zero' switch is
+ specified, then all messages in the folder are appended to the
+ sequence prior to removing the messages. Hence, `-delete -zero'
+ means that each sequence should contain all messages except those
+ indicated, while `-delete -nozero' means that only the indicated
+ messages should be removed from each sequence. As expected, the
+ command `mark -sequence seen -delete all' deletes the sequence
+ "seen" from the current folder.
+
+ When creating (or modifying) a sequence, the `-public' switch indi-
+ cates that the sequence should be made readable for other _M_H users.
+ In contrast, the `-nopublic' switch indicates that the sequence
+ should be private to the user's _M_H environment.
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MARK(1) -44- MARK(1)
+
+
+ The `-list' switch tells _m_a_r_k to list both the sequences
defined
+ for the folder and the messages associated with those sequences.
+ _M_a_r_k will list each sequence named via `-sequence name' (or all
of
+ them if `-sequence' isn't used), and the messages associated with
+ that sequence. The `-zero' switch does not affect the operation of
+ `-list'.
+
+ The current restrictions on sequences are:
+
+ The name used to denote a message sequence must consist of an
+ alphabetic character followed by zero or more alphanumeric char-
+ acters, and can not be one of the "reserved" message names (e.g.,
+ "first", "cur", and so forth).
+
+ Only a certain number of sequences may be defined for a given
+ folder. This number is usually limited to 10.
+
+ Message ranges with user-defined sequence names are restricted to
+ the form "name:n" or "name:-n", and refer to the first or last
+ `n' messages of the sequence `name', respectively. Constructs of
+ the form "name1-name2" are forbidden.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ pick (1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-add' if `-sequence' is specified, `-list' otherwise
+ `msgs' defaults to cur (or all if `-list' is specified)
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHL(1) -45- MHL(1)
+
+
+ _N_A_M_E
+ mhl - produce formatted listings of MH messages
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_l is a formatted message listing program. It can be used as
a
+ replacement for _m_o_r_e (1) (the default
_s_h_o_w_p_r_o_c ). As with _m_o_r_e,
+ each of the messages specified as arguments (or the standard input)
+ will be output. If more than one message file is specified, the
+ user will be prompted prior to each one, and a <RETURN> or <EOT>
+ will begin the output, with <RETURN> clearing the screen (if
+ appropriate), and <EOT> (usually CTRL-D) suppressing the screen
+ clear. An <INTERRUPT> (usually CTRL-C) will abort the current mes-
+ sage output, prompting for the next message (if there is one), and
+ a <QUIT> (usually CTRL-\) will terminate the program (without core
+ dump).
+
+ The `-bell' option tells _m_h_l to ring the terminal's bell at the
end
+ of each page, while the `-clear' option tells _m_h_l to clear
the
+ scree at the end of each page (or output a formfeed after each mes-
+ sage). Both of these switches (and their inverse counterparts)
+ take effect only if the profile entry _m_o_r_e_p_r_o_c is
defined but
+ empty, and _m_h_l is outputting to a terminal. If the
_m_o_r_e_p_r_o_c entry
+ is defined and non-empty, and _m_h_l is outputting to a terminal,
then
+ _m_h_l will cause the _m_o_r_e_p_r_o_c to be placed
between the terminal and
+ _m_h_l and the switches are ignored. Furthermore, if the
`-clear'
+ switch is used and _m_h_l'_s output is directed to a terminal, then
_m_h_l
+ will consult the $TERM and $TERMCAP envariables to determine the
+ user's terminal type in order to find out how to clear the screen.
+ If the `-clear' switch is used and _m_h_l'_s output is not directed
to
+ a terminal (e.g., a pipe or a file), then _m_h_l will send a
formfeed
+ after each message.
+
+ To override the default _m_o_r_e_p_r_o_c and the profile
entry, use the
+ `-moreproc program' switch. Note that _m_h_l will never start
a
+ _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+ The `-length length' and `-width width' switches set the screen
+ length and width, respectively. These default to the values indi-
+ cated by $TERMCAP, if appropriate, otherwise they default to 40 and
+ 80, respectively.
+
+ The default format file used by _m_h_l is called
_m_h_l._f_o_r_m_a_t (which is
+ first searched for in the user's _M_H directory, and then sought in
+ the /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h directory), this can be
changed by using the
+ `-form formatfile' switch.
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHL(1) -46- MHL(1)
+
+
+ Finally, the `-folder +folder' switch sets the _M_H folder name,
+ which is used for the "messagename:" field described below. The
+ envariable $mhfolder is consulted for the default value, which
+ _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize appropriately.
+
+ _M_h_l operates in two phases: 1) read and parse the format file,
and
+ 2) process each message (file). During phase 1, an internal
+ description of the format is produced as a structured list. In
+ phase 2, this list is walked for each message, outputting message
+ information under the format constraints from the format file.
+
+ The "mhl.format" form file contains information controlling screen
+ clearing, screen size, wrap-around control, transparent text, com-
+ ponent ordering, and component formatting. Also, a list of com-
+ ponents to ignore may be specified, and a couple of "special" com-
+ ponents are defined to provide added functionality. Message output
+ will be in the order specified by the order in the format file.
+
+ Each line of mhl.format has one of the formats:
+
+ ;comment
+ :cleartext
+ variable[,variable...]
+ component:[variable,...]
+
+ A line beginning with a `;' is a comment, and is ignored. A line
+ beginning with a `:' is clear text, and is output exactly as is. A
+ line containing only a `:' produces a blank line in the output. A
+ line beginning with "component:" defines the format for the speci-
+ fied component, and finally, remaining lines define the global
+ environment.
+
+ For example, the line:
+
+ width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+ defines the screen size to be 80 columns by 40 rows, specifies that
+ the screen should be cleared prior to each page, that the overflow
+ indentation is 5, and that overflow text should be flagged with
+ "***".
+
+ Following are all of the current variables and their arguments. If
+ they follow a component, they apply only to that component, other-
+ wise, their affect is global. Since the whole format is parsed
+ before any output processing, the last global switch setting for a
+ variable applies to the whole message if that variable is used in a
+ global context (i.e., bell, clearscreen, width, length).
+
+ _v_a_r_i_a_b_l_e _t_y_p_e
_s_e_m_a_n_t_i_c_s
+ width integer screen width or component width
+ length integer screen length or component length
+ offset integer positions to indent "component: "
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHL(1) -47- MHL(1)
+
+
+ overflowtext string text to use at the beginning of an
+ overflow line
+ overflowoffset integer positions to indent overflow lines
+ compwidth integer positions to indent component text
+ after the first line is output
+ uppercase flag output text of this component in all
+ upper case
+ nouppercase flag don't uppercase
+ clearscreen flag/G clear the screen prior to each page
+ noclearscreen flag/G don't clearscreen
+ bell flag/G ring the bell at the end of each page
+ nobell flag/G don't bell
+ component string/L name to use instead of "component" for
+ this component
+ nocomponent flag don't output "component: " for this
+ component
+ center flag center component on line (works for
+ one-line components only)
+ nocenter flag don't center
+ leftadjust flag strip off leading whitespace on each
+ line of text
+ noleftadjust flag don't leftadjust
+ compress flag change newlines in text to spaces
+ nocompress flag don't compress
+ split flag don't combine multiple fields into a
single field
+ nosplit flag combine multiple fields into a single
field
+ formatfield string format string for this component (see
below)
+ addrfield flag field contains addresses
+ datefield flag field contains dates
+
+ To specify the value of integer-valued and string-valued variables,
+ follow their name with an equals-sign and the value.
+ Integer-valued variables are given decimal values, while
+ string-valued variables are given arbirtray text bracketed by
+ double-quotes. If a value is suffixed by "/G" or "/L", then its
+ value is useful in a global-only or local-only context (respec-
+ tively).
+
+ A line of the form:
+
+ ignores=component,...
+
+ specifies a list of components which are never output.
+
+ The component "MessageName" (case-insensitive) will output the
+ actual message name (file name) preceded by the folder name if one
+ is specified or found in the environment. The format is identical
+ to that produced by the `-header' option to _s_h_o_w.
+
+ The component "Extras" will output all of the components of the
+ message which were not matched by explicit components, or included
+ in the ignore list. If this component is not specified, an ignore
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHL(1) -48- MHL(1)
+
+
+ list is not needed since all non-specified components will be
+ ignored.
+
+ If "nocomponent" is NOT specified, then the component name will be
+ output as it appears in the format file.
+
+ The default format is:
+
+ : -- using template mhl.format --
+ overflowtext="***",overflowoffset=5
+ leftadjust,compwidth=9
+ ignores=msgid,message-id,received
+ Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+ To:
+ cc:
+ :
+ From:
+ Subject:
+ :
+ extras:nocomponent
+ :
+ body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+ The variable "formatfield" specifies a format string (see
+ _m_h-_f_o_r_m_a_t (5)). The flag variables "addrfield" and
"datefield"
+ (which are mutually exclusive), tell _m_h_l to interpret the
escapes
+ in the format string as either addresses or dates, respectively.
+
+ By default, _m_h_l does not apply any formatting string to fields
con-
+ taining address or dates (see _m_h-_m_a_i_l (5) for a list
of these
+ fields). Note that this results in faster operation since _m_h_l
must
+ parse both addresses and dates in order to apply a format string to
+ them. If desired, _m_h_l can be given a default format string
for
+ either address or date fields (but not both). To do this, on a
+ global line specify: either the flag addrfield or datefield, along
+ with the apropriate formatfield variable string.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mhl.format The message template
+ or <mh-dir>/mhl.format Rather than the standard template
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ moreproc: Program to use as interactive front-end
+
+
+ _S_e_e _A_l_s_o
+ show(1), ap(8), dp(8)
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHL(1) -49- MHL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-bell'
+ `-noclear'
+ `-length 40'
+ `-width 80'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ There should be some way to pass `bell' and `clear' information to
+ the front-end.
+
+ On hosts where _M_H was configured with the BERK option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -50- MHMAIL(1)
+
+
+ _N_A_M_E
+ mhmail - send or read mail
+
+ _S_Y_N_O_P_S_I_S
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H_m_a_i_l is intended as a replacement for the standard Bell
mail pro-
+ gram (_b_e_l_l_m_a_i_l (1)), compatible with _M_H. When
invoked without
+ arguments, it simply invokes _i_n_c (1) to incorporate new
messages
+ from the user's maildrop. When one or more users is specified, a
+ message is read from the standard input and spooled to a temporary
+ file. _M_H_m_a_i_l then invokes _p_o_s_t (8) with the name
of the temporary
+ file as its argument to deliver the message to the specified user.
+
+ The `-subject subject' switch can be used to specify the "Subject:"
+ field of the message. The `-body text' switch can be used to
+ specify the text of the message; if it is specified, then the stan-
+ dard input is not read. Normally, addresses appearing as arguments
+ are put in the "To:" field. If the `-cc' switch is used, all
+ addresses following it are placed in the "cc:" field.
+
+ By using `-from addr', you can specify the "From:" header of the
+ draft. Naturally, _p_o_s_t will fill-in the "Sender:"
header
+ correctly.
+
+ This program is intended for the use of programs such as _a_t (1),
+ which expect to send mail automatically to various users. Nor-
+ mally, real people (as opposed to the "unreal" ones) will prefer to
+ use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+ _F_i_l_e_s
+ /usr/local/inc Program to incorporate a maildrop
into a folder
+ /usr/local/lib/mh/post Program to deliver a message
+ /tmp/mhmail* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ inc(1), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -51- MHMAIL(1)
+
+
+ _C_o_n_t_e_x_t
+ If _i_n_c is invoked, then _i_n_c's context changes occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -52- MHOOK(1)
+
+
+ _N_A_M_E
+ mhook - MH receive-mail hooks
+
+ _S_Y_N_O_P_S_I_S
+ $HOME/.maildelivery
+
+ /usr/local/lib/mh/rcvdist [-form formfile] [switches for
_p_o_s_t_p_r_o_c]
+ address ... [-help]
+
+ /usr/local/lib/mh/rcvpack file [-help]
+
+ /usr/local/lib/mh/rcvtty [command] [-form formatfile]
+ [-format string] [-bell] [-nobell] [-newline] [-nonewline]
+ [-biff] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ A receive-mail hook is a program that is run whenever you receive a
+ mail message. You do NOT invoke the hook yourself, rather the hook
+ is invoked on your behalf by _M_M_D_F.
+
+ The ._m_a_i_l_d_e_l_i_v_e_r_y file, which is an ordinary
ASCII file, controls
+ how local delivery is performed. This file is read by the local
+ channel. See _m_a_i_l_d_e_l_i_v_e_r_y (5) for the details.
+
+ Four programs are currently standardly available,
_r_c_v_d_i_s_t (redis-
+ tribute incoming messages to additional recipients),
_r_c_v_p_a_c_k (save
+ incoming messages in a _p_a_c_k_f'd file), and _r_c_v_t_t_y
(notify user of
+ incoming messages). The fourth program, _r_c_v_s_t_o_r_e (1)
is described
+ separately. They all reside in the
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/ directory.
+
+ The _r_c_v_d_i_s_t program will resend a copy of the message to
all of the
+ addresses listed on its command line. It uses the format string
+ facility described in _m_h-_f_o_r_m_a_t (5).
+
+ The _r_c_v_p_a_c_k program will append a copy of the message to
the file
+ listed on its command line. Its use is obsoleted by the
._m_a_i_l_-
+ _d_e_l_i_v_e_r_y.
+
+ The _r_c_v_t_t_y program executes the named file with the message
as its
+ standard input, and writes the resulting output on your terminal.
+
+ If no file is specified, or is bogus, etc., then
_r_c_v_t_t_y will
+ instead write a one-line scan listing. Either the
+ `-form formatfile' or `-format string' option may be used to over-
+ ride the default output format (see _m_h-_f_o_r_m_a_t (5)).
A newline is
+ output before the message output, and the terminal bell is rung
+ after the output. The `-nonewline' and `-nobell' options will
+ inhibit these functions.
+
+ Normally, _r_c_v_t_t_y obeys write permission as granted by
_m_e_s_g (1).
+ With the `-biff' option, _r_c_v_t_t_y will obey the
notification status
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -53- MHOOK(1)
+
+
+ set by _b_i_f_f (1). If the terminal access daemon (TTYD) is
available
+ on your system, then _r_c_v_t_t_y will give its output to the
daemon for
+ output instead of writing on the user's terminal.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ $HOME/.maildelivery The file controlling local delivery
+ /usr/local/lib/mh/maildelivery Rather than the standard file
+
+
+ _S_e_e _A_l_s_o
+ rcvstore (1), maildelivery(5), mh-format(5)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Only two return codes are meaningful, others should be.
+
+ Versions of _M_M_D_F with the _m_a_i_l_d_e_l_i_v_e_r_y
mechanism aren't entirely
+ backwards-compatible with earlier versions. If you have an
+ old-style hook, the best you can do is to have a one-line
._m_a_i_l-
+ _d_e_l_i_v_e_r_y file:
+
+ default - pipe A "bin/rcvmail $(address) $(info) $(sender)"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -54- MHPATH(1)
+
+
+ _N_A_M_E
+ mhpath - print full pathnames of MH messages and folders
+
+ _S_Y_N_O_P_S_I_S
+ mhpath [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_p_a_t_h expands and sorts the message list `msgs' and
writes the
+ full pathnames of the messages to the standard output separated by
+ newlines. If no `msgs' are specified, _m_h_p_a_t_h outputs the
folder
+ pathname instead. If the only argument is `+', your MH
_P_a_t_h is
+ output; this can be useful is shell scripts.
+
+ Contrasted with other MH commands, a message argument to
_m_h_p_a_t_h may
+ often be intended for _w_r_i_t_i_n_g. Because of this: 1) the
name "new"
+ has been added to _m_h_p_a_t_h's list of reserved message names
(the oth-
+ ers are "first", "last", "prev", "next", "cur", and "all"). The
+ new message is equivalent to the message after the last message in
+ a folder (and equivalent to 1 in a folder without messages). The
+ "new" message may not be used as part of a message range. 2)
+ Within a message list, the following designations may refer to mes-
+ sages that do not exist: a single numeric message name, the single
+ message name "cur", and (obviously) the single message name "new".
+ All other message designations must refer to at least one existing
+ message. 3) An empty folder is not in itself an error.
+
+ Message numbers greater than the highest existing message in a
+ folder as part of a range designation are replaced with the next
+ free message number.
+
+ Examples: The current folder foo contains messages 3 5 6. Cur is
+ 4.
+
+ % mhpath
+ /r/phyl/Mail/foo
+
+ % mhpath all
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath 2001
+ /r/phyl/Mail/foo/7
+
+ % mhpath 1-2001
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath new
+ /r/phyl/Mail/foo/7
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -55- MHPATH(1)
+
+
+ % mhpath last new
+ /r/phyl/Mail/foo/6
+ /r/phyl/Mail/foo/7
+
+ % mhpath last-new
+ bad message list "last-new".
+
+ % mhpath cur
+ /r/phyl/Mail/foo/4
+
+ % mhpath 1-2
+ no messages in range "1-2".
+
+ % mhpath first:2
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+
+ % mhpath 1 2
+ /r/phyl/Mail/foo/1
+ /r/phyl/Mail/foo/2
+
+ _M_H_p_a_t_h is also useful in back-quoted operations:
+
+ % cd `mhpath +inbox`
+
+ % echo `mhpath +`
+ /r/phyl/Mail
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to none
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -56- MHPATH(1)
+
+
+ _B_u_g_s
+ Like all MH commands, _m_h_p_a_t_h expands and sorts [msgs].
So don't
+ expect
+
+ mv `mhpath 501 500`
+
+ to move 501 to 500. Quite the reverse. But
+
+ mv `mhpath 501` `mhpath 500`
+
+ will do the trick.
+
+ Out of range message 0 is treated far more severely than large out
+ of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -57- MSGCHK(1)
+
+
+ _N_A_M_E
+ msgchk - check for messages
+
+ _S_Y_N_O_P_S_I_S
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [-host host] [-user user] [-rpop]
+ [-norpop] [users ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_s_g_c_h_k program checks all known mail drops for mail
waiting for
+ you. For those drops which have mail for you, _m_s_g_c_h_k will
indicate
+ if it believes that you have seen the mail in question before.
+
+ The `-notify type' switch indicates under what circumstances
_m_s_g_c_h_k
+ should produce a message. The default is `-notify all' which says
+ that _m_s_g_c_h_k should always report the status of the users
maildrop.
+ Other values for `type' include `mail' which says that
_m_s_g_c_h_k
+ should report the status of waiting mail; and, `nomail' which says
+ that _m_s_g_c_h_k should report the status of empty
maildrops. The
+ `-nonotify type' switch has the inverted sense, so `-nonotify all'
+ directs _m_s_g_c_h_k to never report the status of maildrops.
This is
+ useful if the user wishes to check _m_s_g_c_h_k's exit
status. A
+ non-zero exit status indicates that mail was not waiting for at
+ least one of the indicated users.
+
+ If _m_s_g_c_h_k produces output, then the `-date' switch directs
_m_s_g_c_h_k
+ to print out the last date mail was read, if this can be deter-
+ mined.
+
+ If the local host is configured as a POP client, or if the
+ `-host host' switch is given, _m_s_g_c_h_k will query the POP
service
+ host as to the status of mail waiting. The `-user user' switch may
+ be given to specify the name of the POP subscriber you wish to
+ check mail for on the POP service host. The `-rpop' switch uses
+ the UNIX _r_P_O_P (authentication done via trusted connections).
In
+ contrast, the `-norpop' switch uses the ARPA _P_O_P (in which
case
+ _m_s_g_c_h_k will prompt for a password).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -58- MSGCHK(1)
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `user' defaults to the current user
+ `-date'
+ `-notify all'
+ `-rpop'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSH(1) -59- MSH(1)
+
+
+ _N_A_M_E
+ msh - MH shell (and BBoard reader)
+
+ _S_Y_N_O_P_S_I_S
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _m_s_h is an interactive program that implements a subset of the
nor-
+ mal _M_H commands operating on a single file in _p_a_c_k_f'd
format. That
+ is, _m_s_h is used to read a file that contains a number of
messages,
+ as opposed to the standard _M_H style of reading a number of files,
+ each file being a separate message in a folder. _m_s_h's chief
advan-
+ tage is that the normal _M_H style does not allow a file to have more
+ than one message in it. Hence, _m_s_h is ideal for reading
_B_B_o_a_r_d_s,
+ as these files are delivered by the transport system in this for-
+ mat. In addition, _m_s_h can be used on other files, such as
message
+ archives which have been _p_a_c_ked (see _p_a_c_k_f (1)).
Finally, _m_s_h is
+ an excellent _M_H tutor. As the only commands available to the user
+ are _M_H commands, this allows _M_H beginners to concentrate on
how
+ commands to _M_H are formed and (more or less) what they mean.
+
+ When invoked, _m_s_h reads the named file, and enters a command
loop.
+ The user may type most of the normal _M_H commands. The syntax and
+ semantics of these commands typed to _m_s_h are identical to their
_M_H
+ counterparts. In cases where the nature of _m_s_h would be
incon-
+ sistent (e.g., specifying a `+folder' with some commands), _m_s_h
will
+ duly inform the user. The commands that _m_s_h currently supports
(in
+ some slightly modified or restricted forms) are:
+
+ ali
+ burst
+ comp
+ dist
+ folder
+ forw
+ inc
+ mark
+ mhmail
+ msgchk
+ next
+ packf
+ pick
+ prev
+ refile
+ repl
+ rmm
+ scan
+ send
+ show
+ sortm
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSH(1) -60- MSH(1)
+
+
+ whatnow
+ whom
+
+ In addition, _m_s_h has a "help" command which gives a brief
overview.
+ To terminate _m_s_h, type CTRL-D, or use the "quit" command. If
_m_s_h
+ is being invoked from _b_b_c, then typing CTRL-D will also tell
_b_b_c to
+ exit as well, while using the "quit" command will return control to
+ _b_b_c, and _b_b_c will continue examining the list of BBoards
that it is
+ scanning.
+
+ If the file is writable and has been modified, then using "quit"
+ will query the user if the file should be updated.
+
+ The `-prompt string' switch sets the prompting string for _m_s_h.
+
+ You may wish to use an alternate _M_H profile for the commands that
+ _m_s_h executes; see _m_h-_p_r_o_f_i_l_e (5) for details
about the $MH envari-
+ able.
+
+ When invoked from _b_b_c, two special features are enabled: First,
the
+ `-scan' switch directs _m_s_h to do a `scan unseen' on start-up if
new
+ items are present in the BBoard. This feature is best used from
+ _b_b_c, which correctly sets the stage. Second, the _m_a_r_k
command in
+ _m_s_h acts specially when you are reading a BBoard, since
_m_s_h will
+ consult the sequence "unseen" in determining what messages you have
+ actually read. When _m_s_h exits, it reports this information to
_b_b_c.
+ In addition, if you give the _m_a_r_k command with no arguments,
_m_s_h
+ will interpret it as `mark -sequence unseen -delete -nozero all'
+ Hence, to discard all of the messages in the current BBoard you're
+ reading, just use the _m_a_r_k command with no arguments.
+
+ Normally, the "exit" command is identical to the "quit" command in
+ _m_s_h. When run under _b_b_c however, "exit" directs
_m_s_h to mark all
+ messages as seen and then "quit". For speedy type-in, this command
+ is often abbreviated as just "e".
+
+ When invoked from _v_m_h, another special feature is enabled:
The
+ `topcur' switch directs _m_s_h to have the current message "track"
the
+ top line of the _v_m_h scan window. Normally, _m_s_h has the
current
+ message "track" the center of the window (under `-notopcur', which
+ is the default).
+
+ _m_s_h supports an output redirection facility. Commands may be
fol-
+ lowed by one of
+
+ > _f_i_l_e write output to _f_i_l_e
+ >> _f_i_l_e append output to _f_i_l_e
+ | _c_o_m_m_a_n_d pipe output to UNIX _c_o_m_m_a_n_d
+
+ If _f_i_l_e starts with a `~' (tilde), then a _c_s_h-like
expansion takes
+ place. Note that _c_o_m_m_a_n_d is interpreted by _s_h (1).
Also note that
+ _m_s_h does NOT support history substitutions, variable
substitutions,
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSH(1) -61- MSH(1)
+
+
+ or alias substitutions.
+
+ When parsing commands to the left of any redirection symbol,
_m_s_h
+ will honor `\' (back-slash) as the quote next-character symbol, and
+ `"' (double-quote) as quote-word delimiters. All other input
+ tokens are separated by whitespace (spaces and tabs).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Msg-Protect: To set mode when creating a new `file'
+ fileproc: Program to file messages
+ showproc: Program to show messages
+
+
+ _S_e_e _A_l_s_o
+ bbc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to "./msgbox"
+ `-prompt (msh) '
+ `-noscan'
+ `-notopcur'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MSH(1) -62- MSH(1)
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a sin-
+ gle token by the shell that invokes _m_s_h. Therefore, one must
usu-
+ ally place the argument to this switch inside double-quotes.
+
+ There is a strict limit of messages per file in _p_a_c_k_f'd
format
+ which _m_s_h can handle. Usually, this limit is 1000 messages.
+
+ Please remember that _m_s_h is not the _C_S_h_e_l_l, and that
a lot of the
+ nice facilities provided by the latter are not present in the form-
+ er.
+
+ In particular, _m_s_h does not understand back-quoting, so the
only
+ effective way to use _p_i_c_k inside _m_s_h is to
always use the
+ `-seq select' switch. Clever users of _M_H will put the line
+
+ pick: -seq select -list
+
+ in their .mh_profile file so that _p_i_c_k works equally well from
both
+ the shell and _m_s_h.
+
+ _s_o_r_t_m always uses "-noverbose" and if "-textfield field" is
used,
+ "-limit 0".
+
+ The _m_s_h program inherits most (if not all) of the bugs from the
_M_H
+ commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ NEXT(1) -63- NEXT(1)
+
+
+ _N_A_M_E
+ next - show the next message
+
+ _S_Y_N_O_P_S_I_S
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _N_e_x_t performs a _s_h_o_w on the next message in the
specified (or
+ current) folder. Like _s_h_o_w, it passes any switches on to the
pro-
+ gram _s_h_o_w_p_r_o_c, which is called to list the message.
This command
+ is almost exactly equivalent to "show next". Consult the manual
+ entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), prev(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder. The
+ message that is shown (i.e., the next message in sequence) will be-
+ come the current message.
+
+
+ _B_u_g_s
+ _n_e_x_t is really a link to the _s_h_o_w program. As a
result, if you
+ make a link to _n_e_x_t and that link is not called
_n_e_x_t, your link
+ will act like _s_h_o_w instead. To circumvent this, add
a
+ profile-entry for the link to your _M_H profile and add the argument
+ _n_e_x_t to the entry.
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PACKF(1) -64- PACKF(1)
+
+
+ _N_A_M_E
+ packf - compress a folder into a single file
+
+ _S_Y_N_O_P_S_I_S
+ packf [+folder] [msgs] [-file name] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_a_c_k_f takes messages from a folder and copies them to a
single
+ file. Each message in the file is separated by four CTRL-A's and a
+ newline (identical to the way messages are stored in your receiving
+ mail drop). Messages packed can be unpacked using _i_n_c.
+
+ If the _n_a_m_e given to the `-file name' switch exists, then the
mes-
+ sages specified will be appended to the end of the file, otherwise
+ the file will be created and the messages appended.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new `file'
+
+
+ _S_e_e _A_l_s_o
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-file ./msgbox'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The first
+ message packed will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PICK(1) -65- PICK(1)
+
+
+ _N_A_M_E
+ pick - select messages by content
+
+ _S_Y_N_O_P_S_I_S
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-after date]
+ [-before date] [-datefield field] [-sequence name ...]
+ [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+ [-help]
+
+ typically:
+ scan `pick -from jones`
+ pick -to holloway -sequence select
+ show `pick -before friday`
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_i_c_k searches messages within a folder for the specified
contents,
+ and then identifies those messages. Two types of search primitives
+ are available: pattern matching and date constraint operations.
+
+ A modified _g_r_e_p(1) is used to perform the matching, so the
full
+ regular expression (see _e_d(1)) facility is available within `pat-
+ tern'. With `-search', `pattern' is used directly, and with the
+ others, the grep pattern constructed is:
+
+ "component[ \t]*:.*pattern"
+
+ This means that the pattern specified for a `-search' will be found
+ everywhere in the message, including the header and the body, while
+ the other pattern matching requests are limited to the single
+ specified component. The expression
+
+ `--component pattern'
+
+ is a shorthand for specifying
+
+ `-search "component[ \t]*:.*pattern" '
+
+ It is used to pick a component which is not one of "To:", "cc:",
+ "Date:", "From:", or "Subject:". An example is
+ `pick --reply-to pooh'.
+
+ Pattern matching is performed on a per-line basis. Within the
+ header of the message, each component is treated as one long line,
+ but in the body, each line is separate. Lower-case letters in the
+ search pattern will match either lower or upper case in the mes-
+ sage, while upper case will match only upper case.
+
+ Note that since the `-date' switch is a pattern matching operation
+ (as described above), to find messages sent on a certain date the
+ pattern string must match the text of the "Date:" field of the
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PICK(1) -66- PICK(1)
+
+
+ message.
+
+ Independent of any pattern matching operations requested, the
+ switches `-after date' or `-before date' may also be used to intro-
+ duce date/time contraints on all of the messages. By default, the
+ "Date:" field is consulted, but if another date yielding field
+ (such as "BB-Posted:" or "Delivery-Date:") should be used, the
+ `-datefield field' switch may be used.
+
+ With `-before' and `-after', _p_i_c_k will actually parse the
date
+ fields in each of the messages specified in `msgs' and compare them
+ to the date/time specified. If `-after' is given, then only those
+ messages whose "Date:" field value is chronologically after the
+ date specified will be considered. The `-before' switch specifies
+ the complimentary action.
+
+ Both the `-after' and `-before' switches take legal 822-style date
+ specifications as arguments. _P_i_c_k will default certain
missing
+ fields so that the entire date need not be specified. These fields
+ are (in order of defaulting): timezone, time and timezone, date,
+ date and timezone. All defaults are taken from the current date,
+ time, and timezone.
+
+ In addition to 822-style dates, _p_i_c_k will also recognize any of
the
+ days of the week ("sunday", "monday", and so on), and the special
+ dates "today", "yesterday" (24 hours ago), and "tomorrow" (24 hours
+ from now). All days of the week are judged to refer to a day in
+ the past (e.g., telling _p_i_c_k "saturday" on a "tuesday"
means
+ "last saturday" not "this saturday").
+
+ Finally, in addition to these special specifications, _p_i_c_k
will
+ also honor a specification of the form "-dd", which means "dd days
+ ago".
+
+ _P_i_c_k supports complex boolean operations on the searching
primi-
+ tives with the `-and', `-or', `-not', and `-lbrace ... -rbrace'
+ switches. For example,
+
+ pick -after yesterday -and -lbrace -from freida -or -from fear
-rbrace
+
+ identifies messages recently sent by "frieda" or "fear".
+
+ The matching primitives take precedence over the `-not' switch,
+ which in turn takes precedence over `-and' which in turn takes pre-
+ cedence over `-or'. To override the default precedence, the
+ `-lbrace' and `-rbrace' switches are provided, which act just like
+ opening and closing parentheses in logical expressions.
+
+ Once the search has been performed, if the `-list' switch is given,
+ the message numbers of the selected messages are written to the
+ standard output separated by newlines. This is
_e_x_t_r_e_m_e_l_y useful
+ for quickly generating arguments for other _M_H programs by using the
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PICK(1) -67- PICK(1)
+
+
+ "backquoting" syntax of the shell. For example, the command
+
+ scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+ says to _s_c_a_n those messages in the indicated folder which meet
the
+ appropriate criterion. Note that since _p_i_c_k 's context changes
are
+ written out prior to _s_c_a_n 's invocation, you need not give
the
+ folder argument to _s_c_a_n as well.
+
+ Regardless of the operation of the `-list' switch, the `-sequence
+ name' switch may be given once for each sequence the user wishes to
+ define. For each sequence named, that sequence will be defined to
+ mean exactly those messages selected by _p_i_c_k. For example,
+
+ pick -from frated -seq fred
+
+ defines a new message sequence for the current folder called "fred"
+ which contains exactly those messages that were selected.
+
+ Note that whenever _p_i_c_k processes a `-sequence name' switch,
it
+ sets `-nolist'.
+
+ By default, _p_i_c_k will zero the sequence before adding it.
This
+ action can be disabled with the `-nozero' switch, which means that
+ the messages selected by _p_i_c_k will be added to the sequence, if
it
+ already exists, and any messages already a part of that sequence
+ will remain so.
+
+ The `-public' and `-nopublic' switches are used by _p_i_c_k in the
same
+ way _m_a_r_k uses them.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ mark(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-zero'
+ `-list' is the default if no `-sequence', `-nolist' otherwise
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PICK(1) -68- PICK(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the _p_i_c_k command would
_s_h_o_w, _s_c_a_n, or
+ _r_e_f_i_l_e the selected messages. This was rather
"inverted logic"
+ from the UNIX point of view, so _p_i_c_k was changed to define
se-
+ quences and output those sequences. Hence, _p_i_c_k can be
used to
+ generate the arguments for all other _M_H commands, instead of giving
+ _p_i_c_k endless switches for invoking those commands itself.
+
+ Also, previous versions of _p_i_c_k balked if you didn't
specify a
+ search string or a date/time constraint. The current version does
+ not, and merely matches the messages you specify. This lets you
+ type something like:
+
+ show `pick last:20 -seq fear`
+
+ instead of typing
+
+ mark -add -nozero -seq fear last:20
+ show fear
+
+ Finally, timezones used to be ignored when comparing dates: they
+ aren't any more.
+
+
+ _B_u_g_s
+ The argument to the `-after' and `-before' switches must be inter-
+ preted as a single token by the shell that invokes _p_i_c_k.
There-
+ fore, one must usually place the argument to this switch inside
+ double-quotes. Furthermore, any occurance of `-datefield' must oc-
+ cur prior to the `-after' or `-before' switch it applies to.
+
+ If _p_i_c_k is used in a back-quoted operation, such as
+
+ scan `pick -from jones`
+
+ and _p_i_c_k fails (e.g., no messages are from "jones"), then the
shell
+ will still run the outer command (e.g., "scan"). Since no messages
+ were matched, _p_i_c_k produced no output, and the argument given
to
+ the outer command as a result of backquoting _p_i_c_k is empty. In
the
+ case of _M_H programs, the outer command now acts as if the default
+ `msg' or `msgs' should be used (e.g., "all" in the case of
_s_c_a_n ).
+ To prevent this unexpected behavior, if `-list' was given, and if
+ its standard output is not a tty, then _p_i_c_k outputs the
illegal
+ message number "0" when it fails. This lets the outer command fail
+ gracefully as well.
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PREV(1) -69- PREV(1)
+
+
+ _N_A_M_E
+ prev - show the previous message
+
+ _S_Y_N_O_P_S_I_S
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [-switches for _s_h_o_w_p_r_o_c] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_r_e_v performs a _s_h_o_w on the previous message in the
specified (or
+ current) folder. Like _s_h_o_w, it passes any switches on to the
pro-
+ gram named by _s_h_o_w_p_r_o_c, which is called to list the
message. This
+ command is almost exactly equivalent to "show prev". Consult the
+ manual entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), next(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder. The
+ message that is shown (i.e., the previous message in sequence) will
+ become the current message.
+
+
+ _B_u_g_s
+ _p_r_e_v is really a link to the _s_h_o_w program. As a
result, if you
+ make a link to _p_r_e_v and that link is not called
_p_r_e_v, your link
+ will act like _s_h_o_w instead. To circumvent this, add
a
+ profile-entry for the link to your _M_H profile and add the argument
+ _p_r_e_v to the entry.
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -70- PROMPTER(1)
+
+
+ _N_A_M_E
+ prompter - prompting editor front-end
+
+ _S_Y_N_O_P_S_I_S
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This program is normally not invoked directly by users but takes
+ the place of an editor and acts as an editor front-end. It
+ operates on an 822-style message draft skeleton specified by file,
+ normally provided by _c_o_m_p, _d_i_s_t, _f_o_r_w, or
_r_e_p_l.
+
+ _P_r_o_m_p_t_e_r is an editor which allows rapid composition
of messages.
+ It is particularly useful to network and low-speed (less than 2400
+ baud) users of _M_H. It is an _M_H program in that it can have its
own
+ profile entry with switches, but it is not invoked directly by the
+ user. The commands _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l invoke _p_r_o_m_p_t_e_r as
+ an editor, either when invoked with `-editor prompter', or by the
+ profile entry "Editor: prompter", or when given the command
+ `edit prompter' at "What now?" level.
+
+ For each empty component _p_r_o_m_p_t_e_r finds in the draft,
the user is
+ prompted for a response; A <RETURN> will cause the whole component
+ to be left out. Otherwise, a `\' preceding a <RETURN> will con-
+ tinue the response on the next line, allowing for multiline com-
+ ponents. Continuation lines must begin with a space or tab.
+
+ Each non-empty component is copied to the draft and displayed on
+ the terminal.
+
+ The start of the message body is denoted by a blank line or a line
+ of dashes. If the body is non-empty, the prompt, which isn't writ-
+ ten to the file, is
+
+ "--------Enter additional text",
+
+ or (if `-prepend' was given)
+
+ "--------Enter initial text".
+
+ Message-body typing is terminated with an end-of-file (usually
+ CTRL-D). With the `-doteof' switch, a period on a line all by
+ itself also signifies end-of-file. At this point control is
+ returned to the calling program, where the user is asked "What
+ now?". See _w_h_a_t_n_o_w for the valid options to this query.
+
+ By using the `-prepend' switch, the user can add type-in to the
+ beginning of the message body and have the rest of the body follow.
+ This is useful for the _f_o_r_w command.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -71- PROMPTER(1)
+
+
+ By using the `-rapid' switch, if the draft already contains text in
+ the message-body, it is not displayed on the user's terminal. This
+ is useful for low-speed terminals.
+
+ The line editing characters for kill and erase may be specified by
+ the user via the arguments `-kill chr' and `-erase chr', where chr
+ may be a character; or `\nnn', where "nnn" is the octal value for
+ the character.
+
+ An interrupt (usually CTRL-C) during component typing will abort
+ _p_r_o_m_p_t_e_r and the _M_H command that invoked it. An
interrupt during
+ message-body typing is equivalent to CTRL-D, for historical rea-
+ sons. This means that _p_r_o_m_p_t_e_r should finish up and
exit.
+
+ The first non-flag argument to _p_r_o_m_p_t_e_r is taken as the
name of the
+ draft file, and subsequent non-flag arguments are ignored.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /tmp/prompter* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ prompter-next: To name the editor to be used on exit from
+ _p_r_o_m_p_t_e_r
+ Msg-Protect: To set mode when creating a new draft
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prepend'
+ `-norapid'
+ `-nodoteof'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ The `-rapid' option is particularly useful with _f_o_r_w,
and
+ `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+ The user may wish to link _p_r_o_m_p_t_e_r under several names
(e.g., "ra-
+ pid") and give appropriate switches in the profile entries under
+ these names (e.g., "rapid: -rapid"). This facilitates invoking
+ prompter differently for different _M_H commands (e.g., "forw: -edi-
+ tor rapid").
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -72- PROMPTER(1)
+
+
+ _B_u_g_s
+ _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will lose if
you edit files with
+ nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -73- RCVSTORE(1)
+
+
+ _N_A_M_E
+ rcvstore - incorporate new mail asynchronously
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_c_v_s_t_o_r_e incorporates a message from the standard input
into an _M_H
+ folder. If `+folder' isn't specified, the folder named "inbox" in
+ the user's _M_H directory will be used instead. The new message
+ being incorporated is assigned the next highest number in the
+ folder. If the specified (or default) folder doesn't exist, then
+ it will be created if the `-create' option is specified, otherwise
+ _r_c_v_s_t_o_r_e will exit.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it will
+ be used as the protection on the newly created messages, otherwise
+ the _M_H default of 0644 will be used. During all operations on mes-
+ sages, this initially assigned protection will be preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a protection
on an
+ individual message, and its protection will be preserved
+ thereafter.
+
+ _R_c_v_s_t_o_r_e will incorporate anything except zero length
messages into
+ the user's MH folder.
+
+ If the profile entry "Unseen-Sequence" is present and non-empty,
+ then _r_c_v_s_t_o_r_e will add the newly incorporated
message to each
+ sequence named by the profile entry. This is similar to the
+ "Previous-Sequence" profile entry supported by all _M_H commands
+ which take `msgs' or `msg' arguments. Note that
_r_c_v_s_t_o_r_e will not
+ zero each sequence prior to adding messages.
+
+ Furthermore, the incoming messages may be added to user-defined
+ sequences as they arrive by appropriate use of the `-sequence'
+ option. As with _p_i_c_k, use of the `-zero' and `-nozero'
switches
+ can also be used to zero old sequences or not. Similarly, use of
+ the `-public' and `-nopublic switches may be used to force addi-
+ tions to public and private sequences.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -74- RCVSTORE(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Folder-Protect: To set mode when creating a new folder
+ Msg-Protect: To set mode when creating a new message
+ Unseen-Sequence: To name sequences denoting unseen messages
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), mh-mail(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to "inbox"
+ `-create'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ No context changes will be attempted, with the exception of se-
+ quence manipulation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -75- REFILE(1)
+
+
+ _N_A_M_E
+ refile - file message in other folders
+
+ _S_Y_N_O_P_S_I_S
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+ [-src +folder] [-file file] [-rmmproc program] [-normmproc]
+ +folder ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_f_i_l_e moves (_m_v (1)) or links (_l_n (1)) messages
from a source
+ folder into one or more destination folders. If you think of a
+ message as a sheet of paper, this operation is not unlike filing
+ the sheet of paper (or copies) in file cabinet folders. When a
+ message is filed, it is linked into the destination folder(s) if
+ possible, and is copied otherwise. As long as the destination
+ folders are all on the same file system, multiple filing causes
+ little storage overhead. This facility provides a good way to
+ cross-file or multiply-index messages. For example, if a message
+ is received from Jones about the ARPA Map Project, the command
+
+ refile cur +jones +Map
+
+ would allow the message to be found in either of the two folders
+ `jones' or `Map'.
+
+ The option `-file file' directs _r_e_f_i_l_e to use the specified
file as
+ the source message to be filed, rather than a message from a
+ folder. Note that the file should be a validly formatted message,
+ just like any other _M_H message. It should NOT be in mail drop for-
+ mat (to convert a file in mail drop format to a folder of _M_H mes-
+ sages, see _i_n_c (1)).
+
+ If a destination folder doesn't exist, _r_e_f_i_l_e will ask if
you want
+ to create it. A negative response will abort the file operation.
+
+ The option `-link' preserves the source folder copy of the message
+ (i.e., it does a _l_n(1) rather than a _m_v(1)), whereas,
`-nolink'
+ deletes the filed messages from the source folder. Normally, when
+ a message is filed, it is assigned the next highest number avail-
+ able in each of the destination folders. Use of the `-preserve'
+ switch will override this message renaming, but name conflicts may
+ occur, so use this switch cautiously.
+
+ If `-link' is not specified (or `-nolink' is specified), the filed
+ messages will be removed from the source folder, by renaming them
+ with a site-dependent prefix (usually a comma).
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -76- REFILE(1)
+
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then _r_e_f_i_l_e will instead call the named program to delete
the mes-
+ sage files. The user may specify `-rmmproc program' on the command
+ line to override this profile specification. The `-normmproc'
+ option forces the message files to be deleted by renaming them as
+ described above.
+
+ The `-draft' switch tells _r_e_f_i_l_e to file the <mh-dir>/draft.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-src +folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-nolink'
+ `-nopreserve'
+
+
+ _C_o_n_t_e_x_t
+ If `-src +folder' is given, it will become the current folder. If
+ neither `-link' nor `all' is specified, the current message in the
+ source folder will be set to the last message specified; otherwise,
+ the current message won't be changed.
+
+ If the Previous-Sequence profile entry is set, in addition to de-
+ fining the named sequences from the source folder, _r_e_f_i_l_e
will also
+ define those sequences for the destination folders. See
+ _m_h-_p_r_o_f_i_l_e (1) for information concerning the
previous sequence.
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the
message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying `-normmproc', or
you will
+ create an infinte loop.
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REPL(1) -77- REPL(1)
+
+
+ _N_A_M_E
+ repl - reply to a message
+
+ _S_Y_N_O_P_S_I_S
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+ [-inplace] [-noinplace] [-query] [-noquery] [-width columns]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_p_l aids a user in producing a reply to an existing message.
_R_e_p_l
+ uses a reply template to guide its actions when constructing the
+ message draft of the reply. In its simplest form (with no argu-
+ ments), it will set up a message-form skeleton in reply to the
+ current message in the current folder, and invoke the whatnow
+ shell. The default reply template will direct _r_e_p_l to
construct
+ the composed message as follows:
+
+ To: <Reply-To> or <From>
+ cc: <cc>, <To>, and yourself
+ Subject: Re: <Subject>
+ In-reply-to: Your message of <Date>.
+ <Message-Id>
+
+ where field names enclosed in angle brackets (< >) indicate the
+ contents of the named field from the message to which the reply is
+ being made. A reply template is simply a format file. See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ The `-cc type' switch takes an argument which specifies who gets
+ placed on the "cc:" list of the reply. The `-query' switch modi-
+ fies the action of `-cc type' switch by interactively asking you if
+ each address that normally would be placed in the "To:" and "cc:"
+ list should actually be sent a copy. (This is useful for
+ special-purpose replies.) Note that the position of the `-cc' and
+ `-nocc' switches, like all other switches which take a positive and
+ negative form, is important.
+
+ Lines beginning with the fields "To:", "cc:", and "Bcc:" will be
+ standardized and have duplicate addresses removed. In addition,
+ the `-width columns' switch will guide _r_e_p_l's formatting of
these
+ fields.
+
+ If the file named "replcomps" exists in the user's MH directory, it
+ will be used instead of the default form. In either case, the file
+ specified by `-form formfile' will be used if given.
+
+ If the draft already exists, _r_e_p_l will ask you as to the
disposi-
+ tion of the draft. A reply of quit will abort _r_e_p_l, leaving
the
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REPL(1) -78- REPL(1)
+
+
+ draft intact; replace will replace the existing draft with a blank
+ skeleton; and list will display the draft.
+
+ See _c_o_m_p (1) for a description of the `-editor' and
`-noedit'
+ switches. Note that while in the editor, the message being replied
+ to is available through a link named "@" (assuming the default
+ _w_h_a_t_n_o_w_p_r_o_c ). In addition, the actual pathname
of the message is
+ stored in the envariable $editalt, and the pathname of the folder
+ containing the message is stored in the envariable $mhfolder.
+
+ Although _r_e_p_l uses the `-form formfile' switch to direct it how
to
+ construct the beginning of the draft, the `-filter filterfile'
+ switch directs _r_e_p_l as to how the message being replied-to
should
+ be formatted in the body of the draft. If `-filter' is not speci-
+ fied, then the message being replied-to is not included in the body
+ of the draft. If `-filter filterfile' is specified, then the mes-
+ sage being replied-to is filtered (re-formatted) prior to being
+ output to the body of the draft. The filter file for _r_e_p_l
should
+ be a standard form file for _m_h_l, as _r_e_p_l will invoke
_m_h_l to format
+ the message being replied-to. There is no default message filter
+ (`-filter' must be followed by a file name). A filter file that is
+ commonly used is:
+
+ :
+ body:nocomponent,compwidth=9,offset=9
+
+ which says to output a blank line and then the body of the message
+ being replied-to, indented by one tab-stop. Another format popular
+ on USENET is:
+
+ message-id:nocomponent,formatfield=\
+ "In message %{text}you write:"
+ body:component=">",overflowtext=">",overflowoffset=0
+
+ Which cites the Message-ID of the message being replied-to, and
+ then outputs each line of the body prefaced with the ">" character.
+
+ If the `-annotate' switch is given, the message being replied-to
+ will be annotated with the lines
+
+ Replied: date
+ Replied: addrs
+
+ where the address list contains one line for each addressee. The
+ annotation will be done only if the message is sent directly from
+ _r_e_p_l. If the message is not sent immediately from
_r_e_p_l,
+ "comp -use" may be used to re-edit and send the constructed mes-
+ sage, but the annotations won't take place. The `-inplace' switch
+ causes annotation to be done in place in order to preserve links to
+ the annotated message.
+
+ The `-fcc +folder' switch can be used to automatically specify a
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REPL(1) -79- REPL(1)
+
+
+ folder to receive Fcc:s. More than one folder, each preceeded by
+ `-fcc' can be named.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes,
_r_e_p_l also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _f_c_c string Any folders specified with `-fcc folder'
+
+ To avoid reiteration, _r_e_p_l strips any leading `Re: ' strings
from
+ the _s_u_b_j_e_c_t component.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _r_e_p_l will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available options.
The invoca-
+ tion of this program can be inhibited by using the `-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w program
which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/replcomps The reply template
+ or <mh-dir>/replcomps Rather than the standard template
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter message being replied-to
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ REPL(1) -80- REPL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-nocc all' at ATHENA sites, `-cc all' otherwise
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+ `-noquery'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The mes-
+ sage replied-to will become the current message.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-noformat' used to
+ cause address headers to be output as-is. Now all address fields
+ are formatted using Internet standard guidelines.
+
+
+ _B_u_g_s
+ If any addresses occur in the reply template, addresses in the tem-
+ plate that do not contain hosts are defaulted incorrectly. Instead
+ of using the localhost for the default, _r_e_p_l uses the
sender's
+ host. Moral of the story: if you're going to include addresses in
+ a reply template, include the host portion of the address.
+
+ The `-width columns' switch is only used to do address-folding;
+ other headers are not line-wrapped.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then
_r_e_p_l uses a built-in _w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program. Hence, if
you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _r_e_p_l won't run
+ it.
+
+ If your current working directory is not writable, the link named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RMF(1) -81- RMF(1)
+
+
+ _N_A_M_E
+ rmf - remove folder
+
+ _S_Y_N_O_P_S_I_S
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_f removes all of the messages (files) within the specified
(or
+ default) folder, and then removes the folder (directory) itself.
+ If there are any files within the folder which are not a part of
+ _M_H, they will _n_o_t be removed, and an error will be
produced. If
+ the folder is given explicitly or the `-nointeractive' option is
+ given, then the folder will be removed without confirmation. Oth-
+ erwise, the user will be asked for confirmation. If _r_m_f can't
find
+ the current folder, for some reason, the folder to be removed
+ defaults to `+inbox' with confirmation.
+
+ _R_m_f irreversibly deletes messages that don't have other links,
so
+ use it with caution.
+
+ If the folder being removed is a subfolder, the parent folder will
+ become the new current folder, and _r_m_f will produce a message
tel-
+ ling the user this has happened. This provides an easy mechanism
+ for selecting a set of messages, operating on the list, then remov-
+ ing the list and returning to the current folder from which the
+ list was extracted.
+
+ _R_m_f of a read-only folder will delete the private sequence and
cur
+ information (i.e., "atr-_s_e_q-_f_o_l_d_e_r" entries) from
the profile
+ without affecting the folder itself.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ rmm(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder, usually with confirmation
+ `-interactive' if +folder' not given, `-nointeractive' otherwise
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RMF(1) -82- RMF(1)
+
+
+ _C_o_n_t_e_x_t
+ _R_m_f will set the current folder to the parent folder if a
subfolder
+ is removed; or if the current folder is removed, it will make "in-
+ box" current. Otherwise, it doesn't change the current folder or
+ message.
+
+
+ _B_u_g_s
+ Although intuitively one would suspect that _r_m_f works
recursively,
+ it does not. Hence if you have a sub-folder within a folder, in
+ order to _r_m_f the parent, you must first _r_m_f each of the
children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RMM(1) -83- RMM(1)
+
+
+ _N_A_M_E
+ rmm - remove messages
+
+ _S_Y_N_O_P_S_I_S
+ rmm [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_m removes the specified messages by renaming the message
files
+ with preceding commas. Many sites consider files that start with a
+ comma to be a temporary backup, and arrange for _c_r_o_n (8) to
remove
+ such files once a day.
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then instead of simply renaming the message file, _r_m_m will call
the
+ named program to delete the file. Note that at most installations,
+ _c_r_o_n (8) is told to remove files that begin with a comma
once a
+ night.
+
+ Some users of csh prefer the following:
+
+ alias rmm 'refile +d'
+
+ where folder +d is a folder for deleted messages, and
+
+ alias mexp 'rm `mhpath +d all`'
+
+ is used to "expunge" deleted messages.
+
+ The current message is not changed by _r_m_m, so a _n_e_x_t
will advance
+ to the next message in the folder as expected.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ rmf(1)
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ RMM(1) -84- RMM(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ If you're not a csh user, and you have an _r_m_m_p_r_o_c
script which
+ _r_e_f_i_l_es messages, be sure you use something like:
+
+ mv `mhpath msgs` `mhpath new +folder`
+
+ Other work-arounds are possible, such as:
+
+ cd `mhpath +`
+ MH=/dev/null MHCONTEXT=/dev/null refile $* +folder
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to delete the
message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying `-normmproc', or
you will
+ create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -85- SCAN(1)
+
+
+ _N_A_M_E
+ scan - produce a one line per message scan listing
+
+ _S_Y_N_O_P_S_I_S
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_c_a_n produces a one-line-per-message listing of the specified
mes-
+ sages. Each _s_c_a_n line contains the message number (name),
the
+ date, the "From:" field, the "Subject" field, and, if room allows,
+ some of the body of the message. For example:
+
+ 15+ 7/ 5 Dcrocker nned <<Last week I asked some of
+ 16 - 7/ 5 dcrocker message id format <<I recommend
+ 18 7/ 6 Obrien Re: Exit status from mkdir
+ 19 7/ 7 Obrien "scan" listing format in MH
+
+ The `+' on message 15 indicates that it is the current message.
+ The `-' on message 16 indicates that it has been replied to, as
+ indicated by a "Replied:" component produced by an `-annotate'
+ switch to the _r_e_p_l command.
+
+ If there is sufficient room left on the _s_c_a_n line after the
sub-
+ ject, the line will be filled with text from the body, preceded by
+ <<, and terminated by >> if the body is sufficiently short.
_S_c_a_n
+ actually reads each of the specified messages and parses them to
+ extract the desired fields. During parsing, appropriate error mes-
+ sages will be produced if there are format errors in any of the
+ messages.
+
+ The `-header' switch produces a header line prior to the _s_c_a_n
list-
+ ing. Currently, the name of the folder and the current date and
+ time are output (see the HISTORY section for more information).
+
+ If the `-clear' switch is used and _s_c_a_n'_s output is directed
to a
+ terminal, then _s_c_a_n will consult the $TERM and $TERMCAP
envariables
+ to determine your terminal type in order to find out how to clear
+ the screen prior to exiting. If the `-clear' switch is used and
+ _s_c_a_n'_s output is not directed to a terminal (e.g., a pipe
or a
+ file), then _s_c_a_n will send a formfeed prior to exiting.
+
+ For example, the command:
+
+ (scan -clear -header; show all -show pr -f) | lpr
+
+ produces a scan listing of the current folder, followed by a
+ formfeed, followed by a formatted listing of all messages in the
+ folder, one per page. Omitting `-show pr -f' will cause the mes-
+ sages to be concatenated, separated by a one-line header and two
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -86- SCAN(1)
+
+
+ blank lines.
+
+ If _s_c_a_n encounters a message without a "Date:" field, rather
than
+ leaving that portion of the scan listing blank, the date is
+ filled-in with the last write date of the message, and post-fixed
+ with a `*'. This is particularly handy for scanning a
_d_r_a_f_t
+ _f_o_l_d_e_r, as message drafts usually aren't allowed to have
dates in
+ them.
+
+ To override the output format used by _s_c_a_n, the `-format
string' or
+ `-format file' switches are used. This permits individual fields
+ of the scan listing to be extracted with ease. The string is sim-
+ ply a format string and the file is simply a format file. See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5) escapes,
_s_c_a_n also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ body string the (compressed) first part of the body
+
+ Also, if no date header was present in the message, the
_f_u_n_c_t_i_o_n
+ escapes which operate on {_d_a_t_e} will return values for the
date of
+ last modification of the message file itself.
+
+
+ _s_c_a_n will update the _M_H context prior to starting the
listing, so
+ interrupting a long _s_c_a_n listing preserves the new context.
_M_H
+ purists hate this idea.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), show(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the folder current
+ `msgs' defaults to all
+ `-format' defaulted as described above
+ `-noheader'
+ `-width' defaulted to the width of the terminal
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -87- SCAN(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-header' used to gen-
+ erate a heading saying what each column in the listing was. Format
+ strings prevent this from happening.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a sin-
+ gle token by the shell that invokes _s_c_a_n. Therefore, one must
usu-
+ ally place the argument to this switch inside double-quotes.
+ The value of each _c_o_m_p_o_n_e_n_t escape is set by
_s_c_a_n to the contents
+ of the first message header _s_c_a_n encounters with the
corresponding
+ component name; any following headers with the same component name
+ are ignored.
+
+ The switch `-reverse', makes _s_c_a_n list the messages in reverse
ord-
+ er; this should be considered a bug.
+
+ The `-file filename' switch allows the user to obtain a _s_c_a_n
list-
+ ing of a maildrop file as produced by _p_a_c_k_f. This listing
includes
+ every message in the file. The user should use _m_s_h for more
selec-
+ tive processing of the file. `-reverse' is ignored with this op-
+ tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SEND(1) -88- SEND(1)
+
+
+ _N_A_M_E
+ send - send a message
+
+ _S_Y_N_O_P_S_I_S
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+ [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_e_n_d will cause each of the specified files to be delivered
(via
+ _p_o_s_t (8)) to each of the destinations in the "To:", "cc:",
"Bcc:",
+ and "Fcc:" fields of the message. If _s_e_n_d is
re-distributing a
+ message, as invoked from _d_i_s_t, then the corresponding
"Resent-xxx"
+ fields are examined instead.
+
+ If `-push' is specified, _s_e_n_d will detach itself from the
user's
+ terminal and perform its actions in the background. If _p_u_s_h 'd
and
+ the draft can't be sent, then the `-forward' switch says that draft
+ should be forwarded with the failure notice sent to the user. This
+ differs from putting _s_e_n_d in the background because the output
is
+ trapped and analyzed by _M_H.
+
+ If `-verbose' is specified, _s_e_n_d will indicate the
interactions
+ occurring with the transport system, prior to actual delivery. If
+ `-watch' is specified _s_e_n_d will monitor the delivery of local
and
+ network mail. Hence, by specifying both switches, a large detail
+ of information can be gathered about each step of the message's
+ entry into the transport system.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ _S_e_n_d with no _f_i_l_e argument will query whether the
draft is the
+ intended file, whereas `-draft' will suppress this question. Once
+ the transport system has successfully accepted custody of the mes-
+ sage, the file will be renamed with a leading comma, which allows
+ it to be retrieved until the next draft message is sent. If there
+ are errors in the formatting of the message, _s_e_n_d will abort
with a
+ (hopefully) helpful error message.
+
+ If a "Bcc:" field is encountered, its addresses will be used for
+ delivery, and the "Bcc:" field will be removed from the message
+ sent to sighted recipients. The blind recipients will receive an
+ entirely new message with a minimal set of headers. Included in
+ the body of the message will be a copy of the message sent to the
+ sighted recipients. If `-filter filterfile' is specified, then
+ this copy is filtered (re-formatted) prior to being sent to the
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SEND(1) -89- SEND(1)
+
+
+ blind recipients.
+
+ Prior to sending the message, the fields "From: address@hidden", and
+ "Date: now" will be appended to the headers in the message. If the
+ envariable $SIGNATURE is set, then its value is used as your per-
+ sonal name when constructing the "From:" line of the message. If
+ this envariable is not set, then _s_e_n_d will consult the
profile
+ entry "Signature" for this information. On hosts where _M_H was con-
+ figured with the UCI option, if $SIGNATURE is not set and the "Sig-
+ nature" profile entry is not present, then the file
+ $HOME/.signature is consulted. If `-msgid' is specified, then a
+ "Message-ID:" field will also be added to the message.
+
+ If _s_e_n_d is re-distributing a message (when invoked by
_d_i_s_t ), then
+ "Resent-" will be prepended to each of these fields: "From:",
+ "Date:", and "Message-ID:". If the message already contains a
+ "From:" field, then a "Sender: address@hidden" field will be added as
+ well. (An already existing "Sender:" field is an error!)
+
+ By using the `-format' switch, each of the entries in the "To:" and
+ "cc:" fields will be replaced with "standard" format entries. This
+ standard format is designed to be usable by all of the message
+ handlers on the various systems around the Internet. If `-nofor-
+ mat' is given, then headers are output exactly as they appear in
+ the message draft.
+
+ If an "Fcc: folder" is encountered, the message will be copied to
+ the specified folder for the sender in the format in which it will
+ appear to any non-Bcc receivers of the message. That is, it will
+ have the appended fields and field reformatting. The "Fcc:" fields
+ will be removed from all outgoing copies of the message.
+
+ By using the `-width columns' switch, the user can direct _s_e_n_d
as
+ to how long it should make header lines containing addresses.
+
+ The file specified by the profile entry "Aliasfile:" and any addi-
+ tional alias files given by the `-alias aliasfile' switch will be
+ read (more than one file, each preceeded by `-alias', can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ Signature: To determine the user's mail signature
+ mailproc: Program to post failure notices
+ postproc: Program to post the message
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SEND(1) -90- SEND(1)
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-nodraftfolder'
+ `-nofilter'
+ `-format'
+ `-forward'
+ `-nomsgid'
+ `-nopush'
+ `-noverbose'
+ `-nowatch'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -91- SHOW(1)
+
+
+ _N_A_M_E
+ show - show (list) messages
+
+ _S_Y_N_O_P_S_I_S
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_h_o_w lists each of the specified messages to the standard
output
+ (typically, the terminal). Typically, the messages are listed
+ exactly as they are, with no reformatting. A program named by the
+ _s_h_o_w_p_r_o_c profile component is invoked to do the
listing, and any
+ switches not recognized by _s_h_o_w are passed along to that
program.
+ The default program is known as _m_o_r_e (1). To override the
default
+ and the _s_h_o_w_p_r_o_c profile component, use the
`-showproc program'
+ switch. For example, `-show pr' will cause the _p_r (1) program to
+ list the messages. The _M_H command _m_h_l can be used as a
_s_h_o_w_p_r_o_c to
+ show messages in a more uniform format. Normally, this program is
+ specified as the _s_h_o_w_p_r_o_c is the user's .mh_profile.
See _m_h_l (1)
+ for the details. If the `-noshowproc' option is specified,
+ `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+ The `-header' switch tells _s_h_o_w to display a one-line
description
+ of the message being shown. This description includes the folder
+ and the message number.
+
+ If no `msgs' are specified, the current message is used. If more
+ than one message is specified, _m_o_r_e will prompt for a
<RETURN>
+ prior to listing each message. _m_o_r_e will list each message, a
page
+ at a time. When the end of page is reached, _m_o_r_e will ring
the
+ bell and wait for a <SPACE> or <RETURN>. If a <RETURN> is entered,
+ _m_o_r_e will print the next line, whereas <SPACE> will print the
next
+ screenful. To exit _m_o_r_e, type "q".
+
+ If the standard output is not a terminal, no queries are made, and
+ each file is listed with a one-line header and two lines of separa-
+ tion.
+
+ "show -draft" will list the file <mh-dir>/draft if it exists.
+
+ If the profile entry "Unseen-Sequence" is present and non-empty,
+ then _s_h_o_w will remove each of the messages shown from each
sequence
+ named by the profile entry. This is similar to the
+ "Previous-Sequence" profile entry supported by all _M_H commands
+ which take `msgs' or `msg' arguments.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -92- SHOW(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Unseen-Sequence: To name sequences denoting unseen messages
+ showproc: Program to show messages
+
+
+ _S_e_e _A_l_s_o
+ mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The last
+ message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -93- SHOW(1)
+
+
+ _B_u_g_s
+ The `-header' switch doesn't work when `msgs' expands to more than
+ one message. If the _s_h_o_w_p_r_o_c is _m_h_l, then is
problem can be cir-
+ cumvented by referencing the "messagename" field in the _m_h_l
format
+ file.
+
+ _S_h_o_w updates the user's context before showing the message.
Hence
+ _s_h_o_w will mark messages as seen prior to the user actually
seeing
+ them. This is generally not a problem, unless the user relies on
+ the "unseen" messages mechanism, and interrupts _s_h_o_w while
it is
+ showing "unseen" messages.
+
+ If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w uses a
built-in _m_h_l: it does not ac-
+ tually run the _m_h_l program. Hence, if you define your
own
+ _s_h_o_w_p_r_o_c, don't call it _m_h_l since _s_h_o_w
won't run it.
+
+ If _m_o_r_e (1) is your showproc (the default), then avoid running
_s_h_o_w
+ in the background with only its standard output piped to another
+ process, as in
+
+ show | imprint &
+
+ Due to a bug in _m_o_r_e, show will go into a "tty input" state.
To
+ avoid this problem, re-direct _s_h_o_w's diagnostic output as
well.
+ For users of _c_s_h:
+
+ show |& imprint &
+
+ For users of _s_h:
+
+ show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -94- SORTM(1)
+
+
+ _N_A_M_E
+ sortm - sort messages
+
+ _S_Y_N_O_P_S_I_S
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_o_r_t_m sorts the specified messages in the named folder
according to
+ the chronological order of the "Date:" field of each message.
+
+ The `-verbose' switch directs _s_o_r_t_m to tell the user the
general
+ actions that it is taking to place the folder in sorted order.
+
+ The `-datefield field' switch tells _s_o_r_t_m the name of the
field to
+ use when making the date comparison. If the user has a special
+ field in each message, such as "BB-Posted:" or "Delivery-Date:",
+ then the `-datefield' switch can be used to direct _s_o_r_t_m
which
+ field to examine.
+
+ The `-textfield field' switch causes _s_o_r_t_m to sort messages
by the
+ specified text field. If this field is "subject", any leading
+ "re:" is stripped off. In any case, all characters except letters
+ and numbers are stripped and the resulting strings are sorted
+ datefield-major, textfield-minor, using a case insensitive com-
+ parison.
+
+ With `-textfield field', if `-limit days' is specified, messages
+ with similar textfields that are dated within `days' of each other
+ appear together. Specifying `-nolimit' makes the limit infinity.
+ With `-limit 0', the sort is instead made textfield-major,
+ date-minor.
+
+ For example, to order a folder by date-major, subject-minor, use:
+
+ sortm -textfield subject +folder
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder (1)
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -95- SORTM(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-notextfield'
+ `-noverbose'
+ `-nolimit'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. If the
+ current message is moved, _s_o_r_t_m will preserve its
status as
+ current.
+
+
+ _H_i_s_t_o_r_y
+ Timezones used to be ignored when comparing dates: they aren't any
+ more.
+
+ Messages which were in the folder, but not specified by `msgs',
+ used to be moved to the end of the folder; now such messages are
+ left untouched.
+
+ Previously, _s_o_r_t_m would try to fill any gaps in a folder
within the
+ range of messages it sorted. To improve performance,
_s_o_r_t_m now
+ minimizes the number of message moves. To pack a folder, use
+ "_f_o_l_d_e_r -_p_a_c_k" instead.
+
+
+ _B_u_g_s
+ If _s_o_r_t_m encounters a message without a date-field, or if the
mes-
+ sage has a date-field that _s_o_r_t_m cannot parse, then
_s_o_r_t_m attempts
+ to keep the message in the same relative position. This does not
+ always work. For instance, if the first message encountered lacks
+ a date which can be parsed, then it will usually be placed at the
+ end of the messages being sorted.
+
+ When _s_o_r_t_m complains about a message which it can't
temporally ord-
+ er, it complains about the message number _p_r_i_o_r to
sorting. It
+ should indicate what the message number will be _a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ VMH(1) -96- VMH(1)
+
+
+ _N_A_M_E
+ vmh - visual front-end to MH
+
+ _S_Y_N_O_P_S_I_S
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _v_m_h is a program which implements the server side of the _M_H
window
+ management protocol and uses _c_u_r_s_e_s (3) routines to
maintain a
+ split-screen interface to any program which implements the client
+ side of the protocol. This latter program, called the
_v_m_h_p_r_o_c, is
+ specified using the `-vmhproc program' switch.
+
+ The upshot of all this is that one can run _m_s_h on a display
termi-
+ nal and get a nice visual interface. To do this, for example, just
+ add the line
+
+ mshproc: vmh
+
+ to your .mh_profile. (This takes advantage of the fact that _m_s_h
is
+ the default _v_m_h_p_r_o_c for _v_m_h.)
+
+ In order to facilitate things, if the `-novmhproc' switch is given,
+ and _v_m_h can't run on the user's terminal, the
_v_m_h_p_r_o_c is run
+ directly without the window management protocol.
+
+ After initializing the protocol, _v_m_h prompts the user for a
command
+ to be given to the client. Usually, this results in output being
+ sent to one or more windows. If a output to a window would cause
+ it to scroll, _v_m_h prompts the user for instructions, roughly
per-
+ mitting the capabilities of _l_e_s_s or _m_o_r_e (e.g., the
ability to
+ scroll backwards and forwards):
+
+ SPACE advance to the next windowful
+ RETURN * advance to the next line
+ y * retreat to the previous line
+ d * advance to the next ten lines
+ u * retreat to the previous ten lines
+ g * go to an arbitrary line
+ (preceed g with the line number)
+ G * go to the end of the window
+ (if a line number is given, this acts like `g')
+ CTRL-L refresh the entire screen
+ h print a help message
+ q abort the window
+
+ (A `*' indicates that a numeric prefix is meaningful for this com-
+ mand.)
+
+ Note that if a command resulted in more than one window's worth of
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ VMH(1) -97- VMH(1)
+
+
+ information being displayed, and you allow the command which is
+ generating information for the window to gracefully finish (i.e.,
+ you don't use the `q' command to abort information being sent to
+ the window), then _v_m_h will give you one last change to peruse
the
+ window. This is useful for scrolling back and forth. Just type
+ `q' when you're done.
+
+ To abnormally terminate _v_m_h (without core dump), use <QUIT>
(usu-
+ ally CTRL-\). For instance, this does the "right" thing with
_b_b_c
+ and _m_s_h.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+
+
+ _S_e_e _A_l_s_o
+ msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt (vmh) '
+ `-vmhproc msh'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a sin-
+ gle token by the shell that invokes _v_m_h. Therefore, one must
usu-
+ ally place the argument to this switch inside double-quotes.
+
+ At present, there is no way to pass signals (e.g., interrupt, quit)
+ to the client. However, generating QUIT when _v_m_h is reading a
com-
+ mand from the terminal is sufficient to tell the client to go away
+ quickly.
+
+ Acts strangely (loses peer or botches window management protocol
+ with peer) on random occasions.
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -98- WHATNOW(1)
+
+
+ _N_A_M_E
+ whatnow - prompting front-end for send
+
+ _S_Y_N_O_P_S_I_S
+ whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_a_t_n_o_w is the default program that queries the user
about the
+ disposition of a composed draft. It is normally invoked by one of
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l after the
initial edit.
+
+ When started, the editor is started on the draft (unless `-noedit'
+ is given, in which case the initial edit is suppressed). Then,
+ _w_h_a_t_n_o_w repetitively prompts the user with "What now?"
and awaits a
+ response. The valid responses are:
+
+ display to list the message being distributed/replied-to on
+ the terminal
+ edit to re-edit using the same editor that was used on the
+ preceding round unless a profile entry
+ "<lasteditor>-next: <editor>" names an alternate editor
+ edit <editor> to invoke <editor> for further editing
+ list to list the draft on the terminal
+ push to send the message in the background
+ quit to terminate the session and preserve the draft
+ quit -delete to terminate, then delete the draft
+ refile +folder to refile the draft into the given folder
+ send to send the message
+ send -watch to cause the delivery process to be monitored
+ whom to list the addresses that the message will go to
+ whom -check to list the addresses and verify that they are
+ acceptable to the transport service
+
+ For the edit response, any valid switch to the editor is valid.
+ Similarly, for the send and whom responses, any valid switch to
+ _s_e_n_d (1) and _w_h_o_m (1) commands, respectively, are
valid. For the
+ push response, any valid switch to _s_e_n_d (1) is valid (as
this
+ merely invokes _s_e_n_d with the `-push' option). For the
_r_e_f_i_l_e
+ response, any valid switch to the _f_i_l_e_p_r_o_c is
valid. For the
+ display and list responses, any valid argument to the
_l_p_r_o_c is
+ valid. If any non-switch arguments are present, then the pathname
+ of the draft will be excluded from the argument list given to the
+ _l_p_r_o_c (this is useful for listing another _M_H message).
+
+ See _m_h-_p_r_o_f_i_l_e (5) for further information about how
editors are
+ used by MH. It also discusses how complex envariables can be used
+ to direct _w_h_a_t_n_o_w's actions.
+
+ The `-prompt string' switch sets the prompting string for
_w_h_a_t_n_o_w.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -99- WHATNOW(1)
+
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ <lasteditor>-next: To name an editor to be used after exit from
+ <lasteditor>
+ fileproc: Program to refile the message
+ lproc: Program to list the contents of a message
+ sendproc: Program to use to send the message
+ whomproc: Program to determine who a message would go to
+
+
+ _S_e_e _A_l_s_o
+ send(1), whom(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt "What Now? "'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a sin-
+ gle token by the shell that invokes _w_h_a_t_n_o_w.
Therefore, one must
+ usually place the argument to this switch inside double-quotes.
+
+ If the initial edit fails, _w_h_a_t_n_o_w deletes your draft (by
renaming
+ it with a leading comma); failure of a later edit preverves the
+ draft.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is _w_h_a_t_n_o_w, then
_c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l use a
+ built-in _w_h_a_t_n_o_w, and do not actually run the
_w_h_a_t_n_o_w program.
+ Hence, if you define your own _w_h_a_t_n_o_w_p_r_o_c, don't
call it _w_h_a_t_n_o_w
+ since it won't be run.
+
+ If _s_e_n_d_p_r_o_c is _s_e_n_d, then _w_h_a_t_n_o_w
uses a built-in _s_e_n_d, it does not
+ actually run the _s_e_n_d program. Hence, if you define your
own
+ _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since
_w_h_a_t_n_o_w won't run it.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -100- WHATNOW(1)
+
+
+ _N_A_M_E
+ whom - report to whom a message would go
+
+ _S_Y_N_O_P_S_I_S
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [file] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_o_m is used to expand the headers of a message into a set
of
+ addresses and optionally verify that those addresses are deliver-
+ able at that time (if `-check' is given).
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches invoke
+ the _M_H draft folder facility. This is an advanced (and highly use-
+ ful) feature. Consult the Advanced Features section of the _M_H
+ manual for more information.
+
+ The file specified by the profile entry "Aliasfile:" and any addi-
+ tional alias files given by the `-alias aliasfile' switch will be
+ read (more than one file, each preceeded by `-alias', can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ postproc: Program to post the message
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-nocheck'
+ `-alias /usr/local/lib/mh/MailAliases'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ WHOM(1) -101- WHOM(1)
+
+
+ _B_u_g_s
+ With the `-check' option, _w_h_o_m makes no guarantees that the
ad-
+ dresses listed as being ok are really deliverable, rather, an ad-
+ dress being listed as ok means that at the time that _w_h_o_m was
run
+ the address was thought to be deliverable by the transport service.
+ For local addresses, this is absolute; for network addresses, it
+ means that the host is known; for uucp addresses, it (often) means
+ that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+ -102-
+
+
+ _M_O_R_E _D_E_T_A_I_L_S
+
+ This section describes some of the more intense points of the
_M_H
+ system, by expanding on topics previously discussed. The format
+ presented conforms to the standard form for the description of UNIX
+ documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -103- MH-ALIAS(5)
+
+
+ _N_A_M_E
+ mh-alias - alias file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This describes both _M_H personal alias files and the (primary) alias
+ file for mail delivery, the file
+
+ /usr/local/lib/mh/MailAliases
+
+ It does not describe aliases files used by the message transport
+ system. Each line of the alias file has the format:
+
+ alias : address-group
+ or
+ alias ; address-group
+ or
+ < alias-file
+ or
+ ; comment
+
+ where:
+
+ address-group := address-list
+ | "<" file
+ | "=" UNIX-group
+ | "+" UNIX-group
+ | "*"
+
+ address-list := address
+ | address-list, address
+
+ Continuation lines in alias files end with `\' followed by the new-
+ line character.
+
+ Alias-file and file are UNIX file names. UNIX-group is a group
+ name (or number) from /_e_t_c/_g_r_o_u_p. An address is
a "simple"
+ Internet-style address. Througout this file, case is ignored,
+ except for alias-file names.
+
+ If the line starts with a `<', then the file named after the `<' is
+ read for more alias definitions. The reading is done recursively,
+ so a `<' may occur in the beginning of an alias file with the
+ expected results.
+
+ If the address-group starts with a `<', then the file named after
+ the `<' is read and its contents are added to the address-list for
+ the alias.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -104- MH-ALIAS(5)
+
+
+ If the address-group starts with an `=', then the file
/_e_t_c/_g_r_o_u_p
+ is consulted for the UNIX-group named after the `='. Each login
+ name occurring as a member of the group is added to the
+ address-list for the alias.
+
+ In contrast, if the address-group starts with a `+', then the file
+ /_e_t_c/_g_r_o_u_p is consulted to determine the group-id of
the UNIX-group
+ named after the `+'. Each login name occurring in the
/_e_t_c/_p_a_s_s_w_d
+ file whose group-id is indicated by this group is added to the
+ address-list for the alias.
+
+ If the address-group is simply `*', then the file
/_e_t_c/_p_a_s_s_w_d is
+ consulted and all login names with a userid greater than some magic
+ number (usually 200) are added to the address-list for the alias.
+
+ In match, a trailing * on an alias will match just about anything
+ appropriate. (See example below.)
+
+ An approximation of the way aliases are resolved at posting time is
+ (it's not really done this way):
+
+ 1) Build a list of all addresses from the message to be
+ delivered, eliminating duplicate addresses.
+
+ 2) If this draft originated on the local host, then for those
+ addresses in the message that have no host specified, perform
+ alias resolution.
+
+ 3) For each line in the alias file, compare "alias" against
+ all of the existing addresses. If a match, remove the matched
+ "alias" from the address list, and add each new address in the
+ address-group to the address list if it is not already on the
+ list. The alias itself is not usually output, rather the
+ address-group that the alias maps to is output instead. If
+ "alias" is terminated with a `;' instead of a `:', then both
+ the "alias" and the address are output in the correct format.
+ (This makes replies possible since _M_H aliases and personal
+ aliases are unknown to the mail transport system.)
+
+ Since the alias file is read line by line, forward references work,
+ but backward references are not recognized, thus, there is no
+ recursion.
+
+ Example:
+ </usr/local/lib/mh/BBoardAliases
+ sgroup: fred, fear, freida
+ fred: address@hidden
+ UNIX-committee: <unix.aliases
+ staff: =staff
+ wheels: +wheel
+ everyone: *
+ news.*: news
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -105- MH-ALIAS(5)
+
+
+ The first line says that more aliases should immediately be read
+ from the file
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_B_B_o_a_r_d_A_l_i_a_s_e_s.
Following this,
+ "fred" is defined as an alias for "address@hidden", and "sgroup" is
+ defined as an alias for the three names "address@hidden", "fear", and
+ "freida". Next, the definition of "UNIX-committee" is given by
+ reading the file _u_n_i_x._a_l_i_a_s_e_s in the users _M_H
directory, "staff" is
+ defined as all users who are listed as members of the group "staff"
+ in the /_e_t_c/_g_r_o_u_p file, and "wheels" is defined as all
users whose
+ group-id in /_e_t_c/_p_a_s_s_w_d is equivalent to the
"wheel" group.
+ Finally, "everyone" is defined as all users with a user-id in
+ /_e_t_c/_p_a_s_s_w_d greater than 200, and all aliases
of the form
+ "news.<anything>" are defined to be "news".
+
+ The key thing to understand about aliasing in _M_H is that aliases in
+ _M_H alias files are expanded into the headers of messages posted.
+ This aliasing occurs first, at posting time, without the knowledge
+ of the message transport system. In contrast, once the message
+ transport system is given a message to deliver to a list of
+ addresses, for each address that appears to be local, a system-wide
+ alias file is consulted. These aliases are NOT expanded into the
+ headers of messages delivered.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ To use aliasing in _M_H quickly, do the following:
+
+ First, in your ._m_h__p_r_o_f_i_l_e, choose a name for
your primary
+ alias file, say "aliases", and add the line:
+
+ Aliasfile: aliases
+
+ Second, create the file "aliases" in your _M_H directory.
+
+ Third, start adding aliases to your "aliases" file as
+ appropriate.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ ali(1), send(1), whom(1), group(5), passwd(5), conflict(8), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -106- MH-ALIAS(5)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ In previous releases of _M_H, only a single, system-wide mh-alias
+ file was supported. Now that _M_H uses _M_M_D_F as a transport
system,
+ the system-wide aliasing facility can be more consistently con-
+ trolled by the latter. This means that at most sites, the
+ system-wide mh-alias file will be empty (or trivial at best).
+ Hence, the semantics of mh-alias were extended to support personal
+ alias files. Users of _M_H no longer need to bother mail-system ad-
+ ministrators for keeping information in the system-wide alias file,
+ as each _M_H user can create/modify/remove aliases at will from any
+ number of personal files.
+
+
+ _B_u_g_s
+ Although the forward-referencing semantics of
_m_h-_a_l_i_a_s files
+ prevent recursion, the "< alias-file" command may defeat this.
+ Since the number of file descriptors is finite (and very limited),
+ such infinite recursion will terminate with a meaningless diagnos-
+ tic when all the fds are used up.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -107- MH-FORMAT(5)
+
+
+ _N_A_M_E
+ mh-format - format file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ some _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Several _M_H commands utilize either a _f_o_r_m_a_t string or a
_f_o_r_m_a_t file
+ during their execution. For example, _s_c_a_n (1) uses a format
string
+ which directs it how to generate the scan listing for each message;
+ _r_e_p_l (1) uses a format file which directs it how to generate
the
+ reply to a message, and so on.
+
+ Format strings are designed to be efficiently parsed by _M_H which
+ means they are not necessarily simple to write and understand.
+ This means that novice, casual, or even advanced users of _M_H should
+ not have to deal with them. Some canned scan listing formats are
+ in /usr/local/lib/mh/scan.time, /usr/local/lib/mh/scan.size, and
+ /usr/local/lib/mh/scan.timely. Look in /usr/local/lib/mh for other
+ _s_c_a_n and _r_e_p_l format files which may have been
written at your
+ site.
+
+ It suffices to have your local _M_H expert actually write new format
+ commands or modify existing ones. This manual section explains how
+ to do that. Note: familiarity with the C _p_r_i_n_t_f
routine is
+ assumed.
+
+ A format string consists of ordinary text, and special multi-
+ character _e_s_c_a_p_e sequences which begin with `%'. When
specifying a
+ format string, the usual C backslash characters are honored: `\b',
+ `\f', `\n', `\r', and `\t'. Continuation lines in format files end
+ with `\' followed by the newline character. There are three types
+ of _e_s_c_a_p_e sequences: header
_c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and,
+ flow _c_o_n_t_r_o_l.
+
+ A _c_o_m_p_o_n_e_n_t escape is specified as
`%{_c_o_m_p_o_n_e_n_t}', and exists for
+ each header found in the message being processed. For example
+ `%{date}' refers to the "Date:" field of the appropriate message.
+ All component escapes have a string value. Normally, component
+ values are compressed by converting any control characters (tab and
+ newline included) to spaces, then eliding any leading or multiple
+ spaces. However, commands may give different interpretations to
+ some component escapes; be sure to refer to each command's manual
+ entry for complete details.
+
+ A _f_u_n_c_t_i_o_n escape is specified as
`%(_f_u_n_c_t_i_o_n)'. All functions are
+ built-in, and most have a string or numeric value.
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -108- MH-FORMAT(5)
+
+
+ _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+ A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|', or `%>'.
These are
+ combined into the conditional execution construct:
+
+ %<condition
+ _f_o_r_m_a_t _t_e_x_t _1
+ %?condition2
+ _f_o_r_m_a_t _t_e_x_t _2
+ %?condition3
+ _f_o_r_m_a_t _t_e_x_t _3
+ ...
+ %|
+ _f_o_r_m_a_t _t_e_x_t _N
+ %>
+
+ Extra white space is shown here only for clarity. These constructs
+ may be nested without ambiguity. They form a general
+ if-elseif-else-endif block where only one of the _f_o_r_m_a_t
_t_e_x_t seg-
+ ments is interpreted.
+
+ The `%<' and `%?' control escapes causes a condition to be
+ evaluated. This condition may be either a _c_o_m_p_o_n_e_n_t
or a _f_u_n_c_t_i_o_n.
+ The four constructs have the following syntax:
+
+ %<{component}
+ %<(function)
+ %?{component}
+ %?(function)
+
+ These control escapes test whether the function or component value
+ is non-zero (for integer-valued escapes), or non-empty (for
+ string-valued escapes).
+
+ If this test evaulates true, then the format text up to the next
+ corresponding control escape (one of `%|', `%?', or `%>') is inter-
+ preted normally. Next, all format text up to the corresponding
+ `%>' control escape (if any) is skipped. The `%>' control escape
+ is not interpreted; normal interpretation resumes after the `%>'
+ escape.
+
+ If the test evaluates false, however, then the format text up to
+ the next corresponding control escape (again, one of `%|', `%?', or
+ `%>') is skipped, instead of being interpreted. If the control
+ escape encountered was `%?', then the condition associated with
+ that control escape is evaluated, and interpretation proceeds after
+ that test as described in the previous paragraph. If the control
+ escape encountered was `%|', then the format text up to the
+ corresponding `%>' escape is interpreted normally. As above, the
+ `%>' escape is not interpreted and normal interpretation resumes
+ after the `%>' escape.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -109- MH-FORMAT(5)
+
+
+ The `%?' control escape and its following format text is optional,
+ and may be included zero or more times. The `%|' control escape
+ and its following format text is also optional, and may be included
+ zero or one times.
+
+
+ _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+ Most functions expect an argument of a particular type:
+
+ _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n
_E_x_a_m_p_l_e _S_y_n_t_a_x
+ literal A literal number, %(_f_u_n_c 1234)
+ or string %(_f_u_n_c text string)
+ comp Any header component
%(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+ date A date component %(_f_u_n_c{_d_a_t_e})
+ addr An address component %(_f_u_n_c{_f_r_o_m})
+ expr An optional component, %(_f_u_n_c(_f_u_n_c_2))
+ function or control, %(_f_u_n_c
%<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+ perhaps nested
%(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+ The types _d_a_t_e and _a_d_d_r have the same syntax as
_c_o_m_p, but require
+ that the header component be a date string, or address string,
+ respectively.
+
+ All arguments except those of type _e_x_p_r are required. For the
_e_x_p_r
+ argument type, the leading `%' must be omitted for component and
+ function escape arguments, and must be present (with a leading
+ space) for control escape arguments.
+
+ The evaluation of format strings is based on a simple machine with
+ an integer register _n_u_m, and a text string register _s_t_r.
When a
+ function escape is processed, if it accepts an optional _e_x_p_r
argu-
+ ment which is not present, it reads the current value of either
_n_u_m
+ or _s_t_r as appropriate.
+
+
+ _R_e_t_u_r_n _v_a_l_u_e_s
+
+ Component escapes write the value of their message header in
_s_t_r.
+ Function escapes write their return value in _n_u_m for
functions
+ returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n values, and
in _s_t_r for functions
+ returning string values. (The _b_o_o_l_e_a_n type is a subset
of integers
+ with usual values 0=false and 1=true.)
+
+ All component escapes, and those function escapes which return an
+ _i_n_t_e_g_e_r or _s_t_r_i_n_g value, pass this value
back to their caller in
+ addition to setting _s_t_r or _n_u_m. These escapes will print
out this
+ value unless called as part of an argument to another escape
+ sequence. Function escapes which return a _b_o_o_l_e_a_n value
do pass
+ this value back to their caller, but will never print out the
+ value.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -110- MH-FORMAT(5)
+
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t _R_e_t_u_r_n
_D_e_s_c_r_i_p_t_i_o_n
+ msg integer message number
+ cur integer message is current
+ size integer size of message
+ strlen integer length of _s_t_r
+ width integer output buffer size in bytes
+ charleft integer bytes left in output buffer
+ timenow integer seconds since the UNIX epoch
+ me string the user's mailbox
+ eq literal boolean _n_u_m == _a_r_g
+ ne literal boolean _n_u_m != _a_r_g
+ gt literal boolean _n_u_m > _a_r_g
+ match literal boolean _s_t_r contains _a_r_g
+ amatch literal boolean _s_t_r starts with _a_r_g
+ plus literal integer _a_r_g plus _n_u_m
+ minus literal integer _a_r_g minus _n_u_m
+ divide literal integer _n_u_m divided by _a_r_g
+ num literal integer Set _n_u_m to _a_r_g
+ lit literal string Set _s_t_r to _a_r_g
+ nonzero expr boolean _n_u_m is non-zero
+ zero expr boolean _n_u_m is zero
+ null expr boolean _s_t_r is empty
+ nonnull expr boolean _s_t_r is non-empty
+ void expr Set _s_t_r or _n_u_m
+ comp comp string Set _s_t_r to component text
+ compval comp integer _n_u_m set to "atoi(_s_t_r)"
+ trim expr trim trailing white-space from _s_t_r
+ putstr expr print _s_t_r
+ putstrf expr print _s_t_r in a fixed width
+ putnum expr print _n_u_m
+ putnumf expr print _n_u_m in a fixed width
+
+ These functions require a date component as an argument:
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t _R_e_t_u_r_n
_D_e_s_c_r_i_p_t_i_o_n
+ sec date integer seconds of the minute
+ min date integer minutes of the hour
+ hour date integer hours of the day (0-23)
+ wday date integer day of the week (Sun=0)
+ day date string day of the week (abbrev.)
+ weekday date string day of the week
+ sday date integer day of the week known?
+ (0=implicit,-1=unknown)
+ mday date integer day of the month
+ yday date integer day of the year
+ mon date integer month of the year
+ month date string month of the year (abbrev.)
+ lmonth date string month of the year
+ year date integer year of the century
+ zone date integer timezone in hours
+ tzone date string timezone string
+ szone date integer timezone explicit?
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -111- MH-FORMAT(5)
+
+
+ (0=implicit,-1=unknown)
+ date2local date coerce date to local timezone
+ date2gmt date coerce date to GMT
+ dst date integer daylight savings in effect?
+ clock date integer seconds since the UNIX epoch
+ rclock date integer seconds prior to current time
+ tws date string official 822 rendering
+ pretty date string user-friendly rendering
+ nodate date integer _s_t_r not a date string
+
+ These functions require an address component as an argument. The
+ return value of functions noted with `*' pertain only to the first
+ address present in the header component.
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t _R_e_t_u_r_n
_D_e_s_c_r_i_p_t_i_o_n
+ proper addr string official 822 rendering
+ friendly addr string user-friendly rendering
+ addr addr string address@hidden or host!mbox rendering*
+ pers addr string the personal name*
+ note addr string commentary text*
+ mbox addr string the local mailbox*
+ mymbox addr integer the user's addresses? (0=no,1=yes)
+ host addr string the host domain*
+ nohost addr integer no host was present*
+ type addr integer host type* (0=local,1=network,
+ -1=uucp,2=unknown)
+ path addr string any leading host route*
+ ingrp addr integer address was inside a group*
+ gname addr string name of group*
+ formataddr expr append _a_r_g to _s_t_r as a
+ (comma separated) address list
+ putaddr literal print _s_t_r address list with
+ _a_r_g as optional label;
+ get line width from _n_u_m
+
+ When escapes are nested, evaluation is done from inner-most to
+ outer-most. The outer-most escape must begin with `%'; the inner
+ escapes must not. For example,
+
+ %<(mymbox{from}) To: %{to}%>
+
+ writes the value of the header component "From:" to _s_t_r; then
(_m_y_m_-
+ _b_o_x) reads _s_t_r and writes its result to _n_u_m;
then the control
+ escape evaluates _n_u_m. If _n_u_m is non-zero, the string
"To: " is
+ printed followed by the value of the header component "To:".
+
+ A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is in order.
In general, it
+ checks each of the addresses in the header component "_c_o_m_p"
against
+ the user's mailbox name and any
_A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s. It returns
+ true if any address matches, however, it also returns true if the
+ "_c_o_m_p" header is not present in the message. If needed, the
(_n_u_l_l)
+ function can be used to explicitly test for this condition.
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -112- MH-FORMAT(5)
+
+
+ When a function or component escape is interpreted and the result
+ will be immediately printed, an optional field width can be speci-
+ fied to print the field in exactly a given number of characters.
+ For example, a numeric escape like %4(_s_i_z_e) will print at
most 4
+ digits of the message size; overflow will be indicated by a `?' in
+ the first position (like `?234'). A string escape like %4(_m_e) will
+ print the first 4 characters and truncate at the end. Short fields
+ are padded at the right with the fill character (normally, a
+ blank). If the field width argument begins with a leading zero,
+ then the fill character is set to a zero.
+
+ As above, the functions (_p_u_t_n_u_m_f) and
(_p_u_t_s_t_r_f) print their result
+ in exactly the number of characters specified by their leading
+ field width argument. For example,
%06(_p_u_t_n_u_m_f(_s_i_z_e)) will print
+ the message size in a field six characters wide filled with leading
+ zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print the "From:"
header component
+ in fourteen characters with trailing spaces added as needed. For
+ _p_u_t_s_t_r_f, using a negative value for the field width
causes right-
+ justification of the string within the field, with padding on the
+ left up to the field width. The functions (_p_u_t_n_u_m) and
(_p_u_t_s_t_r)
+ print their result in the minimum number of characters required,
+ and ignore any leading field width argument.
+
+ The available output width is kept in an internal register; any
+ output past this width will be truncated.
+
+ With all this in mind, here's the default format string for
_s_c_a_n.
+ It's been divided into several pieces for readability. The first
+ part is:
+
+ %4(putnumf(msg))%<(cur)+%| %>%<{replied}-%| %>
+
+ which says that the message number should be printed in four
+ digits, if the message is the current message then a `+' else a
+ space should be printed, and if a "Replied:" field is present then
+ a `-' else a space should be printed. Next:
+
+ %02(putnumf(mon{date}))/%02(putnumf(mday{date}))
+
+ the month and date are printed in two digits (zero filled)
+ separated by a slash. Next,
+
+ %<{date} %|*>
+
+ If a "Date:" field was present, then a space is printed, otherwise
+ a `*'. Next,
+
+ %<(mymbox{from})To:%14(putstrf(friendly{to}))
+
+ if the message is from me, print `To:' followed by a "user-
+ friendly" rendering of the first address in the "To:" field. Con-
+ tinuing,
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -113- MH-FORMAT(5)
+
+
+ %|%17(putstrf(friendly{from}))%>
+
+ if the message isn't from me, then the print the "From:" address is
+ printed. And finally,
+
+ %{subject}%<{body}<<%{body}%>
+
+ the subject and initial body (if any) are printed.
+
+ For a more complicated example, next consider the default
_r_e_p_l_c_o_m_p_s
+ format file.
+
+ %(lit)%(formataddr %<{reply-to}%|
+
+ This clears _s_t_r and formats the "Reply-To:" header if present.
If
+ not present, the else clause is executed:
+
+ %<{from}%|%<{sender}%|%<{return-path}%>%>%>%>)\
+
+ This formats the "From:", "Sender:" and "Return-Path:" headers,
+ stopping as soon as one of them is present. Next:
+
+ %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+ If the _f_o_r_m_a_t_a_d_d_r result is non-null, it is printed
as an address
+ (with line folding if needed) in a field _w_i_d_t_h wide with a
leading
+ label of "To: ".
+
+ %(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+ _s_t_r is cleared, and the "To:" and "Cc:" headers, along with
the
+ user's address (depending on what was specified with the "-cc"
+ switch to _r_e_p_l) are formatted.
+
+ %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+ If the result is non-null, it is printed as above with a leading
+ label of "cc: ".
+
+ %<{fcc}Fcc: %{fcc}\n%>\
+
+ If a "-fcc folder" switch was given to _r_e_p_l (see _r_e_p_l
(1) for more
+ details about %{_f_c_c}), an "Fcc:" header is output.
+
+ %<{subject}Subject: Re: %{subject}\n%>\
+
+ If a subject component was present, a suitable reply subject is
+ output.
+
+ %<{date}In-reply-to: Your message of "\
+ %<(nodate{date})%{date}%|%(tws{date})%>."%<{message-id}
+ %{message-id}%>\n%>\
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -114- MH-FORMAT(5)
+
+
+ --------
+
+ If a date component was present, an "In-Reply-To:" header is output
+ with the preface "Your message of ". If the date was parseable, it
+ is output in official format, otherwise it is output as-is. The
+ message-id is included if present. As with all plain-text, the row
+ of dashes are output as-is.
+
+ This last part is a good example for a little more elaboration.
+ Here's that part again in pseudo-code:
+
+ if (comp_exists(date)) then
+ print ("In-reply-to: Your message of \"")
+ if (not_date_string(date.value) then
+ print (date.value)
+ else
+ print (rfc822(date.value))
+ endif
+ print ("\"")
+ if (comp_exists(message-id)) then
+ print ("\n\t")
+ print (message-id.value)
+ endif
+ print ("\n")
+ endif
+
+ Although this seems complicated, in point of fact, this method is
+ flexible enough to extract individual fields and print them in any
+ format the user desires.
+
+ _F_i_l_e_s
+ None
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ scan(1), repl(1), ap(8), dp(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -115- MH-FORMAT(5)
+
+
+ _H_i_s_t_o_r_y
+ This software was contributed for MH 6.3. Prior to this, output
+ format specifications were much easier to write, but considerably
+ less flexible.
+
+
+ _B_u_g_s
+ On hosts where _M_H was configured with the BERK option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -116- MH-MAIL(5)
+
+
+ _N_A_M_E
+ mh-mail - message format for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H processes messages in a particular format. It should be noted
+ that although neither Bell nor Berkeley mailers produce message
+ files in the format that _M_H prefers, _M_H can read message files
in
+ that antiquated format.
+
+ Each user possesses a mail drop box which initially receives all
+ messages processed by _p_o_s_t (8). _I_n_c (1) will read from
that drop
+ box and incorporate the new messages found there into the user's
+ own mail folders (typically `+inbox'). The mail drop box consists
+ of one or more messages. To facilitate the separation of messages,
+ each message begins and ends with a line consisting of nothing but
+ four CTRL-A (octal 001) characters.
+
+ Messages are expected to consist of lines of text. Graphics and
+ binary data are not handled. No data compression is accepted. All
+ text is clear ASCII 7-bit data.
+
+ The general "memo" framework of RFC-822 is used. A message con-
+ sists of a block of information in a rigid format, followed by gen-
+ eral text with no specified format. The rigidly formatted first
+ part of a message is called the header, and the free-format portion
+ is called the body. The header must always exist, but the body is
+ optional. These parts are separated by an empty line, i.e., two
+ consecutive newline characters. Within _M_H, the header and body may
+ be separated by a line consisting of dashes:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ The header is composed of one or more header items. Each header
+ item can be viewed as a single logical line of ASCII characters.
+ If the text of a header item extends across several real lines, the
+ continuation lines are indicated by leading spaces or tabs.
+
+ Each header item is called a component and is composed of a keyword
+ or name, along with associated text. The keyword begins at the
+ left margin, may NOT contain spaces or tabs, may not exceed 63
+ characters (as specified by RFC-822), and is terminated by a colon
+ (`:'). Certain components (as identified by their keywords) must
+ follow rigidly defined formats in their text portions.
+
+ The text for most formatted components (e.g., "Date:" and
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -117- MH-MAIL(5)
+
+
+ "Message-Id:") is produced automatically. The only ones entered by
+ the user are address fields such as "To:", "cc:", etc. Internet
+ addresses are assigned mailbox names and host computer specifica-
+ tions. The rough format is "address@hidden", such as
"address@hidden", or
+ "address@hidden". Multiple addresses are separated by commas. A
+ missing host/domain is assumed to be the local host/domain.
+
+ As mentioned above, a blank line (or a line of dashes) signals that
+ all following text up to the end of the file is the body. No for-
+ matting is expected or enforced within the body.
+
+ Following is a list of header components that are considered mean-
+ ingful to various MH programs.
+ Date:
+ Added by _p_o_s_t (8), contains date and time of the
message's
+ entry into the transport system.
+
+ From:
+ Added by _p_o_s_t (8), contains the address of the author
or
+ authors (may be more than one if a "Sender:" field is
+ present). Replies are typically directed to addresses in the
+ "Reply-To:" or "From:" field (the former has precedence if
+ present).
+
+ Sender:
+ Added by _p_o_s_t (8) in the event that the message already
has a
+ "From:" line. This line contains the address of the actual
+ sender. Replies are never sent to addresses in the "Sender:"
+ field.
+
+ To:
+ Contains addresses of primary recipients.
+
+ cc:
+ Contains addresses of secondary recipients.
+
+ Bcc:
+ Still more recipients. However, the "Bcc:" line is not copied
+ onto the message as delivered, so these recipients are not
+ listed. _M_H uses an encapsulation method for blind copies, see
+ _s_e_n_d (1).
+
+ Fcc:
+ Causes _p_o_s_t (8) to copy the message into the specified
folder
+ for the sender, if the message was successfully given to the
+ transport system.
+
+ Message-ID:
+ A unique message identifier added by _p_o_s_t (8) if the
`-msgid'
+ flag is set.
+
+ Subject:
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -118- MH-MAIL(5)
+
+
+ Sender's commentary. It is displayed by _s_c_a_n (1).
+
+ In-Reply-To:
+ A commentary line added by _r_e_p_l (1) when replying to a
mes-
+ sage.
+
+ Resent-Date:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-From:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-To:
+ New recipients for a message resent by _d_i_s_t (1).
+
+ Resent-cc:
+ Still more recipients. See "cc:" and "Resent-To:".
+
+ Resent-Bcc:
+ Even more recipients. See "Bcc:" and "Resent-To:".
+
+ Resent-Fcc:
+ Copy resent message into a folder. See "Fcc:" and
+ "Resent-To:".
+
+ Resent-Message-Id:
+ A unique identifier glued on by _p_o_s_t (8) if the `-msgid'
flag
+ is set. See "Message-Id:" and "Resent-To:".
+
+ Resent:
+ Annotation for _d_i_s_t (1) under the `-annotate' option.
+
+ Forwarded:
+ Annotation for _f_o_r_w (1) under the `-annotate' option.
+
+ Replied:
+ Annotation for _r_e_p_l (1) under the `-annotate' option.
+
+
+ _F_i_l_e_s
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e _F_o_r_m_a_t
_o_f _A_R_P_A _I_n_t_e_r_n_e_t _T_e_x_t
_M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -119- MH-MAIL(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -120- MH-PROFILE(5)
+
+
+ _N_A_M_E
+ .mh_profile - user customization for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Each user of _M_H is expected to have a file named
._m_h__p_r_o_f_i_l_e in his
+ or her home directory. This file contains a set of user parameters
+ used by some or all of the _M_H family of programs. Each line of the
+ file is of the format
+
+ _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t: _v_a_l_u_e
+
+ The possible profile components are exemplified below. Only
+ `Path:' is mandatory. The others are optional; some have default
+ values if they are not present. In the notation used below, (pro-
+ file, default) indicates whether the information is kept in the
+ user's _M_H profile or _M_H context, and indicates what the
default
+ value is.
+
+ Path: Mail
+ Locates _M_H transactions in directory "Mail". (profile,
+ no default)
+
+ context: context
+ Declares the location of the _M_H context file, see the
+ HISTORY section below. (profile, default:
+ <mh-dir>/context)
+
+ Current-Folder: inbox
+ Keeps track of the current open folder. (context,
+ default: +inbox)
+
+ Previous-Sequence: pseq
+ Names the sequences which should be defined as the `msgs'
+ or `msg' argument given to the program. If not present,
+ or empty, no sequences are defined. Otherwise, for each
+ name given, the sequence is first zero'd and then each
+ message is added to the sequence. (profile, no default)
+
+ Sequence-Negation: not
+ Defines the string which, when prefixed to a sequence
+ name, negates that sequence. Hence, "notseen" means all
+ those messages that are not a member of the sequence
+ "seen". (profile, no default)
+
+ Unseen-Sequence: unseen
+ Names the sequences which should be defined as those mes-
+ sages recently incorporated by _i_n_c. _S_h_o_w knows
to remove
+ messages from this sequence once it thinks they have been
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -121- MH-PROFILE(5)
+
+
+ seen. If not present, or empty, no sequences are
+ defined. Otherwise, for each name given, the sequence is
+ first zero'd and then each message is added to the
+ sequence. (profile, no default)
+
+ mh-sequences: .mh_sequences
+ The name of the file in each folder which defines public
+ sequences. To disable the use of public sequences, leave
+ the value portion of this entry blank. (profile,
+ default: .mh_sequences)
+
+ atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+ Keeps track of the private sequence called _s_e_q in
the
+ specified folder. (context, no default)
+
+ Editor: /usr/ucb/ex
+ Defines editor to be used by _c_o_m_p (1),
_d_i_s_t (1),
+ _f_o_r_w (1), and _r_e_p_l (1). (profile, default:
prompter)
+
+ Msg-Protect: 644
+ Defines octal protection bits for message files. See
+ _c_h_m_o_d (1) for an explanation of the octal number.
(pro-
+ file, default: 0644)
+
+ Folder-Protect: 711
+ Defines protection bits for folder directories. (pro-
+ file, default: 0711)
+
+ _p_r_o_g_r_a_m: default switches
+ Sets default switches to be used whenever the mh program
+ _p_r_o_g_r_a_m is invoked. For example, one could
override the
+ _E_d_i_t_o_r: profile component when replying to
messages by
+ adding a component such as:
+ repl: -editor /bin/ed
+ (profile, no defaults)
+
+ _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+ Names "nexteditor" to be the default editor after using
+ "lasteditor". This takes effect at "What now?" level in
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, and _r_e_p_l.
After editing the draft with
+ "lasteditor", the default editor is set to be "nextedi-
+ tor". If the user types "edit" without any arguments to
+ "What now?", then "nexteditor" is used. (profile, no
+ default)
+
+ bboards: system
+ Tells _b_b_c which BBoards you are interested in.
(profile,
+ default: system)
+
+ Folder-Stack: _f_o_l_d_e_r_s
+ The contents of the folder-stack for the _f_o_l_d_e_r
command.
+ (context, no default)
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -122- MH-PROFILE(5)
+
+
+ mhe:
+ If present, tells _i_n_c to compose an _M_H_E
auditfile in
+ addition to its other tasks. _M_H_E is Brian Reid's
_E_m_a_c_s
+ front-end for _M_H. An early version is supplied with the
+ _m_h._6 distribution. (profile, no default)
+
+ Alternate-Mailboxes: address@hidden, bug-mh*
+ Tells _r_e_p_l and _s_c_a_n which addresses are
really yours. In
+ this way, _r_e_p_l knows which addresses should be
included
+ in the reply, and _s_c_a_n knows if the message really
ori-
+ ginated from you. Addresses must be separated by a
+ comma, and the hostnames listed should be the "official"
+ hostnames for the mailboxes you indicate, as local nick-
+ names for hosts are not replaced with their official site
+ names. For each address, if a host is not given, then
+ that address on any host is considered to be you. In
+ addition, an asterisk (`*') may appear at either or both
+ ends of the mailbox and host to indicate wild-card match-
+ ing. (profile, default: your user-id)
+
+ Aliasfile: aliases
+ Indicates a default aliases file for _a_l_i, _w_h_o_m,
and _s_e_n_d.
+ This may be used instead of the `-alias file' switch.
+ (profile, no default)
+
+ Draft-Folder: drafts
+ Indicates a default draft folder for _c_o_m_p,
_d_i_s_t, _f_o_r_w,
+ and _r_e_p_l. (profile, no default)
+
+ digest-issue-_l_i_s_t: 1
+ Tells _f_o_r_w the last issue of the last volume sent for
the
+ digest _l_i_s_t. (context, no default)
+
+ digest-volume-_l_i_s_t: 1
+ Tells _f_o_r_w the last volume sent for the digest
_l_i_s_t.
+ (context, no default)
+
+ MailDrop: .mail
+ Tells _i_n_c your maildrop, if different from the
default.
+ This is superceded by the $MAILDROP envariable. (pro-
+ file, default: /usr/spool/mail/$USER)
+
+ Signature: RAND MH System (agent: Marshall Rose)
+ Tells _s_e_n_d your mail signature. This is superceded
by
+ the $SIGNATURE envariable. On hosts where _M_H was config-
+ ured with the UCI option, if $SIGNATURE is not set and
+ this profile entry is not present, the file
+ $HOME/.signature is consulted. Your signature will be
+ added to the address _s_e_n_d puts in the "From:"
header; do
+ not include an address in the signature text. (profile,
+ no default)
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -123- MH-PROFILE(5)
+
+
+ The following profile elements are used whenever an _M_H program
+ invokes some other program such as _m_o_r_e (1). The
._m_h__p_r_o_f_i_l_e can
+ be used to select alternate programs if the user wishes. The
+ default values are given in the examples.
+
+ fileproc: /usr/local/refile
+ incproc: /usr/local/inc
+ installproc: /usr/local/lib/mh/install-mh
+ lproc: /usr/ucb/more
+ mailproc: /usr/local/mhmail
+ mhlproc: /usr/local/lib/mh/mhl
+ moreproc: /usr/ucb/more
+ mshproc: /usr/local/msh
+ packproc: /usr/local/packf
+ postproc: /usr/local/lib/mh/post
+ rmmproc: none
+ rmfproc: /usr/local/rmf
+ sendproc: /usr/local/send
+ showproc: /usr/ucb/more
+ whatnowproc: /usr/local/whatnow
+ whomproc: /usr/local/whom
+
+ If you define the envariable $MH, you can specify a profile other
+ than ._m_h__p_r_o_f_i_l_e to be read by the _M_H programs
that you invoke. If
+ the value of $MH is not absolute, (i.e., does not begin with a / ),
+ it will be presumed to start from the current working directory.
+ This is one of the very few exceptions in _M_H where non-absolute
+ pathnames are not considered relative to the user's _M_H directory.
+
+ Similarly, if you define the envariable $MHCONTEXT, you can specify
+ a context other than the normal context file (as specified in the
+ _M_H profile). As always, unless the value of $MHCONTEXT is abso-
+ lute, it will be presumed to start from your _M_H directory.
+
+ _M_H programs also support other envariables:
+
+ $MAILDROP : tells _i_n_c the default maildrop
+ This supercedes the "MailDrop:" profile entry.
+
+ $SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail signature
+ This supercedes the "Signature:" profile entry.
+
+ $HOME : tells all _M_H programs your home directory
+
+ $SHELL : tells _b_b_l the default shell to run
+
+ $TERM : tells _M_H your terminal type
+ The $TERMCAP envariable is also consulted. In particular,
+ these tells _s_c_a_n and _m_h_l how to clear your
terminal, and how
+ many columns wide your terminal is. They also tell _m_h_l
how
+ many lines long your terminal screen is.
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -124- MH-PROFILE(5)
+
+
+ $editalt : the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit sessions
so you can
+ peruse the message being distributed or replied-to. The mes-
+ sage is also available through a link called "@" in the
+ current directory if your current working directory and the
+ folder the message lives in are on the same UNIX filesystem.
+
+ $mhdraft : the path to the working draft
+ This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l to tell the _w_h_a_t_-
+ _n_o_w_p_r_o_c which file to ask "What now?" questions
about. In
+ addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l set
$mhfolder if appropriate.
+ Further, _d_i_s_t and _r_e_p_l set $mhaltmsg to tell the
_w_h_a_t_n_o_w_p_r_o_c
+ about an alternate message associated with the draft (the mes-
+ sage being distributed or replied-to), and _d_i_s_t sets
$mhdist
+ to tell the _w_h_a_t_n_o_w_p_r_o_c that message
re-distribution is occur-
+ ring. Also, $mheditor is set to tell the
_w_h_a_t_n_o_w_p_r_o_c the
+ user's choice of editor (unless overridden by `-noedit').
+ Similarly, $mhuse may be set by _c_o_m_p. Finally,
$mhmessages is
+ set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if annotations
are to occur (along
+ with $mhannotate, and $mhinplace). It's amazing all the
+ information that has to get passed via envariables to make the
+ "What now?" interface look squeaky clean to the _M_H user, isn't
+ it? The reason for all this is that the _M_H user can select
+ _a_n_y program as the _w_h_a_t_n_o_w_p_r_o_c,
including one of the standard
+ shells. As a result, it's not possible to pass information
+ via an argument list.
+ If the WHATNOW option was set during _M_H configuration (type
+ `-help' to an _M_H command to find out), and if this envariable
+ is set, if the commands _r_e_f_i_l_e, _s_e_n_d,
_s_h_o_w, or _w_h_o_m are not
+ given any `msgs' arguments, then they will default to using
+ the file indicated by $mhdraft. This is useful for getting
+ the default behavior supplied by the default
_w_h_a_t_n_o_w_p_r_o_c.
+
+ $mhfolder : the folder containing the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit sessions
so you can
+ peruse other messages in the current folder besides the one
+ being distributed or replied-to. The $mhfolder envariable is
+ also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t for use
by _m_h_l.
+
+ $MHBBRC :
+ If you define the envariable $MHBBRC, you can specify a
+ BBoards information file other than ._b_b_r_c to be read by
_b_b_c.
+ If the value of $MHBBRC is not absolute, (i.e., does not begin
+ with a / ), it will be presumed to start from the current
+ working directory.
+
+ $MHFD :
+ If the OVERHEAD option was set during _M_H configuration (type
+ `-help' to an _M_H command to find out), then if this envariable
+ is set, _M_H considers it to be the number of a file-descriptor
+ which is opened, read-only to the _M_H profile. Similarly, if
+ the envariable $MHCONTEXTFD is set, this is the number of a
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -125- MH-PROFILE(5)
+
+
+ file-descriptor which is opened read-only to the _M_H context.
+ This feature of _M_H is experimental, and is used to examine
+ possible speed improvements for _M_H startup. Note that these
+ envariables must be set and non-empty to enable this feature.
+ However, if OVERHEAD is enabled during _M_H configuration, then
+ when _M_H programs call other _M_H programs, this scheme is
used.
+ These file-descriptors are not closed throughout the execution
+ of the _M_H program, so children may take advantage of this.
+ This approach is thought to be completely safe and does result
+ in some performance enhancements.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ or $MH Rather than the standard profile
+ <mh-dir>/context The user context
+ or $CONTEXT Rather than the standard context
+ <folder>/.mh_sequences Public sequences for <folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ All
+
+
+ _S_e_e _A_l_s_o
+ mh(1), environ(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -126- MH-PROFILE(5)
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the current-message value of a writable
+ folder was kept in a file called "cur" in the folder itself. In
+ _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the
current-message values for all
+ folders, regardless of their writability.
+
+ In all versions of _M_H since _m_h._4, the
._m_h__p_r_o_f_i_l_e contains only
+ static information, which _M_H programs will NOT update. Changes in
+ context are made to the _c_o_n_t_e_x_t file kept in the users MH
_d_i_r_e_c_t_o-
+ _r_y. This includes, but is not limited to: the "Current-Folder" en-
+ try and all private sequence information. Public sequence informa-
+ tion is kept in a file called ._m_h__s_e_q_u_e_n_c_e_s in
each folder.
+
+ To convert from the format used in releases of _M_H prior to the for-
+ mat used in the _m_h._4 release, _i_n_s_t_a_l_l-_m_h should
be invoked with the
+ `-compat' switch. This generally happens automatically on _M_H sys-
+ tems generated with the "COMPAT" option during _M_H configuration.
+
+ The ._m_h__p_r_o_f_i_l_e may override the path of the
_c_o_n_t_e_x_t file, by
+ specifying a "context" entry (this must be in lower-case). If the
+ entry is not absolute (does not start with a / ), then it is inter-
+ preted relative to the user's _M_H directory. As a result, you can
+ actually have more than one set of private sequences by using dif-
+ ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -127- MH-PROFILE(5)
+
+
+ _B_u_g_s
+ The shell quoting conventions are not available in the .mh_profile.
+ Each token is separated by whitespace.
+
+ There is some question as to what kind of arguments should be
+ placed in the profile as options. In order to provide a clear
+ answer, recall command line semantics of all _M_H programs: conflict-
+ ing switches (e.g., `-header and `-noheader') may occur more than
+ one time on the command line, with the last switch taking effect.
+ Other arguments, such as message sequences, filenames and folders,
+ are always remembered on the invocation line and are not superseded
+ by following arguments of the same type. Hence, it is safe to
+ place only switches (and their arguments) in the profile.
+
+ If one finds that an _M_H program is being invoked again and again
+ with the same arguments, and those arguments aren't switches, then
+ there are a few possible solutions to this problem. The first is
+ to create a (soft) link in your $_H_O_M_E/_b_i_n directory to
the _M_H pro-
+ gram of your choice. By giving this link a different name, you can
+ create a new entry in your profile and use an alternate set of de-
+ faults for the _M_H command. Similarly, you could create a small
+ shell script which called the _M_H program of your choice with an al-
+ ternate set of invocation line switches (using links and an alter-
+ nate profile entry is preferable to this solution).
+
+ Finally, the _c_s_h user could create an alias for the command of
the
+ form:
+
+ alias cmd 'cmd arg1 arg2 ...'
+
+ In this way, the user can avoid lengthy type-in to the shell, and
+ still give _M_H commands safely. (Recall that some _M_H commands
in-
+ voke others, and that in all cases, the profile is read, meaning
+ that aliases are disregarded beyond an initial command invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -128- MH-SEQUENCE(5)
+
+
+ _N_A_M_E
+ mh-sequence - sequence specification for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ most _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Most _M_H commands accept a `msg' or `msgs' specification, where
+ `msg' indicates one message and `msgs' indicates one or more mes-
+ sages. To designate a message, you may use either its number
+ (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+ _N_a_m_e _D_e_s_c_r_i_p_t_i_o_n
+ first the first message in the folder
+ last the last message in the folder
+ cur the most recently accessed message
+ prev the message numerically preceding "cur"
+ next the message numerically following "cur"
+
+ In commands that take a `msg' argument, the default is "cur". As a
+ shorthand, "." is equivalent to "cur".
+
+ For example: In a folder containing five messages numbered 5, 10,
+ 94, 177 and 325, "first" is 5 and "last" is 325. If "cur" is 94,
+ then "prev" is 10 and "next" is 177.
+
+ The word `msgs' indicates that one or more messages may be speci-
+ fied. Such a specification consists of one message designation or
+ of several message designations separated by spaces. A message
+ designation consists either of a message name as defined above, or
+ a message range.
+
+ A message range is specified as "name1-name2" or "name:n", where
+ `name', `name1' and `name2' are message names, and `n' is an
+ integer.
+
+ The specification "name1-name2" designates all currently-existing
+ messages from `name1' to `name2' inclusive. The message name "all"
+ is a shorthand for the message range "first-last".
+
+ The specification "name:n" designates up to `n' messages. These
+ messages start with `name' if `name' is a message number or one of
+ the reserved names "first" "cur", or "next", The messages end with
+ `name' if `name' is "prev" or "last". The interpretation of `n'
+ may be overridden by preceding `n' with a plus or minus sign; `+n'
+ always means up to `n' messages starting with `name', and `-n'
+ always means up to `n' messages ending with `name'.
+
+ In commands which accept a `msgs' argument, the default is either
+ "cur" or "all", depending on which makes more sense. Repeated
+ specifications of the same message have the same effect as a single
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -129- MH-SEQUENCE(5)
+
+
+ specification of the message.
+
+
+ _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e
_S_e_q_u_e_n_c_e_s
+
+ In addition to the "reserved" (pre-defined) message names given
+ above, _M_H supports user-defined sequence names. User-defined
+ sequences allow the _M_H user a tremendous amount of power in dealing
+ with groups of messages in the same folder by allowing the user to
+ bind a group of messages to a meaningful symbolic name.
+
+ The name used to denote a message sequence must consist of an
+ alphabetic character followed by zero or more alphanumeric charac-
+ ters, and can not be one of the "reserved" message names above.
+ After defining a sequence, it can be used wherever an _M_H command
+ expects a `msg' or `msgs' argument.
+
+ Some forms of message ranges are allowed with user-defined
+ sequences. The specification "name:n" may be used, and it desig-
+ nates up to the first `n' messages (or last `n' messages for `-n')
+ which are elements of the user-defined sequence `name'.
+
+ The specifications "name:next" and "name:prev" may also be used,
+ and they designate the next or previous message (relative to the
+ current message) which is an element of the user-defined sequence
+ `name'. The specificaitions "name:first" and "name:last" are
+ equivalent to "name:1" and "name:-1", respectively. The specifica-
+ tion "name:cur" is not allowed (use just "cur" instead). The syn-
+ tax of these message range specifcations is subject to change in
+ the future.
+
+ User-defined sequence names are specific to each folder. They are
+ defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two varieties of sequences: _p_u_b_l_i_c sequences and
_p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are accessible
to any _M_H
+ user that can read that folder and are kept in the .mh_sequences
+ file in the folder. _P_r_i_v_a_t_e sequences are accessible
only to the
+ _M_H user that defined those sequences and are kept in the user's
_M_H
+ context file. By default, _p_i_c_k and _m_a_r_k create
_p_u_b_l_i_c sequences if
+ the folder for which the sequences are being defined is writable by
+ the _M_H user. Otherwise, _p_r_i_v_a_t_e sequences are
created. This can
+ be overridden with the `-public' and `-private' switches to
_m_a_r_k.
+
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ _M_H provides the ability to select all messages not elements of a
+ user-defined sequence. To do this, the user should define the
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -130- MH-SEQUENCE(5)
+
+
+ entry "Sequence-Negation" in the _M_H profile file; its value may be
+ any string. This string is then used to preface an existing user-
+ defined sequence name. This specification then refers to those
+ messages not elements of the specified sequence name. For example,
+ if the profile entry is:
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command is given "notfoo" as a `msg' or `msgs'
+ argument, it would substitute all messages that are not elements of
+ the sequence "foo".
+
+ Obviously, the user should beware of defining sequences with names
+ that begin with the value of the "Sequence-Negation" profile entry.
+
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ _M_H provides the ability to remember the `msgs' or `msg' argument
+ last given to an _M_H command. The entry "Previous-Sequence" should
+ be defined in the _M_H profile; its value should be a sequence name
+ or multiple sequence names separated by spaces. If this entry is
+ defined, when when an _M_H command finishes, it will define the
+ sequence(s) named in the value of this entry to be those messages
+ that were specified to the command. Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs' argument to
+ define the sequence "pseq" as those messages when it finishes.
+
+ Note: there can be a performance penalty in using the
+ "Previous-Sequence" facility. If it is used, all _M_H programs have
+ to write the sequence information to the .mh_sequences file for the
+ folder each time they run. If the "Previous-Sequence" profile
+ entry is not included, only _p_i_c_k and _m_a_r_k will
write to the
+ .mh_sequences file.
+
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to indicate messages which have not been
+ previously seen by them. Both _i_n_c and _s_h_o_w honor the
profile entry
+ "Unseen-Sequence" to support this activity. This entry in the
+ .mh_profile should be defined as one or more sequence names
+ separated by spaces. If there is a value for "Unseen-Sequence" in
+ the profile, then whenever _i_n_c places new messages in a folder,
the
+ new messages will also be added to the sequence(s) named in the
+ value of this entry. Hence, a profile entry of
+
+ Unseen-Sequence: unseen
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -131- MH-SEQUENCE(5)
+
+
+ directs _i_n_c to add new messages to the sequence "unseen".
Unlike
+ the behavior of the "Previous-Sequence" entry in the profile, how-
+ ever, the sequence(s) will not be zeroed by _i_n_c.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or _p_r_e_v)
displays a message, that
+ message will be removed from any sequences named by the
+ "Unseen-Sequence" entry in the profile.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/context The user context
+ <folder>/.mh_sequences Public sequences for <folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Sequence-Negation: To designate messages not in a sequence
+ Previous-Sequence: The last message specification given
+ Unseen-Sequence: Those messages not yet seen by the user
+
+
+ _S_e_e _A_l_s_o
+ mh(1), mark(1), pick(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+ _B_u_g_s
+ User-defined sequences are stored in the .mh_sequences file as a
+ series of message specifications separated by spaces. If a user-
+ defined sequence contains too many individual message specifica-
+ tions, that line in the file may become too long for _M_H to handle.
+ This will generate the error message ".mh_sequences is poorly for-
+ matted". You'll have to edit the file by hand to remove the of-
+ fending line.
+
+ This can happen to users who define the "Previous-Sequence" entry
+ in the _M_H profile and have a folder containing many messages with
+ gaps in the numbering. A workaround for large folders is to minim-
+ ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ AP(8) -132- AP(8)
+
+
+ _N_A_M_E
+ ap - parse addresses 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_p is a program that parses addresses according to the ARPA Inter-
+ net standard. It also understands many non-standard formats. It
+ is useful for seeing how _M_H will interpret an address.
+
+ The _a_p program treats each argument as one or more addresses, and
+ prints those addresses out in the official 822-format. Hence, it
+ is usually best to enclose each argument in double-quotes for the
+ shell.
+
+ To override the output format used by _a_p, the `-format string' or
+ `-format file' switches are used. This permits individual fields
+ of the address to be extracted with ease. The string is simply a
+ format stringand thefile is simply a format file. See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard escapes, _a_p also recognizes the follow-
+ ing additional escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ error string A diagnostic if the parse failed
+
+ If the `-normalize' switch is given, _a_p will try to track down the
+ official hostname of the address.
+
+ Here is the default format string used by _a_p:
+
+ %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+ which says that if an error was detected, print the error, a `:',
+ and the address in error. Otherwise, output the 822-proper format
+ of the address.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ AP(8) -133- AP(8)
+
+
+ _S_e_e _A_l_s_o
+ dp(8),
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e _F_o_r_m_a_t
_o_f _A_R_P_A _I_n_t_e_r_n_e_t _T_e_x_t
_M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' defaults as described above
+ `-normalize'
+ `-width' defaults to the width of the terminal
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a sin-
+ gle token by the shell that invokes _a_p. Therefore, one must usual-
+ ly place the argument to this switch inside double-quotes.
+
+ On hosts where _M_H was configured with the BERK option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -134- CONFLICT(8)
+
+
+ _N_A_M_E
+ conflict - search for alias/password conflicts
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/conflict [-mail name] [-search directory]
+ [aliasfiles...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_n_f_l_i_c_t is a program that checks to see if the
interface between
+ _M_H and transport system is in good shape
+
+ _C_o_n_f_l_i_c_t also checks for maildrops in /usr/spool/mail
which do not
+ belong to a valid user. It assumes that no user name will start
+ with `.', and thus ignores files in /usr/spool/mail which begin
+ with `.'. It also checks for entries in the _g_r_o_u_p (5) file
which
+ do not belong to a valid user, and for users who do not have a
+ valid group number. In addition duplicate users and groups are
+ noted.
+
+ If the `-mail name' switch is used, then the results will be sent
+ to the specified _n_a_m_e. Otherwise, the results are sent to
the
+ standard output.
+
+ The `-search directory' switch can be used to search directories
+ other than /usr/spool/mail and to report anomalies in those direc-
+ tories. The `-search directory' switch can appear more than one
+ time in an invocation to _c_o_n_f_l_i_c_t.
+
+ _C_o_n_f_l_i_c_t should be run under _c_r_o_n (8), or
whenever system account-
+ ing takes place.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /etc/passwd List of users
+ /etc/group List of groups
+ /usr/local/mhmail Program to send mail
+ /usr/spool/mail/ Directory of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `aliasfiles' defaults to /usr/local/lib/mh/MailAliases
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -135- CONFLICT(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ DP(8) -136- DP(8)
+
+
+ _N_A_M_E
+ dp - parse dates 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_p is a program that parses dates according to the ARPA Internet
+ standard. It also understands many non-standard formats, such as
+ those produced by TOPS-20 sites and some UNIX sites using
+ _c_t_i_m_e (3). It is useful for seeing how _M_H will interpret
a date.
+
+ The _d_p program treats each argument as a single date, and prints
+ the date out in the official 822-format. Hence, it is usually best
+ to enclose each argument in double-quotes for the shell.
+
+ To override the output format used by _d_p, the `-format string' or
+ `-format file' switches are used. This permits individual fields
+ of the address to be extracted with ease. The string is simply a
+ format stringand thefile is simply a format file. See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ Here is the default format string used by _d_p:
+
+ %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+ which says that if an error was detected, print the error, a `:',
+ and the date in error. Otherwise, output the 822-proper format of
+ the date.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ ap(8)
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e _F_o_r_m_a_t
_o_f _A_R_P_A _I_n_t_e_r_n_e_t _T_e_x_t
_M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' default as described above
+ `-width' default to the width of the terminal
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ DP(8) -137- DP(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a sin-
+ gle token by the shell that invokes _d_p. Therefore, one must usual-
+ ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ INSTALL-MH(8) -138- INSTALL-MH(8)
+
+
+ _N_A_M_E
+ install-mh - initialize the MH environment
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ When a user runs any _M_H program for the first time, the program
+ will invoke _i_n_s_t_a_l_l-_m_h (with the `-auto' switch) to
query the user
+ for the initial _M_H environment. The user does NOT invoke this pro-
+ gram directly. The user is asked for the name of the directory
+ that will be designated as the user's _M_H directory. If this direc-
+ tory does not exist, the user is asked if it should be created.
+ Normally, this directory should be under the user's home directory,
+ and has the default name of Mail/. After
_i_n_s_t_a_l_l-_m_h has written
+ the initial .mh_profile for the user, control returns to the origi-
+ nal _M_H program.
+
+ As with all _M_H commands, _i_n_s_t_a_l_l-_m_h first
consults the $HOME
+ envariable to determine the user's home directory. If $HOME is not
+ set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+ When converting from _m_h._3 to _m_h._4,
_i_n_s_t_a_l_l-_m_h is automatically
+ invoked with the `-compat' switch.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To set the user's MH directory
+
+
+ _C_o_n_t_e_x_t
+ With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POST(8) -139- POST(8)
+
+
+ _N_A_M_E
+ post - deliver a message
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+ [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+ file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_o_s_t is the program called by _s_e_n_d (1) to deliver the
message in
+ _f_i_l_e to local and remote users. In fact, all of the
functions
+ attributed to _s_e_n_d on its manual page are performed by
_p_o_s_t, with
+ _s_e_n_d acting as a relatively simple preprocessor. Thus, it is
_p_o_s_t
+ which parses the various header fields, appends From: and Date:
+ lines, and interacts with the _M_M_D_F transport system.
_P_o_s_t will not
+ normally be called directly by the user.
+
+ _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:", and
"Resent-xxx:"
+ header lines of the specified message for destination addresses,
+ checks these addresses for validity, and formats them so as to con-
+ form to ARPAnet Internet Message Format protocol, unless the
+ `-noformat' flag is set. This will normally cause
"@_l_o_c_a_l-_s_i_t_e" to
+ be appended to each local destination address, as well as any local
+ return addresses. The `-width columns' switch can be used to indi-
+ cate the preferred length of the header components that contain
+ addresses.
+
+ If a "Bcc:" field is encountered, its addresses will be used for
+ delivery, and the "Bcc:" field will be removed from the message
+ sent to sighted recipients. The blind recipients will receive an
+ entirely new message with a minimal set of headers. Included in
+ the body of the message will be a copy of the message sent to the
+ sighted recipients. If `-filter filterfile' is specified, then
+ this copy is filtered (re-formatted) prior to being sent to the
+ blind recipients.
+
+ The `-alias aliasfile' switch can be used to specify a file that
+ post should take aliases from. More than one file can be speci-
+ fied, each being preceded with `-alias'. In any event, the primary
+ alias file is read first.
+
+ The `-msgid' switch indicates that a "Message-ID:" or
+ "Resent-Message-ID:" field should be added to the header.
+
+ The `-verbose' switch indicates that the user should be informed of
+ each step of the posting/filing process.
+
+ The `-watch' switch indicates that the user would like to watch the
+ transport system's handling of the message (e.g., local and "fast"
+ delivery).
+
+ [mh.6] MH.6.7 UCI version
+
+
+
+
+
+
+
+
+
+ POST(8) -140- POST(8)
+
+
+ _P_o_s_t consults the envariable $SIGNATURE to determine the
sender's
+ personal name in constructing the "From:" line of the message.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/local/refile Program to process Fcc:s
+ /usr/local/lib/mh/mhl Program to process Bcc:s
+ /usr/local/lib/mh/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ _p_o_s_t does NOT consult the user's .mh_profile
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e _F_o_r_m_a_t
_o_f _A_R_P_A _I_n_t_e_r_n_e_t _T_e_x_t
_M_e_s_s_a_g_e_s (aka
+ RFC-822),
+ mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-format'
+ `-nomsgid'
+ `-noverbose'
+ `-width 72'
+ `-nofilter'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ "Reply-To:" fields are allowed to have groups in them according to
+ the 822 specification, but _p_o_s_t won't let you use them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 [mh.6] MH.6.7 UCI
version
+
+
+
+
+
+
+
+
+
+
+
+
+ _5. _R_E_P_O_R_T_I_N_G
_P_R_O_B_L_E_M_S
+
+
+
+9
+ If problems are encountered with an _M_H program, the problems
should
+ be reported to the local maintainers of _M_H. When doing this, the
name
+ of the program should be reported, along with the version information
+ for the program. To find out what version of an _M_H program is
being
+ run, invoke the program with the `-help' switch. In addition to listing
+ the syntax of the command, the program will list information pertaining
+ to its version. This information includes the version of _M_H, the
host
+ it was generated on, and the date the program was loaded. A second line
+ of information, found on versions of _M_H after #5.380 include
_M_H confi-
+ guration options. For example,
+
+ version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov 6 01:13:53 PST
+ 1985
+ options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII] [SMTP] [POP]
+
+ The `6.1 #1[UCI]' indicates that the program is from the UCI
_m_h._6 ver-
+ sion of _M_H. The program was generated on the host
`nrtc-gremlin' on
+ `Wed Nov 6 01:13:53 PST 1985'. It's usually a good idea to send the
+ output of the `-help' switch along with your report.
+
+ If there is no local _M_H maintainer, try the address Bug-MH. If
that
+ fails, use the Internet mailbox address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 -141-
+
+
+
+
+
+
+
+
+
+
+
+
+ _6. _A_D_V_A_N_C_E_D
_F_E_A_T_U_R_E_S
+
+
+
+9
+ This section describes some features of _M_H that were
included
+ strictly for advanced _M_H users. These capabilities permit _M_H
to exhibit
+ more powerful behavior for the seasoned _M_H users.
+
+
+9 _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+ User-defined sequences allow the _M_H user a tremendous
amount of
+ power in dealing with groups of messages in the same folder by allowing
+ the user to bind a group of messages to a meaningful symbolic name. The
+ user may choose any name for a message sequence, as long as it consists
+ of alphanumeric characters and does not conflict with the standard
_M_H
+ reserved message names (e.g., "first", etc). After defining a sequence,
+ it can be used wherever an _M_H command expects a `msg' or `msgs'
argu-
+ ment.
+
+ A restricted form of message ranges are allowed with user-defined
+ sequences. The form "name:n", specifies up to the first `n' messages
+ which are part of the user-defined sequence `name'. A leading plus sign
+ is allowed on `n', but is ignored. The interpretation of n is overrid-
+ den if n is preceded by a minus sign; `-n' always means up to the last
+ `n' messages which are part of the sequence `name'.
+
+ Although all _M_H commands expand user-defined sequences as
appropri-
+ ate, there are two commands that allow the user to define and manipulate
+ them: _p_i_c_k and _m_a_r_k.
+
+ _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ Most users of _M_H will use user-defined sequences only with the
_p_i_c_k
+ command. By giving the `-sequence name' switch to _p_i_c_k (which
can occur
+ more than once on the command line), each sequence named is defined as
+ those messages which _p_i_c_k matched according the the selection
criteria
+ it was given. Hence,
+
+ pick -from frated -seq fred
+
+ finds all those messages in the current folder which were from "frated",
+ creates a sequence called "fred", and then adds them to the sequence.
+ The user could then invoke
+
+ scan fred
+
+ to get a _s_c_a_n listing of those messages. Note that by
default, _p_i_c_k
+ creates the named sequences before it adds the selected messages to the
+ sequence. Hence, if the named sequence already existed, the sequence is
+
+ -142-
+
+
+
+
+
+
+
+
+
+ -143-
+
+
+ destroyed prior to being re-defined (nothing happens to the messages
+ that were a part of this sequence, they simply cease to be members of
+ that sequence). By using the `-nozero' switch, this behavior can be
+ inhibited, as in
+
+ pick -from frated -seq sgroup
+ pick -from fear -seq sgroup -nozero
+ pick -from freida -seq sgroup -nozero
+
+ finds all those messages in the current folder which were from "frated",
+ "fear", or "freida", and defines the sequence called "sgroup" as exactly
+ those messages. These operations amounted to an "inclusive-or" of three
+ selection criteria, using _p_i_c_k, one can also generate the
"and" of some
+ selection criteria as well:
+
+ pick -from frated -seq fred
+ pick -before friday -seq fred fred
+
+ This example defines the sequence called "fred" as exactly those mes-
+ sages from "frated" that were dated prior to "friday".[1]
+
+ _P_i_c_k is normally used as a back-quoted command, for
example,
+
+ scan `pick -from postmaster`
+
+ Now suppose that the user decides that another command should be issued,
+ using exactly those messages. Since, _p_i_c_k wasn't
given a
+ `-sequence name' argument in this example, the user would end-up typing
+ the entire back-quoted command again. A simpler way is to add a default
+ sequence name to the .mh_profile. For example,
+
+ pick: -seq select -list
+
+ will tell _p_i_c_k to always define the sequence "select" whenever
it's run.
+ The `-list' is necessary since the `-sequence name' switch sets `-nol-
+ ist' whenever the former is encountered. Hence, this profile entry
+
+
+9 [1] Of course, it is much easier to simply use the built-in
boolean
+ operation of _p_i_c_k to get the desired results:
+
+ pick -from frated -or -from fear -or -from freida -seq sgroup
+
+ and
+
+ pick -from frated -and -before friday -seq fred
+
+ do exactly the same thing as the five commands listed above. Hence, the
+ `-nozero' option to _p_i_c_k is only useful to manipulate
existing se-
+ quences.
+
+
+9
+
+
+
+
+
+
+
+
+
+ -144-
+
+
+ makes _p_i_c_k define the "select" sequence and otherwise behave
exactly as
+ if there was no profile entry at all.
+
+ _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ The _m_a_r_k command lets the user perform low-level
manipulation of
+ sequences, and also provides a well-needed debug facility to the
+ implementors/developers/maintainers of _M_H (the _M_H-hacks).
In the
+ future, a user-friendly "front-end" for _m_a_r_k will probably be
developed
+ to give the _M_H user a way to take better advantage of the
underlying
+ facilities.
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two kinds of sequences: _p_u_b_l_i_c sequences,
and _p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are accessible
to any _M_H user
+ that can read that folder and are kept in the .mh_sequences file in the
+ folder. _P_r_i_v_a_t_e sequences are accessible only to
the _M_H user that
+ defined those sequences and are kept in the user's _M_H context file.
By
+ default, _p_i_c_k (and _m_a_r_k ) create
_p_u_b_l_i_c sequences if the folder for
+ which the sequences are being defined is writable by the _M_H user.
Oth-
+ erwise, _p_r_i_v_a_t_e sequences are created. This can be
overridden with the
+ `-public' and `-private' switches.
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ In addition to telling an _M_H command to use the messages in
the
+ sequence "seen", as in
+
+ refile seen +old
+
+ it would be useful to be easily able to tell an _M_H command to use
all
+ messages _e_x_c_e_p_t those in the sequence. One way of doing
this would be
+ to use _m_a_r_k and define the sequence explicitly, as in
+
+ mark -delete -zero seen -seq notseen
+
+ which, owing to _m_a_r_k 's cryptic interpretation of `-delete' and
`-zero',
+ defines the sequence "notseen" to be all messages not in the sequence
+ "seen". Naturally, anytime the sequence "seen" is changed, "notseen"
+ will have to be updated. Another way to achieve this is to define the
+ entry "Sequence-Negation:" in the .mh_profile. If the entry was
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command was given "notseen" as a `msg' or
`msgs'
+ argument, it would substitute all messages that are not a member of the
+ sequence "seen". That is,
+
+ refile notseen +new
+
+ does just that. The value of the "Sequence-Negation:" entry in the
+
+
+
+
+
+
+
+
+
+
+
+ -145-
+
+
+ profile can be any string. Hence, experienced users of _M_H do not
use a
+ word, but rather a special character which their shell does not inter-
+ pret (users of the _C_S_h_e_l_l use a single caret or
circumflex (usually
+ shift-6), while users of the Bourne shell use an exclamation-mark).
+ This is because there is nothing to prevent a user of _M_H from
defining a
+ sequence with this string as its prefix, if the string is nothing by
+ letters and digits. Obviously, this could lead to confusing behavior if
+ the "Sequence-Negation:" entry leads _M_H to believe that two
sequences
+ are opposites by virtue of their names differing by the prefix string.
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ Many times users find themselves issuing a series of commands on
+ the same sequences of messages. If the user first defined these mes-
+ sages as a sequence, then considerable typing may be saved. If the user
+ doesn't have this foresight, _M_H provides a handy way of
having _M_H
+ remember the `msgs' or `msg' argument last given to an _M_H command.
If
+ the entry "Previous-Sequence:" is defined in the .mh_profile, then when
+ the command finishes, it will define the sequence(s) named in the value
+ of this entry as being exactly those messages that were specified.
+ Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs' argument to
define
+ the sequence "pseq" as those messages when it finishes. More than one
+ sequence name may be placed in this entry, separated with spaces. The
+ one disadvantage of this approach is that the _M_H progams have to
update
+ the sequence information for the folder each time they run (although
+ most programs read this information, usually only _p_i_c_k and
_m_a_r_k have to
+ write this information out).
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to distinguish between messages which have
+ been previously seen by them. Both _i_n_c and _s_h_o_w
honorthe profile entry
+ "Unseen-Sequence" to support this activity. Whenever _i_n_c
places new
+ messages in a folder, if the entry "Unseen-Sequence" is defined in the
+ .mh_profile, then when the command finishes, _i_n_c will add the
new mes-
+ sages to the sequence(s) named in the value of this entry. Hence, a
+ profile entry of
+
+ Unseen-Sequence: unseen
+
+ directs _i_n_c to add new messages to the sequence "unseen".
Unlike the
+ behavior of the "Previous-Sequence" entry in the profile however, the
+ sequence(s) will not be zero'd.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or _p_r_e_v
) displays a message,
+ they remove those messages from any sequences named by the
+ "Unseen-Sequence" entry in the profile.
+9
+9
+
+
+
+
+
+
+
+
+
+ -146-
+
+
+ _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+ There are a number of interesting advanced facilities for the com-
+ position of outgoing mail.
+
+
+ _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+ The _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands have two switches,
+ `-draftfolder +folder' and `-draftmessage msg'. If
+ `-draftfolder +folder' is used, these commands are directed to construct
+ a draft message in the indicated folder. (The "Draft-Folder:" profile
+ entry may be used to declare a default draft folder for use with
_c_o_m_p,
+ _d_i_s_t, _f_o_r_w, and _r_e_p_l) If `-draftmessage msg' is
not used, it defaults to
+ `new' (unless the user invokes _c_o_m_p with `-use', in which
case the
+ default is `cur'). Hence, the user may have several message composi-
+ tions in progress simultaneously. Now, all of the _M_H tools are
avail-
+ able on each of the user's message drafts (e.g., _s_h_o_w,
_s_c_a_n, _p_i_c_k, and
+ so on). If the folder does not exist, the user is asked if it should be
+ created (just like with _r_e_f_i_l_e ). Also, the last draft
message the user
+ was composing is known as `cur' in the draft folder.
+
+ Furthermore, the _s_e_n_d command has these switches as well.
Hence,
+ from the shell, the user can send off whatever drafts desired using the
+ standard _M_H `msgs' convention with `-draftmessage msgs'. If no
`msgs'
+ are given, it defaults to `cur'.
+
+ In addition, all five programs have a `-nodraftfolder' switch,
+ which undoes the last occurrence of `-draftfolder folder' (useful if the
+ latter occurs in the user's _M_H profile).
+
+ If the user does not give the `-draftfolder +folder' switch, then
+ all these commands act ``normally''. Note that the `-draft' switch to
+ _s_e_n_d and _s_h_o_w still refers to the file called `draft'
in the user's _M_H
+ directory. In the interests of economy of expression, when using
_c_o_m_p
+ or _s_e_n_d, the user needn't prefix the draft `msg' or `msgs' with
`-draft-
+ message'. Both of these commands accept a `file' or `files' argument,
+ and they will, if given `-draftfolder +folder' treat these arguments as
+ `msg' or `msgs'.[2] Hence,
+
+ send -draftf +drafts first
+
+ is the same as
+
+ send -draftf +drafts -draftm first
+
+
+
+9 [2] This may appear to be inconsistent, at first, but it saves a
lot
+ of typing.
+
+
+9
+
+
+
+
+
+
+
+
+
+ -147-
+
+
+ To make all this a bit more clear, here are some examples. Let's
+ assume that the following entries are in the _M_H profile:
+
+ Draft-Folder: +drafts
+ sendf: -draftfolder +drafts
+
+ Furthermore, let's assume that the program _s_e_n_d_f is a
(symbolic) link in
+ the user's $HOME/bin/ directory to _s_e_n_d. Then, any of the
commands
+
+ comp
+ dist
+ forw
+ repl
+
+ constructs the message draft in the `draft' folder using the `new' mes-
+ sage number. Furthermore, they each define `cur' in this folder to be
+ that message draft. If the user were to use the _q_u_i_t option
at `What
+ now?' level, then later on, if no other draft composition was done, the
+ draft could be sent with simply
+
+ sendf
+
+ Or, if more editing was required, the draft could be edited with
+
+ comp -use
+
+ Instead, if other drafts had been composed in the meantime, so that this
+ message draft was no longer known as `cur' in the `draft' folder, then
+ the user could _s_c_a_n the folder to see which message draft in
the folder
+ should be used for editing or sending. Clever users could even employ a
+ back-quoted _p_i_c_k to do the work:
+
+ comp -use `pick +drafts -to bug-mh`
+
+ or
+
+ sendf `pick +drafts -to bug-mh`
+
+ Note that in the _c_o_m_p example, the output from _p_i_c_k
must resolve to a
+ single message draft (it makes no sense to talk about composing two or
+ more drafts with one invocation of _c_o_m_p ). In contrast, in
the _s_e_n_d
+ example, as many message drafts as desired can appear, since
_s_e_n_d
+ doesn't mind sending more than one draft at a time.
+
+ Note that the argument `-draftfolder +folder' is not included in
+ the profile entry for _s_e_n_d, since when _c_o_m_p, et.
al., invoke _s_e_n_d
+ directly, they supply _s_e_n_d with the UNIX pathname of the
message draft,
+ and not a `draftmessage msg' argument. As far as _s_e_n_d is
concerned, a
+ _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+ It is important to realize that _M_H treats the draft folder
like a
+ standard _M_H folder in nearly all respects. There are two
exceptions:
+
+
+
+
+
+
+
+
+
+
+
+ -148-
+
+
+ first_____, under no circumstancs will the `-draftfolder folder'
switch cause
+ the named folder to become the current folder.[3] Second______,
although con-
+ ceptually _s_e_n_d deletes the `msgs' named in the draft folder, it
does not
+ call `delete-prog' to perform the deletion.
+
+
+ _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e _D_r_a_f_t
_E_x_i_s_t_s
+
+ When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands are invoked and the
+ draft you indicated already exists, these programs will prompt the user
+ for a reponse directing the program's action. The prompt is
+
+ Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+ Disposition?
+
+ The appropriate responses and their meanings are:
replace_______: deletes the
+ draft and starts afresh; list____: lists the draft;
refile______: files the draft
+ into a folder and starts afresh; and, quit____: leaves the draft
intact and
+ exits. In addition, if you specified `-draftfolder folder' to the com-
+ mand, then one other response will be accepted: new___: finds a new
draft,
+ just as if `-draftmessage new' had been given. Finally, the
_c_o_m_p com-
+ mand will accept one more response: use___: re-uses the draft, just
as if
+ `-use' had been given.
+
+
+ _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t
_n_o_w? _L_e_v_e_l
+
+ The _p_u_s_h option to the "What now?" query in the
_c_o_m_p, _d_i_s_t, _f_o_r_w,
+ and _r_e_p_l commands, directs the command to _s_e_n_d the
draft in a special
+ detached fashion, with all normal output discarded. If _p_u_s_h is
used and
+ the draft can not be sent, then _M_H will send the user a message,
indi-
+ cating the name of the draft file, and an explanation of the failure.
+
+ The user can also invoke _s_e_n_d from the shell with the
`-push'
+ switch, which makes _s_e_n_d act like it had been _p_u_s_h 'd
by one of the com-
+ position commands.
+
+ By using _p_u_s_h, the user can free the shell to do other
things,
+ because it appears to the shell that the _M_H command has finished.
As a
+ result the shell will immediately prompt for another command, despite
+ the fact that the command is really still running. Note that if the
+
+
+9 [3] Obviously, if the folder appeared in the context of a
standard
+ `+folder' argument to an _M_H program, as in
+
+ scan +drafts
+
+ it might become the current folder, depending on the context changes of
+ the _M_H program in question.
+
+
+9
+
+
+
+
+
+
+
+
+
+ -149-
+
+
+ user indicates that annotations are to be performed (with `-annotate' to
+ _d_i_s_t, _f_o_r_w, or _r_e_p_l), the annotations will be
performed after the mes-
+ sage has been successfully sent. This action will appear to occur asyn-
+ chronously. Obviously, if one of the messages that is to be annotated
+ is removed before the draft has been successfully sent, then when
_M_H
+ tries to make the annotations, it won't be able to do so. In previous
+ versions of _M_H, this resulted in an error message mysteriously
appearing
+ on the user's terminal. In _m_h._5 and later versions, in this
special
+ circumstance, no error will be generated.
+
+ If send is _p_u_s_h 'd, then the `-forward' switch is
examined if a
+ failure notice is generated. If given, then the draft is forwarded with
+ the failure notice sent to the user. This allows rapid
_b_u_r_s_t 'ing of
+ the failure notice to retrieve the unsent draft.
+
+
+ _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w? _L_e_v_e_l
+
+ By default, the message composition programs call a program called
+ _w_h_a_t_n_o_w before the initial draft composition. The
_M_H user can specify
+ any program for this. Following is some information about the default
+ "What now?" level. More detailed information can be found in the
_w_h_a_t_-
+ _n_o_w (1) manual entry.
+
+ When using the _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands at "What now?"
+ level, the _e_d_i_t, _l_i_s_t, _h_e_a_d_e_r_s,
_r_e_f_i_l_e, and (for the _d_i_s_t and _r_e_p_l com-
+ mands) the _d_i_s_p_l_a_y options will pass on any additional
arguments given
+ them to whatever program they invoke.
+
+ In _m_h._1 (the original RAND _M_H ) and _m_h._2 (the
first UCI version of
+ _M_H ), _M_H used a complicated heuristic to determine if the
draft should
+ be deleted or preserved after an unsuccessful edit. In _m_h._3,
_M_H was
+ changed to preserve the draft always, since _c_o_m_p, et. al.,
could usually
+ look at a draft, apply another set of heuristics, and decide if it was
+ important or not. With the notion of a _d_r_a_f_t
_f_o_l_d_e_r, in which one by
+ default gets a `new' message draft, the edit deletion/preservation algo-
+ rithm was re-implemented, to keep the draft folder from being cluttered
+ with aborted edits.
+
+ Also, note that by default, if the draft cannot be successfully
+ sent, these commands return to "What now?" level. But, when
_p_u_s_h is
+ used, this does not happen (obviously). Hence, if these commands were
+ expected to annotate any messages, this will have to be done by hand,
+ later on, with the _a_n_n_o command.
+
+ Finally, if the `-delete' switch is not given to the _q_u_i_t
option,
+ then these commands will inform the user of the name of the unsent draft
+ file.
+
+
+ _D_i_g_e_s_t_s
+9
+9
+
+
+
+
+
+
+
+
+
+ -150-
+
+
+ The _f_o_r_w command has the beginnings of a digestifying
facility,
+ with the `-digest list', `-issue number', and `-volume number' switches.
+
+ If _f_o_r_w is given "list" to the `-digest' switch as the name of
the dis-
+ cussion group, and the `-issue number' switch is not given, then
_f_o_r_w
+ looks for an entry in the user's _M_H context called
"_d_i_g_e_s_t-issue-list"
+ and increments its value to use as the issue number. Similarly, if the
+ `-volume number' switch is not given, then _f_o_r_w
looks for
+ "_d_i_g_e_s_t-volume-list" (but does not increment its value)
to use as the
+ volume number.
+
+ Having calculated the name of the digest and the volume and issue
+ numbers, _f_o_r_w will now process the components file using the
same format
+ string mechanism used by _r_e_p_l. The current `%'-escapes are:
+
+ _e_s_c_a_p_e _t_y_p_e
_s_u_b_s_t_i_t_u_t_i_o_n
+ digest string digest name
+ msg integer issue number
+ cur integer volume number
+
+ In addition, to capture the current date, any of the escapes valid for
+ _d_p (8) are also valid for _f_o_r_w.
+
+ The default components file used by _f_o_r_w when in digest mode is:
+
+ From: %{digest}-Request
+ To: %{digest} Distribution: dist-%{digest};
+ Subject: %{digest} Digest V%(cur) #%(msg)
+ Reply-To: %{digest}
+ --------
+ %{digest} Digest %(weekday{date}), %2(mday{date})
%(month{date}) 19%02(year{date})
+ Volume %(cur) : Issue %(msg)
+
+ Today's Topics:
+
+ Hence, when the `-digest' switch is present, the first step taken by
+ _f_o_r_w is to expand the format strings in the component file.
The next
+ step is to compose the draft using the standard digest encapsulation
+ algorithm (even putting an "End of list Digest" trailer in the draft).
+ Once the draft is composed by _f_o_r_w, _f_o_r_w writes out the
volume and issue
+ profile entries for the digest, and then invokes the editor.
+
+ Naturally, when composing the draft, _f_o_r_w will
honor the
+ `-filter filterfile' switch, which is given to _m_h_l to filter
each mes-
+ sage being forwarded prior to encapsulation in the draft. A good filter
+ file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+ -151-
+
+
+ width=80,overflowoffset=10
+ leftadjust,compress,compwidth=9
+ Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+9 _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+ There are two interesting facilities for manipulating folders:
+ relative folder addressing, which allows a user to shorten the typing of
+ long folder names; and the folder-stack, which permits a user to keep a
+ stack of current folders.
+
+
+ _R_e_l_a_t_i_v_e _F_o_l_d_e_r
_A_d_d_r_e_s_s_i_n_g
+
+ By default, when `+folder' is given, and the folder name is not
+ absolute (does not start with /, ./, or ../), then the UNIX pathname of
+ the folder is interpreted relative to the user's _M_H directory.
Although
+ this mechanism works fine for top-level folders and their immediate
+ sub-folders, once the depth of the sub-folder tree grows, it becomes
+ rather unwieldly:
+
+ scan +mh/mh.4/draft/flames
+
+ is a lot of typing. _M_H can't do anything if the current folder
was
+ "+inbox", but if the current folder was, say, "+mh/mh.4/draft", _M_H
has a
+ short-hand notation to reference a sub-folder of the current folder.
+ Using the address@hidden' notation, the _M_H user can direct any
_M_H program
+ which expects a `+folder' argument to look for the folder relative to
+ the current folder instead of the user's _M_H directory. Hence,
if the
+ current folder _w_a_s "+mh/mh.4/draft", then
+
+ scan @flames
+
+ would do the trick handily. In addition, if the current folder
_w_a_s
+ "+mh/mh.4/draft",
+
+ scan @../pick
+
+ would scan the folder "+mh/mh.4/pick", since, in the UNIX fashion, it
+ references the folder "pick" which is a sub-folder of the folder that is
+ the parent of the current folder. Since most advanced _M_H users
seem to
+ exhibit a large degree of locality in referencing folders when they pro-
+ cess mail, this convention should receive a wide range of uses.
+
+
+
+9
+
+
+
+
+
+
+
+
+
+ -152-
+
+
+ _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+ The _f_o_l_d_e_r-_s_t_a_c_k mechanism in _M_H gives
the _M_H user a facility simi-
+ lar to the _C_S_h_e_l_l 's directory-stack. Simply put,
+
+ folder -push +foo
+
+ makes "foo" the current folder, saving the folder that was previously
+ the current folder on the _f_o_l_d_e_r-_s_t_a_c_k. As
expected,
+
+ folder -pop
+
+ takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and makes it
the current folder. Each
+ of these switches lists the _f_o_l_d_e_r-_s_t_a_c_k when
they execute. It is sim-
+ ple to write a _p_u_s_h_f command as a shell script. It's one
line:
+
+ exec folder -push $@
+
+ Probably a better way is to link _f_o_l_d_e_r to the
$HOME/bin/ directory
+ under the name of _p_u_s_h_f and then add the entry
+
+ pushf: -push
+
+ to the .mh_profile.
+
+ The manual page for _f_o_l_d_e_r discusses the analogy
between the _C_S_h_e_l_l
+ directory stack commands and the switches in _f_o_l_d_e_r which
manipulate the
+ _f_o_l_d_e_r-_s_t_a_c_k. The _f_o_l_d_e_r command
uses the context entry `Folder-Stack:'
+ to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix A
+ _C_O_M_M_A_N_D _S_U_M_M_A_R_Y
+
+
+
+9 ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ anno [+folder] [msgs] [-component field] [-inplace] [-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet] [-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c] [-rcfile
rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+ [-host host] [-help]
+
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet] [-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+ [-noheader] [-pack] [-nopack] [-recurse] [-norecurse] [-total]
+ [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+ [-pop] [-help]
+
+ folders
+
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace] [-noinplace]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w] [-help]
+
+
+
+
+
+
+
+9 -153-
+
+
+
+
+
+
+
+
+
+
+
+
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-file name] [-form formatfile]
+ [-format string] [-silent] [-nosilent] [-truncate]
+ [-notruncate] [-width columns] [-host host] [-user user]
+ [-pack file] [-nopack] [-rpop] [-norpop] [-help]
+
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete] [-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc] [files ...]
+ [-help]
+
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ mhpath [+folder] [msgs] [-help]
+
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [-host host] [-user user] [-rpop]
+ [-norpop] [users ...] [-help]
+
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur] [file]
+ [-help]
+
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+ packf [+folder] [msgs] [-file name] [-help]
+
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-after date]
+ [-before date] [-datefield field] [-sequence name ...]
+ [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+ [-help]
+
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c] [-help]
+
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend] [-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero] [-nozero]
+ [-help]
+
+
+
+
+
+9
+9 -154-
+
+
+
+
+
+
+
+
+
+
+
+
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve] [-nopreserve]
+ [-src +folder] [-file file] +folder ... [-help]
+
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form formfile]
+ [-inplace] [-noinplace] [-query] [-noquery]
+ [-whatnowproc program] [-nowhatnowproc] [-width columns]
+ [-help]
+
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ rmm [+folder] [msgs] [-help]
+
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-msgid] [-nomsgid] [-push] [-nopush] [-verbose] [-noverbose]
+ [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ whatnow [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file] [-help]
+
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder]
+ [file] [-help]
+
+ /usr/local/lib/mh/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+
+
+
+
+9
+9 -155-
+
+
+
+
+
+
+
+
+
+
+
+
+ /usr/local/lib/mh/conflict [-mail name] [-search directory]
+ [aliasfiles ...] [-help]
+
+ /usr/local/lib/mh/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+ /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+ [-verbose] [-noverbose] [-watch] [-nowatch] [-width columns]
+ file [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 -156-
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix B
+ _M_E_S_S_A_G_E _N_A_M_E _B_N_F
+
+
+
+9
+ msgs := msgspec |
+ msgs msgspec
+
+ msgspec := msg |
+ msg-range |
+ msg-sequence |
+ user-defined-sequence
+
+ msg := msg-name |
+ <number>
+
+ msg-name := "first" |
+ "last" |
+ "cur" |
+ "." |
+ "next" |
+ "prev"
+
+ msg-range := msg"-"msg |
+ "all"
+
+ msg-sequence := msg":"signed-number
+
+ signed-number := "+"<number> |
+ "-"<number> |
+ <number>
+
+ user-defined-sequence := <alpha> |
+ <alpha><alphanumeric>*
+
+
+ Where <number> is a decimal number greater than zero.
+
+ Msg-range specifies all of the messages in the given range and must not
+ be empty.
+
+ Msg-sequence specifies up to <number> of messages, beginning with "msg"
+ (in the case of first, cur, next, or <number>), or ending with "msg" (in
+ the case of prev or last). +<number> forces "starting with msg", and
+ -<number> forces "ending with number". In all cases, "msg" must exist.
+
+ User-defined sequences are defined and manipulated with the
_p_i_c_k and
+ _m_a_r_k commands.
+
+
+
+9 -157-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_F_E_R_E_N_C_E_S
+
+
+
+ 1. Crocker, D. H., J. J. Vittal, K. T. Pogran, and D. A. Henderson,
+ Jr., "Standard for the Format of ARPA Network Text Messages,"
+ _R_F_C_7_3_3, November 1977.
+
+ 2. Thompson, K., and D. M. Ritchie, "The UNIX Time-sharing System,"
+ _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e
_A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+ 3. McCauley, E. J., and P. J. Drongowski, "KSOS-The Design of a Secure
+ Operating System," _A_F_I_P_S _C_o_n_f_e_r_e_n_c_e
_P_r_o_c_e_e_d_i_n_g_s, National Computer
+ Conference, Vol. 48, 1979, pp. 345-353.
+
+ 4. Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d
_F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l
_M_e_s_-
+ _s_a_g_e _S_y_s_t_e_m, The RAND Corporation, R-2134-ARPA,
December 1977.
+
+ 5. Thompson, K., and D. M. Ritchie, _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th ed.,
+ Western Electric Company, May 1975 (available only to UNIX licen-
+ sees).
+
+ 6. Crocker, D. H., "Standard for the Format of ARPA Internet Text Mes-
+ sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 -158-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 -i-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_A_D _T_H_I_S
+
+
+
+
+ Although the _M_H system was originally developed by the RAND
Cor-
+ poration, and is now in the public domain, the RAND Corporation assumes
+ no responsibility for _M_H or this particular version of _M_H.
+
+ In addition, the Regents of the University of California issue the
+ following disclaimer in regard to the UCI version of _M_H:
+
+ "Although each program has been tested by its contributor, no war-
+ ranty, express or implied, is made by the contributor or the
+ University of California, as to the accuracy and functioning of the
+ program and related program material, nor shall the fact of distri-
+ bution constitute any such warranty, and no responsibility is
+ assumed by the contributor or the University of California in con-
+ nection herewith."
+
+ This version of _M_H is in the public domain, and as such, there
are
+ no real restrictions on its use. The _M_H source code and
documentation
+ have no licensing restrictions whatsoever. As a courtesy, the authors
+ ask only that you provide appropriate credit to the RAND Corporation and
+ the University of California for having developed the software.
+
+ _M_H is a software package that is supported neither by the RAND
Cor-
+ poration nor the University of California. However, since we do use the
+ software ourselves and plan to continue using (and improving) _M_H,
bug
+ reports and their associated fixes should be reported back to us so that
+ we may include them in future releases. The current computer mailbox
+ for _M_H is address@hidden (in the ARPA Internet), and
+ ...!ucbvax!ucivax!bug-mh (UUCP). Presently, there are two Internet dis-
+ cussion groups, address@hidden and address@hidden
+ MH-Workers is for people discussing code changes to _M_H. MH-Users
is for
+ general discussion about how to use _M_H. MH-Users is
bi-directionally
+ gatewayed into USENET as comp.mail.mh.
+
+ _H_O_W _T_O _G_E_T _M_H
+
+ Since you probably already have _M_H, you may not need to read
this
+ unless you suspect you have an old version. There are two ways to get
+ the latest release:
+
+ 1. If you can FTP to the ARPA Internet, use anonymous FTP to
+ ics.uci.edu [128.195.1.1] and retrieve the file pub/mh/mh-6.7.tar.Z.
+ This is a tar image after being run through the compress program
+ (approximately 1.5MB). There should also be a README file in that
+ directory which tells what the current release of _M_H is, and how to
get
+ updates.
+
+9
+9 -i-
+
+
+
+
+
+
+
+
+
+ -ii-
+
+
+ This tar file is also available on louie.udel.edu [128.175.1.3] in
+ portal/mh-6.7.tar.Z. You may also find MH on various other hosts; to
+ make sure you get the latest version and don't waste your time re-fixing
+ bugs, it's best to get it from either ics.uci.edu or louie.udel.edu.
+
+ 2. You can send $75 US to the address below. This covers the cost
+ of a 6250 BPI 9-track magtape, handling, and shipping. In addition,
+ you'll get a laser-printed hard-copy of the entire MH documentation set.
+ Be sure to include your USPS address with your check. Checks must be
+ drawn on U.S. funds and should be made payable to:
+
+ Regents of the University of California
+
+ The distribution address is:
+
+ Computing Support Group
+ Attn: MH distribution
+ Department of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92717
+
+ 714/856-7554
+
+ If you just want the hard-copies of the documentation, you still
+ have to pay the $75. The tar image has the documentation source (the
+ manual is in roff format, but the rest are in TeX format). Postscript
+ formatted versions of the TeX papers are available, as are crude tty-
+ conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+ _F_O_R_E_W_O_R_D
+
+
+
+
+ This document describes the RAND _M_H Message Handling System.
Its
+ primary purpose is to serve as a user's manual. It has been heavily
+ based on a previous version of the manual, prepared by Bruce Borden,
+ Stockton Gaines, and Norman Shapiro.
+
+ _M_H is a particularly novel system, and thus it is often more
prone
+ to change than other pieces of production software. As such, some
+ specific points in this manual may not be correct in the future. In all
+ cases, the on-line sections of this manual, available through the
+ UNIX[1] _m_a_n command, should present the most current information.
+
+ When reading this document as a user's manual, certain sections are
+ more interesting than others. The Preface and Summary are not particu-
+ larly interesting to those interested in learning _M_H. The
Introduction
+ is slightly more interesting, as it touches upon the organization of the
+ remainder of this document. The most useful sections are the Overview,
+ Tutorial, and Detailed Description. The Overview should be read by all
+ _M_H users, regardless of their expertise (beginning, novice,
advanced, or
+ hacker). The Tutorial should be read by all beginning and novice
_M_H
+ users, as it presents a nice description of the _M_H system. The
Detailed
+ Description should be read by the day-to-day user of _M_H, as it
spells
+ out all of the realities of the _M_H system. The Advanced Features
sec-
+ tion discusses some powerful _M_H capabilities for advanced users.
Appen-
+ dix A is particularly useful for novices, as it summarizes the invoca-
+ tion syntax of all the _M_H commands.
+
+ There are also several other documents which may be useful to you:
+ _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is
a tutorial for
+ _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I
_B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+ describes the BBoards handling under _M_H; _M_H._5: _H_o_w
_t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+ _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l _g_e_t
_s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which was presented at
+ the 1985 Summer Usenix Conference and Exhibition in Portland, Oregon;
+ _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r
_A_g_e_n_t, which has been accepted for publication
+ by Computer Networks; _M_Z_n_e_t: _M_a_i_l
_S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l
_M_i_c_r_o-_C_o_m_p_u_t_e_r
+ _S_y_s_t_e_m_s, which was presented at the First International
Symposium on
+ Computer Message Systems in Nottingham, U.K.; and,
_D_e_s_i_g_n _o_f _t_h_e _T_T_I
+ _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d _M_a_i_l
_A_g_e_n_t, which describes a proprietary "trusted"
+ mail system built on _M_H. There are also documents, mostly
specific to
+ U.C. Irvine which you may find interesting: _M_H _f_o_r
_B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+ _M_M _U_s_e_r_s. All of these documents exist in the _m_h._6
distribution sent to
+ your site. There's also a document, _C_h_a_n_g_e_s _t_o
_t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m: _M_H._6, which describes
user-visible changes made to _M_H
+
+
+9 [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+9 -iii-
+
+
+
+
+
+
+
+
+
+ -iv-
+
+
+ since the last major release.
+
+ This manual is very large, as it describes a large, powerful system
+ in gruesome detail. The important thing to remember is:
+
+
+ _D_O_N'_T _P_A_N_I_C[_2]
+
+
+ As explained in the tutorial, you really need to know only 5 commands to
+ handle most of your mail.
+
+ Very advanced users may wish to consult _T_h_e _R_A_N_D
_M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m:
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also
present in the _m_h._6
+ distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+9
+
+
+
+
+
+
+
+
+
+
+
+
+
_A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+ The _M_H system described herein is based on the original
RAND _M_H
+ system. It has been extensively developed (perhaps too much so) by
+ Marshall T. Rose and John L. Romine at the University of California,
+ Irvine. Einar A. Stefferud, Jerry N. Sweet, and Terry P. Domae provided
+ numerous suggestions to improve the UCI version of _M_H. Of
course, a
+ large number of people have helped _M_H along. The list of
``_M_H immor-
+ tals'' is too long to list here. However, Van Jacobson deserves a spe-
+ cial acknowledgement for his tireless work in improving the performance
+ of _M_H. Some programs have been speeded-up by a factor of 10 or 20.
All
+ of users of _M_H, everywhere, owe a special thanks to Van. For
this
+ release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes and other
changes. A handful
+ of courageous _M_H-_W_o_r_k_e_r_s volunteered to beta-test
these changes; their
+ help is particularly appreciated.
+
+ This manual is based on the original _M_H manual written at
RAND by
+ Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 -v-
+
+
+
+
+
+
+
+
+
+
+
+
+ _P_R_E_F_A_C_E
+
+
+
+
+ This report describes a system for dealing with messages transmit-
+ ted on a computer. Such messages might originate with other users of
+ the same computer or might come from an outside source through a network
+ to which the user's computer is connected. Such computer-based message
+ systems are becoming increasingly widely used, both within and outside
+ the Department of Defense.
+
+ The message handling system _M_H was developed for two reasons.
One
+ was to investigate some research ideas concerning how a message system
+ might take advantage of the architecture of the UNIX time-sharing
+ operating system for Digital Equipment Corporation PDP-11 and VAX com-
+ puters, and the special features of UNIX's command-level interface with
+ the user (the "shell"). The other reason was to provide a better and
+ more adaptable base than that of conventional designs on which to build
+ a command and control message system. The effort has succeeded in both
+ regards, although this report mainly describes the message system itself
+ and how it fits in with UNIX.
+
+ The present report should be of interest to three groups of
+ readers. First, it is a complete reference manual for the users of
_M_H.
+ Second, it should be of interest to those who have a general knowledge
+ of computer-based message systems, both in civilian and military appli-
+ cations. Finally, it should be of interest to those who build large
+ subsystems that interface with users, since it illustrates a new
+ approach to such interfaces.
+
+ The original _M_H system was developed by Bruce Borden,
using an
+ approach suggested by Stockton Gaines and Norman Shapiro. Valuable
+ assistance was provided by Phyllis Kantar in the later stages of the
+ system's implementation. Several colleagues contributed to the ideas
+ included in this system, particularly Robert Anderson and David Crocker.
+ In addition, valuable experience in message systems, and a valuable
+ source of ideas, was available to us in the form of a previous message
+ system for UNIX called MS, designed at RAND by David Crocker.
+
+ This report was originally prepared as part of the RAND project
+ entitled "Data Automation Research", sponsored by Project AIR FORCE.
+
+
+
+
+
+
+
+
+
+9
+9 -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+ _S_U_M_M_A_R_Y
+
+
+
+
+ Electronic communication of text messages is becoming commonplace.
+ Computer-based message systems-software packages that provide tools for
+ dealing with messages-are used in many contexts. In particular, message
+ systems are becoming increasingly important in command and control and
+ intelligence applications.
+
+ This report describes a message handling system called _M_H.
This
+ system provides the user with tools to compose, send, receive, store,
+ retrieve, forward, and reply to messages. _M_H has been built on the
UNIX
+ time-sharing system, a popular operating system developed for the DEC
+ PDP-11 and VAX classes of computers.
+
+ A complete description of _M_H is given for users of the system.
For
+ those who do not intend to use the system, this description gives a gen-
+ eral idea of what a message system is like. The system involves some
+ new ideas about how large subsystems can be constructed.
+
+ The interesting and unusual features of _M_H include the
following:
+ The user command interface to _M_H is the UNIX "shell" (the standard
UNIX
+ command interpreter). Each separable component of message handling,
+ such as message composition or message display, is a separate command.
+ Each program is driven from and updates a private user environment,
+ which is stored as a file between program invocations. This private
+ environment also contains information to "custom tailor" _M_H to
the
+ individual's tastes. _M_H stores each message as a separate file
under
+ UNIX, and it utilizes the tree-structured UNIX file system to organize
+ groups of files within separate directories or "folders". All of the
+ UNIX facilities for dealing with files and directories, such as renam-
+ ing, copying, deleting, cataloging, off-line printing, etc., are appli-
+ cable to messages and directories of messages (folders). Thus, impor-
+ tant capabilities needed in a message system are available in _M_H
without
+ the need (often seen in other message systems) for code that duplicates
+ the facilities of the supporting operating system. It also allows users
+ familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9 -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+ _C_O_N_T_E_N_T_S
+
+
+
+
+ READ THIS ......................................................... i
+
+ FOREWORD .......................................................... iii
+
+ ACKNOWLEDGMENTS ................................................... v
+
+ PREFACE ........................................................... vi
+
+ SUMMARY ........................................................... vii
+
+ Section
+
+ 1. INTRODUCTION ............................................... 1
+
+ 2. OVERVIEW ................................................... 4
+
+ 3. TUTORIAL ................................................... 7
+
+ 4. DETAILED DESCRIPTION ....................................... 10
+9 THE USER PROFILE .............................................
10
+9 MESSAGE NAMING ...............................................
13
+9 OTHER MH CONVENTIONS .........................................
14
+9 MH COMMANDS ..................................................
16
+ ALI ....................................................... 17
+ ANNO ...................................................... 19
+ BBC ....................................................... 21
+ BBOARDS ................................................... 24
+ BURST ..................................................... 26
+ COMP ...................................................... 28
+ DIST ...................................................... 30
+ FOLDER .................................................... 33
+ FORW ...................................................... 36
+ INC ....................................................... 40
+ MARK ...................................................... 43
+ MHL ....................................................... 45
+ MHMAIL .................................................... 50
+ MHOOK ..................................................... 52
+ MHPATH .................................................... 54
+ MSGCHK .................................................... 57
+ MSH ....................................................... 59
+ NEXT ...................................................... 63
+ PACKF ..................................................... 64
+ PICK ...................................................... 65
+ PREV ...................................................... 69
+ PROMPTER .................................................. 70
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RCVSTORE .................................................. 73
+ REFILE .................................................... 75
+ REPL ...................................................... 77
+ RMF ....................................................... 81
+ RMM ....................................................... 83
+ SCAN ...................................................... 85
+ SEND ...................................................... 88
+ SHOW ...................................................... 91
+ SORTM ..................................................... 94
+ VMH ....................................................... 96
+ WHATNOW ................................................... 98
+ WHOM ...................................................... 100
+9 MORE DETAILS .................................................
102
+ MH-ALIAS .................................................. 103
+ MH-FORMAT ................................................. 107
+ MH-MAIL ................................................... 116
+ MH-PROFILE ................................................ 120
+ MH-SEQUENCE ............................................... 128
+ AP ........................................................ 132
+ CONFLICT .................................................. 134
+ DP ........................................................ 136
+ INSTALL-MH ................................................ 138
+ POST ...................................................... 139
+
+ 5. REPORTING PROBLEMS ......................................... 141
+
+ 6. ADVANCED FEATURES .......................................... 142
+9 USER-DEFINED SEQUENCES .......................................
142
+ Pick and User-Defined Sequences ........................... 142
+ Mark and User-Defined Sequences ........................... 144
+ Public and Private User-Defined Sequences ................. 144
+ Sequence Negation ......................................... 144
+ The Previous Sequence ..................................... 145
+ The Unseen Sequence ....................................... 145
+9 COMPOSITION OF MAIL ..........................................
146
+ The Draft Folder .......................................... 146
+ What Happens if the Draft Exists .......................... 148
+ The Push Option at What now? Level ........................ 148
+ Options at What now? Level ................................ 149
+ Digests ................................................... 150
+9 FOLDER HANDLING ..............................................
151
+ Relative Folder Addressing ................................ 151
+ The Folder-Stack .......................................... 152
+
+ Appendix
+ A. Command Summary ............................................ 153
+ B. Message Name BNF ........................................... 157
+
+ REFERENCES ........................................................ 158
+9
+9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9 THE RAND MH
+
+9 MESSAGE HANDLING
+
+9 SYSTEM:
+
+9 USER'S MANUAL
+
+
+
+
+
+
+ UCI Version
+
+
+
+
+
+ Marshall T. Rose
+
+ John L. Romine
+
+
+
+
+ Based on the original manual by
+
+ Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+ February 1, 1991
+
+ 6.7.1a #6[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+9
+9
+
+
+
+
+
diff --git a/docs/historical/MH-19921214.pdf b/docs/historical/MH-19921214.pdf
new file mode 100644
index 0000000..431c46b
Binary files /dev/null and b/docs/historical/MH-19921214.pdf differ
diff --git a/docs/historical/MH-19921214.txt b/docs/historical/MH-19921214.txt
new file mode 100644
index 0000000..2ee97f5
--- /dev/null
+++ b/docs/historical/MH-19921214.txt
@@ -0,0 +1,13134 @@
+
+
+
+
+
+
+
+
+ _d_i_s_c_a_r_d _t_h_i_s
_p_a_g_e
+
+
+
+
+ The RAND _M_H
+ Message Handling System:
+ User's Manual
+
+ UCI Version
+
+
+ December 14, 1992
+ 6.6 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _1.
_I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+ Although people can travel cross-country in hours and
can reach
+ others by telephone in seconds, communications still depend
heavily upon
+ paper, most of which is distributed through the mails.
+
+ There are several major reasons for this continued
dependence on
+ written documents. First, a written document may be
proofread and
+ corrected prior to its distribution, giving the author
complete control
+ over his words. Thus, a written document is better than
a telephone
+ conversation in this respect. Second, a carefully written
document is
+ far less likely to be misinterpreted or poorly translated
than a phone
+ conversation. Third, a signature offers reasonable
verification of
+ authorship, which cannot be provided with media such as
telegrams.
+
+ However, the need for fast____, accurate, and
reproducible document
+ distribution is obvious. One solution in widespread use is
the telefax.
+ Another that is rapidly gaining popularity is electronic
mail. Elec-
+ tronic mail is similar to telefax in that the data to be
sent are digi-
+ tized, transmitted via phone lines, and turned back into a
document at
+ the receiver. The advantage of electronic mail is in its
compression
+ factor. Whereas a telefax must scan a page in very fine
lines and send
+ all of the black and white information, electronic mail
assigns charac-
+ ters fixed codes which can be transmitted as a few bits of
information.
+ Telefax presently has the advantage of being able to
transmit an arbi-
+ trary page, including pictures, but electronic mail is
beginning to deal
+ with this problem. Electronic mail also integrates well
with current
+ directions in office automation, allowing documents
prepared with
+ sophisticated equipment at one site to be quickly
transferred and
+ printed at another site.
+
+ Currently, most electronic mail is intraorganizational,
with mail
+ transfer remaining within one computer. As computer
networking becomes
+ more common, however, it is becoming more feasible to
communicate with
+ anyone whose computer can be linked to your own via a network.
+
+ The pioneering efforts on general-purpose electronic
mail were by
+ organizations using the DoD ARPAnet[1]. The capability to
send messages
+ between computers existed before the ARPAnet was developed,
but it was
+ used only in limited ways. With the advent of the ARPAnet,
tools began
+ to be developed which made it convenient for individuals or
organiza-
+ tions to distribute messages over broad geographic areas,
using diverse
+ computer facilities. The interest and activity in message
systems has
+ now reached such proportions that steps have been taken
within the DoD
+ to coordinate and unify the development of military
message systems.
+ The use of electronic mail is expected to increase
dramatically in the
+ next few years. The utility of such systems in the command
and control
+ and intelligence environments is clear, and applications in
these areas
+
+
+
+
+
+
+
+
+
+
+
+ -2-
+
+
+ will probably lead the way. As the costs for sending and
handling elec-
+ tronic messages continue their rapid decrease, such uses can
be expected
+ to spread rapidly into other areas and, of course, will not
be limited
+ to the DoD.
+
+ A message system provides tools that help users
(individuals or
+ organizations) deal with messages in various ways.
Messages must be
+ composed, sent, received, stored, retrieved, forwarded, and
replied to.
+ Today's best interactive computer systems provide a
variety of word-
+ processing and information handling capabilities. The
message handling
+ facilities should be well integrated with the rest of the
system, so as
+ to be a graceful extension of overall system capability.
+
+ The message system described in this report, _M_H,
provides most of
+ the features that can be found in other message systems and
also incor-
+ porates some new ones. It has been built on the UNIX
time-sharing sys-
+ tem[2], a popular operating system for the DEC PDP-11[1]
and VAX-11
+ classes of computers. A "secure" operating system similar
to UNIX is
+ currently being developed[3], and that system will also run
_M_H.
+
+ This report provides a complete description of _M_H
and thus may
+ serve as a user's manual, although parts of the report
will be of
+ interest to non-users as well. Sections 2 and 3, the
Overview and
+ Tutorial, present the key ideas of _M_H and will give
those not familiar
+ with message systems an idea of what such systems are like.
+
+ _M_H consists of a set of commands which use some
special files and
+ conventions. The final section is divided into three parts.
The first
+ part covers the information a user needs to know in addition
to the com-
+ mands. Then, each of the _M_H commands is described in
detail. Finally,
+ other obscure details are revealed. A summary of the
commands is given
+ in Appendix A, and the syntax of message sequences is given
in Appendix
+ B.
+
+ A novel approach has been taken in the design of
_M_H. Instead of
+ creating a large subsystem that appears as a single command
to the user
+ (such as MS[4]), _M_H is a collection of separate commands
which are run
+ as separate programs. The file and directory system of
UNIX are used
+ directly. Messages are stored as individual files
(datasets), and col-
+ lections of them are grouped into directories. In contrast,
most other
+ message systems store messages in a complicated data
structure within a
+ monolithic file. With the _M_H approach, UNIX commands can
be interleaved
+ with commands invoking the functions of the message
handler. Con-
+ versely, existing UNIX commands can be used in connection
with messages.
+ For example, all the usual UNIX editing, text-formatting,
and printing
+ facilities can be applied directly to individual messages.
MH, there-
+ fore, consists of a relatively small amount of new code; it
makes exten-
+ sive use of other UNIX software to provide the
capabilities found in
+
+
+ [1] PDP and VAX are trademarks of Digital Equipment
Corporation.
+
+
+
+
+
+
+
+
+
+
+
+
+ -3-
+
+
+ other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _2. _O_V_E_R_V_I_E_W
+
+
+
+
+
+ There are three main aspects of _M_H : the way
messages are
+ stored (the message database), the user's profile (which
directs how
+ certain actions of the message handler take place), and the
commands for
+ dealing with messages.
+
+ Under _M_H, each message is stored as a separate file.
A user can
+ take any action with a message that he could with an
ordinary file in
+ UNIX. A UNIX directory in which messages are stored is
called a folder.
+ Each folder contains some standard entries to support
the message-
+ handling functions. The messages in a folder have
numerical names.
+ These folders (directories) are entries in a particular
directory path,
+ described in the user profile, through which _M_H can find
message fold-
+ ers. Using the UNIX "link" facility, it is possible for
one copy of a
+ message to be "filed" in more than one folder, providing a
message index
+ facility. Also, using the UNIX tree-structured file system,
it is pos-
+ sible to have a folder within a folder, nested arbitrarily
deep, and
+ have the full power of the _M_H commands available.
+
+ Each user of _M_H has a user profile, a file in his
$HOME (initial
+ login) directory called ._m_h__p_r_o_f_i_l_e.
This profile contains several
+ pieces of information used by the _M_H commands: a path
name to the direc-
+ tory that contains the message folders and parameters
that tailor _M_H
+ commands to the individual user's requirements. There is
also another
+ file, called the user context, which contains information
concerning
+ which folder the user last referenced (the "current" folder).
It also
+ contains most of the necessary state information concerning
how the user
+ is dealing with his messages, enabling _M_H to be
implemented as a set of
+ individual UNIX commands, in contrast to the usual approach
of a monol-
+ ithic subsystem.
+
+ In _M_H, incoming mail is appended to the end of a
file in a system
+ spooling area for the user. This area is called the mail
drop direc-
+ tory, and the file is called the user's mail drop. Normally
when the
+ user logins in, s/he is informed of new mail (or the _M_H
program _m_s_g_c_h_k
+ may be run). The user adds the new messages to his/her
collection of _M_H
+ messages by invoking the command _i_n_c. The
_i_n_c (incorporate) command
+ adds the new messages to a folder called "inbox", assigning
them names
+ which are consecutive integers starting with the next
highest integer
+ available in inbox. _i_n_c also produces a _s_c_a_n
summary of the messages
+ thus incorporated. A folder can be compacted into a
single file, for
+ easy storage, by using the _p_a_c_k_f command. Also,
messages within a
+ folder can be sorted by date and time with the
_s_o_r_t_m command.
+
+
+ There are four commands for examining the messages in
a folder:
+ _s_h_o_w, _p_r_e_v, _n_e_x_t, and
_s_c_a_n. The _s_h_o_w command displays a message in a
+
+ -4-
+
+
+
+
+
+
+
+
+
+ -5-
+
+
+ folder, _p_r_e_v displays the message preceding the
current message, and
+ _n_e_x_t displays the message following the current
message. _M_H lets the
+ user choose the program that displays individual messages.
A special
+ program, _m_h_l, can be used to display messages
according to the user's
+ preferences. The _s_c_a_n command summarizes the
messages in a folder, nor-
+ mally producing one line per message, showing who the
message is from,
+ the date, the subject, etc.
+
+ The user may move a message from one folder to another
with the
+ command _r_e_f_i_l_e. Messages may be removed from a
folder by means of the
+ command _r_m_m. In addition, a user may query what the
current folder is
+ and may specify that a new folder become the current folder,
through the
+ command _f_o_l_d_e_r. All folders may be summarized
with the _f_o_l_d_e_r_s command.
+ A message folder (or subfolder) may be removed by means of
the command
+ _r_m_f.
+
+ A set of messages based on content may be selected by
use of the
+ command _p_i_c_k. This command searches through
messages in a folder and
+ selects those that match a given set of criteria. These
messages are
+ then bound to a "sequence" name for use with other _M_H
commands. The
+ _m_a_r_k command manipulates these sequences.
+
+ There are five commands enabling the user to create
new messages
+ and send them: _c_o_m_p, _d_i_s_t, _f_o_r_w,
_r_e_p_l, and _s_e_n_d. The _c_o_m_p command pro-
+ vides the facility for the user to compose a new message;
_d_i_s_t redistri-
+ butes mail to additional addressees; _f_o_r_w enables
the user to forward
+ messages; and _r_e_p_l facilitates the generation of a
reply to an incoming
+ message. The last three commands may optionally annotate
the original
+ message. Messages may be arbitrarily annotated with the
_a_n_n_o command.
+ Once a draft has been constructed by one of the four above
composition
+ programs, a user-specifiable program is run to query the user
as to the
+ disposition of the draft prior to sending. _M_H provides
the simple _w_h_a_t_-
+ _n_o_w program to start users off. If a message is not
sent directly by
+ one of these commands, it may be sent at a later time using
the command
+ _s_e_n_d. _M_H allows the use of any UNIX editor when
composing a message.
+ For rapid entry, a special editor, _p_r_o_m_p_t_e_r,
is provided. For programs,
+ a special mail-sending program, _m_h_m_a_i_l, is
provided.
+
+ _M_H supports a personal aliasing facility which
gives users the
+ capability to considerably shorten address typein and use
meaningful
+ names for addresses. The _a_l_i program can be used to
query _M_H as to the
+ expansion of a list of aliases. After composing a message,
but prior to
+ sending, the _w_h_o_m command can be used to determine
exactly who a message
+ would go to.
+
+ _M_H provides a natural interface for telling the
user's shell the
+ names of _M_H messages and folders. The
_m_h_p_a_t_h program achieves this
+ capability.
+
+ Finally, _M_H supports the UCI BBoards facility.
_b_b_c can be used to
+ query the status of a group of BBoards, while _m_s_h
can be used to read
+ them. The _b_u_r_s_t command can be used to "shred"
digests of messages into
+
+
+
+
+
+
+
+
+
+
+
+ -6-
+
+
+ individual messages.
+
+ All of the elements summarized above are described in
more detail
+ in the following sections. Many of the normal facilities
of UNIX pro-
+ vide additional capabilities for dealing with messages in
various ways.
+ For example, it is possible to print messages on the
line-printer
+ without requiring any additional code within _M_H . Using
standard UNIX
+ facilities, any terminal output can be redirected to a file
for repeated
+ or future viewing. In general, the flexibility and
capabilities of the
+ UNIX interface with the user are preserved as a result of
the integra-
+ tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _3. _T_U_T_O_R_I_A_L
+
+
+
+
+
+ This tutorial provides a brief introduction to the
_M_H commands. It
+ should be sufficient to allow the user to read his mail, do
some simple
+ manipulations of it, and create and send messages.
+
+ A message has two major pieces: the header and the
body. The body
+ consists of the text of the message (whatever you care to
type in). It
+ follows the header and is separated from it by an empty line.
(When you
+ compose a message, the form that appears on your terminal
shows a line
+ of dashes after the header. This is for convenience and is
replaced by
+ an empty line when the message is sent.) The header is
composed of
+ several components, including the subject of the message and
the person
+ to whom it is addressed. Each component starts with a name
and a colon;
+ components must not start with a blank. The text of the
component may
+ take more than one line, but each continuation line must
start with a
+ blank. Messages typically have "To:", "cc:", and "Subject:"
components.
+ When composing a message, you should include the "To:" and
"Subject:"
+ components; the "cc:" (for people you want to send copies
to) is not
+ necessary.
+
+ The basic _M_H commands are _i_n_c, _s_c_a_n,
_s_h_o_w, _n_e_x_t, _p_r_e_v, _r_m_m, _c_o_m_p,
+ and _r_e_p_l. These are described below.
+
+ _i_n_c
+
+ When you get the message "You have mail", type the
command _i_n_c.
+ You will get a "scan listing" such as:
+
+ 7+ 7/13 Cas revival of measurement work
+ 8 10/ 9 Norm NBS people and publications
+ 9 11/26 To:norm question <<Are there any functions
+
+ This shows the messages you received since the last time
you exe-
+ cuted this command (_i_n_c adds these new messages to
your inbox folder).
+ You can see this list again, plus a list of any other
messages you have,
+ by using the _s_c_a_n command.
+
+ _s_c_a_n
+
+ The scan listing shows the message number, followed by
the date and
+ the sender. (If you are the sender, the addressee in the
"To:" com-
+ ponent is displayed. You may send yourself a message by
including your
+ name among the "To:" or "cc:" addressees.) It also shows
the message's
+ subject; if the subject is short, the first part of the body
of the mes-
+ sage is included after the characters <<.
+
+
+
+ -7-
+
+
+
+
+
+
+
+
+
+ -8-
+
+
+ _s_h_o_w
+
+ This command shows the current message, that is, the
first one of
+ the new messages after an _i_n_c. If the message is not
specified by name
+ (number), it is generally the last message referred to by an
_M_H command.
+ For example,
+
+
+ _s_h_o_w 5 will show message 5.
+
+
+ You can use the show command to copy a message or print
a message.
+
+
+ _s_h_o_w > _x will copy the message to file x.
+ _s_h_o_w | _l_p_r will print the message, using
the _l_p_r command.
+ _n_e_x_t will show the message that follows
the current message.
+ _p_r_e_v will show the message previous to
the current message.
+ _r_m_m will remove the current message.
+ _r_m_m _3 will remove message 3.
+
+
+ _c_o_m_p
+
+ The _c_o_m_p command puts you in the editor to write
or edit a message.
+ Fill in or delete the "To:", "cc:", and "Subject:" fields,
as appropri-
+ ate, and type the body of the message. Then exit normally
from the edi-
+ tor. You will be asked "What now?". Type a carriage return
to see the
+ options. Typing send will cause the message to be sent;
typing quit
+ will cause an exit from _c_o_m_p, with the message draft
saved.
+
+ If you quit without sending the message, it will be
saved in a file
+ called <name>/Mail/draft (where <name> is your $HOME
directory). You
+ can resume editing the message later with "comp -use"; or you
can send
+ the message later, using the _s_e_n_d command.
+
+ _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+ This command uses a different editor and is useful for
preparing
+ "quick and dirty" messages. It prompts you for each
component of the
+ header. Type the information for that component, or type
a carriage
+ return to omit the component. After that, type the body of
the message.
+ Backspacing is the only form of editing allowed with this
editor. When
+ the body is complete, type a carriage return followed by
<EOT> (usually
+ <CTRL-D>). This completes the initial preparation of the
message; from
+ then on, use the same procedures as with _c_o_m_p (above).
+
+ _r_e_p_l
+ _r_e_p_l n
+
+ This command makes up an initial message form with a
header that is
+ appropriate for replying to an existing message. The
message being
+
+
+
+
+
+
+
+
+
+
+
+ -9-
+
+
+ answered is the current message if no message number is
mentioned, or n
+ if a number is specified. After the header is completed, you
can finish
+ the message as in _c_o_m_p (above).
+
+ This is enough information to get you going using
_M_H. There are
+ more commands, and the commands described here have more
features. Sub-
+ sequent sections explain _M_H in complete detail. The
system is quite
+ powerful if you want to use its sophisticated features, but
the forego-
+ ing commands suffice for sending and receiving messages.
+
+ There are numerous additional capabilities you may wish
to explore.
+ For example, the _p_i_c_k command will select a subset
of messages based on
+ specified criteria such as sender and/or subject. Groups
of messages
+ may be designated, as described in Sec. IV, under Message
Naming. The
+ file ._m_h__p_r_o_f_i_l_e can be used to tailor your
use of the message system to
+ your needs and preferences, as described in Sec. IV, under
The User Pro-
+ file. In general, you may learn additional features of
the system
+ selectively, according to your requirements, by studying
the relevant
+ sections of this manual. There is no need to learn all the
details of
+ the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _4. _D_E_T_A_I_L_E_D
_D_E_S_C_R_I_P_T_I_O_N
+
+
+
+
+
+ This section describes the _M_H system in detail,
including the com-
+ ponents of the user profile, the conventions for message
naming, and
+ some of the other _M_H conventions. Readers who are
generally familiar
+ with computer systems will be able to follow the
principal ideas,
+ although some details may be meaningful only to those
familiar with
+ UNIX.
+
+
+ _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+ The first time an _M_H command is issued by a new
user, the system
+ prompts for a "Path" and creates an _M_H "profile".
+
+ Each _M_H user has a profile which contains tailoring
information for
+ each individual program. Other profile entries control
the _M_H path
+ (where folders and special files are kept), folder and
message protec-
+ tions, editor selection, and default arguments for each
_M_H program.
+ Each user of _M_H also has a context file which contains
current state
+ information for the _M_H package (the location of the
context file is kept
+ in the user's _M_H directory, or may be named in the user
profile). When
+ a folder becomes the current folder, it is recorded in the
user's con-
+ text. (Other state information is kept in the context
file, see the
+ manual entry for _m_h-_p_r_o_f_i_l_e (5) for more
details.) In general, the term
+ "profile entry" refer to entries in either the profile or
context file.
+ Users of _M_H needn't worry about the distinction, _M_H
handles these things
+ automatically.
+
+ The _M_H profile is stored in the file
._m_h__p_r_o_f_i_l_e in the user's
+ $HOME directory[1]. It has the format of a message without
any body.
+ That is, each profile entry is on one line, with a keyword
followed by a
+ colon (:) followed by text particular to the keyword.
+ => _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t
_h_a_v_e _b_l_a_n_k _l_i_n_e_s.
+ The keywords may have any combination of upper and lower
case. (See the
+ information of _m_h-_m_a_i_l later on in this manual
for a description of mes-
+ sage formats.)
+
+ For the average _M_H user, the only profile entry of
importance is
+ "Path". Path specifies a directory in which _M_H
folders and certain
+ files such as "draft" are found. The argument to this
keyword must be a
+ legal UNIX path that names an existing directory. If this
path is not
+ absolute (i.e., does not begin with a / ), it will be
presumed to start
+
+
+ [1] By defining the envariable $MH, you can specify an
alternate pro-
+ file to be used by _M_H commands.
+
+
+ -10-
+
+
+
+
+
+
+
+
+
+ -11-
+
+
+ from the user's $HOME directory. All folder and message
references
+ within _M_H will relate to this path unless full path names
are used.
+
+ Message protection defaults to 644, and folder
protection to 711.
+ These may be changed by profile entries "Msg-Protect"
and "Folder-
+ Protect", respectively. The argument to these keywords is
an octal
+ number which is used as the UNIX file mode[2].
+
+ When an _M_H program starts running, it looks through
the user's pro-
+ file for an entry with a keyword matching the program's name.
For exam-
+ ple, when _c_o_m_p is run, it looks for a "comp" profile
entry. If one is
+ found, the text of the profile entry is used as the default
switch set-
+ ting until all defaults are overridden by explicit switches
passed to
+ the program as arguments. Thus the
profile entry
+ "comp: -form standard.list" would direct _c_o_m_p to
use the file
+ "standard.list" as the message skeleton. If an explicit
form switch is
+ given to the _c_o_m_p command, it will override the
switch obtained from the
+ profile.
+
+ In UNIX, a program may exist under several names, either
by linking
+ or aliasing. The actual invocation name is used by an
_M_H program when
+ scanning for its profile defaults[3]. Thus, each _M_H
program may have
+ several names by which it can be invoked, and each name may
have a dif-
+ ferent set of default switches. For example, if _c_o_m_p
is invoked by the
+ name _i_c_o_m_p, the profile entry "icomp" will control
the default switches
+ for this invocation of the _c_o_m_p program. This
provides a powerful
+ definitional facility for commonly used switch settings.
+
+ The default editor for editing within _c_o_m_p,
_r_e_p_l, _f_o_r_w, and _d_i_s_t,
+ is usually _p_r_o_m_p_t_e_r, but might be something
else at your site, such as
+ /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e. A different
editor may be used by specifying the
+ profile entry "Editor: ". The argument to "Editor" is the
name of an
+ executable program or shell command file which can be
found via the
+ user's $PATH defined search path, excluding the current
directory. The
+ "Editor:" profile specification may in turn be
overridden by a
+ `-editor <editor>' profile switch associated with
_c_o_m_p, _r_e_p_l, _f_o_r_w, or
+ _d_i_s_t. Finally, an explicit editor switch specified
with any of these
+ four commands will have ultimate precedence.
+
+ During message composition, more than one editor may be
used. For
+ example, one editor (such as _p_r_o_m_p_t_e_r )
may be used initially, and a
+
+
+ [2] See _c_h_m_o_d (1) in the _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+ [3] Unfortunately, the shell does not preserve aliasing
information
+ when calling a program, hence if a program is invoked by an
alias dif-
+ ferent than its name, the program will examine the profile
entry for
+ it's name, not the alias that the user invoked it as. The
correct solu-
+ tion is to create a (soft) link in your
$_H_O_M_E/_b_i_n directory to the _M_H
+ program of your choice. By giving this link a different
name, you can
+ use an alternate set of defaults for the command.
+
+
+
+
+
+
+
+
+
+
+
+
+ -12-
+
+
+ second editor may be invoked later to revise the message
being composed
+ (see the discussion of _c_o_m_p in Section 5 for
details). A profile entry
+ "<lasteditor>-next: <editor>" specifies the name of the
editor to be
+ used after a particular editor. Thus "comp: -e prompter"
causes the
+ initial text to be collected by
_p_r_o_m_p_t_e_r, and the profile entry
+ "prompter-next: ed" names ed as the editor to be invoked
for the next
+ round of editing.
+
+ Some of the _M_H commands, such as _s_h_o_w, can
be used on message fold-
+ ers owned by others, if those folders are readable. However,
you cannot
+ write in someone else's folder. All the _M_H command
actions not requir-
+ ing write permission may be used with a "read-only" folder.
+
+ Table 1 lists examples of some of the currently
defined profile
+ entries, typical arguments, and the programs that reference
the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -13-
+
+
+ Table 1
+
+ PROFILE COMPONENTS
+
______________________________________________________
+
+ _M_H Programs that
+ Keyword and Argument use
Component______________________________________________________
+
+ Path: Mail All
+ Current-Folder: inbox Most
+ Editor: /usr/ucb/ex _c_o_m_p,
_d_i_s_t, _f_o_r_w, _r_e_p_l
+ Inbox: inbox _i_n_c, _r_m_f
+ Msg-Protect: 644 _i_n_c
+ Folder-Protect: 711 _i_n_c,
_p_i_c_k, _r_e_f_i_l_e
+ <program>: default switches All
+ prompter-next: ed _c_o_m_p,
_d_i_s_t, _f_o_r_w, _r_e_p_l
+
______________________________________________________
+
+
+ Path should______ be present. Current-Folder is
maintained automatically
+ by many _M_H commands (see the Context sections of the
individual commands
+ in Sec. IV). All other entries are optional, defaulting to
the values
+ described above.
+
+
+ _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+ Messages may be referred to explicitly or implicitly
when using _M_H
+ commands. A formal syntax of message names is given in
Appendix B, but
+ the following description should be sufficient for most
_M_H users. Some
+ details of message naming that apply only to certain
commands are
+ included in the description of those commands.
+
+ Most of the _M_H commands accept arguments specifying
one or more
+ folders, and one or more messages to operate on. The use
of the word
+ "msg" as an argument to a command means that exactly one
message name
+ may be specified. A message name may be a number, such
as 1, 33, or
+ 234, or it may be one of the "reserved" message names:
first, last,
+ prev, next, and cur. (As a shorthand, a period (.) is
equivalent to
+ cur.) The meanings of these names are straightforward:
"first" is the
+ first message in the folder; "last" is the last message in
the folder;
+ "prev" is the message numerically previous to the
current message;
+ "next" is the message numerically following the current
message; "cur"
+ (or ".") is the current message in the folder. In addition,
_M_H supports
+ user-defined-sequences; see the description of the
_m_a_r_k command for more
+ information.
+
+ The default in commands that take a "msg" argument is
always "cur".
+
+ The word "msgs" indicates that several messages may be
specified.
+ Such a specification consists of several message
designations separated
+ by spaces. A message designation is either a message name or
a message
+
+
+
+
+
+
+
+
+
+
+
+ -14-
+
+
+ range. A message range is a specification of the form
name1-name2 or
+ name1:n, where name1 and name2 are message names and n is
an integer.
+ The first form designates all the messages from name1
to name2
+ inclusive; this must be a non-empty range. The second form
specifies up
+ to n messages, starting with name1 if name1 is a number, or
first, cur,
+ or next, and ending with name1 if name1 is last or prev.
This interpre-
+ tation of n is overridden if n is preceded by a plus sign
or a minus
+ sign; +n always means up to n messages starting with
name1, and -n
+ always means up to n messages ending with name1. Repeated
specifica-
+ tions of the same message have the same effect as a single
specification
+ of the message. Examples of specifications are:
+
+
+ 1 5 7-11 22
+ first 6 8 next
+ first-10
+ last:5
+
+
+ The message name "all" is a shorthand for "first-last",
indicating
+ all of the messages in the folder.
+
+ In commands that accept "msgs" arguments, the default is
either cur
+ or all, depending on which makes more sense.
+
+ In all of the _M_H commands, a plus sign preceding an
argument indi-
+ cates a folder name. Thus, "+inbox" is the name of the
user's standard
+ inbox. If an explicit folder argument is given to an
_M_H command, it
+ will become the current folder (that is, the
"Current-Folder:" entry in
+ the user's profile will be changed to this folder). In the
case of the
+ _r_e_f_i_l_e command, which can have multiple
output folders, a new source
+ folder (other than the default current folder) is
specified by
+ `-src +folder'.
+
+
+ _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+ One very powerful feature of _M_H is that the _M_H
commands may be
+ issued from any current directory, and the proper path to
the appropri-
+ ate folder(s) will be taken from the user's profile. If the
_M_H path is
+ not appropriate for a specific folder or file, the automatic
prepending
+ of the _M_H path can be avoided by beginning a folder or
file name with /,
+ or with ./ or ../ component. Thus any specific absolute
path may be
+ specified along with any path relative to the current working
directory.
+
+ Arguments to the various programs may be given in any
order, with
+ the exception of a few switches whose arguments must follow
immediately,
+ such as `-src +folder' for _r_e_f_i_l_e.
+
+ Whenever an _M_H command prompts the user, the valid
options will be
+ listed in response to a <RETURN>. (The first of the listed
options is
+ the default if end-of-file is encountered, such as from a
command file.)
+
+
+
+
+
+
+
+
+
+
+
+ -15-
+
+
+ A valid response is any _u_n_i_q_u_e abbreviation
of one of the listed
+ options.
+
+ Standard UNIX documentation conventions are used in this
report to
+ describe _M_H command syntax. Arguments enclosed in
brackets ([ ]) are
+ optional; exactly one of the arguments enclosed within braces
({ }) must
+ be specified, and all other arguments are required. The use
of ellipsis
+ dots (...) indicates zero or more repetitions of the previous
item. For
+ example, "+folder ..." would indicate that one or more
"+folder" argu-
+ ments is required and "[+folder ...]" indicates that 0 or
more "+folder"
+ arguments may be given.
+
+ _M_H departs from UNIX standards by using switches
that consist of
+ more than one character, e.g. `-header'. To minimize
typing, only a
+ unique abbreviation of a switch need be typed; thus, for
`-header',
+ `-hea' is probably sufficient, depending on the other
switches the com-
+ mand accepts. Each _M_H program accepts the switch `-help'
(which must be
+ spelled out fully) and produces a syntax description
and a list of
+ switches. In the list of switches, parentheses indicate
required char-
+ acters. For example, all `-help' switches will appear as
"-(help)",
+ indicating that no abbreviation is accepted. Furthermore,
the `-help'
+ switch tells the version of the _M_H program you invoked.
+
+ Many _M_H switches have both on and off forms, such as
`-format' and
+ `-noformat'. In many of the descriptions which follow, only
one form is
+ defined; the other form, often used to nullify profile switch
settings,
+ is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -16-
+
+
+ _M_H _C_O_M_M_A_N_D_S
+
+ The _M_H package comprises several programs:
+
+ ali (1) - list mail aliases
+ anno (1) - annotate messages
+ bbc (1) - check on BBoards
+ bboards (1) - the UCI BBoards facility
+ burst (1) - explode digests into messages
+ comp (1) - compose a message
+ dist (1) - redistribute a message to additional
addresses
+ folder (1) - set/list current folder/message
+ folders (1) - list all folders
+ forw (1) - forward messages
+ inc (1) - incorporate new mail
+ mark (1) - mark messages
+ mhl (1) - produce formatted listings of MH
messages
+ mhmail (1) - send or read mail
+ mhook (1) - MH receive-mail hooks
+ mhparam (1) - print MH profile components
+ mhpath (1) - print full pathnames of MH messages and
folders
+ msgchk (1) - check for messages
+ msh (1) - MH shell (and BBoard reader)
+ next (1) - show the next message
+ packf (1) - compress a folder into a single file
+ pick (1) - select messages by content
+ prev (1) - show the previous message
+ prompter (1) - prompting editor front end
+ rcvstore (1) - incorporate new mail asynchronously
+ refile (1) - file messages in other folders
+ repl (1) - reply to a message
+ rmf (1) - remove folder
+ rmm (1) - remove messages
+ scan (1) - produce a one line per message scan
listing
+ send (1) - send a message
+ show (1) - show (list) messages
+ slocal (1) - special local mail delivery
+ sortm (1) - sort messages
+ vmh (1) - visual front-end to MH
+ whatnow (1) - prompting front-end for send
+ whom (1) - report to whom a message would go
+
+
+ These programs are described below. The form of the
descriptions
+ conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ALI(1) -17-
ALI(1)
+
+
+ _N_A_M_E
+ ali - list mail aliases
+
+ _S_Y_N_O_P_S_I_S
+ ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_l_i searches the named mail alias files for each of
the given
+ _a_l_i_a_s_e_s. It creates a list of addresses
for those _a_l_i_a_s_e_s, and
+ writes that list on standard output. If the `-list'
option is
+ specified, each address appears on a separate line;
otherwise, the
+ addresses are separated by commas and printed on as few
lines as
+ possible.
+
+ The `-user' option directs _a_l_i to perform its
processing in an
+ inverted fashion: instead of listing the addresses that each
given
+ alias expands to, _a_l_i will list the aliases that
expand to each
+ given address. If the `-normalize' switch is given,
_a_l_i will try
+ to track down the official hostname of the address.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read. Each _a_l_i_a_s is processed as described in
_m_h-_a_l_i_a_s (5).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /etc/passwd List of users
+ /etc/group List of groups
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/bs/mh-6.8/lib/MailAliases'
+ `-nolist'
+ `-nonormalize'
+ `-nouser'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ALI(1) -18-
ALI(1)
+
+
+ _B_u_g_s
+ The `-user' option with `-nonormalize' is not entirely
accurate, as
+ it does not replace local nicknames for hosts with their
official
+ site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -19-
ANNO(1)
+
+
+ _N_A_M_E
+ anno - annotate messages
+
+ _S_Y_N_O_P_S_I_S
+ anno [+folder] [msgs] [-component field] [-inplace]
[-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_n_n_o annotates the specified messages in the named
folder using the
+ field and body. Annotation is optionally performed by
_d_i_s_t, _f_o_r_w,
+ and _r_e_p_l, to keep track of your distribution of,
forwarding of, and
+ replies to a message. By using _a_n_n_o, you can
perform arbitrary
+ annotations of your own. Each message selected will be
annotated
+ with the lines
+
+ field: date
+ field: body
+
+ The `-nodate' switch inhibits the date annotation, leaving
only the
+ body annotation. The `-inplace' switch causes annotation
to be
+ done in place in order to preserve links to the annotated
message.
+
+ The field specified should be a valid 822-style message field
name,
+ which means that it should consist of alphanumerics (or
dashes)
+ only. The body specified is arbitrary text.
+
+ If a `-component field' is not specified when _a_n_n_o is
invoked, _a_n_n_o
+ will prompt the user for the name of field for the annotation.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ dist (1), forw (1), repl (1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-date'
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -20-
ANNO(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -21-
BBC(1)
+
+
+ _N_A_M_E
+ bbc - check on BBoards
+
+ _S_Y_N_O_P_S_I_S
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet]
[-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c]
[-rcfile rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+ [-host host] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _b_b_c is a BBoard reading/checking program that
interfaces to the
+ BBoard channel.
+
+ The _b_b_c program has three action switches which direct
its opera-
+ tion:
+
+ The `-read' switch invokes the _m_s_h program on the
named _B_B_o_a_r_d_s.
+ If you also specify the `-archive' switch, then _b_b_c
will invoke
+ the _m_s_h program on the archives of the named
_B_B_o_a_r_d_s. If no
+ _B_B_o_a_r_d_s are given on the command line,
and you specified
+ `-archive', _b_b_c will not read your `bboards' profile
entry, but
+ will read the archives of the "system" _B_B_o_a_r_d
instead.
+
+ The `-check' switch types out status information for the
named
+ _B_B_o_a_r_d_s. _b_b_c can print one of several
messages depending on the
+ status of both the BBoard and the user's reading habits. As
with
+ each of these messages, the number given is the item number
of the
+ last item placed in the BBoard. This number (which is
marked in
+ the messages as the "BBoard-Id") is ever increasing.
Hence, when
+ _b_b_c says "n items", it really means that the highest
BBoard-Id is
+ "n". There may, or may not actually be "n" items in the
BBoard.
+ Some common messages are:
+
+ BBoard -- n items unseen
+ This message tells how many items the user has
not yet
+ seen. When invoked with the `-quiet' switch, this
is the
+ only informative line that _b_b_c will possibly
print out.
+
+ BBoard -- empty
+ The BBoard is empty.
+
+ BBoard -- n items (none seen)
+ The BBoard has items in it, but the user hasn't
seen any.
+
+ BBoard -- n items (all seen)
+ The BBoard is non-empty, and the user has seen
everything
+ in it.
+
+ BBoard -- n items seen out of m
+ The BBoard has at most m-n items that the user
has not
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -22-
BBC(1)
+
+
+ seen.
+
+ The `-topics' switch directs _b_b_c to print three items
about the
+ named _B_B_o_a_r_d_s: it's official name, the number
of items present, and
+ the date and time of the last update. If no
_B_B_o_a_r_d_s are named,
+ then all BBoards are listed. If the `-verbose' switch is
given,
+ more information is output.
+
+ The `-quiet' switch specifies that _b_b_c should be
silent if no
+ _B_B_o_a_r_d_s are found with new information.
The `-verbose' switch
+ specifies that _b_b_c is to consider you to be interested
in _B_B_o_a_r_d_s
+ that you've already seen everything in.
+
+ To override the default _m_s_h_p_r_o_c and the
profile entry, use the
+ `-mshproc program' switch. Any arguments not understood by
_b_b_c are
+ passed to this program. The `-protocol' switch tells
_b_b_c that your
+ _m_s_h_p_r_o_c knows about the special _b_b_c
protocol for reporting back
+ information. _m_s_h (1), the default
_m_s_h_p_r_o_c, knows all about this.
+
+ The `-file BBoardsfile' switch tells _b_b_c to use a
non-standard
+ _B_B_o_a_r_d_s file when performing its
calculations. Similarly, the
+ `-user BBoardsuser' switch tells _b_b_c to use a
non-standard user-
+ name. Both of these switches are useful for debugging
a new
+ _B_B_o_a_r_d_s or _P_O_P file.
+
+ If the local host is configured as an NNTP BBoards client,
or if
+ the `-host host' switch is given, then _b_b_c will query
the NNTP ser-
+ vice host as to the status of the BBoards. For NNTP
BBoards
+ clients, the `-user user' and the `-rpop' switches are
ignored.
+
+ The ._b_b_r_c file in the user's $HOME directory is used
to keep track
+ of what messages have been read. The `-rcfile rcfile' switch
over-
+ rides the use of ._b_b_r_c for this purpose. If the
value given to the
+ switch is not absolute, (i.e., does not begin with a / ),
it will
+ be presumed to start from the current working directory. If
this
+ switch is not given (or the `-norcfile' switch is given),
then _b_b_c
+ consults the envariable $MHBBRC, and honors it similarly.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard "current" message
information
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+ _S_e_e _A_l_s_o
+ bbl(1), bboards(1), msh(1)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -23-
BBC(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-read'
+ `-noarchive'
+ `-protocol'
+ `bboards' defaults to "system"
+ `-file /usr/bs/mh-6.8/bboards/BBoards'
+ `-user bboards'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The `-user' switch takes effect only if followed by the
`-file'
+ switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -24-
BBOARDS(1)
+
+
+ _N_A_M_E
+ bboards - the UCI BBoards facility
+
+ _S_Y_N_O_P_S_I_S
+ bbc [-check] [-read] bboards ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The home directory of _b_b_o_a_r_d_s is where the
BBoard system is kept.
+ This documentation describes some of the nuances of the
BBoard sys-
+ tem.
+
+ BBoards, BBoard-IDs
+ A BBoard is just a file containing a group of messages
relat-
+ ing to the same topic. These files live in the
~bboards home
+ directory. Each message in a BBoard file has in its
header
+ the line "BBoard-Id: n", where "n" is an ascending
decimal
+ number. This id-number is unique for each message
in a
+ BBoards file. It should NOT be confused with the
message
+ number of a message, which can change as messages are
removed
+ from the BBoard.
+
+ BBoard Handling
+ To read BBoards, use the _b_b_c and _m_s_h
programs. The _m_s_h com-
+ mand is a monolithic program which contains all the
func-
+ tionality of _M_H in a single program. The `-check'
switch to
+ _b_b_c lets you check on the status of BBoards, and
the `-read'
+ switch tells _b_b_c to invoke _m_s_h to read those
BBoards.
+
+ Creating a BBoard
+ Both public, and private BBoards are supported.
Contact the
+ mail address _P_o_s_t_M_a_s_t_e_r if you'd
like to have a BBoard
+ created.
+
+ BBoard addresses
+ Each BBoard has associated with it 4 addresses, these
are (for
+ the ficticious BBoard called ``hacks''):
+ hacks : The Internet wide distribution list.
+ dist-hacks : The local BBoard.
+ hacks-request : The people responsible for the BBoard
at the
+ Internet level.
+ local-hacks-request : The people responsible for the
BBoard
+ locally.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard information
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -25-
BBOARDS(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+ _S_e_e _A_l_s_o
+ bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ The default bboard is "system"
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BURST(1) -26-
BURST(1)
+
+
+ _N_A_M_E
+ burst - explode digests into messages
+
+ _S_Y_N_O_P_S_I_S
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet]
[-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _B_u_r_s_t considers the specified messages in the named
folder to be
+ Internet digests, and explodes them in that folder.
+
+ If `-inplace' is given, each digest is replaced by the
"table of
+ contents" for the digest (the original digest is removed).
_B_u_r_s_t
+ then renumbers all of the messages following the digest
in the
+ folder to make room for each of the messages contained
within the
+ digest. These messages are placed immediately after the
digest.
+
+ If `-noinplace' is given, each digest is preserved, no
table of
+ contents is produced, and the messages contained within the
digest
+ are placed at the end of the folder. Other messages are not
tam-
+ pered with in any way.
+
+ The `-quiet' switch directs _b_u_r_s_t to be silent
about reporting mes-
+ sages that are not in digest format.
+
+ The `-verbose' switch directs _b_u_r_s_t to tell the
user the general
+ actions that it is taking to explode the digest.
+
+ It turns out that _b_u_r_s_t works equally well on
forwarded messages
+ and blind-carbon-copies as on Internet digests, provided
that the
+ former two were generated by _f_o_r_w or _s_e_n_d.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new message
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ inc(1), msh(1), pack(1)
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BURST(1) -27-
BURST(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-noquiet'
+ `-noverbose'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. If
`-in-
+ place' is given, then the first message burst becomes the
current
+ message. This leaves the context ready for a _s_h_o_w of
the table of
+ contents of the digest, and a _n_e_x_t to see the first
message of the
+ digest. If `-noinplace' is given, then the first message
extracted
+ from the first digest burst becomes the current message.
This
+ leaves the context in a similar, but not identical, state
to the
+ context achieved when using `-inplace'.
+
+
+ _B_u_g_s
+ The _b_u_r_s_t program enforces a limit on the number of
messages which
+ may be _b_u_r_s_t from a single message. This number is
on the order of
+ 1000 messages. There is usually no limit on the number of
messages
+ which may reside in the folder after the _b_u_r_s_ting.
+
+ Although _b_u_r_s_t uses a sophisticated algorithm to
determine where
+ one encapsulated message ends and another begins, not all
digesti-
+ fying programs use an encapsulation algorithm. In
degenerate
+ cases, this usually results in _b_u_r_s_t finding an
encapsulation boun-
+ dary prematurely and splitting a single encapsulated message
into
+ two or more messages. These erroneous digestifying programs
should
+ be fixed.
+
+ Furthermore, any text which appears after the last
encapsulated
+ message is not placed in a seperate message by
_b_u_r_s_t. In the case
+ of digestified messages, this text is usally an "End of
digest"
+ string. As a result of this possibly un-friendly behavior
on the
+ part of _b_u_r_s_t, note that when the `-inplace' option
is used, this
+ trailing information is lost. In practice, this is not a
problem
+ since correspondents usually place remarks in text prior
to the
+ first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ COMP(1) -28-
COMP(1)
+
+
+ _N_A_M_E
+ comp - compose a message
+
+ _S_Y_N_O_P_S_I_S
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage
msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_m_p is used to create a new message to be mailed.
It copies a
+ message form to the draft being composed and then invokes an
editor
+ on the draft (unless `-noedit' is given, in which case the
initial
+ edit is suppressed).
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "components" exists in the user's MH
directory,
+ it will be used instead of this form. The file
specified by
+ `-form formfile' will be used if given. You may also start
_c_o_m_p
+ using the contents of an existing message as the form. If
you sup-
+ ply either a `+folder' or `msg' argument, that message will
be used
+ as the form. You may not supply both a `-form formfile'
and a
+ `+folder' or `msg' argument. The line of dashes or a blank
line
+ must be left between the header and the body of the message
for the
+ message to be identified properly when it is sent (see
_s_e_n_d (1)).
+ The switch `-use' directs _c_o_m_p to continue
editing an already
+ started message. That is, if a _c_o_m_p (or
_d_i_s_t, _r_e_p_l, or _f_o_r_w ) is
+ terminated without sending the draft, the draft can be edited
again
+ via "comp -use".
+
+ If the draft already exists, _c_o_m_p will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_c_o_m_p, leaving the
+ draft intact; replace will replace the existing draft
with the
+ appropriate form; list will display the draft; use will
use the
+ draft for further composition; and refile +folder will
file the
+ draft in the given folder, and give you a new draft
with the
+ appropriate form. (The `+folder' argument to refile is
required.)
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ The `-file file' switch says to use the named file as the
message
+ draft.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ COMP(1) -29-
COMP(1)
+
+
+ The `-editor editor' switch indicates the editor to use
for the
+ initial edit. Upon exiting from the editor, _c_o_m_p
will invoke the
+ _w_h_a_t_n_o_w program. See _w_h_a_t_n_o_w (1)
for a discussion of available
+ options. The invocation of this program can be inhibited by
using
+ the `-nowhatnowproc' switch. (In truth of fact, it is the
_w_h_a_t_n_o_w
+ program which starts the initial edit. Hence,
`-nowhatnowproc'
+ will prevent any edit from occurring.)
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/components The message skeleton
+ or <mh-dir>/components Rather than the standard
skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to the current message
+ `-nodraftfolder'
+ `-nouse'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _c_o_m_p uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _c_o_m_p won't run
+ it.
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -30-
DIST(1)
+
+
+ _N_A_M_E
+ dist - redistribute a message to additional addresses
+
+ _S_Y_N_O_P_S_I_S
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_i_s_t is similar to _f_o_r_w. It prepares the
specified message for
+ redistribution to addresses that (presumably) are not on the
origi-
+ nal address list.
+
+ The default message form contains the following elements:
+
+ Resent-To:
+ Resent-cc:
+
+ If the file named "distcomps" exists in the user's MH
directory, it
+ will be used instead of this form. In either case, the file
speci-
+ fied by `-form formfile' will be used if given. The form
used will
+ be prepended to the message being resent.
+
+ If the draft already exists, _d_i_s_t will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_d_i_s_t, leaving the
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ Only those addresses in "Resent-To:", "Resent-cc:",
and
+ "Resent-Bcc:" will be sent. Also, a "Resent-Fcc: folder"
will be
+ honored (see _s_e_n_d (1)). Note that with _d_i_s_t,
the draft should con-
+ tain only "Resent-xxx:" fields and no body. The headers
and the
+ body of the original message are copied to the draft when the
mes-
+ sage is sent. Use care in constructing the headers for the
redis-
+ tribution.
+
+ If the `-annotate' switch is given, the message being
distributed
+ will be annotated with the lines:
+
+ Resent: date
+ Resent: addrs
+
+ where each address list contains as many lines as required.
This
+ annotation will be done only if the message is sent
directly from
+ _d_i_s_t. If the message is not sent immediately from
_d_i_s_t, "comp
+ -use" may be used to re-edit and send the constructed
message, but
+ the annotations won't take place. The '-inplace' switch
causes
+ annotation to be done in place in order to preserve links
to the
+ annotated message.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -31-
DIST(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches. Note that while in the editor, the message being
resent
+ is available through a link named "@" (assuming the default
_w_h_a_t_-
+ _n_o_w_p_r_o_c ). In addition, the actual
pathname of the message is
+ stored in the envariable $editalt, and the pathname of the
folder
+ containing the message is stored in the envariable $mhfolder.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _d_i_s_t will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/distcomps The message skeleton
+ or <mh-dir>/distcomps Rather than the standard
skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
mes-
+ sage distributed will become the current message.
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -32-
DIST(1)
+
+
+ _H_i_s_t_o_r_y
+ _D_i_s_t originally used headers of the form
"Distribute-xxx:" instead
+ of "Resent-xxx:". In order to conform with the ARPA Internet
stan-
+ dard, RFC-822, the "Resent-xxx:" form is now used.
_D_i_s_t will
+ recognize "Distribute-xxx:" type headers and automatically
convert
+ them to "Resent-xxx:".
+
+
+ _B_u_g_s
+ _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check
the message being distributed for
+ adherence to the transport standard, but _p_o_s_t called
by _s_e_n_d does.
+ The _p_o_s_t program will balk (and rightly so) at
poorly formatted
+ messages, and _d_i_s_t won't correct things for you.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _d_i_s_t uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _d_i_s_t won't run
+ it.
+
+ If your current working directory is not writable, the link
named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -33-
FOLDER(1)
+
+
+ _N_A_M_E
+ folder, folders - set/list current folder/message
+
+ _S_Y_N_O_P_S_I_S
+ folder [+folder] [msg] [-all] [-print] [-fast] [-nofast]
[-header]
+ [-noheader] [-recurse] [-norecurse] [-total] [-nototal]
+ [-list] [-nolist] [-push] [-pop] [-pack] [-nopack]
[-verbose]
+ [-noverbose] [-help]
+
+ folders
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Since the _M_H environment is the shell, it is easy to lose
track of
+ the current folder from day to day. When
_f_o_l_d_e_r is given the
+ `-print' switch (the default), _f_o_l_d_e_r will list
the current folder,
+ the number of messages in it, the range of the messages
(low-high),
+ and the current message within the folder, and will flag
extra
+ files if they exist. An example of this summary is:
+
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+
+ If a `+folder' and/or `msg' are specified, they will
become the
+ current folder and/or message. If the specified (or
default)
+ folder doesn't exist, the user will be queried as to
whether the
+ folder should be created. When standard input is not a
tty, the
+ folder is created without any query. (This is the easy
way to
+ create an empty folder for use later.)
+
+ By comparison, when a `+folder' argument is given, this
corresponds
+ to a "cd" operation in the _s_h_e_l_l; when no
`+folder' argument is
+ given, this corresponds roughly to a "pwd" operation in the
_s_h_e_l_l.
+
+
+
+ _M_u_l_t_i_p_l_e _F_o_l_d_e_r_s
+
+ Specifying `-all' will produce a summary line for each
top-level
+ folder in the user's MH directory, sorted
alphabetically. (If
+ _f_o_l_d_e_r is invoked by a name ending with "s"
(e.g., _f_o_l_d_e_r_s ),
+ `-all' is assumed). Specifying `-recurse' with `-all'
will also
+ produce a line for all sub-folders. These folders are all
preceded
+ by the read-only folders, which occur as "atr-cur-" entries
in the
+ user's _M_H context. For example,
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -34-
FOLDER(1)
+
+
+ Folder # of messages ( range ) cur msg (other
files)
+ /fsd/rs/m/tacc has 35 messages ( 1- 35); cur= 23.
+ /rnd/phyl/Mail/EP has 82 messages ( 1-108); cur= 82.
+ ff has no messages.
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+ mh has 76 messages ( 1- 76); cur= 70.
+ notes has 2 messages ( 1- 2); cur= 1.
+ ucom has 124 messages ( 1-124); cur= 6;
(others).
+ TOTAL= 339 messages in 7 folders
+
+ The "+" after inbox indicates that it is the current folder.
The
+ "(others)" indicates that the folder `ucom' has files which
aren't
+ messages. These files may either be sub-folders, or files
that
+ don't belong under the MH file naming scheme.
+
+ The header is output if either a `-all' or a `-header'
switch is
+ specified; it is suppressed by `-noheader'. A `-total'
switch will
+ produce only the summary line.
+
+ If `-fast' is given, only the folder name (or names in the
case of
+ `-all') will be listed. (This is faster because the
folders need
+ not be read.)
+
+ If a `+folder' is given along with the `-all' switch,
_f_o_l_d_e_r will,
+ in addition to setting the current folder, list the top-level
fold-
+ ers for the current folder (with `-norecurse') or list all
sub-
+ folders under the current folder recursively (with
`-recurse'). In
+ this case, if a `msg' is also supplied, it will become the
current
+ message of `+folder'.
+
+ The `-recurse' switch lists each folder recursively, so use
of this
+ option effectively defeats the speed enhancement of the
`-fast'
+ option, since each folder must be searched for
subfolders.
+ Nevertheless, the combination of these options is useful.
+
+
+ _C_o_m_p_a_c_t_i_n_g _a _F_o_l_d_e_r
+
+ The `-pack' switch will compress the message names in the
desig-
+ nated folders, removing holes in message numbering. The
`-verbose'
+ switch directs _f_o_l_d_e_r to tell the user the
general actions that it
+ is taking to compress the folder.
+
+
+ _T_h_e _F_o_l_d_e_r _S_t_a_c_k
+
+ The `-push' switch directs _f_o_l_d_e_r to push the
current folder onto
+ the _f_o_l_d_e_r-_s_t_a_c_k, and make the
`+folder' argument the current
+ folder. If `+folder' is not given, the current folder and
the top
+ of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged.
This corresponds to the "pushd"
+ operation in the _C_S_h_e_l_l.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -35-
FOLDER(1)
+
+
+ The `-pop' switch directs _f_o_l_d_e_r to discard
the top of the
+ _f_o_l_d_e_r-_s_t_a_c_k, after setting the
current folder to that value. No
+ `+folder' argument is allowed. This corresponds to the
"popd"
+ operation in the _C_S_h_e_l_l. The `-push' switch and
the `-pop' switch
+ are mutually exclusive: the last occurrence of either one
overrides
+ any previous occurrence of the other. Both of these
switches also
+ set `-list' by default.
+
+ The `-list' switch directs _f_o_l_d_e_r to list the
contents of the
+ _f_o_l_d_e_r-_s_t_a_c_k. No `+folder' argument
is allowed. After a success-
+ ful `-push' or `-pop', the `-list' action is taken, unless a
`-nol-
+ ist' switch follows them on the command line. This
corresponds to
+ the "dirs" operation in the _C_S_h_e_l_l. The
`-push', `-pop', and
+ `-list' switches turn off `-print'.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ Folder-Stack: To determine the folder stack
+
+
+ _S_e_e _A_l_s_o
+ refile(1), mhpath(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to none
+ `-nofast'
+ `-noheader'
+ `-nototal'
+ `-nopack'
+ `-norecurse'
+ `-noverbose'
+ `-print' is the default if no `-list', `-push', or `-pop' is
specified
+ `-list' is the default if `-push', or `-pop' is specified
+
+
+ _C_o_n_t_e_x_t
+ If `+folder' and/or `msg' are given, they will become the
current
+ folder and/or message.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -36-
FOLDER(1)
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the `-fast' switch
prevented context
+ changes from occurring for the current folder. This is no
longer
+ the case: if `+folder' is given, then _f_o_l_d_e_r will
always change the
+ current folder to that.
+
+
+ _B_u_g_s
+ `-all' forces `-header'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -37-
FORW(1)
+
+
+ _N_A_M_E
+ forw - forward messages
+
+ _S_Y_N_O_P_S_I_S
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace]
[-noinplace]
+ [-mime] [-nomime] [-whatnowproc program] [-nowhatnowproc]
+ [-help]
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _F_o_r_w may be used to prepare a message containing
other messages.
+ It constructs the new message from the components
file or
+ `-form formfile' (see _c_o_m_p ), with a body
composed of the
+ message(s) to be forwarded. An editor is invoked as in
_c_o_m_p, and
+ after editing is complete, the user is prompted before the
message
+ is sent.
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "forwcomps" exists in the user's MH
directory, it
+ will be used instead of this form. In either case, the file
speci-
+ fied by `-form formfile' will be used if given.
+
+ If the draft already exists, _f_o_r_w will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_f_o_r_w, leaving the
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ If the `-annotate' switch is given, each message being
forwarded
+ will be annotated with the lines
+
+ Forwarded: date
+ Forwarded: addrs
+
+ where each address list contains as many lines as required.
This
+ annotation will be done only if the message is sent
directly from
+ _f_o_r_w. If the message is not sent immediately
from _f_o_r_w,
+ "comp -use" may be used to re-edit and send the
constructed mes-
+ sage, but the annotations won't take place. The '-inplace'
switch
+ causes annotation to be done in place in order to preserve
links to
+ the annotated message.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -38-
FORW(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches.
+
+ Although _f_o_r_w uses the `-form formfile' switch to
direct it how to
+ construct the beginning of the draft, the `-filter
filterfile',
+ `-format', and `-noformat' switches direct _f_o_r_w as to
how each for-
+ warded message should be formatted in the body of the
draft. If
+ `-noformat' is specified, then each forwarded message is
output
+ exactly as it appears. If `-format' or `-filter
filterfile' is
+ specified, then each forwarded message is filtered
(re-formatted)
+ prior to being output to the body of the draft. The
filter file
+ for _f_o_r_w should be a standard form file for
_m_h_l, as _f_o_r_w will
+ invoke _m_h_l to format the forwarded messages. The
default message
+ filter (what you get with `-format') is:
+
+ width=80,overflowtext=,overflowoffset=10
+ leftadjust,compress,compwidth=9
+
Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ To:
+ cc:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+ If the file named "mhl.forward" exists in the user's MH
directory,
+ it will be used instead of this form. In either case,
the file
+ specified by `-filter filterfile' will be used if given. To
sum-
+ marize: `-noformat' will reproduce each forwarded message
exactly,
+ `-format' will use _m_h_l and a default filterfile,
"mhl.forward", to
+ format each forwarded message, and `-filter filterfile'
will use
+ the named filterfile to format each forwarded message with
_m_h_l.
+
+ Each forwarded message is separated with an encapsulation
delimiter
+ and dashes in the first column of the forwarded messages
will be
+ prepended with `- ' so that when received, the message is
suitable
+ for bursting by _b_u_r_s_t (1). This follows the
Internet RFC-934
+ guidelines.
+
+ For users of _p_r_o_m_p_t_e_r (1), by specifying
prompter's `-prepend'
+ switch in the .mh_profile file, any commentary text is
entered
+ before the forwarded messages. (A major win!)
+
+ To use the MIME rules for encapsulation, specify the
`-mime'
+ switch. This directs _f_o_r_w to generate an
_m_h_n composition file.
+ Note that MH will not invoke _m_h_n automatically,
unless you add
+ this line to your .mh_profile file:
+
+ automhnproc: mhn
+
+ Otherwise, you must specifically give the command
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -39-
FORW(1)
+
+
+ What now? edit mhn
+
+ prior to sending the draft.
+
+ To automate this somewhat, create a link to
_p_r_o_m_p_t_e_r called _r_a_p_i_d
+ and put these lines in your .mh_profile file:
+
+ forw: -editor rapid -mime
+ rapid: -rapid
+ rapid-next: mhn
+
+ Then, you can simply do:
+
+ _f_o_r_w _m_s_g_s
+ To: _m_a_i_l_b_o_x
+ cc:
+ Subject: _w_h_a_t_e_v_e_r
+
+ --------Enter initial text
+
+ _b_l_a_h, _b_l_a_h, _b_l_a_h.
+ <CTRL-D>
+ --------
+
+ What now? _e_d_i_t
+ What now? _s_e_n_d
+
+ The _e_d_i_t command invokes _m_h_n automatically.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _f_o_r_w will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ The `-digest list', `-issue number', and `-volume number'
switches
+ implement a digest facility for _M_H. Specifying
these switches
+ enables and/or overloads the following escapes:
+
+ _T_y_p_e _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _c_o_m_p_o_n_e_n_t _d_i_g_e_s_t string
Argument to `-digest'
+ _f_u_n_c_t_i_o_n _c_u_r integer Argument to
`-volume'
+ _f_u_n_c_t_i_o_n _m_s_g integer Argument to
`-issue'
+
+ Consult the Advanced Features section of the _M_H User's
Manual for
+ more information on making digests.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -40-
FORW(1)
+
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/forwcomps The message skeleton
+ or <mh-dir>/forwcomps Rather than the standard
skeleton
+ /usr/bs/mh-6.8/lib/digestcomps The message skeleton if
`-digest' is given
+ or <mh-dir>/digestcomps Rather than the standard
skeleton
+ /usr/bs/mh-6.8/lib/mhl.forward The message filter
+ or <mh-dir>/mhl.forward Rather than the standard
filter
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter messages being
forwarded
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noformat'
+ `-noinplace'
+ `-nomime'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message forwarded will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -41-
FORW(1)
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _f_o_r_w uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _f_o_r_w won't run
+ it.
+
+ When _f_o_r_w is told to annotate the messages it
forwards, it doesn't
+ actually annotate them until the draft is successfully
sent. If
+ from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h
instead of _s_e_n_d, it's possible to
+ confuse _f_o_r_w by re-ordering the file
(e.g., by using
+ `folder -pack') before the message is successfully sent.
_D_i_s_t and
+ _r_e_p_l don't have this problem.
+
+ To avoid prepending the leading dash characters in forwarded
mes-
+ sages, there is a `-nodashmunging' option. See the
"Hidden
+ Features" section of the _M_H
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -42-
INC(1)
+
+
+ _N_A_M_E
+ inc - incorporate new mail
+
+ _S_Y_N_O_P_S_I_S
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-form formatfile] [-format string]
+ [-file name] [-silent] [-nosilent] [-truncate]
[-notruncate]
+ [-width columns] [-host host] [-user user] [-apop]
[-noapop]
+ [-rpop] [-norpop] [-pack file] [-nopack] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _I_n_c incorporates mail from the user's incoming mail
drop into an _M_H
+ folder. If `+folder' isn't specified, a folder in the
user's _M_H
+ directory will be used, either that specified by the "Inbox:"
entry
+ in the user's profile, or the folder named "inbox". The
new mes-
+ sages being incorporated are assigned numbers starting
with the
+ next highest number in the folder. If the specified (or
default)
+ folder doesn't exist, the user will be queried prior to its
crea-
+ tion. As the messages are processed, a _s_c_a_n
listing of the new
+ mail is produced.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it
will
+ be used as the protection on the newly created messages,
otherwise
+ the _M_H default of 0644 will be used. During all
operations on mes-
+ sages, this initially assigned protection will be
preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a
protection on an
+ individual message, and its protection will be
preserved
+ thereafter.
+
+ If the switch `-audit audit-file' is specified (usually
as a
+ default switch in the profile), then _i_n_c will append a
header line
+ and a line per message to the end of the specified audit-file
with
+ the format:
+
+ <<inc>> date
+ <scan line for first message>
+ <scan line for second message>
+ <etc.>
+
+ This is useful for keeping track of volume and source of
incoming
+ mail. Eventually, _r_e_p_l, _f_o_r_w,
_c_o_m_p, and _d_i_s_t may also produce
+ audits to this (or another) file, perhaps with "Message-Id:"
infor-
+ mation to keep an exact correspondence history.
"Audit-file" will
+ be in the user's MH directory unless a full path is specified.
+
+ _I_n_c will incorporate even improperly formatted
messages into the
+ user's MH folder, inserting a blank line prior to the
offending
+ component and printing a comment identifying the bad message.
+
+ In all cases, the user's mail drop will be zeroed,
unless the
+ `-notruncate' switch is given.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -43-
INC(1)
+
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+ then _i_n_c will add each of the newly incorporated
messages to each
+ sequence named by the profile entry. This is similar
to the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments. Note that _i_n_c
will not zero
+ each sequence prior to adding messages.
+
+ The interpretation of the `-form formatfile', `-format
string', and
+ `-width columns' switches is the same as in _s_c_a_n (1).
+
+ By using the `-file name' switch, one can direct _i_n_c to
incorporate
+ messages from a file other than the user's maildrop. Note
that the
+ name file will NOT be zeroed, unless the `-truncate'
switch is
+ given.
+
+ If the envariable $MAILDROP is set, then _i_n_c uses it as
the loca-
+ tion of the user's maildrop instead of the default
(the `-
+ file name' switch still overrides this, however). If this
envari-
+ able is not set, then _i_n_c will consult the profile
entry "MailDrop"
+ for this information. If the value found is not absolute,
then it
+ is interpreted relative to the user's _M_H directory. If
the value
+ is not found, then _i_n_c will look in the standard
system location
+ for the user's maildrop.
+
+ The `-silent' switch directs _i_n_c to be quiet and not
ask any ques-
+ tions at all. This is useful for putting _i_n_c in the
background and
+ going on to other things.
+
+ If the local host is configured as a POP client, or
if the
+ `-host host' switch is given, then _i_n_c will query the
POP service
+ host as to the status of mail waiting. If the `-user user'
switch
+ is not given, then the current username is used.
Normally, _i_n_c
+ will prompt for a password to use. However, if the `-apop'
switch
+ is given, _i_n_c will generate authentication
credentials to provide
+ for origin authentication and replay protection, but which
do not
+ involve sending a password in the clear over the network.
Other-
+ wise, if the `-rpop' switch is given, then _i_n_c will try
to use a
+ "trusted" connection (ala the BSD r-commands).
+
+ If _i_n_c uses POP, then the `-pack file' switch is
considered. If
+ given, then _i_n_c simply uses the POP to
_p_a_c_k_f (1) the user's mail-
+ drop from the POP service host to the named file. This
switch is
+ provided for those users who prefer to use _m_s_h to read
their mail-
+ drops.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -44-
INC(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Inbox: To determine the inbox, default "inbox"
+ Folder-Protect: To set mode when creating a new folder
+ Msg-Protect: To set mode when creating a new
message and
+ audit-file
+ Unseen-Sequence: To name sequences denoting unseen
messages
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaulted by "Inbox" above
+ `-noaudit'
+ `-changecur'
+ `-format' defaulted as described above
+ `-nosilent'
+ `-truncate' if `-file name' not given, `-notruncate' otherwise
+ `-width' defaulted to the width of the terminal
+ `-nopack'
+ `-rpop'
+
+
+ _C_o_n_t_e_x_t
+ The folder into which messages are being incorporated will
become
+ the current folder. The first message incorporated will
become the
+ current message, unless the `-nochangecur' option is
specified.
+ This leaves the context ready for a _s_h_o_w of the first
new message.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _i_n_c. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -45-
MARK(1)
+
+
+ _N_A_M_E
+ mark - mark messages
+
+ _S_Y_N_O_P_S_I_S
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete]
[-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_a_r_k command manipulates message sequences by
adding or delet-
+ ing message numbers from folder-specific message sequences,
or by
+ listing those sequences and messages. A message sequence is
a key-
+ word, just like one of the "reserved" message names,
such as
+ "first" or "next". Unlike the "reserved" message names,
which have
+ a fixed semantics on a per-folder basis, the semantics of a
message
+ sequence may be defined, modified, and removed by the user.
Mes-
+ sage sequences are folder-specific, e.g., the sequence name
"seen"
+ in the context of folder "+inbox" need not have any relation
what-
+ soever to the sequence of the same name in a folder of a
different
+ name.
+
+ Three action switches direct the operation of _m_a_r_k.
These switches
+ are mutually exclusive: the last occurrence of any of them
over-
+ rides any previous occurrence of the other two.
+
+ The `-add' switch tells _m_a_r_k to add messages to
sequences or to
+ create a new sequence. For each sequence named
via the
+ `-sequence name' argument (which must occur at least once)
the mes-
+ sages named via `msgs' (which defaults to "cur" if no
`msgs' are
+ given), are added to the sequence. The messages to be added
need
+ not be absent from the sequence. If the `-zero' switch is
speci-
+ fied, the sequence will be emptied prior to adding the
messages.
+ Hence, `-add -zero' means that each sequence should be
initialized
+ to the indicated messages, while `-add -nozero' means that
each
+ sequence should be appended to by the indicated messages.
+
+ The `-delete' switch tells _m_a_r_k to delete messages
from sequences,
+ and is the dual of `-add'. For each of the named
sequences, the
+ named messages are removed from the sequence. These messages
need
+ not be already present in the sequence. If the `-zero'
switch is
+ specified, then all messages in the folder are appended
to the
+ sequence prior to removing the messages. Hence, `-delete
-zero'
+ means that each sequence should contain all messages except
those
+ indicated, while `-delete -nozero' means that only the
indicated
+ messages should be removed from each sequence. As
expected, the
+ command `mark -sequence seen -delete all' deletes the
sequence
+ "seen" from the current folder.
+
+ When creating (or modifying) a sequence, the `-public' switch
indi-
+ cates that the sequence should be made readable for other
_M_H users.
+ In contrast, the `-nopublic' switch indicates that the
sequence
+ should be private to the user's _M_H environment.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -46-
MARK(1)
+
+
+ The `-list' switch tells _m_a_r_k to list both the
sequences defined
+ for the folder and the messages associated with those
sequences.
+ _M_a_r_k will list the name of each sequence given by
`-sequence name'
+ and the messages associated with that sequence. If
`-sequence'
+ isn't used, all sequences will be listed, with private
sequences
+ being so indicated. The `-zero' switch does not affect the
opera-
+ tion of `-list'.
+
+ The current restrictions on sequences are:
+
+ The name used to denote a message sequence must consist
of an
+ alphabetic character followed by zero or more alphanumeric
char-
+ acters, and can not be one of the "reserved" message names
(e.g.,
+ "first", "cur", and so forth).
+
+ Only a certain number of sequences may be defined for a
given
+ folder. This number is usually limited to 26 (10 on
small sys-
+ tems).
+
+ Message ranges with user-defined sequence names are
restricted to
+ the form "name:n" or "name:-n", and refer to the first
or last
+ `n' messages of the sequence `name', respectively.
Constructs of
+ the form "name1-name2" are forbidden.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ pick (1), mh-sequence (5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-add' if `-sequence' is specified, `-list' otherwise
+ `msgs' defaults to cur (or all if `-list' is specified)
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ Use "pick sequence -list" to enumerate the messages in a
sequence
+ (such as for use by a shell script).
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -47-
MARK(1)
+
+
+ _N_A_M_E
+ mhl - produce formatted listings of MH messages
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc]
[files ...]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_l is a formatted message listing program. It can be
used as a
+ replacement for _m_o_r_e (1) (the default
_s_h_o_w_p_r_o_c ). As with _m_o_r_e,
+ each of the messages specified as arguments (or the standard
input)
+ will be output. If more than one message file is
specified, the
+ user will be prompted prior to each one, and a <RETURN> or
<EOT>
+ will begin the output, with <RETURN> clearing the
screen (if
+ appropriate), and <EOT> (usually CTRL-D) suppressing the
screen
+ clear. An <INTERRUPT> (usually CTRL-C) will abort the
current mes-
+ sage output, prompting for the next message (if there is
one), and
+ a <QUIT> (usually CTRL-\) will terminate the program
(without core
+ dump).
+
+ The `-bell' option tells _m_h_l to ring the terminal's
bell at the end
+ of each page, while the `-clear' option tells _m_h_l
to clear the
+ scree at the end of each page (or output a formfeed after
each mes-
+ sage). Both of these switches (and their inverse
counterparts)
+ take effect only if the profile entry
_m_o_r_e_p_r_o_c is defined but
+ empty, and _m_h_l is outputting to a terminal. If the
_m_o_r_e_p_r_o_c entry
+ is defined and non-empty, and _m_h_l is outputting to a
terminal, then
+ _m_h_l will cause the _m_o_r_e_p_r_o_c to be
placed between the terminal and
+ _m_h_l and the switches are ignored. Furthermore, if
the `-clear'
+ switch is used and _m_h_l'_s output is directed to a
terminal, then _m_h_l
+ will consult the $TERM and $TERMCAP envariables to
determine the
+ user's terminal type in order to find out how to clear the
screen.
+ If the `-clear' switch is used and _m_h_l'_s output is
not directed to
+ a terminal (e.g., a pipe or a file), then _m_h_l will
send a formfeed
+ after each message.
+
+ To override the default _m_o_r_e_p_r_o_c and the
profile entry, use the
+ `-moreproc program' switch. Note that _m_h_l will
never start a
+ _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+ The `-length length' and `-width width' switches set the
screen
+ length and width, respectively. These default to the values
indi-
+ cated by $TERMCAP, if appropriate, otherwise they default to
40 and
+ 80, respectively.
+
+ The default format file used by _m_h_l is called
_m_h_l._f_o_r_m_a_t (which is
+ first searched for in the user's _M_H directory, and then
sought in
+ the /_u_s_r/_b_s/_m_h-_6._8/_l_i_b directory),
this can be changed by using the
+ `-form formatfile' switch.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -48-
MHL(1)
+
+
+ Finally, the `-folder +folder' switch sets the _M_H
folder name,
+ which is used for the "messagename:" field described
below. The
+ envariable $mhfolder is consulted for the default value,
which
+ _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize
appropriately.
+
+ _M_h_l operates in two phases: 1) read and parse the
format file, and
+ 2) process each message (file). During phase 1, an
internal
+ description of the format is produced as a structured
list. In
+ phase 2, this list is walked for each message, outputting
message
+ information under the format constraints from the format file.
+
+ The "mhl.format" form file contains information controlling
screen
+ clearing, screen size, wrap-around control, transparent
text, com-
+ ponent ordering, and component formatting. Also, a list of
com-
+ ponents to ignore may be specified, and a couple of
"special" com-
+ ponents are defined to provide added functionality. Message
output
+ will be in the order specified by the order in the format
file.
+
+ Each line of mhl.format has one of the formats:
+
+ ;comment
+ :cleartext
+ variable[,variable...]
+ component:[variable,...]
+
+ A line beginning with a `;' is a comment, and is ignored. A
line
+ beginning with a `:' is clear text, and is output exactly as
is. A
+ line containing only a `:' produces a blank line in the
output. A
+ line beginning with "component:" defines the format for the
speci-
+ fied component, and finally, remaining lines define the
global
+ environment.
+
+ For example, the line:
+
+
width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+ defines the screen size to be 80 columns by 40 rows,
specifies that
+ the screen should be cleared prior to each page, that the
overflow
+ indentation is 5, and that overflow text should be
flagged with
+ "***".
+
+ Following are all of the current variables and their
arguments. If
+ they follow a component, they apply only to that component,
other-
+ wise, their affect is global. Since the whole format is
parsed
+ before any output processing, the last global switch setting
for a
+ variable applies to the whole message if that variable is
used in a
+ global context (i.e., bell, clearscreen, width, length).
+
+ _v_a_r_i_a_b_l_e _t_y_p_e
_s_e_m_a_n_t_i_c_s
+ width integer screen width or component width
+ length integer screen length or component
length
+ offset integer positions to indent
"component: "
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -49-
MHL(1)
+
+
+ overflowtext string text to use at the beginning
of an
+ overflow line
+ overflowoffset integer positions to indent overflow
lines
+ compwidth integer positions to indent component
text
+ after the first line is output
+ uppercase flag output text of this component
in all
+ upper case
+ nouppercase flag don't uppercase
+ clearscreen flag/G clear the screen prior to each
page
+ noclearscreen flag/G don't clearscreen
+ bell flag/G ring the bell at the end of
each page
+ nobell flag/G don't bell
+ component string/L name to use instead of
"component" for
+ this component
+ nocomponent flag don't output "component: " for
this
+ component
+ center flag center component on line
(works for
+ one-line components only)
+ nocenter flag don't center
+ leftadjust flag strip off leading whitespace
on each
+ line of text
+ noleftadjust flag don't leftadjust
+ compress flag change newlines in text to
spaces
+ nocompress flag don't compress
+ split flag don't combine multiple fields
into a single field
+ nosplit flag combine multiple fields into a
single field
+ newline flag print newline at end of
components (default)
+ nonewline flag don't print newline at end of
components
+ formatfield string format string for this
component (see below)
+ addrfield flag field contains addresses
+ datefield flag field contains dates
+
+ To specify the value of integer-valued and string-valued
variables,
+ follow their name with an equals-sign and the
value.
+ Integer-valued variables are given decimal values,
while
+ string-valued variables are given arbitrary text
bracketed by
+ double-quotes. If a value is suffixed by "/G" or "/L",
then its
+ value is useful in a global-only or local-only context
(respec-
+ tively).
+
+ A line of the form:
+
+ ignores=component,...
+
+ specifies a list of components which are never output.
+
+ The component "MessageName" (case-insensitive) will
output the
+ actual message name (file name) preceded by the folder name
if one
+ is specified or found in the environment. The format is
identical
+ to that produced by the `-header' option to _s_h_o_w.
+
+ The component "Extras" will output all of the components
of the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -50-
MHL(1)
+
+
+ message which were not matched by explicit components, or
included
+ in the ignore list. If this component is not specified, an
ignore
+ list is not needed since all non-specified components
will be
+ ignored.
+
+ If "nocomponent" is NOT specified, then the component name
will be
+ output as it appears in the format file.
+
+ The default format is:
+
+ : -- using template mhl.format --
+ overflowtext="***",overflowoffset=5
+ leftadjust,compwidth=9
+ ignores=msgid,message-id,received
+
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+ To:
+ cc:
+ :
+ From:
+ Subject:
+ :
+ extras:nocomponent
+ :
+
body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+ The variable "formatfield" specifies a format string
(see
+ _m_h-_f_o_r_m_a_t (5)). The flag variables
"addrfield" and "datefield"
+ (which are mutually exclusive), tell _m_h_l to interpret
the escapes
+ in the format string as either addresses or dates,
respectively.
+
+ By default, _m_h_l does not apply any formatting string to
fields con-
+ taining address or dates (see _m_h-_m_a_i_l (5)
for a list of these
+ fields). Note that this results in faster operation since
_m_h_l must
+ parse both addresses and dates in order to apply a format
string to
+ them. If desired, _m_h_l can be given a default format
string for
+ either address or date fields (but not both). To do
this, on a
+ global line specify: either the flag addrfield or datefield,
along
+ with the apropriate formatfield variable string.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/mhl.format The message template
+ or <mh-dir>/mhl.format Rather than the standard
template
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ moreproc: Program to use as interactive front-end
+
+
+ _S_e_e _A_l_s_o
+ show(1), ap(8), dp(8)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -51-
MHL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-bell'
+ `-noclear'
+ `-length 40'
+ `-width 80'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ There should be some way to pass `bell' and `clear'
information to
+ the front-end.
+
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+ The "nonewline" option interacts badly with "compress" and
"split".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -52-
MHMAIL(1)
+
+
+ _N_A_M_E
+ mhmail - send or read mail
+
+ _S_Y_N_O_P_S_I_S
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H_m_a_i_l is intended as a replacement for the
standard Bell mail pro-
+ gram (_b_e_l_l_m_a_i_l (1)), compatible with
_M_H. When invoked without
+ arguments, it simply invokes _i_n_c (1) to incorporate
new messages
+ from the user's maildrop. When one or more users is
specified, a
+ message is read from the standard input and spooled to a
temporary
+ file. _M_H_m_a_i_l then invokes _p_o_s_t (8) with
the name of the temporary
+ file as its argument to deliver the message to the specified
user.
+
+ The `-subject subject' switch can be used to specify the
"Subject:"
+ field of the message. The `-body text' switch can be
used to
+ specify the text of the message; if it is specified, then the
stan-
+ dard input is not read. Normally, addresses appearing as
arguments
+ are put in the "To:" field. If the `-cc' switch is
used, all
+ addresses following it are placed in the "cc:" field.
+
+ By using `-from addr', you can specify the "From:" header
of the
+ draft. Naturally, _p_o_s_t will fill-in the
"Sender:" header
+ correctly.
+
+ This program is intended for the use of programs such as
_a_t (1),
+ which expect to send mail automatically to various users.
Nor-
+ mally, real people (as opposed to the "unreal" ones) will
prefer to
+ use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/bin/inc Program to incorporate a
maildrop into a folder
+ /usr/bs/mh-6.8/lib/post Program to deliver a
message
+ /tmp/mhmail* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ inc(1), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -53-
MHMAIL(1)
+
+
+ _C_o_n_t_e_x_t
+ If _i_n_c is invoked, then _i_n_c's context changes
occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -54-
MHN(1)
+
+
+ _N_A_M_E
+ mhn - multi-media MH
+
+ _S_Y_N_O_P_S_I_S
+ mhn [+folder] [msgs] [-part number]... [-type content]...
+ [-list [-headers] [-noheaders]
+ [-realsize] [-norealsize]] [-nolist]
+ [-show [-serialonly] [-noserialonly]]
+ [-form formfile]] [-noshow]
+ [-store [-auto] [-noauto]] [-nostore]
+ [-verbose] [-noverbose] [-rfc934mode] [-norfc934mode]
+ [-ebcdicsafe] [-noebcdicsafe]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_h_n command manipulates multi-media messages as
specified in
+ RFC 1341.
+
+ Three action switches direct the operation of _m_h_n,
namely `-list',
+ `-show', and `-store'. Any of these switches may be
used con-
+ currently. Normally these action switches will operate on
the con-
+ tent of each of the named messages. However, by using the
`-part'
+ and `-type' switches, the scope of the operation can be
focused on
+ particular subparts (of a multipart content) and/or
particular con-
+ tent types.
+
+ A part specification consists of a series of numbers
separated by
+ dots. For example, in a multipart content containing three
parts,
+ these would be named as 1, 2, and 3, respectively. If part
2 was
+ also a multipart content containing two parts, these would be
named
+ as 2.1 and 2.2, respectively. Note that the `-part'
switch is
+ effective for only messages containing a multipart content.
If a
+ message has some other kind of content, or if the part is
itself
+ another multipart content, the `-part' switch will not
prevent the
+ content from being acted upon.
+
+ A content specification consists of a content type and a
subtype.
+ The initial list of "standard" content types and subtypes
can be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -55-
MHN(1)
+
+
+ found in RFC 1341. A list of commonly used contents is
briefly
+ reproduced here:
+
+ Type Subtypes
+ ---- --------
+ text plain, richtext
+ multipart mixed, alternative, digest, parallel
+ message rfc822, partial, external-body
+ application octet-stream, oda, postscript
+ image jpeg, gif, x-pbm, x-pgm, x-ppm, x-xwd
+ audio basic
+ video mpeg
+
+ Subtypes are mandatory. To specify a content, regardless
of its
+ subtype, just use the name of the content, e.g.,
"audio". To
+ specify a specific subtype, separate the two with a slash,
e.g.,
+ "audio/basic". Note that regardless of the values given
to the
+ `-type' switch, a multipart content is always acted upon.
Further
+ note that if the `-type' switch is used, and it is desirable
to act
+ on a message/external-body content, then the `-type' switch
must be
+ used twice: once for message/external-body and once for the
content
+ externally referenced.
+
+
+ _L_i_s_t_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+ The `-list' switch tells _m_h_n to list the table of
contents associ-
+ ated with the named messages. The `-headers' switch
indicates that
+ a one-line banner should be displayed above the listing.
The
+ `-realsize' switch tells _m_h_n to evaluate the
"native" (decoded)
+ format of each content prior to listing. This provides an
accurate
+ count at the expense of a small delay.
+
+
+ _S_h_o_w_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+ The `-show' switch tells _m_h_n to display the contents of
the named
+ messages. The headers of the message are displayed
with the
+ _m_h_l_p_r_o_c, using format file
_m_h_l._h_e_a_d_e_r_s. (The choice of format file
+ can be overridden by the `-form formfile' switch.)
+
+ _m_h_n will look for information in the user's profile
to determine
+ how the different contents should be displayed. This is
accom-
+ plished by consulting a display string, and executing it
under
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -56-
MHN(1)
+
+
+ /bin/sh, with the standard input set to the content. The
display
+ string may contain these escapes:
+
+ %a additional arguments
+ %e exclusive execution
+ %f filename containing content
+ %F %e, %f, and stdin is terminal not content
+ %l display listing prior to displaying content
+ %p %l, and ask for confirmation
+ %s subtype
+
+ For those display strings containing the e- or F-escape,
_m_h_n will
+ execute at most one of these at any given time. Although
the F-
+ escape expands to be the filename containing the content,
the e-
+ escape has no expansion as far as the shell is concerned.
+
+ When the p-escape prompts for confirmation, typing INTR
(usually
+ control-C) will tell _m_h_n not to display that
content. Further,
+ when _m_h_n is display a content, typing QUIT (usually
control-\) will
+ tell _m_h_n to wrap things up immediately.
+
+ First, _m_h_n will look for an entry of the form:
+
+ mhn-show-<type>/<subtype>
+
+ to determine the command to use to display the content. If
this
+ isn't found, _m_h_n will look for an entry of the form:
+
+ mhn-show-<type>
+
+ to determine the display command. If this isn't found,
_m_h_n has two
+ default values:
+
+ mhn-show-text/plain: %pmoreproc '%F'
+ mhn-show-message/rfc822: %pshow -file '%F'
+
+ If neither apply, _m_h_n will check to see if the
message has a
+ application/octet-stream content with parameter "type=tar".
If so,
+ _m_h_n will use an appropriate command. If not, _m_h_n
will complain.
+
+ Example entries might be:
+
+ mhn-show-audio/basic: raw2audio 2>/dev/null | play
+ mhn-show-image: xv '%f'
+ mhn-show-application/PostScript: lpr -Pps
+
+ Note that when using the f- or F-escape, it's a good idea
to use
+ single-quotes around the escape. This prevents
misinterpretation
+ by the shell of any funny characters that might be present
in the
+ filename.
+
+ Because the text content might be in a non-ASCII character
set,
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -57-
MHN(1)
+
+
+ when _m_h_n encounters a "charset" parameter for this
content, it
+ checks to see whether the environment variable $MM_CHARSET
is set
+ and whether the value of this environment variable is equal
to the
+ value of the charset parameter. If not, then _m_h_n will
look for an
+ entry of the form:
+
+ mhn-charset-<charset>
+
+ which should contain a command creating an environment to
render
+ the character set. This command string should containing a
single
+ "%s", which will be filled-in with the command to display the
con-
+ tent.
+
+ An example entry might be:
+
+ mhn-charset-iso-8859-1: xterm -fn
'-*-*-medium-r-normal-*-*-
+ 120-*-*-c-*-iso8859-*' -e %s
+
+ Note that many pagination programs strip off the high-order
bit.
+ However, newer releases of the _l_e_s_s program have
modest support for
+ single-octet character sets. The source to _l_e_s_s
version 177, which
+ has such support, is found in the MH source tree
under
+ miscellany/less-177. In order to view messages sent in
the ISO
+ 8859/1 character set using _l_e_s_s, put these lines
in your .login
+ file:
+
+ setenv LESSCHARSET latin1
+ setenv LESS "-f"
+
+ The first line tells _l_e_s_s to use 8859/1 definition
for determing
+ whether a character is "normal", "control", or
"binary". The
+ second line tells _l_e_s_s not to warn you if it
encounters a file that
+ has non-ASCII characters. Then, simply set the moreproc
profile
+ entry to _l_e_s_s, and it will get called automatically.
(To handle
+ other single-octet character sets, look at the
_l_e_s_s (1) manual
+ entry for information about the LESSCHARDEF environment
variable.)
+
+ Finally, _m_h_n will process each message serially -- it
won't start
+ showing the next message until all the commands executed to
display
+ the current message have terminated. In the case of a
multipart
+ content, the content contains advice indicating if the parts
should
+ be displayed serially or in parallel. Because this may cause
con-
+ fusion, particularly on uni-window displays, the
`-serialonly'
+ switch can be given to tell _m_h_n to never display parts
in parallel.
+
+
+ _S_t_o_r_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+ The `-store' switch tells _m_h_n to store the contents of
the named
+ messages in "native" (decoded) format. Two things must be
deter-
+ mined: the directory to store the content, and the
filenames.
+ Files are written in the directory given by the mhn-storage
profile
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -58-
MHN(1)
+
+
+ entry, e.g.,
+
+ mhn-storage: /tmp
+
+ If this entry isn't present, the current working directory is
used.
+
+ _m_h_n will look for information in the user's profile
to determine
+ how the different contents should be stored. This is
achieved
+ through the use of a formatting string, which may contain
these
+ escapes:
+
+ %m message number
+ %P .part
+ %p part
+ %s subtype
+
+ If the content isn't part of a multipart content, the
p-escapes are
+ ignored. Note that if the formatting string starts with
a "+"
+ character, then these escapes are ignored, and the
content is
+ stored in the named folder. (A formatting string consisting
solely
+ of a "+" character indicates the current folder.) Further, a
for-
+ matting string consisting solely of a "-" character
indicates the
+ standard-output.
+
+ First, _m_h_n will look for an entry of the form:
+
+ mhn-store-<type>/<subtype>
+
+ to determine the formatting string. If this isn't found,
_m_h_n will
+ look for an entry of the form:
+
+ mhn-store-<type>
+
+ to determine the formatting string. If this isn't found,
_m_h_n will
+ check to see if the content is application/octet-stream with
param-
+ eter "type=tar". If so, _m_h_n will choose an
appropriate filename.
+ If the content is not application/octet-stream, then
_m_h_n will check
+ to see if the content is a message. If so, _m_h_n will
use the value
+ "+". If not, _m_h_n will use the value "%m%P.%s".
+
+ Note that if the formatting string starts with a '/', then
content
+ will be stored in the full path given (rather than using the
value
+ of mhn-storage or the current working directory.) Similarly,
if the
+ formatting string starts with a '|', then _m_h_n will
execute a com-
+ mand which should ultimately store the content. Note that
before
+ executing the command, _m_h_n will change to the
appropriate direc-
+ tory. Also note that if the formatting string starts with a
'|',
+ then _m_h_n will also honor the a-escape when processing
the format-
+ ting string.
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -59-
MHN(1)
+
+
+ Example entries might be:
+
+ mhn-store-text: %m%P.txt
+ mhn-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1
> %m%P.au
+ mhn-store-application/PostScript: %m%P.ps
+
+ Further, note that when asked to store a content containing a
par-
+ tial message, _m_h_n will try to locate all of the
portions and com-
+ bine them accordingly. Thus, if someone's sent you a
message in
+ several parts, you might put them all in their own folder and
do:
+
+ mhn all -store
+
+ This will store exactly one message, containing the sum
of the
+ parts. Note that if _m_h_n can not locate each part,
it will not
+ store anything.
+
+ Finally, if the `-auto' switch is given and the content
contains
+ information indicating the filename the content should be
stored as
+ (and if the filename doesn't begin with a '/'), then the
filename
+ from the content will be used instead.
+
+
+ _E_x_t_e_r_n_a_l _A_c_c_e_s_s
+
+ For contents of type message/external-body, _m_h_n
supports these
+ access-types:
+
+ afs
+ anon-ftp
+ ftp
+ local-file
+ mail-server
+
+ If your system supports a SOCKETs interface to TCP/IP,
then _m_h_n
+ will use a built-in FTP client. Otherwise, _m_h_n will
look for the
+ mhn-access-ftp profile entry, e.g.,
+
+ mhn-access-ftp: myftp.sh
+
+ to determine the pathname of a program to perform
the FTP
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -60-
MHN(1)
+
+
+ retrieval. This program is invoked with these arguments:
+
+ domain name of FTP-site
+ username
+ password
+ remote directory
+ remote filename
+ local filename
+ "ascii" or "binary"
+
+ The program should terminate with a zero-valued exit-status
if the
+ retrieval is success.
+
+
+ _T_h_e _C_o_n_t_e_n_t _C_a_c_h_e
+
+ When _m_h_n encounters an external content containing a
"Content-ID:"
+ field, and if the content allows caching, then _m_h_n
looks for the
+ profile entry mhn-cache to determine if the content should be
read
+ from/written to a cache. Any content written to the cache
will, by
+ default, be world-readable. (To prevent this, use a
directory name
+ with the desired read and execute permissions.) The
mhn-cache pro-
+ file entry names the directory used for caching, e.g.,
+
+ mhn-cache: /tmp
+
+ might be used if you didn't care that the cache got wiped
after
+ each reboot of the system.
+
+
+ _C_o_m_p_o_s_i_n_g _t_h_e _C_o_n_t_e_n_t_s
+
+ The _m_h_n program can also be used as a simple editor to
aid in com-
+ posing multi-media messages. When invoked by a
_w_h_a_t_n_o_w program,
+ _m_h_n will expect the body of the draft to be formatted
as an "_m_h_n
+ composition file."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -61-
MHN(1)
+
+
+ The syntax of this is straight-forward:
+
+ body ::= 1*(content | EOL)
+
+ content ::= directive | plaintext
+
+ directive ::= "#" type "/" subtype
+ 0*(";" attribute "=" value)
+ [ "(" comment ")" ]
+ [ "[" description "]" ]
+ [ filename ]
+ EOL
+
+ | "#@" type "/" subtype
+ 0*(";" attribute "=" value)
+ [ "(" comment ")" ]
+ [ "[" description "]" ]
+ external-parameters
+ EOL
+
+ | "#forw"
+ [ "[" description "]" ]
+ [ "+"folder ] [ 0*msg ]
+ EOL
+
+ | "#begin"
+ [ "[" description "]" ]
+ [ "alternative"
+ | "parallel" ]
+ EOL
+ 1*body
+ "#end" EOL
+
+ plaintext ::= [ "Content-Description:"
+ description EOL EOL ]
+ 1*line
+ [ "#" EOL ]
+
+ | "#<" type "/" subtype
+ 0*(";" attribute "=" value)
+ [ "(" comment ")" ]
+ [ "[" description "]" ]
+ EOL
+ 1*line
+ [ "#" EOL ]
+
+ line ::= "##" text EOL
+ -- interpreted as "#"text EOL
+ | text EOL
+
+ Basically, the body contains one or more contents. A content
con-
+ sists of either a directive, indicated with a "#" as the
first
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -62-
MHN(1)
+
+
+ character of a line; or, plaintext (one or more lines of
text).
+ The continuation character, "\", may be used to enter a
single
+ directive on more than one line, e.g.,
+
+ address@hidden/octet-stream; \
+ type=tar; \
+ conversions=x-compress
+
+ There are four kinds of directives: "type" directives, which
name
+ the type and subtype of the content; "external-type"
directives,
+ which also name the type and subtype of the content; the
"forw"
+ directive, which is used to forward a digest of messages;
and, the
+ "begin" directive, which is used to create a multipart
content.
+
+ For the type directives, the user may optionally specify the
name
+ of a file containing the contents in "native" (decoded)
format.
+ (If the filename starts with the "|" character, then this
gives a
+ command whose output is captured accordingly.) If a filename
is not
+ given, _m_h_n will look for information in the user's
profile to
+ determine how the different contents should be composed.
This is
+ accomplished by consulting a composition string, and
executing it
+ under /bin/sh, with the standard output set to the
content. The
+ composition string may contain these escapes:
+
+ %a additional arguments
+ %f filename containing content
+ %F %f, and stdout is not re-directed
+ %s subtype
+
+ First, _m_h_n will look for an entry of the form:
+
+ mhn-compose-<type>/<subtype>
+
+ to determine the command to use to compose the content. If
this
+ isn't found, _m_h_n will look for an entry of the form:
+
+ mhn-compose-<type>
+
+ to determine the composition command. If this isn't
found, _m_h_n
+ will complain.
+
+ An example entry might be:
+
+ mhn-compose-audio/basic: record | raw2audio -F
+
+ Because commands like these will vary, depending on the
display
+ environment used for login, composition strings for
different con-
+ tents should probably be put in the file specified by the
$MHN
+ environment variable, instead of directly in your user
profile.
+
+ The external-type directives are used to provide a reference
to a
+ content, rather than enclosing the contents itself. Hence,
instead
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -63-
MHN(1)
+
+
+ of providing a filename as with the type directives,
external-
+ parameters are supplied. These look like regular
parameters, so
+ they must be separated accordingly, e.g.,
+
+ address@hidden/octet-stream; \
+ type=tar; \
+ conversions=x-compress [] \
+ access-type=anon-ftp; \
+ name="mh-mime.tar.Z"; \
+ directory="mrose/mh-mime"; \
+ site="ftp.ics.uci.edu"
+
+ By specifying "[]", an empty description string is given,
and the
+ start of the external-parameters is identified. These
parameters
+ are of the form:
+
+ access-type= usually _a_n_o_n-_f_t_p or
_m_a_i_l-_s_e_r_v_e_r
+ name= filename
+ directory= directoryname (optional)
+ site= hostname
+ mode= usually _a_s_c_i_i or _i_m_a_g_e
(optional)
+ server= mailbox
+ body= command to send for retrieval
+
+
+ For the forw directive, the user may optionally specify the
name of
+ the folder and which messages are to be forwarded. if a
folder is
+ not given, it defaults to the current folder. Similarly, if
a mes-
+ sage is not given, it defaults to the current message.
Hence, the
+ forw directive is similar to the _f_o_r_w (1) command,
except that the
+ former uses the MIME rules for encapsulation rather than
those
+ specified in RFC 934. Usage of the `-rfc934mode' switch
indicates
+ whether _m_h_n should attempt to utilize the
encapsulation rules in
+ such a way as to appear that RFC 934 is being used. If
given, then
+ RFC 934-compliant user-agents should be able to burst the
message
+ on reception -- providing that the messages being
encapsulated do
+ not contain encapsulated messages themselves. The drawback
of this
+ approach is that the encapsulations are generated by
placing an
+ extra newline at the end of the body of each message.
+
+ For the begin directive, the user must specify at least one
content
+ between the begin and end pairs.
+
+ For all of these directives, the user may include a brief
descrip-
+ tion of the content between the "[" character and the "]"
charac-
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -64-
MHN(1)
+
+
+ ter. Putting this all together, here is a brief example of
what a
+ user's components file might look like:
+
+ To:
+ cc:
+ Subject:
+ --------
+ #audio/basic [Flint phone] \
+ |raw2audio -F < /home/mrose/lib/multi-media/flint.au
+ #image/gif [MTR's photo] \
+ /home/mrose/lib/multi-media/mrose.gif
+
+ For a later example, we'll call this components file
_m_h_n_c_o_m_p_s.
+
+ As noted earlier, in addition to directives, plaintext
can be
+ present. Plaintext is gathered, until a directive is found
or the
+ draft is exhausted, and this is made to form a text
content. If
+ the plaintext must contain a "#" at the beginning of a line,
simply
+ double it, e.g.,
+
+ ##when sent, this line will start with only one #
+
+ If you want to end the plaintext prior to a directive,
e.g., to
+ have two plaintext contents adjacent, simply insert a line
contain-
+ ing a single "#" character, e.g.,
+
+ this is the first content
+ #
+ and this is the second
+
+ Finally, if the plaintext starts with a line of the form:
+
+ Content-Description: text
+
+ then this will be used to describe the plaintext content.
NOTE
+ WELL: you must follow this line with a blank line before
starting
+ your text.
+
+ By default, plaintext is captured as a text/plain content.
You can
+ override this by starting the plaintext with "#<"
followed by a
+ content-type specification, e.g.,
+
+ #<text/richtext
+ this content will be tagged as text/richtext
+ #
+ and this content will be tagged as text/plain
+
+ Note that if you use the "#<" plaintext-form, then the
content-
+ description must be on the same line which identifies the
content
+ type of the plaintext.
+
+ If _m_h_n is successful, it renames the original draft to
start with
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -65-
MHN(1)
+
+
+ the "," character and end with the string ".orig", e.g., if
you are
+ editing the file "draft", it will be renamed to
",draft.orig".
+ This allows you to easily recover the _m_h_n composition
file.
+
+
+ _A_u_t_o_m_a_t_i_c _C_o_m_p_o_s_i_t_i_o_n
+
+ Note that MH will not invoke _m_h_n automatically, unless
you add this
+ line to your .mh_profile file:
+
+ automhnproc: mhn
+
+ Otherwise, you must specifically give the command
+
+ What now? edit mhn
+
+ prior to sending the draft.
+
+ You can easily tailor MH to help you remember to do this.
Suppose
+ you have these lines in your profile:
+
+ mcomp: -editor mprompter -form mhncomps
+ mprompter: -noprepend -norapid
+ mprompter-next: mhn
+
+ where _m_c_o_m_p is a link to _c_o_m_p (1), and
_m_p_r_o_m_p_t_e_r is a link to
+ _p_r_o_m_p_t_e_r (1). Then to send a message using
the _m_h_n_c_o_m_p_s components
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -66-
MHN(1)
+
+
+ file above, the sequence is:
+
+ % mcomp
+ To: address@hidden
+ cc:
+ Subject: multi-media message
+ --------
+ #audio/basic [Flint phone] \
+ |raw2audio -F < /home/mrose/lib/multi-media/flint.au
+ #image/gif [MTR's photo] \
+ /home/mrose/lib/multi-media/mrose.gif
+
+ --------Enter additional text
+
+ This message contains three contents.
+ <CTRL-D>
+ --------
+
+ What now? edit (this invokes _m_h_n)
+
+ What now? send
+
+ You have to remember to type the additional edit command,
but it
+ should be fairly obvious from the interaction.
+
+ Finally, you should consider adding this line to your profile:
+
+ lproc: show
+
+ This way, if you decide to list after invoking _m_h_n as
your editor,
+ the command
+
+ What now? list
+
+ will work as you expect.
+
+
+ _S_e_n_d_i_n_g _F_i_l_e_s _v_i_a _M_a_i_l
+
+ When you want to send a bunch of files to someone, you can
run the
+ _v_i_a_m_a_i_l shell script, which is similar the
tarmail command:
+
+ /usr/bs/mh-6.8/lib/viamail mailpath "subject" files ...
+
+ _v_i_a_m_a_i_l will archive the directories/files you
name with _t_a_r (1),
+ and then mail the compressed archive to the `mailpath'
with the
+ given `subject'. The archive will be automatically split up
into
+ as many messages as necessary in order to get past most
mailers.
+
+ Sometimes you want _v_i_a_m_a_i_l to pause after
posting a partial mes-
+ sage. This is usually the case when you are running
_s_e_n_d_m_a_i_l and
+ expect to generate a lot of partial messages. If the
first
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -67-
MHN(1)
+
+
+ argument given to _v_i_a_m_a_i_l starts with a
dash, then it is inter-
+ preted as the number of seconds to pause in between postings,
e.g.,
+
+ /usr/bs/mh-6.8/lib/viamail -300 mailpath "subject" files
...
+
+ will pause 5 minutes in between each posting.
+
+ When these messages are received, invoke _m_h_n once, with
the list of
+ messages, and the `-store' command. The _m_h_n
program will then
+ store exactly one message containing the archive. You can
then use
+ `-show' to find out what's inside; possibly followed by
`-store'
+ to write the archive to a file where you can
subsequently
+ uncompress and untar it, e.g.,
+
+ % mhn -list all
+ msg part type/subtype size description
+ 1 message/partial 47K part 1 of 4
+ 2 message/partial 47K part 2 of 4
+ 3 message/partial 47K part 3 of 4
+ 4 message/partial 18K part 4 of 4
+ % mhn -store all
+ % mhn -list -verbose last
+ msg part type/subtype size description
+ 5 application/octet-stream 118K
+ (extract with uncompress | tar xvpf -)
+ type=tar
+ conversions=x-compress
+ % mhn -show last
+ msg part type/subtype size description
+ 5 application/octet-stream 118K
+ -- headers of message, followed by _t_a_r listing
appears here
+ % mhn -store last
+ % uncompress < 5.tar.Z | tar xvpf -
+
+ Alternately, by using the `-auto' switch, _m_h_n will
automatically do
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -68-
MHN(1)
+
+
+ the extraction for you, e.g.,
+
+ % mhn -list all
+ msg part type/subtype size description
+ 1 message/partial 47K part 1 of 4
+ 2 message/partial 47K part 2 of 4
+ 3 message/partial 47K part 3 of 4
+ 4 message/partial 18K part 4 of 4
+ % mhn -store all
+ % mhn -list -verbose last
+ msg part type/subtype size description
+ 5 application/octet-stream 118K
+ (extract with uncompress | tar xvpf -)
+ type=tar
+ conversions=x-compress
+ % mhn -show last
+ msg part type/subtype size description
+ 5 application/octet-stream 118K
+ -- headers of message, followed by _t_a_r listing
appears here
+ % mhn -store -auto last
+ -- _t_a_r listing appears here as files are extracted
+
+ As the second _t_a_r listing is generated, the files are
extracted. A
+ prudent user will never put `-auto' in the .mh_profile
file. The
+ correct procedure is to first use `-show', to find out what
will be
+ extracted. Then _m_h_n can be invoked with `-store'
and `-auto' to
+ perform the extraction.
+
+
+ _U_s_e_r _E_n_v_i_r_o_n_m_e_n_t
+
+ Because the display environment in which _m_h_n operates
may vary for
+ a user, _m_h_n will look for the environment
variable $MHN. If
+ present, this specifies the name of an additional user
profile
+ which should be read. Hence, when a user logs in on a
particular
+ display device, this environment variable should be set to
refer to
+ a file containing definitions useful for the display device.
Nor-
+ mally, only entries of the form
+
+ mhn-show-<type>/<subtype>
+ mhn-show-<type>
+
+ need be present. Finally, _m_h_n will attempt to consult
one other
+ additional user profile, e.g.,
+
+ /usr/bs/mh-6.8/lib/mhn_defaults
+
+ which is created automatically during MH installation.
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHN(1) -69-
MHN(1)
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $MHN Additional profile
entries
+ /usr/bs/mh-6.8/lib/mhn_defaults System-default profile
entries
+ /usr/bs/mh-6.8/lib/mhl.headers The headers template
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ mhlproc: Default program to display message
headers
+ mhn-access-ftp: Program to retrieve contents via FTP
+ mhn-cache Directory to store cached external
contents
+ mhn-charset-<charset>Template for environment to render
character
+ sets
+ mhn-compose-<type>* Template for composing contents
+ mhn-show-<type>* Template for displaying contents
+ mhn-storage Directory to store contents
+ mhn-store-<type>* Template for storing contents
+ moreproc: Default program to display text/plain
content
+
+
+ _S_e_e _A_l_s_o
+ mhl(1)
+ _M_I_M_E: _M_e_c_h_a_n_i_s_m_s _f_o_r
_S_p_e_c_i_f_y_i_n_g _a_n_d _D_e_s_c_r_i_b_i_n_g
_t_h_e _F_o_r_m_a_t _o_f _I_n_t_e_r-
+ _n_e_t _M_e_s_s_a_g_e _B_o_d_i_e_s (RFC 1341),
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (RFC 934).
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-noauto'
+ `-noebcdicsafe'
+ `-form mhl.headers'
+ `-headers'
+ `-realsize'
+ `-rfc934mode'
+ `-noserialonly'
+ `-show'
+ `-noverbose'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
last
+ message selected will become the current message.
+
+
+ _B_u_g_s
+ Partial messages contained within a multipart content
are not
+ reassembled with the `-store' switch.
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -70-
MHOOK(1)
+
+
+ _N_A_M_E
+ mhook, rcvdist, rcvpack, rcvtty - MH receive-mail hooks
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/rcvdist [-form formfile] [switches for
_p_o_s_t_p_r_o_c]
+ address ... [-help]
+
+ /usr/bs/mh-6.8/lib/rcvpack file [-help]
+
+ /usr/bs/mh-6.8/lib/rcvtty [command] [-form formatfile]
+ [-format string] [-bell] [-nobell] [-newline]
[-nonewline]
+ [-biff] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ A receive-mail hook is a program that is run whenever you
receive a
+ mail message. You do NOT invoke the hook yourself, rather
the hook
+ is invoked on your behalf by your system's Message Transport
Agent.
+ See _s_l_o_c_a_l (1) for details on how to activate
receive-mail hooks on
+ your system.
+
+ Four programs are currently available as part of
_M_H, _r_c_v_d_i_s_t
+ (redistribute incoming messages to additional recipients),
_r_c_v_p_a_c_k
+ (save incoming messages in a _p_a_c_k_f'd file), and
_r_c_v_t_t_y (notify user
+ of incoming messages). The fourth program,
_r_c_v_s_t_o_r_e (1) is
+ described separately. They all reside in the
/_u_s_r/_b_s/_m_h-_6._8/_l_i_b/
+ directory.
+
+ The _r_c_v_d_i_s_t program will resend a copy of the
message to all of the
+ addresses listed on its command line. It uses the format
string
+ facility described in _m_h-_f_o_r_m_a_t (5).
+
+ The _r_c_v_p_a_c_k program will append a copy of the
message to the file
+ listed on its command line. Its use is obsoleted by the
"file"
+ action of _s_l_o_c_a_l.
+
+ The _r_c_v_t_t_y program executes the named file with
the message as its
+ standard input, and writes the resulting output on your
terminal.
+
+ If no file is specified, or is bogus, etc., then
_r_c_v_t_t_y will
+ instead write a one-line scan listing. Either
the
+ `-form formatfile' or `-format string' option may be used to
over-
+ ride the default output format (see
_m_h-_f_o_r_m_a_t (5)). A newline is
+ output before the message output, and the terminal bell is
rung
+ after the output. The `-nonewline' and `-nobell'
options will
+ inhibit these functions.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _r_c_v_t_t_y also
+ recognizes the following additional
_c_o_m_p_o_n_e_n_t escapes:
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -71-
MHOOK(1)
+
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ body string the (compressed) first part of the body
+ dtimenow date the current date
+ folder string the name of the current folder
+
+ Normally, _r_c_v_t_t_y obeys write permission as
granted by _m_e_s_g (1).
+ With the `-biff' option, _r_c_v_t_t_y will obey the
notification status
+ set by _b_i_f_f (1) instead. If the terminal access
daemon (TTYD) is
+ available on your system, then _r_c_v_t_t_y will give
its output to the
+ daemon for output instead of writing on the user's terminal.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+ $HOME/.maildelivery The file controlling
local delivery
+ /usr/bs/mh-6.8/lib/maildelivery Rather than the standard
file
+
+
+ _S_e_e _A_l_s_o
+ rcvstore (1), mh-format(5), slocal(1)
+
+
+ _B_u_g_s
+ Only two return codes are meaningful, others should be.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPARAM(1) -72-
MHPARAM(1)
+
+
+ _N_A_M_E
+ mhparam - print MH profile components
+
+ _S_Y_N_O_P_S_I_S
+ mhparam [components] [-all] [-component] [-nocomponent]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_p_a_r_a_m writes the value of the specified
profile component to the
+ standard output separated by newlines. If the profile
component is
+ not present, the default value (or nothing if there is no
default)
+ is printed.
+
+ If more than one component is specified in the `components'
list,
+ the component value is preceded by the component name. If
`-com-
+ ponent' is specified, the component name is displayed even
when
+ only one component is specified. If `-nocomponent' is
specified,
+ the component name is not displayed even when more than one
com-
+ ponent is specified.
+
+ If `-all' is specified, all components if the MH
profile are
+ displayed and other arguments are ignored.
+
+ Examples:
+
+ % mhparam path
+ Mail
+
+ % mhparam mhlproc
+ /usr/bs/mh-6.8/lib/mhl
+
+ % mhparam -component path
+ Path: Mail
+
+ % mhparam AliasFile rmmproc
+ AliasFile: aliases
+ rmmproc: rmmproc
+
+ % mhparam -nocomponent AliasFile rmmproc
+ aliases
+ rmmproc
+
+ _M_h_p_a_r_a_m is also useful in back-quoted
operations:
+
+ % fgrep cornell.edu `mhpath +`/`mhparam aliasfile`
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPARAM(1) -73-
MHPARAM(1)
+
+
+ _S_e_e _A_l_s_o
+ mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-nocomponent' if only one component is specified
+ `-component' if more than one component is specified
+ `components' defaults to none
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -74-
MHPATH(1)
+
+
+ _N_A_M_E
+ mhpath - print full pathnames of MH messages and folders
+
+ _S_Y_N_O_P_S_I_S
+ mhpath [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_p_a_t_h expands and sorts the message list `msgs'
and writes the
+ full pathnames of the messages to the standard output
separated by
+ newlines. If no `msgs' are specified, _m_h_p_a_t_h
outputs the folder
+ pathname instead. If the only argument is `+', your MH
_P_a_t_h is
+ output; this can be useful is shell scripts.
+
+ Contrasted with other MH commands, a message argument to
_m_h_p_a_t_h may
+ often be intended for _w_r_i_t_i_n_g. Because of this:
+
+ 1) the name "new" has been added to _m_h_p_a_t_h's list
of reserved mes-
+ sage names (the others are "first", "last", "prev", "next",
"cur",
+ and "all"). The new message is equivalent to the message
after the
+ last message in a folder (and equivalent to 1 in a folder
without
+ messages). The "new" message may not be used as part of a
message
+ range.
+
+ 2) Within a message list, the following designations may
refer to
+ messages that do not exist: a single numeric message name,
the sin-
+ gle message name "cur", and (obviously) the single message
name
+ "new". All other message designations must refer to at
least one
+ existing message.
+
+ 3) An empty folder is not in itself an error.
+
+ Message numbers greater than the highest existing message
in a
+ folder as part of a range designation are replaced with
the next
+ free message number.
+
+ Examples: The current folder foo contains messages 3 5 6.
Cur is
+ 4.
+
+ % mhpath
+ /r/phyl/Mail/foo
+
+ % mhpath all
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath 2001
+ /r/phyl/Mail/foo/7
+
+ % mhpath 1-2001
+ /r/phyl/Mail/foo/3
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -75-
MHPATH(1)
+
+
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath new
+ /r/phyl/Mail/foo/7
+
+ % mhpath last new
+ /r/phyl/Mail/foo/6
+ /r/phyl/Mail/foo/7
+
+ % mhpath last-new
+ bad message list "last-new".
+
+ % mhpath cur
+ /r/phyl/Mail/foo/4
+
+ % mhpath 1-2
+ no messages in range "1-2".
+
+ % mhpath first:2
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+
+ % mhpath 1 2
+ /r/phyl/Mail/foo/1
+ /r/phyl/Mail/foo/2
+
+ _M_H_p_a_t_h is also useful in back-quoted operations:
+
+ % cd `mhpath +inbox`
+
+ % echo `mhpath +`
+ /r/phyl/Mail
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to none
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -76-
MHPATH(1)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Like all MH commands, _m_h_p_a_t_h expands and sorts
[msgs]. So don't
+ expect
+
+ mv `mhpath 501 500`
+
+ to move 501 to 500. Quite the reverse. But
+
+ mv `mhpath 501` `mhpath 500`
+
+ will do the trick.
+
+ Out of range message 0 is treated far more severely than
large out
+ of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -77-
MSGCHK(1)
+
+
+ _N_A_M_E
+ msgchk - check for messages
+
+ _S_Y_N_O_P_S_I_S
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [-host host] [-user user]
[-apop]
+ [-noapop] [-rpop] [-norpop] [users ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_s_g_c_h_k program checks all known mail drops
for mail waiting for
+ you. For those drops which have mail for you,
_m_s_g_c_h_k will indicate
+ if it believes that you have seen the mail in question before.
+
+ The `-notify type' switch indicates under what circumstances
_m_s_g_c_h_k
+ should produce a message. The default is `-notify all'
which says
+ that _m_s_g_c_h_k should always report the status of
the users maildrop.
+ Other values for `type' include `mail' which says that
_m_s_g_c_h_k
+ should report the status of waiting mail; and, `nomail' which
says
+ that _m_s_g_c_h_k should report the status of
empty maildrops. The
+ `-nonotify type' switch has the inverted sense, so
`-nonotify all'
+ directs _m_s_g_c_h_k to never report the status of
maildrops. This is
+ useful if the user wishes to check _m_s_g_c_h_k's
exit status. A
+ non-zero exit status indicates that mail was not waiting
for at
+ least one of the indicated users.
+
+ If _m_s_g_c_h_k produces output, then the `-date'
switch directs _m_s_g_c_h_k
+ to print out the last date mail was read, if this can be
deter-
+ mined.
+
+ If the local host is configured as a POP client, or
if the
+ `-host host' switch is given, _m_s_g_c_h_k will
query the POP service
+ host as to the status of mail waiting. If the `-user user'
switch
+ is not given, then the current username is used. Normally,
_m_s_g_c_h_k
+ will prompt for a password to use. However, if the `-apop'
switch
+ is given, _m_s_g_c_h_k will generate authentication
credentials to pro-
+ vide for origin authentication and replay protection, but
which do
+ not involve sending a password in the clear over the network.
Oth-
+ erwise, if the `-rpop' switch is given, then
_m_s_g_c_h_k will try to use
+ a "trusted" connection (ala the BSD r-commands).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -78-
MSGCHK(1)
+
+
+ _S_e_e _A_l_s_o
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l -
_v_e_r_s_i_o_n _3 (aka RFC-1081),
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `user' defaults to the current user
+ `-date'
+ `-notify all'
+ `-rpop'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -79-
MSH(1)
+
+
+ _N_A_M_E
+ msh - MH shell (and BBoard reader)
+
+ _S_Y_N_O_P_S_I_S
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur]
[file]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _m_s_h is an interactive program that implements a subset
of the nor-
+ mal _M_H commands operating on a single file in
_p_a_c_k_f'd format. That
+ is, _m_s_h is used to read a file that contains a number
of messages,
+ as opposed to the standard _M_H style of reading a number
of files,
+ each file being a separate message in a folder. _m_s_h's
chief advan-
+ tage is that the normal _M_H style does not allow a file to
have more
+ than one message in it. Hence, _m_s_h is ideal for
reading _B_B_o_a_r_d_s,
+ as these files are delivered by the transport system in
this for-
+ mat. In addition, _m_s_h can be used on other files, such
as message
+ archives which have been _p_a_c_ked (see
_p_a_c_k_f (1)). Finally, _m_s_h is
+ an excellent _M_H tutor. As the only commands available to
the user
+ are _M_H commands, this allows _M_H beginners to
concentrate on how
+ commands to _M_H are formed and (more or less) what they
mean.
+
+ When invoked, _m_s_h reads the named file, and enters a
command loop.
+ The user may type most of the normal _M_H commands. The
syntax and
+ semantics of these commands typed to _m_s_h are identical
to their _M_H
+ counterparts. In cases where the nature of _m_s_h
would be incon-
+ sistent (e.g., specifying a `+folder' with some commands),
_m_s_h will
+ duly inform the user. The commands that _m_s_h currently
supports (in
+ some slightly modified or restricted forms) are:
+
+ ali
+ burst
+ comp
+ dist
+ folder
+ forw
+ inc
+ mark
+ mhmail
+ mhn
+ msgchk
+ next
+ packf
+ pick
+ prev
+ refile
+ repl
+ rmm
+ scan
+ send
+ show
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -80-
MSH(1)
+
+
+ sortm
+ whatnow
+ whom
+
+ In addition, _m_s_h has a "help" command which gives a
brief overview.
+ To terminate _m_s_h, type CTRL-D, or use the "quit"
command. If _m_s_h
+ is being invoked from _b_b_c, then typing CTRL-D will also
tell _b_b_c to
+ exit as well, while using the "quit" command will return
control to
+ _b_b_c, and _b_b_c will continue examining the list of
BBoards that it is
+ scanning.
+
+ If the file is writable and has been modified, then using
"quit"
+ will query the user if the file should be updated.
+
+ The `-prompt string' switch sets the prompting string for
_m_s_h.
+
+ You may wish to use an alternate _M_H profile for the
commands that
+ _m_s_h executes; see _m_h-_p_r_o_f_i_l_e (5) for
details about the $MH envari-
+ able.
+
+ When invoked from _b_b_c, two special features are
enabled: First, the
+ `-scan' switch directs _m_s_h to do a `scan unseen' on
start-up if new
+ items are present in the BBoard. This feature is best used
from
+ _b_b_c, which correctly sets the stage. Second, the
_m_a_r_k command in
+ _m_s_h acts specially when you are reading a BBoard,
since _m_s_h will
+ consult the sequence "unseen" in determining what messages
you have
+ actually read. When _m_s_h exits, it reports this
information to _b_b_c.
+ In addition, if you give the _m_a_r_k command with no
arguments, _m_s_h
+ will interpret it as `mark -sequence unseen -delete
-nozero all'
+ Hence, to discard all of the messages in the current BBoard
you're
+ reading, just use the _m_a_r_k command with no arguments.
+
+ Normally, the "exit" command is identical to the "quit"
command in
+ _m_s_h. When run under _b_b_c however, "exit"
directs _m_s_h to mark all
+ messages as seen and then "quit". For speedy type-in, this
command
+ is often abbreviated as just "e".
+
+ When invoked from _v_m_h, another special feature is
enabled: The
+ `topcur' switch directs _m_s_h to have the current message
"track" the
+ top line of the _v_m_h scan window. Normally, _m_s_h
has the current
+ message "track" the center of the window (under `-notopcur',
which
+ is the default).
+
+ _m_s_h supports an output redirection facility. Commands
may be fol-
+ lowed by one of
+
+ > _f_i_l_e write output to _f_i_l_e
+ >> _f_i_l_e append output to _f_i_l_e
+ | _c_o_m_m_a_n_d pipe output to UNIX
_c_o_m_m_a_n_d
+
+ If _f_i_l_e starts with a `~' (tilde), then a
_c_s_h-like expansion takes
+ place. Note that _c_o_m_m_a_n_d is interpreted by
_s_h (1). Also note that
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -81-
MSH(1)
+
+
+ _m_s_h does NOT support history substitutions, variable
substitutions,
+ or alias substitutions.
+
+ When parsing commands to the left of any redirection
symbol, _m_s_h
+ will honor `\' (back-slash) as the quote next-character
symbol, and
+ `"' (double-quote) as quote-word delimiters. All other
input
+ tokens are separated by whitespace (spaces and tabs).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Msg-Protect: To set mode when creating a new `file'
+ fileproc: Program to file messages
+ showproc: Program to show messages
+
+
+ _S_e_e _A_l_s_o
+ bbc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to "./msgbox"
+ `-prompt (msh) '
+ `-noscan'
+ `-notopcur'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -82-
MSH(1)
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _m_s_h. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+ There is a strict limit of messages per file in
_p_a_c_k_f'd format
+ which _m_s_h can handle. Usually, this limit is 1000
messages.
+
+ Please remember that _m_s_h is not the _C_S_h_e_l_l,
and that a lot of the
+ nice facilities provided by the latter are not present in the
form-
+ er.
+
+ In particular, _m_s_h does not understand back-quoting,
so the only
+ effective way to use _p_i_c_k inside _m_s_h is
to always use the
+ `-seq select' switch. Clever users of _M_H will put the
line
+
+ pick: -seq select -list
+
+ in their .mh_profile file so that _p_i_c_k works equally
well from both
+ the shell and _m_s_h.
+
+ _s_o_r_t_m always uses "-noverbose" and if "-textfield
field" is used,
+ "-limit 0".
+
+ The _m_s_h program inherits most (if not all) of the bugs
from the _M_H
+ commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ NEXT(1) -83-
NEXT(1)
+
+
+ _N_A_M_E
+ next - show the next message
+
+ _S_Y_N_O_P_S_I_S
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _N_e_x_t performs a _s_h_o_w on the next message
in the specified (or
+ current) folder. Like _s_h_o_w, it passes any switches
on to the pro-
+ gram _s_h_o_w_p_r_o_c, which is called to list the
message. This command
+ is almost exactly equivalent to "show next". Consult the
manual
+ entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), prev(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder.
The
+ message that is shown (i.e., the next message in sequence)
will be-
+ come the current message.
+
+
+ _B_u_g_s
+ _n_e_x_t is really a link to the _s_h_o_w program.
As a result, if you
+ make a link to _n_e_x_t and that link is not called
_n_e_x_t, your link
+ will act like _s_h_o_w instead. To circumvent
this, add a
+ profile-entry for the link to your _M_H profile and add
the argument
+ _n_e_x_t to the entry.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PACKF(1) -84-
PACKF(1)
+
+
+ _N_A_M_E
+ packf - compress an MH folder into a single file
+
+ _S_Y_N_O_P_S_I_S
+ packf [+folder] [msgs] [-file name] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_a_c_k_f takes messages from a folder and copies
them to a single
+ file. Each message in the file is separated by four CTRL-A's
and a
+ newline (identical to the way messages are stored in your
receiving
+ mail drop). Messages packed can be unpacked using _i_n_c.
+
+ If the _n_a_m_e given to the `-file name' switch exists,
then the mes-
+ sages specified will be appended to the end of the file,
otherwise
+ the file will be created and the messages appended.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ .msgbox.map A binary index of the
file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new `file'
+
+
+ _S_e_e _A_l_s_o
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-file ./msgbox'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message packed will become the current message.
+
+
+ _B_u_g_s
+ _P_a_c_k_f doesn't handle the old UUCP-style "mbox"
format (used by
+ _S_e_n_d_M_a_i_l). To pack messages into this
format, use the script
+
/_u_s_r/_b_s/_m_h-_6._8/_l_i_b/_p_a_c_k_m_b_o_x. Note that
_p_a_c_k_m_b_o_x does not take the
+ `-file' option of _p_a_c_k_f, and instead writes its
output on _s_t_d_o_u_t.
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -85-
PICK(1)
+
+
+ _N_A_M_E
+ pick - select messages by content
+
+ _S_Y_N_O_P_S_I_S
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-cc pattern]
+ [-date pattern] [-from pattern] [-search pattern]
+ [-subject pattern] [-to pattern] [-after date] [-before
date]
+ [-datefield field] [-sequence name ...] [-public]
[-nopublic]
+ [-zero] [-nozero] [-list] [-nolist] [-help]
+
+ typically:
+ scan `pick -from jones`
+ pick -to holloway -sequence select
+ show `pick -before friday`
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_i_c_k searches messages within a folder for the
specified contents,
+ and then identifies those messages. Two types of search
primitives
+ are available: pattern matching and date constraint
operations.
+
+ A modified _g_r_e_p(1) is used to perform the matching,
so the full
+ regular expression (see _e_d(1)) facility is available
within `pat-
+ tern'. With `-search', `pattern' is used directly, and
with the
+ others, the grep pattern constructed is:
+
+ "component[ \t]*:.*pattern"
+
+ This means that the pattern specified for a `-search' will be
found
+ everywhere in the message, including the header and the body,
while
+ the other pattern matching requests are limited to the
single
+ specified component. The expression
+
+ `--component pattern'
+
+ is a shorthand for specifying
+
+ `-search "component[ \t]*:.*pattern" '
+
+ It is used to pick a component which is not one of "To:",
"cc:",
+ "Date:", "From:", or "Subject:". An example
is
+ `pick --reply-to pooh'.
+
+ Pattern matching is performed on a per-line basis.
Within the
+ header of the message, each component is treated as one long
line,
+ but in the body, each line is separate. Lower-case letters
in the
+ search pattern will match either lower or upper case in
the mes-
+ sage, while upper case will match only upper case.
+
+ Note that since the `-date' switch is a pattern matching
operation
+ (as described above), to find messages sent on a certain
date the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -86-
PICK(1)
+
+
+ pattern string must match the text of the "Date:" field of
the mes-
+ sage.
+
+ Independent of any pattern matching operations
requested, the
+ switches `-after date' or `-before date' may also be used to
intro-
+ duce date/time contraints on all of the messages. By
default, the
+ "Date:" field is consulted, but if another date yielding
field
+ (such as "BB-Posted:" or "Delivery-Date:") should be
used, the
+ `-datefield field' switch may be used.
+
+ With `-before' and `-after', _p_i_c_k will actually
parse the date
+ fields in each of the messages specified in `msgs' and
compare them
+ to the date/time specified. If `-after' is given, then only
those
+ messages whose "Date:" field value is chronologically
after the
+ date specified will be considered. The `-before' switch
specifies
+ the complimentary action.
+
+ Both the `-after' and `-before' switches take legal 822-style
date
+ specifications as arguments. _P_i_c_k will default
certain missing
+ fields so that the entire date need not be specified. These
fields
+ are (in order of defaulting): timezone, time and timezone,
date,
+ date and timezone. All defaults are taken from the current
date,
+ time, and timezone.
+
+ In addition to 822-style dates, _p_i_c_k will also
recognize any of the
+ days of the week ("sunday", "monday", and so on), and the
special
+ dates "today", "yesterday" (24 hours ago), and "tomorrow" (24
hours
+ from now). All days of the week are judged to refer to a
day in
+ the past (e.g., telling _p_i_c_k "saturday" on a
"tuesday" means
+ "last saturday" not "this saturday").
+
+ Finally, in addition to these special specifications,
_p_i_c_k will
+ also honor a specification of the form "-dd", which means
"dd days
+ ago".
+
+ _P_i_c_k supports complex boolean operations on the
searching primi-
+ tives with the `-and', `-or', `-not', and `-lbrace ...
-rbrace'
+ switches. For example,
+
+ pick -after yesterday -and
+ -lbrace -from freida -or -from fear -rbrace
+
+ identifies messages recently sent by "frieda" or "fear".
+
+ The matching primitives take precedence over the `-not'
switch,
+ which in turn takes precedence over `-and' which in turn
takes pre-
+ cedence over `-or'. To override the default
precedence, the
+ `-lbrace' and `-rbrace' switches are provided, which act
just like
+ opening and closing parentheses in logical expressions.
+
+ If no search criteria are given, all the messages specified
on the
+ command line are selected (this defaults to "all").
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -87-
PICK(1)
+
+
+ Once the search has been performed, if the `-list' switch is
given,
+ the message numbers of the selected messages are written
to the
+ standard output separated by newlines. This is
_e_x_t_r_e_m_e_l_y useful
+ for quickly generating arguments for other _M_H programs by
using the
+ "backquoting" syntax of the shell. For example, the command
+
+ scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+ says to _s_c_a_n those messages in the indicated folder
which meet the
+ appropriate criterion. Note that since _p_i_c_k 's
context changes are
+ written out prior to _s_c_a_n 's invocation, you need
not give the
+ folder argument to _s_c_a_n as well.
+
+ Regardless of the operation of the `-list' switch, the
`-sequence
+ name' switch may be given once for each sequence the user
wishes to
+ define. For each sequence named, that sequence will be
defined to
+ mean exactly those messages selected by _p_i_c_k. For
example,
+
+ pick -from frated -seq fred
+
+ defines a new message sequence for the current folder called
"fred"
+ which contains exactly those messages that were selected.
+
+ Note that whenever _p_i_c_k processes a `-sequence
name' switch, it
+ sets `-nolist'.
+
+ By default, _p_i_c_k will zero the sequence before
adding it. This
+ action can be disabled with the `-nozero' switch, which
means that
+ the messages selected by _p_i_c_k will be added to the
sequence, if it
+ already exists, and any messages already a part of that
sequence
+ will remain so.
+
+ The `-public' and `-nopublic' switches are used by
_p_i_c_k in the same
+ way _m_a_r_k uses them.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ mark(1)
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -88-
PICK(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-zero'
+ `-list' is the default if no `-sequence', `-nolist' otherwise
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the _p_i_c_k command
would _s_h_o_w, _s_c_a_n, or
+ _r_e_f_i_l_e the selected messages. This was
rather "inverted logic"
+ from the UNIX point of view, so _p_i_c_k was changed
to define se-
+ quences and output those sequences. Hence, _p_i_c_k
can be used to
+ generate the arguments for all other _M_H commands, instead
of giving
+ _p_i_c_k endless switches for invoking those commands
itself.
+
+ Also, previous versions of _p_i_c_k balked if you
didn't specify a
+ search string or a date/time constraint. The current
version does
+ not, and merely matches the messages you specify. This
lets you
+ type something like:
+
+ show `pick last:20 -seq fear`
+
+ instead of typing
+
+ mark -add -nozero -seq fear last:20
+ show fear
+
+ Finally, timezones used to be ignored when comparing dates:
they
+ aren't any more.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ Use "pick sequence -list" to enumerate the messages in a
sequence
+ (such as for use by a shell script).
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -89-
PICK(1)
+
+
+ _B_u_g_s
+ The argument to the `-after' and `-before' switches must be
inter-
+ preted as a single token by the shell that invokes
_p_i_c_k. There-
+ fore, one must usually place the argument to this switch
inside
+ double-quotes. Furthermore, any occurance of `-datefield'
must oc-
+ cur prior to the `-after' or `-before' switch it applies to.
+
+ If _p_i_c_k is used in a back-quoted operation, such as
+
+ scan `pick -from jones`
+
+ and _p_i_c_k selects no messages (e.g., no messages are
from "jones"),
+ then the shell will still run the outer command (e.g.,
"scan").
+ Since no messages were matched, _p_i_c_k produced no
output, and the
+ argument given to the outer command as a result of
backquoting _p_i_c_k
+ is empty. In the case of _M_H programs, the outer command
now acts
+ as if the default `msg' or `msgs' should be used (e.g.,
"all" in
+ the case of _s_c_a_n ). To prevent this unexpected
behavior, if
+ `-list' was given, and if its standard output is not a
tty, then
+ _p_i_c_k outputs the illegal message number "0" when it
fails. This
+ lets the outer command fail gracefully as well.
+
+ The pattern syntax "[l-r]" is not supported; each letter
to be
+ matched must be included within the square brackets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PREV(1) -90-
PREV(1)
+
+
+ _N_A_M_E
+ prev - show the previous message
+
+ _S_Y_N_O_P_S_I_S
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [-switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_r_e_v performs a _s_h_o_w on the previous message
in the specified (or
+ current) folder. Like _s_h_o_w, it passes any switches
on to the pro-
+ gram named by _s_h_o_w_p_r_o_c, which is called to
list the message. This
+ command is almost exactly equivalent to "show prev".
Consult the
+ manual entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), next(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder.
The
+ message that is shown (i.e., the previous message in
sequence) will
+ become the current message.
+
+
+ _B_u_g_s
+ _p_r_e_v is really a link to the _s_h_o_w program.
As a result, if you
+ make a link to _p_r_e_v and that link is not called
_p_r_e_v, your link
+ will act like _s_h_o_w instead. To circumvent
this, add a
+ profile-entry for the link to your _M_H profile and add
the argument
+ _p_r_e_v to the entry.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -91-
PROMPTER(1)
+
+
+ _N_A_M_E
+ prompter - prompting editor front-end for MH
+
+ _S_Y_N_O_P_S_I_S
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend]
[-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This program is normally not invoked directly by users but
takes
+ the place of an editor and acts as an editor
front-end. It
+ operates on an 822-style message draft skeleton specified by
file,
+ normally provided by _c_o_m_p, _d_i_s_t,
_f_o_r_w, or _r_e_p_l.
+
+ _P_r_o_m_p_t_e_r is an editor which allows rapid
composition of messages.
+ It is particularly useful to network and low-speed (less
than 2400
+ baud) users of _M_H. It is an _M_H program in that it
can have its own
+ profile entry with switches, but it is not invoked directly
by the
+ user. The commands _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l invoke _p_r_o_m_p_t_e_r as
+ an editor, either when invoked with `-editor prompter', or
by the
+ profile entry "Editor: prompter", or when given the
command
+ `edit prompter' at "What now?" level.
+
+ For each empty component _p_r_o_m_p_t_e_r finds in
the draft, the user is
+ prompted for a response; A <RETURN> will cause the whole
component
+ to be left out. Otherwise, a `\' preceding a <RETURN> will
con-
+ tinue the response on the next line, allowing for
multiline com-
+ ponents. Continuation lines must begin with a space or tab.
+
+ Each non-empty component is copied to the draft and
displayed on
+ the terminal.
+
+ The start of the message body is denoted by a blank line or a
line
+ of dashes. If the body is non-empty, the prompt, which isn't
writ-
+ ten to the file, is
+
+ "--------Enter additional text",
+
+ or (if `-prepend' was given)
+
+ "--------Enter initial text".
+
+ Message-body typing is terminated with an end-of-file
(usually
+ CTRL-D). With the `-doteof' switch, a period on a line
all by
+ itself also signifies end-of-file. At this point
control is
+ returned to the calling program, where the user is asked
"What
+ now?". See _w_h_a_t_n_o_w for the valid options to
this query.
+
+ By using the `-prepend' switch, the user can add type-in
to the
+ beginning of the message body and have the rest of the body
follow.
+ This is useful for the _f_o_r_w command.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -92-
PROMPTER(1)
+
+
+ By using the `-rapid' switch, if the draft already contains
text in
+ the message-body, it is not displayed on the user's terminal.
This
+ is useful for low-speed terminals.
+
+ The line editing characters for kill and erase may be
specified by
+ the user via the arguments `-kill chr' and `-erase chr',
where chr
+ may be a character; or `\nnn', where "nnn" is the octal
value for
+ the character.
+
+ An interrupt (usually CTRL-C) during component typing will
abort
+ _p_r_o_m_p_t_e_r and the _M_H command that
invoked it. An interrupt during
+ message-body typing is equivalent to CTRL-D, for historical
rea-
+ sons. This means that _p_r_o_m_p_t_e_r should finish
up and exit.
+
+ The first non-flag argument to _p_r_o_m_p_t_e_r is
taken as the name of the
+ draft file, and subsequent non-flag arguments are ignored.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /tmp/prompter* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ prompter-next: To name the editor to be used on exit
from
+ _p_r_o_m_p_t_e_r
+ Msg-Protect: To set mode when creating a new draft
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prepend'
+ `-norapid'
+ `-nodoteof'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ The `-rapid' option is particularly useful with
_f_o_r_w, and
+ `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+ The user may wish to link _p_r_o_m_p_t_e_r under
several names (e.g., "ra-
+ pid") and give appropriate switches in the profile entries
under
+ these names (e.g., "rapid: -rapid"). This facilitates
invoking
+ prompter differently for different _M_H commands (e.g.,
"forw: -edi-
+ tor rapid").
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -93-
PROMPTER(1)
+
+
+ _B_u_g_s
+ _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will
lose if you edit files with
+ nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -94-
RCVSTORE(1)
+
+
+ _N_A_M_E
+ rcvstore - incorporate new mail asynchronously
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero]
[-nozero]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_c_v_s_t_o_r_e incorporates a message from the
standard input into an _M_H
+ folder. If `+folder' isn't specified, a folder in the
user's _M_H
+ directory will be used, either that specified by the "Inbox:"
entry
+ in the user's profile, or the folder named "inbox". The
new mes-
+ sage being incorporated is assigned the next highest number
in the
+ folder. If the specified (or default) folder doesn't
exist, then
+ it will be created if the `-create' option is specified,
otherwise
+ _r_c_v_s_t_o_r_e will exit.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it
will
+ be used as the protection on the newly created messages,
otherwise
+ the _M_H default of 0644 will be used. During all
operations on mes-
+ sages, this initially assigned protection will be
preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a
protection on an
+ individual message, and its protection will be
preserved
+ thereafter.
+
+ _R_c_v_s_t_o_r_e will incorporate anything except
zero length messages into
+ the user's MH folder.
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+ then _r_c_v_s_t_o_r_e will add the newly
incorporated message to each
+ sequence named by the profile entry. This is similar
to the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments. Note that
_r_c_v_s_t_o_r_e will not
+ zero each sequence prior to adding messages.
+
+ Furthermore, the incoming messages may be added to
user-defined
+ sequences as they arrive by appropriate use of the
`-sequence'
+ option. As with _p_i_c_k, use of the `-zero' and
`-nozero' switches
+ can also be used to zero old sequences or not. Similarly,
use of
+ the `-public' and `-nopublic switches may be used to force
addi-
+ tions to public and private sequences.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -95-
RCVSTORE(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Folder-Protect: To set mode when creating a new folder
+ Inbox: To find the default inbox
+ Msg-Protect: To set mode when creating a new message
+ Unseen-Sequence: To name sequences denoting unseen
messages
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), mh-mail(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to "inbox"
+ `-create'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ No context changes will be attempted, with the exception
of se-
+ quence manipulation.
+
+
+ _B_u_g_s
+ If you use the "Unseen-Sequence" profile entry,
_r_c_v_s_t_o_r_e could try
+ to update the context while another _M_H process is also
trying to do
+ so. This can cause the context to become corrupted. To
avoid
+ this, do not use _r_c_v_s_t_o_r_e if you use the
"Unseen-Sequence" profile
+ entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -96-
REFILE(1)
+
+
+ _N_A_M_E
+ refile - file message in other folders
+
+ _S_Y_N_O_P_S_I_S
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve]
[-nopreserve]
+ [-src +folder] [-file file] [-rmmproc program]
[-normmproc]
+ +folder ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_f_i_l_e moves (_m_v (1)) or links (_l_n (1))
messages from a source
+ folder into one or more destination folders. If you
think of a
+ message as a sheet of paper, this operation is not unlike
filing
+ the sheet of paper (or copies) in file cabinet folders.
When a
+ message is filed, it is linked into the destination
folder(s) if
+ possible, and is copied otherwise. As long as the
destination
+ folders are all on the same file system, multiple filing
causes
+ little storage overhead. This facility provides a good
way to
+ cross-file or multiply-index messages. For example, if a
message
+ is received from Jones about the ARPA Map Project, the command
+
+ refile cur +jones +Map
+
+ would allow the message to be found in either of the two
folders
+ `jones' or `Map'.
+
+ The option `-file file' directs _r_e_f_i_l_e to use the
specified file as
+ the source message to be filed, rather than a message
from a
+ folder. Note that the file should be a validly formatted
message,
+ just like any other _M_H message. It should NOT be in mail
drop for-
+ mat (to convert a file in mail drop format to a folder of
_M_H mes-
+ sages, see _i_n_c (1)).
+
+ If a destination folder doesn't exist, _r_e_f_i_l_e
will ask if you want
+ to create it. A negative response will abort the file
operation.
+ If the standard input for _r_e_f_i_l_e is _n_o_t a
tty, then _r_e_f_i_l_e will not
+ ask any questions and will proceed as if the user's
answer was
+ "yes" for all questions.
+
+ The option `-link' preserves the source folder copy of the
message
+ (i.e., it does a _l_n(1) rather than a _m_v(1)),
whereas, `-nolink'
+ deletes the filed messages from the source folder. Normally,
when
+ a message is filed, it is assigned the next highest number
avail-
+ able in each of the destination folders. Use of the
`-preserve'
+ switch will override this message renaming, but name
conflicts may
+ occur, so use this switch cautiously.
+
+ If `-link' is not specified (or `-nolink' is specified), the
filed
+ messages will be removed from the source folder, by
renaming them
+ with a site-dependent prefix (usually a comma).
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -97-
REFILE(1)
+
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then _r_e_f_i_l_e will instead call the named program
to delete the mes-
+ sage files. The user may specify `-rmmproc program' on the
command
+ line to override this profile specification. The
`-normmproc'
+ option forces the message files to be deleted by renaming
them as
+ described above.
+
+ The `-draft' switch tells _r_e_f_i_l_e to file the
<mh-dir>/draft.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-src +folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-nolink'
+ `-nopreserve'
+
+
+ _C_o_n_t_e_x_t
+ If `-src +folder' is given, it will become the current
folder. If
+ neither `-link' nor `all' is specified, the current message
in the
+ source folder will be set to the last message specified;
otherwise,
+ the current message won't be changed.
+
+ If the Previous-Sequence profile entry is set, in addition
to de-
+ fining the named sequences from the source folder,
_r_e_f_i_l_e will also
+ define those sequences for the destination folders.
See
+ _m_h-_s_e_q_u_e_n_c_e (5) for information
concerning the previous sequence.
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to
delete the message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying
`-normmproc', or you will
+ create an infinte loop.
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -98-
REPL(1)
+
+
+ _N_A_M_E
+ repl - reply to a message
+
+ _S_Y_N_O_P_S_I_S
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc
all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form
formfile]
+ [-inplace] [-noinplace] [-query] [-noquery] [-width
columns]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_p_l aids a user in producing a reply to an existing
message. _R_e_p_l
+ uses a reply template to guide its actions when
constructing the
+ message draft of the reply. In its simplest form (with no
argu-
+ ments), it will set up a message-form skeleton in reply
to the
+ current message in the current folder, and invoke the
whatnow
+ shell. The default reply template will direct
_r_e_p_l to construct
+ the composed message as follows:
+
+ To: <Reply-To> or <From>
+ cc: <cc>, <To>, and yourself
+ Subject: Re: <Subject>
+ In-reply-to: Your message of <Date>.
+ <Message-Id>
+
+ where field names enclosed in angle brackets (< >)
indicate the
+ contents of the named field from the message to which the
reply is
+ being made. A reply template is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ The `-cc type' switch takes an argument which specifies who
gets
+ placed on the "cc:" list of the reply. The `-query' switch
modi-
+ fies the action of `-cc type' switch by interactively asking
you if
+ each address that normally would be placed in the "To:" and
"cc:"
+ list should actually be sent a copy. (This is
useful for
+ special-purpose replies.) Note that the position of the
`-cc' and
+ `-nocc' switches, like all other switches which take a
positive and
+ negative form, is important.
+
+ Lines beginning with the fields "To:", "cc:", and "Bcc:"
will be
+ standardized and have duplicate addresses removed. In
addition,
+ the `-width columns' switch will guide _r_e_p_l's
formatting of these
+ fields.
+
+ If the file named "replcomps" exists in the user's MH
directory, it
+ will be used instead of the default form. In either case,
the file
+ specified by `-form formfile' will be used if given.
+
+ If the draft already exists, _r_e_p_l will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_r_e_p_l, leaving the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -99-
REPL(1)
+
+
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches. Note that while in the editor, the message being
replied
+ to is available through a link named "@" (assuming the
default
+ _w_h_a_t_n_o_w_p_r_o_c ). In addition, the
actual pathname of the message is
+ stored in the envariable $editalt, and the pathname of the
folder
+ containing the message is stored in the envariable $mhfolder.
+
+ Although _r_e_p_l uses the `-form formfile' switch to
direct it how to
+ construct the beginning of the draft, the `-filter
filterfile'
+ switch directs _r_e_p_l as to how the message being
replied-to should
+ be formatted in the body of the draft. If `-filter' is not
speci-
+ fied, then the message being replied-to is not included in
the body
+ of the draft. If `-filter filterfile' is specified, then
the mes-
+ sage being replied-to is filtered (re-formatted) prior to
being
+ output to the body of the draft. The filter file for
_r_e_p_l should
+ be a standard form file for _m_h_l, as _r_e_p_l will
invoke _m_h_l to format
+ the message being replied-to. There is no default message
filter
+ (`-filter' must be followed by a file name). A filter file
that is
+ commonly used is:
+
+ :
+ body:nocomponent,compwidth=9,offset=9
+
+ which says to output a blank line and then the body of the
message
+ being replied-to, indented by one tab-stop. Another format
popular
+ on USENET is:
+
+
+ message-id:nocomponent,nonewline,\
+ formatfield="In message %{text}, "
+ from:nocomponent,formatfield="%(friendly{text}) writes:"
+ body:component=">",overflowtext=">",overflowoffset=0
+
+ Which cites the Message-ID and author of the message
being
+ replied-to, and then outputs each line of the body
prefaced with
+ the ">" character.
+
+ If the `-annotate' switch is given, the message being
replied-to
+ will be annotated with the lines
+
+ Replied: date
+ Replied: addrs
+
+ where the address list contains one line for each addressee.
The
+ annotation will be done only if the message is sent
directly from
+ _r_e_p_l. If the message is not sent immediately
from _r_e_p_l,
+ "comp -use" may be used to re-edit and send the
constructed mes-
+ sage, but the annotations won't take place. The `-inplace'
switch
+ causes annotation to be done in place in order to preserve
links to
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -100-
REPL(1)
+
+
+ the annotated message.
+
+ The `-fcc +folder' switch can be used to automatically
specify a
+ folder to receive Fcc:s. More than one folder, each
preceeded by
+ `-fcc' can be named.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _r_e_p_l also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t
escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _f_c_c string Any folders specified with `-fcc
folder'
+
+ To avoid reiteration, _r_e_p_l strips any leading `Re: '
strings from
+ the _s_u_b_j_e_c_t component.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _r_e_p_l will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/replcomps The reply template
+ or <mh-dir>/replcomps Rather than the standard
template
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter message being
replied-to
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -101-
REPL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-nocc all' at ATHENA sites, `-cc all' otherwise
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+ `-noquery'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
mes-
+ sage replied-to will become the current message.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-noformat'
used to
+ cause address headers to be output as-is. Now all address
fields
+ are formatted using Internet standard guidelines.
+
+
+ _B_u_g_s
+ If any addresses occur in the reply template, addresses in
the tem-
+ plate that do not contain hosts are defaulted incorrectly.
Instead
+ of using the localhost for the default, _r_e_p_l uses
the sender's
+ host. Moral of the story: if you're going to include
addresses in
+ a reply template, include the host portion of the address.
+
+ The `-width columns' switch is only used to do
address-folding;
+ other headers are not line-wrapped.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _r_e_p_l uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _r_e_p_l won't run
+ it.
+
+ If your current working directory is not writable, the link
named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMF(1) -102-
RMF(1)
+
+
+ _N_A_M_E
+ rmf - remove an MH folder
+
+ _S_Y_N_O_P_S_I_S
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_f removes all of the messages (files) within the
specified (or
+ default) folder, and then removes the folder (directory)
itself.
+ If there are any files within the folder which are not a
part of
+ _M_H, they will _n_o_t be removed, and an error will
be produced. If
+ the folder is given explicitly or the `-nointeractive'
option is
+ given, then the folder will be removed without confirmation.
Oth-
+ erwise, the user will be asked for confirmation. If
_r_m_f can't find
+ the current folder, for some reason, the folder to be
removed
+ defaults to `+inbox' (unless overridden by user's profile
entry
+ "Inbox") with confirmation.
+
+ _R_m_f irreversibly deletes messages that don't have other
links, so
+ use it with caution.
+
+ If the folder being removed is a subfolder, the parent folder
will
+ become the new current folder, and _r_m_f will produce a
message tel-
+ ling the user this has happened. This provides an easy
mechanism
+ for selecting a set of messages, operating on the list, then
remov-
+ ing the list and returning to the current folder from
which the
+ list was extracted.
+
+ _R_m_f of a read-only folder will delete the private
sequence and cur
+ information (i.e., "atr-_s_e_q-_f_o_l_d_e_r"
entries) from the profile
+ without affecting the folder itself.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Inbox: To find the default inbox
+
+
+ _S_e_e _A_l_s_o
+ rmm(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder, usually with
confirmation
+ `-interactive' if +folder' not given, `-nointeractive'
otherwise
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMF(1) -103-
RMF(1)
+
+
+ _C_o_n_t_e_x_t
+ _R_m_f will set the current folder to the parent folder if
a subfolder
+ is removed; or if the current folder is removed, it will
make "in-
+ box" current. Otherwise, it doesn't change the current
folder or
+ message.
+
+
+ _B_u_g_s
+ Although intuitively one would suspect that _r_m_f works
recursively,
+ it does not. Hence if you have a sub-folder within a
folder, in
+ order to _r_m_f the parent, you must first _r_m_f each
of the children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMM(1) -104-
RMM(1)
+
+
+ _N_A_M_E
+ rmm - remove messages
+
+ _S_Y_N_O_P_S_I_S
+ rmm [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_m removes the specified messages by renaming the
message files
+ with preceding commas. Many sites consider files that start
with a
+ comma to be a temporary backup, and arrange for _c_r_o_n
(8) to remove
+ such files once a day.
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then instead of simply renaming the message file, _r_m_m
will call the
+ named program to delete the file. Note that at most
installations,
+ _c_r_o_n (8) is told to remove files that begin with a
comma once a
+ night.
+
+ Some users of csh prefer the following:
+
+ alias rmm 'refile +d'
+
+ where folder +d is a folder for deleted messages, and
+
+ alias mexp 'rm `mhpath +d all`'
+
+ is used to "expunge" deleted messages.
+
+ The current message is not changed by _r_m_m, so a
_n_e_x_t will advance
+ to the next message in the folder as expected.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ rmf(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMM(1) -105-
RMM(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to
delete the message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying
`-normmproc', or you will
+ create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -106-
SCAN(1)
+
+
+ _N_A_M_E
+ scan - produce a one line per message scan listing
+
+ _S_Y_N_O_P_S_I_S
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_c_a_n produces a one-line-per-message listing of the
specified mes-
+ sages. Each _s_c_a_n line contains the message
number (name), the
+ date, the "From:" field, the "Subject" field, and, if room
allows,
+ some of the body of the message. For example:
+
+ 15+ 7/ 5 Dcrocker nned <<Last week I asked some of
+ 16 - 7/ 5 dcrocker message id format <<I recommend
+ 18 7/ 6 Obrien Re: Exit status from mkdir
+ 19 7/ 7 Obrien "scan" listing format in MH
+
+ The `+' on message 15 indicates that it is the current
message.
+ The `-' on message 16 indicates that it has been replied
to, as
+ indicated by a "Replied:" component produced by an
`-annotate'
+ switch to the _r_e_p_l command.
+
+ If there is sufficient room left on the _s_c_a_n line
after the sub-
+ ject, the line will be filled with text from the body,
preceded by
+ <<, and terminated by >> if the body is sufficiently short.
_S_c_a_n
+ actually reads each of the specified messages and parses
them to
+ extract the desired fields. During parsing, appropriate
error mes-
+ sages will be produced if there are format errors in any
of the
+ messages.
+
+ The `-header' switch produces a header line prior to the
_s_c_a_n list-
+ ing. Currently, the name of the folder and the current
date and
+ time are output (see the HISTORY section for more
information).
+
+ If the `-clear' switch is used and _s_c_a_n'_s output is
directed to a
+ terminal, then _s_c_a_n will consult the $TERM and
$TERMCAP envariables
+ to determine your terminal type in order to find out how to
clear
+ the screen prior to exiting. If the `-clear' switch is
used and
+ _s_c_a_n'_s output is not directed to a terminal (e.g.,
a pipe or a
+ file), then _s_c_a_n will send a formfeed prior to
exiting.
+
+ For example, the command:
+
+ (scan -clear -header; show all -show pr -f) | lpr
+
+ produces a scan listing of the current folder, followed
by a
+ formfeed, followed by a formatted listing of all messages
in the
+ folder, one per page. Omitting `-show pr -f' will cause the
mes-
+ sages to be concatenated, separated by a one-line header
and two
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -107-
SCAN(1)
+
+
+ blank lines.
+
+ If _s_c_a_n encounters a message without a "Date:" field,
rather than
+ leaving that portion of the scan listing blank, the
date is
+ filled-in with the last write date of the message, and
post-fixed
+ with a `*'. This is particularly handy for scanning a
_d_r_a_f_t
+ _f_o_l_d_e_r, as message drafts usually aren't allowed
to have dates in
+ them.
+
+ To override the output format used by _s_c_a_n, the
`-format string' or
+ `-format file' switches are used. This permits individual
fields
+ of the scan listing to be extracted with ease. The string is
sim-
+ ply a format string and the file is simply a format
file. See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _s_c_a_n also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t
escapes:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ body string the (compressed) first part of the body
+ dtimenow date the current date
+ folder string the name of the current folder
+
+ Also, if no date header was present in the message, the
_f_u_n_c_t_i_o_n
+ escapes which operate on {_d_a_t_e} will return values
for the date of
+ last modification of the message file itself.
+
+ _s_c_a_n will update the _M_H context prior to starting
the listing, so
+ interrupting a long _s_c_a_n listing preserves the
new context. _M_H
+ purists hate this idea.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), show(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the folder current
+ `msgs' defaults to all
+ `-format' defaulted as described above
+ `-noheader'
+ `-width' defaulted to the width of the terminal
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -108-
SCAN(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-header' used to
gen-
+ erate a heading saying what each column in the listing was.
Format
+ strings prevent this from happening.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _s_c_a_n. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+ The value of each _c_o_m_p_o_n_e_n_t escape is set
by _s_c_a_n to the contents
+ of the first message header _s_c_a_n encounters with the
corresponding
+ component name; any following headers with the same component
name
+ are ignored.
+
+ The switch `-reverse', makes _s_c_a_n list the messages
in reverse ord-
+ er; this should be considered a bug.
+
+ The `-file filename' switch allows the user to obtain a
_s_c_a_n list-
+ ing of a maildrop file as produced by _p_a_c_k_f. This
listing includes
+ every message in the file. The user should use _m_s_h for
more selec-
+ tive processing of the file. `-reverse' is ignored with
this op-
+ tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -109-
SEND(1)
+
+
+ _N_A_M_E
+ send - send a message
+
+ _S_Y_N_O_P_S_I_S
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-mime] [-nomime] [-msgid] [-nomsgid] [-push] [-nopush]
+ [-split seconds] [-verbose] [-noverbose] [-watch]
[-nowatch]
+ [-width columns] [file ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_e_n_d will cause each of the specified files to be
delivered (via
+ _p_o_s_t (8)) to each of the destinations in the "To:",
"cc:", "Bcc:",
+ and "Fcc:" fields of the message. If _s_e_n_d is
re-distributing a
+ message, as invoked from _d_i_s_t, then the
corresponding "Resent-xxx"
+ fields are examined instead.
+
+ If `-push' is specified, _s_e_n_d will detach itself
from the user's
+ terminal and perform its actions in the background. If
_p_u_s_h 'd and
+ the draft can't be sent, then the `-forward' switch says that
draft
+ should be forwarded with the failure notice sent to the user.
This
+ differs from putting _s_e_n_d in the background because
the output is
+ trapped and analyzed by _M_H.
+
+ If `-verbose' is specified, _s_e_n_d will indicate the
interactions
+ occurring with the transport system, prior to actual
delivery. If
+ `-watch' is specified _s_e_n_d will monitor the delivery
of local and
+ network mail. Hence, by specifying both switches, a large
detail
+ of information can be gathered about each step of the
message's
+ entry into the transport system.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ If `-split' is specified, _s_e_n_d will split the draft
into one or
+ more partial messages prior to sending. This makes use
of the
+ multi-media content feature in MH. Note however that if
_s_e_n_d is
+ invoked under _d_i_s_t (1), then this switch is ignored
-- it makes no
+ sense to redistribute a message in this fashion.
Sometimes you
+ want _s_e_n_d to pause after posting a partial message.
This is usu-
+ ally the case when you are running _s_e_n_d_m_a_i_l
and expect to generate
+ a lot of partial messages. The argument to `-split' tells
it how
+ long to pause between postings.
+
+ _S_e_n_d with no _f_i_l_e argument will query
whether the draft is the
+ intended file, whereas `-draft' will suppress this question.
Once
+ the transport system has successfully accepted custody of the
mes-
+ sage, the file will be renamed with a leading comma, which
allows
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -110-
SEND(1)
+
+
+ it to be retrieved until the next draft message is sent. If
there
+ are errors in the formatting of the message, _s_e_n_d
will abort with a
+ (hopefully) helpful error message.
+
+ If a "Bcc:" field is encountered, its addresses will be
used for
+ delivery, and the "Bcc:" field will be removed from the
message
+ sent to sighted recipients. The blind recipients will
receive an
+ entirely new message with a minimal set of headers.
Included in
+ the body of the message will be a copy of the message sent
to the
+ sighted recipients. If `-filter filterfile' is
specified, then
+ this copy is filtered (re-formatted) prior to being sent
to the
+ blind recipients. Otherwise, to use the MIME rules for
encapsula-
+ tion, specify the `-mime' switch.
+
+ Prior to sending the message, the fields "From:
address@hidden", and
+ "Date: now" will be appended to the headers in the message.
If the
+ envariable $SIGNATURE is set, then its value is used as your
per-
+ sonal name when constructing the "From:" line of the
message. If
+ this envariable is not set, then _s_e_n_d will consult
the profile
+ entry "Signature" for this information. On hosts where
_M_H was con-
+ figured with the UCI option, if $SIGNATURE is not set and the
"Sig-
+ nature" profile entry is not present, then the
file
+ $HOME/.signature is consulted. If `-msgid' is specified,
then a
+ "Message-ID:" field will also be added to the message.
+
+ If _s_e_n_d is re-distributing a message (when invoked by
_d_i_s_t ), then
+ "Resent-" will be prepended to each of these fields:
"From:",
+ "Date:", and "Message-ID:". If the message already
contains a
+ "From:" field, then a "Sender: address@hidden" field will
be added as
+ well. (An already existing "Sender:" field is an error!)
+
+ By using the `-format' switch, each of the entries in the
"To:" and
+ "cc:" fields will be replaced with "standard" format entries.
This
+ standard format is designed to be usable by all of the
message
+ handlers on the various systems around the Internet. If
`-nofor-
+ mat' is given, then headers are output exactly as they
appear in
+ the message draft.
+
+ If an "Fcc: folder" is encountered, the message will be
copied to
+ the specified folder for the sender in the format in which
it will
+ appear to any non-Bcc receivers of the message. That is, it
will
+ have the appended fields and field reformatting. The "Fcc:"
fields
+ will be removed from all outgoing copies of the message.
+
+ By using the `-width columns' switch, the user can direct
_s_e_n_d as
+ to how long it should make header lines containing addresses.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read (more than one file, each preceeded by `-alias',
can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -111-
SEND(1)
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ Signature: To determine the user's mail signature
+ mailproc: Program to post failure notices
+ postproc: Program to post the message
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-alias /usr/bs/mh-6.8/lib/MailAliases'
+ `-nodraftfolder'
+ `-nofilter'
+ `-format'
+ `-forward'
+ `-nomime'
+ `-nomsgid'
+ `-nopush'
+ `-noverbose'
+ `-nowatch'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Under some configurations, it is not possible to mointor the
mail
+ delivery transaction; `-watch' is a no-op on those systems.
+
+ Using `-split 0' doesn't work correctly.
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -112-
SHOW(1)
+
+
+ _N_A_M_E
+ show - show (list) messages
+
+ _S_Y_N_O_P_S_I_S
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_h_o_w lists each of the specified messages to the
standard output
+ (typically, the terminal). Typically, the messages are
listed
+ exactly as they are, with no reformatting. A program named
by the
+ _s_h_o_w_p_r_o_c profile component is invoked to
do the listing, and any
+ switches not recognized by _s_h_o_w are passed along to
that program.
+ The default program is known as _m_o_r_e (1). To
override the default
+ and the _s_h_o_w_p_r_o_c profile component, use
the `-showproc program'
+ switch. For example, `-show pr' will cause the _p_r (1)
program to
+ list the messages. The _M_H command _m_h_l can be used
as a _s_h_o_w_p_r_o_c to
+ show messages in a more uniform format. Normally, this
program is
+ specified as the _s_h_o_w_p_r_o_c is the user's
.mh_profile. See _m_h_l (1)
+ for the details. If the `-noshowproc' option is
specified,
+ `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+ If you have messages with multi-media content, you should
define
+ the profile entry _m_h_n_p_r_o_c, which is the name
of a program to mani-
+ pulate multi-media messages. The _m_h_n (1) program is
suitable for
+ this purpose. Note that if the _m_h_n_p_r_o_c
profile entry is defined,
+ the `-noshowproc' option is NOT specified, and if one or more
named
+ messages has a multi-media content, then the program
indicated by
+ _m_h_n_p_r_o_c will be run instead of
_s_h_o_w_p_r_o_c. The use of the _m_h_n_p_r_o_c
+ can also be disabled if the environment variable $NOMHNPROC
is set.
+
+ The `-header' switch tells _s_h_o_w to display a
one-line description
+ of the message being shown. This description includes the
folder
+ and the message number.
+
+ If no `msgs' are specified, the current message is used. If
more
+ than one message is specified, _m_o_r_e will prompt
for a <RETURN>
+ prior to listing each message. _m_o_r_e will list each
message, a page
+ at a time. When the end of page is reached, _m_o_r_e
will ring the
+ bell and wait for a <SPACE> or <RETURN>. If a <RETURN> is
entered,
+ _m_o_r_e will print the next line, whereas <SPACE> will
print the next
+ screenful. To exit _m_o_r_e, type "q".
+
+ If the standard output is not a terminal, no queries are
made, and
+ each file is listed with a one-line header and two lines of
separa-
+ tion.
+
+ "show -draft" will list the file <mh-dir>/draft if it exists.
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -113-
SHOW(1)
+
+
+ then _s_h_o_w will remove each of the messages shown from
each sequence
+ named by the profile entry. This is similar to
the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Unseen-Sequence: To name sequences denoting unseen
messages
+ showproc: Program to show messages
+ mhnproc: Program to show messages with
multi-media con-
+ tent
+
+
+ _S_e_e _A_l_s_o
+ mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
last
+ message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -114-
SHOW(1)
+
+
+ _B_u_g_s
+ The `-header' switch doesn't work when `msgs' expands to more
than
+ one message. If the _s_h_o_w_p_r_o_c is _m_h_l,
then is problem can be cir-
+ cumvented by referencing the "messagename" field in the
_m_h_l format
+ file.
+
+ _S_h_o_w updates the user's context before showing the
message. Hence
+ _s_h_o_w will mark messages as seen prior to the user
actually seeing
+ them. This is generally not a problem, unless the user
relies on
+ the "unseen" messages mechanism, and interrupts
_s_h_o_w while it is
+ showing "unseen" messages.
+
+ If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w
uses a built-in _m_h_l: it does not ac-
+ tually run the _m_h_l program. Hence, if you
define your own
+ _s_h_o_w_p_r_o_c, don't call it _m_h_l since
_s_h_o_w won't run it.
+
+ If _m_o_r_e (1) is your showproc (the default), then
avoid running _s_h_o_w
+ in the background with only its standard output piped to
another
+ process, as in
+
+ show | imprint &
+
+ Due to a bug in _m_o_r_e, show will go into a "tty
input" state. To
+ avoid this problem, re-direct _s_h_o_w's diagnostic
output as well.
+ For users of _c_s_h:
+
+ show |& imprint &
+
+ For users of _s_h:
+
+ show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -115-
SLOCAL(1)
+
+
+ _N_A_M_E
+ slocal - special local mail delivery
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/slocal [address info sender]
+ [-addr address] [-info data] [-sender sender]
+ [-user username] [-mailbox mbox] [-file file]
+ [-maildelivery deliveryfile] [-verbose] [-noverbose]
[-debug]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_l_o_c_a_l is a program designed to allow you to have
your inbound mail
+ processed according to a complex set of selection criteria.
You do
+ not normally invoke _s_l_o_c_a_l yourself, rather
_s_l_o_c_a_l is invoked on
+ your behalf by your system's Message Transfer Agent.
+
+ The message selection criteria used by _s_l_o_c_a_l is
specified in the
+ file ._m_a_i_l_d_e_l_i_v_e_r_y in the user's
home directory. The format of
+ this file is given below.
+
+ The message delivery address and message sender are
determined from
+ the Message Transfer Agent envelope information, if
possible.
+ Under _S_e_n_d_M_a_i_l, the sender will obtained
from the UUCP "From "
+ line, if present. The user may override these values with
command
+ line arguments, or arguments to the `-addr' and `-sender'
switches.
+
+ The message is normally read from the standard input. The
`-file'
+ switch sets the name of the file from which the message
should be
+ read, instead of reading stdin. The `-user' switch tells
_s_l_o_c_a_l
+ the name of the user for whom it is delivering mail. The
`-mail-
+ box' switch tells _s_l_o_c_a_l the name of the user's
maildrop file.
+
+ The `-info' switch may be used to pass an arbitrary
argument to
+ sub-processes which _s_l_o_c_a_l may invoke on your
behalf. The `-ver-
+ bose' switch causes _s_l_o_c_a_l to give information on
stdout about its
+ progress. The `-debug' switch produces more verbose
debugging out-
+ put on stderr.
+
+
+ _M_e_s_s_a_g_e _T_r_a_n_s_f_e_r _A_g_e_n_t_s
+
+ If your MTA is _S_e_n_d_M_a_i_l, you should include
the line
+
+ "| /usr/bs/mh-6.8/lib/slocal -user username"
+
+ in your .forward file in your home directory. This will
cause
+ _S_e_n_d_M_a_i_l to invoke _s_l_o_c_a_l on your
behalf.
+
+ If your MTA is _M_M_D_F-_I, you should (symbolically)
link /usr/bs/mh-
+ 6.8/lib/slocal to the file bin/rcvmail in your home
directory.
+ This will cause _M_M_D_F-_I to invoke _s_l_o_c_a_l
on your behalf with the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -116-
SLOCAL(1)
+
+
+ correct "_a_d_d_r_e_s_s _i_n_f_o
_s_e_n_d_e_r" arguments.
+
+ If your MTA is _M_M_D_F-_I_I, then you should not
use _s_l_o_c_a_l. An
+ equivalent functionality is already provided by
_M_M_D_F-_I_I; see mail-
+ delivery(5) for details.
+
+
+ _T_h_e _M_a_i_l_d_e_l_i_v_e_r_y _F_i_l_e
+
+
+ The ._m_a_i_l_d_e_l_i_v_e_r_y file controls how
local delivery is performed.
+ Each line of this file consists of five fields,
separated by
+ white-space or comma. Since double-quotes are honored, these
char-
+ acters may be included in a single argument by enclosing the
entire
+ argument in double-quotes. A double-quote can be
included by
+ preceding it with a backslash. Lines beginning with
`#' are
+ ignored. The format of each line in the
._m_a_i_l_d_e_l_i_v_e_r_y file is:
+
+
+ header pattern action result string
+
+ header:
+ The name of a header field that is to be searched for a
pat-
+ tern. This is any field in the headers of the
message that
+ might be present. The following special fields are
also
+ defined:
+
+ _s_o_u_r_c_e the out-of-band sender information
+ _a_d_d_r the address that was used to cause
delivery to the
+ recipient
+ _d_e_f_a_u_l_t this matches _o_n_l_y if
the message hasn't been
+ delivered yet
+ * this always matches
+
+ pattern:
+ The sequence of characters to match in the specified
header
+ field. Matching is case-insensitive, but does not use
regular
+ expressions.
+
+ action:
+ The action to take to deliver the message:
+
+ _d_e_s_t_r_o_y This action always succeeds.
+
+ _f_i_l_e or > Append the message to the file named
by string. The
+ message is appended to the file in the
maildrop for-
+ mat which is used by your message transport
system.
+ If the message can be appended to the
file, then
+ this action succeeds. When writing to the
file, a
+ "Delivery-Date: date" header is added which
indi-
+ cates the date and time that message was
appended to
+ the file.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -117-
SLOCAL(1)
+
+
+ _m_b_o_x Identical to _f_i_l_e, but always
appends the message
+ using the format used by _p_a_c_k_f
(the MMDF mailbox
+ format).
+
+ _p_i_p_e or | Pipe the message as the standard input
to the com-
+ mand named by string, using the Bourne shell
_s_h(1)
+ to interpret the string. Prior to giving the
string
+ to the shell, it is expanded with the
following
+ built-in variables:
+
+ $(sender) the out-of-band sender information
+ $(address) the address that was used to
cause
+ delivery to the recipient
+ $(size) the size of the message in bytes
+ $(reply-to) either the "Reply-To:" or "From:"
field
+ of the message
+ $(info) the out-of-band information specified
+ _q_p_i_p_e or
+ <_c_a_r_e_t> Similar to _p_i_p_e, but
executes the command directly,
+ after built-in variable expansion, without
assis-
+ tance from the shell. This action can be
used to
+ avoid quoting special characters which your
shell
+ might interpret.
+
+ result:
+ Indicates how the action should be performed:
+
+ _A Perform the action. If the action
succeeds, then
+ the message is considered delivered.
+
+ _R Perform the action. Regardless of the
outcome of
+ the action, the message is not considered
delivered.
+
+ ? Perform the action only if the message has not
been
+ delivered. If the action succeeds, then the
message
+ is considered delivered.
+
+ _N Perform the action only if the message has
not been
+ delivered and the previous action
succeeded. If
+ this action succeeds, then the message is
considered
+ delivered.
+
+ To summarize, here's an example:
+
+ #_f_i_e_l_d _p_a_t_t_e_r_n _a_c_t_i_o_n
_r_e_s_u_l_t _s_t_r_i_n_g
+ # lines starting with a '#' are ignored, as are blank lines
+ #
+ # file mail with mmdf2 in the "To:" line into file mmdf2.log
+ _T_o _m_m_d_f_2 _f_i_l_e _A
_m_m_d_f_2._l_o_g
+ # Messages from mmdf pipe to the program err-message-archive
+ _F_r_o_m _m_m_d_f _p_i_p_e _A
/_b_i_n/_e_r_r-_m_e_s_s_a_g_e-_a_r_c_h_i_v_e
+ # Anything with the "Sender:" address "mh-workers"
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -118-
SLOCAL(1)
+
+
+ # file in mh.log if not filed already
+ _S_e_n_d_e_r _m_h-_w_o_r_k_e_r_s
_f_i_l_e ? _m_h._l_o_g
+ # "To:" unix - put in file unix-news
+ _T_o _U_n_i_x > _A
_u_n_i_x-_n_e_w_s
+ # if the address is jpo=ack - send an acknowledgement copy
back
+ _a_d_d_r _j_p_o=_a_c_k | _R
"/_b_i_n/_r_e_s_e_n_d -_r $(_r_e_p_l_y-_t_o)"
+ # anything from steve - destroy!
+ _F_r_o_m _s_t_e_v_e _d_e_s_t_r_o_y
_A -
+ # anything not matched yet - put into mailbox
+ _d_e_f_a_u_l_t - > ?
_m_a_i_l_b_o_x
+ # always run rcvtty
+ * - | _R
/_m_h/_l_i_b/_r_c_v_t_t_y
+
+ The file is always read completely, so that several matches
can be
+ made and several actions can be taken. The
._m_a_i_l_d_e_l_i_v_e_r_y file must
+ be owned either by the user or by root, and must be writable
only
+ by the owner. If the ._m_a_i_l_d_e_l_i_v_e_r_y
file cannot be found, or does
+ not perform an action which delivers the message, then the
file
+ /usr/bs/mh-6.8/lib/maildelivery is read according to the
same
+ rules. This file must be owned by the root and must be
writable
+ only by the root. If this file cannot be found or does not
perform
+ an action which delivers the message, then standard delivery
to the
+ user's maildrop is performed.
+
+
+ _S_u_b-_p_r_o_c_e_s_s _e_n_v_i_r_o_n_m_e_n_t
+
+ When a process is invoked, its environment is: the
user/group-ids
+ are set to recipient's ids; the working directory
is the
+ recipient's home directory; the umask is 0077; the process
has no
+ /dev/tty; the standard input is set to the message; the
standard
+ output and diagnostic output are set to /dev/null; all other
file-
+ descriptors are closed; the envariables $USER, $HOME,
$SHELL are
+ set appropriately, and no other envariables exist.
+
+ The process is given a certain amount of time to execute.
If the
+ process does not exit within this limit, the process will
be ter-
+ minated with extreme prejudice. The amount of time is
calculated
+ as ((size x 60) + 300) seconds, where size is the number of
bytes
+ in the message.
+
+ The exit status of the process is consulted in determining
the suc-
+ cess of the action. An exit status of zero means that the
action
+ succeeded. Any other exit status (or abnormal termination)
means
+ that the action failed.
+
+ In order to avoid any time limitations, you might implement a
pro-
+ cess that began by _f_o_r_k_i_n_g. The parent would
return the appropri-
+ ate value immediately, and the child could continue on, doing
what-
+ ever it wanted for as long as it wanted. This approach is
somewhat
+ risky if the parent is going to return an exit status of
zero. If
+ the parent is going to return a non-zero exit status,
then this
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -119-
SLOCAL(1)
+
+
+ approach can lead to quicker delivery into your maildrop.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/mtstailor MH tailor file
+ $HOME/.maildelivery The file controlling
local delivery
+ /usr/bs/mh-6.8/lib/maildelivery Rather than the standard
file
+ /usr/spool/mail/$USER The default maildrop
+
+
+ _S_e_e _A_l_s_o
+ rcvstore(1), mhook(1), mh-format(5) , maildelivery(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-noverbose'
+ `-maildelivery .maildelivery'
+ `-mailbox /usr/spool/mail/$USER'
+ `-file' defaults to stdin
+ `-user' defaults to the current user
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ _S_l_o_c_a_l is designed to be backward-compatible with
the _m_a_i_l_d_e_l_i_v_e_r_y
+ facility provided by _M_M_D_F-_I_I. Thus, the
._m_a_i_l_d_e_l_i_v_e_r_y file syntax
+ is limited, as is the functionality of _s_l_o_c_a_l.
+
+ In addition to an exit status of zero, the _M_M_D_F
values _R_P__M_O_K (32)
+ and _R_P__O_K (9) mean that the message has been fully
delivered. Any
+ other non-zero exit status, including abnormal termination,
is in-
+ terpreted as the _M_M_D_F value _R_P__M_E_C_H
(200), which means "use an al-
+ ternate route" (deliver the message to the maildrop).
+
+
+ _B_u_g_s
+ Only two return codes are meaningful, others should be.
+
+ _S_l_o_c_a_l is designed to be backwards-compatible
with the _m_a_i_l_d_e_l_i_v_e_r_y
+ functionality provided by MMDF-II.
+
+ Versions of _M_M_D_F with the
_m_a_i_l_d_e_l_i_v_e_r_y mechanism aren't entirely
+ backwards-compatible with earlier versions of _M_M_D_F.
If you have an
+ _M_M_D_F-_I old-style hook, the best you can do is to
have a one-line
+ ._m_a_i_l_d_e_l_i_v_e_r_y file:
+
+ default - pipe A "bin/rcvmail $(address) $(info)
$(sender)"
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -120-
SORTM(1)
+
+
+ _N_A_M_E
+ sortm - sort messages
+
+ _S_Y_N_O_P_S_I_S
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_o_r_t_m sorts the specified messages in the named
folder according to
+ the chronological order of the "Date:" field of each message.
+
+ The `-verbose' switch directs _s_o_r_t_m to tell the
user the general
+ actions that it is taking to place the folder in sorted order.
+
+ The `-datefield field' switch tells _s_o_r_t_m the name
of the field to
+ use when making the date comparison. If the user has a
special
+ field in each message, such as "BB-Posted:" or
"Delivery-Date:",
+ then the `-datefield' switch can be used to direct
_s_o_r_t_m which
+ field to examine.
+
+ The `-textfield field' switch causes _s_o_r_t_m to sort
messages by the
+ specified text field. If this field is "subject", any
leading
+ "re:" is stripped off. In any case, all characters except
letters
+ and numbers are stripped and the resulting strings are
sorted
+ datefield-major, textfield-minor, using a case insensitive
com-
+ parison.
+
+ With `-textfield field', if `-limit days' is specified,
messages
+ with similar textfields that are dated within `days' of each
other
+ appear together. Specifying `-nolimit' makes the limit
infinity.
+ With `-limit 0', the sort is instead made
textfield-major,
+ date-minor.
+
+ For example, to order a folder by date-major, subject-minor,
use:
+
+ sortm -textfield subject +folder
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder (1)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -121-
SORTM(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-notextfield'
+ `-noverbose'
+ `-nolimit'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
If the
+ current message is moved, _s_o_r_t_m will preserve
its status as
+ current.
+
+
+ _H_i_s_t_o_r_y
+ Timezones used to be ignored when comparing dates: they
aren't any
+ more.
+
+ Messages which were in the folder, but not specified by
`msgs',
+ used to be moved to the end of the folder; now such
messages are
+ left untouched.
+
+ Previously, _s_o_r_t_m would try to fill any gaps in a
folder within the
+ range of messages it sorted. To improve performance,
_s_o_r_t_m now
+ minimizes the number of message moves. To pack a
folder, use
+ "_f_o_l_d_e_r -_p_a_c_k" instead.
+
+
+ _B_u_g_s
+ If _s_o_r_t_m encounters a message without a date-field,
or if the mes-
+ sage has a date-field that _s_o_r_t_m cannot parse,
then _s_o_r_t_m attempts
+ to keep the message in the same relative position. This
does not
+ always work. For instance, if the first message encountered
lacks
+ a date which can be parsed, then it will usually be placed
at the
+ end of the messages being sorted.
+
+ When _s_o_r_t_m complains about a message which it can't
temporally ord-
+ er, it complains about the message number _p_r_i_o_r
to sorting. It
+ should indicate what the message number will be
_a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ VMH(1) -122-
VMH(1)
+
+
+ _N_A_M_E
+ vmh - visual front-end to MH
+
+ _S_Y_N_O_P_S_I_S
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _v_m_h is a program which implements the server side of
the _M_H window
+ management protocol and uses _c_u_r_s_e_s (3)
routines to maintain a
+ split-screen interface to any program which implements the
client
+ side of the protocol. This latter program, called the
_v_m_h_p_r_o_c, is
+ specified using the `-vmhproc program' switch.
+
+ The upshot of all this is that one can run _m_s_h on a
display termi-
+ nal and get a nice visual interface. To do this, for
example, just
+ add the line
+
+ mshproc: vmh
+
+ to your .mh_profile. (This takes advantage of the fact that
_m_s_h is
+ the default _v_m_h_p_r_o_c for _v_m_h.)
+
+ In order to facilitate things, if the `-novmhproc' switch is
given,
+ and _v_m_h can't run on the user's terminal, the
_v_m_h_p_r_o_c is run
+ directly without the window management protocol.
+
+ After initializing the protocol, _v_m_h prompts the user
for a command
+ to be given to the client. Usually, this results in output
being
+ sent to one or more windows. If a output to a window would
cause
+ it to scroll, _v_m_h prompts the user for instructions,
roughly per-
+ mitting the capabilities of _l_e_s_s or _m_o_r_e
(e.g., the ability to
+ scroll backwards and forwards):
+
+ SPACE advance to the next windowful
+ RETURN * advance to the next line
+ y * retreat to the previous line
+ d * advance to the next ten lines
+ u * retreat to the previous ten lines
+ g * go to an arbitrary line
+ (preceed g with the line number)
+ G * go to the end of the window
+ (if a line number is given, this acts like
`g')
+ CTRL-L refresh the entire screen
+ h print a help message
+ q abort the window
+
+ (A `*' indicates that a numeric prefix is meaningful for this
com-
+ mand.)
+
+ Note that if a command resulted in more than one window's
worth of
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ VMH(1) -123-
VMH(1)
+
+
+ information being displayed, and you allow the command
which is
+ generating information for the window to gracefully finish
(i.e.,
+ you don't use the `q' command to abort information being
sent to
+ the window), then _v_m_h will give you one last change to
peruse the
+ window. This is useful for scrolling back and forth.
Just type
+ `q' when you're done.
+
+ To abnormally terminate _v_m_h (without core dump), use
<QUIT> (usu-
+ ally CTRL-\). For instance, this does the "right" thing
with _b_b_c
+ and _m_s_h.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+
+
+ _S_e_e _A_l_s_o
+ msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt (vmh) '
+ `-vmhproc msh'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _v_m_h. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+ At present, there is no way to pass signals (e.g., interrupt,
quit)
+ to the client. However, generating QUIT when _v_m_h is
reading a com-
+ mand from the terminal is sufficient to tell the client to go
away
+ quickly.
+
+ Acts strangely (loses peer or botches window management
protocol
+ with peer) on random occasions.
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -124-
WHATNOW(1)
+
+
+ _N_A_M_E
+ whatnow - prompting front-end for send
+
+ _S_Y_N_O_P_S_I_S
+ whatnow [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_a_t_n_o_w is the default program that queries
the user about the
+ disposition of a composed draft. It is normally invoked by
one of
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l
after the initial edit.
+
+ When started, the editor is started on the draft (unless
`-noedit'
+ is given, in which case the initial edit is suppressed).
Then,
+ _w_h_a_t_n_o_w repetitively prompts the user with
"What now?" and awaits a
+ response. The valid responses are:
+
+ display to list the message being
distributed/replied-to on
+ the terminal
+ edit to re-edit using the same editor that was
used on the
+ preceding round unless a profile entry
+ "<lasteditor>-next: <editor>" names an
alternate editor
+ edit <editor> to invoke <editor> for further editing
+ list to list the draft on the terminal
+ push to send the message in the background
+ quit to terminate the session and preserve the
draft
+ quit -delete to terminate, then delete the draft
+ refile +folder to refile the draft into the given folder
+ send to send the message
+ send -watch to cause the delivery process to be monitored
+ whom to list the addresses that the message will
go to
+ whom -check to list the addresses and verify that they are
+ acceptable to the transport service
+
+ For the edit response, any valid switch to the editor is
valid.
+ Similarly, for the send and whom responses, any valid
switch to
+ _s_e_n_d (1) and _w_h_o_m (1) commands, respectively,
are valid. For the
+ push response, any valid switch to _s_e_n_d (1) is
valid (as this
+ merely invokes _s_e_n_d with the `-push' option).
For the _r_e_f_i_l_e
+ response, any valid switch to the
_f_i_l_e_p_r_o_c is valid. For the
+ display and list responses, any valid argument to the
_l_p_r_o_c is
+ valid. If any non-switch arguments are present, then the
pathname
+ of the draft will be excluded from the argument list given
to the
+ _l_p_r_o_c (this is useful for listing another _M_H
message).
+
+ See _m_h-_p_r_o_f_i_l_e (5) for further information
about how editors are
+ used by MH. It also discusses how complex envariables can
be used
+ to direct _w_h_a_t_n_o_w's actions.
+
+ The `-prompt string' switch sets the prompting string for
_w_h_a_t_n_o_w.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -125-
WHATNOW(1)
+
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ <lasteditor>-next: To name an editor to be used after exit
from
+ <lasteditor>
+ automhnproc: Program to automatically run prior to
sending
+ if the draft is an _m_h_n composition
file
+ fileproc: Program to refile the message
+ lproc: Program to list the contents of a message
+ sendproc: Program to use to send the message
+ whomproc: Program to determine who a message would
go to
+
+
+ _S_e_e _A_l_s_o
+ send(1), whom(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt "What Now? "'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -126-
WHATNOW(1)
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _w_h_a_t_n_o_w.
Therefore, one must
+ usually place the argument to this switch inside
double-quotes.
+
+ If the initial edit fails, _w_h_a_t_n_o_w deletes your
draft (by renaming
+ it with a leading comma); failure of a later edit
preverves the
+ draft.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l use a
+ built-in _w_h_a_t_n_o_w, and do not actually run
the _w_h_a_t_n_o_w program.
+ Hence, if you define your own
_w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w
+ since it won't be run.
+
+ If _s_e_n_d_p_r_o_c is _s_e_n_d, then
_w_h_a_t_n_o_w uses a built-in _s_e_n_d, it does not
+ actually run the _s_e_n_d program. Hence, if you
define your own
+ _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since
_w_h_a_t_n_o_w won't run it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHOM(1) -127-
WHOM(1)
+
+
+ _N_A_M_E
+ whom - report to whom a message would go
+
+ _S_Y_N_O_P_S_I_S
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [file] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_o_m is used to expand the headers of a message
into a set of
+ addresses and optionally verify that those addresses are
deliver-
+ able at that time (if `-check' is given).
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read (more than one file, each preceeded by `-alias',
can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ postproc: Program to post the message
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-nocheck'
+ `-alias /usr/bs/mh-6.8/lib/MailAliases'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHOM(1) -128-
WHOM(1)
+
+
+ _B_u_g_s
+ With the `-check' option, _w_h_o_m makes no guarantees
that the ad-
+ dresses listed as being ok are really deliverable, rather,
an ad-
+ dress being listed as ok means that at the time that
_w_h_o_m was run
+ the address was thought to be deliverable by the transport
service.
+ For local addresses, this is absolute; for network
addresses, it
+ means that the host is known; for uucp addresses, it (often)
means
+ that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+ -129-
+
+
+ _M_O_R_E _D_E_T_A_I_L_S
+
+ This section describes some of the more intense points
of the _M_H
+ system, by expanding on topics previously discussed.
The format
+ presented conforms to the standard form for the
description of UNIX
+ documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -130-
MH-ALIAS(5)
+
+
+ _N_A_M_E
+ mh-alias - alias file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This describes both _M_H personal alias files and the
(primary) alias
+ file for mail delivery, the file
+
+ /usr/bs/mh-6.8/lib/MailAliases
+
+ It does not describe aliases files used by the message
transport
+ system. Each line of the alias file has the format:
+
+ alias : address-group
+ or
+ alias ; address-group
+ or
+ < alias-file
+ or
+ ; comment
+
+ where:
+
+ address-group := address-list
+ | "<" file
+ | "=" UNIX-group
+ | "+" UNIX-group
+ | "*"
+
+ address-list := address
+ | address-list, address
+
+ Continuation lines in alias files end with `\' followed by
the new-
+ line character.
+
+ Alias-file and file are UNIX file names. UNIX-group is a
group
+ name (or number) from /_e_t_c/_g_r_o_u_p. An
address is a "simple"
+ Internet-style address. Througout this file, case is
ignored,
+ except for alias-file names.
+
+ If the line starts with a `<', then the file named after the
`<' is
+ read for more alias definitions. The reading is done
recursively,
+ so a `<' may occur in the beginning of an alias file
with the
+ expected results.
+
+ If the address-group starts with a `<', then the file named
after
+ the `<' is read and its contents are added to the
address-list for
+ the alias.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -131-
MH-ALIAS(5)
+
+
+ If the address-group starts with an `=', then the file
/_e_t_c/_g_r_o_u_p
+ is consulted for the UNIX-group named after the `='. Each
login
+ name occurring as a member of the group is added to
the
+ address-list for the alias.
+
+ In contrast, if the address-group starts with a `+', then the
file
+ /_e_t_c/_g_r_o_u_p is consulted to determine the
group-id of the UNIX-group
+ named after the `+'. Each login name occurring in the
/_e_t_c/_p_a_s_s_w_d
+ file whose group-id is indicated by this group is added
to the
+ address-list for the alias.
+
+ If the address-group is simply `*', then the file
/_e_t_c/_p_a_s_s_w_d is
+ consulted and all login names with a userid greater than some
magic
+ number (usually 200) are added to the address-list for the
alias.
+
+ In match, a trailing * on an alias will match just about
anything
+ appropriate. (See example below.)
+
+ An approximation of the way aliases are resolved at posting
time is
+ (it's not really done this way):
+
+ 1) Build a list of all addresses from the message
to be
+ delivered, eliminating duplicate addresses.
+
+ 2) If this draft originated on the local host, then for
those
+ addresses in the message that have no host specified,
perform
+ alias resolution.
+
+ 3) For each line in the alias file, compare "alias"
against
+ all of the existing addresses. If a match, remove the
matched
+ "alias" from the address list, and add each new address
in the
+ address-group to the address list if it is not already
on the
+ list. The alias itself is not usually output,
rather the
+ address-group that the alias maps to is output
instead. If
+ "alias" is terminated with a `;' instead of a `:', then
both
+ the "alias" and the address are output in the correct
format.
+ (This makes replies possible since _M_H aliases and
personal
+ aliases are unknown to the mail transport system.)
+
+ Since the alias file is read line by line, forward references
work,
+ but backward references are not recognized, thus, there
is no
+ recursion.
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -132-
MH-ALIAS(5)
+
+
+ Example:
+ </usr/bs/mh-6.8/lib/BBoardAliases
+ sgroup: fred, fear, freida
+ b-people: Blind List: bill, betty;
+ fred: address@hidden
+ UNIX-committee: <unix.aliases
+ staff: =staff
+ wheels: +wheel
+ everyone: *
+ news.*: news
+
+ The first line says that more aliases should immediately be
read
+ from the file
/_u_s_r/_b_s/_m_h-_6._8/_l_i_b/_B_B_o_a_r_d_A_l_i_a_s_e_s.
Following this,
+ "fred" is defined as an alias for "address@hidden", and
"sgroup" is
+ defined as an alias for the three names "address@hidden",
"fear", and
+ "freida".
+
+ The alias "b-people" is a blind list which includes the
addresses
+ "bill" and "betty"; the message will be delieved to
those
+ addresses, but the message header will show only "Blind
List: ;"
+ (not the addresses).
+
+ Next, the definition of "UNIX-committee" is given by
reading the
+ file _u_n_i_x._a_l_i_a_s_e_s in the users _M_H
directory, "staff" is defined as
+ all users who are listed as members of the group "staff"
in the
+ /_e_t_c/_g_r_o_u_p file, and "wheels" is defined
as all users whose
+ group-id in /_e_t_c/_p_a_s_s_w_d is equivalent to
the "wheel" group.
+
+ Finally, "everyone" is defined as all users with a
user-id in
+ /_e_t_c/_p_a_s_s_w_d greater than 200, and all
aliases of the form
+ "news.<anything>" are defined to be "news".
+
+ The key thing to understand about aliasing in _M_H is that
aliases in
+ _M_H alias files are expanded into the headers of
messages posted.
+ This aliasing occurs first, at posting time, without the
knowledge
+ of the message transport system. In contrast, once the
message
+ transport system is given a message to deliver to a
list of
+ addresses, for each address that appears to be local, a
system-wide
+ alias file is consulted. These aliases are NOT expanded
into the
+ headers of messages delivered.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ To use aliasing in _M_H quickly, do the following:
+
+ First, in your ._m_h__p_r_o_f_i_l_e, choose a
name for your alias file,
+ say "aliases", and add the line:
+
+ Aliasfile: aliases
+
+ Second, create the file "aliases" in your _M_H
directory.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -133-
MH-ALIAS(5)
+
+
+ Third, start adding aliases to your "aliases"
file as
+ appropriate.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ ali(1), send(1), whom(1), group(5), passwd(5), conflict(8),
post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ In previous releases of _M_H, only a single, system-wide
mh-alias
+ file was supported. Now that _M_H uses _M_M_D_F as a
transport system,
+ the system-wide aliasing facility can be more consistently
con-
+ trolled by the latter. This means that at most
sites, the
+ system-wide mh-alias file will be empty (or trivial at
best).
+ Hence, the semantics of mh-alias were extended to support
personal
+ alias files. Users of _M_H no longer need to bother
mail-system ad-
+ ministrators for keeping information in the system-wide alias
file,
+ as each _M_H user can create/modify/remove aliases at will
from any
+ number of personal files.
+
+
+ _B_u_g_s
+ Although the forward-referencing semantics of
_m_h-_a_l_i_a_s files
+ prevent recursion, the "< alias-file" command may defeat
this.
+ Since the number of file descriptors is finite (and very
limited),
+ such infinite recursion will terminate with a meaningless
diagnos-
+ tic when all the fds are used up.
+
+ Forward references do not work correctly inside blind lists.
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -134-
MH-FORMAT(5)
+
+
+ _N_A_M_E
+ mh-format - format file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ some _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Several _M_H commands utilize either a _f_o_r_m_a_t
string or a _f_o_r_m_a_t file
+ during their execution. For example, _s_c_a_n (1) uses a
format string
+ which directs it how to generate the scan listing for each
message;
+ _r_e_p_l (1) uses a format file which directs it how
to generate the
+ reply to a message, and so on.
+
+ Format strings are designed to be efficiently parsed by
_M_H which
+ means they are not necessarily simple to write and
understand.
+ This means that novice, casual, or even advanced users of
_M_H should
+ not have to deal with them. Some canned scan listing
formats are
+ in /usr/bs/mh-6.8/lib/scan.time,
/usr/bs/mh-6.8/lib/scan.size, and
+ /usr/bs/mh-6.8/lib/scan.timely. Look in
/usr/bs/mh-6.8/lib for
+ other _s_c_a_n and _r_e_p_l format files which may
have been written at
+ your site.
+
+ It suffices to have your local _M_H expert actually write
new format
+ commands or modify existing ones. This manual section
explains how
+ to do that. Note: familiarity with the C
_p_r_i_n_t_f routine is
+ assumed.
+
+ A format string consists of ordinary text, and special
multi-
+ character _e_s_c_a_p_e sequences which begin with `%'.
When specifying a
+ format string, the usual C backslash characters are honored:
`\b',
+ `\f', `\n', `\r', and `\t'. Continuation lines in format
files end
+ with `\' followed by the newline character. There are three
types
+ of _e_s_c_a_p_e sequences: header
_c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and
+ flow _c_o_n_t_r_o_l.
+
+ A _c_o_m_p_o_n_e_n_t escape is specified as
`%{_c_o_m_p_o_n_e_n_t}', and exists for
+ each header found in the message being processed. For
example
+ `%{date}' refers to the "Date:" field of the appropriate
message.
+ All component escapes have a string value. Normally,
component
+ values are compressed by converting any control characters
(tab and
+ newline included) to spaces, then eliding any leading or
multiple
+ spaces. However, commands may give different
interpretations to
+ some component escapes; be sure to refer to each command's
manual
+ entry for complete details.
+
+ A _f_u_n_c_t_i_o_n escape is specified as
`%(_f_u_n_c_t_i_o_n)'. All functions are
+ built-in, and most have a string or numeric value.
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -135-
MH-FORMAT(5)
+
+
+ _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+ A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|',
or `%>'. These are
+ combined into the conditional execution construct:
+
+ %<condition
+ _f_o_r_m_a_t _t_e_x_t _1
+ %?condition2
+ _f_o_r_m_a_t _t_e_x_t _2
+ %?condition3
+ _f_o_r_m_a_t _t_e_x_t _3
+ ...
+ %|
+ _f_o_r_m_a_t _t_e_x_t _N
+ %>
+
+ Extra white space is shown here only for clarity. These
constructs
+ may be nested without ambiguity. They form a
general
+ if-elseif-else-endif block where only one of the
_f_o_r_m_a_t _t_e_x_t seg-
+ ments is interpreted.
+
+ The `%<' and `%?' control escapes causes a condition
to be
+ evaluated. This condition may be either a
_c_o_m_p_o_n_e_n_t or a _f_u_n_c_t_i_o_n.
+ The four constructs have the following syntax:
+
+ %<{component}
+ %<(function)
+ %?{component}
+ %?(function)
+
+ These control escapes test whether the function or component
value
+ is non-zero (for integer-valued escapes), or non-empty
(for
+ string-valued escapes).
+
+ If this test evaulates true, then the format text up to the
next
+ corresponding control escape (one of `%|', `%?', or `%>') is
inter-
+ preted normally. Next, all format text (if any) up
to the
+ corresponding `%>' control escape is skipped. The `%>'
control
+ escape is not interpreted; normal interpretation resumes
after the
+ `%>' escape.
+
+ If the test evaluates false, however, then the format text
up to
+ the next corresponding control escape (again, one of `%|',
`%?', or
+ `%>') is skipped, instead of being interpreted. If the
control
+ escape encountered was `%?', then the condition
associated with
+ that control escape is evaluated, and interpretation proceeds
after
+ that test as described in the previous paragraph. If the
control
+ escape encountered was `%|', then the format text up
to the
+ corresponding `%>' escape is interpreted normally. As
above, the
+ `%>' escape is not interpreted and normal interpretation
resumes
+ after the `%>' escape.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -136-
MH-FORMAT(5)
+
+
+ The `%?' control escape and its following format text is
optional,
+ and may be included zero or more times. The `%|' control
escape
+ and its following format text is also optional, and may be
included
+ zero or one times.
+
+
+ _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+ Most functions expect an argument of a particular type:
+
+ _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n
_E_x_a_m_p_l_e _S_y_n_t_a_x
+ literal A literal number, %(_f_u_n_c 1234)
+ or string %(_f_u_n_c text string)
+ comp Any header component
%(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+ date A date component %(_f_u_n_c{_d_a_t_e})
+ addr An address component %(_f_u_n_c{_f_r_o_m})
+ expr An optional component,
%(_f_u_n_c(_f_u_n_c_2))
+ function or control, %(_f_u_n_c
%<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+ perhaps nested
%(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+ The types _d_a_t_e and _a_d_d_r have the same syntax
as _c_o_m_p, but require
+ that the header component be a date string, or address
string,
+ respectively.
+
+ All arguments except those of type _e_x_p_r are required.
For the _e_x_p_r
+ argument type, the leading `%' must be omitted for
component and
+ function escape arguments, and must be present (with a
leading
+ space) for control escape arguments.
+
+ The evaluation of format strings is based on a simple machine
with
+ an integer register _n_u_m, and a text string register
_s_t_r. When a
+ function escape is processed, if it accepts an optional
_e_x_p_r argu-
+ ment which is not present, it reads the current value of
either _n_u_m
+ or _s_t_r as appropriate.
+
+
+ _R_e_t_u_r_n _v_a_l_u_e_s
+
+ Component escapes write the value of their message header in
_s_t_r.
+ Function escapes write their return value in _n_u_m
for functions
+ returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n
values, and in _s_t_r for functions
+ returning string values. (The _b_o_o_l_e_a_n type is
a subset of integers
+ with usual values 0=false and 1=true.) Control escapes
return a
+ _b_o_o_l_e_a_n value, and set _n_u_m.
+
+ All component escapes, and those function escapes which
return an
+ _i_n_t_e_g_e_r or _s_t_r_i_n_g value, pass
this value back to their caller in
+ addition to setting _s_t_r or _n_u_m. These escapes
will print out this
+ value unless called as part of an argument to another
escape
+ sequence. Escapes which return a _b_o_o_l_e_a_n value
do pass this value
+ back to their caller in _n_u_m, but will never print out
the value.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -137-
MH-FORMAT(5)
+
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ msg integer message number
+ cur integer message is current
+ size integer size of message
+ strlen integer length of _s_t_r
+ width integer output buffer size in bytes
+ charleft integer bytes left in output buffer
+ timenow integer seconds since the UNIX epoch
+ me string the user's mailbox
+ eq literal boolean _n_u_m == _a_r_g
+ ne literal boolean _n_u_m != _a_r_g
+ gt literal boolean _n_u_m > _a_r_g
+ match literal boolean _s_t_r contains _a_r_g
+ amatch literal boolean _s_t_r starts with _a_r_g
+ plus literal integer _a_r_g plus _n_u_m
+ minus literal integer _a_r_g minus _n_u_m
+ divide literal integer _n_u_m divided by _a_r_g
+ modulo literal integer _n_u_m modulo _a_r_g
+ num literal integer Set _n_u_m to _a_r_g
+ lit literal string Set _s_t_r to _a_r_g
+ getenv literal string Set _s_t_r to environment
value of _a_r_g
+ nonzero expr boolean _n_u_m is non-zero
+ zero expr boolean _n_u_m is zero
+ null expr boolean _s_t_r is empty
+ nonnull expr boolean _s_t_r is non-empty
+ void expr Set _s_t_r or _n_u_m
+ comp comp string Set _s_t_r to component text
+ compval comp integer _n_u_m set to
"atoi(_c_o_m_p)"
+ trim expr trim trailing white-space from
_s_t_r
+ putstr expr print _s_t_r
+ putstrf expr print _s_t_r in a fixed width
+ putnum expr print _n_u_m
+ putnumf expr print _n_u_m in a fixed width
+
+ These functions require a date component as an argument:
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ sec date integer seconds of the minute
+ min date integer minutes of the hour
+ hour date integer hours of the day (0-23)
+ wday date integer day of the week (Sun=0)
+ day date string day of the week (abbrev.)
+ weekday date string day of the week
+ sday date integer day of the week known?
+ (0=implicit,-1=unknown)
+ mday date integer day of the month
+ yday date integer day of the year
+ mon date integer month of the year
+ month date string month of the year (abbrev.)
+ lmonth date string month of the year
+ year date integer year (may be > 100)
+ zone date integer timezone in hours
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -138-
MH-FORMAT(5)
+
+
+ tzone date string timezone string
+ szone date integer timezone explicit?
+ (0=implicit,-1=unknown)
+ date2local date coerce date to local timezone
+ date2gmt date coerce date to GMT
+ dst date integer daylight savings in effect?
+ clock date integer seconds since the UNIX epoch
+ rclock date integer seconds prior to current time
+ tws date string official 822 rendering
+ pretty date string user-friendly rendering
+ nodate date integer _s_t_r not a date string
+
+ These functions require an address component as an
argument. The
+ return value of functions noted with `*' pertain only to the
first
+ address present in the header component.
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ proper addr string official 822 rendering
+ friendly addr string user-friendly rendering
+ addr addr string address@hidden or host!mbox
rendering*
+ pers addr string the personal name*
+ note addr string commentary text*
+ mbox addr string the local mailbox*
+ mymbox addr integer the user's addresses?
(0=no,1=yes)
+ host addr string the host domain*
+ nohost addr integer no host was present*
+ type addr integer host type* (0=local,1=network,
+ -1=uucp,2=unknown)
+ path addr string any leading host route*
+ ingrp addr integer address was inside a group*
+ gname addr string name of group*
+ formataddr expr append _a_r_g to _s_t_r as
a
+ (comma separated) address list
+ putaddr literal print _s_t_r address list with
+ _a_r_g as optional label;
+ get line width from _n_u_m
+
+ When escapes are nested, evaluation is done from
inner-most to
+ outer-most. The outer-most escape must begin with `%'; the
inner
+ escapes must not. For example,
+
+ %<(mymbox{from}) To: %{to}%>
+
+ writes the value of the header component "From:" to
_s_t_r; then (_m_y_m_-
+ _b_o_x) reads _s_t_r and writes its result to
_n_u_m; then the control
+ escape evaluates _n_u_m. If _n_u_m is non-zero, the
string "To: " is
+ printed followed by the value of the header component "To:".
+
+ A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is
in order. In general, it
+ checks each of the addresses in the header component
"_c_o_m_p" against
+ the user's mailbox name and any
_A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s. It returns
+ true if any address matches, however, it also returns true
if the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -139-
MH-FORMAT(5)
+
+
+ "_c_o_m_p" header is not present in the message. If
needed, the (_n_u_l_l)
+ function can be used to explicitly test for this condition.
+
+ When a function or component escape is interpreted and the
result
+ will be immediately printed, an optional field width can be
speci-
+ fied to print the field in exactly a given number of
characters.
+ For example, a numeric escape like %4(_s_i_z_e) will
print at most 4
+ digits of the message size; overflow will be indicated by a
`?' in
+ the first position (like `?234'). A string escape like
%4(_m_e) will
+ print the first 4 characters and truncate at the end. Short
fields
+ are padded at the right with the fill character
(normally, a
+ blank). If the field width argument begins with a leading
zero,
+ then the fill character is set to a zero.
+
+ As above, the functions (_p_u_t_n_u_m_f) and
(_p_u_t_s_t_r_f) print their result
+ in exactly the number of characters specified by their
leading
+ field width argument. For example,
%06(_p_u_t_n_u_m_f(_s_i_z_e)) will print
+ the message size in a field six characters wide filled with
leading
+ zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print
the "From:" header component
+ in fourteen characters with trailing spaces added as
needed. For
+ _p_u_t_s_t_r_f, using a negative value for the field
width causes right-
+ justification of the string within the field, with padding
on the
+ left up to the field width. The functions
(_p_u_t_n_u_m) and (_p_u_t_s_t_r)
+ print their result in the minimum number of characters
required,
+ and ignore any leading field width argument.
+
+ The available output width is kept in an internal
register; any
+ output past this width will be truncated.
+
+ Comments may be inserted in most places where a function
argument
+ is not expected. A comment begins with `%;' and ends with a
(non-
+ escaped) newline.
+
+ With all this in mind, here's the default format string for
_s_c_a_n.
+ It's been divided into several pieces for readability. The
first
+ part is:
+
+ %4(msg)%<(cur)+%| %>%<{replied}-%?{encrypted}E%| %>
+
+ which says that the message number should be printed in
four
+ digits, if the message is the current message then a `+'
else a
+ space should be printed, and if a "Replied:" field is present
then
+ a `-' else if an "Encrypted:" field is present then an `E'
other-
+ wise a space should be printed. Next:
+
+ %02(mon{date})/%02(mday{date})
+
+ the month and date are printed in two digits (zero
filled)
+ separated by a slash. Next,
+
+ %<{date} %|*>
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -140-
MH-FORMAT(5)
+
+
+ If a "Date:" field was present, then a space is printed,
otherwise
+ a `*'. Next,
+
+ %<(mymbox{from})%<{to}To:%14(friendly{to})%>%>
+
+ if the message is from me, and there is a "To:" header, print
`To:'
+ followed by a "user-friendly" rendering of the first address
in the
+ "To:" field. Continuing,
+
+ %<(zero)%17(friendly{from})%>
+
+ if either of the above two tests failed, then the "From:"
address
+ is printed in a "user-friendly" format. And finally,
+
+ %{subject}%<{body}<<%{body}%>
+
+ the subject and initial body (if any) are printed.
+
+ For a more complicated example, next consider the default
_r_e_p_l_c_o_m_p_s
+ format file.
+
+ %(lit)%(formataddr %<{reply-to}
+
+ This clears _s_t_r and formats the "Reply-To:" header if
present. If
+ not present, the else-if clause is executed.
+
+ %?{from}%?{sender}%?{return-path}%>)\
+
+ This formats the "From:", "Sender:" and "Return-Path:"
headers,
+ stopping as soon as one of them is present. Next:
+
+ %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+ If the _f_o_r_m_a_t_a_d_d_r result is non-null, it
is printed as an address
+ (with line folding if needed) in a field _w_i_d_t_h
wide with a leading
+ label of "To: ".
+
+
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+ _s_t_r is cleared, and the "To:" and "Cc:" headers,
along with the
+ user's address (depending on what was specified with the
"-cc"
+ switch to _r_e_p_l) are formatted.
+
+ %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+ If the result is non-null, it is printed as above with a
leading
+ label of "cc: ".
+
+ %<{fcc}Fcc: %{fcc}\n%>\
+
+ If a "-fcc folder" switch was given to _r_e_p_l (see
_r_e_p_l (1) for more
+ details about %{_f_c_c}), an "Fcc:" header is output.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -141-
MH-FORMAT(5)
+
+
+ %<{subject}Subject: Re: %{subject}\n%>\
+
+ If a subject component was present, a suitable reply
subject is
+ output.
+
+ %<{date}In-reply-to: Your message of "\
+
%<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id}
+ %{message-id}%>\n%>\
+ --------
+
+ If a date component was present, an "In-Reply-To:" header is
output
+ with the preface "Your message of ". If the date was
parseable, it
+ is output in a user-friendly format, otherwise it is output
as-is.
+ The message-id is included if present. As with all
plain-text, the
+ row of dashes are output as-is.
+
+ This last part is a good example for a little more
elaboration.
+ Here's that part again in pseudo-code:
+
+ if (comp_exists(date)) then
+ print ("In-reply-to: Your message of \"")
+ if (not_date_string(date.value) then
+ print (date.value)
+ else
+ print (pretty(date.value))
+ endif
+ print ("\"")
+ if (comp_exists(message-id)) then
+ print ("\n\t")
+ print (message-id.value)
+ endif
+ print ("\n")
+ endif
+
+ Although this seems complicated, in point of fact, this
method is
+ flexible enough to extract individual fields and print them
in any
+ format the user desires.
+
+ _F_i_l_e_s
+ None
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ scan(1), repl(1), ap(8), dp(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -142-
MH-FORMAT(5)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ This software was contributed for MH 6.3. Prior to this,
output
+ format specifications were much easier to write, but
considerably
+ less flexible.
+
+
+ _B_u_g_s
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -143-
MH-MAIL(5)
+
+
+ _N_A_M_E
+ mh-mail - message format for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H processes messages in a particular format. It should
be noted
+ that although neither Bell nor Berkeley mailers produce
message
+ files in the format that _M_H prefers, _M_H can read
message files in
+ that antiquated format.
+
+ Each user possesses a mail drop box which initially
receives all
+ messages processed by _p_o_s_t (8). _I_n_c (1) will
read from that drop
+ box and incorporate the new messages found there into the
user's
+ own mail folders (typically `+inbox'). The mail drop box
consists
+ of one or more messages. To facilitate the separation of
messages,
+ each message begins and ends with a line consisting of
nothing but
+ four CTRL-A (octal 001) characters.
+
+ Messages are expected to consist of lines of text.
Graphics and
+ binary data are not handled. No data compression is
accepted. All
+ text is clear ASCII 7-bit data.
+
+ The general "memo" framework of RFC-822 is used. A message
con-
+ sists of a block of information in a rigid format, followed
by gen-
+ eral text with no specified format. The rigidly formatted
first
+ part of a message is called the header, and the free-format
portion
+ is called the body. The header must always exist, but the
body is
+ optional. These parts are separated by an empty line,
i.e., two
+ consecutive newline characters. Within _M_H, the header
and body may
+ be separated by a line consisting of dashes:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ The header is composed of one or more header items. Each
header
+ item can be viewed as a single logical line of ASCII
characters.
+ If the text of a header item extends across several real
lines, the
+ continuation lines are indicated by leading spaces or tabs.
+
+ Each header item is called a component and is composed of a
keyword
+ or name, along with associated text. The keyword begins
at the
+ left margin, may NOT contain spaces or tabs, may not
exceed 63
+ characters (as specified by RFC-822), and is terminated by a
colon
+ (`:'). Certain components (as identified by their keywords)
must
+ follow rigidly defined formats in their text portions.
+
+ The text for most formatted components (e.g., "Date:"
and
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -144-
MH-MAIL(5)
+
+
+ "Message-Id:") is produced automatically. The only ones
entered by
+ the user are address fields such as "To:", "cc:", etc.
Internet
+ addresses are assigned mailbox names and host computer
specifica-
+ tions. The rough format is "address@hidden", such as
"address@hidden", or
+ "address@hidden". Multiple addresses are separated by
commas. A
+ missing host/domain is assumed to be the local host/domain.
+
+ As mentioned above, a blank line (or a line of dashes)
signals that
+ all following text up to the end of the file is the body.
No for-
+ matting is expected or enforced within the body.
+
+ Following is a list of header components that are considered
mean-
+ ingful to various MH programs.
+ Date:
+ Added by _p_o_s_t (8), contains date and time of
the message's
+ entry into the transport system.
+
+ From:
+ Added by _p_o_s_t (8), contains the address of
the author or
+ authors (may be more than one if a "Sender:"
field is
+ present). Replies are typically directed to addresses
in the
+ "Reply-To:" or "From:" field (the former has
precedence if
+ present).
+
+ Sender:
+ Added by _p_o_s_t (8) in the event that the message
already has a
+ "From:" line. This line contains the address of the
actual
+ sender. Replies are never sent to addresses in the
"Sender:"
+ field.
+
+ To:
+ Contains addresses of primary recipients.
+
+ cc:
+ Contains addresses of secondary recipients.
+
+ Bcc:
+ Still more recipients. However, the "Bcc:" line is not
copied
+ onto the message as delivered, so these recipients
are not
+ listed. _M_H uses an encapsulation method for blind
copies, see
+ _s_e_n_d (1).
+
+ Fcc:
+ Causes _p_o_s_t (8) to copy the message into the
specified folder
+ for the sender, if the message was successfully given
to the
+ transport system.
+
+ Message-ID:
+ A unique message identifier added by _p_o_s_t (8) if
the `-msgid'
+ flag is set.
+
+ Subject:
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -145-
MH-MAIL(5)
+
+
+ Sender's commentary. It is displayed by _s_c_a_n
(1).
+
+ In-Reply-To:
+ A commentary line added by _r_e_p_l (1) when
replying to a mes-
+ sage.
+
+ Resent-Date:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-From:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-To:
+ New recipients for a message resent by _d_i_s_t (1).
+
+ Resent-cc:
+ Still more recipients. See "cc:" and "Resent-To:".
+
+ Resent-Bcc:
+ Even more recipients. See "Bcc:" and "Resent-To:".
+
+ Resent-Fcc:
+ Copy resent message into a folder. See "Fcc:"
and
+ "Resent-To:".
+
+ Resent-Message-Id:
+ A unique identifier glued on by _p_o_s_t (8) if the
`-msgid' flag
+ is set. See "Message-Id:" and "Resent-To:".
+
+ Resent:
+ Annotation for _d_i_s_t (1) under the `-annotate'
option.
+
+ Forwarded:
+ Annotation for _f_o_r_w (1) under the `-annotate'
option.
+
+ Replied:
+ Annotation for _r_e_p_l (1) under the `-annotate'
option.
+
+
+ _F_i_l_e_s
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -146-
MH-MAIL(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -147-
MH-PROFILE(5)
+
+
+ _N_A_M_E
+ mh-profile - user profile customization for MH message handler
+
+ _S_Y_N_O_P_S_I_S
+ ._m_h__p_r_o_f_i_l_e
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Each user of _M_H is expected to have a file named
._m_h__p_r_o_f_i_l_e in his
+ or her home directory. This file contains a set of user
parameters
+ used by some or all of the _M_H family of programs. Each
line of the
+ file is of the format
+
+ _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t:
_v_a_l_u_e
+
+ The possible profile components are exemplified below.
Only
+ `Path:' is mandatory. The others are optional; some have
default
+ values if they are not present. In the notation used below,
(pro-
+ file, default) indicates whether the information is kept
in the
+ user's _M_H profile or _M_H context, and indicates what
the default
+ value is.
+
+ Path: Mail
+ Locates _M_H transactions in directory "Mail".
(profile,
+ no default)
+
+ context: context
+ Declares the location of the _M_H context file,
see the
+ HISTORY section below. (profile,
default:
+ <mh-dir>/context)
+
+ Current-Folder: inbox
+ Keeps track of the current open folder.
(context,
+ default: folder specified by "Inbox")
+
+ Inbox: inbox
+ Defines the name of your inbox. (profile,
default:
+ inbox)
+
+ Previous-Sequence: pseq
+ Names the sequences which should be defined as the
`msgs'
+ or `msg' argument given to the program. If not
present,
+ or empty, no sequences are defined. Otherwise, for
each
+ name given, the sequence is first zero'd and
then each
+ message is added to the sequence. (profile, no
default)
+
+ Sequence-Negation: not
+ Defines the string which, when prefixed to a
sequence
+ name, negates that sequence. Hence, "notseen"
means all
+ those messages that are not a member of the
sequence
+ "seen". (profile, no default)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -148-
MH-PROFILE(5)
+
+
+ Unseen-Sequence: unseen
+ Names the sequences which should be defined as
those mes-
+ sages recently incorporated by _i_n_c.
_S_h_o_w knows to remove
+ messages from this sequence once it thinks they
have been
+ seen. If not present, or empty, no
sequences are
+ defined. Otherwise, each message is added to
each
+ sequence name given. (profile, no default)
+
+ mh-sequences: .mh_sequences
+ The name of the file in each folder which defines
public
+ sequences. To disable the use of public sequences,
leave
+ the value portion of this entry blank.
(profile,
+ default: .mh_sequences)
+
+ atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+ Keeps track of the private sequence called
_s_e_q in the
+ specified folder. (context, no default)
+
+ Editor: /usr/ucb/ex
+ Defines editor to be used by _c_o_m_p
(1), _d_i_s_t (1),
+ _f_o_r_w (1), and _r_e_p_l (1). (profile,
default: prompter)
+
+ Msg-Protect: 644
+ Defines octal protection bits for message files.
See
+ _c_h_m_o_d (1) for an explanation of the
octal number. (pro-
+ file, default: 0644)
+
+ Folder-Protect: 711
+ Defines protection bits for folder directories.
(pro-
+ file, default: 0711)
+
+ _p_r_o_g_r_a_m: default switches
+ Sets default switches to be used whenever the mh
program
+ _p_r_o_g_r_a_m is invoked. For example,
one could override the
+ _E_d_i_t_o_r: profile component when replying
to messages by
+ adding a component such as:
+ repl: -editor /bin/ed
+ (profile, no defaults)
+
+ _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+ Names "nexteditor" to be the default editor after
using
+ "lasteditor". This takes effect at "What now?"
level in
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l. After editing the draft with
+ "lasteditor", the default editor is set to be
"nextedi-
+ tor". If the user types "edit" without any
arguments to
+ "What now?", then "nexteditor" is used.
(profile, no
+ default)
+
+ bboards: system
+ Tells _b_b_c which BBoards you are interested
in. (profile,
+ default: system)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -149-
MH-PROFILE(5)
+
+
+ Folder-Stack: _f_o_l_d_e_r_s
+ The contents of the folder-stack for the
_f_o_l_d_e_r command.
+ (context, no default)
+
+ mhe:
+ If present, tells _i_n_c to compose an
_M_H_E auditfile in
+ addition to its other tasks. _M_H_E is Brian
Reid's _E_m_a_c_s
+ front-end for _M_H. An early version is supplied
with the
+ _m_h._6 distribution. (profile, no default)
+
+ Alternate-Mailboxes: address@hidden, bug-mh*
+ Tells _r_e_p_l and _s_c_a_n which addresses
are really yours. In
+ this way, _r_e_p_l knows which addresses
should be included
+ in the reply, and _s_c_a_n knows if the message
really ori-
+ ginated from you. Addresses must be
separated by a
+ comma, and the hostnames listed should be the
"official"
+ hostnames for the mailboxes you indicate, as local
nick-
+ names for hosts are not replaced with their
official site
+ names. For each address, if a host is not
given, then
+ that address on any host is considered to be
you. In
+ addition, an asterisk (`*') may appear at either
or both
+ ends of the mailbox and host to indicate wild-card
match-
+ ing. (profile, default: your user-id)
+
+ Aliasfile: aliases other-alias
+ Indicates aliases files for _a_l_i,
_w_h_o_m, and _s_e_n_d. This
+ may be used instead of the `-alias file' switch.
(pro-
+ file, no default)
+
+ Draft-Folder: drafts
+ Indicates a default draft folder for _c_o_m_p,
_d_i_s_t, _f_o_r_w,
+ and _r_e_p_l. (profile, no default)
+
+ digest-issue-_l_i_s_t: 1
+ Tells _f_o_r_w the last issue of the last
volume sent for the
+ digest _l_i_s_t. (context, no default)
+
+ digest-volume-_l_i_s_t: 1
+ Tells _f_o_r_w the last volume sent for the
digest _l_i_s_t.
+ (context, no default)
+
+ MailDrop: .mail
+ Tells _i_n_c your maildrop, if different from
the default.
+ This is superceded by the MAILDROP envariable.
(profile,
+ default: /usr/spool/mail/$USER)
+
+ Signature: RAND MH System (agent: Marshall Rose)
+ Tells _s_e_n_d your mail signature. This is
superceded by
+ the SIGNATURE envariable. On hosts where _M_H
was config-
+ ured with the UCI option, if SIGNATURE is not
set and
+ this profile entry is not present, the
file
+ $HOME/.signature is consulted. Your signature
will be
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -150-
MH-PROFILE(5)
+
+
+ added to the address _s_e_n_d puts in the
"From:" header; do
+ not include an address in the signature text.
(profile,
+ no default)
+
+ The following profile elements are used whenever an
_M_H program
+ invokes some other program such as _m_o_r_e (1). The
._m_h__p_r_o_f_i_l_e can
+ be used to select alternate programs if the user wishes.
The
+ default values are given in the examples.
+
+ fileproc: /usr/bs/mh-6.8/bin/refile
+ incproc: /usr/bs/mh-6.8/bin/inc
+ installproc: /usr/bs/mh-6.8/lib/install-mh
+ lproc: /usr/ucb/more
+ mailproc: /usr/bs/mh-6.8/bin/mhmail
+ mhlproc: /usr/bs/mh-6.8/lib/mhl
+ moreproc: /usr/ucb/more
+ mshproc: /usr/bs/mh-6.8/bin/msh
+ packproc: /usr/bs/mh-6.8/bin/packf
+ postproc: /usr/bs/mh-6.8/lib/post
+ rmmproc: none
+ rmfproc: /usr/bs/mh-6.8/bin/rmf
+ sendproc: /usr/bs/mh-6.8/bin/send
+ showproc: /usr/ucb/more
+ whatnowproc: /usr/bs/mh-6.8/bin/whatnow
+ whomproc: /usr/bs/mh-6.8/bin/whom
+
+ If you define the envariable MH, you can specify a profile
other
+ than ._m_h__p_r_o_f_i_l_e to be read by the _M_H
programs that you invoke. If
+ the value of MH is not absolute, (i.e., does not begin with a
/ ),
+ it will be presumed to start from the current working
directory.
+ This is one of the very few exceptions in _M_H where
non-absolute
+ pathnames are not considered relative to the user's _M_H
directory.
+
+ Similarly, if you define the envariable MHCONTEXT, you can
specify
+ a context other than the normal context file (as specified
in the
+ _M_H profile). As always, unless the value of MHCONTEXT is
absolute,
+ it will be presumed to start from your _M_H directory.
+
+ _M_H programs also support other envariables:
+
+ MAILDROP : tells _i_n_c the default maildrop
+ This supercedes the "MailDrop:" profile entry.
+
+ SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail
signature
+ This supercedes the "Signature:" profile entry.
+
+ HOME : tells all _M_H programs your home directory
+
+ SHELL : tells _b_b_l the default shell to run
+
+ TERM : tells _M_H your terminal type
+ The TERMCAP envariable is also consulted. In
particular,
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -151-
MH-PROFILE(5)
+
+
+ these tell _s_c_a_n and _m_h_l how to clear
your terminal, and how
+ many columns wide your terminal is. They also tell
_m_h_l how
+ many lines long your terminal screen is.
+
+ editalt : the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit
sessions so you can
+ peruse the message being distributed or replied to.
The mes-
+ sage is also available through a link called "@"
in the
+ current directory if your current working directory
and the
+ folder the message lives in are on the same UNIX
filesystem.
+
+ mhdraft : the path to the working draft
+ This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l to tell the _w_h_a_t_-
+ _n_o_w_p_r_o_c which file to ask "What now?"
questions about. In
+ addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l
set mhfolder if appropriate.
+ Further, _d_i_s_t and _r_e_p_l set mhaltmsg
to tell the _w_h_a_t_n_o_w_p_r_o_c
+ about an alternate message associated with the draft
(the mes-
+ sage being distributed or replied to), and _d_i_s_t
sets mhdist to
+ tell the _w_h_a_t_n_o_w_p_r_o_c that message
re-distribution is occur-
+ ring. Also, mheditor is set to tell the
_w_h_a_t_n_o_w_p_r_o_c the
+ user's choice of editor (unless overridden by
`-noedit').
+ Similarly, mhuse may be set by _c_o_m_p. Finally,
mhmessages is
+ set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if
annotations are to occur (along
+ with mhannotate, and mhinplace). It's amazing all the
infor-
+ mation that has to get passed via envariables to
make the
+ "What now?" interface look squeaky clean to the _M_H
user, isn't
+ it? The reason for all this is that the _M_H user
can select
+ _a_n_y program as the
_w_h_a_t_n_o_w_p_r_o_c, including one of the standard
+ shells. As a result, it's not possible to pass
information
+ via an argument list.
+ If the WHATNOW option was set during _M_H
configuration (type
+ `-help' to an _M_H command to find out), and if this
envariable
+ is set, if the commands _r_e_f_i_l_e,
_s_e_n_d, _s_h_o_w, or _w_h_o_m are not
+ given any `msgs' arguments, then they will default to
using
+ the file indicated by mhdraft. This is useful for
getting the
+ default behavior supplied by the default
_w_h_a_t_n_o_w_p_r_o_c.
+
+ mhfolder : the folder containing the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit
sessions so you can
+ peruse other messages in the current folder besides
the one
+ being distributed or replied to. The mhfolder
envariable is
+ also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t
for use by _m_h_l.
+
+ MHBBRC :
+ If you define the envariable MHBBRC, you can specify a
BBoards
+ information file other than ._b_b_r_c to be read
by _b_b_c. If the
+ value of MHBBRC is not absolute, (i.e., does not begin
with a
+ / ), it will be presumed to start from the current
working
+ directory.
+
+ MHFD :
+ If the OVERHEAD option was set during _M_H
configuration (type
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -152-
MH-PROFILE(5)
+
+
+ `-help' to an _M_H command to find out), then if this
envariable
+ is set, _M_H considers it to be the number of a file
descriptor
+ which is opened, read-only to the _M_H profile.
Similarly, if
+ the envariable MHCONTEXTFD is set, this is the number
of a
+ file descriptor which is opened read-only to the
_M_H context.
+ This feature of _M_H is experimental, and is used
to examine
+ possible speed improvements for _M_H startup. Note
that these
+ envariables must be set and non-empty to enable this
feature.
+ However, if OVERHEAD is enabled during _M_H
configuration, then
+ when _M_H programs call other _M_H programs, this
scheme is used.
+ These file descriptors are not closed throughout the
execution
+ of the _M_H program, so children may take advantage
of this.
+ This approach is thought to be completely safe and does
result
+ in some performance enhancements.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ or $MH Rather than the standard
profile
+ <mh-dir>/context The user context
+ or $CONTEXT Rather than the standard
context
+ <folder>/.mh_sequences Public sequences for
<folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ All
+
+
+ _S_e_e _A_l_s_o
+ mh(1), environ(5), mh-sequence(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -153-
MH-PROFILE(5)
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the current-message value of
a writable
+ folder was kept in a file called "cur" in the folder
itself. In
+ _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the
current-message values for all
+ folders, regardless of their writability.
+
+ In all versions of _M_H since _m_h._4, the
._m_h__p_r_o_f_i_l_e contains only
+ static information, which _M_H programs will NOT update.
Changes in
+ context are made to the _c_o_n_t_e_x_t file kept in
the users MH _d_i_r_e_c_t_o-
+ _r_y. This includes, but is not limited to: the
"Current-Folder" en-
+ try and all private sequence information. Public sequence
informa-
+ tion is kept in a file called
._m_h__s_e_q_u_e_n_c_e_s in each folder.
+
+ To convert from the format used in releases of _M_H prior
to the for-
+ mat used in the _m_h._4 release,
_i_n_s_t_a_l_l-_m_h should be invoked with the
+ `-compat' switch. This generally happens automatically on
_M_H sys-
+ tems generated with the "COMPAT" option during _M_H
configuration.
+
+ The ._m_h__p_r_o_f_i_l_e may override the path of
the _c_o_n_t_e_x_t file, by
+ specifying a "context" entry (this must be in lower-case).
If the
+ entry is not absolute (does not start with a / ), then it is
inter-
+ preted relative to the user's _M_H directory. As a
result, you can
+ actually have more than one set of private sequences by using
dif-
+ ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -154-
MH-PROFILE(5)
+
+
+ _B_u_g_s
+ The shell quoting conventions are not available in the
.mh_profile.
+ Each token is separated by whitespace.
+
+ There is some question as to what kind of arguments
should be
+ placed in the profile as options. In order to provide a
clear
+ answer, recall command line semantics of all _M_H programs:
conflict-
+ ing switches (e.g., `-header and `-noheader') may occur
more than
+ one time on the command line, with the last switch taking
effect.
+ Other arguments, such as message sequences, filenames and
folders,
+ are always remembered on the invocation line and are not
superseded
+ by following arguments of the same type. Hence, it is
safe to
+ place only switches (and their arguments) in the profile.
+
+ If one finds that an _M_H program is being invoked again
and again
+ with the same arguments, and those arguments aren't
switches, then
+ there are a few possible solutions to this problem. The
first is
+ to create a (soft) link in your $_H_O_M_E/_b_i_n
directory to the _M_H pro-
+ gram of your choice. By giving this link a different name,
you can
+ create a new entry in your profile and use an alternate set
of de-
+ faults for the _M_H command. Similarly, you could create
a small
+ shell script which called the _M_H program of your choice
with an al-
+ ternate set of invocation line switches (using links and an
alter-
+ nate profile entry is preferable to this solution).
+
+ Finally, the _c_s_h user could create an alias for the
command of the
+ form:
+
+ alias cmd 'cmd arg1 arg2 ...'
+
+ In this way, the user can avoid lengthy type-in to the
shell, and
+ still give _M_H commands safely. (Recall that some
_M_H commands in-
+ voke others, and that in all cases, the profile is read,
meaning
+ that aliases are disregarded beyond an initial command
invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -155-
MH-SEQUENCE(5)
+
+
+ _N_A_M_E
+ mh-sequence - sequence specification for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ most _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Most _M_H commands accept a `msg' or `msgs'
specification, where
+ `msg' indicates one message and `msgs' indicates one or
more mes-
+ sages. To designate a message, you may use either its
number
+ (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+ _N_a_m_e _D_e_s_c_r_i_p_t_i_o_n
+ first the first message in the folder
+ last the last message in the folder
+ cur the most recently accessed message
+ prev the message numerically preceding "cur"
+ next the message numerically following "cur"
+
+ In commands that take a `msg' argument, the default is "cur".
As a
+ shorthand, "." is equivalent to "cur".
+
+ For example: In a folder containing five messages numbered
5, 10,
+ 94, 177 and 325, "first" is 5 and "last" is 325. If "cur"
is 94,
+ then "prev" is 10 and "next" is 177.
+
+ The word `msgs' indicates that one or more messages may be
speci-
+ fied. Such a specification consists of one message
designation or
+ of several message designations separated by spaces. A
message
+ designation consists either of a message name as defined
above, or
+ a message range.
+
+ A message range is specified as "name1-name2" or "name:n",
where
+ `name', `name1' and `name2' are message names, and `n'
is an
+ integer.
+
+ The specification "name1-name2" designates all
currently-existing
+ messages from `name1' to `name2' inclusive. The message name
"all"
+ is a shorthand for the message range "first-last".
+
+ The specification "name:n" designates up to `n' messages.
These
+ messages start with `name' if `name' is a message number or
one of
+ the reserved names "first" "cur", or "next", The messages end
with
+ `name' if `name' is "prev" or "last". The interpretation
of `n'
+ may be overridden by preceding `n' with a plus or minus sign;
`+n'
+ always means up to `n' messages starting with `name',
and `-n'
+ always means up to `n' messages ending with `name'.
+
+ In commands which accept a `msgs' argument, the default is
either
+ "cur" or "all", depending on which makes more sense for
each com-
+ mand (see the individual man pages for details).
Repeated
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -156-
MH-SEQUENCE(5)
+
+
+ specifications of the same message have the same effect as a
single
+ specification of the message.
+
+
+ _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e
_S_e_q_u_e_n_c_e_s
+
+ In addition to the "reserved" (pre-defined) message names
given
+ above, _M_H supports user-defined sequence names.
User-defined
+ sequences allow the _M_H user a tremendous amount of power
in dealing
+ with groups of messages in the same folder by allowing the
user to
+ bind a group of messages to a meaningful symbolic name.
+
+ The name used to denote a message sequence must consist
of an
+ alphabetic character followed by zero or more alphanumeric
charac-
+ ters, and can not be one of the "reserved" message names
above.
+ After defining a sequence, it can be used wherever an
_M_H command
+ expects a `msg' or `msgs' argument.
+
+ Some forms of message ranges are allowed with
user-defined
+ sequences. The specification "name:n" may be used, and it
desig-
+ nates up to the first `n' messages (or last `n' messages for
`-n')
+ which are elements of the user-defined sequence `name'.
+
+ The specifications "name:next" and "name:prev" may also be
used,
+ and they designate the next or previous message (relative
to the
+ current message) which is an element of the user-defined
sequence
+ `name'. The specificaitions "name:first" and
"name:last" are
+ equivalent to "name:1" and "name:-1", respectively. The
specifica-
+ tion "name:cur" is not allowed (use just "cur" instead).
The syn-
+ tax of these message range specifcations is subject to
change in
+ the future.
+
+ User-defined sequence names are specific to each folder.
They are
+ defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two varieties of sequences: _p_u_b_l_i_c
sequences and _p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are
accessible to any _M_H
+ user that can read that folder and are kept in the
.mh_sequences
+ file in the folder. _P_r_i_v_a_t_e sequences are
accessible only to the
+ _M_H user that defined those sequences and are kept in the
user's _M_H
+ context file. By default, _p_i_c_k and _m_a_r_k
create _p_u_b_l_i_c sequences if
+ the folder for which the sequences are being defined is
writable by
+ the _M_H user. Otherwise, _p_r_i_v_a_t_e
sequences are created. This can
+ be overridden with the `-public' and `-private' switches to
_m_a_r_k.
+
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ _M_H provides the ability to select all messages not
elements of a
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -157-
MH-SEQUENCE(5)
+
+
+ user-defined sequence. To do this, the user should
define the
+ entry "Sequence-Negation" in the _M_H profile file; its
value may be
+ any string. This string is then used to preface an existing
user-
+ defined sequence name. This specification then refers to
those
+ messages not elements of the specified sequence name. For
example,
+ if the profile entry is:
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command is given "notfoo" as a `msg'
or `msgs'
+ argument, it would substitute all messages that are not
elements of
+ the sequence "foo".
+
+ Obviously, the user should beware of defining sequences with
names
+ that begin with the value of the "Sequence-Negation" profile
entry.
+
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ _M_H provides the ability to remember the `msgs' or `msg'
argument
+ last given to an _M_H command. The entry
"Previous-Sequence" should
+ be defined in the _M_H profile; its value should be a
sequence name
+ or multiple sequence names separated by spaces. If this
entry is
+ defined, when when an _M_H command finishes, it will
define the
+ sequence(s) named in the value of this entry to be those
messages
+ that were specified to the command. Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs'
argument to
+ define the sequence "pseq" as those messages when it finishes.
+
+ Note: there can be a performance penalty in using
the
+ "Previous-Sequence" facility. If it is used, all _M_H
programs have
+ to write the sequence information to the .mh_sequences file
for the
+ folder each time they run. If the "Previous-Sequence"
profile
+ entry is not included, only _p_i_c_k and _m_a_r_k
will write to the
+ .mh_sequences file.
+
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to indicate messages which have not
been
+ previously seen by them. Both _i_n_c and _s_h_o_w
honor the profile entry
+ "Unseen-Sequence" to support this activity. This entry
in the
+ .mh_profile should be defined as one or more sequence
names
+ separated by spaces. If there is a value for
"Unseen-Sequence" in
+ the profile, then whenever _i_n_c places new messages in a
folder, the
+ new messages will also be added to the sequence(s) named
in the
+ value of this entry. Hence, a profile entry of
+
+ Unseen-Sequence: unseen
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -158-
MH-SEQUENCE(5)
+
+
+ directs _i_n_c to add new messages to the sequence
"unseen". Unlike
+ the behavior of the "Previous-Sequence" entry in the
profile, how-
+ ever, the sequence(s) will not be zeroed by _i_n_c.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or
_p_r_e_v) displays a message, that
+ message will be removed from any sequences named
by the
+ "Unseen-Sequence" entry in the profile.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/context The user context
+ <folder>/.mh_sequences Public sequences for
<folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Sequence-Negation: To designate messages not in a sequence
+ Previous-Sequence: The last message specification given
+ Unseen-Sequence: Those messages not yet seen by the user
+
+
+ _S_e_e _A_l_s_o
+ mh(1), mark(1), pick(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+ _B_u_g_s
+ User-defined sequences are stored in the .mh_sequences file
as a
+ series of message specifications separated by spaces. If a
user-
+ defined sequence contains too many individual message
specifica-
+ tions, that line in the file may become too long for _M_H
to handle.
+ This will generate the error message ".mh_sequences is poorly
for-
+ matted". You'll have to edit the file by hand to remove
the of-
+ fending line.
+
+ This can happen to users who define the "Previous-Sequence"
entry
+ in the _M_H profile and have a folder containing many
messages with
+ gaps in the numbering. A workaround for large folders is to
minim-
+ ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ AP(8) -159-
AP(8)
+
+
+ _N_A_M_E
+ ap - parse addresses 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_p is a program that parses addresses according to the
ARPA Inter-
+ net standard. It also understands many non-standard
formats. It
+ is useful for seeing how _M_H will interpret an address.
+
+ The _a_p program treats each argument as one or more
addresses, and
+ prints those addresses out in the official 822-format.
Hence, it
+ is usually best to enclose each argument in double-quotes
for the
+ shell.
+
+ To override the output format used by _a_p, the `-format
string' or
+ `-format file' switches are used. This permits individual
fields
+ of the address to be extracted with ease. The string is
simply a
+ format stringand thefile is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard escapes, _a_p also recognizes
the follow-
+ ing additional escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ error string A diagnostic if the parse failed
+
+ If the `-normalize' switch is given, _a_p will try to track
down the
+ official hostname of the address.
+
+ Here is the default format string used by _a_p:
+
+ %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+ which says that if an error was detected, print the error, a
`:',
+ and the address in error. Otherwise, output the 822-proper
format
+ of the address.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ AP(8) -160-
AP(8)
+
+
+ _S_e_e _A_l_s_o
+ dp(8),
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' defaults as described above
+ `-normalize'
+ `-width' defaults to the width of the terminal
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _a_p. Therefore, one
must usual-
+ ly place the argument to this switch inside double-quotes.
+
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -161-
CONFLICT(8)
+
+
+ _N_A_M_E
+ conflict - search for alias/password conflicts
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/conflict [-mail name] [-search directory]
+ [aliasfiles...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_n_f_l_i_c_t is a program that checks to see if
the interface between
+ _M_H and transport system is in good shape
+
+ _C_o_n_f_l_i_c_t also checks for maildrops in
/usr/spool/mail which do not
+ belong to a valid user. It assumes that no user name will
start
+ with `.', and thus ignores files in /usr/spool/mail which
begin
+ with `.'. It also checks for entries in the
_g_r_o_u_p (5) file which
+ do not belong to a valid user, and for users who do not
have a
+ valid group number. In addition duplicate users and
groups are
+ noted.
+
+ If the `-mail name' switch is used, then the results will be
sent
+ to the specified _n_a_m_e. Otherwise, the results
are sent to the
+ standard output.
+
+ The `-search directory' switch can be used to search
directories
+ other than /usr/spool/mail and to report anomalies in those
direc-
+ tories. The `-search directory' switch can appear more
than one
+ time in an invocation to _c_o_n_f_l_i_c_t.
+
+ _C_o_n_f_l_i_c_t should be run under _c_r_o_n
(8), or whenever system account-
+ ing takes place.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+ /etc/passwd List of users
+ /etc/group List of groups
+ /usr/bs/mh-6.8/bin/mhmail Program to send mail
+ /usr/spool/mail/ Directory of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `aliasfiles' defaults to /usr/bs/mh-6.8/lib/MailAliases
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -162-
CONFLICT(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DP(8) -163-
DP(8)
+
+
+ _N_A_M_E
+ dp - parse dates 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_p is a program that parses dates according to the ARPA
Internet
+ standard. It also understands many non-standard formats,
such as
+ those produced by TOPS-20 sites and some UNIX sites
using
+ _c_t_i_m_e (3). It is useful for seeing how _M_H will
interpret a date.
+
+ The _d_p program treats each argument as a single date,
and prints
+ the date out in the official 822-format. Hence, it is
usually best
+ to enclose each argument in double-quotes for the shell.
+
+ To override the output format used by _d_p, the `-format
string' or
+ `-format file' switches are used. This permits individual
fields
+ of the address to be extracted with ease. The string is
simply a
+ format stringand thefile is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ Here is the default format string used by _d_p:
+
+ %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+ which says that if an error was detected, print the error, a
`:',
+ and the date in error. Otherwise, output the 822-proper
format of
+ the date.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ ap(8)
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' default as described above
+ `-width' default to the width of the terminal
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DP(8) -164-
DP(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _d_p. Therefore, one
must usual-
+ ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FMTDUMP(8) -165-
FMTDUMP(8)
+
+
+ _N_A_M_E
+ fmtdump - decode MH format files
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/fmtdump [-form formatfile] [-format string]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _F_m_t_d_u_m_p is a program that parses an _M_H
format file and produces a
+ pseudo-language listing of the how _M_H interprets the file.
+
+ The `-format string' and `-form formatfile' switches may be
used to
+ specify a format string or format file to read. The string
is sim-
+ ply a format string and the file is simply a format file.
See _m_h-
+ _f_o_r_m_a_t(5) for the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/bs/mh-6.8/lib/scan.default The default format file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+
+
+ _S_e_e _A_l_s_o
+ mh-format(5), mh-sequences(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The output may not be useful unless you are familiar
with the
+ internals of the mh-format subroutines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INSTALL-MH(8) -166-
INSTALL-MH(8)
+
+
+ _N_A_M_E
+ install-mh - initialize the MH environment
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/install-mh [-auto] [-compat]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ When a user runs any _M_H program for the first time,
the program
+ will invoke _i_n_s_t_a_l_l-_m_h (with the `-auto'
switch) to query the user
+ for the initial _M_H environment. The user does NOT invoke
this pro-
+ gram directly. The user is asked for the name of the
directory
+ that will be designated as the user's _M_H directory. If
this direc-
+ tory does not exist, the user is asked if it should be
created.
+ Normally, this directory should be under the user's home
directory,
+ and has the default name of Mail/. After
_i_n_s_t_a_l_l-_m_h has written
+ the initial .mh_profile for the user, control returns to the
origi-
+ nal _M_H program.
+
+ As with all _M_H commands, _i_n_s_t_a_l_l-_m_h
first consults the $HOME
+ envariable to determine the user's home directory. If $HOME
is not
+ set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+ When converting from _m_h._3 to _m_h._4,
_i_n_s_t_a_l_l-_m_h is automatically
+ invoked with the `-compat' switch.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To set the user's MH directory
+
+
+ _C_o_n_t_e_x_t
+ With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POST(8) -167-
POST(8)
+
+
+ _N_A_M_E
+ post - deliver a message
+
+ _S_Y_N_O_P_S_I_S
+ /usr/bs/mh-6.8/lib/post [-alias aliasfile] [-filter
filterfile]
+ [-nofilter] [-format] [-noformat] [-mime] [-nomime]
[-msgid]
+ [-nomsgid] [-verbose] [-noverbose] [-watch] [-nowatch]
+ [-width columns] file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_o_s_t is the program called by _s_e_n_d (1) to
deliver the message in
+ _f_i_l_e to local and remote users. In fact, all of
the functions
+ attributed to _s_e_n_d on its manual page are performed
by _p_o_s_t, with
+ _s_e_n_d acting as a relatively simple preprocessor.
Thus, it is _p_o_s_t
+ which parses the various header fields, appends From: and
Date:
+ lines, and interacts with the _M_M_D_F transport system.
_P_o_s_t will not
+ normally be called directly by the user.
+
+ _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:", and
"Resent-xxx:"
+ header lines of the specified message for destination
addresses,
+ checks these addresses for validity, and formats them so as
to con-
+ form to ARPAnet Internet Message Format protocol,
unless the
+ `-noformat' flag is set. This will normally cause
"@_l_o_c_a_l-_s_i_t_e" to
+ be appended to each local destination address, as well as any
local
+ return addresses. The `-width columns' switch can be used to
indi-
+ cate the preferred length of the header components that
contain
+ addresses.
+
+ If a "Bcc:" field is encountered, its addresses will be
used for
+ delivery, and the "Bcc:" field will be removed from the
message
+ sent to sighted recipients. The blind recipients will
receive an
+ entirely new message with a minimal set of headers.
Included in
+ the body of the message will be a copy of the message sent
to the
+ sighted recipients. If `-filter filterfile' is
specified, then
+ this copy is filtered (re-formatted) prior to being sent
to the
+ blind recipients. Otherwise, to use the MIME rules for
encapsula-
+ tion, specify the `-mime' switch.
+
+ The `-alias aliasfile' switch can be used to specify a file
that
+ post should take aliases from. More than one file can be
speci-
+ fied, each being preceded with `-alias'. In any event, the
primary
+ alias file is read first.
+
+ The `-msgid' switch indicates that a
"Message-ID:" or
+ "Resent-Message-ID:" field should be added to the header.
+
+ The `-verbose' switch indicates that the user should be
informed of
+ each step of the posting/filing process.
+
+ The `-watch' switch indicates that the user would like to
watch the
+ transport system's handling of the message (e.g., local and
"fast"
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POST(8) -168-
POST(8)
+
+
+ delivery).
+
+ _P_o_s_t consults the envariable $SIGNATURE to determine
the sender's
+ personal name in constructing the "From:" line of the message.
+
+ _F_i_l_e_s
+ /usr/bs/mh-6.8/lib/mtstailor tailor file
+ /usr/bs/mh-6.8/bin/refile Program to process Fcc:s
+ /usr/bs/mh-6.8/lib/mhl Program to process Bcc:s
+ /usr/bs/mh-6.8/lib/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ _p_o_s_t does NOT consult the user's .mh_profile
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822),
+ mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/bs/mh-6.8/lib/MailAliases'
+ `-format'
+ `-nomime'
+ `-nomsgid'
+ `-noverbose'
+ `-nowatch'
+ `-width 72'
+ `-nofilter'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ "Reply-To:" fields are allowed to have groups in them
according to
+ the 822 specification, but _p_o_s_t won't let you use
them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _5. _R_E_P_O_R_T_I_N_G
_P_R_O_B_L_E_M_S
+
+
+
+
+
+ If problems are encountered with an _M_H program, the
problems should
+ be reported to the local maintainers of _M_H. When doing
this, the name
+ of the program should be reported, along with the version
information
+ for the program. To find out what version of an _M_H
program is being
+ run, invoke the program with the `-help' switch. In addition
to listing
+ the syntax of the command, the program will list information
pertaining
+ to its version. This information includes the version of
_M_H, the host
+ it was generated on, and the date the program was loaded. A
second line
+ of information, found on versions of _M_H after #5.380
include _M_H confi-
+ guration options. For example,
+
+ version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov 6
01:13:53 PST
+ 1985
+ options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII]
[SMTP] [POP]
+
+ The `6.1 #1[UCI]' indicates that the program is from the UCI
_m_h._6 ver-
+ sion of _M_H. The program was generated on the host
`nrtc-gremlin' on
+ `Wed Nov 6 01:13:53 PST 1985'. It's usually a good idea to
send the
+ output of the `-help' switch along with your report.
+
+ If there is no local _M_H maintainer, try the address
Bug-MH. If that
+ fails, use the Internet mailbox address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -169-
+
+
+
+
+
+
+
+
+
+
+
+
+ _6. _A_D_V_A_N_C_E_D
_F_E_A_T_U_R_E_S
+
+
+
+
+
+ This section describes some features of _M_H that
were included
+ strictly for advanced _M_H users. These capabilities
permit _M_H to exhibit
+ more powerful behavior for the seasoned _M_H users.
+
+
+ _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+ User-defined sequences allow the _M_H user a
tremendous amount of
+ power in dealing with groups of messages in the same folder
by allowing
+ the user to bind a group of messages to a meaningful symbolic
name. The
+ user may choose any name for a message sequence, as long as
it consists
+ of alphanumeric characters and does not conflict with the
standard _M_H
+ reserved message names (e.g., "first", etc). After defining
a sequence,
+ it can be used wherever an _M_H command expects a `msg' or
`msgs' argu-
+ ment.
+
+ A restricted form of message ranges are allowed with
user-defined
+ sequences. The form "name:n", specifies up to the first
`n' messages
+ which are part of the user-defined sequence `name'. A
leading plus sign
+ is allowed on `n', but is ignored. The interpretation of n
is overrid-
+ den if n is preceded by a minus sign; `-n' always means up to
the last
+ `n' messages which are part of the sequence `name'.
+
+ Although all _M_H commands expand user-defined
sequences as appropri-
+ ate, there are two commands that allow the user to define and
manipulate
+ them: _p_i_c_k and _m_a_r_k.
+
+ _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ Most users of _M_H will use user-defined sequences
only with the _p_i_c_k
+ command. By giving the `-sequence name' switch to
_p_i_c_k (which can occur
+ more than once on the command line), each sequence named is
defined as
+ those messages which _p_i_c_k matched according the the
selection criteria
+ it was given. Hence,
+
+ pick -from frated -seq fred
+
+ finds all those messages in the current folder which were
from "frated",
+ creates a sequence called "fred", and then adds them to
the sequence.
+ The user could then invoke
+
+ scan fred
+
+ to get a _s_c_a_n listing of those messages. Note that
by default, _p_i_c_k
+ creates the named sequences before it adds the selected
messages to the
+ sequence. Hence, if the named sequence already existed, the
sequence is
+
+ -170-
+
+
+
+
+
+
+
+
+
+ -171-
+
+
+ destroyed prior to being re-defined (nothing happens to
the messages
+ that were a part of this sequence, they simply cease to be
members of
+ that sequence). By using the `-nozero' switch, this
behavior can be
+ inhibited, as in
+
+ pick -from frated -seq sgroup
+ pick -from fear -seq sgroup -nozero
+ pick -from freida -seq sgroup -nozero
+
+ finds all those messages in the current folder which were
from "frated",
+ "fear", or "freida", and defines the sequence called "sgroup"
as exactly
+ those messages. These operations amounted to an
"inclusive-or" of three
+ selection criteria, using _p_i_c_k, one can also
generate the "and" of some
+ selection criteria as well:
+
+ pick -from frated -seq fred
+ pick -before friday -seq fred fred
+
+ This example defines the sequence called "fred" as exactly
those mes-
+ sages from "frated" that were dated prior to "friday".[1]
+
+ _P_i_c_k is normally used as a back-quoted command,
for example,
+
+ scan `pick -from postmaster`
+
+ Now suppose that the user decides that another command should
be issued,
+ using exactly those messages. Since, _p_i_c_k
wasn't given a
+ `-sequence name' argument in this example, the user would
end-up typing
+ the entire back-quoted command again. A simpler way is to
add a default
+ sequence name to the .mh_profile. For example,
+
+ pick: -seq select -list
+
+ will tell _p_i_c_k to always define the sequence "select"
whenever it's run.
+ The `-list' is necessary since the `-sequence name' switch
sets `-nol-
+ ist' whenever the former is encountered. Hence, this
profile entry
+ makes _p_i_c_k define the "select" sequence and
otherwise behave exactly as
+
+
+ [1] Of course, it is much easier to simply use the
built-in boolean
+ operation of _p_i_c_k to get the desired results:
+
+ pick -from frated -or -from fear -or -from freida -seq
sgroup
+
+ and
+
+ pick -from frated -and -before friday -seq fred
+
+ do exactly the same thing as the five commands listed above.
Hence, the
+ `-nozero' option to _p_i_c_k is only useful to
manipulate existing se-
+ quences.
+
+
+
+
+
+
+
+
+
+
+
+
+ -172-
+
+
+ if there was no profile entry at all.
+
+ _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ The _m_a_r_k command lets the user perform
low-level manipulation of
+ sequences, and also provides a well-needed debug
facility to the
+ implementors/developers/maintainers of _M_H (the
_M_H-hacks). In the
+ future, a user-friendly "front-end" for _m_a_r_k will
probably be developed
+ to give the _M_H user a way to take better advantage of
the underlying
+ facilities.
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two kinds of sequences: _p_u_b_l_i_c
sequences, and _p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are
accessible to any _M_H user
+ that can read that folder and are kept in the .mh_sequences
file in the
+ folder. _P_r_i_v_a_t_e sequences are accessible
only to the _M_H user that
+ defined those sequences and are kept in the user's _M_H
context file. By
+ default, _p_i_c_k (and _m_a_r_k ) create
_p_u_b_l_i_c sequences if the folder for
+ which the sequences are being defined is writable by the
_M_H user. Oth-
+ erwise, _p_r_i_v_a_t_e sequences are created. This
can be overridden with the
+ `-public' and `-nopublic' switches.
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ In addition to telling an _M_H command to use the
messages in the
+ sequence "seen", as in
+
+ refile seen +old
+
+ it would be useful to be easily able to tell an _M_H
command to use all
+ messages _e_x_c_e_p_t those in the sequence. One way
of doing this would be
+ to use _m_a_r_k and define the sequence explicitly, as in
+
+ mark -delete -zero seen -seq notseen
+
+ which, owing to _m_a_r_k 's cryptic interpretation of
`-delete' and `-zero',
+ defines the sequence "notseen" to be all messages not in
the sequence
+ "seen". Naturally, anytime the sequence "seen" is changed,
"notseen"
+ will have to be updated. Another way to achieve this is to
define the
+ entry "Sequence-Negation:" in the .mh_profile. If the entry
was
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command was given "notseen" as a
`msg' or `msgs'
+ argument, it would substitute all messages that are not a
member of the
+ sequence "seen". That is,
+
+ refile notseen +new
+
+ does just that. The value of the "Sequence-Negation:" entry
in the pro-
+ file can be any string. Hence, experienced users of
_M_H do not use a
+
+
+
+
+
+
+
+
+
+
+
+ -173-
+
+
+ word, but rather a special character which their shell does
not inter-
+ pret (users of the _C_S_h_e_l_l use a single caret
or circumflex (usually
+ shift-6), while users of the Bourne shell use an
exclamation-mark).
+ This is because there is nothing to prevent a user of _M_H
from defining a
+ sequence with this string as its prefix, if the string is
nothing by
+ letters and digits. Obviously, this could lead to confusing
behavior if
+ the "Sequence-Negation:" entry leads _M_H to believe that
two sequences
+ are opposites by virtue of their names differing by the
prefix string.
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ Many times users find themselves issuing a series of
commands on
+ the same sequences of messages. If the user first defined
these mes-
+ sages as a sequence, then considerable typing may be saved.
If the user
+ doesn't have this foresight, _M_H provides a handy
way of having _M_H
+ remember the `msgs' or `msg' argument last given to an _M_H
command. If
+ the entry "Previous-Sequence:" is defined in the
.mh_profile, then when
+ the command finishes, it will define the sequence(s) named in
the value
+ of this entry as being exactly those messages that were
specified.
+ Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs'
argument to define
+ the sequence "pseq" as those messages when it finishes.
More than one
+ sequence name may be placed in this entry, separated with
spaces. The
+ one disadvantage of this approach is that the _M_H progams
have to update
+ the sequence information for the folder each time they run
(although
+ most programs read this information, usually only
_p_i_c_k and _m_a_r_k have to
+ write this information out).
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to distinguish between messages
which have
+ been previously seen by them. Both _i_n_c and
_s_h_o_w honorthe profile entry
+ "Unseen-Sequence" to support this activity. Whenever
_i_n_c places new
+ messages in a folder, if the entry "Unseen-Sequence" is
defined in the
+ .mh_profile, then when the command finishes, _i_n_c will
add the new mes-
+ sages to the sequence(s) named in the value of this
entry. Hence, a
+ profile entry of
+
+ Unseen-Sequence: unseen
+
+ directs _i_n_c to add new messages to the sequence
"unseen". Unlike the
+ behavior of the "Previous-Sequence" entry in the profile
however, the
+ sequence(s) will not be zero'd.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or
_p_r_e_v ) displays a message,
+ they remove those messages from any sequences
named by the
+ "Unseen-Sequence" entry in the profile.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -174-
+
+
+ _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+ There are a number of interesting advanced facilities
for the com-
+ position of outgoing mail.
+
+
+ _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+ The _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands have two switches,
+ `-draftfolder +folder' and `-draftmessage msg'.
If
+ `-draftfolder +folder' is used, these commands are directed
to construct
+ a draft message in the indicated folder. (The
"Draft-Folder:" profile
+ entry may be used to declare a default draft folder for use
with _c_o_m_p,
+ _d_i_s_t, _f_o_r_w, and _r_e_p_l) If
`-draftmessage msg' is not used, it defaults to
+ `new' (unless the user invokes _c_o_m_p with `-use',
in which case the
+ default is `cur'). Hence, the user may have several
message composi-
+ tions in progress simultaneously. Now, all of the _M_H
tools are avail-
+ able on each of the user's message drafts (e.g.,
_s_h_o_w, _s_c_a_n, _p_i_c_k, and
+ so on). If the folder does not exist, the user is asked if
it should be
+ created (just like with _r_e_f_i_l_e ). Also, the last
draft message the user
+ was composing is known as `cur' in the draft folder.
+
+ Furthermore, the _s_e_n_d command has these switches
as well. Hence,
+ from the shell, the user can send off whatever drafts
desired using the
+ standard _M_H `msgs' convention with `-draftmessage msgs'.
If no `msgs'
+ are given, it defaults to `cur'.
+
+ In addition, all five programs have a
`-nodraftfolder' switch,
+ which undoes the last occurrence of `-draftfolder folder'
(useful if the
+ latter occurs in the user's _M_H profile).
+
+ If the user does not give the `-draftfolder +folder'
switch, then
+ all these commands act ``normally''. Note that the
`-draft' switch to
+ _s_e_n_d and _s_h_o_w still refers to the file called
`draft' in the user's _M_H
+ directory. In the interests of economy of expression, when
using _c_o_m_p
+ or _s_e_n_d, the user needn't prefix the draft `msg' or
`msgs' with `-draft-
+ message'. Both of these commands accept a `file' or
`files' argument,
+ and they will, if given `-draftfolder +folder' treat these
arguments as
+ `msg' or `msgs'.[2] Hence,
+
+ send -draftf +drafts first
+
+ is the same as
+
+ send -draftf +drafts -draftm first
+
+
+
+
+ [2] This may appear to be inconsistent, at first, but it
saves a lot
+ of typing.
+
+
+
+
+
+
+
+
+
+
+
+
+ -175-
+
+
+ To make all this a bit more clear, here are some
examples. Let's
+ assume that the following entries are in the _M_H profile:
+
+ Draft-Folder: +drafts
+ sendf: -draftfolder +drafts
+
+ Furthermore, let's assume that the program _s_e_n_d_f is
a (symbolic) link in
+ the user's $HOME/bin/ directory to _s_e_n_d. Then, any
of the commands
+
+ comp
+ dist
+ forw
+ repl
+
+ constructs the message draft in the `draft' folder using the
`new' mes-
+ sage number. Furthermore, they each define `cur' in this
folder to be
+ that message draft. If the user were to use the _q_u_i_t
option at `What
+ now?' level, then later on, if no other draft composition
was done, the
+ draft could be sent with simply
+
+ sendf
+
+ Or, if more editing was required, the draft could be edited
with
+
+ comp -use
+
+ Instead, if other drafts had been composed in the meantime,
so that this
+ message draft was no longer known as `cur' in the `draft'
folder, then
+ the user could _s_c_a_n the folder to see which message
draft in the folder
+ should be used for editing or sending. Clever users could
even employ a
+ back-quoted _p_i_c_k to do the work:
+
+ comp -use `pick +drafts -to bug-mh`
+
+ or
+
+ sendf `pick +drafts -to bug-mh`
+
+ Note that in the _c_o_m_p example, the output from
_p_i_c_k must resolve to a
+ single message draft (it makes no sense to talk about
composing two or
+ more drafts with one invocation of _c_o_m_p ). In
contrast, in the _s_e_n_d
+ example, as many message drafts as desired can appear,
since _s_e_n_d
+ doesn't mind sending more than one draft at a time.
+
+ Note that the argument `-draftfolder +folder' is not
included in
+ the profile entry for _s_e_n_d, since when
_c_o_m_p, et. al., invoke _s_e_n_d
+ directly, they supply _s_e_n_d with the UNIX pathname of
the message draft,
+ and not a `draftmessage msg' argument. As far as
_s_e_n_d is concerned, a
+ _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+ It is important to realize that _M_H treats the draft
folder like a
+ standard _M_H folder in nearly all respects. There are
two exceptions:
+
+
+
+
+
+
+
+
+
+
+
+ -176-
+
+
+ first_____, under no circumstancs will the `-draftfolder
folder' switch cause
+ the named folder to become the current folder.[3]
Second______, although con-
+ ceptually _s_e_n_d deletes the `msgs' named in the draft
folder, it does not
+ call `delete-prog' to perform the deletion.
+
+
+ _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e
_D_r_a_f_t _E_x_i_s_t_s
+
+ When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands are invoked and the
+ draft you indicated already exists, these programs will
prompt the user
+ for a reponse directing the program's action. The prompt is
+
+ Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+ Disposition?
+
+ The appropriate responses and their meanings are:
replace_______: deletes the
+ draft and starts afresh; list____: lists the draft;
refile______: files the draft
+ into a folder and starts afresh; and, quit____: leaves
the draft intact and
+ exits. In addition, if you specified `-draftfolder folder'
to the com-
+ mand, then one other response will be accepted: new___:
finds a new draft,
+ just as if `-draftmessage new' had been given. Finally,
the _c_o_m_p com-
+ mand will accept one more response: use___: re-uses the
draft, just as if
+ `-use' had been given.
+
+
+ _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t
_n_o_w? _L_e_v_e_l
+
+ The _p_u_s_h option to the "What now?" query in the
_c_o_m_p, _d_i_s_t, _f_o_r_w,
+ and _r_e_p_l commands, directs the command to
_s_e_n_d the draft in a special
+ detached fashion, with all normal output discarded. If
_p_u_s_h is used and
+ the draft can not be sent, then _M_H will send the user a
message, indi-
+ cating the name of the draft file, and an explanation of the
failure.
+
+ The user can also invoke _s_e_n_d from the shell
with the `-push'
+ switch, which makes _s_e_n_d act like it had been
_p_u_s_h 'd by one of the com-
+ position commands.
+
+ By using _p_u_s_h, the user can free the shell to
do other things,
+ because it appears to the shell that the _M_H command has
finished. As a
+ result the shell will immediately prompt for another
command, despite
+ the fact that the command is really still running. Note
that if the
+ user indicates that annotations are to be performed (with
`-annotate' to
+
+
+ [3] Obviously, if the folder appeared in the context of
a standard
+ `+folder' argument to an _M_H program, as in
+
+ scan +drafts
+
+ it might become the current folder, depending on the context
changes of
+ the _M_H program in question.
+
+
+
+
+
+
+
+
+
+
+
+
+ -177-
+
+
+ _d_i_s_t, _f_o_r_w, or _r_e_p_l), the annotations
will be performed after the mes-
+ sage has been successfully sent. This action will appear to
occur asyn-
+ chronously. Obviously, if one of the messages that is to be
annotated
+ is removed before the draft has been successfully sent,
then when _M_H
+ tries to make the annotations, it won't be able to do so.
In previous
+ versions of _M_H, this resulted in an error message
mysteriously appearing
+ on the user's terminal. In _m_h._5 and later versions,
in this special
+ circumstance, no error will be generated.
+
+ If send is _p_u_s_h 'd, then the `-forward' switch
is examined if a
+ failure notice is generated. If given, then the draft is
forwarded with
+ the failure notice sent to the user. This allows rapid
_b_u_r_s_t 'ing of
+ the failure notice to retrieve the unsent draft.
+
+
+ _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w?
_L_e_v_e_l
+
+ By default, the message composition programs call a
program called
+ _w_h_a_t_n_o_w before the initial draft composition.
The _M_H user can specify
+ any program for this. Following is some information about
the default
+ "What now?" level. More detailed information can be found
in the _w_h_a_t_-
+ _n_o_w (1) manual entry.
+
+ When using the _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l commands at "What now?"
+ level, the _e_d_i_t, _l_i_s_t,
_h_e_a_d_e_r_s, _r_e_f_i_l_e, and (for the _d_i_s_t and
_r_e_p_l com-
+ mands) the _d_i_s_p_l_a_y options will pass on any
additional arguments given
+ them to whatever program they invoke.
+
+ In _m_h._1 (the original RAND _M_H ) and _m_h._2
(the first UCI version of
+ _M_H ), _M_H used a complicated heuristic to determine
if the draft should
+ be deleted or preserved after an unsuccessful edit. In
_m_h._3, _M_H was
+ changed to preserve the draft always, since _c_o_m_p, et.
al., could usually
+ look at a draft, apply another set of heuristics, and decide
if it was
+ important or not. With the notion of a _d_r_a_f_t
_f_o_l_d_e_r, in which one by
+ default gets a `new' message draft, the edit
deletion/preservation algo-
+ rithm was re-implemented, to keep the draft folder from
being cluttered
+ with aborted edits.
+
+ Also, note that by default, if the draft cannot be
successfully
+ sent, these commands return to "What now?" level. But,
when _p_u_s_h is
+ used, this does not happen (obviously). Hence, if these
commands were
+ expected to annotate any messages, this will have to be
done by hand,
+ later on, with the _a_n_n_o command.
+
+ Finally, if the `-delete' switch is not given to the
_q_u_i_t option,
+ then these commands will inform the user of the name of the
unsent draft
+ file.
+
+
+ _D_i_g_e_s_t_s
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -178-
+
+
+ The _f_o_r_w command has the beginnings of a
digestifying facility,
+ with the `-digest list', `-issue number', and `-volume
number' switches.
+
+ If _f_o_r_w is given "list" to the `-digest' switch as
the name of the dis-
+ cussion group, and the `-issue number' switch is not
given, then _f_o_r_w
+ looks for an entry in the user's _M_H context called
"_d_i_g_e_s_t-issue-list"
+ and increments its value to use as the issue number.
Similarly, if the
+ `-volume number' switch is not given, then
_f_o_r_w looks for
+ "_d_i_g_e_s_t-volume-list" (but does not increment
its value) to use as the
+ volume number.
+
+ Having calculated the name of the digest and the volume
and issue
+ numbers, _f_o_r_w will now process the components file
using the same format
+ string mechanism used by _r_e_p_l. The current
`%'-escapes are:
+
+ _e_s_c_a_p_e _t_y_p_e
_s_u_b_s_t_i_t_u_t_i_o_n
+ digest string digest name
+ msg integer issue number
+ cur integer volume number
+
+ In addition, to capture the current date, any of the escapes
valid for
+ _d_p (8) are also valid for _f_o_r_w.
+
+ The default components file used by _f_o_r_w when in
digest mode is:
+
+ From: %{digest}-Request
+ To: %{digest} Distribution: dist-%{digest};
+ Subject: %{digest} Digest V%(cur) #%(msg)
+ Reply-To: %{digest}
+ --------
+ %{digest} Digest %(weekday{date}), %2(mday{date})
%(month{date}) 19%02(year{date})
+ Volume %(cur) : Issue %(msg)
+
+ Today's Topics:
+
+ Hence, when the `-digest' switch is present, the first step
taken by
+ _f_o_r_w is to expand the format strings in the
component file. The next
+ step is to compose the draft using the standard digest
encapsulation
+ algorithm (even putting an "End of list Digest" trailer in
the draft).
+ Once the draft is composed by _f_o_r_w, _f_o_r_w
writes out the volume and issue
+ profile entries for the digest, and then invokes the editor.
+
+ Naturally, when composing the draft, _f_o_r_w
will honor the
+ `-filter filterfile' switch, which is given to _m_h_l to
filter each mes-
+ sage being forwarded prior to encapsulation in the draft. A
good filter
+ file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -179-
+
+
+ width=80,overflowoffset=10
+ leftadjust,compress,compwidth=9
+
Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+ _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+ There are two interesting facilities for
manipulating folders:
+ relative folder addressing, which allows a user to shorten
the typing of
+ long folder names; and the folder-stack, which permits a user
to keep a
+ stack of current folders.
+
+
+ _R_e_l_a_t_i_v_e _F_o_l_d_e_r
_A_d_d_r_e_s_s_i_n_g
+
+ By default, when `+folder' is given, and the folder
name is not
+ absolute (does not start with /, ./, or ../), then the UNIX
pathname of
+ the folder is interpreted relative to the user's _M_H
directory. Although
+ this mechanism works fine for top-level folders and
their immediate
+ sub-folders, once the depth of the sub-folder tree grows,
it becomes
+ rather unwieldly:
+
+ scan +mh/mh.4/draft/flames
+
+ is a lot of typing. _M_H can't do anything if the
current folder was
+ "+inbox", but if the current folder was, say,
"+mh/mh.4/draft", _M_H has a
+ short-hand notation to reference a sub-folder of the
current folder.
+ Using the address@hidden' notation, the _M_H user can
direct any _M_H program
+ which expects a `+folder' argument to look for the folder
relative to
+ the current folder instead of the user's _M_H directory.
Hence, if the
+ current folder _w_a_s "+mh/mh.4/draft", then
+
+ scan @flames
+
+ would do the trick handily. In addition, if the current
folder _w_a_s
+ "+mh/mh.4/draft",
+
+ scan @../pick
+
+ would scan the folder "+mh/mh.4/pick", since, in the UNIX
fashion, it
+ references the folder "pick" which is a sub-folder of the
folder that is
+ the parent of the current folder. Since most advanced _M_H
users seem to
+ exhibit a large degree of locality in referencing folders
when they pro-
+ cess mail, this convention should receive a wide range of
uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -180-
+
+
+ _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+ The _f_o_l_d_e_r-_s_t_a_c_k mechanism in
_M_H gives the _M_H user a facility simi-
+ lar to the _C_S_h_e_l_l 's directory-stack. Simply put,
+
+ folder -push +foo
+
+ makes "foo" the current folder, saving the folder that was
previously
+ the current folder on the _f_o_l_d_e_r-_s_t_a_c_k.
As expected,
+
+ folder -pop
+
+ takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and
makes it the current folder. Each
+ of these switches lists the
_f_o_l_d_e_r-_s_t_a_c_k when they execute. It is sim-
+ ple to write a _p_u_s_h_f command as a shell script.
It's one line:
+
+ exec folder -push $@
+
+ Probably a better way is to link _f_o_l_d_e_r to the
$HOME/bin/ directory
+ under the name of _p_u_s_h_f and then add the entry
+
+ pushf: -push
+
+ to the .mh_profile.
+
+ The manual page for _f_o_l_d_e_r discusses the
analogy between the _C_S_h_e_l_l
+ directory stack commands and the switches in
_f_o_l_d_e_r which manipulate the
+ _f_o_l_d_e_r-_s_t_a_c_k. The _f_o_l_d_e_r
command uses the context entry `Folder-Stack:'
+ to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix A
+ _C_O_M_M_A_N_D
_S_U_M_M_A_R_Y
+
+
+
+
+ ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ anno [+folder] [msgs] [-component field] [-inplace]
[-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet]
[-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c]
[-rcfile rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
+ [-host host] [-help]
+
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet]
[-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage
msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc]
[-help]
+
+ /usr/bs/mh-6.8/lib/fmtdump [-form formatfile] [-format string]
+ [-help]
+
+ folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+ [-noheader] [-pack] [-nopack] [-recurse] [-norecurse]
[-total]
+ [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+ [-pop] [-help]
+
+ folders
+
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace]
[-noinplace]
+ [-mime] [-nomime] [-whatnowproc program] [-nowhatnowproc]
+ [-help]
+
+
+
+
+
+
+ -181-
+
+
+
+
+
+
+
+
+
+
+
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w]
[-help]
+
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-file name] [-form formatfile]
+ [-format string] [-silent] [-nosilent] [-truncate]
+ [-notruncate] [-width columns] [-host host] [-user user]
+ [-apop] [-noapop] [-rpop] [-norpop] [-pack file]
[-nopack]
+ [-help]
+
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete]
[-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ /usr/bs/mh-6.8/lib/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc]
[files ...]
+ [-help]
+
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ mhn [+folder] [msgs] [-part number]... [-type content]...
+ [-list [-header] [-noheader]
+ [-realsize] [-norealsize]] [-nolist]
+ [-show [-serialonly] [-noserialonly]]
+ [-form formfile]] [-noshow]
+ [-store [-auto] [-noauto]] [-nostore]
+ [-verbose] [-noverbose] [-rfc934mode] [-norfc934mode]
+ [-ebcdic] [-noebcdicsafe]
+ [-help]
+
+ mhparam [profile-components] [-components] [-nocomponents]
[-all]
+ [-help]
+
+ mhpath [+folder] [msgs] [-help]
+
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [-host host] [-user user]
[-apop]
+ [-noapop] [-rpop] [-norpop] [users ...] [-help]
+
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur]
[file]
+ [-help]
+
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ packf [+folder] [msgs] [-file name] [-help]
+
+
+
+
+
+
+ -182-
+
+
+
+
+
+
+
+
+
+
+
+
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-after date]
+ [-before date] [-datefield field] [-sequence name ...]
+ [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+ [-help]
+
+
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend]
[-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ /usr/bs/mh-6.8/lib/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero]
[-nozero]
+ [-help]
+
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve]
[-nopreserve]
+ [-src +folder] [-file file] +folder ... [-help]
+
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc
all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form
formfile]
+ [-inplace] [-noinplace] [-query] [-noquery]
+ [-whatnowproc program] [-nowhatnowproc] [-width columns]
+ [-help]
+
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ rmm [+folder] [msgs] [-help]
+
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-mime] [-nomime] [-msgid] [-nomsgid] [-push] [-nopush]
+ [-split seconds] [-verbose] [-noverbose] [-watch]
[-nowatch]
+ [-width columns] [file ...] [-help]
+
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+
+
+ -183-
+
+
+
+
+
+
+
+
+
+
+
+
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ whatnow [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file]
[-help]
+
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [file] [-help]
+
+ /usr/bs/mh-6.8/lib/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+ /usr/bs/mh-6.8/lib/conflict [-mail name] [-search directory]
+ [aliasfiles ...] [-help]
+
+ /usr/bs/mh-6.8/lib/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ /usr/bs/mh-6.8/lib/install-mh [-auto] [-compat]
+
+ /usr/bs/mh-6.8/lib/post [-alias aliasfile] [-filter
filterfile]
+ [-nofilter] [-format] [-noformat] [-mime] [-nomime]
[-msgid]
+ [-nomsgid] [-verbose] [-noverbose] [-watch] [-nowatch]
+ [-width columns] file [-help]
+
+ /usr/bs/mh-6.8/lib/slocal [address info sender] [-addr
address]
+ [-info data] [-sender sender] [-user username] [-mailbox
mbox]
+ [-file file] [-maildelivery deliveryfile] [-verbose]
+ [-noverbose] [-debug] [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -184-
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix B
+ _M_E_S_S_A_G_E
_N_A_M_E _B_N_F
+
+
+
+
+
+ msgs := msgspec |
+ msgs msgspec
+
+ msgspec := msg |
+ msg-range |
+ msg-sequence |
+ user-defined-sequence
+
+ msg := msg-name |
+ <number>
+
+ msg-name := "first" |
+ "last" |
+ "cur" |
+ "." |
+ "next" |
+ "prev"
+
+ msg-range := msg"-"msg |
+ "all"
+
+ msg-sequence := msg":"signed-number
+
+ signed-number := "+"<number> |
+ "-"<number> |
+ <number>
+
+ user-defined-sequence := <alpha> |
+ <alpha><alphanumeric>*
+
+
+ Where <number> is a decimal number greater than zero.
+
+ Msg-range specifies all of the messages in the given range
and must not
+ be empty.
+
+ Msg-sequence specifies up to <number> of messages, beginning
with "msg"
+ (in the case of first, cur, next, or <number>), or ending
with "msg" (in
+ the case of prev or last). +<number> forces "starting with
msg", and
+ -<number> forces "ending with number". In all cases, "msg"
must exist.
+
+ User-defined sequences are defined and manipulated with the
_p_i_c_k and
+ _m_a_r_k commands.
+
+
+
+ -185-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_F_E_R_E_N_C_E_S
+
+
+
+ 1. Crocker, D. H., J. J. Vittal, K. T. Pogran, and D. A.
Henderson,
+ Jr., "Standard for the Format of ARPA Network Text
Messages,"
+ _R_F_C_7_3_3, November 1977.
+
+ 2. Thompson, K., and D. M. Ritchie, "The UNIX
Time-sharing System,"
+ _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f
_t_h_e _A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+ 3. McCauley, E. J., and P. J. Drongowski, "KSOS-The Design
of a Secure
+ Operating System," _A_F_I_P_S
_C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, National
Computer
+ Conference, Vol. 48, 1979, pp. 345-353.
+
+ 4. Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d
_F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l
_M_e_s_-
+ _s_a_g_e _S_y_s_t_e_m, The RAND Corporation,
R-2134-ARPA, December 1977.
+
+ 5. Thompson, K., and D. M. Ritchie, _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th ed.,
+ Western Electric Company, May 1975 (available only to
UNIX licen-
+ sees).
+
+ 6. Crocker, D. H., "Standard for the Format of ARPA Internet
Text Mes-
+ sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -186-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -i-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_A_D _T_H_I_S
+
+
+
+
+ Although the _M_H system was originally developed by
the RAND Cor-
+ poration, and is now in the public domain, the RAND
Corporation assumes
+ no responsibility for _M_H or this particular version of
_M_H.
+
+ In addition, the Regents of the University of California
issue the
+ following disclaimer in regard to the UCI version of _M_H:
+
+ "Although each program has been tested by its
contributor, no war-
+ ranty, express or implied, is made by the
contributor or the
+ University of California, as to the accuracy and
functioning of the
+ program and related program material, nor shall the fact
of distri-
+ bution constitute any such warranty, and no
responsibility is
+ assumed by the contributor or the University of
California in con-
+ nection herewith."
+
+ This version of _M_H is in the public domain, and as
such, there are
+ no real restrictions on its use. The _M_H source code
and documentation
+ have no licensing restrictions whatsoever. As a courtesy,
the authors
+ ask only that you provide appropriate credit to the RAND
Corporation and
+ the University of California for having developed the
software.
+
+ _M_H is a software package that is supported neither
by the RAND Cor-
+ poration nor the University of California. However, since we
do use the
+ software ourselves and plan to continue using (and
improving) _M_H, bug
+ reports and their associated fixes should be reported back to
us so that
+ we may include them in future releases. The current
computer mailbox
+ for _M_H is address@hidden (in the ARPA
Internet), and
+ ...!ucbvax!ucivax!bug-mh (UUCP). Presently, there are two
Internet dis-
+ cussion groups, address@hidden and address@hidden
+ MH-Workers is for people discussing code changes to _M_H.
MH-Users is for
+ general discussion about how to use _M_H. MH-Users is
bi-directionally
+ gatewayed into USENET as comp.mail.mh.
+
+ _H_O_W _T_O _G_E_T _M_H
+
+ Since you probably already have _M_H, you may not need
to read this
+ unless you suspect you have an old version. There are two
ways to get
+ the latest release:
+
+ 1. If you can FTP to the ARPA Internet, use
anonymous FTP to
+ ics.uci.edu [128.195.1.1] and retrieve the file
pub/mh/mh-6.8.tar.Z.
+ This is a tar image after being run through the
compress program
+ (approximately 1.8MB). There should also be a README
file in that
+ directory which tells what the current release of _M_H is,
and how to get
+ updates.
+
+
+
+ -i-
+
+
+
+
+
+
+
+
+
+ -ii-
+
+
+ This tar file is also available on louie.udel.edu
[128.175.1.3] in
+ portal/mh-6.8.tar.Z. You may also find MH on various
other hosts; to
+ make sure you get the latest version and don't waste your
time re-fixing
+ bugs, it's best to get it from either ics.uci.edu or
louie.udel.edu.
+
+ 2. You can send $75 US to the address below. This
covers the cost
+ of a 6250 BPI 9-track magtape, handling, and shipping.
In addition,
+ you'll get a laser-printed hard-copy of the entire MH
documentation set.
+ Be sure to include your USPS address with your check.
Checks must be
+ drawn on U.S. funds and should be made payable to:
+
+ Regents of the University of California
+
+ The distribution address is:
+
+ Computing Support Group
+ Attn: MH distribution
+ Department of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92717
+
+ 714/856-7554
+
+ If you just want the hard-copies of the documentation,
you still
+ have to pay the $75. The tar image has the documentation
source (the
+ manual is in roff format, but the rest are in TeX format).
Postscript
+ formatted versions of the TeX papers are available, as are
crude tty-
+ conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _F_O_R_E_W_O_R_D
+
+
+
+
+ This document describes the RAND _M_H Message Handling
System. Its
+ primary purpose is to serve as a user's manual. It has
been heavily
+ based on a previous version of the manual, prepared by
Bruce Borden,
+ Stockton Gaines, and Norman Shapiro.
+
+ _M_H is a particularly novel system, and thus it is
often more prone
+ to change than other pieces of production software. As
such, some
+ specific points in this manual may not be correct in the
future. In all
+ cases, the on-line sections of this manual, available
through the
+ UNIX[1] _m_a_n command, should present the most current
information.
+
+ When reading this document as a user's manual, certain
sections are
+ more interesting than others. The Preface and Summary are
not particu-
+ larly interesting to those interested in learning _M_H.
The Introduction
+ is slightly more interesting, as it touches upon the
organization of the
+ remainder of this document. The most useful sections are the
Overview,
+ Tutorial, and Detailed Description. The Overview should be
read by all
+ _M_H users, regardless of their expertise (beginning,
novice, advanced, or
+ hacker). The Tutorial should be read by all beginning
and novice _M_H
+ users, as it presents a nice description of the _M_H
system. The Detailed
+ Description should be read by the day-to-day user of
_M_H, as it spells
+ out all of the realities of the _M_H system. The Advanced
Features sec-
+ tion discusses some powerful _M_H capabilities for advanced
users. Appen-
+ dix A is particularly useful for novices, as it summarizes
the invoca-
+ tion syntax of all the _M_H commands.
+
+ There are also several other documents which may be
useful to you:
+ _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is
a tutorial for
+ _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I
_B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+ describes the BBoards handling under _M_H; _M_H._5:
_H_o_w _t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+ _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l
_g_e_t _s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which was
presented at
+ the 1985 Summer Usenix Conference and Exhibition in
Portland, Oregon;
+ _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r
_A_g_e_n_t, which has been accepted for publication
+ by Computer Networks; _M_Z_n_e_t: _M_a_i_l
_S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l
_M_i_c_r_o-_C_o_m_p_u_t_e_r
+ _S_y_s_t_e_m_s, which was presented at the First
International Symposium on
+ Computer Message Systems in Nottingham, U.K.; and,
_D_e_s_i_g_n _o_f _t_h_e _T_T_I
+ _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d
_M_a_i_l _A_g_e_n_t, which describes a proprietary "trusted"
+ mail system built on _M_H. There are also documents,
mostly specific to
+ U.C. Irvine which you may find interesting: _M_H _f_o_r
_B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+ _M_M _U_s_e_r_s. All of these documents exist in the
_m_h._6 distribution sent to
+ your site. There's also a document, _C_h_a_n_g_e_s
_t_o _t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m: _M_H._6, which
describes user-visible changes made to _M_H
+ since the last major release.
+
+
+ [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+ -iii-
+
+
+
+
+
+
+
+
+
+ -iv-
+
+
+ This manual is very large, as it describes a large,
powerful system
+ in gruesome detail. The important thing to remember is:
+
+
+ _D_O_N'_T
_P_A_N_I_C[_2]
+
+
+ As explained in the tutorial, you really need to know only 5
commands to
+ handle most of your mail.
+
+ Very advanced users may wish to consult _T_h_e
_R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m:
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also
present in the _m_h._6
+ distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
_A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+ The _M_H system described herein is based on the
original RAND _M_H
+ system. It has been extensively developed (perhaps too
much so) by
+ Marshall T. Rose and John L. Romine at the University of
California,
+ Irvine. Einar A. Stefferud, Jerry N. Sweet, and Terry P.
Domae provided
+ numerous suggestions to improve the UCI version of _M_H.
Of course, a
+ large number of people have helped _M_H along. The list
of ``_M_H immor-
+ tals'' is too long to list here. However, Van Jacobson
deserves a spe-
+ cial acknowledgement for his tireless work in improving the
performance
+ of _M_H. Some programs have been speeded-up by a factor of
10 or 20. All
+ of users of _M_H, everywhere, owe a special thanks to
Van. For this
+ release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes
and other changes. A handful
+ of courageous _M_H-_W_o_r_k_e_r_s volunteered to
beta-test these changes; their
+ help is particularly appreciated.
+
+ This manual is based on the original _M_H manual
written at RAND by
+ Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -v-
+
+
+
+
+
+
+
+
+
+
+
+
+ _P_R_E_F_A_C_E
+
+
+
+
+ This report describes a system for dealing with messages
transmit-
+ ted on a computer. Such messages might originate with
other users of
+ the same computer or might come from an outside source
through a network
+ to which the user's computer is connected. Such
computer-based message
+ systems are becoming increasingly widely used, both within
and outside
+ the Department of Defense.
+
+ The message handling system _M_H was developed for two
reasons. One
+ was to investigate some research ideas concerning how a
message system
+ might take advantage of the architecture of the UNIX
time-sharing
+ operating system for Digital Equipment Corporation PDP-11
and VAX com-
+ puters, and the special features of UNIX's command-level
interface with
+ the user (the "shell"). The other reason was to provide a
better and
+ more adaptable base than that of conventional designs on
which to build
+ a command and control message system. The effort has
succeeded in both
+ regards, although this report mainly describes the message
system itself
+ and how it fits in with UNIX.
+
+ The present report should be of interest to three
groups of
+ readers. First, it is a complete reference manual for the
users of _M_H.
+ Second, it should be of interest to those who have a general
knowledge
+ of computer-based message systems, both in civilian and
military appli-
+ cations. Finally, it should be of interest to those who
build large
+ subsystems that interface with users, since it
illustrates a new
+ approach to such interfaces.
+
+ The original _M_H system was developed by Bruce
Borden, using an
+ approach suggested by Stockton Gaines and Norman
Shapiro. Valuable
+ assistance was provided by Phyllis Kantar in the later
stages of the
+ system's implementation. Several colleagues contributed
to the ideas
+ included in this system, particularly Robert Anderson and
David Crocker.
+ In addition, valuable experience in message systems, and
a valuable
+ source of ideas, was available to us in the form of a
previous message
+ system for UNIX called MS, designed at RAND by David Crocker.
+
+ This report was originally prepared as part of the
RAND project
+ entitled "Data Automation Research", sponsored by Project AIR
FORCE.
+
+
+
+
+
+
+
+
+
+
+
+ -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+ _S_U_M_M_A_R_Y
+
+
+
+
+ Electronic communication of text messages is becoming
commonplace.
+ Computer-based message systems-software packages that
provide tools for
+ dealing with messages-are used in many contexts. In
particular, message
+ systems are becoming increasingly important in command and
control and
+ intelligence applications.
+
+ This report describes a message handling system called
_M_H. This
+ system provides the user with tools to compose, send,
receive, store,
+ retrieve, forward, and reply to messages. _M_H has been
built on the UNIX
+ time-sharing system, a popular operating system developed
for the DEC
+ PDP-11 and VAX classes of computers.
+
+ A complete description of _M_H is given for users of
the system. For
+ those who do not intend to use the system, this description
gives a gen-
+ eral idea of what a message system is like. The system
involves some
+ new ideas about how large subsystems can be constructed.
+
+ The interesting and unusual features of _M_H include
the following:
+ The user command interface to _M_H is the UNIX "shell"
(the standard UNIX
+ command interpreter). Each separable component of message
handling,
+ such as message composition or message display, is a
separate command.
+ Each program is driven from and updates a private user
environment,
+ which is stored as a file between program invocations.
This private
+ environment also contains information to "custom tailor"
_M_H to the
+ individual's tastes. _M_H stores each message as a
separate file under
+ UNIX, and it utilizes the tree-structured UNIX file system
to organize
+ groups of files within separate directories or "folders".
All of the
+ UNIX facilities for dealing with files and directories, such
as renam-
+ ing, copying, deleting, cataloging, off-line printing, etc.,
are appli-
+ cable to messages and directories of messages (folders).
Thus, impor-
+ tant capabilities needed in a message system are available in
_M_H without
+ the need (often seen in other message systems) for code that
duplicates
+ the facilities of the supporting operating system. It also
allows users
+ familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+ _C_O_N_T_E_N_T_S
+
+
+
+
+ READ THIS
......................................................... i
+
+ FOREWORD
.......................................................... iii
+
+ ACKNOWLEDGMENTS
................................................... v
+
+ PREFACE
........................................................... vi
+
+ SUMMARY
........................................................... vii
+
+ Section
+
+ 1. INTRODUCTION
............................................... 1
+
+ 2. OVERVIEW
................................................... 4
+
+ 3. TUTORIAL
................................................... 7
+
+ 4. DETAILED DESCRIPTION
....................................... 10
+ THE USER PROFILE
............................................. 10
+ MESSAGE NAMING
............................................... 13
+ OTHER MH CONVENTIONS
......................................... 14
+ MH COMMANDS
.................................................. 16
+ ALI
....................................................... 17
+ ANNO
...................................................... 19
+ BBC
....................................................... 21
+ BBOARDS
................................................... 24
+ BURST
..................................................... 26
+ COMP
...................................................... 28
+ DIST
...................................................... 30
+ FOLDER
.................................................... 33
+ FORW
...................................................... 37
+ INC
....................................................... 42
+ MARK
...................................................... 45
+ MHL
....................................................... 47
+ MHMAIL
.................................................... 52
+ MHN
....................................................... 54
+ MHOOK
..................................................... 70
+ MHPARAM
................................................... 72
+ MHPATH
.................................................... 74
+ MSGCHK
.................................................... 77
+ MSH
....................................................... 79
+ NEXT
...................................................... 83
+ PACKF
..................................................... 84
+ PICK
...................................................... 85
+ PREV
...................................................... 90
+ PROMPTER
.................................................. 91
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RCVSTORE
.................................................. 94
+ REFILE
.................................................... 96
+ REPL
...................................................... 98
+ RMF
....................................................... 102
+ RMM
....................................................... 104
+ SCAN
...................................................... 106
+ SEND
...................................................... 109
+ SHOW
...................................................... 112
+ SLOCAL
.................................................... 115
+ SORTM
..................................................... 120
+ VMH
....................................................... 122
+ WHATNOW
................................................... 124
+ WHOM
...................................................... 127
+ MORE DETAILS
................................................. 129
+ MH-ALIAS
.................................................. 130
+ MH-FORMAT
................................................. 134
+ MH-MAIL
................................................... 143
+ MH-PROFILE
................................................ 147
+ MH-SEQUENCE
............................................... 155
+ AP
........................................................ 159
+ CONFLICT
.................................................. 161
+ DP
........................................................ 163
+ FMTDUMP
................................................... 165
+ INSTALL-MH
................................................ 166
+ POST
...................................................... 167
+
+ 5. REPORTING PROBLEMS
......................................... 169
+
+ 6. ADVANCED FEATURES
.......................................... 170
+ USER-DEFINED SEQUENCES
....................................... 170
+ Pick and User-Defined Sequences
........................... 170
+ Mark and User-Defined Sequences
........................... 172
+ Public and Private User-Defined Sequences
................. 172
+ Sequence Negation
......................................... 172
+ The Previous Sequence
..................................... 173
+ The Unseen Sequence
....................................... 173
+ COMPOSITION OF MAIL
.......................................... 174
+ The Draft Folder
.......................................... 174
+ What Happens if the Draft Exists
.......................... 176
+ The Push Option at What now? Level
........................ 176
+ Options at What now? Level
................................ 177
+ Digests
................................................... 178
+ FOLDER HANDLING
.............................................. 179
+ Relative Folder Addressing
................................ 179
+ The Folder-Stack
.......................................... 180
+
+ Appendix
+ A. Command Summary
............................................ 181
+ B. Message Name BNF
........................................... 185
+
+ REFERENCES
........................................................ 186
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ THE RAND MH
+
+
+ MESSAGE HANDLING
+
+
+ SYSTEM:
+
+
+ USER'S MANUAL
+
+
+
+
+
+
+ UCI Version
+
+
+
+
+
+ Marshall T. Rose
+
+ John L. Romine
+
+
+
+
+ Based on the original manual by
+
+ Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+ December 14, 1992
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 6.6 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/MH.pdf b/docs/historical/MH.pdf
new file mode 100644
index 0000000..1a460cc
Binary files /dev/null and b/docs/historical/MH.pdf differ
diff --git a/docs/historical/MH.txt b/docs/historical/MH.txt
new file mode 100644
index 0000000..1c25514
--- /dev/null
+++ b/docs/historical/MH.txt
@@ -0,0 +1,11880 @@
+
+
+
+
+
+
+
+
+ _d_i_s_c_a_r_d _t_h_i_s
_p_a_g_e
+
+
+
+
+ The RAND _M_H
+ Message Handling System:
+ User's Manual
+
+ UCI Version
+
+
+ November 30, 1993
+ 6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _1.
_I_N_T_R_O_D_U_C_T_I_O_N
+
+
+
+
+
+ Although people can travel cross-country in hours and
can reach
+ others by telephone in seconds, communications still depend
heavily upon
+ paper, most of which is distributed through the mails.
+
+ There are several major reasons for this continued
dependence on
+ written documents. First, a written document may be
proofread and
+ corrected prior to its distribution, giving the author
complete control
+ over his words. Thus, a written document is better than
a telephone
+ conversation in this respect. Second, a carefully written
document is
+ far less likely to be misinterpreted or poorly translated
than a phone
+ conversation. Third, a signature offers reasonable
verification of
+ authorship, which cannot be provided with media such as
telegrams.
+
+ However, the need for fast____, accurate, and
reproducible document
+ distribution is obvious. One solution in widespread use is
the telefax.
+ Another that is rapidly gaining popularity is electronic
mail. Elec-
+ tronic mail is similar to telefax in that the data to be
sent are digi-
+ tized, transmitted via phone lines, and turned back into a
document at
+ the receiver. The advantage of electronic mail is in its
compression
+ factor. Whereas a telefax must scan a page in very fine
lines and send
+ all of the black and white information, electronic mail
assigns charac-
+ ters fixed codes which can be transmitted as a few bits of
information.
+ Telefax presently has the advantage of being able to
transmit an arbi-
+ trary page, including pictures, but electronic mail is
beginning to deal
+ with this problem. Electronic mail also integrates well
with current
+ directions in office automation, allowing documents
prepared with
+ sophisticated equipment at one site to be quickly
transferred and
+ printed at another site.
+
+ Currently, most electronic mail is intraorganizational,
with mail
+ transfer remaining within one computer. As computer
networking becomes
+ more common, however, it is becoming more feasible to
communicate with
+ anyone whose computer can be linked to your own via a network.
+
+ The pioneering efforts on general-purpose electronic
mail were by
+ organizations using the DoD ARPAnet[1]. The capability to
send messages
+ between computers existed before the ARPAnet was developed,
but it was
+ used only in limited ways. With the advent of the ARPAnet,
tools began
+ to be developed which made it convenient for individuals or
organiza-
+ tions to distribute messages over broad geographic areas,
using diverse
+ computer facilities. The interest and activity in message
systems has
+ now reached such proportions that steps have been taken
within the DoD
+ to coordinate and unify the development of military
message systems.
+ The use of electronic mail is expected to increase
dramatically in the
+ next few years. The utility of such systems in the command
and control
+ and intelligence environments is clear, and applications in
these areas
+
+
+
+
+
+
+
+
+
+
+
+ -2-
+
+
+ will probably lead the way. As the costs for sending and
handling elec-
+ tronic messages continue their rapid decrease, such uses can
be expected
+ to spread rapidly into other areas and, of course, will not
be limited
+ to the DoD.
+
+ A message system provides tools that help users
(individuals or
+ organizations) deal with messages in various ways.
Messages must be
+ composed, sent, received, stored, retrieved, forwarded, and
replied to.
+ Today's best interactive computer systems provide a
variety of word-
+ processing and information handling capabilities. The
message handling
+ facilities should be well integrated with the rest of the
system, so as
+ to be a graceful extension of overall system capability.
+
+ The message system described in this report, _M_H,
provides most of
+ the features that can be found in other message systems and
also incor-
+ porates some new ones. It has been built on the UNIX
time-sharing sys-
+ tem[2], a popular operating system for the DEC PDP-11[1]
and VAX-11
+ classes of computers. A "secure" operating system similar
to UNIX is
+ currently being developed[3], and that system will also run
_M_H.
+
+ This report provides a complete description of _M_H
and thus may
+ serve as a user's manual, although parts of the report
will be of
+ interest to non-users as well. Sections 2 and 3, the
Overview and
+ Tutorial, present the key ideas of _M_H and will give
those not familiar
+ with message systems an idea of what such systems are like.
+
+ _M_H consists of a set of commands which use some
special files and
+ conventions. The final section is divided into three parts.
The first
+ part covers the information a user needs to know in addition
to the com-
+ mands. Then, each of the _M_H commands is described in
detail. Finally,
+ other obscure details are revealed. A summary of the
commands is given
+ in Appendix A, and the syntax of message sequences is given
in Appendix
+ B.
+
+ A novel approach has been taken in the design of
_M_H. Instead of
+ creating a large subsystem that appears as a single command
to the user
+ (such as MS[4]), _M_H is a collection of separate commands
which are run
+ as separate programs. The file and directory system of
UNIX are used
+ directly. Messages are stored as individual files
(datasets), and col-
+ lections of them are grouped into directories. In contrast,
most other
+ message systems store messages in a complicated data
structure within a
+ monolithic file. With the _M_H approach, UNIX commands can
be interleaved
+ with commands invoking the functions of the message
handler. Con-
+ versely, existing UNIX commands can be used in connection
with messages.
+ For example, all the usual UNIX editing, text-formatting,
and printing
+ facilities can be applied directly to individual messages.
MH, there-
+ fore, consists of a relatively small amount of new code; it
makes exten-
+ sive use of other UNIX software to provide the
capabilities found in
+
+
+ [1] PDP and VAX are trademarks of Digital Equipment
Corporation.
+
+
+
+
+
+
+
+
+
+
+
+
+ -3-
+
+
+ other message systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _2. _O_V_E_R_V_I_E_W
+
+
+
+
+
+ There are three main aspects of _M_H : the way
messages are
+ stored (the message database), the user's profile (which
directs how
+ certain actions of the message handler take place), and the
commands for
+ dealing with messages.
+
+ Under _M_H, each message is stored as a separate file.
A user can
+ take any action with a message that he could with an
ordinary file in
+ UNIX. A UNIX directory in which messages are stored is
called a folder.
+ Each folder contains some standard entries to support
the message-
+ handling functions. The messages in a folder have
numerical names.
+ These folders (directories) are entries in a particular
directory path,
+ described in the user profile, through which _M_H can find
message fold-
+ ers. Using the UNIX "link" facility, it is possible for
one copy of a
+ message to be "filed" in more than one folder, providing a
message index
+ facility. Also, using the UNIX tree-structured file system,
it is pos-
+ sible to have a folder within a folder, nested arbitrarily
deep, and
+ have the full power of the _M_H commands available.
+
+ Each user of _M_H has a user profile, a file in his
$HOME (initial
+ login) directory called ._m_h__p_r_o_f_i_l_e.
This profile contains several
+ pieces of information used by the _M_H commands: a path
name to the direc-
+ tory that contains the message folders and parameters
that tailor _M_H
+ commands to the individual user's requirements. There is
also another
+ file, called the user context, which contains information
concerning
+ which folder the user last referenced (the "current" folder).
It also
+ contains most of the necessary state information concerning
how the user
+ is dealing with his messages, enabling _M_H to be
implemented as a set of
+ individual UNIX commands, in contrast to the usual approach
of a monol-
+ ithic subsystem.
+
+ In _M_H, incoming mail is appended to the end of a
file in a system
+ spooling area for the user. This area is called the mail
drop direc-
+ tory, and the file is called the user's mail drop. Normally
when the
+ user logins in, s/he is informed of new mail (or the _M_H
program _m_s_g_c_h_k
+ may be run). The user adds the new messages to his/her
collection of _M_H
+ messages by invoking the command _i_n_c. The
_i_n_c (incorporate) command
+ adds the new messages to a folder called "inbox", assigning
them names
+ which are consecutive integers starting with the next
highest integer
+ available in inbox. _i_n_c also produces a _s_c_a_n
summary of the messages
+ thus incorporated. A folder can be compacted into a
single file, for
+ easy storage, by using the _p_a_c_k_f command. Also,
messages within a
+ folder can be sorted by date and time with the
_s_o_r_t_m command.
+
+
+ There are four commands for examining the messages in
a folder:
+ _s_h_o_w, _p_r_e_v, _n_e_x_t, and
_s_c_a_n. The _s_h_o_w command displays a message in a
+
+ -4-
+
+
+
+
+
+
+
+
+
+ -5-
+
+
+ folder, _p_r_e_v displays the message preceding the
current message, and
+ _n_e_x_t displays the message following the current
message. _M_H lets the
+ user choose the program that displays individual messages.
A special
+ program, _m_h_l, can be used to display messages
according to the user's
+ preferences. The _s_c_a_n command summarizes the
messages in a folder, nor-
+ mally producing one line per message, showing who the
message is from,
+ the date, the subject, etc.
+
+ The user may move a message from one folder to another
with the
+ command _r_e_f_i_l_e. Messages may be removed from a
folder by means of the
+ command _r_m_m. In addition, a user may query what the
current folder is
+ and may specify that a new folder become the current folder,
through the
+ command _f_o_l_d_e_r. All folders may be summarized
with the _f_o_l_d_e_r_s command.
+ A message folder (or subfolder) may be removed by means of
the command
+ _r_m_f.
+
+ A set of messages based on content may be selected by
use of the
+ command _p_i_c_k. This command searches through
messages in a folder and
+ selects those that match a given set of criteria. These
messages are
+ then bound to a "sequence" name for use with other _M_H
commands. The
+ _m_a_r_k command manipulates these sequences.
+
+ There are five commands enabling the user to create
new messages
+ and send them: _c_o_m_p, _d_i_s_t, _f_o_r_w,
_r_e_p_l, and _s_e_n_d. The _c_o_m_p command pro-
+ vides the facility for the user to compose a new message;
_d_i_s_t redistri-
+ butes mail to additional addressees; _f_o_r_w enables
the user to forward
+ messages; and _r_e_p_l facilitates the generation of a
reply to an incoming
+ message. The last three commands may optionally annotate
the original
+ message. Messages may be arbitrarily annotated with the
_a_n_n_o command.
+ Once a draft has been constructed by one of the four above
composition
+ programs, a user-specifiable program is run to query the user
as to the
+ disposition of the draft prior to sending. _M_H provides
the simple _w_h_a_t_-
+ _n_o_w program to start users off. If a message is not
sent directly by
+ one of these commands, it may be sent at a later time using
the command
+ _s_e_n_d. _M_H allows the use of any UNIX editor when
composing a message.
+ For rapid entry, a special editor, _p_r_o_m_p_t_e_r,
is provided. For programs,
+ a special mail-sending program, _m_h_m_a_i_l, is
provided.
+
+ _M_H supports a personal aliasing facility which
gives users the
+ capability to considerably shorten address typein and use
meaningful
+ names for addresses. The _a_l_i program can be used to
query _M_H as to the
+ expansion of a list of aliases. After composing a message,
but prior to
+ sending, the _w_h_o_m command can be used to determine
exactly who a message
+ would go to.
+
+ _M_H provides a natural interface for telling the
user's shell the
+ names of _M_H messages and folders. The
_m_h_p_a_t_h program achieves this
+ capability.
+
+ Finally, _M_H supports the UCI BBoards facility.
_b_b_c can be used to
+ query the status of a group of BBoards, while _m_s_h
can be used to read
+ them. The _b_u_r_s_t command can be used to "shred"
digests of messages into
+
+
+
+
+
+
+
+
+
+
+
+ -6-
+
+
+ individual messages.
+
+ All of the elements summarized above are described in
more detail
+ in the following sections. Many of the normal facilities
of UNIX pro-
+ vide additional capabilities for dealing with messages in
various ways.
+ For example, it is possible to print messages on the
line-printer
+ without requiring any additional code within _M_H . Using
standard UNIX
+ facilities, any terminal output can be redirected to a file
for repeated
+ or future viewing. In general, the flexibility and
capabilities of the
+ UNIX interface with the user are preserved as a result of
the integra-
+ tion of _M_H into the UNIX structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _3. _T_U_T_O_R_I_A_L
+
+
+
+
+
+ This tutorial provides a brief introduction to the
_M_H commands. It
+ should be sufficient to allow the user to read his mail, do
some simple
+ manipulations of it, and create and send messages.
+
+ A message has two major pieces: the header and the
body. The body
+ consists of the text of the message (whatever you care to
type in). It
+ follows the header and is separated from it by an empty line.
(When you
+ compose a message, the form that appears on your terminal
shows a line
+ of dashes after the header. This is for convenience and is
replaced by
+ an empty line when the message is sent.) The header is
composed of
+ several components, including the subject of the message and
the person
+ to whom it is addressed. Each component starts with a name
and a colon;
+ components must not start with a blank. The text of the
component may
+ take more than one line, but each continuation line must
start with a
+ blank. Messages typically have "To:", "cc:", and "Subject:"
components.
+ When composing a message, you should include the "To:" and
"Subject:"
+ components; the "cc:" (for people you want to send copies
to) is not
+ necessary.
+
+ The basic _M_H commands are _i_n_c, _s_c_a_n,
_s_h_o_w, _n_e_x_t, _p_r_e_v, _r_m_m, _c_o_m_p,
+ and _r_e_p_l. These are described below.
+
+ _i_n_c
+
+ When you get the message "You have mail", type the
command _i_n_c.
+ You will get a "scan listing" such as:
+
+ 7+ 7/13 Cas revival of measurement work
+ 8 10/ 9 Norm NBS people and publications
+ 9 11/26 To:norm question <<Are there any functions
+
+ This shows the messages you received since the last time
you exe-
+ cuted this command (_i_n_c adds these new messages to
your inbox folder).
+ You can see this list again, plus a list of any other
messages you have,
+ by using the _s_c_a_n command.
+
+ _s_c_a_n
+
+ The scan listing shows the message number, followed by
the date and
+ the sender. (If you are the sender, the addressee in the
"To:" com-
+ ponent is displayed. You may send yourself a message by
including your
+ name among the "To:" or "cc:" addressees.) It also shows
the message's
+ subject; if the subject is short, the first part of the body
of the mes-
+ sage is included after the characters <<.
+
+
+
+ -7-
+
+
+
+
+
+
+
+
+
+ -8-
+
+
+ _s_h_o_w
+
+ This command shows the current message, that is, the
first one of
+ the new messages after an _i_n_c. If the message is not
specified by name
+ (number), it is generally the last message referred to by an
_M_H command.
+ For example,
+
+
+ _s_h_o_w 5 will show message 5.
+
+
+ You can use the show command to copy a message or print
a message.
+
+
+ _s_h_o_w > _x will copy the message to file x.
+ _s_h_o_w | _l_p_r will print the message, using
the _l_p_r command.
+ _n_e_x_t will show the message that follows
the current message.
+ _p_r_e_v will show the message previous to
the current message.
+ _r_m_m will remove the current message.
+ _r_m_m _3 will remove message 3.
+
+
+ _c_o_m_p
+
+ The _c_o_m_p command puts you in the editor to write
or edit a message.
+ Fill in or delete the "To:", "cc:", and "Subject:" fields,
as appropri-
+ ate, and type the body of the message. Then exit normally
from the edi-
+ tor. You will be asked "What now?". Type a carriage return
to see the
+ options. Typing send will cause the message to be sent;
typing quit
+ will cause an exit from _c_o_m_p, with the message draft
saved.
+
+ If you quit without sending the message, it will be
saved in a file
+ called <name>/Mail/draft (where <name> is your $HOME
directory). You
+ can resume editing the message later with "comp -use"; or you
can send
+ the message later, using the _s_e_n_d command.
+
+ _c_o_m_p -_e_d_i_t_o_r _p_r_o_m_p_t_e_r
+
+ This command uses a different editor and is useful for
preparing
+ "quick and dirty" messages. It prompts you for each
component of the
+ header. Type the information for that component, or type
a carriage
+ return to omit the component. After that, type the body of
the message.
+ Backspacing is the only form of editing allowed with this
editor. When
+ the body is complete, type a carriage return followed by
<EOT> (usually
+ <CTRL-D>). This completes the initial preparation of the
message; from
+ then on, use the same procedures as with _c_o_m_p (above).
+
+ _r_e_p_l
+ _r_e_p_l n
+
+ This command makes up an initial message form with a
header that is
+ appropriate for replying to an existing message. The
message being
+
+
+
+
+
+
+
+
+
+
+
+ -9-
+
+
+ answered is the current message if no message number is
mentioned, or n
+ if a number is specified. After the header is completed, you
can finish
+ the message as in _c_o_m_p (above).
+
+ This is enough information to get you going using
_M_H. There are
+ more commands, and the commands described here have more
features. Sub-
+ sequent sections explain _M_H in complete detail. The
system is quite
+ powerful if you want to use its sophisticated features, but
the forego-
+ ing commands suffice for sending and receiving messages.
+
+ There are numerous additional capabilities you may wish
to explore.
+ For example, the _p_i_c_k command will select a subset
of messages based on
+ specified criteria such as sender and/or subject. Groups
of messages
+ may be designated, as described in Sec. IV, under Message
Naming. The
+ file ._m_h__p_r_o_f_i_l_e can be used to tailor your
use of the message system to
+ your needs and preferences, as described in Sec. IV, under
The User Pro-
+ file. In general, you may learn additional features of
the system
+ selectively, according to your requirements, by studying
the relevant
+ sections of this manual. There is no need to learn all the
details of
+ the system at once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _4. _D_E_T_A_I_L_E_D
_D_E_S_C_R_I_P_T_I_O_N
+
+
+
+
+
+ This section describes the _M_H system in detail,
including the com-
+ ponents of the user profile, the conventions for message
naming, and
+ some of the other _M_H conventions. Readers who are
generally familiar
+ with computer systems will be able to follow the
principal ideas,
+ although some details may be meaningful only to those
familiar with
+ UNIX.
+
+
+ _T_H_E _U_S_E_R _P_R_O_F_I_L_E
+
+ The first time an _M_H command is issued by a new
user, the system
+ prompts for a "Path" and creates an _M_H "profile".
+
+ Each _M_H user has a profile which contains tailoring
information for
+ each individual program. Other profile entries control
the _M_H path
+ (where folders and special files are kept), folder and
message protec-
+ tions, editor selection, and default arguments for each
_M_H program.
+ Each user of _M_H also has a context file which contains
current state
+ information for the _M_H package (the location of the
context file is kept
+ in the user's _M_H directory, or may be named in the user
profile). When
+ a folder becomes the current folder, it is recorded in the
user's con-
+ text. (Other state information is kept in the context
file, see the
+ manual entry for _m_h-_p_r_o_f_i_l_e (5) for more
details.) In general, the term
+ "profile entry" refer to entries in either the profile or
context file.
+ Users of _M_H needn't worry about the distinction, _M_H
handles these things
+ automatically.
+
+ The _M_H profile is stored in the file
._m_h__p_r_o_f_i_l_e in the user's
+ $HOME directory[1]. It has the format of a message without
any body.
+ That is, each profile entry is on one line, with a keyword
followed by a
+ colon (:) followed by text particular to the keyword.
+ => _T_h_i_s _f_i_l_e _m_u_s_t _n_o_t
_h_a_v_e _b_l_a_n_k _l_i_n_e_s.
+ The keywords may have any combination of upper and lower
case. (See the
+ information of _m_h-_m_a_i_l later on in this manual
for a description of mes-
+ sage formats.)
+
+ For the average _M_H user, the only profile entry of
importance is
+ "Path". Path specifies a directory in which _M_H
folders and certain
+ files such as "draft" are found. The argument to this
keyword must be a
+ legal UNIX path that names an existing directory. If this
path is not
+ absolute (i.e., does not begin with a / ), it will be
presumed to start
+
+
+ [1] By defining the envariable $MH, you can specify an
alternate pro-
+ file to be used by _M_H commands.
+
+
+ -10-
+
+
+
+
+
+
+
+
+
+ -11-
+
+
+ from the user's $HOME directory. All folder and message
references
+ within _M_H will relate to this path unless full path names
are used.
+
+ Message protection defaults to 644, and folder
protection to 711.
+ These may be changed by profile entries "Msg-Protect"
and "Folder-
+ Protect", respectively. The argument to these keywords is
an octal
+ number which is used as the UNIX file mode[2].
+
+ When an _M_H program starts running, it looks through
the user's pro-
+ file for an entry with a keyword matching the program's name.
For exam-
+ ple, when _c_o_m_p is run, it looks for a "comp" profile
entry. If one is
+ found, the text of the profile entry is used as the default
switch set-
+ ting until all defaults are overridden by explicit switches
passed to
+ the program as arguments. Thus the
profile entry
+ "comp: -form standard.list" would direct _c_o_m_p to
use the file
+ "standard.list" as the message skeleton. If an explicit
form switch is
+ given to the _c_o_m_p command, it will override the
switch obtained from the
+ profile.
+
+ In UNIX, a program may exist under several names, either
by linking
+ or aliasing. The actual invocation name is used by an
_M_H program when
+ scanning for its profile defaults[3]. Thus, each _M_H
program may have
+ several names by which it can be invoked, and each name may
have a dif-
+ ferent set of default switches. For example, if _c_o_m_p
is invoked by the
+ name _i_c_o_m_p, the profile entry "icomp" will control
the default switches
+ for this invocation of the _c_o_m_p program. This
provides a powerful
+ definitional facility for commonly used switch settings.
+
+ The default editor for editing within _c_o_m_p,
_r_e_p_l, _f_o_r_w, and _d_i_s_t,
+ is usually _p_r_o_m_p_t_e_r, but might be something
else at your site, such as
+ /_u_s_r/_u_c_b/_e_x or /_b_i_n/_e. A different
editor may be used by specifying the
+ profile entry "Editor: ". The argument to "Editor" is the
name of an
+ executable program or shell command file which can be
found via the
+ user's $PATH defined search path, excluding the current
directory. The
+ "Editor:" profile specification may in turn be
overridden by a
+ `-editor <editor>' profile switch associated with
_c_o_m_p, _r_e_p_l, _f_o_r_w, or
+ _d_i_s_t. Finally, an explicit editor switch specified
with any of these
+ four commands will have ultimate precedence.
+
+ During message composition, more than one editor may be
used. For
+ example, one editor (such as _p_r_o_m_p_t_e_r )
may be used initially, and a
+
+
+ [2] See _c_h_m_o_d (1) in the _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l [5].
+ [3] Unfortunately, the shell does not preserve aliasing
information
+ when calling a program, hence if a program is invoked by an
alias dif-
+ ferent than its name, the program will examine the profile
entry for
+ it's name, not the alias that the user invoked it as. The
correct solu-
+ tion is to create a (soft) link in your
$_H_O_M_E/_b_i_n directory to the _M_H
+ program of your choice. By giving this link a different
name, you can
+ use an alternate set of defaults for the command.
+
+
+
+
+
+
+
+
+
+
+
+
+ -12-
+
+
+ second editor may be invoked later to revise the message
being composed
+ (see the discussion of _c_o_m_p in Section 5 for
details). A profile entry
+ "<lasteditor>-next: <editor>" specifies the name of the
editor to be
+ used after a particular editor. Thus "comp: -e prompter"
causes the
+ initial text to be collected by
_p_r_o_m_p_t_e_r, and the profile entry
+ "prompter-next: ed" names ed as the editor to be invoked
for the next
+ round of editing.
+
+ Some of the _M_H commands, such as _s_h_o_w, can
be used on message fold-
+ ers owned by others, if those folders are readable. However,
you cannot
+ write in someone else's folder. All the _M_H command
actions not requir-
+ ing write permission may be used with a "read-only" folder.
+
+ Table 1 lists examples of some of the currently
defined profile
+ entries, typical arguments, and the programs that reference
the entries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -13-
+
+
+ Table 1
+
+ PROFILE COMPONENTS
+
______________________________________________________
+
+ _M_H Programs that
+ Keyword and Argument use
Component______________________________________________________
+
+ Path: Mail All
+ Current-Folder: inbox Most
+ Editor: /usr/ucb/ex _c_o_m_p,
_d_i_s_t, _f_o_r_w, _r_e_p_l
+ Inbox: inbox _i_n_c, _r_m_f
+ Msg-Protect: 644 _i_n_c
+ Folder-Protect: 711 _i_n_c,
_p_i_c_k, _r_e_f_i_l_e
+ <program>: default switches All
+ prompter-next: ed _c_o_m_p,
_d_i_s_t, _f_o_r_w, _r_e_p_l
+
______________________________________________________
+
+
+ Path should______ be present. Current-Folder is
maintained automatically
+ by many _M_H commands (see the Context sections of the
individual commands
+ in Sec. IV). All other entries are optional, defaulting to
the values
+ described above.
+
+
+ _M_E_S_S_A_G_E _N_A_M_I_N_G
+
+ Messages may be referred to explicitly or implicitly
when using _M_H
+ commands. A formal syntax of message names is given in
Appendix B, but
+ the following description should be sufficient for most
_M_H users. Some
+ details of message naming that apply only to certain
commands are
+ included in the description of those commands.
+
+ Most of the _M_H commands accept arguments specifying
one or more
+ folders, and one or more messages to operate on. The use
of the word
+ "msg" as an argument to a command means that exactly one
message name
+ may be specified. A message name may be a number, such
as 1, 33, or
+ 234, or it may be one of the "reserved" message names:
first, last,
+ prev, next, and cur. (As a shorthand, a period (.) is
equivalent to
+ cur.) The meanings of these names are straightforward:
"first" is the
+ first message in the folder; "last" is the last message in
the folder;
+ "prev" is the message numerically previous to the
current message;
+ "next" is the message numerically following the current
message; "cur"
+ (or ".") is the current message in the folder. In addition,
_M_H supports
+ user-defined-sequences; see the description of the
_m_a_r_k command for more
+ information.
+
+ The default in commands that take a "msg" argument is
always "cur".
+
+ The word "msgs" indicates that several messages may be
specified.
+ Such a specification consists of several message
designations separated
+ by spaces. A message designation is either a message name or
a message
+
+
+
+
+
+
+
+
+
+
+
+ -14-
+
+
+ range. A message range is a specification of the form
name1-name2 or
+ name1:n, where name1 and name2 are message names and n is
an integer.
+ The first form designates all the messages from name1
to name2
+ inclusive; this must be a non-empty range. The second form
specifies up
+ to n messages, starting with name1 if name1 is a number, or
first, cur,
+ or next, and ending with name1 if name1 is last or prev.
This interpre-
+ tation of n is overridden if n is preceded by a plus sign
or a minus
+ sign; +n always means up to n messages starting with
name1, and -n
+ always means up to n messages ending with name1. Repeated
specifica-
+ tions of the same message have the same effect as a single
specification
+ of the message. Examples of specifications are:
+
+
+ 1 5 7-11 22
+ first 6 8 next
+ first-10
+ last:5
+
+
+ The message name "all" is a shorthand for "first-last",
indicating
+ all of the messages in the folder.
+
+ In commands that accept "msgs" arguments, the default is
either cur
+ or all, depending on which makes more sense.
+
+ In all of the _M_H commands, a plus sign preceding an
argument indi-
+ cates a folder name. Thus, "+inbox" is the name of the
user's standard
+ inbox. If an explicit folder argument is given to an
_M_H command, it
+ will become the current folder (that is, the
"Current-Folder:" entry in
+ the user's profile will be changed to this folder). In the
case of the
+ _r_e_f_i_l_e command, which can have multiple
output folders, a new source
+ folder (other than the default current folder) is
specified by
+ `-src +folder'.
+
+
+ _O_T_H_E_R _M_H _C_O_N_V_E_N_T_I_O_N_S
+
+ One very powerful feature of _M_H is that the _M_H
commands may be
+ issued from any current directory, and the proper path to
the appropri-
+ ate folder(s) will be taken from the user's profile. If the
_M_H path is
+ not appropriate for a specific folder or file, the automatic
prepending
+ of the _M_H path can be avoided by beginning a folder or
file name with /,
+ or with ./ or ../ component. Thus any specific absolute
path may be
+ specified along with any path relative to the current working
directory.
+
+ Arguments to the various programs may be given in any
order, with
+ the exception of a few switches whose arguments must follow
immediately,
+ such as `-src +folder' for _r_e_f_i_l_e.
+
+ Whenever an _M_H command prompts the user, the valid
options will be
+ listed in response to a <RETURN>. (The first of the listed
options is
+ the default if end-of-file is encountered, such as from a
command file.)
+
+
+
+
+
+
+
+
+
+
+
+ -15-
+
+
+ A valid response is any _u_n_i_q_u_e abbreviation
of one of the listed
+ options.
+
+ Standard UNIX documentation conventions are used in this
report to
+ describe _M_H command syntax. Arguments enclosed in
brackets ([ ]) are
+ optional; exactly one of the arguments enclosed within braces
({ }) must
+ be specified, and all other arguments are required. The use
of ellipsis
+ dots (...) indicates zero or more repetitions of the previous
item. For
+ example, "+folder ..." would indicate that one or more
"+folder" argu-
+ ments is required and "[+folder ...]" indicates that 0 or
more "+folder"
+ arguments may be given.
+
+ _M_H departs from UNIX standards by using switches
that consist of
+ more than one character, e.g. `-header'. To minimize
typing, only a
+ unique abbreviation of a switch need be typed; thus, for
`-header',
+ `-hea' is probably sufficient, depending on the other
switches the com-
+ mand accepts. Each _M_H program accepts the switch `-help'
(which must be
+ spelled out fully) and produces a syntax description
and a list of
+ switches. In the list of switches, parentheses indicate
required char-
+ acters. For example, all `-help' switches will appear as
"-(help)",
+ indicating that no abbreviation is accepted. Furthermore,
the `-help'
+ switch tells the version of the _M_H program you invoked.
+
+ Many _M_H switches have both on and off forms, such as
`-format' and
+ `-noformat'. In many of the descriptions which follow, only
one form is
+ defined; the other form, often used to nullify profile switch
settings,
+ is assumed to be the opposite.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -16-
+
+
+ _M_H _C_O_M_M_A_N_D_S
+
+ The _M_H package comprises several programs:
+
+ ali (1) - list mail aliases
+ anno (1) - annotate messages
+ bbc (1) - check on BBoards
+ bboards (1) - the UCI BBoards facility
+ burst (1) - explode digests into messages
+ comp (1) - compose a message
+ dist (1) - redistribute a message to additional
addresses
+ folder (1) - set/list current folder/message
+ folders (1) - list all folders
+ forw (1) - forward messages
+ inc (1) - incorporate new mail
+ mark (1) - mark messages
+ mhl (1) - produce formatted listings of MH
messages
+ mhmail (1) - send or read mail
+ mhook (1) - MH receive-mail hooks
+ mhparam (1) - print MH profile components
+ mhpath (1) - print full pathnames of MH messages and
folders
+ msgchk (1) - check for messages
+ msh (1) - MH shell (and BBoard reader)
+ next (1) - show the next message
+ packf (1) - compress a folder into a single file
+ pick (1) - select messages by content
+ prev (1) - show the previous message
+ prompter (1) - prompting editor front end
+ rcvstore (1) - incorporate new mail asynchronously
+ refile (1) - file messages in other folders
+ repl (1) - reply to a message
+ rmf (1) - remove folder
+ rmm (1) - remove messages
+ scan (1) - produce a one line per message scan
listing
+ send (1) - send a message
+ show (1) - show (list) messages
+ slocal (1) - special local mail delivery
+ sortm (1) - sort messages
+ vmh (1) - visual front-end to MH
+ whatnow (1) - prompting front-end for send
+ whom (1) - report to whom a message would go
+
+
+ These programs are described below. The form of the
descriptions
+ conforms to the standard form for the description of UNIX commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ALI(1) -17-
ALI(1)
+
+
+ _N_A_M_E
+ ali - list mail aliases
+
+ _S_Y_N_O_P_S_I_S
+ ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_l_i searches the named mail alias files for each of
the given
+ _a_l_i_a_s_e_s. It creates a list of addresses
for those _a_l_i_a_s_e_s, and
+ writes that list on standard output. If the `-list'
option is
+ specified, each address appears on a separate line;
otherwise, the
+ addresses are separated by commas and printed on as few
lines as
+ possible.
+
+ The `-user' option directs _a_l_i to perform its
processing in an
+ inverted fashion: instead of listing the addresses that each
given
+ alias expands to, _a_l_i will list the aliases that
expand to each
+ given address. If the `-normalize' switch is given,
_a_l_i will try
+ to track down the official hostname of the address.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read. Each _a_l_i_a_s is processed as described in
_m_h-_a_l_i_a_s (5).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /etc/passwd List of users
+ /etc/group List of groups
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-nolist'
+ `-nonormalize'
+ `-nouser'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ALI(1) -18-
ALI(1)
+
+
+ _B_u_g_s
+ The `-user' option with `-nonormalize' is not entirely
accurate, as
+ it does not replace local nicknames for hosts with their
official
+ site names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -19-
ANNO(1)
+
+
+ _N_A_M_E
+ anno - annotate messages
+
+ _S_Y_N_O_P_S_I_S
+ anno [+folder] [msgs] [-component field] [-inplace]
[-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_n_n_o annotates the specified messages in the named
folder using the
+ field and body. Annotation is optionally performed by
_d_i_s_t, _f_o_r_w,
+ and _r_e_p_l, to keep track of your distribution of,
forwarding of, and
+ replies to a message. By using _a_n_n_o, you can
perform arbitrary
+ annotations of your own. Each message selected will be
annotated
+ with the lines
+
+ field: date
+ field: body
+
+ The `-nodate' switch inhibits the date annotation, leaving
only the
+ body annotation. The `-inplace' switch causes annotation
to be
+ done in place in order to preserve links to the annotated
message.
+
+ The field specified should be a valid 822-style message field
name,
+ which means that it should consist of alphanumerics (or
dashes)
+ only. The body specified is arbitrary text.
+
+ If a `-component field' is not specified when _a_n_n_o is
invoked, _a_n_n_o
+ will prompt the user for the name of field for the annotation.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ dist (1), forw (1), repl (1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-date'
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ ANNO(1) -20-
ANNO(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message annotated will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -21-
BBC(1)
+
+
+ _N_A_M_E
+ bbc - check on BBoards
+
+ _S_Y_N_O_P_S_I_S
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet]
[-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c]
[-rcfile rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _b_b_c is a BBoard reading/checking program that
interfaces to the
+ BBoard channel.
+
+ The _b_b_c program has three action switches which direct
its opera-
+ tion:
+
+ The `-read' switch invokes the _m_s_h program on the
named _B_B_o_a_r_d_s.
+ If you also specify the `-archive' switch, then _b_b_c
will invoke
+ the _m_s_h program on the archives of the named
_B_B_o_a_r_d_s. If no
+ _B_B_o_a_r_d_s are given on the command line,
and you specified
+ `-archive', _b_b_c will not read your `bboards' profile
entry, but
+ will read the archives of the "system" _B_B_o_a_r_d
instead.
+
+ The `-check' switch types out status information for the
named
+ _B_B_o_a_r_d_s. _b_b_c can print one of several
messages depending on the
+ status of both the BBoard and the user's reading habits. As
with
+ each of these messages, the number given is the item number
of the
+ last item placed in the BBoard. This number (which is
marked in
+ the messages as the "BBoard-Id") is ever increasing.
Hence, when
+ _b_b_c says "n items", it really means that the highest
BBoard-Id is
+ "n". There may, or may not actually be "n" items in the
BBoard.
+ Some common messages are:
+
+ BBoard -- n items unseen
+ This message tells how many items the user has
not yet
+ seen. When invoked with the `-quiet' switch, this
is the
+ only informative line that _b_b_c will possibly
print out.
+
+ BBoard -- empty
+ The BBoard is empty.
+
+ BBoard -- n items (none seen)
+ The BBoard has items in it, but the user hasn't
seen any.
+
+ BBoard -- n items (all seen)
+ The BBoard is non-empty, and the user has seen
everything
+ in it.
+
+ BBoard -- n items seen out of m
+ The BBoard has at most m-n items that the user
has not
+ seen.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -22-
BBC(1)
+
+
+ The `-topics' switch directs _b_b_c to print three items
about the
+ named _B_B_o_a_r_d_s: it's official name, the number
of items present, and
+ the date and time of the last update. If no
_B_B_o_a_r_d_s are named,
+ then all BBoards are listed. If the `-verbose' switch is
given,
+ more information is output.
+
+ The `-quiet' switch specifies that _b_b_c should be
silent if no
+ _B_B_o_a_r_d_s are found with new information.
The `-verbose' switch
+ specifies that _b_b_c is to consider you to be interested
in _B_B_o_a_r_d_s
+ that you've already seen everything in.
+
+ To override the default _m_s_h_p_r_o_c and the
profile entry, use the
+ `-mshproc program' switch. Any arguments not understood by
_b_b_c are
+ passed to this program. The `-protocol' switch tells
_b_b_c that your
+ _m_s_h_p_r_o_c knows about the special _b_b_c
protocol for reporting back
+ information. _m_s_h (1), the default
_m_s_h_p_r_o_c, knows all about this.
+
+ The `-file BBoardsfile' switch tells _b_b_c to use a
non-standard
+ _B_B_o_a_r_d_s file when performing its
calculations. Similarly, the
+ `-user BBoardsuser' switch tells _b_b_c to use a
non-standard user-
+ name. Both of these switches are useful for debugging
a new
+ _B_B_o_a_r_d_s or _P_O_P file.
+
+ The ._b_b_r_c file in the user's $HOME directory is used
to keep track
+ of what messages have been read. The `-rcfile rcfile' switch
over-
+ rides the use of ._b_b_r_c for this purpose. If the
value given to the
+ switch is not absolute, (i.e., does not begin with a / ),
it will
+ be presumed to start from the current working directory. If
this
+ switch is not given (or the `-norcfile' switch is given),
then _b_b_c
+ consults the envariable $MHBBRC, and honors it similarly.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard "current" message
information
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+ _S_e_e _A_l_s_o
+ bbl(1), bboards(1), msh(1)
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBC(1) -23-
BBC(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-read'
+ `-noarchive'
+ `-protocol'
+ `bboards' defaults to "system"
+ `-file /usr/spool/bboards/BBoards'
+ `-user bboards'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The `-user' switch takes effect only if followed by the
`-file'
+ switch.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -24-
BBOARDS(1)
+
+
+ _N_A_M_E
+ bboards - the UCI BBoards facility
+
+ _S_Y_N_O_P_S_I_S
+ bbc [-check] [-read] bboards ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The home directory of _b_b_o_a_r_d_s is where the
BBoard system is kept.
+ This documentation describes some of the nuances of the
BBoard sys-
+ tem.
+
+ BBoards, BBoard-IDs
+ A BBoard is just a file containing a group of messages
relat-
+ ing to the same topic. These files live in the
~bboards home
+ directory. Each message in a BBoard file has in its
header
+ the line "BBoard-Id: n", where "n" is an ascending
decimal
+ number. This id-number is unique for each message
in a
+ BBoards file. It should NOT be confused with the
message
+ number of a message, which can change as messages are
removed
+ from the BBoard.
+
+ BBoard Handling
+ To read BBoards, use the _b_b_c and _m_s_h
programs. The _m_s_h com-
+ mand is a monolithic program which contains all the
func-
+ tionality of _M_H in a single program. The `-check'
switch to
+ _b_b_c lets you check on the status of BBoards, and
the `-read'
+ switch tells _b_b_c to invoke _m_s_h to read those
BBoards.
+
+ Creating a BBoard
+ Both public, and private BBoards are supported.
Contact the
+ mail address _P_o_s_t_M_a_s_t_e_r if you'd
like to have a BBoard
+ created.
+
+ BBoard addresses
+ Each BBoard has associated with it 4 addresses, these
are (for
+ the ficticious BBoard called ``hacks''):
+ hacks : The Internet wide distribution list.
+ dist-hacks : The local BBoard.
+ hacks-request : The people responsible for the BBoard
at the
+ Internet level.
+ local-hacks-request : The people responsible for the
BBoard
+ locally.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ $HOME/.bbrc BBoard information
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BBOARDS(1) -25-
BBOARDS(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ bboards: To specify interesting BBoards
+ mshproc: Program to read a given BBoard
+
+
+ _S_e_e _A_l_s_o
+ bbc(1), bbl(1), bbleader(1), msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ The default bboard is "system"
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BURST(1) -26-
BURST(1)
+
+
+ _N_A_M_E
+ burst - explode digests into messages
+
+ _S_Y_N_O_P_S_I_S
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet]
[-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _B_u_r_s_t considers the specified messages in the named
folder to be
+ Internet digests, and explodes them in that folder.
+
+ If `-inplace' is given, each digest is replaced by the
"table of
+ contents" for the digest (the original digest is removed).
_B_u_r_s_t
+ then renumbers all of the messages following the digest
in the
+ folder to make room for each of the messages contained
within the
+ digest. These messages are placed immediately after the
digest.
+
+ If `-noinplace' is given, each digest is preserved, no
table of
+ contents is produced, and the messages contained within the
digest
+ are placed at the end of the folder. Other messages are not
tam-
+ pered with in any way.
+
+ The `-quiet' switch directs _b_u_r_s_t to be silent
about reporting mes-
+ sages that are not in digest format.
+
+ The `-verbose' switch directs _b_u_r_s_t to tell the
user the general
+ actions that it is taking to explode the digest.
+
+ It turns out that _b_u_r_s_t works equally well on
forwarded messages
+ and blind-carbon-copies as on Internet digests, provided
that the
+ former two were generated by _f_o_r_w or _s_e_n_d.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new message
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ inc(1), msh(1), pack(1)
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ BURST(1) -27-
BURST(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noinplace'
+ `-noquiet'
+ `-noverbose'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. If
`-in-
+ place' is given, then the first message burst becomes the
current
+ message. This leaves the context ready for a _s_h_o_w of
the table of
+ contents of the digest, and a _n_e_x_t to see the first
message of the
+ digest. If `-noinplace' is given, then the first message
extracted
+ from the first digest burst becomes the current message.
This
+ leaves the context in a similar, but not identical, state
to the
+ context achieved when using `-inplace'.
+
+
+ _B_u_g_s
+ The _b_u_r_s_t program enforces a limit on the number of
messages which
+ may be _b_u_r_s_t from a single message. This number is
on the order of
+ 1000 messages. There is usually no limit on the number of
messages
+ which may reside in the folder after the _b_u_r_s_ting.
+
+ Although _b_u_r_s_t uses a sophisticated algorithm to
determine where
+ one encapsulated message ends and another begins, not all
digesti-
+ fying programs use an encapsulation algorithm. In
degenerate
+ cases, this usually results in _b_u_r_s_t finding an
encapsulation boun-
+ dary prematurely and splitting a single encapsulated message
into
+ two or more messages. These erroneous digestifying programs
should
+ be fixed.
+
+ Furthermore, any text which appears after the last
encapsulated
+ message is not placed in a seperate message by
_b_u_r_s_t. In the case
+ of digestified messages, this text is usally an "End of
digest"
+ string. As a result of this possibly un-friendly behavior
on the
+ part of _b_u_r_s_t, note that when the `-inplace' option
is used, this
+ trailing information is lost. In practice, this is not a
problem
+ since correspondents usually place remarks in text prior
to the
+ first encapsulated message, and this information is not lost.
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ COMP(1) -28-
COMP(1)
+
+
+ _N_A_M_E
+ comp - compose a message
+
+ _S_Y_N_O_P_S_I_S
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage
msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_m_p is used to create a new message to be mailed.
It copies a
+ message form to the draft being composed and then invokes an
editor
+ on the draft (unless `-noedit' is given, in which case the
initial
+ edit is suppressed).
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "components" exists in the user's MH
directory,
+ it will be used instead of this form. The file
specified by
+ `-form formfile' will be used if given. You may also start
_c_o_m_p
+ using the contents of an existing message as the form. If
you sup-
+ ply either a `+folder' or `msg' argument, that message will
be used
+ as the form. You may not supply both a `-form formfile'
and a
+ `+folder' or `msg' argument. The line of dashes or a blank
line
+ must be left between the header and the body of the message
for the
+ message to be identified properly when it is sent (see
_s_e_n_d (1)).
+ The switch `-use' directs _c_o_m_p to continue
editing an already
+ started message. That is, if a _c_o_m_p (or
_d_i_s_t, _r_e_p_l, or _f_o_r_w ) is
+ terminated without sending the draft, the draft can be edited
again
+ via "comp -use".
+
+ If the draft already exists, _c_o_m_p will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_c_o_m_p, leaving the
+ draft intact; replace will replace the existing draft
with the
+ appropriate form; list will display the draft; use will
use the
+ draft for further composition; and refile +folder will
file the
+ draft in the given folder, and give you a new draft
with the
+ appropriate form. (The `+folder' argument to refile is
required.)
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ The `-file file' switch says to use the named file as the
message
+ draft.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ COMP(1) -29-
COMP(1)
+
+
+ The `-editor editor' switch indicates the editor to use
for the
+ initial edit. Upon exiting from the editor, _c_o_m_p
will invoke the
+ _w_h_a_t_n_o_w program. See _w_h_a_t_n_o_w (1)
for a discussion of available
+ options. The invocation of this program can be inhibited by
using
+ the `-nowhatnowproc' switch. (In truth of fact, it is the
_w_h_a_t_n_o_w
+ program which starts the initial edit. Hence,
`-nowhatnowproc'
+ will prevent any edit from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/components The message skeleton
+ or <mh-dir>/components Rather than the standard
skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ dist(1), forw(1), repl(1), send(1), whatnow(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to the current message
+ `-nodraftfolder'
+ `-nouse'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _c_o_m_p uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _c_o_m_p won't run
+ it.
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -30-
DIST(1)
+
+
+ _N_A_M_E
+ dist - redistribute a message to additional addresses
+
+ _S_Y_N_O_P_S_I_S
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_i_s_t is similar to _f_o_r_w. It prepares the
specified message for
+ redistribution to addresses that (presumably) are not on the
origi-
+ nal address list.
+
+ The default message form contains the following elements:
+
+ Resent-To:
+ Resent-cc:
+
+ If the file named "distcomps" exists in the user's MH
directory, it
+ will be used instead of this form. In either case, the file
speci-
+ fied by `-form formfile' will be used if given. The form
used will
+ be prepended to the message being resent.
+
+ If the draft already exists, _d_i_s_t will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_d_i_s_t, leaving the
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ Only those addresses in "Resent-To:", "Resent-cc:",
and
+ "Resent-Bcc:" will be sent. Also, a "Resent-Fcc: folder"
will be
+ honored (see _s_e_n_d (1)). Note that with _d_i_s_t,
the draft should con-
+ tain only "Resent-xxx:" fields and no body. The headers
and the
+ body of the original message are copied to the draft when the
mes-
+ sage is sent. Use care in constructing the headers for the
redis-
+ tribution.
+
+ If the `-annotate' switch is given, the message being
distributed
+ will be annotated with the lines:
+
+ Resent: date
+ Resent: addrs
+
+ where each address list contains as many lines as required.
This
+ annotation will be done only if the message is sent
directly from
+ _d_i_s_t. If the message is not sent immediately from
_d_i_s_t, "comp
+ -use" may be used to re-edit and send the constructed
message, but
+ the annotations won't take place. The '-inplace' switch
causes
+ annotation to be done in place in order to preserve links
to the
+ annotated message.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -31-
DIST(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches. Note that while in the editor, the message being
resent
+ is available through a link named "@" (assuming the default
_w_h_a_t_-
+ _n_o_w_p_r_o_c ). In addition, the actual
pathname of the message is
+ stored in the envariable $editalt, and the pathname of the
folder
+ containing the message is stored in the envariable $mhfolder.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _d_i_s_t will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/distcomps The message skeleton
+ or <mh-dir>/distcomps Rather than the standard
skeleton
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ fileproc: Program to refile the message
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), forw(1), repl(1), send(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
mes-
+ sage distributed will become the current message.
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DIST(1) -32-
DIST(1)
+
+
+ _H_i_s_t_o_r_y
+ _D_i_s_t originally used headers of the form
"Distribute-xxx:" instead
+ of "Resent-xxx:". In order to conform with the ARPA Internet
stan-
+ dard, RFC-822, the "Resent-xxx:" form is now used.
_D_i_s_t will
+ recognize "Distribute-xxx:" type headers and automatically
convert
+ them to "Resent-xxx:".
+
+
+ _B_u_g_s
+ _D_i_s_t does not _r_i_g_o_r_o_u_s_l_y check
the message being distributed for
+ adherence to the transport standard, but _p_o_s_t called
by _s_e_n_d does.
+ The _p_o_s_t program will balk (and rightly so) at
poorly formatted
+ messages, and _d_i_s_t won't correct things for you.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _d_i_s_t uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _d_i_s_t won't run
+ it.
+
+ If your current working directory is not writable, the link
named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -33-
FOLDER(1)
+
+
+ _N_A_M_E
+ folder, folders - set/list current folder/message
+
+ _S_Y_N_O_P_S_I_S
+ folder [+folder] [msg] [-all] [-create] [-nocreate] [-print]
+ [-fast] [-nofast] [-header] [-noheader] [-recurse]
+ [-norecurse] [-total] [-nototal] [-list] [-nolist]
[-push]
+ [-pop] [-pack] [-nopack] [-verbose] [-noverbose] [-help]
+
+ folders
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Since the _M_H environment is the shell, it is easy to lose
track of
+ the current folder from day to day. When
_f_o_l_d_e_r is given the
+ `-print' switch (the default), _f_o_l_d_e_r will list
the current folder,
+ the number of messages in it, the range of the messages
(low-high),
+ and the current message within the folder, and will flag
extra
+ files if they exist. An example of this summary is:
+
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+
+ If a `+folder' and/or `msg' are specified, they will
become the
+ current folder and/or message. By comparison, when a
`+folder'
+ argument is given, this corresponds to a "cd" operation
in the
+ _s_h_e_l_l; when no `+folder' argument is given,
this corresponds
+ roughly to a "pwd" operation in the _s_h_e_l_l.
+
+ If the specified (or default) folder doesn't exist, the
default
+ action is to query the user as to whether the folder
should be
+ created; when standard input is not a tty, the answer to the
query
+ is assumed to be "yes".
+
+ Specifying `-create' will cause _f_o_l_d_e_r to
create new folders
+ without any query. (This is the easy way to create an empty
folder
+ for use later.) Specifying `-nocreate' will cause
_f_o_l_d_e_r to exit
+ without creating a non-existant folder.
+
+ _M_u_l_t_i_p_l_e _F_o_l_d_e_r_s
+
+ Specifying `-all' will produce a summary line for each
top-level
+ folder in the user's MH directory, sorted
alphabetically. (If
+ _f_o_l_d_e_r is invoked by a name ending with "s"
(e.g., _f_o_l_d_e_r_s ),
+ `-all' is assumed). Specifying `-recurse' with `-all'
will also
+ produce a line for all sub-folders. These folders are all
preceded
+ by the read-only folders, which occur as "atr-cur-" entries
in the
+ user's _M_H context. For example,
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -34-
FOLDER(1)
+
+
+ Folder # of messages ( range ) cur msg (other
files)
+ /fsd/rs/m/tacc has 35 messages ( 1- 35); cur= 23.
+ /rnd/phyl/Mail/EP has 82 messages ( 1-108); cur= 82.
+ ff has no messages.
+ inbox+ has 16 messages ( 3- 22); cur= 5.
+ mh has 76 messages ( 1- 76); cur= 70.
+ notes has 2 messages ( 1- 2); cur= 1.
+ ucom has 124 messages ( 1-124); cur= 6;
(others).
+ TOTAL= 339 messages in 7 folders
+
+ The "+" after inbox indicates that it is the current folder.
The
+ "(others)" indicates that the folder `ucom' has files which
aren't
+ messages. These files may either be sub-folders, or files
that
+ don't belong under the MH file naming scheme.
+
+ The header is output if either a `-all' or a `-header'
switch is
+ specified; it is suppressed by `-noheader'. A `-total'
switch will
+ produce only the summary line.
+
+ If `-fast' is given, only the folder name (or names in the
case of
+ `-all') will be listed. (This is faster because the
folders need
+ not be read.)
+
+ If a `+folder' is given along with the `-all' switch,
_f_o_l_d_e_r will,
+ in addition to setting the current folder, list the top-level
fold-
+ ers for the current folder (with `-norecurse') or list all
sub-
+ folders under the current folder recursively (with
`-recurse'). In
+ this case, if a `msg' is also supplied, it will become the
current
+ message of `+folder'.
+
+ The `-recurse' switch lists each folder recursively, so use
of this
+ option effectively defeats the speed enhancement of the
`-fast'
+ option, since each folder must be searched for
subfolders.
+ Nevertheless, the combination of these options is useful.
+
+
+ _C_o_m_p_a_c_t_i_n_g _a _F_o_l_d_e_r
+
+ The `-pack' switch will compress the message names in the
desig-
+ nated folders, removing holes in message numbering. The
`-verbose'
+ switch directs _f_o_l_d_e_r to tell the user the
general actions that it
+ is taking to compress the folder.
+
+
+ _T_h_e _F_o_l_d_e_r _S_t_a_c_k
+
+ The `-push' switch directs _f_o_l_d_e_r to push the
current folder onto
+ the _f_o_l_d_e_r-_s_t_a_c_k, and make the
`+folder' argument the current
+ folder. If `+folder' is not given, the current folder and
the top
+ of the _f_o_l_d_e_r-_s_t_a_c_k are exchanged.
This corresponds to the "pushd"
+ operation in the _C_S_h_e_l_l.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -35-
FOLDER(1)
+
+
+ The `-pop' switch directs _f_o_l_d_e_r to discard
the top of the
+ _f_o_l_d_e_r-_s_t_a_c_k, after setting the
current folder to that value. No
+ `+folder' argument is allowed. This corresponds to the
"popd"
+ operation in the _C_S_h_e_l_l. The `-push' switch and
the `-pop' switch
+ are mutually exclusive: the last occurrence of either one
overrides
+ any previous occurrence of the other. Both of these
switches also
+ set `-list' by default.
+
+ The `-list' switch directs _f_o_l_d_e_r to list the
contents of the
+ _f_o_l_d_e_r-_s_t_a_c_k. No `+folder' argument
is allowed. After a success-
+ ful `-push' or `-pop', the `-list' action is taken, unless a
`-nol-
+ ist' switch follows them on the command line. This
corresponds to
+ the "dirs" operation in the _C_S_h_e_l_l. The
`-push', `-pop', and
+ `-list' switches turn off `-print'.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ Folder-Stack: To determine the folder stack
+
+
+ _S_e_e _A_l_s_o
+ refile(1), mhpath(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to none
+ `-nofast'
+ `-noheader'
+ `-nototal'
+ `-nopack'
+ `-norecurse'
+ `-noverbose'
+ `-print' is the default if no `-list', `-push', or `-pop' is
specified
+ `-list' is the default if `-push', or `-pop' is specified
+
+
+ _C_o_n_t_e_x_t
+ If `+folder' and/or `msg' are given, they will become the
current
+ folder and/or message.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FOLDER(1) -36-
FOLDER(1)
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the `-fast' switch
prevented context
+ changes from occurring for the current folder. This is no
longer
+ the case: if `+folder' is given, then _f_o_l_d_e_r will
always change the
+ current folder to that.
+
+
+ _B_u_g_s
+ `-all' forces `-header' and `-total'.
+
+ There is no way to restore the default behavior (to ask the
user
+ whether to create a non-existant folder) after `-create' or
`-no-
+ create' is given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -37-
FORW(1)
+
+
+ _N_A_M_E
+ forw - forward messages
+
+ _S_Y_N_O_P_S_I_S
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace]
[-noinplace]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _F_o_r_w may be used to prepare a message containing
other messages.
+ It constructs the new message from the components
file or
+ `-form formfile' (see _c_o_m_p ), with a body
composed of the
+ message(s) to be forwarded. An editor is invoked as in
_c_o_m_p, and
+ after editing is complete, the user is prompted before the
message
+ is sent.
+
+ The default message form contains the following elements:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ If the file named "forwcomps" exists in the user's MH
directory, it
+ will be used instead of this form. In either case, the file
speci-
+ fied by `-form formfile' will be used if given.
+
+ If the draft already exists, _f_o_r_w will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_f_o_r_w, leaving the
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ If the `-annotate' switch is given, each message being
forwarded
+ will be annotated with the lines
+
+ Forwarded: date
+ Forwarded: addrs
+
+ where each address list contains as many lines as required.
This
+ annotation will be done only if the message is sent
directly from
+ _f_o_r_w. If the message is not sent immediately
from _f_o_r_w,
+ "comp -use" may be used to re-edit and send the
constructed mes-
+ sage, but the annotations won't take place. The '-inplace'
switch
+ causes annotation to be done in place in order to preserve
links to
+ the annotated message.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -38-
FORW(1)
+
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches.
+
+ Although _f_o_r_w uses the `-form formfile' switch to
direct it how to
+ construct the beginning of the draft, the `-filter
filterfile',
+ `-format', and `-noformat' switches direct _f_o_r_w as to
how each for-
+ warded message should be formatted in the body of the
draft. If
+ `-noformat' is specified, then each forwarded message is
output
+ exactly as it appears. If `-format' or `-filter
filterfile' is
+ specified, then each forwarded message is filtered
(re-formatted)
+ prior to being output to the body of the draft. The
filter file
+ for _f_o_r_w should be a standard form file for
_m_h_l, as _f_o_r_w will
+ invoke _m_h_l to format the forwarded messages. The
default message
+ filter (what you get with `-format') is:
+
+ width=80,overflowtext=,overflowoffset=10
+ leftadjust,compress,compwidth=9
+
Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ To:
+ cc:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+ If the file named "mhl.forward" exists in the user's MH
directory,
+ it will be used instead of this form. In either case,
the file
+ specified by `-filter filterfile' will be used if given. To
sum-
+ marize: `-noformat' will reproduce each forwarded message
exactly,
+ `-format' will use _m_h_l and a default filterfile,
"mhl.forward", to
+ format each forwarded message, and `-filter filterfile'
will use
+ the named filterfile to format each forwarded message with
_m_h_l.
+
+ Each forwarded message is separated with an encapsulation
delimiter
+ and dashes in the first column of the forwarded messages
will be
+ prepended with `- ' so that when received, the message is
suitable
+ for bursting by _b_u_r_s_t (1). This follows the
Internet RFC-934
+ guidelines.
+
+ For users of _p_r_o_m_p_t_e_r (1), by specifying
prompter's `-prepend'
+ switch in the .mh_profile file, any commentary text is
entered
+ before the forwarded messages. (A major win!)
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _f_o_r_w will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -39-
FORW(1)
+
+
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ The `-digest list', `-issue number', and `-volume number'
switches
+ implement a digest facility for _M_H. Specifying
these switches
+ enables and/or overloads the following escapes:
+
+ _T_y_p_e _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _c_o_m_p_o_n_e_n_t _d_i_g_e_s_t string
Argument to `-digest'
+ _f_u_n_c_t_i_o_n _c_u_r integer Argument to
`-volume'
+ _f_u_n_c_t_i_o_n _m_s_g integer Argument to
`-issue'
+
+ Consult the Advanced Features section of the _M_H User's
Manual for
+ more information on making digests.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/forwcomps The message skeleton
+ or <mh-dir>/forwcomps Rather than the standard
skeleton
+ /usr/local/lib/mh/digestcomps The message skeleton if
`-digest' is given
+ or <mh-dir>/digestcomps Rather than the standard
skeleton
+ /usr/local/lib/mh/mhl.forward The message filter
+ or <mh-dir>/mhl.forward Rather than the standard
filter
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter messages being
forwarded
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r
_M_e_s_s_a_g_e _E_n_c_a_p_s_u_l_a_t_i_o_n (aka RFC-934),
+ comp(1), dist(1), repl(1), send(1), whatnow(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-noannotate'
+ `-nodraftfolder'
+ `-noformat'
+ `-noinplace'
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FORW(1) -40-
FORW(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message forwarded will become the current message.
+
+
+ _B_u_g_s
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _f_o_r_w uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _f_o_r_w won't run
+ it.
+
+ When _f_o_r_w is told to annotate the messages it
forwards, it doesn't
+ actually annotate them until the draft is successfully
sent. If
+ from the _w_h_a_t_n_o_w_p_r_o_c, you _p_u_s_h
instead of _s_e_n_d, it's possible to
+ confuse _f_o_r_w by re-ordering the file
(e.g., by using
+ `folder -pack') before the message is successfully sent.
_D_i_s_t and
+ _r_e_p_l don't have this problem.
+
+ To avoid prepending the leading dash characters in forwarded
mes-
+ sages, there is a `-nodashmunging' option. See the
"Hidden
+ Features" section of the _M_H
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -41-
INC(1)
+
+
+ _N_A_M_E
+ inc - incorporate new mail
+
+ _S_Y_N_O_P_S_I_S
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-form formatfile] [-format string]
+ [-file name] [-silent] [-nosilent] [-truncate]
[-notruncate]
+ [-width columns] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _I_n_c incorporates mail from the user's incoming mail
drop into an _M_H
+ folder. If `+folder' isn't specified, a folder in the
user's _M_H
+ directory will be used, either that specified by the "Inbox:"
entry
+ in the user's profile, or the folder named "inbox". The
new mes-
+ sages being incorporated are assigned numbers starting
with the
+ next highest number in the folder. If the specified (or
default)
+ folder doesn't exist, the user will be queried prior to its
crea-
+ tion. As the messages are processed, a _s_c_a_n
listing of the new
+ mail is produced.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it
will
+ be used as the protection on the newly created messages,
otherwise
+ the _M_H default of 0644 will be used. During all
operations on mes-
+ sages, this initially assigned protection will be
preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a
protection on an
+ individual message, and its protection will be
preserved
+ thereafter.
+
+ If the switch `-audit audit-file' is specified (usually
as a
+ default switch in the profile), then _i_n_c will append a
header line
+ and a line per message to the end of the specified audit-file
with
+ the format:
+
+ <<inc>> date
+ <scan line for first message>
+ <scan line for second message>
+ <etc.>
+
+ This is useful for keeping track of volume and source of
incoming
+ mail. Eventually, _r_e_p_l, _f_o_r_w,
_c_o_m_p, and _d_i_s_t may also produce
+ audits to this (or another) file, perhaps with "Message-Id:"
infor-
+ mation to keep an exact correspondence history.
"Audit-file" will
+ be in the user's MH directory unless a full path is specified.
+
+ _I_n_c will incorporate even improperly formatted
messages into the
+ user's MH folder, inserting a blank line prior to the
offending
+ component and printing a comment identifying the bad message.
+
+ In all cases, the user's mail drop will be zeroed,
unless the
+ `-notruncate' switch is given.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -42-
INC(1)
+
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+ then _i_n_c will add each of the newly incorporated
messages to each
+ sequence named by the profile entry. This is similar
to the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments. Note that _i_n_c
will not zero
+ each sequence prior to adding messages.
+
+ The interpretation of the `-form formatfile', `-format
string', and
+ `-width columns' switches is the same as in _s_c_a_n (1).
+
+ By using the `-file name' switch, one can direct _i_n_c to
incorporate
+ messages from a file other than the user's maildrop. Note
that the
+ name file will NOT be zeroed, unless the `-truncate'
switch is
+ given.
+
+ If the envariable $MAILDROP is set, then _i_n_c uses it as
the loca-
+ tion of the user's maildrop instead of the default
(the `-
+ file name' switch still overrides this, however). If this
envari-
+ able is not set, then _i_n_c will consult the profile
entry "MailDrop"
+ for this information. If the value found is not absolute,
then it
+ is interpreted relative to the user's _M_H directory. If
the value
+ is not found, then _i_n_c will look in the standard
system location
+ for the user's maildrop.
+
+ The `-silent' switch directs _i_n_c to be quiet and not
ask any ques-
+ tions at all. This is useful for putting _i_n_c in the
background and
+ going on to other things.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Inbox: To determine the inbox, default "inbox"
+ Folder-Protect: To set mode when creating a new folder
+ Msg-Protect: To set mode when creating a new
message and
+ audit-file
+ Unseen-Sequence: To name sequences denoting unseen
messages
+
+
+ _S_e_e _A_l_s_o
+ mhmail(1), scan(1), mh-mail(5), post(8)
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INC(1) -43-
INC(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaulted by "Inbox" above
+ `-noaudit'
+ `-changecur'
+ `-format' defaulted as described above
+ `-nosilent'
+ `-truncate' if `-file name' not given, `-notruncate' otherwise
+ `-width' defaulted to the width of the terminal
+
+
+ _C_o_n_t_e_x_t
+ The folder into which messages are being incorporated will
become
+ the current folder. The first message incorporated will
become the
+ current message, unless the `-nochangecur' option is
specified.
+ This leaves the context ready for a _s_h_o_w of the first
new message.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _i_n_c. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -44-
MARK(1)
+
+
+ _N_A_M_E
+ mark - mark messages
+
+ _S_Y_N_O_P_S_I_S
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete]
[-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_a_r_k command manipulates message sequences by
adding or delet-
+ ing message numbers from folder-specific message sequences,
or by
+ listing those sequences and messages. A message sequence is
a key-
+ word, just like one of the "reserved" message names,
such as
+ "first" or "next". Unlike the "reserved" message names,
which have
+ a fixed semantics on a per-folder basis, the semantics of a
message
+ sequence may be defined, modified, and removed by the user.
Mes-
+ sage sequences are folder-specific, e.g., the sequence name
"seen"
+ in the context of folder "+inbox" need not have any relation
what-
+ soever to the sequence of the same name in a folder of a
different
+ name.
+
+ Three action switches direct the operation of _m_a_r_k.
These switches
+ are mutually exclusive: the last occurrence of any of them
over-
+ rides any previous occurrence of the other two.
+
+ The `-add' switch tells _m_a_r_k to add messages to
sequences or to
+ create a new sequence. For each sequence named
via the
+ `-sequence name' argument (which must occur at least once)
the mes-
+ sages named via `msgs' (which defaults to "cur" if no
`msgs' are
+ given), are added to the sequence. The messages to be added
need
+ not be absent from the sequence. If the `-zero' switch is
speci-
+ fied, the sequence will be emptied prior to adding the
messages.
+ Hence, `-add -zero' means that each sequence should be
initialized
+ to the indicated messages, while `-add -nozero' means that
each
+ sequence should be appended to by the indicated messages.
+
+ The `-delete' switch tells _m_a_r_k to delete messages
from sequences,
+ and is the dual of `-add'. For each of the named
sequences, the
+ named messages are removed from the sequence. These messages
need
+ not be already present in the sequence. If the `-zero'
switch is
+ specified, then all messages in the folder are appended
to the
+ sequence prior to removing the messages. Hence, `-delete
-zero'
+ means that each sequence should contain all messages except
those
+ indicated, while `-delete -nozero' means that only the
indicated
+ messages should be removed from each sequence. As
expected, the
+ command `mark -sequence seen -delete all' deletes the
sequence
+ "seen" from the current folder.
+
+ When creating (or modifying) a sequence, the `-public' switch
indi-
+ cates that the sequence should be made readable for other
_M_H users.
+ In contrast, the `-nopublic' switch indicates that the
sequence
+ should be private to the user's _M_H environment.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -45-
MARK(1)
+
+
+ The `-list' switch tells _m_a_r_k to list both the
sequences defined
+ for the folder and the messages associated with those
sequences.
+ _M_a_r_k will list the name of each sequence given by
`-sequence name'
+ and the messages associated with that sequence. If
`-sequence'
+ isn't used, all sequences will be listed, with private
sequences
+ being so indicated. The `-zero' switch does not affect the
opera-
+ tion of `-list'.
+
+ The current restrictions on sequences are:
+
+ The name used to denote a message sequence must consist
of an
+ alphabetic character followed by zero or more alphanumeric
char-
+ acters, and cannot be one of the (reserved) message names
"new",
+ "first", "last", "all", "next", or "prev".
+
+ Only a certain number of sequences may be defined for a
given
+ folder. This number is usually limited to 26 (10 on
small sys-
+ tems).
+
+ Message ranges with user-defined sequence names are
restricted to
+ the form "name:n" or "name:-n", and refer to the first
or last
+ `n' messages of the sequence `name', respectively.
Constructs of
+ the form "name1-name2" are forbidden.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ pick (1), mh-sequence (5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-add' if `-sequence' is specified, `-list' otherwise
+ `msgs' defaults to cur (or all if `-list' is specified)
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ Use "pick sequence -list" to enumerate the messages in a
sequence
+ (such as for use by a shell script).
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MARK(1) -46-
MARK(1)
+
+
+ _N_A_M_E
+ mhl - produce formatted listings of MH messages
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc]
[files ...]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_l is a formatted message listing program. It can be
used as a
+ replacement for _m_o_r_e (1) (the default
_s_h_o_w_p_r_o_c ). As with _m_o_r_e,
+ each of the messages specified as arguments (or the standard
input)
+ will be output. If more than one message file is
specified, the
+ user will be prompted prior to each one, and a <RETURN> or
<EOT>
+ will begin the output, with <RETURN> clearing the
screen (if
+ appropriate), and <EOT> (usually CTRL-D) suppressing the
screen
+ clear. An <INTERRUPT> (usually CTRL-C) will abort the
current mes-
+ sage output, prompting for the next message (if there is
one), and
+ a <QUIT> (usually CTRL-\) will terminate the program
(without core
+ dump).
+
+ The `-bell' option tells _m_h_l to ring the terminal's
bell at the end
+ of each page, while the `-clear' option tells _m_h_l
to clear the
+ scree at the end of each page (or output a formfeed after
each mes-
+ sage). Both of these switches (and their inverse
counterparts)
+ take effect only if the profile entry
_m_o_r_e_p_r_o_c is defined but
+ empty, and _m_h_l is outputting to a terminal. If the
_m_o_r_e_p_r_o_c entry
+ is defined and non-empty, and _m_h_l is outputting to a
terminal, then
+ _m_h_l will cause the _m_o_r_e_p_r_o_c to be
placed between the terminal and
+ _m_h_l and the switches are ignored. Furthermore, if
the `-clear'
+ switch is used and _m_h_l'_s output is directed to a
terminal, then _m_h_l
+ will consult the $TERM and $TERMCAP envariables to
determine the
+ user's terminal type in order to find out how to clear the
screen.
+ If the `-clear' switch is used and _m_h_l'_s output is
not directed to
+ a terminal (e.g., a pipe or a file), then _m_h_l will
send a formfeed
+ after each message.
+
+ To override the default _m_o_r_e_p_r_o_c and the
profile entry, use the
+ `-moreproc program' switch. Note that _m_h_l will
never start a
+ _m_o_r_e_p_r_o_c if invoked on a hardcopy terminal.
+
+ The `-length length' and `-width width' switches set the
screen
+ length and width, respectively. These default to the values
indi-
+ cated by $TERMCAP, if appropriate, otherwise they default to
40 and
+ 80, respectively.
+
+ The default format file used by _m_h_l is called
_m_h_l._f_o_r_m_a_t (which is
+ first searched for in the user's _M_H directory, and then
sought in
+ the /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h directory),
this can be changed by using the
+ `-form formatfile' switch.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -47-
MHL(1)
+
+
+ Finally, the `-folder +folder' switch sets the _M_H
folder name,
+ which is used for the "messagename:" field described
below. The
+ envariable $mhfolder is consulted for the default value,
which
+ _s_h_o_w, _n_e_x_t, and _p_r_e_v initialize
appropriately.
+
+ _M_h_l operates in two phases: 1) read and parse the
format file, and
+ 2) process each message (file). During phase 1, an
internal
+ description of the format is produced as a structured
list. In
+ phase 2, this list is walked for each message, outputting
message
+ information under the format constraints from the format file.
+
+ The "mhl.format" form file contains information controlling
screen
+ clearing, screen size, wrap-around control, transparent
text, com-
+ ponent ordering, and component formatting. Also, a list of
com-
+ ponents to ignore may be specified, and a couple of
"special" com-
+ ponents are defined to provide added functionality. Message
output
+ will be in the order specified by the order in the format
file.
+
+ Each line of mhl.format has one of the formats:
+
+ ;comment
+ :cleartext
+ variable[,variable...]
+ component:[variable,...]
+
+ A line beginning with a `;' is a comment, and is ignored. A
line
+ beginning with a `:' is clear text, and is output exactly as
is. A
+ line containing only a `:' produces a blank line in the
output. A
+ line beginning with "component:" defines the format for the
speci-
+ fied component, and finally, remaining lines define the
global
+ environment.
+
+ For example, the line:
+
+
width=80,length=40,clearscreen,overflowtext="***",overflowoffset=5
+
+ defines the screen size to be 80 columns by 40 rows,
specifies that
+ the screen should be cleared prior to each page, that the
overflow
+ indentation is 5, and that overflow text should be
flagged with
+ "***".
+
+ Following are all of the current variables and their
arguments. If
+ they follow a component, they apply only to that component,
other-
+ wise, their affect is global. Since the whole format is
parsed
+ before any output processing, the last global switch setting
for a
+ variable applies to the whole message if that variable is
used in a
+ global context (i.e., bell, clearscreen, width, length).
+
+ _v_a_r_i_a_b_l_e _t_y_p_e
_s_e_m_a_n_t_i_c_s
+ width integer screen width or component width
+ length integer screen length or component
length
+ offset integer positions to indent
"component: "
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -48-
MHL(1)
+
+
+ overflowtext string text to use at the beginning
of an
+ overflow line
+ overflowoffset integer positions to indent overflow
lines
+ compwidth integer positions to indent component
text
+ after the first line is output
+ uppercase flag output text of this component
in all
+ upper case
+ nouppercase flag don't uppercase
+ clearscreen flag/G clear the screen prior to each
page
+ noclearscreen flag/G don't clearscreen
+ bell flag/G ring the bell at the end of
each page
+ nobell flag/G don't bell
+ component string/L name to use instead of
"component" for
+ this component
+ nocomponent flag don't output "component: " for
this
+ component
+ center flag center component on line
(works for
+ one-line components only)
+ nocenter flag don't center
+ leftadjust flag strip off leading whitespace
on each
+ line of text
+ noleftadjust flag don't leftadjust
+ compress flag change newlines in text to
spaces
+ nocompress flag don't compress
+ split flag don't combine multiple fields
into a single field
+ nosplit flag combine multiple fields into a
single field
+ newline flag print newline at end of
components (default)
+ nonewline flag don't print newline at end of
components
+ formatfield string format string for this
component (see below)
+ addrfield flag field contains addresses
+ datefield flag field contains dates
+
+ To specify the value of integer-valued and string-valued
variables,
+ follow their name with an equals-sign and the
value.
+ Integer-valued variables are given decimal values,
while
+ string-valued variables are given arbitrary text
bracketed by
+ double-quotes. If a value is suffixed by "/G" or "/L",
then its
+ value is useful in a global-only or local-only context
(respec-
+ tively).
+
+ A line of the form:
+
+ ignores=component,...
+
+ specifies a list of components which are never output.
+
+ The component "MessageName" (case-insensitive) will
output the
+ actual message name (file name) preceded by the folder name
if one
+ is specified or found in the environment. The format is
identical
+ to that produced by the `-header' option to _s_h_o_w.
+
+ The component "Extras" will output all of the components
of the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -49-
MHL(1)
+
+
+ message which were not matched by explicit components, or
included
+ in the ignore list. If this component is not specified, an
ignore
+ list is not needed since all non-specified components
will be
+ ignored.
+
+ If "nocomponent" is NOT specified, then the component name
will be
+ output as it appears in the format file.
+
+ The default format is:
+
+ : -- using template mhl.format --
+ overflowtext="***",overflowoffset=5
+ leftadjust,compwidth=9
+ ignores=msgid,message-id,received
+
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
+ To:
+ cc:
+ :
+ From:
+ Subject:
+ :
+ extras:nocomponent
+ :
+
body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
+
+ The variable "formatfield" specifies a format string
(see
+ _m_h-_f_o_r_m_a_t (5)). The flag variables
"addrfield" and "datefield"
+ (which are mutually exclusive), tell _m_h_l to interpret
the escapes
+ in the format string as either addresses or dates,
respectively.
+
+ By default, _m_h_l does not apply any formatting string to
fields con-
+ taining address or dates (see _m_h-_m_a_i_l (5)
for a list of these
+ fields). Note that this results in faster operation since
_m_h_l must
+ parse both addresses and dates in order to apply a format
string to
+ them. If desired, _m_h_l can be given a default format
string for
+ either address or date fields (but not both). To do
this, on a
+ global line specify: either the flag addrfield or datefield,
along
+ with the apropriate formatfield variable string.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mhl.format The message template
+ or <mh-dir>/mhl.format Rather than the standard
template
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ moreproc: Program to use as interactive front-end
+
+
+ _S_e_e _A_l_s_o
+ show(1), ap(8), dp(8)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHL(1) -50-
MHL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-bell'
+ `-noclear'
+ `-length 40'
+ `-width 80'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ There should be some way to pass `bell' and `clear'
information to
+ the front-end.
+
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+ The "nonewline" option interacts badly with "compress" and
"split".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -51-
MHMAIL(1)
+
+
+ _N_A_M_E
+ mhmail - send or read mail
+
+ _S_Y_N_O_P_S_I_S
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H_m_a_i_l is intended as a replacement for the
standard Bell mail pro-
+ gram (_b_e_l_l_m_a_i_l (1)), compatible with
_M_H. When invoked without
+ arguments, it simply invokes _i_n_c (1) to incorporate
new messages
+ from the user's maildrop. When one or more users is
specified, a
+ message is read from the standard input and spooled to a
temporary
+ file. _M_H_m_a_i_l then invokes _p_o_s_t (8) with
the name of the temporary
+ file as its argument to deliver the message to the specified
user.
+
+ The `-subject subject' switch can be used to specify the
"Subject:"
+ field of the message. The `-body text' switch can be
used to
+ specify the text of the message; if it is specified, then the
stan-
+ dard input is not read. Normally, addresses appearing as
arguments
+ are put in the "To:" field. If the `-cc' switch is
used, all
+ addresses following it are placed in the "cc:" field.
+
+ By using `-from addr', you can specify the "From:" header
of the
+ draft. Naturally, _p_o_s_t will fill-in the
"Sender:" header
+ correctly.
+
+ This program is intended for the use of programs such as
_a_t (1),
+ which expect to send mail automatically to various users.
Nor-
+ mally, real people (as opposed to the "unreal" ones) will
prefer to
+ use _c_o_m_p (1) and _s_e_n_d (1) to send messages.
+
+ _F_i_l_e_s
+ /usr/local/inc Program to incorporate a
maildrop into a folder
+ /usr/local/lib/mh/post Program to deliver a
message
+ /tmp/mhmail* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ inc(1), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHMAIL(1) -52-
MHMAIL(1)
+
+
+ _C_o_n_t_e_x_t
+ If _i_n_c is invoked, then _i_n_c's context changes
occur.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -53-
MHOOK(1)
+
+
+ _N_A_M_E
+ mhook, rcvdist, rcvpack, rcvtty - MH receive-mail hooks
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/rcvdist [-form formfile] [switches for
_p_o_s_t_p_r_o_c]
+ address ... [-help]
+
+ /usr/local/lib/mh/rcvpack file [-help]
+
+ /usr/local/lib/mh/rcvtty [command] [-form formatfile]
+ [-format string] [-bell] [-nobell] [-newline]
[-nonewline]
+ [-biff] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ A receive-mail hook is a program that is run whenever you
receive a
+ mail message. You do NOT invoke the hook yourself, rather
the hook
+ is invoked on your behalf by your system's Message Transport
Agent.
+ See _s_l_o_c_a_l (1) for details on how to activate
receive-mail hooks on
+ your system.
+
+ Four programs are currently available as part of
_M_H, _r_c_v_d_i_s_t
+ (redistribute incoming messages to additional recipients),
_r_c_v_p_a_c_k
+ (save incoming messages in a _p_a_c_k_f'd file), and
_r_c_v_t_t_y (notify user
+ of incoming messages). The fourth program,
_r_c_v_s_t_o_r_e (1) is
+ described separately. They all reside in the
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/
+ directory.
+
+ The _r_c_v_d_i_s_t program will resend a copy of the
message to all of the
+ addresses listed on its command line. It uses the format
string
+ facility described in _m_h-_f_o_r_m_a_t (5).
+
+ The _r_c_v_p_a_c_k program will append a copy of the
message to the file
+ listed on its command line. Its use is obsoleted by the
"file"
+ action of _s_l_o_c_a_l.
+
+ The _r_c_v_t_t_y program executes the named file with
the message as its
+ standard input, and writes the resulting output on your
terminal.
+
+ If no file is specified, or is bogus, etc., then
_r_c_v_t_t_y will
+ instead write a one-line scan listing. Either
the
+ `-form formatfile' or `-format string' option may be used to
over-
+ ride the default output format (see
_m_h-_f_o_r_m_a_t (5)). A newline is
+ output before the message output, and the terminal bell is
rung
+ after the output. The `-nonewline' and `-nobell'
options will
+ inhibit these functions.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _r_c_v_t_t_y also
+ recognizes the following additional
_c_o_m_p_o_n_e_n_t escapes:
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHOOK(1) -54-
MHOOK(1)
+
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ body string the (compressed) first part of the body
+ dtimenow date the current date
+ folder string the name of the current folder
+
+ Normally, _r_c_v_t_t_y obeys write permission as
granted by _m_e_s_g (1).
+ With the `-biff' option, _r_c_v_t_t_y will obey the
notification status
+ set by _b_i_f_f (1) instead. If the terminal access
daemon (TTYD) is
+ available on your system, then _r_c_v_t_t_y will give
its output to the
+ daemon for output instead of writing on the user's terminal.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ $HOME/.maildelivery The file controlling
local delivery
+ /usr/local/lib/mh/maildelivery Rather than the standard
file
+
+
+ _S_e_e _A_l_s_o
+ rcvstore (1), mh-format(5), slocal(1)
+
+
+ _B_u_g_s
+ Only two return codes are meaningful, others should be.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPARAM(1) -55-
MHPARAM(1)
+
+
+ _N_A_M_E
+ mhparam - print MH profile components
+
+ _S_Y_N_O_P_S_I_S
+ mhparam [components] [-all] [-component] [-nocomponent]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_p_a_r_a_m writes the value of the specified
profile component to the
+ standard output separated by newlines. If the profile
component is
+ not present, the default value (or nothing if there is no
default)
+ is printed.
+
+ If more than one component is specified in the `components'
list,
+ the component value is preceded by the component name. If
`-com-
+ ponent' is specified, the component name is displayed even
when
+ only one component is specified. If `-nocomponent' is
specified,
+ the component name is not displayed even when more than one
com-
+ ponent is specified.
+
+ If `-all' is specified, all components if the MH
profile are
+ displayed and other arguments are ignored.
+
+ Examples:
+
+ % mhparam path
+ Mail
+
+ % mhparam mhlproc
+ /usr/local/lib/mh/mhl
+
+ % mhparam -component path
+ Path: Mail
+
+ % mhparam AliasFile rmmproc
+ AliasFile: aliases
+ rmmproc: rmmproc
+
+ % mhparam -nocomponent AliasFile rmmproc
+ aliases
+ rmmproc
+
+ _M_h_p_a_r_a_m is also useful in back-quoted
operations:
+
+ % fgrep cornell.edu `mhpath +`/`mhparam aliasfile`
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPARAM(1) -56-
MHPARAM(1)
+
+
+ _S_e_e _A_l_s_o
+ mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-nocomponent' if only one component is specified
+ `-component' if more than one component is specified
+ `components' defaults to none
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -57-
MHPATH(1)
+
+
+ _N_A_M_E
+ mhpath - print full pathnames of MH messages and folders
+
+ _S_Y_N_O_P_S_I_S
+ mhpath [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_h_p_a_t_h expands and sorts the message list `msgs'
and writes the
+ full pathnames of the messages to the standard output
separated by
+ newlines. If no `msgs' are specified, _m_h_p_a_t_h
outputs the folder
+ pathname instead. If the only argument is `+', your MH
_P_a_t_h is
+ output; this can be useful is shell scripts.
+
+ Contrasted with other MH commands, a message argument to
_m_h_p_a_t_h may
+ often be intended for _w_r_i_t_i_n_g. Because of this:
+
+ 1) the name "new" has been added to _m_h_p_a_t_h's list
of reserved mes-
+ sage names (the others are "first", "last", "prev", "next",
"cur",
+ and "all"). The new message is equivalent to the message
after the
+ last message in a folder (and equivalent to 1 in a folder
without
+ messages). The "new" message may not be used as part of a
message
+ range.
+
+ 2) Within a message list, the following designations may
refer to
+ messages that do not exist: a single numeric message name,
the sin-
+ gle message name "cur", and (obviously) the single message
name
+ "new". All other message designations must refer to at
least one
+ existing message.
+
+ 3) An empty folder is not in itself an error.
+
+ Message numbers greater than the highest existing message
in a
+ folder as part of a range designation are replaced with
the next
+ free message number.
+
+ Examples: The current folder foo contains messages 3 5 6.
Cur is
+ 4.
+
+ % mhpath
+ /r/phyl/Mail/foo
+
+ % mhpath all
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath 2001
+ /r/phyl/Mail/foo/7
+
+ % mhpath 1-2001
+ /r/phyl/Mail/foo/3
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -58-
MHPATH(1)
+
+
+ /r/phyl/Mail/foo/5
+ /r/phyl/Mail/foo/6
+
+ % mhpath new
+ /r/phyl/Mail/foo/7
+
+ % mhpath last new
+ /r/phyl/Mail/foo/6
+ /r/phyl/Mail/foo/7
+
+ % mhpath last-new
+ bad message list "last-new".
+
+ % mhpath cur
+ /r/phyl/Mail/foo/4
+
+ % mhpath 1-2
+ no messages in range "1-2".
+
+ % mhpath first:2
+ /r/phyl/Mail/foo/3
+ /r/phyl/Mail/foo/5
+
+ % mhpath 1 2
+ /r/phyl/Mail/foo/1
+ /r/phyl/Mail/foo/2
+
+ _M_H_p_a_t_h is also useful in back-quoted operations:
+
+ % cd `mhpath +inbox`
+
+ % echo `mhpath +`
+ /r/phyl/Mail
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to none
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MHPATH(1) -59-
MHPATH(1)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Like all MH commands, _m_h_p_a_t_h expands and sorts
[msgs]. So don't
+ expect
+
+ mv `mhpath 501 500`
+
+ to move 501 to 500. Quite the reverse. But
+
+ mv `mhpath 501` `mhpath 500`
+
+ will do the trick.
+
+ Out of range message 0 is treated far more severely than
large out
+ of range message numbers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -60-
MSGCHK(1)
+
+
+ _N_A_M_E
+ msgchk - check for messages
+
+ _S_Y_N_O_P_S_I_S
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [users ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ The _m_s_g_c_h_k program checks all known mail drops
for mail waiting for
+ you. For those drops which have mail for you,
_m_s_g_c_h_k will indicate
+ if it believes that you have seen the mail in question before.
+
+ The `-notify type' switch indicates under what circumstances
_m_s_g_c_h_k
+ should produce a message. The default is `-notify all'
which says
+ that _m_s_g_c_h_k should always report the status of
the users maildrop.
+ Other values for `type' include `mail' which says that
_m_s_g_c_h_k
+ should report the status of waiting mail; and, `nomail' which
says
+ that _m_s_g_c_h_k should report the status of
empty maildrops. The
+ `-nonotify type' switch has the inverted sense, so
`-nonotify all'
+ directs _m_s_g_c_h_k to never report the status of
maildrops. This is
+ useful if the user wishes to check _m_s_g_c_h_k's
exit status. A
+ non-zero exit status indicates that mail was not waiting
for at
+ least one of the indicated users.
+
+ If _m_s_g_c_h_k produces output, then the `-date'
switch directs _m_s_g_c_h_k
+ to print out the last date mail was read, if this can be
deter-
+ mined.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `user' defaults to the current user
+ `-date'
+ `-notify all'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSGCHK(1) -61-
MSGCHK(1)
+
+
+ _N_A_M_E
+ msh - MH shell (and BBoard reader)
+
+ _S_Y_N_O_P_S_I_S
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur]
[file]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _m_s_h is an interactive program that implements a subset
of the nor-
+ mal _M_H commands operating on a single file in
_p_a_c_k_f'd format. That
+ is, _m_s_h is used to read a file that contains a number
of messages,
+ as opposed to the standard _M_H style of reading a number
of files,
+ each file being a separate message in a folder. _m_s_h's
chief advan-
+ tage is that the normal _M_H style does not allow a file to
have more
+ than one message in it. Hence, _m_s_h is ideal for
reading _B_B_o_a_r_d_s,
+ as these files are delivered by the transport system in
this for-
+ mat. In addition, _m_s_h can be used on other files, such
as message
+ archives which have been _p_a_c_ked (see
_p_a_c_k_f (1)). Finally, _m_s_h is
+ an excellent _M_H tutor. As the only commands available to
the user
+ are _M_H commands, this allows _M_H beginners to
concentrate on how
+ commands to _M_H are formed and (more or less) what they
mean.
+
+ When invoked, _m_s_h reads the named file, and enters a
command loop.
+ The user may type most of the normal _M_H commands. The
syntax and
+ semantics of these commands typed to _m_s_h are identical
to their _M_H
+ counterparts. In cases where the nature of _m_s_h
would be incon-
+ sistent (e.g., specifying a `+folder' with some commands),
_m_s_h will
+ duly inform the user. The commands that _m_s_h currently
supports (in
+ some slightly modified or restricted forms) are:
+
+ ali
+ burst
+ comp
+ dist
+ folder
+ forw
+ inc
+ mark
+ mhmail
+ msgchk
+ next
+ packf
+ pick
+ prev
+ refile
+ repl
+ rmm
+ scan
+ send
+ show
+ sortm
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -62-
MSH(1)
+
+
+ whatnow
+ whom
+
+ In addition, _m_s_h has a "help" command which gives a
brief overview.
+ To terminate _m_s_h, type CTRL-D, or use the "quit"
command. If _m_s_h
+ is being invoked from _b_b_c, then typing CTRL-D will also
tell _b_b_c to
+ exit as well, while using the "quit" command will return
control to
+ _b_b_c, and _b_b_c will continue examining the list of
BBoards that it is
+ scanning.
+
+ If the file is writable and has been modified, then using
"quit"
+ will query the user if the file should be updated.
+
+ The `-prompt string' switch sets the prompting string for
_m_s_h.
+
+ You may wish to use an alternate _M_H profile for the
commands that
+ _m_s_h executes; see _m_h-_p_r_o_f_i_l_e (5) for
details about the $MH envari-
+ able.
+
+ When invoked from _b_b_c, two special features are
enabled: First, the
+ `-scan' switch directs _m_s_h to do a `scan unseen' on
start-up if new
+ items are present in the BBoard. This feature is best used
from
+ _b_b_c, which correctly sets the stage. Second, the
_m_a_r_k command in
+ _m_s_h acts specially when you are reading a BBoard,
since _m_s_h will
+ consult the sequence "unseen" in determining what messages
you have
+ actually read. When _m_s_h exits, it reports this
information to _b_b_c.
+ In addition, if you give the _m_a_r_k command with no
arguments, _m_s_h
+ will interpret it as `mark -sequence unseen -delete
-nozero all'
+ Hence, to discard all of the messages in the current BBoard
you're
+ reading, just use the _m_a_r_k command with no arguments.
+
+ Normally, the "exit" command is identical to the "quit"
command in
+ _m_s_h. When run under _b_b_c however, "exit"
directs _m_s_h to mark all
+ messages as seen and then "quit". For speedy type-in, this
command
+ is often abbreviated as just "e".
+
+ When invoked from _v_m_h, another special feature is
enabled: The
+ `topcur' switch directs _m_s_h to have the current message
"track" the
+ top line of the _v_m_h scan window. Normally, _m_s_h
has the current
+ message "track" the center of the window (under `-notopcur',
which
+ is the default).
+
+ _m_s_h supports an output redirection facility. Commands
may be fol-
+ lowed by one of
+
+ > _f_i_l_e write output to _f_i_l_e
+ >> _f_i_l_e append output to _f_i_l_e
+ | _c_o_m_m_a_n_d pipe output to UNIX
_c_o_m_m_a_n_d
+
+ If _f_i_l_e starts with a `~' (tilde), then a
_c_s_h-like expansion takes
+ place. Note that _c_o_m_m_a_n_d is interpreted by
_s_h (1). Also note that
+ _m_s_h does NOT support history substitutions, variable
substitutions,
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -63-
MSH(1)
+
+
+ or alias substitutions.
+
+ When parsing commands to the left of any redirection
symbol, _m_s_h
+ will honor `\' (back-slash) as the quote next-character
symbol, and
+ `"' (double-quote) as quote-word delimiters. All other
input
+ tokens are separated by whitespace (spaces and tabs).
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Msg-Protect: To set mode when creating a new `file'
+ fileproc: Program to file messages
+ showproc: Program to show messages
+
+
+ _S_e_e _A_l_s_o
+ bbc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to "./msgbox"
+ `-prompt (msh) '
+ `-noscan'
+ `-notopcur'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MSH(1) -64-
MSH(1)
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _m_s_h. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+ There is a strict limit of messages per file in
_p_a_c_k_f'd format
+ which _m_s_h can handle. Usually, this limit is 1000
messages.
+
+ Please remember that _m_s_h is not the _C_S_h_e_l_l,
and that a lot of the
+ nice facilities provided by the latter are not present in the
form-
+ er.
+
+ In particular, _m_s_h does not understand back-quoting,
so the only
+ effective way to use _p_i_c_k inside _m_s_h is
to always use the
+ `-seq select' switch. Clever users of _M_H will put the
line
+
+ pick: -seq select -list
+
+ in their .mh_profile file so that _p_i_c_k works equally
well from both
+ the shell and _m_s_h.
+
+ _s_o_r_t_m always uses "-noverbose" and if "-textfield
field" is used,
+ "-limit 0".
+
+ The _m_s_h program inherits most (if not all) of the bugs
from the _M_H
+ commands it implements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ NEXT(1) -65-
NEXT(1)
+
+
+ _N_A_M_E
+ next - show the next message
+
+ _S_Y_N_O_P_S_I_S
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _N_e_x_t performs a _s_h_o_w on the next message
in the specified (or
+ current) folder. Like _s_h_o_w, it passes any switches
on to the pro-
+ gram _s_h_o_w_p_r_o_c, which is called to list the
message. This command
+ is almost exactly equivalent to "show next". Consult the
manual
+ entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), prev(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder.
The
+ message that is shown (i.e., the next message in sequence)
will be-
+ come the current message.
+
+
+ _B_u_g_s
+ _n_e_x_t is really a link to the _s_h_o_w program.
As a result, if you
+ make a link to _n_e_x_t and that link is not called
_n_e_x_t, your link
+ will act like _s_h_o_w instead. To circumvent
this, add a
+ profile-entry for the link to your _M_H profile and add
the argument
+ _n_e_x_t to the entry.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PACKF(1) -66-
PACKF(1)
+
+
+ _N_A_M_E
+ packf - compress an MH folder into a single file
+
+ _S_Y_N_O_P_S_I_S
+ packf [+folder] [msgs] [-file name] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_a_c_k_f takes messages from a folder and copies
them to a single
+ file. Each message in the file is separated by four CTRL-A's
and a
+ newline. Messages packed can be unpacked using _i_n_c.
+
+ If the _n_a_m_e given to the `-file name' switch exists,
then the mes-
+ sages specified will be appended to the end of the file,
otherwise
+ the file will be created and the messages appended.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ .msgbox.map A binary index of the file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Msg-Protect: To set mode when creating a new `file'
+
+
+ _S_e_e _A_l_s_o
+ inc(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-file ./msgbox'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
first
+ message packed will become the current message.
+
+
+ _B_u_g_s
+ _P_a_c_k_f doesn't handle the old UUCP-style "mbox"
format (used by
+ _S_e_n_d_M_a_i_l). To pack messages into this
format, use the script
+
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_p_a_c_k_m_b_o_x. Note
that _p_a_c_k_m_b_o_x does not take the
+ `-file' option of _p_a_c_k_f, and instead writes its
output on _s_t_d_o_u_t.
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -67-
PICK(1)
+
+
+ _N_A_M_E
+ pick - select messages by content
+
+ _S_Y_N_O_P_S_I_S
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-cc pattern]
+ [-date pattern] [-from pattern] [-search pattern]
+ [-subject pattern] [-to pattern] [-after date] [-before
date]
+ [-datefield field] [-sequence name ...] [-public]
[-nopublic]
+ [-zero] [-nozero] [-list] [-nolist] [-help]
+
+ typically:
+ scan `pick -from jones`
+ pick -to holloway -sequence select
+ show `pick -before friday`
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_i_c_k searches messages within a folder for the
specified contents,
+ and then identifies those messages. Two types of search
primitives
+ are available: pattern matching and date constraint
operations.
+
+ A modified _g_r_e_p(1) is used to perform the matching,
so the full
+ regular expression (see _e_d(1)) facility is available
within `pat-
+ tern'. With `-search', `pattern' is used directly, and
with the
+ others, the grep pattern constructed is:
+
+ "component[ \t]*:.*pattern"
+
+ This means that the pattern specified for a `-search' will be
found
+ everywhere in the message, including the header and the body,
while
+ the other pattern matching requests are limited to the
single
+ specified component. The expression
+
+ `--component pattern'
+
+ is a shorthand for specifying
+
+ `-search "component[ \t]*:.*pattern" '
+
+ It is used to pick a component which is not one of "To:",
"cc:",
+ "Date:", "From:", or "Subject:". An example
is
+ `pick --reply-to pooh'.
+
+ Pattern matching is performed on a per-line basis.
Within the
+ header of the message, each component is treated as one long
line,
+ but in the body, each line is separate. Lower-case letters
in the
+ search pattern will match either lower or upper case in
the mes-
+ sage, while upper case will match only upper case.
+
+ Note that since the `-date' switch is a pattern matching
operation
+ (as described above), to find messages sent on a certain
date the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -68-
PICK(1)
+
+
+ pattern string must match the text of the "Date:" field of
the mes-
+ sage.
+
+ Independent of any pattern matching operations
requested, the
+ switches `-after date' or `-before date' may also be used to
intro-
+ duce date/time contraints on all of the messages. By
default, the
+ "Date:" field is consulted, but if another date yielding
field
+ (such as "BB-Posted:" or "Delivery-Date:") should be
used, the
+ `-datefield field' switch may be used.
+
+ With `-before' and `-after', _p_i_c_k will actually
parse the date
+ fields in each of the messages specified in `msgs' and
compare them
+ to the date/time specified. If `-after' is given, then only
those
+ messages whose "Date:" field value is chronologically
after the
+ date specified will be considered. The `-before' switch
specifies
+ the complimentary action.
+
+ Both the `-after' and `-before' switches take legal 822-style
date
+ specifications as arguments. _P_i_c_k will default
certain missing
+ fields so that the entire date need not be specified. These
fields
+ are (in order of defaulting): timezone, time and timezone,
date,
+ date and timezone. All defaults are taken from the current
date,
+ time, and timezone.
+
+ In addition to 822-style dates, _p_i_c_k will also
recognize any of the
+ days of the week ("sunday", "monday", and so on), and the
special
+ dates "today", "yesterday" (24 hours ago), and "tomorrow" (24
hours
+ from now). All days of the week are judged to refer to a
day in
+ the past (e.g., telling _p_i_c_k "saturday" on a
"tuesday" means
+ "last saturday" not "this saturday").
+
+ Finally, in addition to these special specifications,
_p_i_c_k will
+ also honor a specification of the form "-dd", which means
"dd days
+ ago".
+
+ _P_i_c_k supports complex boolean operations on the
searching primi-
+ tives with the `-and', `-or', `-not', and `-lbrace ...
-rbrace'
+ switches. For example,
+
+ pick -after yesterday -and
+ -lbrace -from freida -or -from fear -rbrace
+
+ identifies messages recently sent by "frieda" or "fear".
+
+ The matching primitives take precedence over the `-not'
switch,
+ which in turn takes precedence over `-and' which in turn
takes pre-
+ cedence over `-or'. To override the default
precedence, the
+ `-lbrace' and `-rbrace' switches are provided, which act
just like
+ opening and closing parentheses in logical expressions.
+
+ If no search criteria are given, all the messages specified
on the
+ command line are selected (this defaults to "all").
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -69-
PICK(1)
+
+
+ Once the search has been performed, if the `-list' switch is
given,
+ the message numbers of the selected messages are written
to the
+ standard output separated by newlines. This is
_e_x_t_r_e_m_e_l_y useful
+ for quickly generating arguments for other _M_H programs by
using the
+ "backquoting" syntax of the shell. For example, the command
+
+ scan `pick +todo -after "31 Mar 83 0123 PST"`
+
+ says to _s_c_a_n those messages in the indicated folder
which meet the
+ appropriate criterion. Note that since _p_i_c_k 's
context changes are
+ written out prior to _s_c_a_n 's invocation, you need
not give the
+ folder argument to _s_c_a_n as well.
+
+ Regardless of the operation of the `-list' switch, the
`-sequence
+ name' switch may be given once for each sequence the user
wishes to
+ define. For each sequence named, that sequence will be
defined to
+ mean exactly those messages selected by _p_i_c_k. For
example,
+
+ pick -from frated -seq fred
+
+ defines a new message sequence for the current folder called
"fred"
+ which contains exactly those messages that were selected.
+
+ Note that whenever _p_i_c_k processes a `-sequence
name' switch, it
+ sets `-nolist'.
+
+ By default, _p_i_c_k will zero the sequence before
adding it. This
+ action can be disabled with the `-nozero' switch, which
means that
+ the messages selected by _p_i_c_k will be added to the
sequence, if it
+ already exists, and any messages already a part of that
sequence
+ will remain so.
+
+ The `-public' and `-nopublic' switches are used by
_p_i_c_k in the same
+ way _m_a_r_k uses them.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ mark(1)
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -70-
PICK(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-zero'
+ `-list' is the default if no `-sequence', `-nolist' otherwise
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the _p_i_c_k command
would _s_h_o_w, _s_c_a_n, or
+ _r_e_f_i_l_e the selected messages. This was
rather "inverted logic"
+ from the UNIX point of view, so _p_i_c_k was changed
to define se-
+ quences and output those sequences. Hence, _p_i_c_k
can be used to
+ generate the arguments for all other _M_H commands, instead
of giving
+ _p_i_c_k endless switches for invoking those commands
itself.
+
+ Also, previous versions of _p_i_c_k balked if you
didn't specify a
+ search string or a date/time constraint. The current
version does
+ not, and merely matches the messages you specify. This
lets you
+ type something like:
+
+ show `pick last:20 -seq fear`
+
+ instead of typing
+
+ mark -add -nozero -seq fear last:20
+ show fear
+
+ Finally, timezones used to be ignored when comparing dates:
they
+ aren't any more.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ Use "pick sequence -list" to enumerate the messages in a
sequence
+ (such as for use by a shell script).
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PICK(1) -71-
PICK(1)
+
+
+ _B_u_g_s
+ The argument to the `-after' and `-before' switches must be
inter-
+ preted as a single token by the shell that invokes
_p_i_c_k. There-
+ fore, one must usually place the argument to this switch
inside
+ double-quotes. Furthermore, any occurance of `-datefield'
must oc-
+ cur prior to the `-after' or `-before' switch it applies to.
+
+ If _p_i_c_k is used in a back-quoted operation, such as
+
+ scan `pick -from jones`
+
+ and _p_i_c_k selects no messages (e.g., no messages are
from "jones"),
+ then the shell will still run the outer command (e.g.,
"scan").
+ Since no messages were matched, _p_i_c_k produced no
output, and the
+ argument given to the outer command as a result of
backquoting _p_i_c_k
+ is empty. In the case of _M_H programs, the outer command
now acts
+ as if the default `msg' or `msgs' should be used (e.g.,
"all" in
+ the case of _s_c_a_n ). To prevent this unexpected
behavior, if
+ `-list' was given, and if its standard output is not a
tty, then
+ _p_i_c_k outputs the illegal message number "0" when it
fails. This
+ lets the outer command fail gracefully as well.
+
+ The pattern syntax "[l-r]" is not supported; each letter
to be
+ matched must be included within the square brackets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PREV(1) -72-
PREV(1)
+
+
+ _N_A_M_E
+ prev - show the previous message
+
+ _S_Y_N_O_P_S_I_S
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [-switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_r_e_v performs a _s_h_o_w on the previous message
in the specified (or
+ current) folder. Like _s_h_o_w, it passes any switches
on to the pro-
+ gram named by _s_h_o_w_p_r_o_c, which is called to
list the message. This
+ command is almost exactly equivalent to "show prev".
Consult the
+ manual entry for _s_h_o_w (1) for all the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ showproc: Program to show the message
+
+
+ _S_e_e _A_l_s_o
+ show(1), next(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is specified, it will become the current folder.
The
+ message that is shown (i.e., the previous message in
sequence) will
+ become the current message.
+
+
+ _B_u_g_s
+ _p_r_e_v is really a link to the _s_h_o_w program.
As a result, if you
+ make a link to _p_r_e_v and that link is not called
_p_r_e_v, your link
+ will act like _s_h_o_w instead. To circumvent
this, add a
+ profile-entry for the link to your _M_H profile and add
the argument
+ _p_r_e_v to the entry.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -73-
PROMPTER(1)
+
+
+ _N_A_M_E
+ prompter - prompting editor front-end for MH
+
+ _S_Y_N_O_P_S_I_S
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend]
[-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This program is normally not invoked directly by users but
takes
+ the place of an editor and acts as an editor
front-end. It
+ operates on an 822-style message draft skeleton specified by
file,
+ normally provided by _c_o_m_p, _d_i_s_t,
_f_o_r_w, or _r_e_p_l.
+
+ _P_r_o_m_p_t_e_r is an editor which allows rapid
composition of messages.
+ It is particularly useful to network and low-speed (less
than 2400
+ baud) users of _M_H. It is an _M_H program in that it
can have its own
+ profile entry with switches, but it is not invoked directly
by the
+ user. The commands _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l invoke _p_r_o_m_p_t_e_r as
+ an editor, either when invoked with `-editor prompter', or
by the
+ profile entry "Editor: prompter", or when given the
command
+ `edit prompter' at "What now?" level.
+
+ For each empty component _p_r_o_m_p_t_e_r finds in
the draft, the user is
+ prompted for a response; A <RETURN> will cause the whole
component
+ to be left out. Otherwise, a `\' preceding a <RETURN> will
con-
+ tinue the response on the next line, allowing for
multiline com-
+ ponents. Continuation lines must begin with a space or tab.
+
+ Each non-empty component is copied to the draft and
displayed on
+ the terminal.
+
+ The start of the message body is denoted by a blank line or a
line
+ of dashes. If the body is non-empty, the prompt, which isn't
writ-
+ ten to the file, is
+
+ "--------Enter additional text",
+
+ or (if `-prepend' was given)
+
+ "--------Enter initial text".
+
+ Message-body typing is terminated with an end-of-file
(usually
+ CTRL-D). With the `-doteof' switch, a period on a line
all by
+ itself also signifies end-of-file. At this point
control is
+ returned to the calling program, where the user is asked
"What
+ now?". See _w_h_a_t_n_o_w for the valid options to
this query.
+
+ By using the `-prepend' switch, the user can add type-in
to the
+ beginning of the message body and have the rest of the body
follow.
+ This is useful for the _f_o_r_w command.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -74-
PROMPTER(1)
+
+
+ By using the `-rapid' switch, if the draft already contains
text in
+ the message-body, it is not displayed on the user's terminal.
This
+ is useful for low-speed terminals.
+
+ The line editing characters for kill and erase may be
specified by
+ the user via the arguments `-kill chr' and `-erase chr',
where chr
+ may be a character; or `\nnn', where "nnn" is the octal
value for
+ the character.
+
+ An interrupt (usually CTRL-C) during component typing will
abort
+ _p_r_o_m_p_t_e_r and the _M_H command that
invoked it. An interrupt during
+ message-body typing is equivalent to CTRL-D, for historical
rea-
+ sons. This means that _p_r_o_m_p_t_e_r should finish
up and exit.
+
+ The first non-flag argument to _p_r_o_m_p_t_e_r is
taken as the name of the
+ draft file, and subsequent non-flag arguments are ignored.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /tmp/prompter* Temporary copy of message
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ prompter-next: To name the editor to be used on exit
from
+ _p_r_o_m_p_t_e_r
+ Msg-Protect: To set mode when creating a new draft
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), whatnow(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prepend'
+ `-norapid'
+ `-nodoteof'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ The `-rapid' option is particularly useful with
_f_o_r_w, and
+ `-noprepend' is useful with _c_o_m_p -_u_s_e.
+
+ The user may wish to link _p_r_o_m_p_t_e_r under
several names (e.g., "ra-
+ pid") and give appropriate switches in the profile entries
under
+ these names (e.g., "rapid: -rapid"). This facilitates
invoking
+ prompter differently for different _M_H commands (e.g.,
"forw: -edi-
+ tor rapid").
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ PROMPTER(1) -75-
PROMPTER(1)
+
+
+ _B_u_g_s
+ _P_r_o_m_p_t_e_r uses _s_t_d_i_o (3), so it will
lose if you edit files with
+ nulls in them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -76-
RCVSTORE(1)
+
+
+ _N_A_M_E
+ rcvstore - incorporate new mail asynchronously
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero]
[-nozero]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_c_v_s_t_o_r_e incorporates a message from the
standard input into an _M_H
+ folder. If `+folder' isn't specified, a folder in the
user's _M_H
+ directory will be used, either that specified by the "Inbox:"
entry
+ in the user's profile, or the folder named "inbox". The
new mes-
+ sage being incorporated is assigned the next highest number
in the
+ folder. If the specified (or default) folder doesn't
exist, then
+ it will be created if the `-create' option is specified,
otherwise
+ _r_c_v_s_t_o_r_e will exit.
+
+ If the user's profile contains a "Msg-Protect: nnn" entry, it
will
+ be used as the protection on the newly created messages,
otherwise
+ the _M_H default of 0644 will be used. During all
operations on mes-
+ sages, this initially assigned protection will be
preserved for
+ each message, so _c_h_m_o_d(1) may be used to set a
protection on an
+ individual message, and its protection will be
preserved
+ thereafter.
+
+ _R_c_v_s_t_o_r_e will incorporate anything except
zero length messages into
+ the user's MH folder.
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+ then _r_c_v_s_t_o_r_e will add the newly
incorporated message to each
+ sequence named by the profile entry. This is similar
to the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments. Note that
_r_c_v_s_t_o_r_e will not
+ zero each sequence prior to adding messages.
+
+ Furthermore, the incoming messages may be added to
user-defined
+ sequences as they arrive by appropriate use of the
`-sequence'
+ option. As with _p_i_c_k, use of the `-zero' and
`-nozero' switches
+ can also be used to zero old sequences or not. Similarly,
use of
+ the `-public' and `-nopublic switches may be used to force
addi-
+ tions to public and private sequences.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RCVSTORE(1) -77-
RCVSTORE(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Folder-Protect: To set mode when creating a new folder
+ Inbox: To find the default inbox
+ Msg-Protect: To set mode when creating a new message
+ Unseen-Sequence: To name sequences denoting unseen
messages
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), mh-mail(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to "inbox"
+ `-create'
+ `-nopublic' if the folder is read-only, `-public' otherwise
+ `-nozero'
+
+
+ _C_o_n_t_e_x_t
+ No context changes will be attempted, with the exception
of se-
+ quence manipulation.
+
+
+ _B_u_g_s
+ If you use the "Unseen-Sequence" profile entry,
_r_c_v_s_t_o_r_e could try
+ to update the context while another _M_H process is also
trying to do
+ so. This can cause the context to become corrupted. To
avoid
+ this, do not use _r_c_v_s_t_o_r_e if you use the
"Unseen-Sequence" profile
+ entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -78-
REFILE(1)
+
+
+ _N_A_M_E
+ refile - file message in other folders
+
+ _S_Y_N_O_P_S_I_S
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve]
[-nopreserve]
+ [-src +folder] [-file file] [-rmmproc program]
[-normmproc]
+ +folder ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_f_i_l_e moves (_m_v (1)) or links (_l_n (1))
messages from a source
+ folder into one or more destination folders. If you
think of a
+ message as a sheet of paper, this operation is not unlike
filing
+ the sheet of paper (or copies) in file cabinet folders.
When a
+ message is filed, it is linked into the destination
folder(s) if
+ possible, and is copied otherwise. As long as the
destination
+ folders are all on the same file system, multiple filing
causes
+ little storage overhead. This facility provides a good
way to
+ cross-file or multiply-index messages. For example, if a
message
+ is received from Jones about the ARPA Map Project, the command
+
+ refile cur +jones +Map
+
+ would allow the message to be found in either of the two
folders
+ `jones' or `Map'.
+
+ The option `-file file' directs _r_e_f_i_l_e to use the
specified file as
+ the source message to be filed, rather than a message
from a
+ folder. Note that the file should be a validly formatted
message,
+ just like any other _M_H message. It should NOT be in mail
drop for-
+ mat (to convert a file in mail drop format to a folder of
_M_H mes-
+ sages, see _i_n_c (1)).
+
+ If a destination folder doesn't exist, _r_e_f_i_l_e
will ask if you want
+ to create it. A negative response will abort the file
operation.
+ If the standard input for _r_e_f_i_l_e is _n_o_t a
tty, then _r_e_f_i_l_e will not
+ ask any questions and will proceed as if the user answered
"yes" to
+ all questions.
+
+ The option `-link' preserves the source folder copy of the
message
+ (i.e., it does a _l_n(1) rather than a _m_v(1)),
whereas, `-nolink'
+ deletes the filed messages from the source folder. Normally,
when
+ a message is filed, it is assigned the next highest number
avail-
+ able in each of the destination folders. Use of the
`-preserve'
+ switch will override this message renaming, but name
conflicts may
+ occur, so use this switch cautiously.
+
+ If `-link' is not specified (or `-nolink' is specified), the
filed
+ messages will be removed from the source folder, by
renaming them
+ with a site-dependent prefix (usually a comma).
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REFILE(1) -79-
REFILE(1)
+
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then _r_e_f_i_l_e will instead call the named program
to delete the mes-
+ sage files. The user may specify `-rmmproc program' on the
command
+ line to override this profile specification. The
`-normmproc'
+ option forces the message files to be deleted by renaming
them as
+ described above.
+
+ The `-draft' switch tells _r_e_f_i_l_e to file the
<mh-dir>/draft.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Folder-Protect: To set mode when creating a new folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ folder(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-src +folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-nolink'
+ `-nopreserve'
+
+
+ _C_o_n_t_e_x_t
+ If `-src +folder' is given, it will become the current
folder. If
+ neither `-link' nor `all' is specified, the current message
in the
+ source folder will be set to the last message specified;
otherwise,
+ the current message won't be changed.
+
+ If the Previous-Sequence profile entry is set, in addition
to de-
+ fining the named sequences from the source folder,
_r_e_f_i_l_e will also
+ define those sequences for the destination folders.
See
+ _m_h-_s_e_q_u_e_n_c_e (5) for information
concerning the previous sequence.
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to
delete the message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying
`-normmproc', or you will
+ create an infinte loop.
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -80-
REPL(1)
+
+
+ _N_A_M_E
+ repl - reply to a message
+
+ _S_Y_N_O_P_S_I_S
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc
all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form
formfile]
+ [-inplace] [-noinplace] [-query] [-noquery] [-width
columns]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_e_p_l aids a user in producing a reply to an existing
message. _R_e_p_l
+ uses a reply template to guide its actions when
constructing the
+ message draft of the reply. In its simplest form (with no
argu-
+ ments), it will set up a message-form skeleton in reply
to the
+ current message in the current folder, and invoke the
whatnow
+ shell. The default reply template will direct
_r_e_p_l to construct
+ the composed message as follows:
+
+ To: <Reply-To> or <From>
+ cc: <cc>, <To>, and yourself
+ Subject: Re: <Subject>
+ In-reply-to: Your message of <Date>.
+ <Message-Id>
+
+ where field names enclosed in angle brackets (< >)
indicate the
+ contents of the named field from the message to which the
reply is
+ being made. A reply template is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ The `-cc type' switch takes an argument which specifies who
gets
+ placed on the "cc:" list of the reply. The `-query' switch
modi-
+ fies the action of `-cc type' switch by interactively asking
you if
+ each address that normally would be placed in the "To:" and
"cc:"
+ list should actually be sent a copy. (This is
useful for
+ special-purpose replies.) Note that the position of the
`-cc' and
+ `-nocc' switches, like all other switches which take a
positive and
+ negative form, is important.
+
+ Lines beginning with the fields "To:", "cc:", and "Bcc:"
will be
+ standardized and have duplicate addresses removed. In
addition,
+ the `-width columns' switch will guide _r_e_p_l's
formatting of these
+ fields.
+
+ If the file named "replcomps" exists in the user's MH
directory, it
+ will be used instead of the default form. In either case,
the file
+ specified by `-form formfile' will be used if given.
+
+ If the draft already exists, _r_e_p_l will ask you as to
the disposi-
+ tion of the draft. A reply of quit will abort
_r_e_p_l, leaving the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -81-
REPL(1)
+
+
+ draft intact; replace will replace the existing draft with a
blank
+ skeleton; and list will display the draft.
+
+ See _c_o_m_p (1) for a description of the `-editor'
and `-noedit'
+ switches. Note that while in the editor, the message being
replied
+ to is available through a link named "@" (assuming the
default
+ _w_h_a_t_n_o_w_p_r_o_c ). In addition, the
actual pathname of the message is
+ stored in the envariable $editalt, and the pathname of the
folder
+ containing the message is stored in the envariable $mhfolder.
+
+ Although _r_e_p_l uses the `-form formfile' switch to
direct it how to
+ construct the beginning of the draft, the `-filter
filterfile'
+ switch directs _r_e_p_l as to how the message being
replied-to should
+ be formatted in the body of the draft. If `-filter' is not
speci-
+ fied, then the message being replied-to is not included in
the body
+ of the draft. If `-filter filterfile' is specified, then
the mes-
+ sage being replied-to is filtered (re-formatted) prior to
being
+ output to the body of the draft. The filter file for
_r_e_p_l should
+ be a standard form file for _m_h_l, as _r_e_p_l will
invoke _m_h_l to format
+ the message being replied-to. There is no default message
filter
+ (`-filter' must be followed by a file name). A filter file
that is
+ commonly used is:
+
+ :
+ body:nocomponent,compwidth=9,offset=9
+
+ which says to output a blank line and then the body of the
message
+ being replied-to, indented by one tab-stop. Another format
popular
+ on USENET is:
+
+
+ message-id:nocomponent,nonewline,\
+ formatfield="In message %{text}, "
+ from:nocomponent,formatfield="%(friendly{text}) writes:"
+ body:component=">",overflowtext=">",overflowoffset=0
+
+ Which cites the Message-ID and author of the message
being
+ replied-to, and then outputs each line of the body
prefaced with
+ the ">" character.
+
+ If the `-annotate' switch is given, the message being
replied-to
+ will be annotated with the lines
+
+ Replied: date
+ Replied: addrs
+
+ where the address list contains one line for each addressee.
The
+ annotation will be done only if the message is sent
directly from
+ _r_e_p_l. If the message is not sent immediately
from _r_e_p_l,
+ "comp -use" may be used to re-edit and send the
constructed mes-
+ sage, but the annotations won't take place. The `-inplace'
switch
+ causes annotation to be done in place in order to preserve
links to
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -82-
REPL(1)
+
+
+ the annotated message.
+
+ The `-fcc +folder' switch can be used to automatically
specify a
+ folder to receive Fcc:s. More than one folder, each
preceeded by
+ `-fcc' can be named.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _r_e_p_l also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t
escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ _f_c_c string Any folders specified with `-fcc
folder'
+
+ To avoid reiteration, _r_e_p_l strips any leading `Re: '
strings from
+ the _s_u_b_j_e_c_t component.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ Upon exiting from the editor, _r_e_p_l will invoke the
_w_h_a_t_n_o_w program.
+ See _w_h_a_t_n_o_w (1) for a discussion of available
options. The invoca-
+ tion of this program can be inhibited by using the
`-nowhatnowproc'
+ switch. (In truth of fact, it is the _w_h_a_t_n_o_w
program which starts
+ the initial edit. Hence, `-nowhatnowproc' will prevent any
edit
+ from occurring.)
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/replcomps The reply template
+ or <mh-dir>/replcomps Rather than the standard
template
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ Msg-Protect: To set mode when creating a new
message
+ (draft)
+ fileproc: Program to refile the message
+ mhlproc: Program to filter message being
replied-to
+ whatnowproc: Program to ask the "What now?" questions
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), send(1), whatnow(1), mh-format(5)
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ REPL(1) -83-
REPL(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msg' defaults to cur
+ `-nocc all' at ATHENA sites, `-cc all' otherwise
+ `-noannotate'
+ `-nodraftfolder'
+ `-noinplace'
+ `-noquery'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
mes-
+ sage replied-to will become the current message.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-noformat'
used to
+ cause address headers to be output as-is. Now all address
fields
+ are formatted using Internet standard guidelines.
+
+
+ _B_u_g_s
+ If any addresses occur in the reply template, addresses in
the tem-
+ plate that do not contain hosts are defaulted incorrectly.
Instead
+ of using the localhost for the default, _r_e_p_l uses
the sender's
+ host. Moral of the story: if you're going to include
addresses in
+ a reply template, include the host portion of the address.
+
+ The `-width columns' switch is only used to do
address-folding;
+ other headers are not line-wrapped.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _r_e_p_l uses a built-in
_w_h_a_t_n_o_w, it
+ does not actually run the _w_h_a_t_n_o_w program.
Hence, if you define
+ your own _w_h_a_t_n_o_w_p_r_o_c, don't call it
_w_h_a_t_n_o_w since _r_e_p_l won't run
+ it.
+
+ If your current working directory is not writable, the link
named
+ "@" is not available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMF(1) -84-
RMF(1)
+
+
+ _N_A_M_E
+ rmf - remove an MH folder
+
+ _S_Y_N_O_P_S_I_S
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_f removes all of the messages (files) within the
specified (or
+ default) folder, and then removes the folder (directory)
itself.
+ If there are any files within the folder which are not a
part of
+ _M_H, they will _n_o_t be removed, and an error will
be produced. If
+ the folder is given explicitly or the `-nointeractive'
option is
+ given, then the folder will be removed without confirmation.
Oth-
+ erwise, the user will be asked for confirmation. If
_r_m_f can't find
+ the current folder, for some reason, the folder to be
removed
+ defaults to `+inbox' (unless overridden by user's profile
entry
+ "Inbox") with confirmation.
+
+ _R_m_f irreversibly deletes messages that don't have other
links, so
+ use it with caution.
+
+ If the folder being removed is a subfolder, the parent folder
will
+ become the new current folder, and _r_m_f will produce a
message tel-
+ ling the user this has happened. This provides an easy
mechanism
+ for selecting a set of messages, operating on the list, then
remov-
+ ing the list and returning to the current folder from
which the
+ list was extracted.
+
+ _R_m_f of a read-only folder will delete the private
sequence and cur
+ information (i.e., "atr-_s_e_q-_f_o_l_d_e_r"
entries) from the profile
+ without affecting the folder itself.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Inbox: To find the default inbox
+
+
+ _S_e_e _A_l_s_o
+ rmm(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder, usually with
confirmation
+ `-interactive' if +folder' not given, `-nointeractive'
otherwise
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMF(1) -85-
RMF(1)
+
+
+ _C_o_n_t_e_x_t
+ _R_m_f will set the current folder to the parent folder if
a subfolder
+ is removed; or if the current folder is removed, it will
make "in-
+ box" current. Otherwise, it doesn't change the current
folder or
+ message.
+
+
+ _B_u_g_s
+ Although intuitively one would suspect that _r_m_f works
recursively,
+ it does not. Hence if you have a sub-folder within a
folder, in
+ order to _r_m_f the parent, you must first _r_m_f each
of the children.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMM(1) -86-
RMM(1)
+
+
+ _N_A_M_E
+ rmm - remove messages
+
+ _S_Y_N_O_P_S_I_S
+ rmm [+folder] [msgs] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _R_m_m removes the specified messages by renaming the
message files
+ with preceding commas. Many sites consider files that start
with a
+ comma to be a temporary backup, and arrange for _c_r_o_n
(8) to remove
+ such files once a day.
+
+ If the user has a profile component such as
+
+ rmmproc: /bin/rm
+
+ then instead of simply renaming the message file, _r_m_m
will call the
+ named program to delete the file. Note that at most
installations,
+ _c_r_o_n (8) is told to remove files that begin with a
comma once a
+ night.
+
+ Some users of csh prefer the following:
+
+ alias rmm 'refile +d'
+
+ where folder +d is a folder for deleted messages, and
+
+ alias mexp 'rm `mhpath +d all`'
+
+ is used to "expunge" deleted messages.
+
+ The current message is not changed by _r_m_m, so a
_n_e_x_t will advance
+ to the next message in the folder as expected.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ rmmproc: Program to delete the message
+
+
+ _S_e_e _A_l_s_o
+ rmf(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ RMM(1) -87-
RMM(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _B_u_g_s
+ Since _r_e_f_i_l_e uses your _r_m_m_p_r_o_c to
delete the message, the _r_m_m_p_r_o_c
+ must NOT call _r_e_f_i_l_e without specifying
`-normmproc', or you will
+ create an infinte loop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -88-
SCAN(1)
+
+
+ _N_A_M_E
+ scan - produce a one line per message scan listing
+
+ _S_Y_N_O_P_S_I_S
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_c_a_n produces a one-line-per-message listing of the
specified mes-
+ sages. Each _s_c_a_n line contains the message
number (name), the
+ date, the "From:" field, the "Subject" field, and, if room
allows,
+ some of the body of the message. For example:
+
+ 15+ 7/ 5 Dcrocker nned <<Last week I asked some of
+ 16 - 7/ 5 dcrocker message id format <<I recommend
+ 18 7/ 6 Obrien Re: Exit status from mkdir
+ 19 7/ 7 Obrien "scan" listing format in MH
+
+ The `+' on message 15 indicates that it is the current
message.
+ The `-' on message 16 indicates that it has been replied
to, as
+ indicated by a "Replied:" component produced by an
`-annotate'
+ switch to the _r_e_p_l command.
+
+ If there is sufficient room left on the _s_c_a_n line
after the sub-
+ ject, the line will be filled with text from the body,
preceded by
+ <<, and terminated by >> if the body is sufficiently short.
_S_c_a_n
+ actually reads each of the specified messages and parses
them to
+ extract the desired fields. During parsing, appropriate
error mes-
+ sages will be produced if there are format errors in any
of the
+ messages.
+
+ The `-header' switch produces a header line prior to the
_s_c_a_n list-
+ ing. Currently, the name of the folder and the current
date and
+ time are output (see the HISTORY section for more
information).
+
+ If the `-clear' switch is used and _s_c_a_n'_s output is
directed to a
+ terminal, then _s_c_a_n will consult the $TERM and
$TERMCAP envariables
+ to determine your terminal type in order to find out how to
clear
+ the screen prior to exiting. If the `-clear' switch is
used and
+ _s_c_a_n'_s output is not directed to a terminal (e.g.,
a pipe or a
+ file), then _s_c_a_n will send a formfeed prior to
exiting.
+
+ For example, the command:
+
+ (scan -clear -header; show all -show pr -f) | lpr
+
+ produces a scan listing of the current folder, followed
by a
+ formfeed, followed by a formatted listing of all messages
in the
+ folder, one per page. Omitting `-show pr -f' will cause the
mes-
+ sages to be concatenated, separated by a one-line header
and two
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -89-
SCAN(1)
+
+
+ blank lines.
+
+ If _s_c_a_n encounters a message without a "Date:" field,
rather than
+ leaving that portion of the scan listing blank, the
date is
+ filled-in with the last write date of the message, and
post-fixed
+ with a `*'. This is particularly handy for scanning a
_d_r_a_f_t
+ _f_o_l_d_e_r, as message drafts usually aren't allowed
to have dates in
+ them.
+
+ To override the output format used by _s_c_a_n, the
`-format string' or
+ `-form file' switches are used. This permits individual
fields of
+ the scan listing to be extracted with ease. The string is
simply a
+ format string and the file is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard _m_h-_f_o_r_m_a_t (5)
escapes, _s_c_a_n also recog-
+ nizes the following additional _c_o_m_p_o_n_e_n_t
escapes:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ body string the (compressed) first part of the body
+ dtimenow date the current date
+ folder string the name of the current folder
+
+ Also, if no date header was present in the message, the
_f_u_n_c_t_i_o_n
+ escapes which operate on {_d_a_t_e} will return values
for the date of
+ last modification of the message file itself.
+
+ _s_c_a_n will update the _M_H context prior to starting
the listing, so
+ interrupting a long _s_c_a_n listing preserves the
new context. _M_H
+ purists hate this idea.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Alternate-Mailboxes: To determine the user's mailboxes
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ inc(1), pick(1), show(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the folder current
+ `msgs' defaults to all
+ `-format' defaulted as described above
+ `-noheader'
+ `-width' defaulted to the width of the terminal
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SCAN(1) -90-
SCAN(1)
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
+
+
+ _H_i_s_t_o_r_y
+ Prior to using the format string mechanism, `-header' used to
gen-
+ erate a heading saying what each column in the listing was.
Format
+ strings prevent this from happening.
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _s_c_a_n. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+ The value of each _c_o_m_p_o_n_e_n_t escape is set
by _s_c_a_n to the contents
+ of the first message header _s_c_a_n encounters with the
corresponding
+ component name; any following headers with the same component
name
+ are ignored.
+
+ The switch `-reverse', makes _s_c_a_n list the messages
in reverse ord-
+ er; this should be considered a bug.
+
+ The `-file filename' switch allows the user to obtain a
_s_c_a_n list-
+ ing of a maildrop file as produced by _p_a_c_k_f. This
listing includes
+ every message in the file. The user should use _m_s_h for
more selec-
+ tive processing of the file. `-reverse' is ignored with
this op-
+ tion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -91-
SEND(1)
+
+
+ _N_A_M_E
+ send - send a message
+
+ _S_Y_N_O_P_S_I_S
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-msgid] [-nomsgid] [-push] [-nopush] [-verbose]
[-noverbose]
+ [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_e_n_d will cause each of the specified files to be
delivered (via
+ _p_o_s_t (8)) to each of the destinations in the "To:",
"cc:", "Bcc:",
+ and "Fcc:" fields of the message. If _s_e_n_d is
re-distributing a
+ message, as invoked from _d_i_s_t, then the
corresponding "Resent-xxx"
+ fields are examined instead.
+
+ If `-push' is specified, _s_e_n_d will detach itself
from the user's
+ terminal and perform its actions in the background. If
_p_u_s_h 'd and
+ the draft can't be sent, then the `-forward' switch says that
draft
+ should be forwarded with the failure notice sent to the user.
This
+ differs from putting _s_e_n_d in the background because
the output is
+ trapped and analyzed by _M_H.
+
+ If `-verbose' is specified, _s_e_n_d will indicate the
interactions
+ occurring with the transport system, prior to actual
delivery. If
+ `-watch' is specified _s_e_n_d will monitor the delivery
of local and
+ network mail. Hence, by specifying both switches, a large
detail
+ of information can be gathered about each step of the
message's
+ entry into the transport system.
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ _S_e_n_d with no _f_i_l_e argument will query
whether the draft is the
+ intended file, whereas `-draft' will suppress this question.
Once
+ the transport system has successfully accepted custody of the
mes-
+ sage, the file will be renamed with a leading comma, which
allows
+ it to be retrieved until the next draft message is sent. If
there
+ are errors in the formatting of the message, _s_e_n_d
will abort with a
+ (hopefully) helpful error message.
+
+ If a "Bcc:" field is encountered, its addresses will be
used for
+ delivery, and the "Bcc:" field will be removed from the
message
+ sent to sighted recipients. The blind recipients will
receive an
+ entirely new message with a minimal set of headers.
Included in
+ the body of the message will be a copy of the message sent
to the
+ sighted recipients. If `-filter filterfile' is
specified, then
+ this copy is filtered (re-formatted) prior to being sent
to the
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -92-
SEND(1)
+
+
+ blind recipients.
+
+ Prior to sending the message, the fields "From:
address@hidden", and
+ "Date: now" will be appended to the headers in the message.
If the
+ envariable $SIGNATURE is set, then its value is used as your
per-
+ sonal name when constructing the "From:" line of the
message. If
+ this envariable is not set, then _s_e_n_d will consult
the profile
+ entry "Signature" for this information. On hosts where
_M_H was con-
+ figured with the UCI option, if $SIGNATURE is not set and the
"Sig-
+ nature" profile entry is not present, then the
file
+ $HOME/.signature is consulted. If `-msgid' is specified,
then a
+ "Message-ID:" field will also be added to the message.
+
+ If _s_e_n_d is re-distributing a message (when invoked by
_d_i_s_t ), then
+ "Resent-" will be prepended to each of these fields:
"From:",
+ "Date:", and "Message-ID:". If the message already
contains a
+ "From:" field, then a "Sender: address@hidden" field will
be added as
+ well. (An already existing "Sender:" field is an error!)
+
+ By using the `-format' switch, each of the entries in the
"To:" and
+ "cc:" fields will be replaced with "standard" format entries.
This
+ standard format is designed to be usable by all of the
message
+ handlers on the various systems around the Internet. If
`-nofor-
+ mat' is given, then headers are output exactly as they
appear in
+ the message draft.
+
+ If an "Fcc: folder" is encountered, the message will be
copied to
+ the specified folder for the sender in the format in which
it will
+ appear to any non-Bcc receivers of the message. That is, it
will
+ have the appended fields and field reformatting. The "Fcc:"
fields
+ will be removed from all outgoing copies of the message.
+
+ By using the `-width columns' switch, the user can direct
_s_e_n_d as
+ to how long it should make header lines containing addresses.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read (more than one file, each preceeded by `-alias',
can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ Signature: To determine the user's mail signature
+ mailproc: Program to post failure notices
+ postproc: Program to post the message
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SEND(1) -93-
SEND(1)
+
+
+ _S_e_e _A_l_s_o
+ comp(1), dist(1), forw(1), repl(1), mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-nodraftfolder'
+ `-nofilter'
+ `-format'
+ `-forward'
+ `-nomsgid'
+ `-nopush'
+ `-noverbose'
+ `-nowatch'
+ `-width 72'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ Under some configurations, it is not possible to mointor the
mail
+ delivery transaction; `-watch' is a no-op on those systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -94-
SHOW(1)
+
+
+ _N_A_M_E
+ show - show (list) messages
+
+ _S_Y_N_O_P_S_I_S
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_h_o_w lists each of the specified messages to the
standard output
+ (typically, the terminal). Typically, the messages are
listed
+ exactly as they are, with no reformatting. A program named
by the
+ _s_h_o_w_p_r_o_c profile component is invoked to
do the listing, and any
+ switches not recognized by _s_h_o_w are passed along to
that program.
+ The default program is known as _m_o_r_e (1). To
override the default
+ and the _s_h_o_w_p_r_o_c profile component, use
the `-showproc program'
+ switch. For example, `-show pr' will cause the _p_r (1)
program to
+ list the messages. The _M_H command _m_h_l can be used
as a _s_h_o_w_p_r_o_c to
+ show messages in a more uniform format. Normally, this
program is
+ specified as the _s_h_o_w_p_r_o_c is the user's
.mh_profile. See _m_h_l (1)
+ for the details. If the `-noshowproc' option is
specified,
+ `/bin/cat' is used instead of _s_h_o_w_p_r_o_c.
+
+ The `-header' switch tells _s_h_o_w to display a
one-line description
+ of the message being shown. This description includes the
folder
+ and the message number.
+
+ If no `msgs' are specified, the current message is used. If
more
+ than one message is specified, _m_o_r_e will prompt
for a <RETURN>
+ prior to listing each message. _m_o_r_e will list each
message, a page
+ at a time. When the end of page is reached, _m_o_r_e
will ring the
+ bell and wait for a <SPACE> or <RETURN>. If a <RETURN> is
entered,
+ _m_o_r_e will print the next line, whereas <SPACE> will
print the next
+ screenful. To exit _m_o_r_e, type "q".
+
+ If the standard output is not a terminal, no queries are
made, and
+ each file is listed with a one-line header and two lines of
separa-
+ tion.
+
+ "show -draft" will list the file <mh-dir>/draft if it exists.
+
+ If the profile entry "Unseen-Sequence" is present and
non-empty,
+ then _s_h_o_w will remove each of the messages shown from
each sequence
+ named by the profile entry. This is similar to
the
+ "Previous-Sequence" profile entry supported by all
_M_H commands
+ which take `msgs' or `msg' arguments.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -95-
SHOW(1)
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+ Unseen-Sequence: To name sequences denoting unseen
messages
+ showproc: Program to show messages
+
+
+ _S_e_e _A_l_s_o
+ mhl(1), more(1), next(1), pick(1), prev(1), scan(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to cur
+ `-header'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder. The
last
+ message shown will become the current message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SHOW(1) -96-
SHOW(1)
+
+
+ _B_u_g_s
+ The `-header' switch doesn't work when `msgs' expands to more
than
+ one message. If the _s_h_o_w_p_r_o_c is _m_h_l,
then is problem can be cir-
+ cumvented by referencing the "messagename" field in the
_m_h_l format
+ file.
+
+ _S_h_o_w updates the user's context before showing the
message. Hence
+ _s_h_o_w will mark messages as seen prior to the user
actually seeing
+ them. This is generally not a problem, unless the user
relies on
+ the "unseen" messages mechanism, and interrupts
_s_h_o_w while it is
+ showing "unseen" messages.
+
+ If _s_h_o_w_p_r_o_c is _m_h_l, then _s_h_o_w
uses a built-in _m_h_l: it does not ac-
+ tually run the _m_h_l program. Hence, if you
define your own
+ _s_h_o_w_p_r_o_c, don't call it _m_h_l since
_s_h_o_w won't run it.
+
+ If _m_o_r_e (1) is your showproc (the default), then
avoid running _s_h_o_w
+ in the background with only its standard output piped to
another
+ process, as in
+
+ show | imprint &
+
+ Due to a bug in _m_o_r_e, show will go into a "tty
input" state. To
+ avoid this problem, re-direct _s_h_o_w's diagnostic
output as well.
+ For users of _c_s_h:
+
+ show |& imprint &
+
+ For users of _s_h:
+
+ show 2>&1 | imprint &
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -97-
SLOCAL(1)
+
+
+ _N_A_M_E
+ slocal - special local mail delivery
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/slocal [address info sender]
+ [-addr address] [-info data] [-sender sender]
+ [-user username] [-mailbox mbox] [-file file]
+ [-maildelivery deliveryfile] [-verbose] [-noverbose]
[-debug]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_l_o_c_a_l is a program designed to allow you to have
your inbound mail
+ processed according to a complex set of selection criteria.
You do
+ not normally invoke _s_l_o_c_a_l yourself, rather
_s_l_o_c_a_l is invoked on
+ your behalf by your system's Message Transfer Agent.
+
+ The message selection criteria used by _s_l_o_c_a_l is
specified in the
+ file ._m_a_i_l_d_e_l_i_v_e_r_y in the user's
home directory. The format of
+ this file is given below.
+
+ The message delivery address and message sender are
determined from
+ the Message Transfer Agent envelope information, if
possible.
+ Under _S_e_n_d_M_a_i_l, the sender will obtained
from the UUCP "From "
+ line, if present. The user may override these values with
command
+ line arguments, or arguments to the `-addr' and `-sender'
switches.
+
+ The message is normally read from the standard input. The
`-file'
+ switch sets the name of the file from which the message
should be
+ read, instead of reading stdin. The `-user' switch tells
_s_l_o_c_a_l
+ the name of the user for whom it is delivering mail. The
`-mail-
+ box' switch tells _s_l_o_c_a_l the name of the user's
maildrop file.
+
+ The `-info' switch may be used to pass an arbitrary
argument to
+ sub-processes which _s_l_o_c_a_l may invoke on your
behalf. The `-ver-
+ bose' switch causes _s_l_o_c_a_l to give information on
stdout about its
+ progress. The `-debug' switch produces more verbose
debugging out-
+ put on stderr.
+
+
+ _M_e_s_s_a_g_e _T_r_a_n_s_f_e_r _A_g_e_n_t_s
+
+ If your MTA is _S_e_n_d_M_a_i_l, you should include
the line
+
+ "| /usr/local/lib/mh/slocal -user username"
+
+ in your .forward file in your home directory. This will
cause
+ _S_e_n_d_M_a_i_l to invoke _s_l_o_c_a_l on your
behalf.
+
+ If your MTA is _M_M_D_F-_I, you should
(symbolically) link
+ /usr/local/lib/mh/slocal to the file bin/rcvmail in
your home
+ directory. This will cause _M_M_D_F-_I to invoke
_s_l_o_c_a_l on your behalf
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -98-
SLOCAL(1)
+
+
+ with the correct "_a_d_d_r_e_s_s _i_n_f_o
_s_e_n_d_e_r" arguments.
+
+ If your MTA is _M_M_D_F-_I_I, then you should not
use _s_l_o_c_a_l. An
+ equivalent functionality is already provided by
_M_M_D_F-_I_I; see mail-
+ delivery(5) for details.
+
+
+ _T_h_e _M_a_i_l_d_e_l_i_v_e_r_y _F_i_l_e
+
+
+ The ._m_a_i_l_d_e_l_i_v_e_r_y file controls how
local delivery is performed.
+ Each line of this file consists of five fields,
separated by
+ white-space or comma. Since double-quotes are honored, these
char-
+ acters may be included in a single argument by enclosing the
entire
+ argument in double-quotes. A double-quote can be
included by
+ preceding it with a backslash. Lines beginning with
`#' are
+ ignored. The format of each line in the
._m_a_i_l_d_e_l_i_v_e_r_y file is:
+
+
+ header pattern action result string
+
+ header:
+ The name of a header field that is to be searched for a
pat-
+ tern. This is any field in the headers of the
message that
+ might be present. The following special fields are
also
+ defined:
+
+ _s_o_u_r_c_e the out-of-band sender information
+ _a_d_d_r the address that was used to cause
delivery to the
+ recipient
+ _d_e_f_a_u_l_t this matches _o_n_l_y if
the message hasn't been
+ delivered yet
+ * this always matches
+
+ pattern:
+ The sequence of characters to match in the specified
header
+ field. Matching is case-insensitive, but does not use
regular
+ expressions.
+
+ action:
+ The action to take to deliver the message:
+
+ _d_e_s_t_r_o_y This action always succeeds.
+
+ _f_i_l_e or > Append the message to the file named
by string. The
+ message is appended to the file in the
maildrop for-
+ mat which is used by your message transport
system.
+ If the message can be appended to the
file, then
+ this action succeeds. When writing to the
file, a
+ "Delivery-Date: date" header is added which
indi-
+ cates the date and time that message was
appended to
+ the file.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -99-
SLOCAL(1)
+
+
+ _m_b_o_x Identical to _f_i_l_e, but always
appends the message
+ using the format used by _p_a_c_k_f
(the MMDF mailbox
+ format).
+
+ _p_i_p_e or | Pipe the message as the standard input
to the com-
+ mand named by string, using the Bourne shell
_s_h(1)
+ to interpret the string. Prior to giving the
string
+ to the shell, it is expanded with the
following
+ built-in variables:
+
+ $(sender) the out-of-band sender information
+ $(address) the address that was used to
cause
+ delivery to the recipient
+ $(size) the size of the message in bytes
+ $(reply-to) either the "Reply-To:" or "From:"
field
+ of the message
+ $(info) the out-of-band information specified
+ _q_p_i_p_e or
+ <_c_a_r_e_t> Similar to _p_i_p_e, but
executes the command directly,
+ after built-in variable expansion, without
assis-
+ tance from the shell. This action can be
used to
+ avoid quoting special characters which your
shell
+ might interpret.
+
+ result:
+ Indicates how the action should be performed:
+
+ _A Perform the action. If the action
succeeds, then
+ the message is considered delivered.
+
+ _R Perform the action. Regardless of the
outcome of
+ the action, the message is not considered
delivered.
+
+ ? Perform the action only if the message has not
been
+ delivered. If the action succeeds, then the
message
+ is considered delivered.
+
+ _N Perform the action only if the message has
not been
+ delivered and the previous action
succeeded. If
+ this action succeeds, then the message is
considered
+ delivered.
+
+ To summarize, here's an example:
+
+ #_f_i_e_l_d _p_a_t_t_e_r_n _a_c_t_i_o_n
_r_e_s_u_l_t _s_t_r_i_n_g
+ # lines starting with a '#' are ignored, as are blank lines
+ #
+ # file mail with mmdf2 in the "To:" line into file mmdf2.log
+ _T_o _m_m_d_f_2 _f_i_l_e _A
_m_m_d_f_2._l_o_g
+ # Messages from mmdf pipe to the program err-message-archive
+ _F_r_o_m _m_m_d_f _p_i_p_e _A
/_b_i_n/_e_r_r-_m_e_s_s_a_g_e-_a_r_c_h_i_v_e
+ # Anything with the "Sender:" address "mh-workers"
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -100-
SLOCAL(1)
+
+
+ # file in mh.log if not filed already
+ _S_e_n_d_e_r _m_h-_w_o_r_k_e_r_s
_f_i_l_e ? _m_h._l_o_g
+ # "To:" unix - put in file unix-news
+ _T_o _U_n_i_x > _A
_u_n_i_x-_n_e_w_s
+ # if the address is jpo=ack - send an acknowledgement copy
back
+ _a_d_d_r _j_p_o=_a_c_k | _R
"/_b_i_n/_r_e_s_e_n_d -_r $(_r_e_p_l_y-_t_o)"
+ # anything from steve - destroy!
+ _F_r_o_m _s_t_e_v_e _d_e_s_t_r_o_y
_A -
+ # anything not matched yet - put into mailbox
+ _d_e_f_a_u_l_t - > ?
_m_a_i_l_b_o_x
+ # always run rcvtty
+ * - | _R
/_m_h/_l_i_b/_r_c_v_t_t_y
+
+ The file is always read completely, so that several matches
can be
+ made and several actions can be taken. The
._m_a_i_l_d_e_l_i_v_e_r_y file must
+ be owned either by the user or by root, and must be writable
only
+ by the owner. If the ._m_a_i_l_d_e_l_i_v_e_r_y
file cannot be found, or does
+ not perform an action which delivers the message, then the
file
+ /usr/local/lib/mh/maildelivery is read according to the same
rules.
+ This file must be owned by the root and must be writable
only by
+ the root. If this file cannot be found or does not
perform an
+ action which delivers the message, then standard delivery
to the
+ user's maildrop is performed.
+
+
+ _S_u_b-_p_r_o_c_e_s_s _e_n_v_i_r_o_n_m_e_n_t
+
+ When a process is invoked, its environment is: the
user/group-ids
+ are set to recipient's ids; the working directory
is the
+ recipient's home directory; the umask is 0077; the process
has no
+ /dev/tty; the standard input is set to the message; the
standard
+ output and diagnostic output are set to /dev/null; all other
file-
+ descriptors are closed; the envariables $USER, $HOME,
$SHELL are
+ set appropriately, and no other envariables exist.
+
+ The process is given a certain amount of time to execute.
If the
+ process does not exit within this limit, the process will
be ter-
+ minated with extreme prejudice. The amount of time is
calculated
+ as ((size x 60) + 300) seconds, where size is the number of
bytes
+ in the message.
+
+ The exit status of the process is consulted in determining
the suc-
+ cess of the action. An exit status of zero means that the
action
+ succeeded. Any other exit status (or abnormal termination)
means
+ that the action failed.
+
+ In order to avoid any time limitations, you might implement a
pro-
+ cess that began by _f_o_r_k_i_n_g. The parent would
return the appropri-
+ ate value immediately, and the child could continue on, doing
what-
+ ever it wanted for as long as it wanted. This approach is
somewhat
+ risky if the parent is going to return an exit status of
zero. If
+ the parent is going to return a non-zero exit status,
then this
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SLOCAL(1) -101-
SLOCAL(1)
+
+
+ approach can lead to quicker delivery into your maildrop.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor MH tailor file
+ $HOME/.maildelivery The file controlling
local delivery
+ /usr/local/lib/mh/maildelivery Rather than the standard
file
+ /usr/spool/mail/$USER The default maildrop
+
+
+ _S_e_e _A_l_s_o
+ rcvstore(1), mhook(1), mh-format(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-noverbose'
+ `-maildelivery .maildelivery'
+ `-mailbox /usr/spool/mail/$USER'
+ `-file' defaults to stdin
+ `-user' defaults to the current user
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ _S_l_o_c_a_l is designed to be backward-compatible with
the _m_a_i_l_d_e_l_i_v_e_r_y
+ facility provided by _M_M_D_F-_I_I. Thus, the
._m_a_i_l_d_e_l_i_v_e_r_y file syntax
+ is limited, as is the functionality of _s_l_o_c_a_l.
+
+ In addition to an exit status of zero, the _M_M_D_F
values _R_P__M_O_K (32)
+ and _R_P__O_K (9) mean that the message has been fully
delivered. Any
+ other non-zero exit status, including abnormal termination,
is in-
+ terpreted as the _M_M_D_F value _R_P__M_E_C_H
(200), which means "use an al-
+ ternate route" (deliver the message to the maildrop).
+
+
+ _B_u_g_s
+ Only two return codes are meaningful, others should be.
+
+ _S_l_o_c_a_l is designed to be backwards-compatible
with the _m_a_i_l_d_e_l_i_v_e_r_y
+ functionality provided by MMDF-II.
+
+ Versions of _M_M_D_F with the
_m_a_i_l_d_e_l_i_v_e_r_y mechanism aren't entirely
+ backwards-compatible with earlier versions of _M_M_D_F.
If you have an
+ _M_M_D_F-_I old-style hook, the best you can do is to
have a one-line
+ ._m_a_i_l_d_e_l_i_v_e_r_y file:
+
+ default - pipe A "bin/rcvmail $(address) $(info)
$(sender)"
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -102-
SORTM(1)
+
+
+ _N_A_M_E
+ sortm - sort messages
+
+ _S_Y_N_O_P_S_I_S
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _S_o_r_t_m sorts the specified messages in the named
folder according to
+ the chronological order of the "Date:" field of each message.
+
+ The `-verbose' switch directs _s_o_r_t_m to tell the
user the general
+ actions that it is taking to place the folder in sorted order.
+
+ The `-datefield field' switch tells _s_o_r_t_m the name
of the field to
+ use when making the date comparison. If the user has a
special
+ field in each message, such as "BB-Posted:" or
"Delivery-Date:",
+ then the `-datefield' switch can be used to direct
_s_o_r_t_m which
+ field to examine.
+
+ The `-textfield field' switch causes _s_o_r_t_m to sort
messages by the
+ specified text field. If this field is "subject", any
leading
+ "re:" is stripped off. In any case, all characters except
letters
+ and numbers are stripped and the resulting strings are
sorted
+ datefield-major, textfield-minor, using a case insensitive
com-
+ parison.
+
+ With `-textfield field', if `-limit days' is specified,
messages
+ with similar textfields that are dated within `days' of each
other
+ appear together. Specifying `-nolimit' makes the limit
infinity.
+ With `-limit 0', the sort is instead made
textfield-major,
+ date-minor.
+
+ For example, to order a folder by date-major, subject-minor,
use:
+
+ sortm -textfield subject +folder
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Current-Folder: To find the default current folder
+
+
+ _S_e_e _A_l_s_o
+ folder (1)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ SORTM(1) -103-
SORTM(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `+folder' defaults to the current folder
+ `msgs' defaults to all
+ `-datefield date'
+ `-notextfield'
+ `-noverbose'
+ `-nolimit'
+
+
+ _C_o_n_t_e_x_t
+ If a folder is given, it will become the current folder.
If the
+ current message is moved, _s_o_r_t_m will preserve
its status as
+ current.
+
+
+ _H_i_s_t_o_r_y
+ Timezones used to be ignored when comparing dates: they
aren't any
+ more.
+
+ Messages which were in the folder, but not specified by
`msgs',
+ used to be moved to the end of the folder; now such
messages are
+ left untouched.
+
+ _S_o_r_t_m sometimes did not preserve the message
numbering in a folder
+ (e.g., messages 1, 3, and 5, might have been renumbered to
1, 2, 3
+ after sorting). This was a bug, and has been fixed. To
compress
+ the message numbering in a folder, use "_f_o_l_d_e_r
-_p_a_c_k" as always.
+
+
+ _B_u_g_s
+ If _s_o_r_t_m encounters a message without a date-field,
or if the mes-
+ sage has a date-field that _s_o_r_t_m cannot parse,
then _s_o_r_t_m attempts
+ to keep the message in the same relative position. This
does not
+ always work. For instance, if the first message encountered
lacks
+ a date which can be parsed, then it will usually be placed
at the
+ end of the messages being sorted.
+
+ When _s_o_r_t_m complains about a message which it can't
temporally ord-
+ er, it complains about the message number _p_r_i_o_r
to sorting. It
+ should indicate what the message number will be
_a_f_t_e_r sorting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ VMH(1) -104-
VMH(1)
+
+
+ _N_A_M_E
+ vmh - visual front-end to MH
+
+ _S_Y_N_O_P_S_I_S
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _v_m_h is a program which implements the server side of
the _M_H window
+ management protocol and uses _c_u_r_s_e_s (3)
routines to maintain a
+ split-screen interface to any program which implements the
client
+ side of the protocol. This latter program, called the
_v_m_h_p_r_o_c, is
+ specified using the `-vmhproc program' switch.
+
+ The upshot of all this is that one can run _m_s_h on a
display termi-
+ nal and get a nice visual interface. To do this, for
example, just
+ add the line
+
+ mshproc: vmh
+
+ to your .mh_profile. (This takes advantage of the fact that
_m_s_h is
+ the default _v_m_h_p_r_o_c for _v_m_h.)
+
+ In order to facilitate things, if the `-novmhproc' switch is
given,
+ and _v_m_h can't run on the user's terminal, the
_v_m_h_p_r_o_c is run
+ directly without the window management protocol.
+
+ After initializing the protocol, _v_m_h prompts the user
for a command
+ to be given to the client. Usually, this results in output
being
+ sent to one or more windows. If a output to a window would
cause
+ it to scroll, _v_m_h prompts the user for instructions,
roughly per-
+ mitting the capabilities of _l_e_s_s or _m_o_r_e
(e.g., the ability to
+ scroll backwards and forwards):
+
+ SPACE advance to the next windowful
+ RETURN * advance to the next line
+ y * retreat to the previous line
+ d * advance to the next ten lines
+ u * retreat to the previous ten lines
+ g * go to an arbitrary line
+ (preceed g with the line number)
+ G * go to the end of the window
+ (if a line number is given, this acts like
`g')
+ CTRL-L refresh the entire screen
+ h print a help message
+ q abort the window
+
+ (A `*' indicates that a numeric prefix is meaningful for this
com-
+ mand.)
+
+ Note that if a command resulted in more than one window's
worth of
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ VMH(1) -105-
VMH(1)
+
+
+ information being displayed, and you allow the command
which is
+ generating information for the window to gracefully finish
(i.e.,
+ you don't use the `q' command to abort information being
sent to
+ the window), then _v_m_h will give you one last change to
peruse the
+ window. This is useful for scrolling back and forth.
Just type
+ `q' when you're done.
+
+ To abnormally terminate _v_m_h (without core dump), use
<QUIT> (usu-
+ ally CTRL-\). For instance, this does the "right" thing
with _b_b_c
+ and _m_s_h.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+
+
+ _S_e_e _A_l_s_o
+ msh(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt (vmh) '
+ `-vmhproc msh'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _v_m_h. Therefore,
one must usu-
+ ally place the argument to this switch inside double-quotes.
+
+ At present, there is no way to pass signals (e.g., interrupt,
quit)
+ to the client. However, generating QUIT when _v_m_h is
reading a com-
+ mand from the terminal is sufficient to tell the client to go
away
+ quickly.
+
+ Acts strangely (loses peer or botches window management
protocol
+ with peer) on random occasions.
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -106-
WHATNOW(1)
+
+
+ _N_A_M_E
+ whatnow - prompting front-end for send
+
+ _S_Y_N_O_P_S_I_S
+ whatnow [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file]
[-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_a_t_n_o_w is the default program that queries
the user about the
+ disposition of a composed draft. It is normally invoked by
one of
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, or _r_e_p_l
after the initial edit.
+
+ When started, the editor is started on the draft (unless
`-noedit'
+ is given, in which case the initial edit is suppressed).
Then,
+ _w_h_a_t_n_o_w repetitively prompts the user with
"What now?" and awaits a
+ response. The valid responses are:
+
+ display to list the message being
distributed/replied-to on
+ the terminal
+ edit to re-edit using the same editor that was
used on the
+ preceding round unless a profile entry
+ "<lasteditor>-next: <editor>" names an
alternate editor
+ edit <editor> to invoke <editor> for further editing
+ list to list the draft on the terminal
+ push to send the message in the background
+ quit to terminate the session and preserve the
draft
+ quit -delete to terminate, then delete the draft
+ refile +folder to refile the draft into the given folder
+ send to send the message
+ send -watch to cause the delivery process to be monitored
+ whom to list the addresses that the message will
go to
+ whom -check to list the addresses and verify that they are
+ acceptable to the transport service
+
+ For the edit response, any valid switch to the editor is
valid.
+ Similarly, for the send and whom responses, any valid
switch to
+ _s_e_n_d (1) and _w_h_o_m (1) commands, respectively,
are valid. For the
+ push response, any valid switch to _s_e_n_d (1) is
valid (as this
+ merely invokes _s_e_n_d with the `-push' option).
For the _r_e_f_i_l_e
+ response, any valid switch to the
_f_i_l_e_p_r_o_c is valid. For the
+ display and list responses, any valid argument to the
_l_p_r_o_c is
+ valid. If any non-switch arguments are present, then the
pathname
+ of the draft will be excluded from the argument list given
to the
+ _l_p_r_o_c (this is useful for listing another _M_H
message).
+
+ See _m_h-_p_r_o_f_i_l_e (5) for further information
about how editors are
+ used by MH. It also discusses how complex envariables can
be used
+ to direct _w_h_a_t_n_o_w's actions.
+
+ The `-prompt string' switch sets the prompting string for
_w_h_a_t_n_o_w.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -107-
WHATNOW(1)
+
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/draft The draft file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Editor: To override the default editor
+ <lasteditor>-next: To name an editor to be used after exit
from
+ <lasteditor>
+ fileproc: Program to refile the message
+ lproc: Program to list the contents of a message
+ sendproc: Program to use to send the message
+ whomproc: Program to determine who a message would
go to
+
+
+ _S_e_e _A_l_s_o
+ send(1), whom(1)
+
+
+ _D_e_f_a_u_l_t_s
+ `-prompt "What Now? "'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-prompt' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _w_h_a_t_n_o_w.
Therefore, one must
+ usually place the argument to this switch inside
double-quotes.
+
+ If the initial edit fails, _w_h_a_t_n_o_w deletes your
draft (by renaming
+ it with a leading comma); failure of a later edit
preverves the
+ draft.
+
+ If _w_h_a_t_n_o_w_p_r_o_c is
_w_h_a_t_n_o_w, then _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l use a
+ built-in _w_h_a_t_n_o_w, and do not actually run
the _w_h_a_t_n_o_w program.
+ Hence, if you define your own
_w_h_a_t_n_o_w_p_r_o_c, don't call it _w_h_a_t_n_o_w
+ since it won't be run.
+
+ If _s_e_n_d_p_r_o_c is _s_e_n_d, then
_w_h_a_t_n_o_w uses a built-in _s_e_n_d, it does not
+ actually run the _s_e_n_d program. Hence, if you
define your own
+ _s_e_n_d_p_r_o_c, don't call it _s_e_n_d since
_w_h_a_t_n_o_w won't run it.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHATNOW(1) -108-
WHATNOW(1)
+
+
+ _N_A_M_E
+ whom - report to whom a message would go
+
+ _S_Y_N_O_P_S_I_S
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [file] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _W_h_o_m is used to expand the headers of a message
into a set of
+ addresses and optionally verify that those addresses are
deliver-
+ able at that time (if `-check' is given).
+
+ The `-draftfolder +folder' and `-draftmessage msg' switches
invoke
+ the _M_H draft folder facility. This is an advanced (and
highly use-
+ ful) feature. Consult the Advanced Features section of
the _M_H
+ manual for more information.
+
+ The files specified by the profile entry "Aliasfile:" and any
addi-
+ tional alias files given by the `-alias aliasfile' switch
will be
+ read (more than one file, each preceeded by `-alias',
can be
+ named). See _m_h-_a_l_i_a_s (5) for more information.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+ Draft-Folder: To find the default draft-folder
+ Aliasfile: For a default alias file
+ postproc: Program to post the message
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5), post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ `file' defaults to <mh-dir>/draft
+ `-nocheck'
+ `-alias /usr/local/lib/mh/MailAliases'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ WHOM(1) -109-
WHOM(1)
+
+
+ _B_u_g_s
+ With the `-check' option, _w_h_o_m makes no guarantees
that the ad-
+ dresses listed as being ok are really deliverable, rather,
an ad-
+ dress being listed as ok means that at the time that
_w_h_o_m was run
+ the address was thought to be deliverable by the transport
service.
+ For local addresses, this is absolute; for network
addresses, it
+ means that the host is known; for uucp addresses, it (often)
means
+ that the _U_U_C_P network is available for use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+ -110-
+
+
+ _M_O_R_E _D_E_T_A_I_L_S
+
+ This section describes some of the more intense points
of the _M_H
+ system, by expanding on topics previously discussed.
The format
+ presented conforms to the standard form for the
description of UNIX
+ documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -111-
MH-ALIAS(5)
+
+
+ _N_A_M_E
+ mh-alias - alias file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ This describes both _M_H personal alias files and the
(primary) alias
+ file for mail delivery, the file
+
+ /usr/local/lib/mh/MailAliases
+
+ It does not describe aliases files used by the message
transport
+ system. Each line of the alias file has the format:
+
+ alias : address-group
+ or
+ alias ; address-group
+ or
+ < alias-file
+ or
+ ; comment
+
+ where:
+
+ address-group := address-list
+ | "<" file
+ | "=" UNIX-group
+ | "+" UNIX-group
+ | "*"
+
+ address-list := address
+ | address-list, address
+
+ Continuation lines in alias files end with `\' followed by
the new-
+ line character.
+
+ Alias-file and file are UNIX file names. UNIX-group is a
group
+ name (or number) from /_e_t_c/_g_r_o_u_p. An
address is a "simple"
+ Internet-style address. Througout this file, case is
ignored,
+ except for alias-file names.
+
+ If the line starts with a `<', then the file named after the
`<' is
+ read for more alias definitions. The reading is done
recursively,
+ so a `<' may occur in the beginning of an alias file
with the
+ expected results.
+
+ If the address-group starts with a `<', then the file named
after
+ the `<' is read and its contents are added to the
address-list for
+ the alias.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -112-
MH-ALIAS(5)
+
+
+ If the address-group starts with an `=', then the file
/_e_t_c/_g_r_o_u_p
+ is consulted for the UNIX-group named after the `='. Each
login
+ name occurring as a member of the group is added to
the
+ address-list for the alias.
+
+ In contrast, if the address-group starts with a `+', then the
file
+ /_e_t_c/_g_r_o_u_p is consulted to determine the
group-id of the UNIX-group
+ named after the `+'. Each login name occurring in the
/_e_t_c/_p_a_s_s_w_d
+ file whose group-id is indicated by this group is added
to the
+ address-list for the alias.
+
+ If the address-group is simply `*', then the file
/_e_t_c/_p_a_s_s_w_d is
+ consulted and all login names with a userid greater than some
magic
+ number (usually 200) are added to the address-list for the
alias.
+
+ In match, a trailing * on an alias will match just about
anything
+ appropriate. (See example below.)
+
+ An approximation of the way aliases are resolved at posting
time is
+ (it's not really done this way):
+
+ 1) Build a list of all addresses from the message
to be
+ delivered, eliminating duplicate addresses.
+
+ 2) If this draft originated on the local host, then for
those
+ addresses in the message that have no host specified,
perform
+ alias resolution.
+
+ 3) For each line in the alias file, compare "alias"
against
+ all of the existing addresses. If a match, remove the
matched
+ "alias" from the address list, and add each new address
in the
+ address-group to the address list if it is not already
on the
+ list. The alias itself is not usually output,
rather the
+ address-group that the alias maps to is output
instead. If
+ "alias" is terminated with a `;' instead of a `:', then
both
+ the "alias" and the address are output in the correct
format.
+ (This makes replies possible since _M_H aliases and
personal
+ aliases are unknown to the mail transport system.)
+
+ Since the alias file is read line by line, forward references
work,
+ but backward references are not recognized, thus, there
is no
+ recursion.
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -113-
MH-ALIAS(5)
+
+
+ Example:
+ </usr/local/lib/mh/BBoardAliases
+ sgroup: fred, fear, freida
+ b-people: Blind List: bill, betty;
+ fred: address@hidden
+ UNIX-committee: <unix.aliases
+ staff: =staff
+ wheels: +wheel
+ everyone: *
+ news.*: news
+
+ The first line says that more aliases should immediately be
read
+ from the file
/_u_s_r/_l_o_c_a_l/_l_i_b/_m_h/_B_B_o_a_r_d_A_l_i_a_s_e_s.
Following this,
+ "fred" is defined as an alias for "address@hidden", and
"sgroup" is
+ defined as an alias for the three names "address@hidden",
"fear", and
+ "freida".
+
+ The alias "b-people" is a blind list which includes the
addresses
+ "bill" and "betty"; the message will be delieved to
those
+ addresses, but the message header will show only "Blind
List: ;"
+ (not the addresses).
+
+ Next, the definition of "UNIX-committee" is given by
reading the
+ file _u_n_i_x._a_l_i_a_s_e_s in the users _M_H
directory, "staff" is defined as
+ all users who are listed as members of the group "staff"
in the
+ /_e_t_c/_g_r_o_u_p file, and "wheels" is defined
as all users whose
+ group-id in /_e_t_c/_p_a_s_s_w_d is equivalent to
the "wheel" group.
+
+ Finally, "everyone" is defined as all users with a
user-id in
+ /_e_t_c/_p_a_s_s_w_d greater than 200, and all
aliases of the form
+ "news.<anything>" are defined to be "news".
+
+ The key thing to understand about aliasing in _M_H is that
aliases in
+ _M_H alias files are expanded into the headers of
messages posted.
+ This aliasing occurs first, at posting time, without the
knowledge
+ of the message transport system. In contrast, once the
message
+ transport system is given a message to deliver to a
list of
+ addresses, for each address that appears to be local, a
system-wide
+ alias file is consulted. These aliases are NOT expanded
into the
+ headers of messages delivered.
+
+ _H_e_l_p_f_u_l _H_i_n_t_s
+
+ To use aliasing in _M_H quickly, do the following:
+
+ First, in your ._m_h__p_r_o_f_i_l_e, choose a
name for your alias file,
+ say "aliases", and add the line:
+
+ Aliasfile: aliases
+
+ Second, create the file "aliases" in your _M_H
directory.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-ALIAS(5) -114-
MH-ALIAS(5)
+
+
+ Third, start adding aliases to your "aliases"
file as
+ appropriate.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Aliasfile: For a default alias file
+
+
+ _S_e_e _A_l_s_o
+ ali(1), send(1), whom(1), group(5), passwd(5), conflict(8),
post(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ In previous releases of _M_H, only a single, system-wide
mh-alias
+ file was supported. This led to a number of problems,
since only
+ mail-system administrators were capable of (un)defining
aliases.
+ Hence, the semantics of mh-alias were extended to support
personal
+ alias files. Users of _M_H no longer need to bother
mail-system ad-
+ ministrators for keeping information in the system-wide alias
file,
+ as each _M_H user can create/modify/remove aliases at will
from any
+ number of personal files.
+
+
+ _B_u_g_s
+ Although the forward-referencing semantics of
_m_h-_a_l_i_a_s files
+ prevent recursion, the "< alias-file" command may defeat
this.
+ Since the number of file descriptors is finite (and very
limited),
+ such infinite recursion will terminate with a meaningless
diagnos-
+ tic when all the fds are used up.
+
+ Forward references do not work correctly inside blind lists.
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -115-
MH-FORMAT(5)
+
+
+ _N_A_M_E
+ mh-format - format file for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ some _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Several _M_H commands utilize either a _f_o_r_m_a_t
string or a _f_o_r_m_a_t file
+ during their execution. For example, _s_c_a_n (1) uses a
format string
+ which directs it how to generate the scan listing for each
message;
+ _r_e_p_l (1) uses a format file which directs it how
to generate the
+ reply to a message, and so on.
+
+ Format strings are designed to be efficiently parsed by
_M_H which
+ means they are not necessarily simple to write and
understand.
+ This means that novice, casual, or even advanced users of
_M_H should
+ not have to deal with them. Some canned scan listing
formats are
+ in /usr/local/lib/mh/scan.time,
/usr/local/lib/mh/scan.size, and
+ /usr/local/lib/mh/scan.timely. Look in /usr/local/lib/mh for
other
+ _s_c_a_n and _r_e_p_l format files which may have
been written at your
+ site.
+
+ It suffices to have your local _M_H expert actually write
new format
+ commands or modify existing ones. This manual section
explains how
+ to do that. Note: familiarity with the C
_p_r_i_n_t_f routine is
+ assumed.
+
+ A format string consists of ordinary text, and special
multi-
+ character _e_s_c_a_p_e sequences which begin with `%'.
When specifying a
+ format string, the usual C backslash characters are honored:
`\b',
+ `\f', `\n', `\r', and `\t'. Continuation lines in format
files end
+ with `\' followed by the newline character. There are three
types
+ of _e_s_c_a_p_e sequences: header
_c_o_m_p_o_n_e_n_t_s, built-in _f_u_n_c_t_i_o_n_s, and
+ flow _c_o_n_t_r_o_l.
+
+ A _c_o_m_p_o_n_e_n_t escape is specified as
`%{_c_o_m_p_o_n_e_n_t}', and exists for
+ each header found in the message being processed. For
example
+ `%{date}' refers to the "Date:" field of the appropriate
message.
+ All component escapes have a string value. Normally,
component
+ values are compressed by converting any control characters
(tab and
+ newline included) to spaces, then eliding any leading or
multiple
+ spaces. However, commands may give different
interpretations to
+ some component escapes; be sure to refer to each command's
manual
+ entry for complete details.
+
+ A _f_u_n_c_t_i_o_n escape is specified as
`%(_f_u_n_c_t_i_o_n)'. All functions are
+ built-in, and most have a string or numeric value.
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -116-
MH-FORMAT(5)
+
+
+ _C_o_n_t_r_o_l-_f_l_o_w _e_s_c_a_p_e_s
+
+ A _c_o_n_t_r_o_l escape is one of: `%<', `%?', `%|',
or `%>'. These are
+ combined into the conditional execution construct:
+
+ %<condition
+ _f_o_r_m_a_t _t_e_x_t _1
+ %?condition2
+ _f_o_r_m_a_t _t_e_x_t _2
+ %?condition3
+ _f_o_r_m_a_t _t_e_x_t _3
+ ...
+ %|
+ _f_o_r_m_a_t _t_e_x_t _N
+ %>
+
+ Extra white space is shown here only for clarity. These
constructs
+ may be nested without ambiguity. They form a
general
+ if-elseif-else-endif block where only one of the
_f_o_r_m_a_t _t_e_x_t seg-
+ ments is interpreted.
+
+ The `%<' and `%?' control escapes causes a condition
to be
+ evaluated. This condition may be either a
_c_o_m_p_o_n_e_n_t or a _f_u_n_c_t_i_o_n.
+ The four constructs have the following syntax:
+
+ %<{component}
+ %<(function)
+ %?{component}
+ %?(function)
+
+ These control escapes test whether the function or component
value
+ is non-zero (for integer-valued escapes), or non-empty
(for
+ string-valued escapes).
+
+ If this test evaulates true, then the format text up to the
next
+ corresponding control escape (one of `%|', `%?', or `%>') is
inter-
+ preted normally. Next, all format text (if any) up
to the
+ corresponding `%>' control escape is skipped. The `%>'
control
+ escape is not interpreted; normal interpretation resumes
after the
+ `%>' escape.
+
+ If the test evaluates false, however, then the format text
up to
+ the next corresponding control escape (again, one of `%|',
`%?', or
+ `%>') is skipped, instead of being interpreted. If the
control
+ escape encountered was `%?', then the condition
associated with
+ that control escape is evaluated, and interpretation proceeds
after
+ that test as described in the previous paragraph. If the
control
+ escape encountered was `%|', then the format text up
to the
+ corresponding `%>' escape is interpreted normally. As
above, the
+ `%>' escape is not interpreted and normal interpretation
resumes
+ after the `%>' escape.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -117-
MH-FORMAT(5)
+
+
+ The `%?' control escape and its following format text is
optional,
+ and may be included zero or more times. The `%|' control
escape
+ and its following format text is also optional, and may be
included
+ zero or one times.
+
+
+ _F_u_n_c_t_i_o_n _e_s_c_a_p_e_s
+
+ Most functions expect an argument of a particular type:
+
+ _A_r_g_u_m_e_n_t _D_e_s_c_r_i_p_t_i_o_n
_E_x_a_m_p_l_e _S_y_n_t_a_x
+ literal A literal number, %(_f_u_n_c 1234)
+ or string %(_f_u_n_c text string)
+ comp Any header component
%(_f_u_n_c{_i_n-_r_e_p_l_y-_t_o})
+ date A date component %(_f_u_n_c{_d_a_t_e})
+ addr An address component %(_f_u_n_c{_f_r_o_m})
+ expr An optional component,
%(_f_u_n_c(_f_u_n_c_2))
+ function or control, %(_f_u_n_c
%<{_r_e_p_l_y-_t_o}%|%{_f_r_o_m}%>)
+ perhaps nested
%(_f_u_n_c(_f_u_n_c_2{_c_o_m_p}))
+
+ The types _d_a_t_e and _a_d_d_r have the same syntax
as _c_o_m_p, but require
+ that the header component be a date string, or address
string,
+ respectively.
+
+ All arguments except those of type _e_x_p_r are required.
For the _e_x_p_r
+ argument type, the leading `%' must be omitted for
component and
+ function escape arguments, and must be present (with a
leading
+ space) for control escape arguments.
+
+ The evaluation of format strings is based on a simple machine
with
+ an integer register _n_u_m, and a text string register
_s_t_r. When a
+ function escape is processed, if it accepts an optional
_e_x_p_r argu-
+ ment which is not present, it reads the current value of
either _n_u_m
+ or _s_t_r as appropriate.
+
+
+ _R_e_t_u_r_n _v_a_l_u_e_s
+
+ Component escapes write the value of their message header in
_s_t_r.
+ Function escapes write their return value in _n_u_m
for functions
+ returning _i_n_t_e_g_e_r or _b_o_o_l_e_a_n
values, and in _s_t_r for functions
+ returning string values. (The _b_o_o_l_e_a_n type is
a subset of integers
+ with usual values 0=false and 1=true.) Control escapes
return a
+ _b_o_o_l_e_a_n value, and set _n_u_m.
+
+ All component escapes, and those function escapes which
return an
+ _i_n_t_e_g_e_r or _s_t_r_i_n_g value, pass
this value back to their caller in
+ addition to setting _s_t_r or _n_u_m. These escapes
will print out this
+ value unless called as part of an argument to another
escape
+ sequence. Escapes which return a _b_o_o_l_e_a_n value
do pass this value
+ back to their caller in _n_u_m, but will never print out
the value.
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -118-
MH-FORMAT(5)
+
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ msg integer message number
+ cur integer message is current
+ size integer size of message
+ strlen integer length of _s_t_r
+ width integer output buffer size in bytes
+ charleft integer bytes left in output buffer
+ timenow integer seconds since the UNIX epoch
+ me string the user's mailbox
+ eq literal boolean _n_u_m == _a_r_g
+ ne literal boolean _n_u_m != _a_r_g
+ gt literal boolean _n_u_m > _a_r_g
+ match literal boolean _s_t_r contains _a_r_g
+ amatch literal boolean _s_t_r starts with _a_r_g
+ plus literal integer _a_r_g plus _n_u_m
+ minus literal integer _a_r_g minus _n_u_m
+ divide literal integer _n_u_m divided by _a_r_g
+ modulo literal integer _n_u_m modulo _a_r_g
+ num literal integer Set _n_u_m to _a_r_g
+ lit literal string Set _s_t_r to _a_r_g
+ getenv literal string Set _s_t_r to environment
value of _a_r_g
+ profile literal string Set _s_t_r to profile
component _a_r_g value
+ nonzero expr boolean _n_u_m is non-zero
+ zero expr boolean _n_u_m is zero
+ null expr boolean _s_t_r is empty
+ nonnull expr boolean _s_t_r is non-empty
+ void expr Set _s_t_r or _n_u_m
+ comp comp string Set _s_t_r to component text
+ compval comp integer _n_u_m set to
"atoi(_c_o_m_p)"
+ trim expr trim trailing white-space from
_s_t_r
+ putstr expr print _s_t_r
+ putstrf expr print _s_t_r in a fixed width
+ putnum expr print _n_u_m
+ putnumf expr print _n_u_m in a fixed width
+
+ These functions require a date component as an argument:
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ sec date integer seconds of the minute
+ min date integer minutes of the hour
+ hour date integer hours of the day (0-23)
+ wday date integer day of the week (Sun=0)
+ day date string day of the week (abbrev.)
+ weekday date string day of the week
+ sday date integer day of the week known?
+ (0=implicit,-1=unknown)
+ mday date integer day of the month
+ yday date integer day of the year
+ mon date integer month of the year
+ month date string month of the year (abbrev.)
+ lmonth date string month of the year
+ year date integer year (may be > 100)
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -119-
MH-FORMAT(5)
+
+
+ zone date integer timezone in hours
+ tzone date string timezone string
+ szone date integer timezone explicit?
+ (0=implicit,-1=unknown)
+ date2local date coerce date to local timezone
+ date2gmt date coerce date to GMT
+ dst date integer daylight savings in effect?
+ clock date integer seconds since the UNIX epoch
+ rclock date integer seconds prior to current time
+ tws date string official 822 rendering
+ pretty date string user-friendly rendering
+ nodate date integer _s_t_r not a date string
+
+ These functions require an address component as an
argument. The
+ return value of functions noted with `*' pertain only to the
first
+ address present in the header component.
+
+ _F_u_n_c_t_i_o_n _A_r_g_u_m_e_n_t
_R_e_t_u_r_n _D_e_s_c_r_i_p_t_i_o_n
+ proper addr string official 822 rendering
+ friendly addr string user-friendly rendering
+ addr addr string address@hidden or host!mbox
rendering*
+ pers addr string the personal name*
+ note addr string commentary text*
+ mbox addr string the local mailbox*
+ mymbox addr integer the user's addresses?
(0=no,1=yes)
+ host addr string the host domain*
+ nohost addr integer no host was present*
+ type addr integer host type* (0=local,1=network,
+ -1=uucp,2=unknown)
+ path addr string any leading host route*
+ ingrp addr integer address was inside a group*
+ gname addr string name of group*
+ formataddr expr append _a_r_g to _s_t_r as
a
+ (comma separated) address list
+ putaddr literal print _s_t_r address list with
+ _a_r_g as optional label;
+ get line width from _n_u_m
+
+ When escapes are nested, evaluation is done from
inner-most to
+ outer-most. The outer-most escape must begin with `%'; the
inner
+ escapes must not. For example,
+
+ %<(mymbox{from}) To: %{to}%>
+
+ writes the value of the header component "From:" to
_s_t_r; then (_m_y_m_-
+ _b_o_x) reads _s_t_r and writes its result to
_n_u_m; then the control
+ escape evaluates _n_u_m. If _n_u_m is non-zero, the
string "To: " is
+ printed followed by the value of the header component "To:".
+
+ A minor explanation of (_m_y_m_b_o_x{_c_o_m_p}) is
in order. In general, it
+ checks each of the addresses in the header component
"_c_o_m_p" against
+ the user's mailbox name and any
_A_l_t_e_r_n_a_t_e-_M_a_i_l_b_o_x_e_s. It returns
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -120-
MH-FORMAT(5)
+
+
+ true if any address matches, however, it also returns true
if the
+ "_c_o_m_p" header is not present in the message. If
needed, the (_n_u_l_l)
+ function can be used to explicitly test for this condition.
+
+ When a function or component escape is interpreted and the
result
+ will be immediately printed, an optional field width can be
speci-
+ fied to print the field in exactly a given number of
characters.
+ For example, a numeric escape like %4(_s_i_z_e) will
print at most 4
+ digits of the message size; overflow will be indicated by a
`?' in
+ the first position (like `?234'). A string escape like
%4(_m_e) will
+ print the first 4 characters and truncate at the end. Short
fields
+ are padded at the right with the fill character
(normally, a
+ blank). If the field width argument begins with a leading
zero,
+ then the fill character is set to a zero.
+
+ As above, the functions (_p_u_t_n_u_m_f) and
(_p_u_t_s_t_r_f) print their result
+ in exactly the number of characters specified by their
leading
+ field width argument. For example,
%06(_p_u_t_n_u_m_f(_s_i_z_e)) will print
+ the message size in a field six characters wide filled with
leading
+ zeros; %14(_p_u_t_s_t_r_f{_f_r_o_m}) will print
the "From:" header component
+ in fourteen characters with trailing spaces added as
needed. For
+ _p_u_t_s_t_r_f, using a negative value for the field
width causes right-
+ justification of the string within the field, with padding
on the
+ left up to the field width. The functions
(_p_u_t_n_u_m) and (_p_u_t_s_t_r)
+ print their result in the minimum number of characters
required,
+ and ignore any leading field width argument.
+
+ The available output width is kept in an internal
register; any
+ output past this width will be truncated.
+
+ Comments may be inserted in most places where a function
argument
+ is not expected. A comment begins with `%;' and ends with a
(non-
+ escaped) newline.
+
+ With all this in mind, here's the default format string for
_s_c_a_n.
+ It's been divided into several pieces for readability. The
first
+ part is:
+
+ %4(msg)%<(cur)+%| %>%<{replied}-%?{encrypted}E%| %>
+
+ which says that the message number should be printed in
four
+ digits, if the message is the current message then a `+'
else a
+ space should be printed, and if a "Replied:" field is present
then
+ a `-' else if an "Encrypted:" field is present then an `E'
other-
+ wise a space should be printed. Next:
+
+ %02(mon{date})/%02(mday{date})
+
+ the month and date are printed in two digits (zero
filled)
+ separated by a slash. Next,
+
+ %<{date} %|*>
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -121-
MH-FORMAT(5)
+
+
+ If a "Date:" field was present, then a space is printed,
otherwise
+ a `*'. Next,
+
+ %<(mymbox{from})%<{to}To:%14(friendly{to})%>%>
+
+ if the message is from me, and there is a "To:" header, print
`To:'
+ followed by a "user-friendly" rendering of the first address
in the
+ "To:" field. Continuing,
+
+ %<(zero)%17(friendly{from})%>
+
+ if either of the above two tests failed, then the "From:"
address
+ is printed in a "user-friendly" format. And finally,
+
+ %{subject}%<{body}<<%{body}%>
+
+ the subject and initial body (if any) are printed.
+
+ For a more complicated example, next consider the default
_r_e_p_l_c_o_m_p_s
+ format file.
+
+ %(lit)%(formataddr %<{reply-to}
+
+ This clears _s_t_r and formats the "Reply-To:" header if
present. If
+ not present, the else-if clause is executed.
+
+ %?{from}%?{sender}%?{return-path}%>)\
+
+ This formats the "From:", "Sender:" and "Return-Path:"
headers,
+ stopping as soon as one of them is present. Next:
+
+ %<(nonnull)%(void(width))%(putaddr To: )\n%>\
+
+ If the _f_o_r_m_a_t_a_d_d_r result is non-null, it
is printed as an address
+ (with line folding if needed) in a field _w_i_d_t_h
wide with a leading
+ label of "To: ".
+
+
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
+
+ _s_t_r is cleared, and the "To:" and "Cc:" headers,
along with the
+ user's address (depending on what was specified with the
"-cc"
+ switch to _r_e_p_l) are formatted.
+
+ %<(nonnull)%(void(width))%(putaddr cc: )\n%>\
+
+ If the result is non-null, it is printed as above with a
leading
+ label of "cc: ".
+
+ %<{fcc}Fcc: %{fcc}\n%>\
+
+ If a "-fcc folder" switch was given to _r_e_p_l (see
_r_e_p_l (1) for more
+ details about %{_f_c_c}), an "Fcc:" header is output.
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -122-
MH-FORMAT(5)
+
+
+ %<{subject}Subject: Re: %{subject}\n%>\
+
+ If a subject component was present, a suitable reply
subject is
+ output.
+
+ %<{date}In-reply-to: Your message of "\
+
%<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id}
+ %{message-id}%>\n%>\
+ --------
+
+ If a date component was present, an "In-Reply-To:" header is
output
+ with the preface "Your message of ". If the date was
parseable, it
+ is output in a user-friendly format, otherwise it is output
as-is.
+ The message-id is included if present. As with all
plain-text, the
+ row of dashes are output as-is.
+
+ This last part is a good example for a little more
elaboration.
+ Here's that part again in pseudo-code:
+
+ if (comp_exists(date)) then
+ print ("In-reply-to: Your message of \"")
+ if (not_date_string(date.value) then
+ print (date.value)
+ else
+ print (pretty(date.value))
+ endif
+ print ("\"")
+ if (comp_exists(message-id)) then
+ print ("\n\t")
+ print (message-id.value)
+ endif
+ print ("\n")
+ endif
+
+ Although this seems complicated, in point of fact, this
method is
+ flexible enough to extract individual fields and print them
in any
+ format the user desires.
+
+ _F_i_l_e_s
+ None
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ scan(1), repl(1), ap(8), dp(8)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-FORMAT(5) -123-
MH-FORMAT(5)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _H_i_s_t_o_r_y
+ This software was contributed for MH 6.3. Prior to this,
output
+ format specifications were much easier to write, but
considerably
+ less flexible.
+
+
+ _B_u_g_s
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -124-
MH-MAIL(5)
+
+
+ _N_A_M_E
+ mh-mail - message format for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ any _M_H command
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _M_H processes messages in a particular format. It should
be noted
+ that although neither Bell nor Berkeley mailers produce
message
+ files in the format that _M_H prefers, _M_H can read
message files in
+ that antiquated format.
+
+ Each user possesses a mail drop box which initially
receives all
+ messages processed by _p_o_s_t (8). _I_n_c (1) will
read from that drop
+ box and incorporate the new messages found there into the
user's
+ own mail folders (typically `+inbox'). The mail drop box
consists
+ of one or more messages.
+
+ Messages are expected to consist of lines of text.
Graphics and
+ binary data are not handled. No data compression is
accepted. All
+ text is clear ASCII 7-bit data.
+
+ The general "memo" framework of RFC-822 is used. A message
con-
+ sists of a block of information in a rigid format, followed
by gen-
+ eral text with no specified format. The rigidly formatted
first
+ part of a message is called the header, and the free-format
portion
+ is called the body. The header must always exist, but the
body is
+ optional. These parts are separated by an empty line,
i.e., two
+ consecutive newline characters. Within _M_H, the header
and body may
+ be separated by a line consisting of dashes:
+
+ To:
+ cc:
+ Subject:
+ --------
+
+ The header is composed of one or more header items. Each
header
+ item can be viewed as a single logical line of ASCII
characters.
+ If the text of a header item extends across several real
lines, the
+ continuation lines are indicated by leading spaces or tabs.
+
+ Each header item is called a component and is composed of a
keyword
+ or name, along with associated text. The keyword begins
at the
+ left margin, may NOT contain spaces or tabs, may not
exceed 63
+ characters (as specified by RFC-822), and is terminated by a
colon
+ (`:'). Certain components (as identified by their keywords)
must
+ follow rigidly defined formats in their text portions.
+
+ The text for most formatted components (e.g., "Date:"
and
+ "Message-Id:") is produced automatically. The only ones
entered by
+ the user are address fields such as "To:", "cc:", etc.
Internet
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -125-
MH-MAIL(5)
+
+
+ addresses are assigned mailbox names and host computer
specifica-
+ tions. The rough format is "address@hidden", such as
"address@hidden", or
+ "address@hidden". Multiple addresses are separated by
commas. A
+ missing host/domain is assumed to be the local host/domain.
+
+ As mentioned above, a blank line (or a line of dashes)
signals that
+ all following text up to the end of the file is the body.
No for-
+ matting is expected or enforced within the body.
+
+ Following is a list of header components that are considered
mean-
+ ingful to various MH programs.
+ Date:
+ Added by _p_o_s_t (8), contains date and time of
the message's
+ entry into the transport system.
+
+ From:
+ Added by _p_o_s_t (8), contains the address of
the author or
+ authors (may be more than one if a "Sender:"
field is
+ present). Replies are typically directed to addresses
in the
+ "Reply-To:" or "From:" field (the former has
precedence if
+ present).
+
+ Sender:
+ Added by _p_o_s_t (8) in the event that the message
already has a
+ "From:" line. This line contains the address of the
actual
+ sender. Replies are never sent to addresses in the
"Sender:"
+ field.
+
+ To:
+ Contains addresses of primary recipients.
+
+ cc:
+ Contains addresses of secondary recipients.
+
+ Bcc:
+ Still more recipients. However, the "Bcc:" line is not
copied
+ onto the message as delivered, so these recipients
are not
+ listed. _M_H uses an encapsulation method for blind
copies, see
+ _s_e_n_d (1).
+
+ Fcc:
+ Causes _p_o_s_t (8) to copy the message into the
specified folder
+ for the sender, if the message was successfully given
to the
+ transport system.
+
+ Message-ID:
+ A unique message identifier added by _p_o_s_t (8) if
the `-msgid'
+ flag is set.
+
+ Subject:
+ Sender's commentary. It is displayed by _s_c_a_n
(1).
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -126-
MH-MAIL(5)
+
+
+ In-Reply-To:
+ A commentary line added by _r_e_p_l (1) when
replying to a mes-
+ sage.
+
+ Resent-Date:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-From:
+ Added when redistributing a message by _p_o_s_t (8).
+
+ Resent-To:
+ New recipients for a message resent by _d_i_s_t (1).
+
+ Resent-cc:
+ Still more recipients. See "cc:" and "Resent-To:".
+
+ Resent-Bcc:
+ Even more recipients. See "Bcc:" and "Resent-To:".
+
+ Resent-Fcc:
+ Copy resent message into a folder. See "Fcc:"
and
+ "Resent-To:".
+
+ Resent-Message-Id:
+ A unique identifier glued on by _p_o_s_t (8) if the
`-msgid' flag
+ is set. See "Message-Id:" and "Resent-To:".
+
+ Resent:
+ Annotation for _d_i_s_t (1) under the `-annotate'
option.
+
+ Forwarded:
+ Annotation for _f_o_r_w (1) under the `-annotate'
option.
+
+ Replied:
+ Annotation for _r_e_p_l (1) under the `-annotate'
option.
+
+
+ _F_i_l_e_s
+ /usr/spool/mail/$USER Location of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-MAIL(5) -127-
MH-MAIL(5)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -128-
MH-PROFILE(5)
+
+
+ _N_A_M_E
+ mh-profile - user profile customization for MH message handler
+
+ _S_Y_N_O_P_S_I_S
+ ._m_h__p_r_o_f_i_l_e
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Each user of _M_H is expected to have a file named
._m_h__p_r_o_f_i_l_e in his
+ or her home directory. This file contains a set of user
parameters
+ used by some or all of the _M_H family of programs. Each
line of the
+ file is of the format
+
+ _p_r_o_f_i_l_e-_c_o_m_p_o_n_e_n_t:
_v_a_l_u_e
+
+ The possible profile components are exemplified below.
Only
+ `Path:' is mandatory. The others are optional; some have
default
+ values if they are not present. In the notation used below,
(pro-
+ file, default) indicates whether the information is kept
in the
+ user's _M_H profile or _M_H context, and indicates what
the default
+ value is.
+
+ Path: Mail
+ Locates _M_H transactions in directory "Mail".
(profile,
+ no default)
+
+ context: context
+ Declares the location of the _M_H context file,
see the
+ HISTORY section below. (profile,
default:
+ <mh-dir>/context)
+
+ Current-Folder: inbox
+ Keeps track of the current open folder.
(context,
+ default: folder specified by "Inbox")
+
+ Inbox: inbox
+ Defines the name of your inbox. (profile,
default:
+ inbox)
+
+ Previous-Sequence: pseq
+ Names the sequences which should be defined as the
`msgs'
+ or `msg' argument given to the program. If not
present,
+ or empty, no sequences are defined. Otherwise, for
each
+ name given, the sequence is first zero'd and
then each
+ message is added to the sequence. (profile, no
default)
+
+ Sequence-Negation: not
+ Defines the string which, when prefixed to a
sequence
+ name, negates that sequence. Hence, "notseen"
means all
+ those messages that are not a member of the
sequence
+ "seen". (profile, no default)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -129-
MH-PROFILE(5)
+
+
+ Unseen-Sequence: unseen
+ Names the sequences which should be defined as
those mes-
+ sages recently incorporated by _i_n_c.
_S_h_o_w knows to remove
+ messages from this sequence once it thinks they
have been
+ seen. If not present, or empty, no
sequences are
+ defined. Otherwise, each message is added to
each
+ sequence name given. (profile, no default)
+
+ mh-sequences: .mh_sequences
+ The name of the file in each folder which defines
public
+ sequences. To disable the use of public sequences,
leave
+ the value portion of this entry blank.
(profile,
+ default: .mh_sequences)
+
+ atr-_s_e_q-_f_o_l_d_e_r: 172 178-181 212
+ Keeps track of the private sequence called
_s_e_q in the
+ specified folder. (context, no default)
+
+ Editor: /usr/ucb/ex
+ Defines editor to be used by _c_o_m_p
(1), _d_i_s_t (1),
+ _f_o_r_w (1), and _r_e_p_l (1). (profile,
default: prompter)
+
+ Msg-Protect: 644
+ Defines octal protection bits for message files.
See
+ _c_h_m_o_d (1) for an explanation of the
octal number. (pro-
+ file, default: 0644)
+
+ Folder-Protect: 711
+ Defines protection bits for folder directories.
(pro-
+ file, default: 0711)
+
+ _p_r_o_g_r_a_m: default switches
+ Sets default switches to be used whenever the mh
program
+ _p_r_o_g_r_a_m is invoked. For example,
one could override the
+ _E_d_i_t_o_r: profile component when replying
to messages by
+ adding a component such as:
+ repl: -editor /bin/ed
+ (profile, no defaults)
+
+ _l_a_s_t_e_d_i_t_o_r-next: nexteditor
+ Names "nexteditor" to be the default editor after
using
+ "lasteditor". This takes effect at "What now?"
level in
+ _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l. After editing the draft with
+ "lasteditor", the default editor is set to be
"nextedi-
+ tor". If the user types "edit" without any
arguments to
+ "What now?", then "nexteditor" is used.
(profile, no
+ default)
+
+ bboards: system
+ Tells _b_b_c which BBoards you are interested
in. (profile,
+ default: system)
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -130-
MH-PROFILE(5)
+
+
+ Folder-Stack: _f_o_l_d_e_r_s
+ The contents of the folder-stack for the
_f_o_l_d_e_r command.
+ (context, no default)
+
+ mhe:
+ If present, tells _i_n_c to compose an
_M_H_E auditfile in
+ addition to its other tasks. _M_H_E is Brian
Reid's _E_m_a_c_s
+ front-end for _M_H. An early version is supplied
with the
+ _m_h._6 distribution. (profile, no default)
+
+ Alternate-Mailboxes: address@hidden, bug-mh*
+ Tells _r_e_p_l and _s_c_a_n which addresses
are really yours. In
+ this way, _r_e_p_l knows which addresses
should be included
+ in the reply, and _s_c_a_n knows if the message
really ori-
+ ginated from you. Addresses must be
separated by a
+ comma, and the hostnames listed should be the
"official"
+ hostnames for the mailboxes you indicate, as local
nick-
+ names for hosts are not replaced with their
official site
+ names. For each address, if a host is not
given, then
+ that address on any host is considered to be
you. In
+ addition, an asterisk (`*') may appear at either
or both
+ ends of the mailbox and host to indicate wild-card
match-
+ ing. (profile, default: your user-id)
+
+ Aliasfile: aliases other-alias
+ Indicates aliases files for _a_l_i,
_w_h_o_m, and _s_e_n_d. This
+ may be used instead of the `-alias file' switch.
(pro-
+ file, no default)
+
+ Draft-Folder: drafts
+ Indicates a default draft folder for _c_o_m_p,
_d_i_s_t, _f_o_r_w,
+ and _r_e_p_l. (profile, no default)
+
+ digest-issue-_l_i_s_t: 1
+ Tells _f_o_r_w the last issue of the last
volume sent for the
+ digest _l_i_s_t. (context, no default)
+
+ digest-volume-_l_i_s_t: 1
+ Tells _f_o_r_w the last volume sent for the
digest _l_i_s_t.
+ (context, no default)
+
+ MailDrop: .mail
+ Tells _i_n_c your maildrop, if different from
the default.
+ This is superceded by the MAILDROP envariable.
(profile,
+ default: /usr/spool/mail/$USER)
+
+ Signature: RAND MH System (agent: Marshall Rose)
+ Tells _s_e_n_d your mail signature. This is
superceded by
+ the SIGNATURE envariable. If SIGNATURE is not
set and
+ this profile entry is not present, the "gcos"
field of
+ the /_e_t_c/_p_a_s_s_w_d file will be
used; otherwise, on hosts
+ where _M_H was configured with the UCI option,
the file
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -131-
MH-PROFILE(5)
+
+
+ $HOME/.signature is consulted. Your signature
will be
+ added to the address _s_e_n_d puts in the
"From:" header; do
+ not include an address in the signature text.
(profile,
+ no default)
+
+ The following profile elements are used whenever an
_M_H program
+ invokes some other program such as _m_o_r_e (1). The
._m_h__p_r_o_f_i_l_e can
+ be used to select alternate programs if the user wishes.
The
+ default values are given in the examples.
+
+ fileproc: /usr/local/refile
+ incproc: /usr/local/inc
+ installproc: /usr/local/lib/mh/install-mh
+ lproc: /usr/ucb/more
+ mailproc: /usr/local/mhmail
+ mhlproc: /usr/local/lib/mh/mhl
+ moreproc: /usr/ucb/more
+ mshproc: /usr/local/msh
+ packproc: /usr/local/packf
+ postproc: /usr/local/lib/mh/post
+ rmmproc: none
+ rmfproc: /usr/local/rmf
+ sendproc: /usr/local/send
+ showproc: /usr/ucb/more
+ whatnowproc: /usr/local/whatnow
+ whomproc: /usr/local/whom
+
+ If you define the envariable MH, you can specify a profile
other
+ than ._m_h__p_r_o_f_i_l_e to be read by the _M_H
programs that you invoke. If
+ the value of MH is not absolute, (i.e., does not begin with a
/ ),
+ it will be presumed to start from the current working
directory.
+ This is one of the very few exceptions in _M_H where
non-absolute
+ pathnames are not considered relative to the user's _M_H
directory.
+
+ Similarly, if you define the envariable MHCONTEXT, you can
specify
+ a context other than the normal context file (as specified
in the
+ _M_H profile). As always, unless the value of MHCONTEXT is
absolute,
+ it will be presumed to start from your _M_H directory.
+
+ _M_H programs also support other envariables:
+
+ MAILDROP : tells _i_n_c the default maildrop
+ This supercedes the "MailDrop:" profile entry.
+
+ SIGNATURE : tells _s_e_n_d and _p_o_s_t your mail
signature
+ This supercedes the "Signature:" profile entry.
+
+ HOME : tells all _M_H programs your home directory
+
+ SHELL : tells _b_b_l the default shell to run
+
+ TERM : tells _M_H your terminal type
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -132-
MH-PROFILE(5)
+
+
+ The TERMCAP envariable is also consulted. In
particular,
+ these tell _s_c_a_n and _m_h_l how to clear
your terminal, and how
+ many columns wide your terminal is. They also tell
_m_h_l how
+ many lines long your terminal screen is.
+
+ editalt : the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit
sessions so you can
+ peruse the message being distributed or replied to.
The mes-
+ sage is also available through a link called "@"
in the
+ current directory if your current working directory
and the
+ folder the message lives in are on the same UNIX
filesystem.
+
+ mhdraft : the path to the working draft
+ This is set by _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l to tell the _w_h_a_t_-
+ _n_o_w_p_r_o_c which file to ask "What now?"
questions about. In
+ addition, _d_i_s_t, _f_o_r_w, and _r_e_p_l
set mhfolder if appropriate.
+ Further, _d_i_s_t and _r_e_p_l set mhaltmsg
to tell the _w_h_a_t_n_o_w_p_r_o_c
+ about an alternate message associated with the draft
(the mes-
+ sage being distributed or replied to), and _d_i_s_t
sets mhdist to
+ tell the _w_h_a_t_n_o_w_p_r_o_c that message
re-distribution is occur-
+ ring. Also, mheditor is set to tell the
_w_h_a_t_n_o_w_p_r_o_c the
+ user's choice of editor (unless overridden by
`-noedit').
+ Similarly, mhuse may be set by _c_o_m_p. Finally,
mhmessages is
+ set by _d_i_s_t, _f_o_r_w, and _r_e_p_l if
annotations are to occur (along
+ with mhannotate, and mhinplace). It's amazing all the
infor-
+ mation that has to get passed via envariables to
make the
+ "What now?" interface look squeaky clean to the _M_H
user, isn't
+ it? The reason for all this is that the _M_H user
can select
+ _a_n_y program as the
_w_h_a_t_n_o_w_p_r_o_c, including one of the standard
+ shells. As a result, it's not possible to pass
information
+ via an argument list.
+ If the WHATNOW option was set during _M_H
configuration (type
+ `-help' to an _M_H command to find out), and if this
envariable
+ is set, if the commands _r_e_f_i_l_e,
_s_e_n_d, _s_h_o_w, or _w_h_o_m are not
+ given any `msgs' arguments, then they will default to
using
+ the file indicated by mhdraft. This is useful for
getting the
+ default behavior supplied by the default
_w_h_a_t_n_o_w_p_r_o_c.
+
+ mhfolder : the folder containing the alternate message
+ This is set by _d_i_s_t and _r_e_p_l during edit
sessions so you can
+ peruse other messages in the current folder besides
the one
+ being distributed or replied to. The mhfolder
envariable is
+ also set by _s_h_o_w, _p_r_e_v, and _n_e_x_t
for use by _m_h_l.
+
+ MHBBRC :
+ If you define the envariable MHBBRC, you can specify a
BBoards
+ information file other than ._b_b_r_c to be read
by _b_b_c. If the
+ value of MHBBRC is not absolute, (i.e., does not begin
with a
+ / ), it will be presumed to start from the current
working
+ directory.
+
+ MHFD :
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -133-
MH-PROFILE(5)
+
+
+ If the OVERHEAD option was set during _M_H
configuration (type
+ `-help' to an _M_H command to find out), then if this
envariable
+ is set, _M_H considers it to be the number of a file
descriptor
+ which is opened, read-only to the _M_H profile.
Similarly, if
+ the envariable MHCONTEXTFD is set, this is the number
of a
+ file descriptor which is opened read-only to the
_M_H context.
+ This feature of _M_H is experimental, and is used
to examine
+ possible speed improvements for _M_H startup. Note
that these
+ envariables must be set and non-empty to enable this
feature.
+ However, if OVERHEAD is enabled during _M_H
configuration, then
+ when _M_H programs call other _M_H programs, this
scheme is used.
+ These file descriptors are not closed throughout the
execution
+ of the _M_H program, so children may take advantage
of this.
+ This approach is thought to be completely safe and does
result
+ in some performance enhancements.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ or $MH Rather than the standard
profile
+ <mh-dir>/context The user context
+ or $CONTEXT Rather than the standard
context
+ <folder>/.mh_sequences Public sequences for
<folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ All
+
+
+ _S_e_e _A_l_s_o
+ mh(1), environ(5), mh-sequence(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -134-
MH-PROFILE(5)
+
+
+ _H_i_s_t_o_r_y
+ In previous versions of _M_H, the current-message value of
a writable
+ folder was kept in a file called "cur" in the folder
itself. In
+ _m_h._3, the ._m_h__p_r_o_f_i_l_e contained the
current-message values for all
+ folders, regardless of their writability.
+
+ In all versions of _M_H since _m_h._4, the
._m_h__p_r_o_f_i_l_e contains only
+ static information, which _M_H programs will NOT update.
Changes in
+ context are made to the _c_o_n_t_e_x_t file kept in
the users MH _d_i_r_e_c_t_o-
+ _r_y. This includes, but is not limited to: the
"Current-Folder" en-
+ try and all private sequence information. Public sequence
informa-
+ tion is kept in a file called
._m_h__s_e_q_u_e_n_c_e_s in each folder.
+
+ To convert from the format used in releases of _M_H prior
to the for-
+ mat used in the _m_h._4 release,
_i_n_s_t_a_l_l-_m_h should be invoked with the
+ `-compat' switch. This generally happens automatically on
_M_H sys-
+ tems generated with the "COMPAT" option during _M_H
configuration.
+
+ The ._m_h__p_r_o_f_i_l_e may override the path of
the _c_o_n_t_e_x_t file, by
+ specifying a "context" entry (this must be in lower-case).
If the
+ entry is not absolute (does not start with a / ), then it is
inter-
+ preted relative to the user's _M_H directory. As a
result, you can
+ actually have more than one set of private sequences by using
dif-
+ ferent context files.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-PROFILE(5) -135-
MH-PROFILE(5)
+
+
+ _B_u_g_s
+ The shell quoting conventions are not available in the
.mh_profile.
+ Each token is separated by whitespace.
+
+ There is some question as to what kind of arguments
should be
+ placed in the profile as options. In order to provide a
clear
+ answer, recall command line semantics of all _M_H programs:
conflict-
+ ing switches (e.g., `-header and `-noheader') may occur
more than
+ one time on the command line, with the last switch taking
effect.
+ Other arguments, such as message sequences, filenames and
folders,
+ are always remembered on the invocation line and are not
superseded
+ by following arguments of the same type. Hence, it is
safe to
+ place only switches (and their arguments) in the profile.
+
+ If one finds that an _M_H program is being invoked again
and again
+ with the same arguments, and those arguments aren't
switches, then
+ there are a few possible solutions to this problem. The
first is
+ to create a (soft) link in your $_H_O_M_E/_b_i_n
directory to the _M_H pro-
+ gram of your choice. By giving this link a different name,
you can
+ create a new entry in your profile and use an alternate set
of de-
+ faults for the _M_H command. Similarly, you could create
a small
+ shell script which called the _M_H program of your choice
with an al-
+ ternate set of invocation line switches (using links and an
alter-
+ nate profile entry is preferable to this solution).
+
+ Finally, the _c_s_h user could create an alias for the
command of the
+ form:
+
+ alias cmd 'cmd arg1 arg2 ...'
+
+ In this way, the user can avoid lengthy type-in to the
shell, and
+ still give _M_H commands safely. (Recall that some
_M_H commands in-
+ voke others, and that in all cases, the profile is read,
meaning
+ that aliases are disregarded beyond an initial command
invocation)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -136-
MH-SEQUENCE(5)
+
+
+ _N_A_M_E
+ mh-sequence - sequence specification for MH message system
+
+ _S_Y_N_O_P_S_I_S
+ most _M_H commands
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ Most _M_H commands accept a `msg' or `msgs'
specification, where
+ `msg' indicates one message and `msgs' indicates one or
more mes-
+ sages. To designate a message, you may use either its
number
+ (e.g., 1, 10, 234) or one of these "reserved" message names:
+
+ _N_a_m_e _D_e_s_c_r_i_p_t_i_o_n
+ first the first message in the folder
+ last the last message in the folder
+ cur the most recently accessed message
+ prev the message numerically preceding "cur"
+ next the message numerically following "cur"
+
+ In commands that take a `msg' argument, the default is "cur".
As a
+ shorthand, "." is equivalent to "cur".
+
+ For example: In a folder containing five messages numbered
5, 10,
+ 94, 177 and 325, "first" is 5 and "last" is 325. If "cur"
is 94,
+ then "prev" is 10 and "next" is 177.
+
+ The word `msgs' indicates that one or more messages may be
speci-
+ fied. Such a specification consists of one message
designation or
+ of several message designations separated by spaces. A
message
+ designation consists either of a message name as defined
above, or
+ a message range.
+
+ A message range is specified as "name1-name2" or "name:n",
where
+ `name', `name1' and `name2' are message names, and `n'
is an
+ integer.
+
+ The specification "name1-name2" designates all
currently-existing
+ messages from `name1' to `name2' inclusive. The message name
"all"
+ is a shorthand for the message range "first-last".
+
+ The specification "name:n" designates up to `n' messages.
These
+ messages start with `name' if `name' is a message number or
one of
+ the reserved names "first" "cur", or "next", The messages end
with
+ `name' if `name' is "prev" or "last". The interpretation
of `n'
+ may be overridden by preceding `n' with a plus or minus sign;
`+n'
+ always means up to `n' messages starting with `name',
and `-n'
+ always means up to `n' messages ending with `name'.
+
+ In commands which accept a `msgs' argument, the default is
either
+ "cur" or "all", depending on which makes more sense for
each com-
+ mand (see the individual man pages for details).
Repeated
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -137-
MH-SEQUENCE(5)
+
+
+ specifications of the same message have the same effect as a
single
+ specification of the message.
+
+
+ _U_s_e_r-_D_e_f_i_n_e_d _M_e_s_s_a_g_e
_S_e_q_u_e_n_c_e_s
+
+ In addition to the "reserved" (pre-defined) message names
given
+ above, _M_H supports user-defined sequence names.
User-defined
+ sequences allow the _M_H user a tremendous amount of power
in dealing
+ with groups of messages in the same folder by allowing the
user to
+ bind a group of messages to a meaningful symbolic name.
+
+ The name used to denote a message sequence must consist
of an
+ alphabetic character followed by zero or more alphanumeric
charac-
+ ters, and can not be one of the "reserved" message names
above.
+ After defining a sequence, it can be used wherever an
_M_H command
+ expects a `msg' or `msgs' argument.
+
+ Some forms of message ranges are allowed with
user-defined
+ sequences. The specification "name:n" may be used, and it
desig-
+ nates up to the first `n' messages (or last `n' messages for
`-n')
+ which are elements of the user-defined sequence `name'.
+
+ The specifications "name:next" and "name:prev" may also be
used,
+ and they designate the next or previous message (relative
to the
+ current message) which is an element of the user-defined
sequence
+ `name'. The specificaitions "name:first" and
"name:last" are
+ equivalent to "name:1" and "name:-1", respectively. The
specifica-
+ tion "name:cur" is not allowed (use just "cur" instead).
The syn-
+ tax of these message range specifcations is subject to
change in
+ the future.
+
+ User-defined sequence names are specific to each folder.
They are
+ defined using the _p_i_c_k and _m_a_r_k commands.
+
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two varieties of sequences: _p_u_b_l_i_c
sequences and _p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are
accessible to any _M_H
+ user that can read that folder and are kept in the
.mh_sequences
+ file in the folder. _P_r_i_v_a_t_e sequences are
accessible only to the
+ _M_H user that defined those sequences and are kept in the
user's _M_H
+ context file. By default, _p_i_c_k and _m_a_r_k
create _p_u_b_l_i_c sequences if
+ the folder for which the sequences are being defined is
writable by
+ the _M_H user. Otherwise, _p_r_i_v_a_t_e
sequences are created. This can
+ be overridden with the `-public' and `-private' switches to
_m_a_r_k.
+
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ _M_H provides the ability to select all messages not
elements of a
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -138-
MH-SEQUENCE(5)
+
+
+ user-defined sequence. To do this, the user should
define the
+ entry "Sequence-Negation" in the _M_H profile file; its
value may be
+ any string. This string is then used to preface an existing
user-
+ defined sequence name. This specification then refers to
those
+ messages not elements of the specified sequence name. For
example,
+ if the profile entry is:
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command is given "notfoo" as a `msg'
or `msgs'
+ argument, it would substitute all messages that are not
elements of
+ the sequence "foo".
+
+ Obviously, the user should beware of defining sequences with
names
+ that begin with the value of the "Sequence-Negation" profile
entry.
+
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ _M_H provides the ability to remember the `msgs' or `msg'
argument
+ last given to an _M_H command. The entry
"Previous-Sequence" should
+ be defined in the _M_H profile; its value should be a
sequence name
+ or multiple sequence names separated by spaces. If this
entry is
+ defined, when when an _M_H command finishes, it will
define the
+ sequence(s) named in the value of this entry to be those
messages
+ that were specified to the command. Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs'
argument to
+ define the sequence "pseq" as those messages when it finishes.
+
+ Note: there can be a performance penalty in using
the
+ "Previous-Sequence" facility. If it is used, all _M_H
programs have
+ to write the sequence information to the .mh_sequences file
for the
+ folder each time they run. If the "Previous-Sequence"
profile
+ entry is not included, only _p_i_c_k and _m_a_r_k
will write to the
+ .mh_sequences file.
+
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to indicate messages which have not
been
+ previously seen by them. Both _i_n_c and _s_h_o_w
honor the profile entry
+ "Unseen-Sequence" to support this activity. This entry
in the
+ .mh_profile should be defined as one or more sequence
names
+ separated by spaces. If there is a value for
"Unseen-Sequence" in
+ the profile, then whenever _i_n_c places new messages in a
folder, the
+ new messages will also be added to the sequence(s) named
in the
+ value of this entry. Hence, a profile entry of
+
+ Unseen-Sequence: unseen
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ MH-SEQUENCE(5) -139-
MH-SEQUENCE(5)
+
+
+ directs _i_n_c to add new messages to the sequence
"unseen". Unlike
+ the behavior of the "Previous-Sequence" entry in the
profile, how-
+ ever, the sequence(s) will not be zeroed by _i_n_c.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or
_p_r_e_v) displays a message, that
+ message will be removed from any sequences named
by the
+ "Unseen-Sequence" entry in the profile.
+
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ <mh-dir>/context The user context
+ <folder>/.mh_sequences Public sequences for
<folder>
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Sequence-Negation: To designate messages not in a sequence
+ Previous-Sequence: The last message specification given
+ Unseen-Sequence: Those messages not yet seen by the user
+
+
+ _S_e_e _A_l_s_o
+ mh(1), mark(1), pick(1), mh-profile(5)
+
+
+ _D_e_f_a_u_l_t_s
+ None
+
+
+ _C_o_n_t_e_x_t
+ All
+
+
+ _B_u_g_s
+ User-defined sequences are stored in the .mh_sequences file
as a
+ series of message specifications separated by spaces. If a
user-
+ defined sequence contains too many individual message
specifica-
+ tions, that line in the file may become too long for _M_H
to handle.
+ This will generate the error message ".mh_sequences is poorly
for-
+ matted". You'll have to edit the file by hand to remove
the of-
+ fending line.
+
+ This can happen to users who define the "Previous-Sequence"
entry
+ in the _M_H profile and have a folder containing many
messages with
+ gaps in the numbering. A workaround for large folders is to
minim-
+ ize numbering gaps by using "folder -pack" often.
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ AP(8) -140-
AP(8)
+
+
+ _N_A_M_E
+ ap - parse addresses 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _A_p is a program that parses addresses according to the
ARPA Inter-
+ net standard. It also understands many non-standard
formats. It
+ is useful for seeing how _M_H will interpret an address.
+
+ The _a_p program treats each argument as one or more
addresses, and
+ prints those addresses out in the official 822-format.
Hence, it
+ is usually best to enclose each argument in double-quotes
for the
+ shell.
+
+ To override the output format used by _a_p, the `-format
string' or
+ `-format file' switches are used. This permits individual
fields
+ of the address to be extracted with ease. The string is
simply a
+ format stringand thefile is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ In addition to the standard escapes, _a_p also recognizes
the follow-
+ ing additional escape:
+
+ _E_s_c_a_p_e _R_e_t_u_r_n_s
_D_e_s_c_r_i_p_t_i_o_n
+ error string A diagnostic if the parse failed
+
+ If the `-normalize' switch is given, _a_p will try to track
down the
+ official hostname of the address.
+
+ Here is the default format string used by _a_p:
+
+ %<{error}%{error}: %{text}%|%(putstr(proper{text}))%>
+
+ which says that if an error was detected, print the error, a
`:',
+ and the address in error. Otherwise, output the 822-proper
format
+ of the address.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/mtstailor tailor file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ AP(8) -141-
AP(8)
+
+
+ _S_e_e _A_l_s_o
+ dp(8),
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' defaults as described above
+ `-normalize'
+ `-width' defaults to the width of the terminal
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _a_p. Therefore, one
must usual-
+ ly place the argument to this switch inside double-quotes.
+
+ On hosts where _M_H was configured with the BERK
option, address
+ parsing is not enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -142-
CONFLICT(8)
+
+
+ _N_A_M_E
+ conflict - search for alias/password conflicts
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/conflict [-mail name] [-search directory]
+ [aliasfiles...] [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _C_o_n_f_l_i_c_t is a program that checks to see if
the interface between
+ _M_H and transport system is in good shape
+
+ _C_o_n_f_l_i_c_t also checks for maildrops in
/usr/spool/mail which do not
+ belong to a valid user. It assumes that no user name will
start
+ with `.', and thus ignores files in /usr/spool/mail which
begin
+ with `.'. It also checks for entries in the
_g_r_o_u_p (5) file which
+ do not belong to a valid user, and for users who do not
have a
+ valid group number. In addition duplicate users and
groups are
+ noted.
+
+ If the `-mail name' switch is used, then the results will be
sent
+ to the specified _n_a_m_e. Otherwise, the results
are sent to the
+ standard output.
+
+ The `-search directory' switch can be used to search
directories
+ other than /usr/spool/mail and to report anomalies in those
direc-
+ tories. The `-search directory' switch can appear more
than one
+ time in an invocation to _c_o_n_f_l_i_c_t.
+
+ _C_o_n_f_l_i_c_t should be run under _c_r_o_n
(8), or whenever system account-
+ ing takes place.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /etc/passwd List of users
+ /etc/group List of groups
+ /usr/local/mhmail Program to send mail
+ /usr/spool/mail/ Directory of mail drop
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `aliasfiles' defaults to /usr/local/lib/mh/MailAliases
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ CONFLICT(8) -143-
CONFLICT(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DP(8) -144-
DP(8)
+
+
+ _N_A_M_E
+ dp - parse dates 822-style
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _D_p is a program that parses dates according to the ARPA
Internet
+ standard. It also understands many non-standard formats,
such as
+ those produced by TOPS-20 sites and some UNIX sites
using
+ _c_t_i_m_e (3). It is useful for seeing how _M_H will
interpret a date.
+
+ The _d_p program treats each argument as a single date,
and prints
+ the date out in the official 822-format. Hence, it is
usually best
+ to enclose each argument in double-quotes for the shell.
+
+ To override the output format used by _d_p, the `-format
string' or
+ `-format file' switches are used. This permits individual
fields
+ of the address to be extracted with ease. The string is
simply a
+ format stringand thefile is simply a format file.
See
+ _m_h-_f_o_r_m_a_t (5) for the details.
+
+ Here is the default format string used by _d_p:
+
+ %<(nodate{text})error: %{text}%|%(putstr(pretty{text}))%>
+
+ which says that if an error was detected, print the error, a
`:',
+ and the date in error. Otherwise, output the 822-proper
format of
+ the date.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ None
+
+
+ _S_e_e _A_l_s_o
+ ap(8)
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822)
+
+
+ _D_e_f_a_u_l_t_s
+ `-format' default as described above
+ `-width' default to the width of the terminal
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ DP(8) -145-
DP(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The argument to the `-format' switch must be interpreted as a
sin-
+ gle token by the shell that invokes _d_p. Therefore, one
must usual-
+ ly place the argument to this switch inside double-quotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ FMTDUMP(8) -146-
FMTDUMP(8)
+
+
+ _N_A_M_E
+ fmtdump - decode MH format files
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/fmtdump [-form formatfile] [-format string]
+ [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _F_m_t_d_u_m_p is a program that parses an _M_H
format file and produces a
+ pseudo-language listing of the how _M_H interprets the file.
+
+ The `-format string' and `-form formatfile' switches may be
used to
+ specify a format string or format file to read. The string
is sim-
+ ply a format string and the file is simply a format file.
See _m_h-
+ _f_o_r_m_a_t(5) for the details.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+ /usr/local/lib/mh/scan.default The default format file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To determine the user's MH directory
+
+
+ _S_e_e _A_l_s_o
+ mh-format(5), mh-sequences(8)
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ The output may not be useful unless you are familiar
with the
+ internals of the mh-format subroutines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ INSTALL-MH(8) -147-
INSTALL-MH(8)
+
+
+ _N_A_M_E
+ install-mh - initialize the MH environment
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ When a user runs any _M_H program for the first time,
the program
+ will invoke _i_n_s_t_a_l_l-_m_h (with the `-auto'
switch) to query the user
+ for the initial _M_H environment. The user does NOT invoke
this pro-
+ gram directly. The user is asked for the name of the
directory
+ that will be designated as the user's _M_H directory. If
this direc-
+ tory does not exist, the user is asked if it should be
created.
+ Normally, this directory should be under the user's home
directory,
+ and has the default name of Mail/. After
_i_n_s_t_a_l_l-_m_h has written
+ the initial .mh_profile for the user, control returns to the
origi-
+ nal _M_H program.
+
+ As with all _M_H commands, _i_n_s_t_a_l_l-_m_h
first consults the $HOME
+ envariable to determine the user's home directory. If $HOME
is not
+ set, then the /_e_t_c/_p_a_s_s_w_d file is consulted.
+
+ When converting from _m_h._3 to _m_h._4,
_i_n_s_t_a_l_l-_m_h is automatically
+ invoked with the `-compat' switch.
+
+ _F_i_l_e_s
+ $HOME/.mh_profile The user profile
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ Path: To set the user's MH directory
+
+
+ _C_o_n_t_e_x_t
+ With `-auto', the current folder is changed to "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POST(8) -148-
POST(8)
+
+
+ _N_A_M_E
+ post - deliver a message
+
+ _S_Y_N_O_P_S_I_S
+ /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+ [-verbose] [-noverbose] [-watch] [-nowatch] [-width
columns]
+ file [-help]
+
+ _D_E_S_C_R_I_P_T_I_O_N
+
+ _P_o_s_t is the program called by _s_e_n_d (1) to
deliver the message in
+ _f_i_l_e to local and remote users. In fact, all of
the functions
+ attributed to _s_e_n_d on its manual page are performed
by _p_o_s_t, with
+ _s_e_n_d acting as a relatively simple preprocessor.
Thus, it is _p_o_s_t
+ which parses the various header fields, appends From: and
Date:
+ lines, and interacts with the _S_e_n_d_M_a_i_l
transport system. _P_o_s_t will
+ not normally be called directly by the user.
+
+ _P_o_s_t searches the "To:", "cc:", "Bcc:", "Fcc:", and
"Resent-xxx:"
+ header lines of the specified message for destination
addresses,
+ checks these addresses for validity, and formats them so as
to con-
+ form to ARPAnet Internet Message Format protocol,
unless the
+ `-noformat' flag is set. This will normally cause
"@_l_o_c_a_l-_s_i_t_e" to
+ be appended to each local destination address, as well as any
local
+ return addresses. The `-width columns' switch can be used to
indi-
+ cate the preferred length of the header components that
contain
+ addresses.
+
+ If a "Bcc:" field is encountered, its addresses will be
used for
+ delivery, and the "Bcc:" field will be removed from the
message
+ sent to sighted recipients. The blind recipients will
receive an
+ entirely new message with a minimal set of headers.
Included in
+ the body of the message will be a copy of the message sent
to the
+ sighted recipients. If `-filter filterfile' is
specified, then
+ this copy is filtered (re-formatted) prior to being sent
to the
+ blind recipients.
+
+ The `-alias aliasfile' switch can be used to specify a file
that
+ post should take aliases from. More than one file can be
speci-
+ fied, each being preceded with `-alias'. In any event, the
primary
+ alias file is read first.
+
+ The `-msgid' switch indicates that a
"Message-ID:" or
+ "Resent-Message-ID:" field should be added to the header.
+
+ The `-verbose' switch indicates that the user should be
informed of
+ each step of the posting/filing process.
+
+ The `-watch' switch indicates that the user would like to
watch the
+ transport system's handling of the message (e.g., local and
"fast"
+ delivery).
+
+ [mh.6] MH.6.8 UCI
version
+
+
+
+
+
+
+
+
+
+ POST(8) -149-
POST(8)
+
+
+ _P_o_s_t consults the envariable $SIGNATURE to determine
the sender's
+ personal name in constructing the "From:" line of the message.
+
+ _F_i_l_e_s
+ /usr/local/lib/mh/mtstailor tailor file
+ /usr/local/refile Program to process Fcc:s
+ /usr/local/lib/mh/mhl Program to process Bcc:s
+ /usr/local/lib/mh/MailAliases Primary alias file
+
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+ _p_o_s_t does NOT consult the user's .mh_profile
+
+
+ _S_e_e _A_l_s_o
+ _S_t_a_n_d_a_r_d _f_o_r _t_h_e
_F_o_r_m_a_t _o_f _A_R_P_A _I_n_t_e_r_n_e_t
_T_e_x_t _M_e_s_s_a_g_e_s (aka
+ RFC-822),
+ mhmail(1), send(1), mh-mail(5), mh-alias(5)
+
+
+ _D_e_f_a_u_l_t_s
+ `-alias /usr/local/lib/mh/MailAliases'
+ `-format'
+ `-nomsgid'
+ `-noverbose'
+ `-nowatch'
+ `-width 72'
+ `-nofilter'
+
+
+ _C_o_n_t_e_x_t
+ None
+
+
+ _B_u_g_s
+ "Reply-To:" fields are allowed to have groups in them
according to
+ the 822 specification, but _p_o_s_t won't let you use
them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [mh.6] MH.6.8
UCI version
+
+
+
+
+
+
+
+
+
+
+
+
+ _5. _R_E_P_O_R_T_I_N_G
_P_R_O_B_L_E_M_S
+
+
+
+
+
+ If problems are encountered with an _M_H program, the
problems should
+ be reported to the local maintainers of _M_H. When doing
this, the name
+ of the program should be reported, along with the version
information
+ for the program. To find out what version of an _M_H
program is being
+ run, invoke the program with the `-help' switch. In addition
to listing
+ the syntax of the command, the program will list information
pertaining
+ to its version. This information includes the version of
_M_H, the host
+ it was generated on, and the date the program was loaded. A
second line
+ of information, found on versions of _M_H after #5.380
include _M_H confi-
+ guration options. For example,
+
+ version: MH 6.1 #1[UCI] (nrtc-gremlin) of Wed Nov 6
01:13:53 PST
+ 1985
+ options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII]
[SMTP] [POP]
+
+ The `6.1 #1[UCI]' indicates that the program is from the UCI
_m_h._6 ver-
+ sion of _M_H. The program was generated on the host
`nrtc-gremlin' on
+ `Wed Nov 6 01:13:53 PST 1985'. It's usually a good idea to
send the
+ output of the `-help' switch along with your report.
+
+ If there is no local _M_H maintainer, try the address
Bug-MH. If that
+ fails, use the Internet mailbox address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -150-
+
+
+
+
+
+
+
+
+
+
+
+
+ _6. _A_D_V_A_N_C_E_D
_F_E_A_T_U_R_E_S
+
+
+
+
+
+ This section describes some features of _M_H that
were included
+ strictly for advanced _M_H users. These capabilities
permit _M_H to exhibit
+ more powerful behavior for the seasoned _M_H users.
+
+
+ _U_S_E_R-_D_E_F_I_N_E_D _S_E_Q_U_E_N_C_E_S
+
+ User-defined sequences allow the _M_H user a
tremendous amount of
+ power in dealing with groups of messages in the same folder
by allowing
+ the user to bind a group of messages to a meaningful symbolic
name. The
+ user may choose any name for a message sequence, as long as
it consists
+ of alphanumeric characters and does not conflict with the
standard _M_H
+ reserved message names (e.g., "first", etc). After defining
a sequence,
+ it can be used wherever an _M_H command expects a `msg' or
`msgs' argu-
+ ment.
+
+ A restricted form of message ranges are allowed with
user-defined
+ sequences. The form "name:n", specifies up to the first
`n' messages
+ which are part of the user-defined sequence `name'. A
leading plus sign
+ is allowed on `n', but is ignored. The interpretation of n
is overrid-
+ den if n is preceded by a minus sign; `-n' always means up to
the last
+ `n' messages which are part of the sequence `name'.
+
+ Although all _M_H commands expand user-defined
sequences as appropri-
+ ate, there are two commands that allow the user to define and
manipulate
+ them: _p_i_c_k and _m_a_r_k.
+
+ _P_i_c_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ Most users of _M_H will use user-defined sequences
only with the _p_i_c_k
+ command. By giving the `-sequence name' switch to
_p_i_c_k (which can occur
+ more than once on the command line), each sequence named is
defined as
+ those messages which _p_i_c_k matched according the the
selection criteria
+ it was given. Hence,
+
+ pick -from frated -seq fred
+
+ finds all those messages in the current folder which were
from "frated",
+ creates a sequence called "fred", and then adds them to
the sequence.
+ The user could then invoke
+
+ scan fred
+
+ to get a _s_c_a_n listing of those messages. Note that
by default, _p_i_c_k
+ creates the named sequences before it adds the selected
messages to the
+ sequence. Hence, if the named sequence already existed, the
sequence is
+
+ -151-
+
+
+
+
+
+
+
+
+
+ -152-
+
+
+ destroyed prior to being re-defined (nothing happens to
the messages
+ that were a part of this sequence, they simply cease to be
members of
+ that sequence). By using the `-nozero' switch, this
behavior can be
+ inhibited, as in
+
+ pick -from frated -seq sgroup
+ pick -from fear -seq sgroup -nozero
+ pick -from freida -seq sgroup -nozero
+
+ finds all those messages in the current folder which were
from "frated",
+ "fear", or "freida", and defines the sequence called "sgroup"
as exactly
+ those messages. These operations amounted to an
"inclusive-or" of three
+ selection criteria, using _p_i_c_k, one can also
generate the "and" of some
+ selection criteria as well:
+
+ pick -from frated -seq fred
+ pick -before friday -seq fred fred
+
+ This example defines the sequence called "fred" as exactly
those mes-
+ sages from "frated" that were dated prior to "friday".[1]
+
+ _P_i_c_k is normally used as a back-quoted command,
for example,
+
+ scan `pick -from postmaster`
+
+ Now suppose that the user decides that another command should
be issued,
+ using exactly those messages. Since, _p_i_c_k
wasn't given a
+ `-sequence name' argument in this example, the user would
end-up typing
+ the entire back-quoted command again. A simpler way is to
add a default
+ sequence name to the .mh_profile. For example,
+
+ pick: -seq select -list
+
+ will tell _p_i_c_k to always define the sequence "select"
whenever it's run.
+ The `-list' is necessary since the `-sequence name' switch
sets `-nol-
+ ist' whenever the former is encountered. Hence, this
profile entry
+ makes _p_i_c_k define the "select" sequence and
otherwise behave exactly as
+
+
+ [1] Of course, it is much easier to simply use the
built-in boolean
+ operation of _p_i_c_k to get the desired results:
+
+ pick -from frated -or -from fear -or -from freida -seq
sgroup
+
+ and
+
+ pick -from frated -and -before friday -seq fred
+
+ do exactly the same thing as the five commands listed above.
Hence, the
+ `-nozero' option to _p_i_c_k is only useful to
manipulate existing se-
+ quences.
+
+
+
+
+
+
+
+
+
+
+
+
+ -153-
+
+
+ if there was no profile entry at all.
+
+ _M_a_r_k _a_n_d _U_s_e_r-_D_e_f_i_n_e_d
_S_e_q_u_e_n_c_e_s
+
+ The _m_a_r_k command lets the user perform
low-level manipulation of
+ sequences, and also provides a well-needed debug
facility to the
+ implementors/developers/maintainers of _M_H (the
_M_H-hacks). In the
+ future, a user-friendly "front-end" for _m_a_r_k will
probably be developed
+ to give the _M_H user a way to take better advantage of
the underlying
+ facilities.
+
+ _P_u_b_l_i_c _a_n_d _P_r_i_v_a_t_e
_U_s_e_r-_D_e_f_i_n_e_d _S_e_q_u_e_n_c_e_s
+
+ There are two kinds of sequences: _p_u_b_l_i_c
sequences, and _p_r_i_v_a_t_e
+ sequences. _P_u_b_l_i_c sequences of a folder are
accessible to any _M_H user
+ that can read that folder and are kept in the .mh_sequences
file in the
+ folder. _P_r_i_v_a_t_e sequences are accessible
only to the _M_H user that
+ defined those sequences and are kept in the user's _M_H
context file. By
+ default, _p_i_c_k (and _m_a_r_k ) create
_p_u_b_l_i_c sequences if the folder for
+ which the sequences are being defined is writable by the
_M_H user. Oth-
+ erwise, _p_r_i_v_a_t_e sequences are created. This
can be overridden with the
+ `-public' and `-nopublic' switches.
+
+ _S_e_q_u_e_n_c_e _N_e_g_a_t_i_o_n
+
+ In addition to telling an _M_H command to use the
messages in the
+ sequence "seen", as in
+
+ refile seen +old
+
+ it would be useful to be easily able to tell an _M_H
command to use all
+ messages _e_x_c_e_p_t those in the sequence. One way
of doing this would be
+ to use _m_a_r_k and define the sequence explicitly, as in
+
+ mark -delete -zero seen -seq notseen
+
+ which, owing to _m_a_r_k 's cryptic interpretation of
`-delete' and `-zero',
+ defines the sequence "notseen" to be all messages not in
the sequence
+ "seen". Naturally, anytime the sequence "seen" is changed,
"notseen"
+ will have to be updated. Another way to achieve this is to
define the
+ entry "Sequence-Negation:" in the .mh_profile. If the entry
was
+
+ Sequence-Negation: not
+
+ then anytime an _M_H command was given "notseen" as a
`msg' or `msgs'
+ argument, it would substitute all messages that are not a
member of the
+ sequence "seen". That is,
+
+ refile notseen +new
+
+ does just that. The value of the "Sequence-Negation:" entry
in the pro-
+ file can be any string. Hence, experienced users of
_M_H do not use a
+
+
+
+
+
+
+
+
+
+
+
+ -154-
+
+
+ word, but rather a special character which their shell does
not inter-
+ pret (users of the _C_S_h_e_l_l use a single caret
or circumflex (usually
+ shift-6), while users of the Bourne shell use an
exclamation-mark).
+ This is because there is nothing to prevent a user of _M_H
from defining a
+ sequence with this string as its prefix, if the string is
nothing by
+ letters and digits. Obviously, this could lead to confusing
behavior if
+ the "Sequence-Negation:" entry leads _M_H to believe that
two sequences
+ are opposites by virtue of their names differing by the
prefix string.
+
+ _T_h_e _P_r_e_v_i_o_u_s _S_e_q_u_e_n_c_e
+
+ Many times users find themselves issuing a series of
commands on
+ the same sequences of messages. If the user first defined
these mes-
+ sages as a sequence, then considerable typing may be saved.
If the user
+ doesn't have this foresight, _M_H provides a handy
way of having _M_H
+ remember the `msgs' or `msg' argument last given to an _M_H
command. If
+ the entry "Previous-Sequence:" is defined in the
.mh_profile, then when
+ the command finishes, it will define the sequence(s) named in
the value
+ of this entry as being exactly those messages that were
specified.
+ Hence, a profile entry of
+
+ Previous-Sequence: pseq
+
+ directs any _M_H command that accepts a `msg' or `msgs'
argument to define
+ the sequence "pseq" as those messages when it finishes.
More than one
+ sequence name may be placed in this entry, separated with
spaces. The
+ one disadvantage of this approach is that the _M_H progams
have to update
+ the sequence information for the folder each time they run
(although
+ most programs read this information, usually only
_p_i_c_k and _m_a_r_k have to
+ write this information out).
+
+ _T_h_e _U_n_s_e_e_n _S_e_q_u_e_n_c_e
+
+ Finally, some users like to distinguish between messages
which have
+ been previously seen by them. Both _i_n_c and
_s_h_o_w honorthe profile entry
+ "Unseen-Sequence" to support this activity. Whenever
_i_n_c places new
+ messages in a folder, if the entry "Unseen-Sequence" is
defined in the
+ .mh_profile, then when the command finishes, _i_n_c will
add the new mes-
+ sages to the sequence(s) named in the value of this
entry. Hence, a
+ profile entry of
+
+ Unseen-Sequence: unseen
+
+ directs _i_n_c to add new messages to the sequence
"unseen". Unlike the
+ behavior of the "Previous-Sequence" entry in the profile
however, the
+ sequence(s) will not be zero'd.
+
+ Similarly, whenever _s_h_o_w (or _n_e_x_t or
_p_r_e_v ) displays a message,
+ they remove those messages from any sequences
named by the
+ "Unseen-Sequence" entry in the profile.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -155-
+
+
+ _C_O_M_P_O_S_I_T_I_O_N _O_F _M_A_I_L
+
+ There are a number of interesting advanced facilities
for the com-
+ position of outgoing mail.
+
+
+ _T_h_e _D_r_a_f_t _F_o_l_d_e_r
+
+ The _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands have two switches,
+ `-draftfolder +folder' and `-draftmessage msg'.
If
+ `-draftfolder +folder' is used, these commands are directed
to construct
+ a draft message in the indicated folder. (The
"Draft-Folder:" profile
+ entry may be used to declare a default draft folder for use
with _c_o_m_p,
+ _d_i_s_t, _f_o_r_w, and _r_e_p_l) If
`-draftmessage msg' is not used, it defaults to
+ `new' (unless the user invokes _c_o_m_p with `-use',
in which case the
+ default is `cur'). Hence, the user may have several
message composi-
+ tions in progress simultaneously. Now, all of the _M_H
tools are avail-
+ able on each of the user's message drafts (e.g.,
_s_h_o_w, _s_c_a_n, _p_i_c_k, and
+ so on). If the folder does not exist, the user is asked if
it should be
+ created (just like with _r_e_f_i_l_e ). Also, the last
draft message the user
+ was composing is known as `cur' in the draft folder.
+
+ Furthermore, the _s_e_n_d command has these switches
as well. Hence,
+ from the shell, the user can send off whatever drafts
desired using the
+ standard _M_H `msgs' convention with `-draftmessage msgs'.
If no `msgs'
+ are given, it defaults to `cur'.
+
+ In addition, all five programs have a
`-nodraftfolder' switch,
+ which undoes the last occurrence of `-draftfolder folder'
(useful if the
+ latter occurs in the user's _M_H profile).
+
+ If the user does not give the `-draftfolder +folder'
switch, then
+ all these commands act ``normally''. Note that the
`-draft' switch to
+ _s_e_n_d and _s_h_o_w still refers to the file called
`draft' in the user's _M_H
+ directory. In the interests of economy of expression, when
using _c_o_m_p
+ or _s_e_n_d, the user needn't prefix the draft `msg' or
`msgs' with `-draft-
+ message'. Both of these commands accept a `file' or
`files' argument,
+ and they will, if given `-draftfolder +folder' treat these
arguments as
+ `msg' or `msgs'.[2] Hence,
+
+ send -draftf +drafts first
+
+ is the same as
+
+ send -draftf +drafts -draftm first
+
+
+
+
+ [2] This may appear to be inconsistent, at first, but it
saves a lot
+ of typing.
+
+
+
+
+
+
+
+
+
+
+
+
+ -156-
+
+
+ To make all this a bit more clear, here are some
examples. Let's
+ assume that the following entries are in the _M_H profile:
+
+ Draft-Folder: +drafts
+ sendf: -draftfolder +drafts
+
+ Furthermore, let's assume that the program _s_e_n_d_f is
a (symbolic) link in
+ the user's $HOME/bin/ directory to _s_e_n_d. Then, any
of the commands
+
+ comp
+ dist
+ forw
+ repl
+
+ constructs the message draft in the `draft' folder using the
`new' mes-
+ sage number. Furthermore, they each define `cur' in this
folder to be
+ that message draft. If the user were to use the _q_u_i_t
option at `What
+ now?' level, then later on, if no other draft composition
was done, the
+ draft could be sent with simply
+
+ sendf
+
+ Or, if more editing was required, the draft could be edited
with
+
+ comp -use
+
+ Instead, if other drafts had been composed in the meantime,
so that this
+ message draft was no longer known as `cur' in the `draft'
folder, then
+ the user could _s_c_a_n the folder to see which message
draft in the folder
+ should be used for editing or sending. Clever users could
even employ a
+ back-quoted _p_i_c_k to do the work:
+
+ comp -use `pick +drafts -to bug-mh`
+
+ or
+
+ sendf `pick +drafts -to bug-mh`
+
+ Note that in the _c_o_m_p example, the output from
_p_i_c_k must resolve to a
+ single message draft (it makes no sense to talk about
composing two or
+ more drafts with one invocation of _c_o_m_p ). In
contrast, in the _s_e_n_d
+ example, as many message drafts as desired can appear,
since _s_e_n_d
+ doesn't mind sending more than one draft at a time.
+
+ Note that the argument `-draftfolder +folder' is not
included in
+ the profile entry for _s_e_n_d, since when
_c_o_m_p, et. al., invoke _s_e_n_d
+ directly, they supply _s_e_n_d with the UNIX pathname of
the message draft,
+ and not a `draftmessage msg' argument. As far as
_s_e_n_d is concerned, a
+ _d_r_a_f_t _f_o_l_d_e_r is not being used.
+
+ It is important to realize that _M_H treats the draft
folder like a
+ standard _M_H folder in nearly all respects. There are
two exceptions:
+
+
+
+
+
+
+
+
+
+
+
+ -157-
+
+
+ first_____, under no circumstancs will the `-draftfolder
folder' switch cause
+ the named folder to become the current folder.[3]
Second______, although con-
+ ceptually _s_e_n_d deletes the `msgs' named in the draft
folder, it does not
+ call `delete-prog' to perform the deletion.
+
+
+ _W_h_a_t _H_a_p_p_e_n_s _i_f _t_h_e
_D_r_a_f_t _E_x_i_s_t_s
+
+ When the _c_o_m_p, _d_i_s_t, _f_o_r_w, and
_r_e_p_l commands are invoked and the
+ draft you indicated already exists, these programs will
prompt the user
+ for a reponse directing the program's action. The prompt is
+
+ Draft ``/usr/src/uci/mh/mhbox/draft'' exists (xx bytes).
+ Disposition?
+
+ The appropriate responses and their meanings are:
replace_______: deletes the
+ draft and starts afresh; list____: lists the draft;
refile______: files the draft
+ into a folder and starts afresh; and, quit____: leaves
the draft intact and
+ exits. In addition, if you specified `-draftfolder folder'
to the com-
+ mand, then one other response will be accepted: new___:
finds a new draft,
+ just as if `-draftmessage new' had been given. Finally,
the _c_o_m_p com-
+ mand will accept one more response: use___: re-uses the
draft, just as if
+ `-use' had been given.
+
+
+ _T_h_e _P_u_s_h _O_p_t_i_o_n _a_t _W_h_a_t
_n_o_w? _L_e_v_e_l
+
+ The _p_u_s_h option to the "What now?" query in the
_c_o_m_p, _d_i_s_t, _f_o_r_w,
+ and _r_e_p_l commands, directs the command to
_s_e_n_d the draft in a special
+ detached fashion, with all normal output discarded. If
_p_u_s_h is used and
+ the draft can not be sent, then _M_H will send the user a
message, indi-
+ cating the name of the draft file, and an explanation of the
failure.
+
+ The user can also invoke _s_e_n_d from the shell
with the `-push'
+ switch, which makes _s_e_n_d act like it had been
_p_u_s_h 'd by one of the com-
+ position commands.
+
+ By using _p_u_s_h, the user can free the shell to
do other things,
+ because it appears to the shell that the _M_H command has
finished. As a
+ result the shell will immediately prompt for another
command, despite
+ the fact that the command is really still running. Note
that if the
+ user indicates that annotations are to be performed (with
`-annotate' to
+
+
+ [3] Obviously, if the folder appeared in the context of
a standard
+ `+folder' argument to an _M_H program, as in
+
+ scan +drafts
+
+ it might become the current folder, depending on the context
changes of
+ the _M_H program in question.
+
+
+
+
+
+
+
+
+
+
+
+
+ -158-
+
+
+ _d_i_s_t, _f_o_r_w, or _r_e_p_l), the annotations
will be performed after the mes-
+ sage has been successfully sent. This action will appear to
occur asyn-
+ chronously. Obviously, if one of the messages that is to be
annotated
+ is removed before the draft has been successfully sent,
then when _M_H
+ tries to make the annotations, it won't be able to do so.
In previous
+ versions of _M_H, this resulted in an error message
mysteriously appearing
+ on the user's terminal. In _m_h._5 and later versions,
in this special
+ circumstance, no error will be generated.
+
+ If send is _p_u_s_h 'd, then the `-forward' switch
is examined if a
+ failure notice is generated. If given, then the draft is
forwarded with
+ the failure notice sent to the user. This allows rapid
_b_u_r_s_t 'ing of
+ the failure notice to retrieve the unsent draft.
+
+
+ _O_p_t_i_o_n_s _a_t _W_h_a_t _n_o_w?
_L_e_v_e_l
+
+ By default, the message composition programs call a
program called
+ _w_h_a_t_n_o_w before the initial draft composition.
The _M_H user can specify
+ any program for this. Following is some information about
the default
+ "What now?" level. More detailed information can be found
in the _w_h_a_t_-
+ _n_o_w (1) manual entry.
+
+ When using the _c_o_m_p, _d_i_s_t, _f_o_r_w,
and _r_e_p_l commands at "What now?"
+ level, the _e_d_i_t, _l_i_s_t,
_h_e_a_d_e_r_s, _r_e_f_i_l_e, and (for the _d_i_s_t and
_r_e_p_l com-
+ mands) the _d_i_s_p_l_a_y options will pass on any
additional arguments given
+ them to whatever program they invoke.
+
+ In _m_h._1 (the original RAND _M_H ) and _m_h._2
(the first UCI version of
+ _M_H ), _M_H used a complicated heuristic to determine
if the draft should
+ be deleted or preserved after an unsuccessful edit. In
_m_h._3, _M_H was
+ changed to preserve the draft always, since _c_o_m_p, et.
al., could usually
+ look at a draft, apply another set of heuristics, and decide
if it was
+ important or not. With the notion of a _d_r_a_f_t
_f_o_l_d_e_r, in which one by
+ default gets a `new' message draft, the edit
deletion/preservation algo-
+ rithm was re-implemented, to keep the draft folder from
being cluttered
+ with aborted edits.
+
+ Also, note that by default, if the draft cannot be
successfully
+ sent, these commands return to "What now?" level. But,
when _p_u_s_h is
+ used, this does not happen (obviously). Hence, if these
commands were
+ expected to annotate any messages, this will have to be
done by hand,
+ later on, with the _a_n_n_o command.
+
+ Finally, if the `-delete' switch is not given to the
_q_u_i_t option,
+ then these commands will inform the user of the name of the
unsent draft
+ file.
+
+
+ _D_i_g_e_s_t_s
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -159-
+
+
+ The _f_o_r_w command has the beginnings of a
digestifying facility,
+ with the `-digest list', `-issue number', and `-volume
number' switches.
+
+ If _f_o_r_w is given "list" to the `-digest' switch as
the name of the dis-
+ cussion group, and the `-issue number' switch is not
given, then _f_o_r_w
+ looks for an entry in the user's _M_H context called
"_d_i_g_e_s_t-issue-list"
+ and increments its value to use as the issue number.
Similarly, if the
+ `-volume number' switch is not given, then
_f_o_r_w looks for
+ "_d_i_g_e_s_t-volume-list" (but does not increment
its value) to use as the
+ volume number.
+
+ Having calculated the name of the digest and the volume
and issue
+ numbers, _f_o_r_w will now process the components file
using the same format
+ string mechanism used by _r_e_p_l. The current
`%'-escapes are:
+
+ _e_s_c_a_p_e _t_y_p_e
_s_u_b_s_t_i_t_u_t_i_o_n
+ digest string digest name
+ msg integer issue number
+ cur integer volume number
+
+ In addition, to capture the current date, any of the escapes
valid for
+ _d_p (8) are also valid for _f_o_r_w.
+
+ The default components file used by _f_o_r_w when in
digest mode is:
+
+ From: %{digest}-Request
+ To: %{digest} Distribution: dist-%{digest};
+ Subject: %{digest} Digest V%(cur) #%(msg)
+ Reply-To: %{digest}
+ --------
+ %{digest} Digest %(weekday{date}), %2(mday{date})
%(month{date}) 19%02(year{date})
+ Volume %(cur) : Issue %(msg)
+
+ Today's Topics:
+
+ Hence, when the `-digest' switch is present, the first step
taken by
+ _f_o_r_w is to expand the format strings in the
component file. The next
+ step is to compose the draft using the standard digest
encapsulation
+ algorithm (even putting an "End of list Digest" trailer in
the draft).
+ Once the draft is composed by _f_o_r_w, _f_o_r_w
writes out the volume and issue
+ profile entries for the digest, and then invokes the editor.
+
+ Naturally, when composing the draft, _f_o_r_w
will honor the
+ `-filter filterfile' switch, which is given to _m_h_l to
filter each mes-
+ sage being forwarded prior to encapsulation in the draft. A
good filter
+ file to use, which is called _m_h_l._d_i_g_e_s_t, is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -160-
+
+
+ width=80,overflowoffset=10
+ leftadjust,compress,compwidth=9
+
Date:formatfield="%<(nodate{text})%{text}%|%(tws{text})%>"
+ From:
+ Subject:
+ :
+ body:nocomponent,overflowoffset=0,noleftadjust,nocompress
+
+
+
+ _F_O_L_D_E_R _H_A_N_D_L_I_N_G
+
+ There are two interesting facilities for
manipulating folders:
+ relative folder addressing, which allows a user to shorten
the typing of
+ long folder names; and the folder-stack, which permits a user
to keep a
+ stack of current folders.
+
+
+ _R_e_l_a_t_i_v_e _F_o_l_d_e_r
_A_d_d_r_e_s_s_i_n_g
+
+ By default, when `+folder' is given, and the folder
name is not
+ absolute (does not start with /, ./, or ../), then the UNIX
pathname of
+ the folder is interpreted relative to the user's _M_H
directory. Although
+ this mechanism works fine for top-level folders and
their immediate
+ sub-folders, once the depth of the sub-folder tree grows,
it becomes
+ rather unwieldly:
+
+ scan +mh/mh.4/draft/flames
+
+ is a lot of typing. _M_H can't do anything if the
current folder was
+ "+inbox", but if the current folder was, say,
"+mh/mh.4/draft", _M_H has a
+ short-hand notation to reference a sub-folder of the
current folder.
+ Using the address@hidden' notation, the _M_H user can
direct any _M_H program
+ which expects a `+folder' argument to look for the folder
relative to
+ the current folder instead of the user's _M_H directory.
Hence, if the
+ current folder _w_a_s "+mh/mh.4/draft", then
+
+ scan @flames
+
+ would do the trick handily. In addition, if the current
folder _w_a_s
+ "+mh/mh.4/draft",
+
+ scan @../pick
+
+ would scan the folder "+mh/mh.4/pick", since, in the UNIX
fashion, it
+ references the folder "pick" which is a sub-folder of the
folder that is
+ the parent of the current folder. Since most advanced _M_H
users seem to
+ exhibit a large degree of locality in referencing folders
when they pro-
+ cess mail, this convention should receive a wide range of
uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -161-
+
+
+ _T_h_e _F_o_l_d_e_r-_S_t_a_c_k
+
+ The _f_o_l_d_e_r-_s_t_a_c_k mechanism in
_M_H gives the _M_H user a facility simi-
+ lar to the _C_S_h_e_l_l 's directory-stack. Simply put,
+
+ folder -push +foo
+
+ makes "foo" the current folder, saving the folder that was
previously
+ the current folder on the _f_o_l_d_e_r-_s_t_a_c_k.
As expected,
+
+ folder -pop
+
+ takes the top of the _f_o_l_d_e_r-_s_t_a_c_k and
makes it the current folder. Each
+ of these switches lists the
_f_o_l_d_e_r-_s_t_a_c_k when they execute. It is sim-
+ ple to write a _p_u_s_h_f command as a shell script.
It's one line:
+
+ exec folder -push $@
+
+ Probably a better way is to link _f_o_l_d_e_r to the
$HOME/bin/ directory
+ under the name of _p_u_s_h_f and then add the entry
+
+ pushf: -push
+
+ to the .mh_profile.
+
+ The manual page for _f_o_l_d_e_r discusses the
analogy between the _C_S_h_e_l_l
+ directory stack commands and the switches in
_f_o_l_d_e_r which manipulate the
+ _f_o_l_d_e_r-_s_t_a_c_k. The _f_o_l_d_e_r
command uses the context entry `Folder-Stack:'
+ to keep track of the folders in the user's stack of folders.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix A
+ _C_O_M_M_A_N_D
_S_U_M_M_A_R_Y
+
+
+
+
+ ali [-alias aliasfile] [-list] [-nolist] [-normalize]
+ [-nonormalize] [-user] [-nouser] aliases ... [-help]
+
+ anno [+folder] [msgs] [-component field] [-inplace]
[-noinplace]
+ [-date] [-nodate] [-text body] [-help]
+
+ bbc [bboards ...] [-topics] [-check] [-read] [-quiet]
[-verbose]
+ [-archive] [-noarchive] [-protocol] [-noprotocol]
+ [-mshproc program] [switches for _m_s_h_p_r_o_c]
[-rcfile rcfile]
+ [-norcfile] [-file BBoardsfile] [-user BBoardsuser]
[-help]
+
+ burst [+folder] [msgs] [-inplace] [-noinplace] [-quiet]
[-noquiet]
+ [-verbose] [-noverbose] [-help]
+
+ comp [+folder] [msg] [-draftfolder +folder] [-draftmessage
msg]
+ [-nodraftfolder] [-editor editor] [-noedit] [-file file]
+ [-form formfile] [-use] [-nouse] [-whatnowproc program]
+ [-nowhatnowproc] [-help]
+
+ dist [+folder] [msg] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-form formfile] [-inplace]
+ [-noinplace] [-whatnowproc program] [-nowhatnowproc]
[-help]
+
+ /usr/local/lib/mh/fmtdump [-form formatfile] [-format string]
+ [-help]
+
+ folder [+folder] [msg] [-all] [-fast] [-nofast] [-header]
+ [-noheader] [-pack] [-nopack] [-recurse] [-norecurse]
[-total]
+ [-nototal] [-print] [-noprint] [-list] [-nolist] [-push]
+ [-pop] [-help]
+
+ folders
+
+ forw [+folder] [msgs] [-annotate] [-noannotate]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-filter filterfile]
+ [-form formfile] [-format] [-noformat] [-inplace]
[-noinplace]
+ [-whatnowproc program] [-nowhatnowproc] [-help]
+
+ forw [+folder] [msgs] [-digest list] [-issue number]
+ [-volume number] [other switches for _f_o_r_w]
[-help]
+
+
+
+
+
+ -162-
+
+
+
+
+
+
+
+
+
+
+
+
+ inc [+folder] [-audit audit-file] [-noaudit] [-changecur]
+ [-nochangecur] [-file name] [-form formatfile]
+ [-format string] [-silent] [-nosilent] [-truncate]
+ [-notruncate] [-width columns] [-help]
+
+ mark [+folder] [msgs] [-sequence name ...] [-add] [-delete]
[-list]
+ [-public] [-nopublic] [-zero] [-nozero] [-help]
+
+ /usr/local/lib/mh/mhl [-bell] [-nobell] [-clear] [-noclear]
+ [-folder +folder] [-form formfile] [-length lines]
+ [-width columns] [-moreproc program] [-nomoreproc]
[files ...]
+ [-help]
+
+ mhmail [ addrs ... [-body text] [-cc addrs ...] [-from addr]
+ [-subject subject]] [-help]
+
+ mhparam [profile-components] [-components] [-nocomponents]
[-all]
+ [-help]
+
+ mhpath [+folder] [msgs] [-help]
+
+ msgchk [-date] [-nodate] [-notify all/mail/nomail]
+ [-nonotify all/mail/nomail] [users ...] [-help]
+
+ msh [-prompt string] [-scan] [-noscan] [-topcur] [-notopcur]
[file]
+ [-help]
+
+ next [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ packf [+folder] [msgs] [-file name] [-help]
+
+ pick [+folder] [msgs] [-and ...] [-or ...] [-not ...]
+ [-lbrace ... -rbrace] [--component pattern] [-after date]
+ [-before date] [-datefield field] [-sequence name ...]
+ [-public] [-nopublic] [-zero] [-nozero] [-list] [-nolist]
+ [-help]
+
+
+ prev [+folder] [-header] [-noheader] [-showproc program]
+ [-noshowproc] [switches for _s_h_o_w_p_r_o_c]
[-help]
+
+ prompter [-erase chr] [-kill chr] [-prepend] [-noprepend]
[-rapid]
+ [-norapid] [-doteof] [-nodoteof] file [-help]
+
+ /usr/local/lib/mh/rcvstore [+folder] [-create] [-nocreate]
+ [-sequence name ...] [-public] [-nopublic] [-zero]
[-nozero]
+ [-help]
+
+
+
+
+
+ -163-
+
+
+
+
+
+
+
+
+
+
+
+
+ refile [msgs] [-draft] [-link] [-nolink] [-preserve]
[-nopreserve]
+ [-src +folder] [-file file] +folder ... [-help]
+
+ repl [+folder] [msg] [-annotate] [-noannotate] [-cc
all/to/cc/me]
+ [-nocc all/to/cc/me] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-editor editor]
+ [-noedit] [-fcc +folder] [-filter filterfile] [-form
formfile]
+ [-inplace] [-noinplace] [-query] [-noquery]
+ [-whatnowproc program] [-nowhatnowproc] [-width columns]
+ [-help]
+
+ rmf [+folder] [-interactive] [-nointeractive] [-help]
+
+ rmm [+folder] [msgs] [-help]
+
+ scan [+folder] [msgs] [-clear] [-noclear] [-form formatfile]
+ [-format string] [-header] [-noheader] [-width columns]
+ [-reverse] [-noreverse] [-file filename] [-help]
+
+ send [-alias aliasfile] [-draft] [-draftfolder +folder]
+ [-draftmessage msg] [-nodraftfolder] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-forward] [-noforward]
+ [-msgid] [-nomsgid] [-push] [-nopush] [-verbose]
[-noverbose]
+ [-watch] [-nowatch] [-width columns] [file ...] [-help]
+
+ show [+folder] [msgs] [-draft] [-header] [-noheader]
+ [-showproc program] [-noshowproc] [switches for
_s_h_o_w_p_r_o_c]
+ [-help]
+
+ sortm [+folder] [msgs] [-datefield field] [-textfield field]
+ [-notextfield] [-limit days] [-nolimit] [-verbose]
+ [-noverbose] [-help]
+
+ vmh [-prompt string] [-vmhproc program] [-novmhproc]
+ [switches for _v_m_h_p_r_o_c] [-help]
+
+ whatnow [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [-editor editor] [-noedit] [-prompt string] [file]
[-help]
+
+ whom [-alias aliasfile] [-check] [-nocheck] [-draft]
+ [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder]
+ [file] [-help]
+
+ /usr/local/lib/mh/ap [-form formatfile] [-format string]
+ [-normalize] [-nonormalize] [-width columns] addrs ...
+ [-help]
+
+ /usr/local/lib/mh/conflict [-mail name] [-search directory]
+ [aliasfiles ...] [-help]
+
+
+
+
+ -164-
+
+
+
+
+
+
+
+
+
+
+
+
+ /usr/local/lib/mh/dp [-form formatfile] [-format string]
+ [-width columns] dates ... [-help]
+
+ /usr/local/lib/mh/install-mh [-auto] [-compat]
+
+ /usr/local/lib/mh/post [-alias aliasfile] [-filter filterfile]
+ [-nofilter] [-format] [-noformat] [-msgid] [-nomsgid]
+ [-verbose] [-noverbose] [-watch] [-nowatch] [-width
columns]
+ file [-help]
+
+ /usr/local/lib/mh/slocal [address info sender] [-addr address]
+ [-info data] [-sender sender] [-user username] [-mailbox
mbox]
+ [-file file] [-maildelivery deliveryfile] [-verbose]
+ [-noverbose] [-debug] [-help]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -165-
+
+
+
+
+
+
+
+
+
+
+
+
+ Appendix B
+ _M_E_S_S_A_G_E
_N_A_M_E _B_N_F
+
+
+
+
+
+ msgs := msgspec |
+ msgs msgspec
+
+ msgspec := msg |
+ msg-range |
+ msg-sequence |
+ user-defined-sequence
+
+ msg := msg-name |
+ <number>
+
+ msg-name := "first" |
+ "last" |
+ "cur" |
+ "." |
+ "next" |
+ "prev"
+
+ msg-range := msg"-"msg |
+ "all"
+
+ msg-sequence := msg":"signed-number
+
+ signed-number := "+"<number> |
+ "-"<number> |
+ <number>
+
+ user-defined-sequence := <alpha> |
+ <alpha><alphanumeric>*
+
+
+ Where <number> is a decimal number greater than zero.
+
+ Msg-range specifies all of the messages in the given range
and must not
+ be empty.
+
+ Msg-sequence specifies up to <number> of messages, beginning
with "msg"
+ (in the case of first, cur, next, or <number>), or ending
with "msg" (in
+ the case of prev or last). +<number> forces "starting with
msg", and
+ -<number> forces "ending with number". In all cases, "msg"
must exist.
+
+ User-defined sequences are defined and manipulated with the
_p_i_c_k and
+ _m_a_r_k commands.
+
+
+
+ -166-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_F_E_R_E_N_C_E_S
+
+
+
+ 1. Crocker, D. H., J. J. Vittal, K. T. Pogran, and D. A.
Henderson,
+ Jr., "Standard for the Format of ARPA Network Text
Messages,"
+ _R_F_C_7_3_3, November 1977.
+
+ 2. Thompson, K., and D. M. Ritchie, "The UNIX
Time-sharing System,"
+ _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f
_t_h_e _A_C_M, Vol. 17, July 1974, pp. 365-375.
+
+ 3. McCauley, E. J., and P. J. Drongowski, "KSOS-The Design
of a Secure
+ Operating System," _A_F_I_P_S
_C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, National
Computer
+ Conference, Vol. 48, 1979, pp. 345-353.
+
+ 4. Crocker, David H., _F_r_a_m_e_w_o_r_k _a_n_d
_F_u_n_c_t_i_o_n_s _o_f _t_h_e "_M_S" _P_e_r_s_o_n_a_l
_M_e_s_-
+ _s_a_g_e _S_y_s_t_e_m, The RAND Corporation,
R-2134-ARPA, December 1977.
+
+ 5. Thompson, K., and D. M. Ritchie, _U_N_I_X
_P_r_o_g_r_a_m_m_e_r'_s _M_a_n_u_a_l, 6th ed.,
+ Western Electric Company, May 1975 (available only to
UNIX licen-
+ sees).
+
+ 6. Crocker, D. H., "Standard for the Format of ARPA Internet
Text Mes-
+ sages," _R_F_C_8_2_2, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -167-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -i-
+
+
+
+
+
+
+
+
+
+
+
+
+ _R_E_A_D _T_H_I_S
+
+
+
+
+ Although the _M_H system was originally developed by
the RAND Cor-
+ poration, and is now in the public domain, the RAND
Corporation assumes
+ no responsibility for _M_H or this particular version of
_M_H.
+
+ In addition, the Regents of the University of California
issue the
+ following disclaimer in regard to the UCI version of _M_H:
+
+ "Although each program has been tested by its
contributor, no war-
+ ranty, express or implied, is made by the
contributor or the
+ University of California, as to the accuracy and
functioning of the
+ program and related program material, nor shall the fact
of distri-
+ bution constitute any such warranty, and no
responsibility is
+ assumed by the contributor or the University of
California in con-
+ nection herewith."
+
+ This version of _M_H is in the public domain, and as
such, there are
+ no real restrictions on its use. The _M_H source code
and documentation
+ have no licensing restrictions whatsoever. As a courtesy,
the authors
+ ask only that you provide appropriate credit to the RAND
Corporation and
+ the University of California for having developed the
software.
+
+ _M_H is a software package that is supported neither
by the RAND Cor-
+ poration nor the University of California. However, since we
do use the
+ software ourselves and plan to continue using (and
improving) _M_H, bug
+ reports and their associated fixes should be reported back to
us so that
+ we may include them in future releases. The current
computer mailbox
+ for _M_H is address@hidden (in the ARPA
Internet), and
+ ...!ucbvax!ucivax!bug-mh (UUCP). Presently, there are two
Internet dis-
+ cussion groups, address@hidden and address@hidden
+ MH-Workers is for people discussing code changes to _M_H.
MH-Users is for
+ general discussion about how to use _M_H. MH-Users is
bi-directionally
+ gatewayed into USENET as comp.mail.mh.
+
+ _H_O_W _T_O _G_E_T _M_H
+
+ Since you probably already have _M_H, you may not need
to read this
+ unless you suspect you have an old version. There are two
ways to get
+ the latest release:
+
+ 1. If you can FTP to the ARPA Internet, use
anonymous FTP to
+ ics.uci.edu [128.195.1.1] and retrieve the file
pub/mh/mh-6.8.tar.Z.
+ This is a tar image after being run through the
compress program
+ (approximately 1.8MB). There should also be a README
file in that
+ directory which tells what the current release of _M_H is,
and how to get
+ updates.
+
+
+
+ -i-
+
+
+
+
+
+
+
+
+
+ -ii-
+
+
+ This tar file is also available on louie.udel.edu
[128.175.1.3] in
+ portal/mh-6.8.tar.Z. You may also find MH on various
other hosts; to
+ make sure you get the latest version and don't waste your
time re-fixing
+ bugs, it's best to get it from either ics.uci.edu or
louie.udel.edu.
+
+ 2. You can send $75 US to the address below. This
covers the cost
+ of a 6250 BPI 9-track magtape, handling, and shipping.
In addition,
+ you'll get a laser-printed hard-copy of the entire MH
documentation set.
+ Be sure to include your USPS address with your check.
Checks must be
+ drawn on U.S. funds and should be made payable to:
+
+ Regents of the University of California
+
+ The distribution address is:
+
+ Computing Support Group
+ Attn: MH distribution
+ Department of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92717
+
+ 714/856-7554
+
+ If you just want the hard-copies of the documentation,
you still
+ have to pay the $75. The tar image has the documentation
source (the
+ manual is in roff format, but the rest are in TeX format).
Postscript
+ formatted versions of the TeX papers are available, as are
crude tty-
+ conversions of those papers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ _F_O_R_E_W_O_R_D
+
+
+
+
+ This document describes the RAND _M_H Message Handling
System. Its
+ primary purpose is to serve as a user's manual. It has
been heavily
+ based on a previous version of the manual, prepared by
Bruce Borden,
+ Stockton Gaines, and Norman Shapiro.
+
+ _M_H is a particularly novel system, and thus it is
often more prone
+ to change than other pieces of production software. As
such, some
+ specific points in this manual may not be correct in the
future. In all
+ cases, the on-line sections of this manual, available
through the
+ UNIX[1] _m_a_n command, should present the most current
information.
+
+ When reading this document as a user's manual, certain
sections are
+ more interesting than others. The Preface and Summary are
not particu-
+ larly interesting to those interested in learning _M_H.
The Introduction
+ is slightly more interesting, as it touches upon the
organization of the
+ remainder of this document. The most useful sections are the
Overview,
+ Tutorial, and Detailed Description. The Overview should be
read by all
+ _M_H users, regardless of their expertise (beginning,
novice, advanced, or
+ hacker). The Tutorial should be read by all beginning
and novice _M_H
+ users, as it presents a nice description of the _M_H
system. The Detailed
+ Description should be read by the day-to-day user of
_M_H, as it spells
+ out all of the realities of the _M_H system. The Advanced
Features sec-
+ tion discusses some powerful _M_H capabilities for advanced
users. Appen-
+ dix A is particularly useful for novices, as it summarizes
the invoca-
+ tion syntax of all the _M_H commands.
+
+ There are also several other documents which may be
useful to you:
+ _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_u_t_o_r_i_a_l, which is
a tutorial for
+ _M_H; _T_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e
_H_a_n_d_l_i_n_g _S_y_s_t_e_m: _T_h_e _U_C_I
_B_B_o_a_r_d_s _F_a_c_i_l_i_t_y, which
+ describes the BBoards handling under _M_H; _M_H._5:
_H_o_w _t_o _p_r_o_c_e_s_s _2_0_0 _m_e_s_-
+ _s_a_g_e_s _a _d_a_y _a_n_d _s_t_i_l_l
_g_e_t _s_o_m_e _r_e_a_l _w_o_r_k _d_o_n_e, which was
presented at
+ the 1985 Summer Usenix Conference and Exhibition in
Portland, Oregon;
+ _M_H: _A _M_u_l_t_i_f_a_r_i_o_u_s _U_s_e_r
_A_g_e_n_t, which has been accepted for publication
+ by Computer Networks; _M_Z_n_e_t: _M_a_i_l
_S_e_r_v_i_c_e _f_o_r _P_e_r_s_o_n_a_l
_M_i_c_r_o-_C_o_m_p_u_t_e_r
+ _S_y_s_t_e_m_s, which was presented at the First
International Symposium on
+ Computer Message Systems in Nottingham, U.K.; and,
_D_e_s_i_g_n _o_f _t_h_e _T_T_I
+ _P_r_o_t_o_t_y_p_e _T_r_u_s_t_e_d
_M_a_i_l _A_g_e_n_t, which describes a proprietary "trusted"
+ mail system built on _M_H. There are also documents,
mostly specific to
+ U.C. Irvine which you may find interesting: _M_H _f_o_r
_B_e_g_i_n_n_e_r_s, and _M_H _f_o_r
+ _M_M _U_s_e_r_s. All of these documents exist in the
_m_h._6 distribution sent to
+ your site. There's also a document, _C_h_a_n_g_e_s
_t_o _t_h_e _R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m: _M_H._6, which
describes user-visible changes made to _M_H
+ since the last major release.
+
+
+ [1] UNIX is a trademark of AT&T Bell Laboratories.
+
+
+ -iii-
+
+
+
+
+
+
+
+
+
+ -iv-
+
+
+ This manual is very large, as it describes a large,
powerful system
+ in gruesome detail. The important thing to remember is:
+
+
+ _D_O_N'_T
_P_A_N_I_C[_2]
+
+
+ As explained in the tutorial, you really need to know only 5
commands to
+ handle most of your mail.
+
+ Very advanced users may wish to consult _T_h_e
_R_A_N_D _M_H _M_e_s_s_a_g_e _H_a_n_-
+ _d_l_i_n_g _S_y_s_t_e_m:
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, which is also
present in the _m_h._6
+ distribution sent to your site.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [2] Note the large, _f_r_i_e_n_d_l_y letters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
_A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
+
+
+
+
+ The _M_H system described herein is based on the
original RAND _M_H
+ system. It has been extensively developed (perhaps too
much so) by
+ Marshall T. Rose and John L. Romine at the University of
California,
+ Irvine. Einar A. Stefferud, Jerry N. Sweet, and Terry P.
Domae provided
+ numerous suggestions to improve the UCI version of _M_H.
Of course, a
+ large number of people have helped _M_H along. The list
of ``_M_H immor-
+ tals'' is too long to list here. However, Van Jacobson
deserves a spe-
+ cial acknowledgement for his tireless work in improving the
performance
+ of _M_H. Some programs have been speeded-up by a factor of
10 or 20. All
+ of users of _M_H, everywhere, owe a special thanks to
Van. For this
+ release, numerous _M_H-_W_o_r_k_e_r_s sent in fixes
and other changes. A handful
+ of courageous _M_H-_W_o_r_k_e_r_s volunteered to
beta-test these changes; their
+ help is particularly appreciated.
+
+ This manual is based on the original _M_H manual
written at RAND by
+ Bruce Borden, Stockton Gaines, and Norman Shapiro.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -v-
+
+
+
+
+
+
+
+
+
+
+
+
+ _P_R_E_F_A_C_E
+
+
+
+
+ This report describes a system for dealing with messages
transmit-
+ ted on a computer. Such messages might originate with
other users of
+ the same computer or might come from an outside source
through a network
+ to which the user's computer is connected. Such
computer-based message
+ systems are becoming increasingly widely used, both within
and outside
+ the Department of Defense.
+
+ The message handling system _M_H was developed for two
reasons. One
+ was to investigate some research ideas concerning how a
message system
+ might take advantage of the architecture of the UNIX
time-sharing
+ operating system for Digital Equipment Corporation PDP-11
and VAX com-
+ puters, and the special features of UNIX's command-level
interface with
+ the user (the "shell"). The other reason was to provide a
better and
+ more adaptable base than that of conventional designs on
which to build
+ a command and control message system. The effort has
succeeded in both
+ regards, although this report mainly describes the message
system itself
+ and how it fits in with UNIX.
+
+ The present report should be of interest to three
groups of
+ readers. First, it is a complete reference manual for the
users of _M_H.
+ Second, it should be of interest to those who have a general
knowledge
+ of computer-based message systems, both in civilian and
military appli-
+ cations. Finally, it should be of interest to those who
build large
+ subsystems that interface with users, since it
illustrates a new
+ approach to such interfaces.
+
+ The original _M_H system was developed by Bruce
Borden, using an
+ approach suggested by Stockton Gaines and Norman
Shapiro. Valuable
+ assistance was provided by Phyllis Kantar in the later
stages of the
+ system's implementation. Several colleagues contributed
to the ideas
+ included in this system, particularly Robert Anderson and
David Crocker.
+ In addition, valuable experience in message systems, and
a valuable
+ source of ideas, was available to us in the form of a
previous message
+ system for UNIX called MS, designed at RAND by David Crocker.
+
+ This report was originally prepared as part of the
RAND project
+ entitled "Data Automation Research", sponsored by Project AIR
FORCE.
+
+
+
+
+
+
+
+
+
+
+
+ -vi-
+
+
+
+
+
+
+
+
+
+
+
+
+ _S_U_M_M_A_R_Y
+
+
+
+
+ Electronic communication of text messages is becoming
commonplace.
+ Computer-based message systems-software packages that
provide tools for
+ dealing with messages-are used in many contexts. In
particular, message
+ systems are becoming increasingly important in command and
control and
+ intelligence applications.
+
+ This report describes a message handling system called
_M_H. This
+ system provides the user with tools to compose, send,
receive, store,
+ retrieve, forward, and reply to messages. _M_H has been
built on the UNIX
+ time-sharing system, a popular operating system developed
for the DEC
+ PDP-11 and VAX classes of computers.
+
+ A complete description of _M_H is given for users of
the system. For
+ those who do not intend to use the system, this description
gives a gen-
+ eral idea of what a message system is like. The system
involves some
+ new ideas about how large subsystems can be constructed.
+
+ The interesting and unusual features of _M_H include
the following:
+ The user command interface to _M_H is the UNIX "shell"
(the standard UNIX
+ command interpreter). Each separable component of message
handling,
+ such as message composition or message display, is a
separate command.
+ Each program is driven from and updates a private user
environment,
+ which is stored as a file between program invocations.
This private
+ environment also contains information to "custom tailor"
_M_H to the
+ individual's tastes. _M_H stores each message as a
separate file under
+ UNIX, and it utilizes the tree-structured UNIX file system
to organize
+ groups of files within separate directories or "folders".
All of the
+ UNIX facilities for dealing with files and directories, such
as renam-
+ ing, copying, deleting, cataloging, off-line printing, etc.,
are appli-
+ cable to messages and directories of messages (folders).
Thus, impor-
+ tant capabilities needed in a message system are available in
_M_H without
+ the need (often seen in other message systems) for code that
duplicates
+ the facilities of the supporting operating system. It also
allows users
+ familiar with the shell to use _M_H with minimal effort.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -vii-
+
+
+
+
+
+
+
+
+
+
+
+
+ _C_O_N_T_E_N_T_S
+
+
+
+
+ READ THIS
......................................................... i
+
+ FOREWORD
.......................................................... iii
+
+ ACKNOWLEDGMENTS
................................................... v
+
+ PREFACE
........................................................... vi
+
+ SUMMARY
........................................................... vii
+
+ Section
+
+ 1. INTRODUCTION
............................................... 1
+
+ 2. OVERVIEW
................................................... 4
+
+ 3. TUTORIAL
................................................... 7
+
+ 4. DETAILED DESCRIPTION
....................................... 10
+ THE USER PROFILE
............................................. 10
+ MESSAGE NAMING
............................................... 13
+ OTHER MH CONVENTIONS
......................................... 14
+ MH COMMANDS
.................................................. 16
+ ALI
....................................................... 17
+ ANNO
...................................................... 19
+ BBC
....................................................... 21
+ BBOARDS
................................................... 24
+ BURST
..................................................... 26
+ COMP
...................................................... 28
+ DIST
...................................................... 30
+ FOLDER
.................................................... 33
+ FORW
...................................................... 37
+ INC
....................................................... 41
+ MARK
...................................................... 44
+ MHL
....................................................... 46
+ MHMAIL
.................................................... 51
+ MHOOK
..................................................... 53
+ MHPARAM
................................................... 55
+ MHPATH
.................................................... 57
+ MSGCHK
.................................................... 60
+ MSH
....................................................... 61
+ NEXT
...................................................... 65
+ PACKF
..................................................... 66
+ PICK
...................................................... 67
+ PREV
...................................................... 72
+ PROMPTER
.................................................. 73
+ RCVSTORE
.................................................. 76
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ REFILE
.................................................... 78
+ REPL
...................................................... 80
+ RMF
....................................................... 84
+ RMM
....................................................... 86
+ SCAN
...................................................... 88
+ SEND
...................................................... 91
+ SHOW
...................................................... 94
+ SLOCAL
.................................................... 97
+ SORTM
..................................................... 102
+ VMH
....................................................... 104
+ WHATNOW
................................................... 106
+ WHOM
...................................................... 108
+ MORE DETAILS
................................................. 110
+ MH-ALIAS
.................................................. 111
+ MH-FORMAT
................................................. 115
+ MH-MAIL
................................................... 124
+ MH-PROFILE
................................................ 128
+ MH-SEQUENCE
............................................... 136
+ AP
........................................................ 140
+ CONFLICT
.................................................. 142
+ DP
........................................................ 144
+ FMTDUMP
................................................... 146
+ INSTALL-MH
................................................ 147
+ POST
...................................................... 148
+
+ 5. REPORTING PROBLEMS
......................................... 150
+
+ 6. ADVANCED FEATURES
.......................................... 151
+ USER-DEFINED SEQUENCES
....................................... 151
+ Pick and User-Defined Sequences
........................... 151
+ Mark and User-Defined Sequences
........................... 153
+ Public and Private User-Defined Sequences
................. 153
+ Sequence Negation
......................................... 153
+ The Previous Sequence
..................................... 154
+ The Unseen Sequence
....................................... 154
+ COMPOSITION OF MAIL
.......................................... 155
+ The Draft Folder
.......................................... 155
+ What Happens if the Draft Exists
.......................... 157
+ The Push Option at What now? Level
........................ 157
+ Options at What now? Level
................................ 158
+ Digests
................................................... 159
+ FOLDER HANDLING
.............................................. 160
+ Relative Folder Addressing
................................ 160
+ The Folder-Stack
.......................................... 161
+
+ Appendix
+ A. Command Summary
............................................ 162
+ B. Message Name BNF
........................................... 166
+
+ REFERENCES
........................................................ 167
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ THE RAND MH
+
+
+ MESSAGE HANDLING
+
+
+ SYSTEM:
+
+
+ USER'S MANUAL
+
+
+
+
+
+
+ UCI Version
+
+
+
+
+
+ Marshall T. Rose
+
+ John L. Romine
+
+
+
+
+ Based on the original manual by
+
+ Borden, Gaines, and Shapiro
+
+
+
+
+
+
+
+ November 30, 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 6.8.3 #1[UCI]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/historical/README b/docs/historical/README
new file mode 100644
index 0000000..5fdb663
--- /dev/null
+++ b/docs/historical/README
@@ -0,0 +1,108 @@
+The most recent versions of the documents in this directory were
+downloaded from ftp://ftp.vim.org/pub/mail/mh/doc/
+
+These older versions:
+ ADMIN-19910201.txt
+ MH-19910201.txt
+ MH-19921214.pdf
+ MH-19921214.txt
+were downloaded from ftp://munnari.oz.au/pub/mh/doc/
+
+designOfMH.pdf was downloaded from
+http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA257836
+
+The README below is retained in its original form for posterity. All
+of the txt (.doc and .tty) files have been renamed to .txt. All of
+the postscript (.ps) files have been converted to pdf using ps2pdf.
+
+D. Levine 28 Feb 2012
+
+------------------------------------------------------------------------
+------------------------------------------------------------------------
+
+mh/doc/README
+
+These are formatted versions of the major MH documents (written
+using the troff "-ms" and "-me" macro packages). The ".doc" files
+are formatted for 66 lines/page:
+
+ ADMIN.doc - The MH Administrator's Manual - how to configure MH
+ MH.doc - The MH User's Manual
+ changes.doc - Changes from MH 6.6 to MH 6.8
+ mh-gen.doc - The "READ-ME" file - how to generate MH (aka mh-gen(8))
+
+Postscript versions are also available:
+
+ ADMIN.ps - The MH Administrator's Manual - how to configure MH
+ MH.ps - The MH User's Manual
+ changes.ps - Changes from MH 6.6 to MH 6.8
+ mh-gen.ps - The "READ-ME" file - how to generate MH (aka mh-gen(8))
+
+------------------------------------------------------------------------
+
+These are postscript conversions of the MH papers which were written
+using the TeX typesetting language:
+
+ bboards.ps - The UCI BBoards Facility
+ beginners.ps - UCI MH for Beginners
+ mh4mm.ps - MH for MM users
+ mh6.ps - Changes from MH 6.0 to MH 6.5 for 4.3BSD
+ multifarious.ps - MH: A Multifarious User Agen
+ mznet.ps - MZnet - Mail Service for Personal Micro Comp. Sys.
+ realwork.ps - MH.5 - How to process 200 messages...
+ trusted.ps - Design of the TTI Prototype Trusted Mail Agent
+ tutorial.ps - The MH Tutorial
+
+These conversions have been provided because they may be of use to some
+sites who retrieved MH using FTP, and who do not have TeX to typeset
+the papers themselves. Of course, all recipients of an MH distribution
+tape receive a complete set of laser-printed manuals.
+
+These conversions were generated with the "dvips" program. I have
+printed them on an Imagen 5320 w/ Turboscript, and the output is
+identical to the original "dvi" versions of these papers.
+
+As yet, I have had no success downloading the postscript files to a Mac-
+intosh, and printing them on a Laserwriter. If you are able to generate
+copies of these papers which will print (identically to the originals or
+otherwise) on a Laserwriter, please contact "address@hidden".
+
+------------------------------------------------------------------------
+
+These files are tty-readable conversions of the MH papers which were
+written using the TeX typesetting language:
+
+ bboards.tty - The UCI BBoards Facility
+ beginners.tty - UCI MH for Beginners
+ mh4mm.tty - MH for MM users
+ mh6.tty - Changes from MH 6.0 to MH 6.5 for 4.3BSD
+ multifarious.tty - MH: A Multifarious User Agen
+ mznet.tty - MZnet - Mail Service for Personal Micro Comp. Sys.
+ realwork.tty - MH.5 - How to process 200 messages...
+ trusted.tty - Design of the TTI Prototype Trusted Mail Agent
+ tutorial.tty - The MH Tutorial
+
+These conversions have been provided because they may be of use to some
+sites who retrieved MH using FTP, and who do not have TeX or a laser
+printer on which to print the papers. If you have a Postscript
+printer, you may want to retrieve the Postscript conversion of these
+papers, available in a different tar archive.
+
+Of course, all recipients of an MH distribution tape receive a complete
+set of laser-printed manuals, and these conversions are not a
+substitute for properly-formatted copies of the originals.
+
+The conversion was generated by the "dvi2tty" program. As full use of
+TeX's rich typesetting environment was used in writing many of these
+papers, and since the output is intended for a line printer, it is
+necessarily quite primitive.
+
+Font changes and special character representations are lost entirely.
+White-space between words may be deleted or expanded, especially near
+punctuation characters. Blank lines may be added or deleted.
+
+Since typeset lines are typically longer than 80 tty characters, the
+output has been generated for 132-colunm output devices. A typical
+page has about 76 lines. Pages are separated by a formfeed character.
+
+/JLR
diff --git a/docs/historical/bboards.pdf b/docs/historical/bboards.pdf
new file mode 100644
index 0000000..6e7d2cf
Binary files /dev/null and b/docs/historical/bboards.pdf differ
diff --git a/docs/historical/bboards.txt b/docs/historical/bboards.txt
new file mode 100644
index 0000000..ace0d08
--- /dev/null
+++ b/docs/historical/bboards.txt
@@ -0,0 +1,965 @@
+
+
+
+
+ The Rand MH Message Handling System:
+
+
+
+ The UCI BBoards Facility
+
+
+ Marshall T. Rosey
+
+ Wed May 21 21:03:57 PDT 1986
+
+
+
+ Abstract
+
+
+ This document discusses how to process BBoards using the
+
+ Rand MH system. In particular, this guide discusses: check-
+
+ ing the status of a BBoard, viewing new messages,
archive
+
+ handling, composing mail destined for a BBoard, and reply-
+
+ ing to a message posted to a BBoard.
+
+
+ Although this document is based on the standard MH
+
+ user manual[MH], this document is meant to supplement, not
+
+ supersede, that lengthier work.
+
+
+ Comments concerning this documentation should be ad-
+
+ dressed to the Internet mailbox address@hidden
+
+
+
+_____________________________________
+y Computer Mail: address@hidden
+
+
+ The Rand MH Message Handling System:
+
+
+
+ The UCI BBoards Facility
+
+
+
+Acknowledgements
+
+ The MH system described herein is based on the original Rand MH system.
+
+It has been extensively developed (perhaps too much so) by Marshall Rose and
+
+John Romine at the University of California, Irvine. Einar Stefferud, Jerry
Sweet,
+
+and Terry Domae provided numerous suggestions to improve the UCI version of
+
+MH.
+
+
+ In particular, the UCI BBoards facility, which was suggested
by Einar
+
+Stefferud, has been in place at the University of California, Irvine (in one
form or
+
+another) for the last two and one-half years. The UCI BBoards facilities runs
under
+
+both MMDF and SendMail, and, in a more restricted form, under stand-alone MH.
+
+
+
+Disclaimer
+
+ The Regents of the University of California wish to make it known that:
+
+
+
+ "Although each program has been tested by its contributor, no warranty,
express or
+ implied, is made by the contributor or the University of California,
as to the accuracy
+ and functioning of the program and related program material, nor shall
the fact of
+ distribution constitute any such warranty, and no responsibility is
assumed by the
+ contributor or the University of California in connection herewith."
+
+
+
+Scope
+
+ This document explains how to use the UCI BBoards facility
to a user
+
+familiar with MH and the UNIX1 operating system in general. A large degree of
+
+expertise is not assumed. This document does not attempt to introduce MH to
the
+
+novice user (for that task, consult the MH tutorial known as [MH.TUT]).
Additional
+
+information on the programs discussed here (particularly bbc) is to be found in
+
+[MH].
+
+
+
+_____________________________________
+1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ 1
+
2
+
+
+Conventions
+
+ In this document, certain TEX-formatting conventions are adhered to:
+
+
+ 1. The names of UNIX commands, such as comp, are
presented in text
+
+ italics.
+
+
+ 2. Arguments to programs, such as `msgs' , are presented in
typewriter
+
+ style and delimited by single-quotes.
+
+
+ 3. UNIX pathnames and envariables, such as /usr/uci/ and $
SIGNATURE ,
+
+ are presented in slanted roman.
+
+
+ 4. Text presenting an example, such as
+
+
+ comp -editor zz
+
+
+ is presented in typewriter style.
+
+
+
+Introduction
+
+ MH is a very powerful message handling system that runs under the UNIX
+
+operating system. One of the many features which MH offers is an interface to
+
+the UCI BBoards facility. This facility permits the efficient distribution of
interest
+
+group messages on a single host, a group of hosts under a single
administration,
+
+and the ARPA Internet community.
+
+
+ Described simply, a interest group is composed of a number of
subscribers
+
+with a common interest. These subscribers post mail to a single address, known
+
+as a distribution address. From this distribution address, a copy of the
message
+
+is sent to each subscriber. Each group has a moderator, which is the person
that
+
+runs the the group. This moderator can usually be reached at a special
address,
+
+known as a request address. Usually, the responsibilities of the moderator
are quite
+
+simple, since the mail system handles the distribution to subscribers
automatically.
+
+In some cases, the interest group, instead of being distributed
directly to its
+
+subscribers, is put into a digest format by the moderator and then sent to the
+
+subscribers. Although this requires more work on the part of the moderator,
such
+
+groups tend to be better organized.
+
+
+ Unfortunately, there are a few problems with the scheme
outlined above.
+
+First, if two users on the same host subscribe to the same interest group, two
copies
+
+of the message get delivered. This is wasteful of both processor and disk
resources.
+
+
+ Second, some of these groups carry a lot of traffic. Although
subscription
+
+to an group does indicate interest on the part of a subscriber, it is usually
not
+
+interesting to get 50 messages or so delivered to the user's private maildrop
each
+
+day, interspersed with personal mail, that is likely to be of a much more
important
+
+and timely nature.
+
3
+
+
+ Third, if a subscriber on the distribution list for a group
becomes "bad"
+
+somehow, the originator of the message and not the moderator of the group is
+
+notified. It is not uncommon for a large list to have 10 or so
bogus addresses
+
+present. This results in the originator being flooded with "error messages"
from
+
+mailers across the ARPA Internet stating that a given address on the list was
bad.
+
+Needless to say, the originator usually could not care less if the bogus
addresses
+
+got a copy of the message or not. The originator is merely interested in
posting a
+
+message to the group at large. Furthermore, the moderator of the group does
care
+
+if there are bogus addresses on the list, but ironically does not receive
notification.
+
+
+ To solve all of these problems, the UCI BBoards facility introduces a
new
+
+entity into the picture: all interest group mail is handled by a special
component of
+
+the mail system. The distribution address maps to a special channel that
performs
+
+several actions. First, if local delivery is to be performed, then
a copy of the
+
+message is placed in a global maildrop for the interest group with a timestamp
+
+and a unique number. Local users can read messages posted for the interest
group
+
+by reading the file. Second, if further distribution is to take
place, a copy of
+
+the message is sent to the distribution address in such a way that if any of
the
+
+addresses are bogus, the failure notice is sent to the maintainer of the group
and
+
+not the originator.
+
+
+ This scheme has several advantages: First, messages delivered to the
host
+
+are processed and saved once in a globally accessible area. The UCI
BBoards
+
+facility supports software which allows a user to query the interest
group for
+
+new messages and to read those messages in the MH-style. Second, once a host
+
+subscribes to an interest group, a user can add or remove him/herself from the
list
+
+without contacting the moderator. Third, a hierarchical distribution scheme
can
+
+be constructed to further reduce the amount of message traffic. Fourth,
errors are
+
+prevented from propagating. When an address on the distribution list goes bad,
+
+the request address immediately responsible for the address is notified.
Usually,
+
+this is the local PostMaster and not the group moderator.
+
+
+ In addition to solving the problems outlined above, the UCI BBoards
facility
+
+supports several other capabilities. BBoards may be automatically archived in
+
+order to conserve disk space and reduce processing time when reading them.
+
+
+ Special alias files may be generated which allow the MH user
to shorten
+
+address type-in. For example, instead of sending to address@hidden''
,
+
+a user of MH usually sends to ``SF-Lovers'' and the MH
aliasing facility
+
+automatically makes the appropriate expansion in the headers of the
outgoing
+
+message. Hence, one need only know the name of a interest group and not its
+
+address.
+
4
+
+
+ Finally, the UCI BBoards facility supports private interest groups
using the
+
+UNIX group access mechanism. This allows a group of people on the
same or
+
+different machines to conduct a private discussion.
+
+
+ The practical upshot of all this is that the UCI BBoards facility
automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+
+BBoard Handling
+
+ Usually the term BBoard is used interchangeably with the terms
discussion
+
+group and interest group. This is true of the discussion that follows.
+
+
+ The messages for a BBoard delivered locally are kept in the same
format as a
+
+maildrop.2 Unlike the user's private maildrop however, the inc program is not
run
+
+to incorporate new BBoard messages into the user's MH ``+inbox''
folder. The
+
+programs which are used will be discussed momentarily.
+
+
+ Each message in a BBoard maildrop has a unique number and a timestamp.
+
+The number, called the BBoard-ID, is always ascending. The BBoard-ID
of a
+
+message should NOT be confused with the message number of a message, which
+
+can change as messages are removed from the BBoard. The BBoard-ID is a value
+
+which is unique for every message delivered locally to the BBoard.
+
+
+ To read BBoards, the MH user invokes bbc. The bbc program has several
+
+switches to direct it's action. The `-topics' switch to bbc tells the
MH user about
+
+the status of a BBoard. The `-check' switch to bbc lets the MH user
check on the
+
+activity of a BBoard. The `-read' switch to bbc invokes the msh program
on the
+
+BBoard. msh is a monolithic program which contains most of the functionality
of
+
+MH in a single program. These commands are now discussed in greater detail.
+
+
+BBoard status
+
+ The `-topics' option to the bbc program can be used to report
information
+
+about a BBoard that does not pertain to the user's reading habits. If the MH
users
+
+types
+
+
+ bbc -topics
+
+
+then bbc will list the following information for all BBoards received on the
host:
+
+
+ - the official name of the BBoard
+
+
+ - the number of messages delivered to the BBoard (but not
necessarily
+
+ present)
+
+
+_____________________________________
+2 Actually, your site might be running with all BBoards kept on a single
host. MH supports the
+
+remote access of BBoards using a modified version of the ARPA Post Office
Protocol (POP). This
+has the advantage that it saves a lot of disk space, and incurs only a modest
performance penalty.
+
5
+
+
+ - the date and time of the last message delivered to the BBoard
+
+
+
+In addition to `-topics' , if the `-verbose' option is given to
bbc, then more
+
+information is listed:
+
+
+ - any aliases the BBoard is known as
+
+
+ - the local leaders of the BBoard
+
+
+ - the file that the BBoard is locally delivered to
+
+
+ - the "global" distribution address
+
+
+ - the "global" request address
+
+
+ - the host that distributes the BBoard to the local host
+
+
+ - the addresses to which this host distributes
+
+
+ - miscellaneous information (presently only archiving status)
+
+
+
+Naturally, bbc can be invoked with the `-topics' option and one or more
BBoard
+
+names listed on its command line. For example
+
+
+ bbc -topics unix-wizards
+
+
+is completely acceptable _ it tells bbc to report the status of
the BBoard
+
+``unix-wizards'' .
+
+
+BBoard checking
+
+ The `-check' option to the bbc program can be used to check for
new BBoard
+
+messages in a synchronous fashion (i.e., when you specifically ask for it).
The MH
+
+users types
+
+
+ bbc -check
+
+
+and bbc consults the profile entry for ``bboards:'' in the user's
.mh_profile file.
+
+For each BBoard listed, bbc prints one of several messages depending on the
status
+
+of both the BBoard and the user's reading habits (for example, in the case of
the
+
+mythical BBoard ``foo'' ):
+
+
+ 1. ``foo -- n items unseen''
+
+ This message indicates items in the BBoard have not been seen
by the
+
+ user. When bbc is invoked with the ``quiet'' switch,
this is the only
+
+ informative message that bbc will print out. Users of MH
usually put
+
+
+ bbc -check -quiet
+
+
+ in their $ HOME/.login file.
+
6
+
+
+ 2. ``foo -- empty''
+
+ The BBoard is empty.
+
+
+ 3. ``foo -- n items (none seen)''
+
+ The BBoard has n items in it, but the user hasn't seen any.
+
+
+ 4. ``foo -- n items (all seen)''
+
+ The BBoard is non-empty, and the user has seen everything in it.
+
+
+ 5. ``foo -- n items seen out of m''
+
+ The BBoard has at most m n items that the user has not seen.
+
+
+
+It is important to note that bbc performs its calculations on BBoard-ID:s and
not
+
+the messages actually present in a BBoard. This means that the numbers given
by
+
+bbc are maximal end-points. When bbc says n, bbc means "at most n".
+
+
+ Naturally, bbc can be invoked with the `-check' option and one
or more
+
+BBoards listed on its command line. For example
+
+
+ bbc -check info-c poli-sci
+
+
+is completely acceptable _ it tells bbc to check on the BBoards ``info-c''
and
+
+``poli-sci'' only.
+
+
+ There are two ways to check for new BBoard messages in an asynchronous
+
+fashion: using the CShell variable $ mail and running the useto program.
+
+
+Asynchronous Checking with the CShell
+
+ The CShell has a variable called $ mail . This variable can contain
one or more
+
+words. Each word should be a filename where the shell should check for new
mail.
+
+The check is performed after a specified time interval has elapsed just before
the
+
+shell would prompt the user.
+
+
+ If the first word of $ mail is a number, then this number specifies
a different
+
+checking interval, in seconds, than the default, which is 10 minutes.
+
+
+ Whenever the time interval elapses and the shell is ready to prompt
the user,
+
+the shell looks at the file and decides if new messages have arrived. If so,
it says
+
+
+ You have new mail.
+
+
+if only one file is present in $ mail . Otherwise, if more than one file is
present in
+
+$ mail , then the shell says
+
+
+ New mail in foo.
+
+
+whenever there is new mail in the file called ``foo'' .
+
7
+
+
+ To find out what file is associated with a BBoard, say ``info-unix''
, the
+
+MH user types
+
+
+ bbc -topics -verbose info-unix
+
+
+Usually the local file for a BBoard has an extension of .mbox .
+
+
+Asynchronous Checking with Useto
+
+ In contrast to using the $mail variable in the CShell, the
MH user might
+
+employ useto instead.3 The useto program is a continuous update display that
+
+prints information on the status line of your terminal. Needless to
say, your
+
+terminal must support a status line in order to run useto. Not all terminals
have
+
+this capability, but for those that do it's usually well worth the effort to
run useto.
+
+
+ For example, users of MH could put
+
+
+ useto -bepf tcp-ip sftp % D % M % d % h:% m% z% b % n.tty% t:% l1
+
+
+in their $ HOME/.login file. This command line to useto says to inform
the user of
+
+
+ - the current date and time
+
+
+ - new mail for the user
+
+
+ - new messages for the BBoards ``tcp-ip'' and ``sftp''
+
+
+ - the name of the host and tty that the user is logged in on
+
+
+ - the 5-minute load average of that host
+
+
+ The useto program is really quite amusing and useful.4
+
+
+BBoard reading
+
+ If bbc is not given either the `-check' or `-topics'
option, the bbc program
+
+reads BBoard messages. For each BBoard listed in the MH user's profile entry
for
+
+``bboards:'' , bbc checks to see if there is unread mail. If so, bbc
starts msh on
+
+the BBoard, telling msh which messages haven't been seen.5
+
+
+ When msh starts it identifies the BBoard being read and indicates how
many
+
+messages are present and how many the user has read. Usually, in the user's MH
+
+profile, the user has the entry
+
+
+ msh: -scan
+
+
+
+_____________________________________
+3 Not all sites have useto; contact the same people who supplied MH to get a
copy.
+4 To be honest, the author considers computing environments without
useto to be less than
+
+adequate.
+5 If the `-verbose' option is given to bbc, then bbc will start msh on
the BBoard regardless of
+
+whether there are unseen messages there.
+
8
+
+
+ This says that when msh starts, it should print a scan listing of
the messages which
+
+ the user hasn't seen yet.
+
+
+ The msh program now prompts the user for MH commands. The
user may
+
+ type most of the normal MH command. The syntax and semantics of
the commands
+
+ typed to msh are identical to their MH counterparts. For example,
to reply to
+
+ a message on the BBoard, the MH user types ``repl'' ;
other MH commands
+
+ likewise may be applied to BBoard messages. In cases where the
nature of msh
+
+ would be inconsistent (e.g., specifying a `+folder' with some
commands), msh
+
+ will duly inform the user. In addition to supporting most MH
commands, msh also
+
+ has a ``help'' command which gives a brief overview.
+
+
+ The only command that behaves entirely differently in msh
is the ``mark''
+
+ command when given no arguments. The msh program maintains
a special
+
+ sequence, ``unseen'' , which it uses to keep track of the
messages you've seen. If
+
+ the ``mark'' command is given without any arguments, then msh
will interpret it
+
+ as
+
+
+ mark -sequence unseen -delete -nozero all
+
+
+ Hence, to discard all of the messages in the current BBoard being
read, the MH
+
+ user types ``mark'' which says to remove all messages
from sequence called
+
+ ``unseen'' .
+
+
+ To leave msh use the ``quit'' command. This tells msh
to terminate and
+
+ bbc to go to the next BBoard. Instead, if the user types EOT
(usually CTRL-D),
+
+ then bbc will exit as well, updating whatever information was
appropriate.
+
+
+
+ Current BBoards
+
+ There are many, many active interest groups. Consult the
BBoard called
+
+ ``list-of-lists'' for a comprehensive description. Here
are a few of the more
+
+ popular:
+
+
+ system Important announcements for the local system are
posted here.
+
+
+ mh-users A discussion group for users of MH.
+
+
+arpanet-bboards Redistribution address for all known BBoards on the
ARPAnet.
+
+
+ editor-people Discussion of topics related to computerized
text editing, display
+
+ editors, and human factors in man/machine
interaction. The theoretical
+
+ discussion is catholic, but practical discussion
focuses particularly on
+
+ Tops206 and UNIX.
+
+
+ franz-friends Discusses the Franz Lisp language.
+
+
+ _____________________________________
+ 6 Tops20 is a trademark of Digital Equipment Corporation.
+
9
+
+
+header-people Interest specifically in the format of message headers
and related issues
+
+ such as inter-network mail formats/standards, etc.
+
+
+ human-nets Human-Nets has discussed many topics, all of
them related in some
+
+ way to the theme of a world-wide computer and
telecommunications
+
+ network usually called WorldNet. The topics have
ranged very widely,
+
+ from something like tutorials, to state of the art
discussions, to rampant
+
+ speculation about technology and its impact.
+
+
+ info-micro Information/discussion list on the general interest
topic of microcom-
+
+ puters.
+
+
+ info-unix Info-UNIX is intended for question/answer discussion,
where "novice"
+
+ system administrators can pose questions.
+
+
+ msggroup Interest in electronic mail, message formats, message
systems, and the
+
+ sociological implications of the above.
+
+
+ poli-sci A permanent distributed political "bull" session.
+
+
+ sf-lovers Science Fiction lovers. SF-Lovers has discussed many
topics, all of them
+
+ related in some way to the theme of science fiction or
fantasy.
+
+
+ space Discussions (daily digest) on space-related topics.
+
+
+ telecom A broad spectrum moderated-digest-format discussion on
telecommu-
+
+ nictions technology: the telephone system, modems,
and other more
+
+ technical aspects of telecommunications systems.
+
+
+ unix-emacs Used for new release announcements and general
discussions of Gosling's
+
+ EMACS.
+
+
+ unix-wizards Distribution list for people maintaining machines
running the UNIX
+
+ operating system.
+
+
+
+ As discussed earlier, to find out about all of the BBoards
that the local host
+
+ subscribes to, the MH users types
+
+
+ bbc -topics
+
+
+
+ More on BBoards
+
+ Finally, here are a few more operational details:
+
+
+ Creating a BBoard
+
+ Contact the PostMaster at your host to have a BBoard created.
Be sure to
+
+ indicate its status (public or private) and scope (where distribution
should occur).
+
10
+
+
+ Subscribing to a BBoard
+
+ If your local host already receives an interest group,
then simply add the
+
+ name of the BBoard to the ``bboards:'' entry in your MH
profile. If not, ask the
+
+ PostMaster to create the BBoard and contact the global request
address for you.
+
+
+ BBoard Archives
+
+ BBoard messages are automatically archived on a weekly
basis. Usually, this
+
+ results in messages older than 12 days being moved to an archive
area. To read
+
+ the archives for a BBoard, the `-archive' option is used.
For example,
+
+
+ bbc -archive telecom
+
+
+ tells bbc to invoke msh on the archives for the ``telecom''
BBoard.
+
+
+ Note that the archives may not be present for all
BBoards on a given host;
+
+ also note that the archives may be periodically moved to tape
and expunged from
+
+ the system. Contact your local PostMaster for the details.
+
+
+ BBoard Addresses
+
+ Each BBoard has associated with it 4 addresses (for
example, in the case of
+
+ the mythical BBoard ``foo'' ):
+
+
+ foo The global distribution list
+
+ If you post a message addressed to foo then the
message is distributed
+
+ to everyone who subscribes to ``foo'' .
+
+
+ dist-foo The local distribution list
+
+ If you post a message addressed to
dist-foo then the message is
+
+ distributed to the local BBoard for ``foo''
and to any sites which the
+
+ local system distributes to.
+
+
+ foo-request The global moderator
+
+ If you post a message addressed to foo-request
then the message is
+
+ sent to the moderator for the entire interest
group called ``foo'' .
+
+
+local-foo-request The local moderator
+
+ If you post a message addressed to
local-foo-request then the
+
+ message is sent to the person responsible for the
BBoard ``foo'' on
+
+ the local system.
+
+
+
+ These addresses are defined by the MH alias facility. Users of
the BBoards facility
+
+ who do not use MH may not be able to make use of them.
+
+
+ Leading a BBoard
+
+ Except for special circumstances, this task is wholly
automated. For more
+
+ information though, see the manual entries for bbl (1) and
bbleaders (8).
+
11
+
+
+Extra for Experts
+
+ Some clever MH users might ask why BBoards aren't kept as folders
instead
+
+of pack'd files. This is a good question. Perhaps some future release of MH
and the
+
+UCI BBoards facility will treat BBoards as a variant of read-only folders.
+
+
+ The problem with msh, of course, is that it's a monolithic
program, and
+
+although it does support input/output redirection and a few other
primitive
+
+shell-like properties, it's still not the CShell.
+
12
+
+
+ References
+
+
+
+[MH] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
+
+ User's Manual. UCI Version. Department of Information and
Computer
+
+ Science, University of California, Irvine (July, 1984).
+
+
+
+[MH.TUT] M.T. Rose. The Rand MH Message Handling System:
Tutorial.
+
+ Department of Computer and Information Sciences,
University of
+
+ Delaware (October, 1984).
+
+
+
+
+ Contents
+
+
+
+
Page
+
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 1
+
+ Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1
+
+ Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1
+
+ Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 2
+
+ Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 2
+
+ BBoard Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 4
+
+ BBoard status . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 4
+
+ BBoard checking. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 5
+
+ Asynchronous Checking with the CShell. . . . . . . . . . . . .
. . . 6
+
+ Asynchronous Checking with Useto. . . . . . . . . . . . . . .
. . . . 7
+
+ BBoard reading . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 7
+
+ Current BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 8
+
+ More on BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 9
+
+ Creating a BBoard . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 9
+
+ Subscribing to a BBoard . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 10
+
+ BBoard Archives. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 10
+
+ BBoard Addresses . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 10
+
+ Leading a BBoard . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 10
+
+ Extra for Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 11
+
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 12
+
+
+
+ _____________________________________
+This document (version #2.6) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+ i
diff --git a/docs/historical/beginners.pdf b/docs/historical/beginners.pdf
new file mode 100644
index 0000000..8d12ca0
Binary files /dev/null and b/docs/historical/beginners.pdf differ
diff --git a/docs/historical/beginners.txt b/docs/historical/beginners.txt
new file mode 100644
index 0000000..18cf893
--- /dev/null
+++ b/docs/historical/beginners.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+ MH for Beginners
+
+
+
+ Mary Hegardt Tim Morgan
+
+
+
+ April 12, 1990
+
+
+
+This document is intended to be an introduction for new users to
the MH
+
+mail system. For more detailed information, users will want to read
the
+
+document called The Rand MH Message Handling System: User's Manual
+
+by Marshall T. Rose and John L. Romine. It is available for
Xeroxing in
+
+suite CS408.
+
+
+
+1 Using Electronic Mail
+
+
+
+Electronic mail (e-mail) is a quick, convenient way to send a
message to
+
+another person (or persons). The message recipient can read and
reply to
+
+the message at his convenience. E-mail is much faster than a paper
memo
+
+and avoids inconveniences associated with the telephone such as
unwanted
+
+interruptions and "phone tag."
+
+
+At UCI, one can send e-mail to people within the ICS department, people in
+
+other units on campus, and to people at some other institutions off
campus
+
+(usually other universities).
+
+
+An electronic mail message consists of two parts: the headers and the body.
+
+The body comes after the headers and consists of the "message":
whatever
+
+the sender types in. The headers are the lines at the top of the
message
+
+including the subject and addresses of the people to whom the
message is
+
+addressed. It is similar to the top lines of a memo: To:, From:,
Subject:,
+
+and so on. The headers are separated from the body by a blank line. As in
+
+
+
+ 1
+
+
+
+
+memos, the people listed in the Cc: field are not intended to be the primary
+
+recipients of the message. The message is for their information
only, and
+
+they are not expected to reply.
+
+
+E-mail is also useful for discussions among groups of people. This "bboards"
+
+(electronic bulletin boards) facility will be discussed later.
+
+
+An electronic mail address looks like "name @site ". The name is a
person's
+
+"mail handle" _ usually his first initial followed by his last
name. For
+
+example, Mary Hegardt's mail handle is "mhegardt". The site is the system
+
+where the addressee receives mail. Within the ICS Department, you
need
+
+only know the person's mail handle; the mail system will
automatically fill
+
+in the "@site " part.
+
+
+
+2 Why MH ?
+
+
+
+The MH system is very different from most mail user agents.
Instead of
+
+running one large program which handles all mail functions and keeps
mes-
+
+sages in one large file, MH is a collection of smaller single-purpose programs
+
+used to manipulate mail messages which are kept in individual files.
MH
+
+may seem to be more complicated or harder to use than other mail systems
+
+(MM, for example), but MH has been designed to allow you to take full ad-
+
+vantage of existing Unix1 commands and programs in connection with mail
+
+messages. For example, you can use your usual text editor, spelling program,
+
+and printer commands on individual messages.
+
+
+
+3 The Basics
+
+
+
+The first time you use an MH command (probably inc), MH will
create a
+
+directory called "Mail" in your home (login) directory. All your mail will be
+
+stored in directories beneath this one. It will also create a file in your
home
+
+directory called .mh_profile. It is a file that allows you to
tailor your MH
+
+environment. We'll discuss this more later.
+________________________________________________
+ 1 Unix is a trademark of AT&T Bell Laboratories
+
+
+
+ 2
+
+
+
+
+3.1 Reading Mail
+
+
+
+When someone sends a mail message to you, it is delivered to a
file called
+
+your "mail drop" file. When you are ready to read your mail, you
have to
+
+incorporate (or "inc") your mail messages from the mail drop area into your
+
+account.
+
+
+Everytime you log in to your Unix account, you will be told if
you have
+
+new mail messages. When you are ready to read them, type inc. The
inc
+
+program will copy your mail into your "inbox" and generate a "scan" listing
+
+of the new messages. For example,
+
+
+
+4.2 BSD UNIX #116: Mon Jul 15 14:03:21 PDT 1985
+You have new ZOTnet mail, type "inc" (or mail)
+
+TERM = (dm1520)
+
+% inc
+
+Incorporating new mail into inbox ...
+
+ 1+ 10/29 1732-PST Tim Morgan new bboard! <<Please add
us to the uni
+ 2 11/12 0016-PST address@hidden CP6 from the 20s <<What is
(will be) t
+ 4 11/15 1909-EDT address@hidden Hello, got a few
questions
+ 5 11/15 2134-PST Marshall Rose MH.6 on 750a <<Mary, I've
left the dis
+ 6 11/16 0808-PST Mail Delivery Su Returned mail: Host unknown
+ 7 11/16 1021-PST Tim Morgan Unix-wizards/info-unix move
+ 8 11/18 0952-PST address@hidden Re:New system wide aliases for
ICS facu
+ 9 11/18 1346-EDT address@hidden Have we got a
problem?
+
+
+
+This is what a typical "inc" session for the Postmaster looks like. Inc
copies
+
+my mail into my "inbox" folder, assigns a unique number to each
message,
+
+and scans them for me. The numbers allow you to refer to each
message
+
+individually. After the message number, you see the date and time the mes-
+
+sage was sent, the name of the sender, and the subject of the message. The
+
+"current" message is indicated by a "+" sign. To read it, type "show":
+
+
+
+% show
+
+ (Message inbox:1)
+ Received: from localhost by UCI.EDU id a005369; 29 Oct 85 17:32
PST
+ To: address@hidden
+ Subject: new bboard!
+ Date: 29 Oct 85 17:32:24 PST (Tue)
+ From: Tim Morgan <address@hidden>
+
+
+
+ 3
+
+
+
+
+ Please add us to the unix-sw list. Also, if RAJ hasn't
mentioned it,
+ and if it still exists, we should get on the Astronomy bboard.
+
+ Tim
+
+
+
+If the message is longer than one screenful, you will see the word "more" at
+
+the bottom_of_the_screen.__When you are ready to see "more" of the
message,______
+
+press the __space_bar______ __to see another screenful, or press the
__return____ _key to see
+
+just one more line.
+
+
+To see the next message, you could type a couple of different commands:
+
+
+ % next
+
+
+or
+
+
+ % show next
+
+
+or
+
+
+ % show 2
+
+
+All of these commands would have the same effect: to type out the
next
+
+message in the list. The most efficient thing to do is to type "next". When
+
+You do that, message number 2 will be shown and become the "current
+
+message".
+
+
+
+% next
+
+
+(Message inbox:2)
+Received: from UCI-20B by UCI-ICSA id aa01222; 12 Nov 85 0:23 PST
+Date: 12 Nov 1985 0016-PST
+From: address@hidden
+Subject: CP6 from the 20s
+To: address@hidden
+cc: address@hidden
+
+
+What is (will be) the prescribed method of addressing for sending
+CP6 mail from the 20s? They dont seem to know about @CF, @UCICP6,
+but "Name_Name%UCICP6"@ICSA seems to fly.
+
+
+dana
+
+
+
+ 4
+
+
+
+
+3.2 Selecting Messages
+
+
+
+As you have seen, messages can be referred to by their message
numbers.
+
+Some MH commands, such as show, can act upon more than one message
+
+at a time. A range of messages can be specified using the form
"name1-
+
+name2 " where name is a message number or one of the reserved
message
+
+names described below:
+
+
+
+ cur The current message (the last one that was handled)
+
+
+ next The next message (same as cur + 1)
+
+
+ prev The previous message (cur 1)
+
+
+ first The first message in the current folder
+
+
+ last The last message in the folder
+
+
+ all All messages (first last )
+
+
+
+If you do not name a specific message, the command will act upon the "cur-
+
+rent message".
+
+
+
+3.3 Sending Messages
+
+
+
+A mail message consists of two parts: the headers and the body. The headers
+
+are the lines at the top of the message that say "To:" and so on. The body
+
+is the actual text of the message (what you want to say). To send
someone
+
+a message, you start with the comp command. This will start up an
editor
+
+called prompter that will prompt you to fill in_the_headers._ You should type
+
+the requested information for that header or a __return____ _to_omit_it._ You
should
+
+end the message by typing control-D (press down the key marked __ctrl__ __and
+
+strike the D key) at the beginning of a new line. Here's an example:
+
+
+
+% comp
+
+To: morgan, raj
+
+Cc:
+
+
+
+ 5
+
+
+
+
+Subject: Lunch
+
+---------
+
+Where are we going for lunch today ?
+
+
+
+Mary
+
+<control-D>
+
+--------
+
+What now ? send
+
+
+
+At the "What now ?" prompt you can type a ? to see what commands
you
+
+can type next. One of the most useful options at this point is
to edit the
+
+draft of the message to correct any mistakes. To do this you type:
+
+
+ What now ? edit vi
+
+
+This will put you in the vi editor to edit the message. If you use emacs or
any
+
+other editor, just type "edit emacs" or whatever. When you have
finished
+
+editing, just exit the editor as you would normally. You will then get another
+
+"What now ?" prompt. Here are some of the "What now" options:
+
+
+
+ edit editor Edit the message using the specified
editor. When you
+
+ exit, you will be back at What now.
+
+
+ list Shows the message you just typed
+
+
+ whom -check Verifies that the addresses you have used are
valid as far
+
+ as our system can tell
+
+
+ send Sends the message to the recipients
+
+
+ push Sends the message in the background
+
+
+ quit Quits without sending the message. Saves
the text of
+
+ the message as a "draft". Type comp -use
to get back
+
+ to that draft later.
+
+
+ quit -delete Quit, throwing away the draft
+
+
+
+Make sure you are happy with your message before typing send. There is no
+
+way to recall a message once it has been sent.
+
+
+
+ 6
+
+
+
+
+3.4 Replying to Messages
+
+
+
+To reply to the current message type repl. When you do this, the
reply
+
+headers will be printed out and you will be put in the prompter
editor to
+
+type in your reply text. When you are replying to a message, the
name of
+
+the sender of the original message will appear in the "To:" field. Any people
+
+on the "To:" or "Cc:" lists will also be copied on your reply
message. As
+
+with comp, when you have finished, type control-D and send (or
whatever)
+
+at What now ?.
+
+
+
+3.5 Forwarding Messages
+
+
+
+If you receive a particularly interesting message and can't resist
sharing
+
+it with others, you can forward it using the forw command. You
will be
+
+prompted to fill in the headers (the address to which the message
is to be
+
+forwarded, etc.). When you have done this, you will see the text of the mes-
+
+sage which you are forwarding and will be given the opportunity to add some
+
+enlightening text to the message. Exit with control-D and do whatever feels
+
+good at the What now ? prompt.
+
+
+
+3.6 The Advanced Features
+
+
+
+You will probably want to master the beginning MH concepts before
you
+
+tackle the following. . .
+
+
+
+3.7 Folders
+
+
+
+Folders are really just directories for storing mail messages in an
organized
+
+way. To store a message in a folder named "inbox", type:
+
+
+ % refile 5 +inventory
+
+
+If the folder doesn't exist yet, you will be asked if it should
be created. To
+
+access messages in another folder, you can change your current
folder from
+
+
+
+ 7
+
+
+
+
+"inbox" to something else. If you want to look at all the messages pertaining
+
+to the inventory, you type:
+
+
+ % folder +inventory
+
+
+and now you use scan, show, etc., to manipulate the messages in that folder.
+
+To change back to inbox, type:
+
+
+ % folder +inbox
+
+
+Using the inc command will change your current folder to be the
"inbox"
+
+automatically.
+
+
+
+4 Mailing files
+
+
+
+Mailing files is usually not a good idea, especially for large
files. The mail
+
+system was never designed for moving big files. You can use the cp
file to
+
+move the file to another account much more efficiently:
+
+
+ % cp "frated/desired-file "./newfile
+
+
+This will copy the file from frated's account to the current directory and call
+
+it "newfile".
+
+
+You can also copy files across the network using rcp:
+
+
+ % rcp icsd:frated/desired-file ./newfile
+
+
+This copies frated's file on the system icsd to the current directory.
+
+
+If you really have to mail a file, you use the mhmail program. To mail a
file
+
+"myfile" to another user "frated", with "MyFile" as the subject type:
+
+
+ % mhmail frated -subject MyFile < myfile
+
+
+
+5 Searching for messages
+
+
+
+The pick program allows you to search your inbox (or any other)
folder to
+
+find messages which contain a certain word. If you want to list all messages
+
+
+
+ 8
+
+
+
+
+from Smith you can type:
+
+
+ % pick -from smith -list
+
+
+and it will list the numbers of all messages from Smith that are
in the cur-
+
+rent folder. You can pick messages according to any of the headers
(-to
+
+-from -subj -cc or -date) or just search all the messages for a given word
+
+(-search).
+
+
+
+6 The MH Profile
+
+
+
+Each MH user has a file in his directory called .mh_profile. This file
contains
+
+a list of user-specified default options for MH programs. The only
required
+
+entry is the name of your MH directory:
+
+
+ Path: Mail
+
+
+or
+
+
+ Path: mhbox
+
+
+To make a change to your .mh_profile, you edit the file and add a line for
+
+the applicable program. For example, if you would like to use vi
instead of
+
+prompter as your initial editor when composing messages, you would
add
+
+this line to your .mh_profile:
+
+
+ comp: -editor vi
+
+
+or, if you want to have a format file for scan to use, you should have:
+
+
+ scan: -form formatfile
+
+
+Almost all of the MH programs have options that can be set using
the
+
+.mh_profile. You should consult the MH User's Manual for more infor-
+
+mation about this.
+
+
+Many people will want to add a signature line to their .mh_profile.
This
+
+line will appear as your signature on the From: line in messages you send. It
+
+looks like this:
+
+
+
+ 9
+
+
+
+
+ Signature: John Q. Public
+
+
+Occasionally people express an interest in getting rid of some of
the header
+
+lines in their mail messages. They don't want to see the "Received
from",
+
+"Via" information, or some other header. It is possible to prevent
these
+
+and other annoying headers from being displayed by changing your show
+
+processor to be mhless. To do this you must add this line
+
+
+ showproc: mhless
+
+
+to your .mh_profile. You also must create a file called ".mhlessrc" contain-
+
+ing the words which appear at the beginning of the lines you don't
want to
+
+see.
+
+
+The typical ".mhlessrc" file will look like this:
+
+
+
+Received
+
+Via
+
+BB-Posted
+
+Return-Path
+
+
+
+The ".mhlessrc" file must be in your home directory.
+
+
+
+7 BBoards
+
+
+
+Electronic bulletin boards (BBoards) are a convenient way for a group of peo-
+
+ple to discuss a particular topic. Messages are sent to an address where they
+
+can be read and replied to by all interested parties. In the ICS
department
+
+we have some "local" BBoards which involve only people in the department.
+
+We also subscribe to many nationally distributed BBoards. BBoards are
+
+read using the bbc program which will allow you to read the
messages with
+
+an MH-like interface.
+
+
+One very important BBoard is "system". It contains vital news about
+
+changes in software, system downtime, new programs, and other informa-
+
+tion useful to all users.
+
+
+
+ 10
+
+
+
+
+To read a BBoard, you type "bbc BBoard__name ". The bbc program
will
+
+check to see if there are new messages in the named BBoard and if there are,
+
+it will start up msh so you can read them. The msh program allows
you to
+
+use regular MH commands when reading BBoards. Type "show" to see the
+
+current message, "next" to see the next message, and so on. Type "quit" to
+
+quit reading the current BBoard. If you have named more than one BBoard
+
+on the command line or in your .mh_profile, bbc will continue
processing
+
+the next BBoard in the list.
+
+
+Here is an example of using bbc to read the system BBoard:
+
+
+
+ 11
+
+
+
+
+% bbc system
+Reading system, currently at message 1 of 22
+(msh) show
+
+
+(Message 1, BBoard-ID: 1360)
+BBoard-ID: 1360
+BB-Posted: Wed, 29 Jan 86 15:36:39 PST
+Received: from localhost by UCI.EDU id a006693; 29 Jan 86 15:20 PST
+To: address@hidden
+Subject: Imagen 24300
+Date: Wed, 29 Jan 86 15:19:43 -0800
+From: Tinh Tang <address@hidden>
+
+
+The Imagen 24300 is now operating normally. It was broken down
+due to the paper jammed in the drum. Luckily, it didn't cause
+any damage.
+
+
+/ttang
+
+
+(msh) next
+
+
+(Message 4, BBoard-ID: 1363)
+BBoard-ID: 1363
+BB-Posted: Fri, 31 Jan 86 13:33:37 PST
+Received: from localhost by UCI.EDU id a001631; 31 Jan 86 13:30 PST
+To: address@hidden
+Subject: uci.edu down 2/7/86 17:10 - 2/7/86 20:30
+Date: Fri, 31 Jan 86 13:30:27 -0800
+From: address@hidden
+
+
+The uci.edu will be down from
+February 7,1986 17:10 till February 7,1986 20:30.
+The reason for the downtime is:
+Both, the Computing Facility and the Physical Sciences Dataswitches
+will be unavailable from 5:10pm until 8:30pm on Friday, February 7th.
+Therefore all the Computers attached to those switches and the
+corresponding tandem link will be unavailable to users on
+the specified time. (RJ).
+
+
+Downtime Scheduler
+
+
+(msh) quit
+%
+
+
+
+ 12
+
+
+
+
+You can see a list of all the available BBoards by typing:
+
+
+ % bbc -topics
+
+
+You can also put a line in your ".mh_profile" listing all the
BBoards you
+
+want to read on a regular basis:
+
+
+ bboards: system movies mh-users events
+
+
+Then you only need to type "bbc" to read all your BBoards.
+
+
+
+8 Checking for Mail
+
+
+
+Under Unix, there are many different ways to check for new mail. The easiest
+
+way to do it is to set the csh variable named "mail" to tell csh to check for
+
+new mail for you periodically. To do this, add the line
+
+
+ set mail=(60 /usr/spool/mail/$USER)
+
+
+to the .login file in your home directory. This command says to
check for
+
+mail if csh is about to prompt you with a % sign, and if it has been at least
+
+60 seconds since it last checked for mail. The advantage of this
method of
+
+mail notification, besides simplicity, is that you will never be interrupted by
+
+a mail notification. You will only be notified about new mail when
you are
+
+between commands.
+
+
+If you want asynchronous mail notification, which will print to your terminal
+
+regardless of what you are currently doing, you may make use of a
"receive
+
+mail hook" called "rcvtty". To do this, create a file in your home
directory
+
+called ".maildelivery". In this file, put the line
+
+
+ * - pipe R /usr/uci/lib/mh/rcvtty
+
+
+Then, each time mail arrives, you will receive a one-line "scan"
listing of
+
+the mail if your terminal is world-writable. For more information
on mail
+
+delivery files, type:
+
+
+ % man 5 maildelivery
+
+
+
+ 13
+
+
+
+
+This will tell you about all the options available to you if you use
maildelivery
+
+files.
+
+
+
+9 Aliases
+
+
+
+Using MH, you may specify your own private mail aliases. This feature allows
+
+you to store lists of addresses or long internet addresses of people with whom
+
+you frequently correspond in one file, and then to address them
using short
+
+mnemonic names. Typically, you will call your alias file "aliases"; it must
+
+be stored in your MH directory. The format of this file is simple.
The alias
+
+is given, followed by a colon, followed by one or more legal mail
addresses
+
+separated by commas. For example, you might for some reason have an alias
+
+for all the users named "Rose" in the ICS department:
+
+
+ roses: prose, srose, mrose, drose
+
+
+In addition to your "aliases" file, you will need to
modify your
+
+.mh_profile in order to use aliases. You should add the flag
"-alias
+
+aliases" to the entries for the commands ali, whom, send, and push,
cre-
+
+ating entries for these programs if they aren't already in your .mh_profile.
+
+Now, messages addressed to "roses" will be distributed to all the
people
+
+listed in the alias.
+
+
+The ali command is used to show you what an alias expands to. You
just
+
+type
+
+
+ % ali alias
+
+
+and ali will respond with the expansion of the alias. Ali searches the
system
+
+aliases file in addition to your private ones.
+
+
+
+10 Blind Lists
+
+
+
+There are two different types of so-called "blind addressing" of
messages.
+
+The BCC: field allows you to add recipients to your message just
like those
+
+who are CC'd, but the normal recipients will not see that the BCC recipients
+
+
+
+ 14
+
+
+
+
+were copied on the message, their replies will not go to the blind recipients,
+
+and the blind recipients cannot (easily) reply to the message.
+
+
+The second type of blind mailing is actually called a "group
address list",
+
+although it is commonly referred to as a "blind list". The format of this type
+
+of address is
+
+
+ phrase : address__list ;
+
+
+where the "phrase " is any English phrase of one or more words,
and the
+
+address__list consists of one or more addresses separated by commas.
The
+
+recipients of a message addressed in this fashion will see simply
+
+
+ phrase : ;
+
+
+so when they reply to the message, their reply will come only to
the sender
+
+(or the Reply-To: field, if one was specified), rather than going
to all the
+
+recipients of the original list. For example, to use a group address list for
the
+
+"roses" alias you would type:
+
+
+ To: People Named Rose: roses;
+
+
+This type of group address is very useful for making up lists of related
people,
+
+such as all the people working on a particular research project.
+
+
+
+ 15
diff --git a/docs/historical/changes.pdf b/docs/historical/changes.pdf
new file mode 100644
index 0000000..12b4c64
Binary files /dev/null and b/docs/historical/changes.pdf differ
diff --git a/docs/historical/changes.txt b/docs/historical/changes.txt
new file mode 100644
index 0000000..813e341
--- /dev/null
+++ b/docs/historical/changes.txt
@@ -0,0 +1,1452 @@
+
+
+
+
+
+
+
+
+
+ Changes to
+ The RAND MH Message Handling System:
+ UCI version MH 6.8
+
+
+ John L. Romine
+
+ Computing Support Group
+ Department of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92717-3425
+ address@hidden
+
+
+ _A_B_S_T_R_A_C_T
+
+
+ This document describes the changes to the
+ UCI version of the RAND MH system from MH 6.6 to
+ this release of MH 6.8. This document is meant to
+ supplement, not supersede, the standard MH User's
+ manual and MH Administrator's manual.
+
+ Comments concerning this documentation should
+ be addressed to the mailbox address@hidden, or
+ ucbvax!ucivax!bug-mh.
+
+
+
+ _A_C_K_N_O_W_L_E_D_G_E_M_E_N_T_S
+
+ The _M_H system described herein is based on the original RAND
+ _M_H system. It has been extensively developed (perhaps too
+ much so) by Marshall T. Rose and John L. Romine at the
+ University of California, Irvine. Einar A. Stefferud, Jerry
+ N. Sweet, and Terry P. Domae provided numerous suggestions
+ to improve the UCI version of _M_H.
+
+ Of course, a large number of people have helped _M_H
+ along. The list of "_M_H immortals" is too long to list here.
+ For this release, numerous _M_H-_W_o_r_k_e_r_s sent in
fixes and
+ other changes. A handful of courageous _M_H-_W_o_r_k_e_r_s
volun-
+ teered to beta-test these changes; their help is particu-
+ larly appreciated.
+
+
+
+
+
+
+
+
+
+
+ December 1, 1993
+
+
+
+
+
+ Changes to MH 6.8 2
+
+
+
+ _D_I_S_C_L_A_I_M_E_R
+
+ The Regents of the University of California wish to make it
+ known that:
+
+ Although each program has been tested by its con-
+ tributor, no warranty, express or implied, is made
+ by the contributor or the University of Califor-
+ nia, as to the accuracy and functioning of the
+ program and related program material, nor shall
+ the fact of distribution constitute any such war-
+ ranty, and no responsibility is assumed by the
+ contributor or the University of California in
+ connection herewith.
+
+ _C_O_N_V_E_N_T_I_O_N_S
+
+ In this document, certain formatting conventions are adhered
+ to:
+
+ The names of UNIX commands, such as _c_o_m_p are presented
+ in _i_t_a_l_i_c_s.
+
+ Arguments to programs, such as `msgs' and `-nobell' are
+ delimited by single-quotes.
+
+ Text that should be typed exactly as-is, such as com-
+ mand lines (e.g., "folder -pack"), are delimited by
+ double-quotes.
+
+ UNIX pathnames and envariables, such as /usr/uci and
+ $SIGNATURE, are presented in bold font.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ December 1, 1993
+
+
+
+
+
+ Changes for MH 6.8.3 3
+
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._8._3
+
+ The MH 6.8.3 maintenance release contains few user-visible
+ changes. Most of the changes are internal to the multi-
+ media display program _m_h_n to support RFC 1521 (the new MIME
+ standard). This is the current version of MH as of December
+ 1, 1993.
+
+ _R_u_n_t_i_m_e _T_a_i_l_o_r_i_n_g
+
+ When posting mail using the SMTP, _p_o_s_t does not normally
+ send the HELO command. This is because _S_e_n_d_M_a_i_l
would fail
+ if the host name given in the HELO command was the local
+ host. Later versions of _S_e_n_d_M_a_i_l will now complain
if you
+ omit the HELO command.
+
+ If you specify a hostname with the clientname: option
+ in the _m_t_s_t_a_i_l_o_r file, _p_o_s_t will give the
HELO command with
+ that name, otherwise no HELO command is given. See _m_h-
+ _t_a_i_l_o_r(5) for more details.
+
+ _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+ folder The _f_o_l_d_e_r command now has `-create' and
`-nocreate'
+ options. See _f_o_l_d_e_r(1) for details.
+
+ inc A bug where `-host' would not override the pophost
+ as set in the _m_t_s_t_a_i_l_o_r file has been
fixed. This
+ bug was also fixed in _m_s_g_c_h_k.
+
+ mhn The _m_h_n command has several changes: updates for
+ conformance with RFC 1521, addition of two caches:
+ public and private, addition of two caching poli-
+ cies: one for reading and one for writing, support
+ for storing multipart entities, and a few bug fixes.
+ See _m_h_n(1) for complete details.
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._8._2
+
+ The MH.6.8.2 patch release contains only internal changes to
+ support the BSD 4.4 and 386BSD versions of UNIX. This ver-
+ sion of _M_H was released August 25, 1993, but was not widely
+ distributed.
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._8._1
+
+ The MH.6.8.1 patch release is a maintenance release. This
+ is the current released version of _M_H as of August 20, 1993.
+
+ This release includes a small number of bug fixes, a
+ few minor enhancements, some changes for the new MIME stan-
+ dard, and support for ESMTP (RFC 1425). Support for BSD 4.4
+ and 386BSD is planned for the next release.
+
+
+
+
+ December 1, 1993
+
+
+
+
+
+ Changes for MH 6.8.3 4
+
+
+ Many other fixes which have already been received are
+ still being merged. If you've sent an update for MH 6.8 to
+ address@hidden and it isn't in this release, it'll prob-
+ ably appear in the next release.
+
+ _F_i_x_e_s _a_n_d _E_n_h_a_n_c_e_m_e_n_t_s
+
+ Many minor documentation corrections were made. There are
+ also a few program changes:
+
+ mhn The `-cache policy', `-[no]check', and `-[no]pause'
+ switches have been added. Some other minor changes
+ have been made to comply with the new MIME standard.
+ See _m_h_n(1) for complete details.
+
+ post When posting mail with SendMail, _p_o_s_t will not use the
+ ONEX command when it is posting a message with BCCs.
+
+ scan _s_c_a_n will now work with big width values.
+
+ _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+ One new function has been added:
+
+ %(profile arg) This function looks up a component in the
+ .mh_profile or context files and returns the
+ value of that component.
+
+ _C_o_n_f_i_g_u_r_a_t_i_o_n
+
+ Two new configuration options are present:
+
+ GCOS_HACK The so-called "gcos" field of the password file
+ is used as a last resort to find the user's
+ full name (see _m_h-_p_r_o_f_i_l_e(5) for
details).
+ Enable this option if your _p_a_s_s_w_d(5) man
page
+ notes that the `&' character in the "gcos"
+ field stands for the login name.
+
+ NORUSERPASS Tells _M_H that your system doesn't have the
+ _r_u_s_e_r_p_a_s_s(3) routine; _M_H will
include its own
+ copy of this routine in its library.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ December 1, 1993
+
+
+
+
+
+ Changes for MH 6.8 5
+
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._8
+
+ This is the current released version of _M_H as of December
+ 14, 1992. This release includes a number of bug fixes and
+ internal changes to make the code more portable. Two new
+ authentication methods are provided for the POP, and support
+ for SVR4 shared libraries is complete.
+
+ The major user-visible change in this release is the
+ incorporation of support for multi-media mail as specified
+ by the Multi-purpose Internet Mail Extensions (MIME)
+ RFC 1341. This allows you to include things like audio,
+ graphics, and the like, in your mail messages. A new com-
+ mand, _m_h_n, has been provided to support MIME and a detailed
+ man page is provided in _m_h_n(1).
+
+ _D_o_c_u_m_e_n_t_a_t_i_o_n
+
+ The documentation has some general improvements, and the
+ READ-ME document has been re-organized to help _M_H adminis-
+ trators find the appropriate configuration options for their
+ system. The Makefiles in the papers/ hierarchy have been
+ changed to invoke _T_e_X as "tex" (instead of "tex82").
+
+ The following new man pages are also available:
+
+ _m_h_n(1) _m_h_n helps the user process multi-media mail.
+
+ _m_h_p_a_r_a_m(1) _m_h_p_a_r_a_m lets the user
extract information from
+ the _M_H profile.
+
+ _p_o_p_a_u_t_h(8) the APOP database administration program
(see
+ below).
+
+ _p_o_p_i(1) the POP initiator (see below).
+
+ _s_l_o_c_a_l(1) fully documents _s_l_o_c_a_l. The
_m_h_o_o_k(1) man page
+ now documents only the _M_H receive-mail hooks.
+
+ _I_n_t_e_r_n_a_l _C_h_a_n_g_e_s
+
+ The _M_H source code is in the process of being cleaned up to
+ make pedantic ANSI C compilers happy. Occurrences of "NULL"
+ have been replaced by "0" where appropriate. Extra tokens
+ after "#else" and "#endif" have been put inside comments
+ (this is still in progress). The code should now compile
+ cleanly on many more systems, specifically, more variants of
+ SVR4.
+
+ The version of tws/dtimep.c which was included in MH
+ 6.7.2 was incompatible with the _l_e_x library on some systems,
+ and has been removed.
+
+ A bug in the handling of blind lists inside alias files
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.8 6
+
+
+ has been fixed.
+
+ _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l
+
+ There were three new options added to the POP.
+
+ APOP This option indicates that the POP daemon will support
+ the non-standard APOP command which provides a
+ challenge-based authentication system using the MD5
+ message digest algorithm.
+
+ This option also causes the _p_o_p_a_u_t_h program to
be in-
+ stalled, which allows the administrator to manipulate
+ the APOP authorization database.
+
+ KPOP Support for KERBEROS with POP. This code builds _p_o_p_d,
+ _i_n_c and _m_s_g_c_h_k to support only the "kpop"
protocol.
+ This code is still expiremental, but is available for
+ those sites wishing to test it.
+
+ MPOP This option indicates that the POP daemon will support
+ the non-standard XTND SCAN command which provides per-
+ formance enhancements when using the POP over low-
+ speed connections.
+
+ This option also causes an interactive POP client pro-
+ gram, _p_o_p_i, to be compiled and installed. A man page
+ for the _p_o_p_i program is also provided. This option
+ requires the configuration to have "bboards: pop".
+
+ The APOP and MPOP non-standard POP facilities are documented
+ in _T_h_e _I_n_t_e_r_n_e_t _M_e_s_s_a_g_e (ISBN
0-13-092941-7), a book by
+ Marshall T. Rose. For more details, see support/pop/pop-
+ more.txt and the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s
_G_u_i_d_e. The APOP option
+ peacefully co-exists with the standard POP, KPOP completely
+ replaces the standard POP, and MPOP requires "bboards: pop".
+
+ _F_i_l_e _L_o_c_k_i_n_g
+
+ The file locking code has been cleaned up to support three
+ kinds of kernel-level file locking. As appropriate for your
+ system, include the LOCKF, FCNTL or FLOCK option. For more
+ details, see _m_h-_t_a_i_l_o_r(5).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.8 7
+
+
+ Configuration Directives
+
+ A number of new configuration directives have been added or
+ changed. The full details are given in the READ-ME.
+
+ cp: The command used to install new files if not
+ "cp".
+
+ ln: The command used to link files together in the
+ source tree if not "ln".
+
+ mts: Full support for ZMAILER has been added.
+
+ popdir: The directory where _p_o_p_d will be installed if not
+ /usr/etc.
+
+ regtest: Set to "on" to prevent the hostname and compile
+ date from being included in _M_H binaries.
+
+ sharedlib: You may now specify "sun4" or "sys5" (for SVR4)
+ shared libraries.
+
+ signal: Specifies the base type of the function returned
+ by _s_i_g_n_a_l(). This was previously defined
with
+ "options TYPESIG".
+
+ Several `-D' options to _c_c have been added or changed:
+
+ APOP Authenticated POP (see above).
+
+ AUX Support for A/UX systems.
+
+ DBMPWD The DBM option has been renamed DBMPWD.
+
+ HESIOD Support for the HESIOD name server.
+
+ KPOP KERBEROS POP (see above).
+
+ LOCALE Support for local characters sets; uses the _s_e_t_-
+ _l_o_c_a_l() function.
+
+ MAILGROUP Makes _i_n_c set-group-id. You may need this option
+ if your /usr/spool/mail is not world-writeable.
+
+ MIME Multi-media mail.
+
+ MPOP Mobile POP (see above).
+
+ MSGID Enables _s_l_o_c_a_l to detect and surpress
duplicate
+ messages.
+
+ OSF1 Support for DEC OSF1 systems. May be incomplete.
+
+ RENAME Include this option if your system has a
_r_e_n_a_m_e()
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.8 8
+
+
+ system call.
+
+ SVR4 Support for System 5 Release 4 or newer systems.
+
+ TYPESIG This option has been dropped. See `signal'
+ above.
+
+ UNISTD Include this option if your system has the
+ include file <unistd.h>.
+
+ VSPRINTF Include this option if your system has the
+ _v_s_p_r_i_n_t_f() library routine; otherwise,
__d_o_p_r_n_t()
+ will be used.
+
+ YEARMOD Forces the _m_h-_f_o_r_m_a_t `year' function to
return
+ 2-digit values. Use this option during a brief
+ transition period if you have local
_m_h-_f_o_r_m_a_t
+ files which need to be converted to support 4-
+ digit years.
+
+ _F_U_N_C_T_I_O_N_A_L _C_H_A_N_G_E_S
+
+ In addition to the configuration changes mentioned above, a
+ number of functional changes have been made to the system.
+ Many programs have new features added and a few new programs
+ have are provided. Each command's manual page gives complete
+ information about the its operation. Here is a short sum-
+ mary of the changes.
+
+ _M_H _S_e_q_u_e_n_c_e_s
+
+ A larger number of user-defined sequences are available.
+ Previously, this number had been 10. On 32-bit systems, 26
+ user-defined sequences are available.
+
+ _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s
+
+ _M_H programs will now complain if the .mh_profile does not
+ end in a newline. Also, one enhancement and one new profile
+ component are provided:
+
+ Aliasfile: Multiple filenames may now be given.
+
+ Inbox: New; the default folder (for _i_n_c, etc.) if not
+ "inbox".
+
+
+
+
+
+
+
+
+
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.8 9
+
+
+
+ _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+ A few minor bugs were fixed in format string handling, and a
+ few new features were added. See _m_h-_f_o_r_m_a_t(5) for
complete
+ details.
+
+ Addresses An attempt is made to decipher X.400
+ RFC 987-style addresses.
+
+ Comments Comments may be added to _m_h-_f_o_r_m_a_t
files; a
+ comment begins with the 2-character sequence
+ "%;", and ends with an un-escaped newline.
+
+ %(modulo n) The `modulo' function escape has been added.
+
+ %(year{date}) The date parser has been enhanced to under-
+ stand more illegal date formats; `year' now
+ returns a 4-digit number.
+
+ _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+ A number of _M_H commands have minor changes:
+
+ ali The output with `-user -list' was changed to match
+ the output with `-nouser -list'.
+
+ burst Will no longer drop the last message of a digest.
+
+ inc Accepts the `-apop' switch for authenticated POP
+ (see above); will attempt to detect write errors
+ (e.g., no space left on device) when incorporating
+ mail; no longer replaces newline characters with
+ NULLs.
+
+ folder The `-noprint' option was broken and has been
+ dropped.
+
+ forw Supports `-mime' to use MIME-style multi-part mes-
+ sages.
+
+ mhl Will no longer put an extra space at the end of
+ the `%{text}' in a formatfield.
+
+ mhn New; manipulates multi-media (MIME) messages; a
+ detailed man page is provided.
+
+ mhparam New; reads the _M_H profile (and context) and writes
+ the values of the specified components on the
+ standard output; useful in programmatic con-
+ structs.
+
+ msgchk Supports `-apop' (see above).
+
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.8 10
+
+
+ packmbox New; packs an _M_H folder into a UUCP-style mailbox.
+
+ popi New; a client-side POP initiator; available only
+ if you built _M_H with the MPOP option (see above).
+
+ refile A bug where the `rmmproc' did not remove all
+ specified message files has been fixed.
+
+ scan The `-file' option is fully supported and will no
+ longer complain about empty folders.
+
+ send Supports `-mime' and `-split' to split large mes-
+ sages into multiple partial messages using MIME.
+
+ _S_u_p_p_o_r_t _P_r_o_g_r_a_m_s
+
+ fmtdump Can now read a format file, or a format string
+ given on the command line.
+
+ popauth New; manages the APOP authorization database (see
+ above).
+
+ sendmail The _s_e_n_d_m_a_i_l replacement will be installed
only if
+ your `mts' setting uses the `/smtp' option.
+
+ slocal A new man page for _s_l_o_c_a_l is available; the new
+ `mbox' action is available to write a file in
+ _p_a_c_k_f format; a bug where extra `>' characters
+ were written to MMDF-style maildrops has been
+ fixed; if compiled with the MSGID option, can
+ detect and suppress reception of duplicate mes-
+ sages.
+
+ viamail New; bundles a directory (like _s_h_a_r) and sends it
+ through multi-media mail.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ December 14, 1992
+
+
+
+
+
+ Changes for MH 6.7.2 11
+
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._7._2
+
+ The MH.6.7.2 patch release is a maintenance release. This
+ is the current released version of _M_H as of February 1,
+ 1992.
+
+ This release now supports the NCR Tower running SYS5R4.
+ The WP changes installed in MH.6.7.0 have been removed.
+
+ _S_h_a_r_e_d _L_i_b_r_a_r_i_e_s
+
+ Support for SYS 5 shared libraries is in progress.
+
+ Support for Sun OS 4.0 shared libraries had been
+ improved. The _M_H library has been modified to move initial-
+ ized data into a data definition file. The shared library
+ will now consist of a libmh.so and libmh.sa file. The
+ shared library version number will no longer track the _M_H
+ patch release number, and its numbering begins with version
+ `1.1' with this release.
+
+ _R_e_p_l_a_c_e_m_e_n_t _S_e_n_d_M_a_i_l
+
+ Since many standard system programs expect to post mail by
+ invoking /usr/lib/sendmail, a minimal replacement
_S_e_n_d_M_a_i_l
+ is provided in this release. This replacement is meant to
+ be installed on (e.g., diskless) client workstations which
+ post mail using SMTP, and do not run a message transport
+ system. It will call _p_o_s_t to post mail; be sure you have
+ configured _M_H with the `/smtp' mts option. This sendmail
+ replacement is installed in your _M_H etc directory, and you
+ should link /usr/lib/sendmail to it.
+
+ _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+ A manual page for the _f_m_t_d_u_m_p format string
disassembler is
+ supplied, and some new format functions were added:
+
+ folder In _s_c_a_n, this component escape contains the name of
+ the current folder. It is not defined for other _M_H
+ commands.
+
+ getenv This function escape returns the value of an en-
+ vironment variable.
+
+ There will be some additional changes in these routines
+ in the next patch release.
+
+
+
+
+
+
+
+
+
+
+ Feb 1, 1992
+
+
+
+
+
+ Changes for MH 6.7.2 12
+
+
+
+ _O_t_h_e_r _B_u_g _F_i_x_e_s _a_n_d
_E_n_h_a_n_c_e_m_e_n_t_s
+
+ In addition to some other minor enhancements, some bugs were
+ fixed which in general were not user-visible:
+
+ Blind lists Users may now specify RFC822 address groups in
+ their alias files. These groups are imple-
+ mented by _M_H as blind lists.
+
+ date parsing A number of sites have brain-damaged versions
+ of lex. _M_H will now come with the date parser
+ already run through lex.
+
+ mark A bug dealing with _m_a_r_k and the sequence named
+ `cur' is fixed. This was previously a problem
+ for mh-e users.
+
+ MH.doc The _M_H nroff version of the manual no longer
+ contains teletype escape sequences.
+
+ scan Can now handle headers as long as 512 bytes.
+
+ Signals _M_H programs will no longer catch the HUP and
+ TERM signals while waiting for a sub-process.
+ This was causing hung processes when your ter-
+ minal line was was dropped unexpectedly.
+
+ Signature If your signature is not defined, _M_H will use
+ the value of the gecos field of your
+ /etc/passwd entry as your signature.
+
+ version.sh A bug in the awk script in config/version.sh
+ was fixed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Feb 1, 1992
+
+
+
+
+
+ Changes for MH 6.7.1a 13
+
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._7._1_a
+
+ The MH.6.7.1a patch was made available on January 25, 1991
+ for limited distribution only. (This release had some known
+ bugs, and so was not widely distributed.) This release
+ incorporates several new features of particular note to
+ users of sequences and format strings, as well as some gen-
+ eral documentation improvements. There are a few minor
+ enhancements and internal bug fixes also. Complete documen-
+ tation of these changes is given in the individual manual
+ pages, and the READ-ME file.
+
+ _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e_s
+
+ A new manual page, _m_h-_s_e_q_u_e_n_c_e (5), has been
added. This
+ manual page attempts to completely document the syntax and
+ semantics of _M_H message sequence specifications.
+
+ A powerful new feature is the ability to specify mes-
+ sage ranges with user-defined sequences. The specification
+ "name:n" may be used, and it designates up to the first `n'
+ messages (or last `n' messages for `-n') which are
+ elements of the user-defined sequence `name'.
+
+ The message specifications "name:next" and "name:prev"
+ may also be used, and they designate the next or previous
+ message (relative to the current message) which is an ele-
+ ment of the user-defined sequence `name'. The specifica-
+ tions "name:first" and "name:last" are equivalent to
+ "name:1" and "name:-1", respectively. The specification
+ "name:cur" is not allowed (use just "cur" instead).
+
+ These specifications allow the user to step through a
+ sequence with a command like "show name:next".
+
+ _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+ _M_H format strings now support an if-then-elseif-else clause
+ (the `elseif' is new). This will make format strings with
+ multi-case conditions somewhat less complex.
+
+ A new format function `addr' had been added. This
+ function takes an address header name as its argument, and
+ returns a rendering of the address contained in that header
+ as "address@hidden" or "host!user".
+
+ Format widths now may be specified as a negative
+ number. This causes the output to be right-justified within
+ the format width.
+
+
+
+
+
+
+
+
+ January 25, 1991
+
+
+
+
+
+ Changes for MH 6.7.1a 14
+
+
+
+ _O_t_h_e_r _C_h_a_n_g_e_s
+
+ Along with a few minor enhancements, some bugs were fixed
+ which in general were not user-visible:
+
+ fmtdump This new program produces an pseudo-language
+ representation of an _M_H format file, vaguely remin-
+ iscent of assembly language. While this output
+ format is not explicitly documented, it can still
+ be useful when debugging _M_H format files.
+
+ refile Now takes a `-[no]rmmproc' switch. This makes it
+ easier to avoid loops when your "rmmproc" calls _r_e-
+ _f_i_l_e.
+
+ slocal A problem with the UUCP-style mailboxes, the
+ `RPATHS' configuration option, and the "Return-
+ Path:" header was fixed.
+
+ sortm Will ensure that no messages are lost if it is in-
+ terrupted.
+
+ whatnow Will now tell you where it is leaving the draft,
+ when interrupted in the initial edit. Previously
+ the draft was simply unlinked.
+
+ _C_o_m_p_i_l_a_t_i_o_n _O_p_t_i_o_n_s
+
+ LOCKF This option causes _M_H to use the lockf() system
+ call for locking (if available), instead of
+ flock().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ January 25, 1991
+
+
+
+
+
+ Changes for MH 6.7.1 15
+
+
+ _C_H_A_N_G_E_S _F_O_R _M_H _6._7._1
+
+ The MH.6.7.1 patch release is a maintenance release, and as
+ such, provides few changes from the previous release. This
+ is the current released version of _M_H as of December 14,
+ 1990.
+
+ _U_s_e_r-_V_i_s_i_b_l_e _C_h_a_n_g_e_s
+
+ The major change in this release is to the POP daemon
+ (popd). In _M_H 6.7, it was changed to be able to read both
+ UUCP and MMDF-style mailboxes. This did not work as
+ reported. The code has now been changed to parse MMDF-style
+ mailboxes if you are configuring MH to run with MMDF as your
+ message transport system. Otherwise, UUCP-style mailboxes
+ are expected.
+
+ Since there are number of client programs available for
+ only the POP2 protocol instead of POP3, popd has been
+ updated to support both protocols. This is a major win. If
+ you are compiling with POP turned on, add the `POP2' option
+ to your _M_H config file, and the POP daemon will respond to
+ POP2 or POP3 commands. If you're using POP, there's no rea-
+ son not to include this option; it does not affect the
+ existing support for POP3.
+
+ _I_n_t_e_r_n_a_l _C_h_a_n_g_e_s
+
+ Some bugs were fixed which in general were not user-visible:
+
+ context Errors when writing out sequences are detected
+ correctly.
+
+ inc No longer inserts extra blank lines into mes-
+ sages.
+
+ mh-format A nil pointer bug in the address parser was
+ fixed.
+
+ repl, etc. The malloc/free problem has been fixed.
+
+ rmf A spelling error in the `-nointeractive' switch
+ has been corrected.
+
+ rcvtty Will not print the message size if not available
+ (i.e., zero).
+
+ send/post Illegal signatures (those containing unquoted
+ "."s) will be quoted.
+
+
+
+
+
+
+
+
+ December 14, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 16
+
+
+ _G_E_N_E_R_A_L _C_H_A_N_G_E_S _F_O_R _M_H
_6._7._0
+
+ The author is pleased to announce that there are very few
+ user-visible changes to _M_H 6.7 from the previous _M_H 6.6 dis-
+ tribution. The majority of development was in the form of
+ bug fixes and slight enhancements. In addition, this
+ release is slightly faster than the previous release. With
+ a few minor exceptions, it is backward-compatible with the
+ previous release. _M_H 6.7.0 is the current released version
+ of _M_H as of April 12, 1990.
+
+ The changes were made mainly to generalize the source
+ code to be compatible with a larger range of systems and
+ compilers. There were many small changes to add declara-
+ tions for ANSI C compliance. The System 5 support has been
+ brought up to SYS5 R3, and there is support for Sun OS 4.0.
+
+ _U_s_e_r-_V_i_s_i_b_l_e _C_h_a_n_g_e_s
+
+ Here a quick summary of the changes that were made which are
+ not backward-compatible with the previous release of _M_H:
+
+ repl The `-format' and `-noformat' switches have not been
+ functional since _M_H 5, and have been removed. Any
+ users who have these switches in their .mh_profile,
+ will have to remove them.
+
+ sortm Previously, in most cases _s_o_r_t_m would fill-in any
+ gaps in the numbering of a folder, by renumbering the
+ messages starting with `1'. This will no longer
+ occur; for this behavior, use "folder -pack".
+
+
+ _U_s_i_n_g _A_l_i_a_s_e_s
+
+ A new profile entry `Aliasfile:' has been added. The _a_l_i,
+ _s_e_n_d, and _w_h_o_m programs will look for this profile
entry and
+ treat it as they would an argument to `-alias'. This should
+ make it easier for novice _M_H users to begin using aliases.
+
+
+ _R_e_a_d_i_n_g _N_e_t_w_o_r_k _N_e_w_s &
_B_B_o_a_r_d_s
+
+ The UCI BBoards facility can read local BBoards, and if com-
+ piled with the `bboards: pop' and `pop: on' options, can
+ also read remote BBoards using the Post Office Protocol (POP
+ ver. 3). With this release, _M_H can instead be compiled to
+ read the Network News (i.e., USENET) using the Network News
+ Transfer Protocol (NNTP).
+
+ This capability is enabled by compiling _M_H with the
+ `bboards: nntp' and `pop: on' options. Unfortunately, read-
+ ing remote BBoards via the POP and reading the Network News
+ via the NNTP are mutually exclusive options.
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 17
+
+
+ To support the NNTP, a new module, uip/pshsbr.c, is
+ compiled and loaded into _b_b_c and _m_s_h instead of
+ uip/popsbr.c. The default BBoard is changed from "system"
+ to "general" for the NNTP.
+
+ When reading BBoards, _b_b_c will first look for local
+ BBoards, and then contact the NNTP server to read the Net-
+ work News. The location of the NNTP server should be speci-
+ fied with the `nntphost:' entry in the mtstailor file (see
+ the _M_H Administrator's Guide for details), or may be speci-
+ fied on the command line with the `-host' switch.
+
+
+ _F_o_r_m_a_t _S_t_r_i_n_g_s
+
+ The manual page _m_h-_f_o_r_m_a_t (5) has been rewritten to
give a
+ better explanation of how to write format strings, and how
+ they are interpreted by _M_H. A line-by-line description of
+ the default _r_e_p_l form file (replcomps) is now included in
+ that manual page.
+
+ Some new format functions were added, and others were aug-
+ mented:
+
+ trim Strips any leading and trailing white-space from
+ the current string value.
+
+ date2local Will coerce the date to the local timezone.
+
+ date2gmt Will coerce the date to GMT.
+
+ divide Divides the current numeric value by its argu-
+ ment. This could be useful for building _s_c_a_n
+ format strings which print large message sizes
+ in "Kb" or "Mb".
+
+ friendly If the address field cannot be parsed, this
+ function will return the text of the address
+ header, instead of a null string.
+
+ szone A flag indicating whether the timezone was ex-
+ plicit in the date string.
+
+ _P_R_O_G_R_A_M _C_H_A_N_G_E_S
+
+ In addition to the general changes mentioned above, many
+ programs have specific new features added, either by new
+ switches or by expanded functionality. Each command's
+ manual page gives complete information about its new
+ options. Here is a short summary.
+
+ _U_s_e_r _I_n_t_e_r_f_a_c_e _P_r_o_g_r_a_m_s
+
+ anno Accepts a `-nodate' switch which inhibits the date
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 18
+
+
+ annotation, leaving only the body annotation.
+
+ folder When invoked with the `-pack' switch and the new
+ `-verbose' switch, _f_o_l_d_e_r will give information
+ about the actions taken to renumber the folder.
+
+ On most systems, _f_o_l_d_e_r can now create any
+ non-existing parent folders of a new sub-folder.
+
+ forw When making digests, _f_o_r_w will put the issue and
+ volume numbers in addition to the digest list
+ name, in the digest trailer.
+
+ inc Detects NFS write failures, and will not zero your
+ maildrop in that event.
+
+ msh Supports a variant of the new _s_o_r_t_m.
+
+ prompter Considers a period on a line by itself to signify
+ end-of-file when the `-doteof' switch is speci-
+ fied.
+
+ repl The `-[no]format' switches have not been used
+ since _M_H 5 and have been deleted. _r_e_p_l will now
+ find filter files in the _M_H library area.
+
+ scan With the `-file msgbox' switch, _s_c_a_n can list a
+ _p_a_c_k_f'd-format file directly (without using
_m_s_h).
+
+ Lists messages in reverse order with the
+ `-reverse' switch. This should be considered a
+ bug.
+
+ sortm Now has the options: `-textfield field', `-notext-
+ field', `-limit days', and `-nolimit'.
+
+ With these options, _s_o_r_t_m can be instructed to
+ sort a folder based on the contents of an arbi-
+ trary header such as "subject".
+
+ _s_o_r_t_m minimizes renaming messages, and will no
+ longer arbitrarily pack folders; for this
+ behavior, use "folder -pack".
+
+ whatnow Deletes the draft by renaming it with leading
+ comma, instead of unlinking it.
+
+ _M_H _S_u_p_p_o_r_t _P_r_o_g_r_a_m_s
+
+ The following support programs also have changes or enhance-
+ ments:
+
+ mhl Will now accept a format string on any component,
+ not just on addresses and dates.
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 19
+
+
+ popd Will use _s_h_a_d_o_w passwords if compiled with the
SHA-
+ DOW option. It can now also read UUCP-style mail-
+ drops directly.
+
+ rcvtty If given no arguments, _r_c_v_t_t_y will produce a scan
+ listing as specified by a format string or file; a
+ default format string is used if one is not speci-
+ fied.
+
+ Before the listing is written to the users terminal,
+ the terminal's bell is rung and a newline is output.
+ The `-nobell' and the `-nonewline' options inhibit
+ these functions.
+
+ _r_c_v_t_t_y will obey terminal write notification set
by
+ _m_e_s_g. With the `-biff' switch, _r_c_v_t_t_y
will also
+ obey the mail notification status set by _b_i_f_f.
+
+ On BSD43 systems, as with _w_r_i_t_e,
_r_c_v_t_t_y will be
+ installed set-group-id to the group "tty".
+
+ slocal Understands UUCP-style "From " lines and will write
+ output files using this format if appropriate.
+ Before invoking a delivery program, _s_l_o_c_a_l will
+ strip such lines unless compiled with the RPATHS
+ option, in which case it will will convert such
+ lines into "Return-Path:" headers.
+
+ _s_l_o_c_a_l has a new result code "N", for use in
.mail-
+ delivery files. With this result code, _s_l_o_c_a_l
will
+ perform the action only if the message has not been
+ delivered and the previous action succeeded. This
+ allows for performing an action only if multiple
+ conditions are true.
+
+ _D_O_C_U_M_E_N_T_A_T_I_O_N
+
+ Several of the older _M_H papers have been difficult to format
+ because they depended on an older version of PhDTeX which
+ was not supplied. These papers have been updated, and some
+ TeX library files are supplied in papers/doclib/, so that
+ these papers may be generated on any system with TeX.
+
+ Many of the manual pages have been revised to include
+ documentation of new command options, and some have been
+ expanded to give more detail. All are now slightly refor-
+ matted at installation time to make them more compatible
+ with programs like _m_a_k_e_w_h_a_t_i_s.
+
+
+ _M_H _A_D_M_I_N_I_S_T_R_A_T_I_O_N
+
+ This section describes changes in configuring, compiling and
+ installing _M_H 6.7 and should not be of interest to casual _M_H
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 20
+
+
+ users. The READ-ME file has been considerably revised and
+ expanded to give more detail about the configuration and
+ compilation options which have been included in this
+ release. Some compilation options have been removed, and
+ many new options have been added.
+
+ All _M_H Makefiles have been updated to work around some
+ incompatibilities introduced in newer versions of _m_a_k_e.
_M_H
+ programs will no longer be installed with the sticky-bit
+ turned on.
+
+ Reading this section not a substitute for carefully
+ reading the READ-ME file before attempting to compile _M_H
+
+
+ _B_u_g _F_i_x_e_s
+
+ Some bugs were fixed which in general were not user-visible:
+
+ address parser Fixed to allow use of the "AT" domain, and
+ some minor bugs were fixed pertaining to ad-
+ dress groups.
+
+ date parser Improved to accept more forms of illegal
+ dates. Military timezones were removed.
+
+ dynamic memory Many problems with corruption of the dynamic
+ memory pool have been fixed.
+
+ locking Will open files for write, if necessary to
+ enable locking.
+
+ nil pointers All reported nil pointer problems have been
+ fixed.
+
+ replcomps The "In-Reply-To:" header had quotes added
+ around the date field to comply with RFC822.
+
+ _W_h_i_t_e _P_a_g_e_s
+
+ If _M_H is compiled with the WP option, _s_e_n_d recognizes an
+ address between "<<" and ">>" characters such as:
+
+ To: << rose -org psi >>
+
+ to be a name meaningful to a whitepages service. In order
+ to expand the name, _s_e_n_d must be invoked interactively
+ (i.e., not from _p_u_s_h). For each name, _s_e_n_d will
invoke a
+ command called _f_r_e_d in a special mode asking to expand the
+ name.
+
+ To get a copy of the white pages service, contact
+ address@hidden
+
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 21
+
+
+ _C_o_n_f_i_g_u_r_a_t_i_o_n _O_p_t_i_o_n_s
+
+ Some configuration options have been added or changed:
+
+ cc To specify an alternate C compiler.
+
+ ccoptions Defaults to `-O'.
+
+ bboards May now be defined as "on", "off", "pop", or
+ "nntp".
+
+ bbdelivery Determines whether the bboard delivery agent and
+ library files should be installed.
+
+ lex To specify an alternate version of _l_e_x.
+
+ mailgroup If defined, _i_n_c will be made set-group-id to
+ this group.
+
+ sharedlib For SUN40 systems; if "on", makes libmh.a into a
+ shared library.
+
+ slibdir The directory where the above shared library
+ should be installed.
+
+ sprintf Set this to "int" if that's what your
+ _s_p_r_i_n_t_f (3) library routine returns.
+
+ _C_o_m_p_i_l_a_t_i_o_n _O_p_t_i_o_n_s
+
+ For different configurations, several `-D' options to _c_c
+ have been added or changed:
+
+ BERK This disables the address and date parsing rou-
+ tines. If you want to do much with
+ _m_h-_f_o_r_m_a_t (5), don't enable this.
+
+ BSD43 Will make _r_c_v_t_t_y set-group-id to the group
+ "tty".
+
+ DBM For sites with a dbm-style password file (such
+ as with Yellow Pages), _M_H will not read the
+ entire passwd file into a cache. At one site
+ that runs YP on a large passwd file, using this
+ showed a 6:1 performance improvement.
+
+ NETWORK This option has been deleted. See SOCKETS.
+
+ NOIOCTLH Tells _M_H not to include the file sys/ioctl.h.
+ Use this if this file is not present on your
+ system.
+
+ NTOHLSWAP On systems with TCP/IP networking, _m_s_h will try
+ to use the ntohl() macro from the file
+
+
+
+ April 12, 1990
+
+
+
+
+
+ Changes for MH 6.7.0 22
+
+
+ netinet/in.h to byte-swap the binary map files
+ it writes.
+
+ SENDMAILBUG Some versions of _s_e_n_d_m_a_i_l return a 451
(failure)
+ reply code when they don't mean to indicate
+ failure. This option considers that code to be
+ equivalent to 250 (OK).
+
+ SHADOW Causes _p_o_p_d to read the file /etc/shadow for
+ encrypted passwords instead of /etc/passwd. Use
+ this if you have a shadow password file (such as
+ on newer versions of SYSTEM 5).
+
+ SOCKETS Enable this if you are on a non-BSD system with
+ a socket interface for TCP/IP networking compa-
+ tible with 4.2BSD UNIX.
+
+ SUN40 Use on Suns running Sun OS 4.0 and later.
+
+ SYS5 This option has been updated to refer to SYS5 R3
+ and later systems.
+
+ SYS5DIR Use this if your system uses "struct dirent"
+ instead of "struct direct". This should be true
+ for systems based on SYS5 R3 and later.
+
+ TYPESIG Defines the base type for the _s_i_g_n_a_l system
+ call. This defaults to "int", but should be
+ defined as "void" if appropriate for your sys-
+ tem.
+
+ WP Enables support for the White Pages service.
+
+ _I_n_s_t_a_l_l_a_t_i_o_n
+
+ _M_H will now explicitly set the protection mode on every file
+ it installs.
+
+ Previously any existing file installed by _M_H would be
+ backed up into the source tree, and then overwritten. Now,
+ a few system-dependent files will not be overwritten, and
+ your changes will have to be merged in by hand. See the
+ READ-ME file for more details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ April 12, 1990
+
+
diff --git a/docs/historical/designOfMH.pdf b/docs/historical/designOfMH.pdf
new file mode 100644
index 0000000..bf86e4f
Binary files /dev/null and b/docs/historical/designOfMH.pdf differ
diff --git a/docs/historical/mh-gen.pdf b/docs/historical/mh-gen.pdf
new file mode 100644
index 0000000..d71cd7d
Binary files /dev/null and b/docs/historical/mh-gen.pdf differ
diff --git a/docs/historical/mh-gen.txt b/docs/historical/mh-gen.txt
new file mode 100644
index 0000000..6c7f755
--- /dev/null
+++ b/docs/historical/mh-gen.txt
@@ -0,0 +1,1452 @@
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+NAME
+ mh-gen - generating the MH system
+
+READ THIS
+ This documentation describes how to configure, generate, and
+ install the UCI version of the RAND _M_H system. Be certain
+ to read this document completely before you begin. You
+ probably will also want to familiarize yourself with the _M_H
+ Administrator's Guide before you install _M_H. A copy can be
+ found in the file doc/ADMIN.doc is the _M_H sources.
+
+DISCLAIMER
+ Although the _M_H system was originally developed by the RAND
+ Corporation, and is now in the public domain, the RAND Cor-
+ poration assumes no responsibility for _M_H or this particular
+ modification of _M_H.
+
+ In addition, the Regents of the University of California
+ issue the following disclaimer in regard to the UCI version
+ of _M_H:
+ "Although each program has been tested by its contribu-
+ tor, no warranty, express or implied, is made by the
+ contributor or the University of California, as to the
+ accuracy and functioning of the program and related
+ program material, nor shall the fact of distribution
+ constitute any such warranty, and no responsibility is
+ assumed by the contributor or the University of Cali-
+ fornia in connection herewith."
+
+ This version of _M_H is in the public domain, and as such,
+ there are no real restrictions on its use. The _M_H source
+ code and documentation have no licensing restrictions what-
+ soever. As a courtesy, the authors ask only that you pro-
+ vide appropriate credit to the RAND Corporation and the
+ University of California for having developed the software.
+
+GETTING HELP
+ _M_H is a software package that is neither supported by the
+ RAND Corporation nor the University of California. However,
+ since we do use the software ourselves and plan to continue
+ using (and improving) _M_H, bug reports and their associated
+ fixes should be reported back to us so that we may include
+ them in future releases. The current computer mailbox for
+ _M_H is address@hidden (in the ARPA Internet), and
+ ...!ucbvax!ucivax!bug-mh (UUCP).
+
+ Presently, there are two Internet discussion groups,
+ address@hidden and address@hidden MH-Workers
+ is for people discussing code changes to _M_H. MH-Users is
+ for general discussion about how to use _M_H. MH-Users is
+ bi-directionally gatewayed into USENET as comp.mail.mh.
+
+
+
+
+[mh.6] Last change: MH.6.8.3 1
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+HOW TO GET MH
+ Since you probably already have _M_H, you may not need to read
+ this unless you suspect you have an old version. There are
+ two ways to get the latest release:
+
+ 1. If you can FTP to the ARPA Internet, use anonymous FTP
+ to ftp.ics.uci.edu [128.195.1.1] and retrieve the file
+ pub/mh/mh-6.8.tar.Z. This is a tar image after being run
+ through the compress program (approximately 1.8MB). There
+ should also be a README file in that directory which tells
+ what the current release of _M_H is, and how to get updates.
+
+ This tar file is also available on louie.udel.edu
+ [128.175.1.3] in portal/mh-6.8.tar.Z. You may also find MH
+ on various other hosts; to make sure you get the latest ver-
+ sion and don't waste your time re-fixing bugs, it's best to
+ get it from either ftp.ics.uci.edu or louie.udel.edu.
+
+ 2. You can send $75 US to the address below. This covers
+ the cost of a 6250 BPI 9-track magtape, handling, and ship-
+ ping. In addition, you'll get a laser-printed hard-copy of
+ the entire MH documentation set. Be sure to include your
+ USPS address with your check. Checks must be drawn on U.S.
+ funds and should be made payable to:
+
+ Regents of the University of California
+
+ The distribution address is:
+
+ Univeristy of California at Irvine
+ Office of Academic Computing
+ 360 Computer Science
+ Irvine, CA 92717 USA
+
+ +1 714 856 5153
+
+ Sadly, if you just want the hard-copies of the documenta-
+ tion, you still have to pay the $75. The tar image has the
+ documentation source (the manual is in roff format, but the
+ rest are in TeX format). Postscript formatted versions of
+ the TeX papers are available, as are crude tty-conversions
+ of those papers.
+
+SYNOPSIS
+ MAKE
+
+DESCRIPTION
+ This is a description of how one can bring up an _M_H system.
+ It is assumed that you have super-user privileges in order
+ to (re-)install _M_H. Super-user privileges are not required
+ to configure or generate _M_H.
+
+
+
+
+[mh.6] Last change: MH.6.8.3 2
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Become the super-user and cd to /usr/src/local/ (or whatever
+ you keep your local sources). The distribution tape con-
+ tains the hierarchy for the mh.6-8/ directory. Bring the
+ sources on-line:
+
+ # cd /usr/src/local
+ % tar xv
+ % cd mh-6.8
+
+CONFIGURATION
+ First, go to the conf/ directory.
+
+ % cd conf/
+
+ This directory contains files that will produce source files
+ tailored for your choice of _M_H configuration. You should
+ edit only the file MH. This file contains configuration
+ directives. These configuration directives are read by the
+ _m_h_c_o_n_f_i_g program to produce customized files.
+
+ For examples of various configurations, look in the direc-
+ tory conf/examples/. The file MH provided in conf/ is a
+ reasonable default. Lines beginning with `#' are comments,
+ and are not otherwise interpreted.
+
+ Here are the _M_H configuration directives available. Be sure
+ to read through this list completely before attempting to
+ decide what directives are appropriate for your system.
+
+ More information on some of these options is available in
+ the the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e. If
you do not have a printed
+ copy, you should configure your system with the default con-
+ figuration file, MH, then generate and print a copy of the
+ guide (as described below).
+
+ Installation paths
+ bin: /usr/local
+ The directory where user-invoked programs go (see
+ manual section 1).
+
+ etc: /usr/local/lib/mh
+ The directory where pgm-invoked programs go (see manual
+ section 8).
+
+ mail: /usr/spool/mail
+ The directory where the maildrops are stored. If this
+ pathname is absolute (i.e., begins with a / ), then the
+ user's maildrop is a file called $USER in this direc-
+ tory. If the pathname is not absolute, then the user's
+ maildrop is in the user's home directory under the
+ given name.
+
+
+
+
+[mh.6] Last change: MH.6.8.3 3
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ mandir: /usr/man
+ The parent directory of the manual entries.
+
+ manuals: standard
+ Where manual entries should be installed, relative to
+ the directory given with "mandir". Either "local" to
+ install manual entries under manl/, or "new" to install
+ manual entries under mann/, or "old" to install manual
+ entries under mano/, or "standard" to install manual
+ entries under man?/, or "bsd44" to install manual
+ entries as man?/_p_a_g_e.0, or "gen" to generate but not
+ install them, or "none" to neither generate nor install
+ them.
+
+ Any of these values may have the suffix "/cat" appended
+ to it. In that case, the manual entries will be for-
+ matted with "nroff -man" and they will be installed in
+ the corresponding "cat?" directories.
+
+ For example, to install manual entries under
+ /usr/man/u_man/man?, use "standard" and /usr/man/u_man
+ for "mandir". To install formatted manual entires
+ under /usr/contrib/man/cat?, use "standard/cat" and
+ /usr/contrib/man for "mandir". To install formatted
+ manual entries using the BSD44 convention, use
+ "bsd44/cat".
+
+ chown: /etc/chown
+ The location of the _c_h_o_w_n(8) on your system. If
_c_h_o_w_n
+ is in your search path, just use the value of "chown".
+ On SYS5 systems, this should probably be "/bin/chown".
+
+ cp: cp
+ The command to copy files when installing, if not "cp".
+ (Some sites use "cp -p".)
+
+ ln: ln
+ The command to link files together in the source tree,
+ if not "ln". If you're using something like lndir to
+ keep your compile tree separate from your source tree,
+ set this to "ln -s" or "cp".
+
+ remove: mv -f
+ How _M_H should make backup copies of existing files when
+ installing new files. To simply remove the old files,
+ use "rm -f".
+
+ Compiler/loader
+ cc: cc
+ The name of your C compiler, if not "cc".
+
+ ccoptions: -O
+
+
+
+[mh.6] Last change: MH.6.8.3 4
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Options given directly to _c_c(1). The most common is
+ "-M" if you're running _M_H on an ALTOS. This defaults
+ to "-O". If you define this and want to keep "-O", be
+ sure to include it explicitly. If you're using the _G_N_U
+ C compiler, it should include `-traditional'. See
+ "options:" for `-D' options.
+
+ curses: -lcurses -ltermlib
+ This should be the loader option required to load the
+ _t_e_r_m_c_a_p(3) and _c_u_r_s_e_s(3) libraries on your
system. On
+ SYS5 systems, it probably should be just "-lcurses".
+ Some sites have reported that both "-lcurses" and
+ "-ltermlib" are necessary.
+
+ ldoptions: -s
+ Options given directly to _l_d(1) (via _c_c) at the begin-
+ ning of the command line. Useful for machines which
+ require arguments to tell _l_d to increase the stack
+ space (e.g. the Gould, which uses "-m 8"). Usually,
+ "-s" is a good choice in any event.
+
+ ldoptlibs:
+ Options given directly to _l_d(1) (via _c_c) at the end of
+ the command line. The two most common are: "-ldbm" if
+ you're running MMDF with the _d_b_m package; and, "-lndir"
+ if you are generating _M_H on a system which does not
+ load the new directory access mechanism by default
+ (e.g., 4.1BSD, SYS5). If you don't have _l_i_b_n_d_i_r on
+ your system, the sources are in miscellany/libndir/.
+
+ lex: lex -nt
+ Alternative version of _l_e_x. Used in zotnet/tws/.
+
+ oldload: off
+ This controls how _M_H will try to process library object
+ files to eliminate local symbols. Support for the
+ ALTOS loader if "on". Support for loaders not handling
+ `-x -r' correctly if "none".
+
+ ranlib: on
+ Support for systems with _r_a_n_l_i_b(1). For SYSTEM 5 sys-
+ tems, this should be "off" which tells _M_H to use
_l_o_r_d_e_r
+ and _t_s_o_r_t instead. Some SYSTEM 5 sites reported that
+ running this isn't always sufficient. If this is the
+ case, then you should edit conf/makefiles/uip to
+ include ../sbr/libmh.a and ../zotnet/libzot.a twice in
+ the LIBES variable.
+
+ Message Transport System
+ mts: sendmail
+ Which message transport system to use. Either "mmdf"
+ to use _M_M_D_F as the transport system, "mmdf2" to use
+
+
+
+[mh.6] Last change: MH.6.8.3 5
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ _M_M_D_F-_I_I as the transport system, "sendmail" to have
+ _S_e_n_d_M_a_i_l as the transport system, "zmailer" to have
+ _Z_M_A_I_L_E_R as the transport system, or, "mh" to have
_M_H as
+ the transport system.
+
+ On UNIX systems supporting TCP/IP networking via sock-
+ ets you can add the suffix "/smtp" to the mts setting.
+ This often yields a superior interface as _M_H will post
+ mail with the local _S_M_T_P server instead of interacting
+ directly with _M_M_D_F or _S_e_n_d_M_a_i_l. Hence, for
TCP/IP UNIX
+ systems, the "/smtp" suffix to either "sendmail" or
+ "mmdf2" is the preferred MTS configuration. The
+ "/smtp" suffix is described in detail in the
+ _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e; be sure
to set "servers:" as
+ described in _m_h-_t_a_i_l_o_r(8) if you use this option.
+
+ mf: off
+ Support for mail filtering on those systems in which
+ the message transport system isn't integrated with _U_U_C_P
+ This option is strictly for an _M_H system using either
+ _M_M_D_F-_I as its transport system or one using
+ "stand-alone delivery".
+
+ UCI BBoards Facility
+ bboards: off
+ If "on", include support for the UCI BBoards facility.
+ BBoards may be enabled with any mts setting. If "off",
+ the BBoard reading program _b_b_c will not be installed.
+ If "nntp", include support for the UCI BBoards facility
+ to read the Network News via the NNTP. If "pop" (form-
+ erly "popbboards: on"), include support for the UCI
+ BBoards facility via the POP3 service; this setting
+ requires "pop: on".
+
+ bbdelivery: off
+ If "off", the BBoards delivery agent and library files
+ will not be installed. If "on", and you set "bboards:"
+ to something besides "off", then the BBoards delivery
+ agent and library files will be installed in the _b_b_h_o_m_e
+ directory (see below). To read remote BBoards, the
+ usual configuration would have _b_b_c talk to a _P_O_P_3 or
+ _N_N_T_P server. However, it may be useful to set this to
+ "off" if you NFS mount the _b_b_h_o_m_e directory from
+ another host and want to use _b_b_c to read those files
+ directly.
+
+ bbhome: /usr/spool/bboards
+ The home directory for the BBoards user.
+
+
+
+
+
+
+
+[mh.6] Last change: MH.6.8.3 6
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Post Office Protocol
+ pop: off
+ Support for POP service. This allows local delivery
+ for non-local users (a major win). See
+ support/pop/pop.rfc for more information on the POP.
+ This option currently works only on UNIX systems with
+ TCP/IP sockets. (It doesn't hurt to enable this option
+ regardless of whether or not you intend to use POP.)
+ See also "bboards: pop" to enable reading bboards with
+ the POP.
+
+ popdir: /usr/etc
+ The directory where the POP daemon (popd) will be
+ installed.
+
+ options:
+ `-D' options to _c_c(1).
+
+ APOP='"/etc/pop.auth"'
+ This option indicates that the POP daemon will sup-
+ port the non-standard APOP command, and specifies the
+ name of APOP authorization database. The APOP com-
+ mand provides a challenge-based authentication system
+ using the MD5 message digest algorithm. This facil-
+ ity is documented in _T_h_e _I_n_t_e_r_n_e_t
_M_e_s_s_a_g_e (ISBN
+ 0-13-092941-7), a book by Marshall T. Rose.
+
+ This option also causes the popauth program to be
+ installed, which allows the administrator to manipu-
+ late the APOP authorization database. For more
+ details, see support/pop/pop-more.txt and the
+ _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.
+
+ DPOP
+ This option indicates that POP subscribers do not
+ have entries in the _p_a_s_s_w_d(5) file, and instead have
+ their own separate database (a win).
+
+ KPOP
+ Support for KERBEROS with POP. This code builds
+ _p_o_p_d, _i_n_c and _m_s_g_c_h_k to support only the
"kpop" pro-
+ tocol. This code is still experimental, but is
+ available for those sites wishing to test it.
+
+ MPOP
+ This option indicates that the POP daemon will sup-
+ port the non-standard XTND SCAN command which pro-
+ vides performance enhancements when using the POP
+ over low-speed connections. This option also causes
+ an interactive POP client program, popi, to be com-
+ piled and installed. A man page for the popi program
+ is also provided.
+
+
+
+[mh.6] Last change: MH.6.8.3 7
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ These extensions are described in _T_h_e
_I_n_t_e_r_n_e_t _M_e_s_-
+ _s_a_g_e, a book by Marshall T. Rose. For more details,
+ see support/pop/pop-more.txt. Note: this option
+ requires "bboards: pop".
+
+ POP2
+ Have the POP daemon understand the older POP2 proto-
+ col as well as the _M_H POP3 protocol - a major win.
+ The POP daemon auto-magically determines which POP
+ protocol your client is using. If you're enabling
+ POP service, there's no reason not to enable this
+ option as well. See also _P_O_P_S_E_R_V_I_C_E.
+
+ POPSERVICE
+ The port name the _M_H POP will use. For historical
+ reasons, this defaults to "pop".
+
+ In 1987, the _M_H POP protocol (POP version 3) was pub-
+ lished as RFC1081 and was assigned its own port
+ number (110), which differs from the original POP
+ (version 1 and 2) port number (109).
+
+ To have _M_H POP use the new assigned port number, set
+ POPSERVICE='"pop3"', and be sure that this service
+ name is listed in your /etc/services file on both POP
+ client and server hosts as "110/tcp". If you enable
+ _P_O_P_2, you can safely leave _P_O_P_S_E_R_V_I_C_E
undefined
+ unless you are using POP3 clients besides _M_H.
+
+ RPOP
+ This option indicates that support for the UNIX vari-
+ ant of POP, RPOP, which uses privileged sockets for
+ authentication be enabled. This peacefully co-exists
+ with the standard POP.
+
+ SHADOW
+ Indicates that the popd POP server can find encrypted
+ passwords in the /etc/shadow file (and not in the
+ /etc/passwd file). It should be used only for some
+ (newer) SYSTEM 5 systems.
+
+ The "APOP" and "MPOP" non-standard POP facilities are
+ documented in _T_h_e _I_n_t_e_r_n_e_t
_M_e_s_s_a_g_e (ISBN 0-13-092941-7),
+ a book by Marshall T. Rose. For more details, see
+ support/pop/pop-more.txt. The "APOP" option peacefully
+ co-exists with the standard POP. The "MPOP" option
+ requires "bboards: pop".
+
+ Shared libraries
+ sharedlib: off
+ If "sun4", makes libmh.a into a SunOS 4.0 (and later)
+ shared library. If you enable this, be sure to also use
+
+
+
+[mh.6] Last change: MH.6.8.3 8
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ "options SUN40". If "sys5", makes libmh.a into a SYS5
+ R4 (and later) shared library. If you enable this, be
+ sure to also use "options SVR4".
+
+ slflags: -pic
+ The compiler flags to produce position independent code.
+
+ slibdir: /usr/local/lib
+ The directory where the _M_H shared library should go.
+
+ Under SunOS (sun4)
+ Since some _M_H programs are setuid, they'll only look for
+ the library in "trusted" locations. Putting the library
+ somewhere besides /usr/lib or /usr/local/lib is not
+ advisable.
+
+ If you must do this, be sure that you add the path given
+ by slibdir to the compiler's library search list (e.g.,
+ "ldoptions: -L/usr/mh/lib") and make sure the path
+ starts with a leading `/'.
+
+ You may need to run _l_d_c_o_n_f_i_g(8) manually whenever a
new
+ shared object is installed on the system. See _l_d(1) for
+ more information about using shared libraries.
+
+ Under Solaris 2.0 (and newer)
+ The above instructions for SunOS apply, except you
+ should set the run-time library search path using `-R'
+ instead of `-L' (e.g., "ldoptions: -R/usr/mh/lib").
+
+ General System Dependencies
+ You should include the following directives which are
+ appropriate for your version of UNIX. If you don't know what
+ an option does, it probably doesn't apply to you.
+
+ mailgroup: off
+ If set, _i_n_c is made set-group-id to this group name.
+ Some SYS5 systems want this to be set to "mail". Set
+ this if your /usr/spool/mail is not world-writeable.
+
+ Note that slocal doesn't know how to deal with this, and
+ will not work under these systems; just making it set-
+ group-id will open a security hole. If you're using
+ "mailgroup", you should remove slocal (and its man page)
+ from your system.
+
+ signal: int
+ The base type (int or void) of the function
+ parameter/return value of _s_i_g_n_a_l(2). The default is
+ int. Set "signal void" on systems which use this type
+ (e.g., SYSTEM 5 V3.0 and later or Sun OS 4.0 and later).
+
+
+
+
+[mh.6] Last change: MH.6.8.3 9
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ sprintf: char *
+ The return value of the _s_p_r_i_n_t_f library routine. This
+ defaults to "char *". Set this to "int" if you have an
+ older version of SYSTEM 5 which has this routine return
+ an "int" type.
+
+ options:
+ `-D' options to _c_c(1).
+
+ ALTOS
+ Use on XENIX/v7 systems. Also, be sure to use
+ "options V7".
+
+ ATTVIBUG
+ This option causes _M_H to return to the "What now?"
+ prompt if your initial editor is vi and it exits with
+ non-zero status. Use on Sun OS 4.1 and other systems
+ where the /usr/ucb/vi editor was changed to exit with
+ its status equal to the number of pseudo-"errors"
+ encountered during the edit. This causes a problem
+ for programs that test the exit status of their editor
+ and abort if the status is non-zero. (This includes
+ _M_H and programs like /usr/etc/vipw).
+
+ AUX
+ Use with AUX systems.
+
+ BIND
+ If you are running with the BIND code on UNIX systems
+ with TCP/IP sockets (e.g. 4.{2,3}BSD), be sure to
+ define this.
+
+ BSD41A
+ Use on 4.1a Berkeley UNIX systems.
+
+ BSD42
+ Use on Berkeley UNIX systems on or after 4.2BSD.
+
+ BSD43
+ Use on 4.3 Berkeley UNIX systems. Also, be sure to
+ use "options BSD42". If _o_p_e_n_l_o_g(3) (see "man 3 sys-
+ log") takes three arguments instead of two, and your
+ _w_r_i_t_e(1) command is set-group-id to group "tty", use
+ this option. If only one of these conditions is true,
+ you lose.
+
+ BSD44
+ Use on Berkeley UNIX systems on or after 4.4BSD.
+ Also, be sure to use "options BSD43" and "options
+ BSD42".
+
+ DBMPWD
+
+
+
+[mh.6] Last change: MH.6.8.3 10
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Use this option if your _g_e_t_p_w_e_n_t(3) routines read a
+ dbm database (such as with Yellow Pages) instead of
+ doing a sequential read of /etc/passwd. Without
+ DBMPWD the entire passwd file is read into memory one
+ entry at a time for alias expansion. This is a per-
+ formance improvement when reading a standard
+ /etc/passwd file, but is _v_e_r_y slow on systems with a
+ dbm database. At one site that runs YP on a large
+ passwd file, it showed a 6:1 performance improvement.
+
+ GCOS_HACK
+ The so-called "gcos" field of the password file is
+ used as a last resort to find the user's full name
+ (see _m_h-_p_r_o_f_i_l_e(5) for details). Enable this
option
+ if your _p_a_s_s_w_d(5) man page notes that the `&' charac-
+ ter in the "gcos" field stands for the login name.
+
+ FCNTL
+ Directs _M_H to use the fcntl() system call for kernel-
+ level locking. If you're using a SYS5 system, you may
+ want this option. (See also `FLOCK' and `LOCKF').
+
+ FLOCK
+ Directs _M_H to use the flock() system call for kernel-
+ level locking. If you're on a BSD42 system, and
+ you're not using NFS to read or write maildrops, you
+ should enable this option. (See also `FCNTL' and
+ `LOCKF').
+
+ HESIOD
+ Support for HESIOD. This code was contributed, and
+ included no documentation.
+
+ LOCKF
+ Directs _M_H to use the lockf() system call for kernel-
+ level locking. If you're using NFS to read or write
+ maildrops, you should enable this option. (See also
+ `FLOCK' and `FCNTL').
+
+ locname
+ Hard-wires the local name for the host _M_H is running
+ on. For example, locname='"PICKLE"'. It's probably
+ better to either let UNIX tell _M_H this information, or
+ to put the information in the host specific mtstailor
+ file.
+
+ MORE
+ Defines the location of the _m_o_r_e(1) program. On
+ ALTOS and DUAL systems, set MORE='"/usr/bin/more"'.
+ The default is "/usr/ucb/more".
+
+ NDIR
+
+
+
+[mh.6] Last change: MH.6.8.3 11
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ For non-Berkeley UNIX systems, this _M_H will try to
+ find the new directory access mechanism by looking in
+ <ndir.h> if this option is given. Otherwise, _M_H will
+ try <dir.h>. If you still can't get this to work on
+ your system, edit h/local.h as appropriate. (See also
+ `SYS5DIR'.)
+
+ NFS
+ Tells _M_H to hack around a problem in the NFS C
+ library. If you get an undefined symbol "ruserpass"
+ when compiling _M_H, you probably need this option. If,
+ however, you include this option and get an undefined
+ symbol "__ruserpass" when compiling, then you should
+ omit this option. (See also `NORUSERPASS'.)
+
+ NOIOCTLH
+ Tells _M_H not to include the file <sys/ioctl.h>. To be
+ used on systems where this file is not present.
+
+ NORUSERPASS
+ Tells _M_H that your system doesn't have the _r_u_s_e_r_-
+ _p_a_s_s(3) routine; _M_H will include its own copy of this
+ routine in its library. (See also `NFS'.)
+
+ NTOHLSWAP
+ Tells _M_H to use the ntohl() macro when processing _m_s_h
+ binary map files. _M_H can use this macro on systems
+ with the include file netinet/in.h, to byte-swap the
+ binary information in these map files. If you're
+ using the same map files on machines of different
+ architectures, enable this option.
+
+ RENAME
+ Include this option if your system has a rename()
+ library call. This is true on BSD42 and newer and
+ some SYS5 systems.
+
+ SENDMAILBUG
+ Causes SMTP reply code 451 (failure) to be considered
+ the same as code 250 (OK). Since this might cause
+ problems, only enable this if you are certain that
+ your SendMail will return this code even when it
+ doesn't mean to indicate a failure.
+
+ SOCKETS
+ Indicates the availability of a socket interface for
+ TCP/IP networking that is compatible with 4.{2,3}BSD
+ UNIX. It is not necessary to define this when BSD42
+ is already defined, but it might be useful for SYSTEM
+ 5 or HPUX systems with TCP/IP sockets.
+
+ SUN40
+
+
+
+[mh.6] Last change: MH.6.8.3 12
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Use on Sun OS 4.0 (and later?) systems. You also will
+ need "options BSD42", "options BSD43", and "signal
+ void".
+
+ If you're using Sun's brain-damaged approach to offer-
+ ing Domain Name Service through NIS, be sure to
+ include "options BIND" and "ldoptions -lresolv" to
+ work around some NIS/DNS bugs.
+
+ SYS5
+ Use on AT&T SYSTEM 5 R3 (and newer?) UNIX systems.
+ See also _m_a_i_l_g_r_o_u_p.
+
+ SYS5DIR
+ Define this if your system uses "struct dirent"
+ instead of "struct direct". This is true of System V
+ Release 3.0 and later. Uses include file <dirent.h>
+ and the routines _m_k_d_i_r, _r_m_d_i_r and
_g_e_t_c_w_d.
+
+ SVR4
+ Use on AT&T SYSTEM 5 R4 (and newer?) UNIX systems. You
+ should also include "options SYS5" and "options
+ SYS5DIR". See also _m_a_i_l_g_r_o_u_p. You will also
need to
+ include "oldload none" if your ld doesn't handle
+ `-x -r' correctly.
+
+ TERMINFO
+ Define TERMINFO if you have it. You get it automati-
+ cally if you're running SYS5, and you don't get it if
+ you're not. (If you're not SYS5, you probably have
+ termcap.)
+
+ TZNAME
+ Use time zone names from the _t_z_n_a_m_e variable, set via
+ _t_z_s_e_t. Only applicable on SYSTEM 5 systems and only
+ effective when you have asked for alpha-timezones (see
+ the ATZ option). See also ZONEINFO.
+
+ UNISTD
+ Include this option if your system has the file
+ <unistd.h>. If not specified, the LOCKF option will
+ include <sys/fcntl.h>.
+
+ V7
+ Use on V7 UNIX systems. Also, be sure to use "options
+ void=int".
+
+ VSPRINTF
+ Include this option if your system has the
_v_s_p_r_i_n_t_f(3)
+ library routine; otherwise, __d_o_p_r_n_t(3) will be used.
+
+ WAITINT
+
+
+
+[mh.6] Last change: MH.6.8.3 13
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ BSD42 based systems call the _w_a_i_t(2) system routine
+ with a pointer to type _u_n_i_o_n _w_a_i_t. Include this
+ option if you included "options BSD42", but your sys-
+ tem calls the _w_a_i_t(2) system routine with a pointer to
+ type _i_n_t (the non-BSD42 default).
+
+ ZONEINFO
+ Specify this if you have a BSD43 based system that
+ keeps time zone information /etc/zoneinfo or
+ /usr/lib/zoneinfo (SunOS), and where the _s_t_r_u_c_t _t_m
+ returned by _l_o_c_a_l_t_i_m_e(3) contains a
_t_m__g_m_t_o_f_f element
+ (see /usr/include/time.h). With this fix the GMT
+ offset specified in outgoing mail will be corrected
+ when the TZ enviornment variable is set to a different
+ time zone. See also TZNAME.
+
+Site Preferences
+ These options change the default behavior of _M_H or enable
+ optional features. Add the options which are appropriate for
+ your configuration or your site preferences.
+
+ editor: prompter
+ The default editor for _M_H.
+
+ options:
+ `-D' options to _c_c(1).
+
+ ATZ
+ Directs _M_H to use alpha-timezones whenever possible.
+ You should not use this option if you are on the Inter-
+ net, since it will make your host non-compliant with
+ RFC-1123 (Requirements for Internet Hosts).
+
+ ATHENA
+ Makes _r_e_p_l `-nocc all' the default instead of
+ `-cc all'. You may want to enable this if you're using
+ _x_m_h.
+
+ BANG
+ Directs _M_H to favor `!' over `@' in addressing.
+
+ BERK
+ Optional for for 4.{2,3}BSD sites running SendMail.
+ Disables nearly all of the RFC822 address and header-
+ parsing routines in favor of recognizing such formats
+ as ASCnet, and so on. If you don't need to disable the
+ parser for this reason, you probably want to use
+ "options DUMB" instead.
+
+ COMPAT
+ If you previously ran a version of _M_H earlier than mh.4
+ use this option. After a short grace period, remove it
+
+
+
+[mh.6] Last change: MH.6.8.3 14
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ and re-{configure,generate,install} everything.
+
+ DUMB
+ Directs _M_H not to try and rewrite addresses to their
+ "official" form.
+
+ FOLDPROT
+ Defines the octal value for default folder-protection.
+ For example, FOLDPROT='"0700"'. The default is "0711".
+
+ ISI
+ When using "repl -ccme", only "cc:" the first address
+ found which belongs to the user; any other
_A_l_t_e_r_n_a_t_e-
+ _M_a_i_l_b_o_x_e_s do not receive "cc:"s.
+
+ LINK
+ Defines the filename for alternate file name for _d_i_s_t
+ and _r_e_p_l. For example, LINK='"\\043"' to use the
+ pound-sign character. The default is "@".
+
+ MHE
+ Enables crude support for Brien Reid's MHE interface.
+ Recommended for use with the GNU Emacs mh-e package.
+
+ MHRC
+ Enables _M_H to recognize the _C_S_h_e_l_l's `~'-construct.
+ This is useful for sites that run with a ~/.mhrc for
+ their users.
+
+ MIME
+ Enables support for multi-media messages, as specified
+ in RFC 1341 -- a major win. This allows you to include
+ things like audio, graphics, and the like, in your mail
+ messages. Several _M_H commands are extended to support
+ these multi-media messages, and the _m_h_n command is pro-
+ vided to encode and decode MIME messages. For more
+ details, see miscellany/multi-media/READ-ME and _m_h_n(1).
+
+ MSGID
+ Enables slocal to detect and surpress duplicate mes-
+ sages received. This code uses the <ndbm.h> library,
+ and requires "options BSD42" since it uses the _f_l_o_c_k(2)
+ system call for locking. (Note that this means its
+ database locking does not work over NFS.) It has only
+ been tested under SUN40.
+
+ MSGPROT
+ Defines the octal value for default folder-protection.
+ For example, MSGPROT='"0600"'. The default is "0644".
+
+ NOMHSEQ
+ Directs _M_H to make private sequences the default.
+
+
+
+[mh.6] Last change: MH.6.8.3 15
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ OVERHEAD
+ Enable _M_H commands to read profile/context from open
+ fd:s without doing an open(); see _m_h-_p_r_o_f_i_l_e(5)
for the
+ details.
+
+ RPATHS
+ Directs _i_n_c to note UNIX "From " lines as Return-Path:
+ info.
+
+ SBACKUP
+ Defines the prefix string for backup file names. For
+ example, SBACKUP='"\\043"'. The default is ",".
+
+ TMA
+ Support for the TTI _t_r_u_s_t_e_d _m_a_i_l
_a_g_e_n_t (TMA). Although
+ the TTI TMA is not in the public domain, the _M_H support
+ for the TTI TMA is in the public domain. You should
+ enable this option only if you are licensed to run the
+ TMA software (otherwise, you don't have the software in
+ your _M_H source tree).
+
+ TTYD
+ Support for TTYD. This is no longer in wide use, and
+ is not recommended.
+
+ UCI
+ First, "_" and "#" are recognized as the prefixes for
+ scratch files. Second, support for the UCI
+ group-leadership mechanism is enabled in _c_o_n_f_l_i_c_t.
+ Third, the first line of the file file $HOME/.signature
+ is used as the _F_u_l_l _N_a_m_e part of your "From:" header.
+ This may conflict with the interpretation of this file
+ by _N_e_w_s. If you're not at UCI, you probably don't want
+ this option.
+
+ UK
+ Directs the _s_c_a_n program to generate UK-style dates by
+ default.
+
+ WHATNOW
+ Enable certain _M_H commands to act differently when
+ $mhdraft set.
+
+ YEARMOD
+ This option makes the _m_h-_f_o_r_m_a_t %(year) function
always
+ return a value less than 100. Enable this option if
+ you have local _m_h-_f_o_r_m_a_t(5) files which cannot handle
+ 4-digit years. You should convert these files to use a
+ 4-character field width, or use the %(modulo 100) func-
+ tion to obtain a 2-digit year value. After a short
+ grace period, remove `YEARMOD' and re-
+ {configure,generate,install} everything.
+
+
+
+[mh.6] Last change: MH.6.8.3 16
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+Testing/debugging
+ debug: off
+ Support for debug mode of _M_H. Don't use this unless you
+ know what you're doing, which isn't likely if you're read-
+ ing this document!
+
+ regtest: off
+ Set this to "on" if you are doing regression testing among
+ different compilations of _M_H, and you do not want the
+ hostname and compile date included in _M_H binaries.
+
+
+
+ Now edit conf/config/mtstailor, depending on your choice of
+ the setting for mts in the _M_H configuration file. for an
+ mts setting of "mh", look at the file conf/tailor/mhmts; for
+ an mts setting of "sendmail", "sendmail/smtp", "mmdf/smtp",
+ or "mmdf2/smtp", look at the file conf/tailor/sendmts; and,
+ for an mts setting of "mmdf", or "mmdf2", look at the file
+ conf/tailor/mmdf.
+
+ Now install the configured files into the source areas. (On
+ SYS5 systems, or other systems where you get complaints
+ about "_index" and "_rindex" being undefined, you should use
+ "make sys5" to compile mhconfig.)
+
+ % make
+ % ./mhconfig MH
+
+ Before proceeding, you should familiarize yourself with the
+ _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e. To generate
an _n_r_o_f_f version, go to
+ the doc/ directory and type:
+
+ % (cd ../doc/; make ADMIN.doc)
+
+
+ If you're already running _M_H at your site, you should also
+ read the _m_h changes document CHANGES. The source is in
+ papers/changes/.
+
+ After reading the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s
_G_u_i_d_e, you may decide to
+ change your MH configuration. If so, cd back to the conf/
+ directory, re-edit the files MH and conf/config/mtstailor,
+ and re-run _m_h_c_o_n_f_i_g.
+
+ You now proceed based on your choice of a transport system
+ (the setting for mts above). The best interface is achieved
+ with "sendmail" followed by "mmdf" or ("mmdf2"), and then
+ "mh" (stand-alone delivery, not recommended).
+
+ SENDMAIL
+ If you have not enabled BBoards or POP then no further
+
+
+
+[mh.6] Last change: MH.6.8.3 17
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ MTS-specific action is required on your part!
+
+ If you have enabled POP, but you want to let _S_e_n_d_M_a_i_l
+ deliver mail POP mail using its standard delivery program
+ /bin/mail, then, again, no further MTS-specific action is
+ required on your part!
+
+ Otherwise, go to the mts/sendmail/ directory.
+
+ % cd ../mts/sendmail/
+
+ This directory contains files whose definitions correspond
+ to the configuration of your _S_e_n_d_M_a_i_l system. If you have
+ enabled BBoards or POP service, then you will need to
+ re-configure _S_e_n_d_M_a_i_l. First, in the "local info" section
+ of your site's _S_e_n_d_M_a_i_l configuration file, choose a free
+ macro/class (B is used in this distribution), and add these
+ lines:
+
+ # BBoards support
+ DBbboards
+ CBbboards
+
+ Second, immediately after the inclusion of the zerobase
+ file, in the "machine dependent part of ruleset zero" sec-
+ tion, add these lines:
+
+ # resolve names for the BBoards system
+ R$+<@$=B> address@hidden:$1 address@hidden
+
+ Be sure to use tabs when separating these fields. Third,
+ add the line
+
+ include(bboardsMH.m4)
+
+ after the line
+
+ include(localm.m4)
+
+ in your site's _S_e_n_d_M_a_i_l configuration file. Finally, you
+ should link the file mts/sendmail/bboardsMH.m4 into your
+ _S_e_n_d_M_a_i_l cf/ directory and re-configure
_S_e_n_d_M_a_i_l.
+
+ If you have enabled POP service, a similar procedure must be
+ used on the POP service host, to re-configure _S_e_n_d_M_a_i_l.
+ First, in the "local info" section of your site's _S_e_n_d_M_a_i_l
+ configuration file, choose a free macro/class (P is used in
+ this distribution), and add these lines:
+
+ # POP support
+ DPpop
+ CPpop
+
+
+
+[mh.6] Last change: MH.6.8.3 18
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Second, immediately after the inclusion of the zerobase
+ file, in the "machine dependent part of ruleset zero" sec-
+ tion, add these lines:
+
+ # resolve names for the POP system
+ R$+<@$=P> address@hidden:$1 address@hidden
+
+ Be sure to use tabs when separating these fields. Third,
+ add the line
+
+ include(popMH.m4)
+
+ after the line
+
+ include(localm.m4)
+
+ in your site's _S_e_n_d_M_a_i_l configuration file. Finally, you
+ should link the file mts/sendmail/popMH.m4 into your _S_e_n_d_-
+ _M_a_i_l cf/ directory and re-configure _S_e_n_d_M_a_i_l.
+
+ MMDF
+ If you want _M_M_D_F to be your transport service, and have NOT
+ specified "mmdf/smtp" (or "mmdf2/smtp") as your mts setting,
+ then go to the mmdf/ directory. (If you're using
+ "mmdf/smtp" or "mmdf2/smtp" as your mts setting, then skip
+ to the next section.)
+
+ % cd ../mts/mmdf/
+
+ This directory contains files whose definitions correspond
+ to the configuration of your _M_M_D_F system.
+
+ If you're running _M_M_D_F-_I, then copy the following files from
+ wherever you keep the _M_M_D_F sources to this directory:
+ mmdf/h/ch.h, mmdf/h/conf.h, utildir/conf_util.h,
+ utildir/ll_log.h, mmdf/h/mmdf.h, utildir/util.h,
+ mmdf/mmdf_lib.a, and utildir/util_lib.a.
+
+ If you're running _M_M_D_F-_I_I, then copy the following files
+ from where you keep the _M_M_D_F sources to this directory:
+ h/ch.h, h/conf.h, h/dm.h, h/ll_log.h, h/mmdf.h, h/util.h,
+ and lib/libmmdf.a
+
+ If you have enabled bboards, then the directories
+ support/bboards/mmdfI and support/bboards/mmdfII contain
+ information you'll need to put a UCI BBoards channel in your
+ _M_M_D_F configuration. Similarly, if you have enabled option
+ "mf" and are running _M_M_D_F-_I, then the zotnet/mf/mmdfI/
+ directory contains information you'll need to put a _U_U_C_P
+ channel in your _M_M_D_F-_I configuration. Finally, the direc-
+ tory support/pop/mmdfII contains information you'll need to
+ put a POP channel in your _M_M_D_F-_I_I configuration.
+
+
+
+[mh.6] Last change: MH.6.8.3 19
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ Note that _M_M_D_F-_I_I is distributed with the BBoards channel,
+ although the version in the _M_H distribution might be more
+ current, the version in the _M_M_D_F-_I_I distribution has been
+ tested with that revision of _M_M_D_F.
+
+ MMDF/SMTP
+ If you are using "mmdf/smtp" as your mts setting, then no
+ further MTS-specific action is required on your part!
+
+ MMDF2/SMTP
+ If you are using "mmdf2/smtp" as your mts setting, then no
+ further MTS-specific action is required on your part!
+
+ STAND-ALONE DELIVERY
+ If, instead, you want _M_H to handle its own mail delivery,
+ then no further MTS-specific action is required on your
+ part!
+
+GENERATION
+ Go to the _M_H top-level directory and generate the system.
+
+ % cd ../; make
+
+ This will cause a complete generation of the _M_H system. If
+ all goes well, proceed with installation. If not, complain,
+ as there "should be no problems" at this step.
+
+INSTALLATION
+ If the directories you chose for the user-programs,
+ support-programs and manuals ("bin", "etc", "popdir", "slib-
+ dir", and "mandir" in the conf/MH file) don't exist, you
+ should create them at this point.
+
+ Next, if you enabled support for the UCI BBoards facility,
+ then create a login called "bboards" with the following
+ characteristics: home directory is /usr/spool/bboards/ with
+ mode 755 (actually, use the value for "bbhome" given in the
+ _M_H configuration file), login shell is /bin/csh (or
+ /bin/sh), and, encrypted password field is "*". The
+ "bboards" login should own the /usr/spool/bboards/ direc-
+ tory. In addition to creating /usr/spool/bboards/, also
+ create /usr/spool/bboards/etc/ and
+ /usr/spool/bboards/archive/. These directories should also
+ be owned by the "bboards" login.
+
+ If you enabled support for POP, then on the POP service
+ host, create a login called "pop" with the following charac-
+ teristics: home directory is /usr/spool/pop/ with mode 755,
+ login shell is /bin/csh, and, encrypted password field is
+ "*". If you don't have /bin/csh on your system (V7), then
+ /bin/sh is just fine. The "pop" login should own the
+ /usr/spool/pop/ directory. You'll also need to add a line
+
+
+
+[mh.6] Last change: MH.6.8.3 20
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ to the /etc/services file and the /etc/rc.local file, see
+ the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for more
details.
+
+ If this is not the first time you have installed _M_H, these
+ files will need particular attention:
+
+ _D_i_r_e_c_t_o_r_y _F_i_l_e_s
+ "etc/" MailAliases, BBoardAliases, mtstailor
+ /usr/spool/bboards/ BBoards, .cshrc, .mh_profile
+ /usr/spool/bboards/etc/ *
+
+ The MailAliases, BBoardAliases, mtstailor and BBoards files
+ will NOT be installed over existing copies; you will need to
+ edit these by hand and merge in any changes from your previ-
+ ous _M_H release. The other files under /usr/spool/bboards/
+ will be overwritten if they exist. You may wish to preserve
+ your old versions of these before installing _M_H.
+
+ As the super-user, and from the mh.6/ directory, install the
+ system.
+
+ # make inst-all
+
+ This will cause the _M_H processes and files to be transferred
+ to the appropriate areas with the appropriate attributes.
+
+TAILORING
+ See the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e for
information on tailoring
+ _M_H for the MTS, BBoards, and POP.
+
+DOCUMENTATION
+ In addition to this document, the
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e, and
+ the _U_s_e_r'_s _M_a_n_u_a_l, there are several documents
referenced by
+ the user's manual which may be useful. The sources for all
+ of these can be found under the papers/ directory.
+
+OTHER THINGS
+ Consult the directory miscellany/ for the sources to a
+ number of things which aren't part of the mainstream _M_H dis-
+ tribution, but which are still quite useful.
+
+FILES
+ Too numerous to mention. Really.
+
+SEE ALSO
+ make(1)
+
+BUGS
+ The _m_h_c_o_n_f_i_g program should be smarter.
+
+ There's no way to print the _A_d_m_i_n_i_s_t_r_a_t_o_r'_s
_G_u_i_d_e until
+ after you have configured the system; it is difficult to
+
+
+
+[mh.6] Last change: MH.6.8.3 21
+
+
+
+
+
+
+MH-GEN(8) MAINTENANCE COMMANDS MH-GEN(8)
+
+
+
+ configure the system without the
_A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e.
+
+ The Makefiles should know when _m_h_c_o_n_f_i_g has been run and
+ force "make clean" behavior.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[mh.6] Last change: MH.6.8.3 22
+
+
+
diff --git a/docs/historical/mh4mm.pdf b/docs/historical/mh4mm.pdf
new file mode 100644
index 0000000..466d319
Binary files /dev/null and b/docs/historical/mh4mm.pdf differ
diff --git a/docs/historical/mh4mm.txt b/docs/historical/mh4mm.txt
new file mode 100644
index 0000000..3aa30f1
--- /dev/null
+++ b/docs/historical/mh4mm.txt
@@ -0,0 +1,1168 @@
+
+
+
+
+ MH for MM Users
+
+
+
+ Mary Hegardt Tim Morgan
+
+
+
+ April 12, 1990
+
+
+
+1 Introduction
+
+
+
+This document is another in a continuing series on use of the MH mail system
+
+at UCI. It is intended for those users accustomed to the mm "user
agent"
+
+(mail program) under Tops-20 and who are already familiar with
network
+
+mail, but who may not be experienced Unix users. For an
introduction
+
+to MH, see "MH For Beginners" by Mary Hegardt and Tim Morgan. For
+
+complete, detailed information on the MH system, see The Rand MH Message
+
+Handling System: User's Manual by Marshall T. Rose and John L. Romine.
+
+Both documents are available for Xeroxing in suite CS408.
+
+
+
+1.1 UNIX Versus Tops-20
+
+
+
+The Unix1 paradigm is that each command, or program, should perform
+
+only one function. An extension of this idea is that the operating
system
+
+implements only those functions which are necessary, but it does so
in a
+
+very general way so that programs may still accomplish their functions. This
+
+philosophy probably evolved because the original versions of Unix ran
on
+
+PDP-11 minicomputers which had only a small memory space for each pro-
+
+cess.
+________________________________________________
+ 1 Unix is a trademark of AT&T Bell Laboratories
+
+
+
+ 1
+
+
+
+
+Consequently, all commands in Unix, with a very few exceptions, are
in
+
+actuality programs. On Tops-20, in contrast, many of the most
frequently
+
+used commands are built into the user's shell, or exec. Both the
Exec and
+
+csh, which is typically the user's command interface on Unix, will
accept
+
+and parse command lines, attempting to invoke a command as a program if
+
+it is not one of the built-in commands. Unix and Tops-20 are surprisingly
+
+similar internally: the use of the shell, separate processes for each command
+
+or program to execute, standard input and output for each program,
and
+
+many other ideas are common to both operating systems. Users should
be
+
+familiar with the capabilities of the shell, which is described in the document
+
+"Introduction to the Csh."
+
+
+
+1.2 The MH User Interface
+
+
+
+The MH mail "user agent" is different from most other mail systems.
mm,
+
+for example, is a monolithic system because one program implements all the
+
+mail-related functions. The disadvantages of monolithic systems are
that
+
+(a) they are large, so they tend to put more burden on the computer system,
+
+and (b) they allow for much less flexibility. In contrast, MH implements each
+
+mail command as a separate program: there is no single program called mh.
+
+This approach facilitates interspersing mail commands with other,
perhaps
+
+unrelated, commands.
+
+
+Another unique feature of MH is that it takes advantage of the
facilities
+
+provided by the operating system. Most mail agents, such as mm,
maintain
+
+a file containing the user's mail in a special, usually undocumented, format.
+
+When a message is deleted, mm must take care of compacting the
mail file.
+
+It must be able to distinguish the separate messages contained in
the file.
+
+mm must also implement a simple text editor to allow the user to enter and
+
+modify a message while it is being composed. These functions are essentially
+
+those provided by the operating system when separate files are stored within
+
+a directory. Therefore, the approach taken by MH is that each
message is
+
+kept in a separate file. This file simply contains the message,
with no other
+
+special formatting characters or requirements. All the messages are
stored
+
+within a normal Unix directory. This approach makes it easy to add
new
+
+MH commands, to edit messages using standard text editors, etc.
+
+
+
+ 2
+
+
+
+
+All your MH related files are stored in a directory within your home directory.
+
+Usually this directory is called Mail or mhbox, although you are free to name
+
+it as you choose. Another file in your home directory called .mh_profile is
+
+equivalent to the MM.INIT file under mm. It contains all the
options which
+
+you prefer for the various MH commands. It also contains the name
of the
+
+MH directory and the name that you want on your outgoing mail in
the
+
+From: field (your "signature ").
+
+
+
+2 Getting Started
+
+
+
+2.1 Incorporating Mail
+
+
+
+Another important difference between mm and MH is the concept of the mail-
+
+drop file. Under Tops-20, the mail transport system delivers new messages
+
+directly into the recipient's MAIL.TXT file, where they may then be processed
+
+with mm. In contrast, the Unix mail transport system, called
MMDF-II,
+
+makes no assumptions about the user agent used by the recipient.
Instead,
+
+it puts all new mail into a special file called the maildrop. This file is in
the
+
+/usr/spool/mail directory. When you log in, if there is new mail
for you
+
+in your maildrop, you will be so notified by the message
+
+
+ You have new ZOTnet mail -- type inc (or mail)
+
+
+When you are ready to process this new mail, you may type the command
+
+
+ % inc
+
+
+("incorporate") which will copy the new mail into separate files, one per mes-
+
+sage, stored in your "inbox" folder. A folder is a subdirectory beneath your
+
+MH directory which is used to store related messages. Additional information
+
+on folders is given in Section 4.5, page 13. The "inbox" is a
distinguished
+
+folder because by default inc will always copy new mail into that
folder,
+
+removing it from the maildrop.
+
+
+If this is the first time you have used inc or any other MH
command, the
+
+mh-install program will inform you that it is creating your Mail
directory.
+
+It will also create the "inbox" folder directory, and .mh_profile.
+
+
+
+ 3
+
+
+
+
+2.2 Message Numbers
+
+
+
+As inc processes each message, it prints a "scan" listing showing the message
+
+number, the date the message was sent, the name of the sender, the subject,
+
+and sometimes the initial part of the text of the message. A
"scan" listing
+
+is thus similar to the output of the HEADERS command in mm. Each message
+
+within a folder is given a number, starting with 1, by which it
can be ref-
+
+erenced. Inc will display the numbers assigned to each new message
in its
+
+"scan" listing.
+
+
+As in mm, there is a "current message" number which usually
identifies the
+
+message most recently manipulated by the user. With most MH commands,
+
+this will be the default message if no messages are explicitly
specified in
+
+a command. Inc makes the first new message the current message,
which
+
+is indicated by a "+" character in the scan listing, just after
the message
+
+number.
+
+
+Many MH commands take a list of messages to process. A message
desig-
+
+nation is either a single message number, two message numbers
separated
+
+by a dash. The dash format indicates a range of messages including
the
+
+endpoints. A message list consists of one or more message designations sep-
+
+arated by spaces. For example, messages 11 through 15 and message 17 may
+
+be indicated by typing
+
+
+ 11-15 17
+
+
+as the argument to some command. There are also several predefined names
+
+for messages or lists of messages which may be used in place of
message
+
+numbers:
+
+
+ cur The current message (the last one that was handled).
Equivalent
+
+ to "." or "CURRENT" in mm.
+
+ next The next message
+
+ prev The previous message
+
+ first The first message in the current folder.
+
+ last The last message in the folder. Equivalent to % or * in mm.
+
+ all All messages (first last ). Same as in mm.
+
+
+It is also possible for you to define your own named sequences of
messages.
+
+
+
+ 4
+
+
+
+
+See the pick command description for more details.
+
+
+
+3 Processing Messages
+
+
+
+This section contains a list of the common mm commands and their equiva-
+
+lents in the in MH mail system. A short textual note describes how the MH
+
+commands differ from their mm counterparts.
+
+
+
+3.1 Listing Messages
+
+
+
+As mentioned in Section 2.2, the scan command may be used to summarize
+
+the messages in a folder, similar to the HEADERS command in mm.
Unlike
+
+most MH commands, however, scan defaults to all the messages in the current
+
+folder unless you specify one or messages on the command line to be scanned.
+
+So simply typing
+
+
+ % scan
+
+
+is equivalent to typing HEADERS ALL (or H A) in mm.
+
+
+
+3.2 Reading Mail
+
+
+
+Unlike the READ command in mm, in MH there is no special
mail-reading
+
+mode (indicated in mm by the R> prompt). The command to read messages
+
+in MH is show. If no message list is specified, then the current
message
+
+is displayed. The message is displayed by your "showproc", as
specified in
+
+the .mh_profile, described in Section 4.2. Normally, your "showproc"
will
+
+be more or mhless. Both of these programs__will__display_ your
messages one
+
+screenful at a time. You press the __space_bar______ __on your
terminal to see the
+ ____________
+next screenful, or the __return____ _key to see the next line.
+
+
+The command
+
+
+ % show next
+
+
+
+ 5
+
+
+
+
+(which will display the first message following the current message
in the
+
+current folder) can be abbreviated as simply
+
+
+ % next
+
+
+Similarly, the command "show prev" can be abbreviated as simply "prev".
+
+
+To get a paper copy of a mail message, take the output from the show com-
+
+mand and pipe it into the imprint command.
+
+
+ % show 5 _ imprint
+
+
+See the manual page for imprint for more information.
+
+
+
+3.3 Deleting Messages
+
+
+
+The equivalent of the DELETE command in mm is rmm in MH (remove mes-
+
+sages). It acts on the current message unless messages are specified
on the
+
+command line. Unlike mm, the deleted messages will no longer show
up in
+
+a "scan" listing. But the messages are not completely removed; they
are
+
+renamed to have a comma prepended to the name of the file containing the
+
+message within its folder directory. Therefore, if you need to recover a mes-
+
+sage, it is possible to go into the directory and rename the
message back.
+
+Be careful in doing this not to overwrite a new message with the same mes-
+
+sage number! It is a Unix convention that files whose names begin
with a
+
+comma will be removed from disk (expunged ) early each morning. Therefore,
+
+your deleted messages will be available for the rest of the day, unless you re-
+
+move another message subsequently which has the same message. Then the
+
+previously deleted message is gone.
+
+
+
+3.4 Replying to Mail
+
+
+
+The equivalent of the REPLY command in mm is repl in MH. Repl may
be
+
+given the number of the message to which you wish to reply, or it will default
+
+to the current message. When replying in mm, you are prompted
asking
+
+if you wish to reply to all the recipients of the message to
which you are
+
+replying, or only to its sender. In MH, normally the reply will be constructed
+
+
+
+ 6
+
+
+
+
+to be sent to all the recipients. You may select which recipients receive
copies
+
+of your reply by using the -query option on repl, or by putting
this option
+
+in your .mh_profile, as described in Section 4.2. If you wish a
reply to go
+
+to everyone but yourself, you can use repl -nocc me.
+
+
+
+3.5 Sending Mail
+
+
+
+The equivalent of the SEND mm command is comp ("compose") in MH. These
+
+two commands are fairly similar, except that the recipient of the
message
+
+cannot be specified on the comp command line. The comp program invokes
+
+a simple editor called prompter which will prompt you for the To:, Cc:, and
+
+Subject: fields of the message. Then a line of dashes is typed,
and you
+
+may enter the__body__of your message (its text,__in__mm_ terms). When
you are
+
+finished, type __ctrl__-__D (equivalent to typing __ESC_______or control-Z in
mm). Then
+
+you'll receive the prompt
+
+
+ What now?
+
+
+which is similar to mm's S> prompt. You may receive a
list__of__the_ options
+
+that you have at this point by typing "?" followed by
__return____._ Here is a
+
+short list of the options and their meanings. Notice that, unlike
mm, there
+
+are very few commands to modify the message (such as the TEXT, TO, CC, etc.,
+
+commands which may be typed at the S> prompt in mm). In place of these
+
+commands, you use the edit command to invoke your favorite text
editor
+
+on the message, and you use it to make the equivalent changes. You also use
+
+your editor to include other files into the body of the message,
rather than
+
+using control-B, as in mm. One additional use of the edit command
is for
+
+spelling checking. In mm, you may use the command SPELL for this purpose.
+
+In MH, you type "edit spell"2 instead. This will cause the spelling checker
+
+to be run, giving you a list of the possibly misspelled words in your message.
+
+
+
+ edit editor Edit the message using the specified
editor. When you
+
+ exit, you will be back at What now?.
+________________________________________________
+ 2 Actually, any program named after the "edit" command will be invoked
with what-
+
+ever arguments you have given and a path to the file containing
the message you are
+editing.
+
+
+
+ 7
+
+
+
+
+ list Shows the message you just typed
+
+
+ whom -check Verifies that the addresses you have used are
valid as far
+
+ as our system can tell
+
+
+ send Sends the message to the recipients
+
+
+ push Sends the message in the background
+
+
+ quit Quits without sending the message. Saves
the text of
+
+ the message as a "draft". Type comp -use
to get back
+
+ to that draft later.
+
+
+ quit -delete Quit, throwing away the draft
+
+
+
+3.6 Forwarding Mail
+
+
+
+The forw command is used in MH to forward messages. It will take
a list
+
+of messages on the command line to be forwarded, or it will
default to the
+
+current message if none are specified. It will prompt you like
comp does
+
+for the To:, Cc:, and Subject: fields. Note that, unlike mm's
FORWARD
+
+command, forw will not construct a subject line automatically. Also as with
+
+comp, you will have the opportunity to add additional text to the message(s)
+
+which you are forwarding, ended with a control-D.
+
+
+
+3.7 Resending Mail
+
+
+
+The equivalent of the RESEND command in mm is the dist
("distribute")
+
+command in MH. Dist works very much like the forw command, except
+
+that the prompts will be Resend-To:, Resend-Cc:, etc. After filling
in the
+
+headers, a line of dashes is typed giving the impression that
additional text
+
+can be entered. Nothing could be further from the truth; if you add any text
+
+at this point the dist will fail. Your only opportunity to add
text is in the
+
+Resend-Note: field.
+
+
+
+ 8
+
+
+
+
+4 Advanced Topics
+
+
+
+4.1 Selecting Messages
+
+
+
+In mm, you may use several reserved command words to select messages
+
+in place of an explicit list of message numbers. For example, you
can
+
+type "DELETE FROM SMITH" to remove all the messages from a user
named
+
+"Smith". Rather than building such a capability into each MH program
+
+which can process message lists, a special program called pick is
used in-
+
+stead. Just as there are predefined sequences of messages, such as
"all",
+
+"cur", etc., you may use pick to define your own sequences. Pick is capable
+
+of selecting messages from a folder based on the To:, From:, Subject:, Cc:,
+
+or Date: fields, or by searching the body of the message. The
patterns to
+
+be searched for may include full regular expressions (see the "man" page for
+
+ed(1) for more information) or simple strings.
+
+
+Pick may be used in one of two ways. First, it may output the
sequence of
+
+message numbers which match the search parameters. Using the backquot-
+
+ing mechanism of the shell, these message numbers may then become
the
+
+arguments to other MH programs. The second way to use pick is to have it
+
+define a new sequence name which will be the messages which were selected.
+
+Only this second method of using pick will be described here; see
pick(l) if
+
+you wish to use the first method.
+
+
+In your .mh_profile, add the line
+
+
+ pick: -seq sel
+
+
+Then each time you use the pick command, it will define the
resulting se-
+
+quence of messages to be called "sel". Then to "pick" all the messages in the
+
+current folder which are from "Smith", just type
+
+
+ % pick -from smith
+
+
+To see a summary of those messages, type
+
+
+ % scan sel
+
+
+Then to the remove the messages, type the command
+
+
+
+ 9
+
+
+
+
+ % rmm sel
+
+
+You can pick messages according to any of the headers (-to -from
-subj
+
+-cc or -date) or just search all the messages for a given word (-search).
+
+
+
+4.2 Customizing Your Mail Environment
+
+
+
+In mm, you use the PROFILE command to tailor your mail environment.
+
+This command writes a file called MM.INIT in your home directory
which
+
+is then read by subsequent executions of mm. In the MH system,
the file
+
+.mh_profile serves the same purpose. It is edited with any normal
text
+
+editor, rather than using a special-purpose command to modify it.
The
+
+format of the file is line oriented, one line per MH program or MH option to
+
+be set. The only required line in the profile is the name of the
primary MH
+
+mail directory, which is by default Mail. This information is specified by the
+
+line
+
+
+ Path: Mail
+
+
+The textual name you would like to have on your outgoing mail is
specified
+
+by the Signature: line. For example,
+
+
+ Signature: Mary Hegardt
+
+
+The BBoards which you like to read should also be listed in the .mh_profile
+
+(see Section 4.6, page 14, for additional information). For example,
if you
+
+read the "system" BBoard (where all important announcements are posted),
+
+as well as "whimsey" and "imagen-users" BBoards, your .mh_profile should
+
+contain the line
+
+
+ bboards: system whimsey imagen-users
+
+
+Other options may be specified on a per-program basis. The format for these
+
+lines is the same. First, the program name is given followed by a colon. Then
+
+any flags which are to be the default options for that program are given. Here
+
+is a short list of the most common options which you may want to set in your
+
+.mh_profile:
+
+
+ showproc: mhless
+
+
+
+ 10
+
+
+
+
+The showproc is the program used to show messages to you. By
default, it
+
+is the more command. Mhless is the same as more except that it omits the
+
+headers of the messages which you indicate that you wish not to see. Type
+
+
+ % man mhless
+
+
+for more information about this program.
+
+
+ msh: -scan
+
+
+Selecting this option causes an automatic scan of new messages on BBoards to
+
+be made when reading BBoards with bbc, similar to the scan listing produced
+
+by inc.
+
+
+ repl: -query
+
+
+causes repl to ask for each address in the message being replied to if it
should
+
+be included in the To: or Cc: fields of the reply being composed.
+
+
+ pick: -seq sel
+
+
+This line will cause messages "picked" by the pick command to be
put into
+
+a sequence named "sel". This sequence name may then be used just
as the
+
+built-in sequences ("last", "first", etc.).
+
+
+
+4.3 Aliases
+
+
+
+Using MH, you may specify your own private mail aliases. This feature allows
+
+you to store lists of addresses or long internet addresses of people with whom
+
+you frequently correspond in one file, and then to address them
using short
+
+mnemonic names. Typically, you will call your alias file "aliases"; it must
+
+be stored in your MH directory. The format of this file is simple.
The alias
+
+is given, followed by a colon, followed by one or more legal mail
addresses
+
+separated by commas. For example, you might for some reason have an alias
+
+for all the users named "Rose" in the ICS department:
+
+
+ roses: prose, srose, mrose, drose
+
+
+In addition to your "aliases" file, you will need to modify your .mh_profile
+
+in order to use aliases. You should add the flag "-alias aliases"
to the
+
+
+
+ 11
+
+
+
+
+entries for the commands ali, whom, send, and push, creating entries
for
+
+these programs if they aren't already in your .mh_profile. Now,
messages
+
+addressed to "roses" will be distributed to all the people listed in the alias.
+
+
+The ali command is used to show you what an alias expands to. You
just
+
+type
+
+
+ % ali alias
+
+
+and ali will respond with the expansion of the alias. Ali searches the
system
+
+aliases file in addition to your private ones.
+
+
+
+4.4 Blind Lists
+
+
+
+There are two different types of so-called "blind addressing" of
messages.
+
+Users of mm may already be familiar with the "Blind Carbon Copy",
or
+
+BCC: field. It allows you to add recipients to your message just
like those
+
+who are CC'd, but the normal recipients will not see that the BCC recipients
+
+were copied on the message, their replies will not go to the blind recipients,
+
+and the blind recipients cannot (easily) reply to the message.
+
+
+The second type of blind mailing is actually called a "group
address list",
+
+although it is commonly referred to as a "blind list". The format of this type
+
+of address is
+
+
+ phrase : address__list ;
+
+
+where the "phrase " is any English phrase of one or more words,
and the
+
+address__list consists of one or more addresses separated by commas.
The
+
+recipients of a message addressed in this fashion will see simply
+
+
+ phrase : ;
+
+
+so when they reply to the message, their reply will come only to
the sender
+
+(or the Reply-To: field, if one was specified), rather than going
to all the
+
+recipients of the original list. For example, to use a group address list for
the
+
+"roses" alias you would type:
+
+
+ To: People Named Rose: roses;
+
+
+
+ 12
+
+
+
+
+This type of group address is very useful for making up lists of related
people,
+
+such as all the people working on a particular research project.
+
+
+
+4.5 Folders
+
+
+
+As mentioned previously, folders are directories within your MH
directory
+
+used to store related messages. There is no equivalent of the
folder concept
+
+in the mm system. Usually, you will use only the folder "inbox", so you won't
+
+have to worry about folders. However, if you process a large volume of mail,
+
+then folders become invaluable in managing the messages which you wish to
+
+keep for future reference.
+
+
+Just as there is a "current message," MH maintains a "current folder," which
+
+will normally be "inbox". You can change folders either by
specifying the
+
+folder on the command line of MH programs which take a list of messages as
+
+an argument, or by using the folder command:
+
+
+ % folder +folder__name
+
+
+In general, the folder name is indicated by a "+" sign followed
immediately
+
+by the folder name, all preceeding any list of messages. For
example, you
+
+may read the most recent message in a folder called "job__offers"
using the
+
+command
+
+
+ % show +job__offers last
+
+
+This command will have the side-effect of setting the current folder
to be
+
+"job__offers". You may move messages from the current folder into
the
+
+"job__offers" folder using the command
+
+
+ % refile +job__offers messages
+
+
+where, as usual, the messages list will default to the current message in the
+
+current folder if none are specified. Note that, in contrast with
the show
+
+command and most other MH commands, the messages are not considered
+
+to be in the folder "job__offers". You may obtain a summary of all your
folders
+
+by typing the command
+
+
+ % folders
+
+
+
+ 13
+
+
+
+
+When you remove messages from a folder using the rmm command, the
+
+deleted messages will show up as a "hole" in the message numbering.
The
+
+command
+
+
+ % folder -pack
+
+
+will cause all the messages within one folder to be renumbered starting with 1.
+
+Similarly, the command
+
+
+ % folders -pack
+
+
+will do the same thing for all your folders.
+
+
+To remove an empty folder, use the command
+
+
+ % rmf +folder
+
+
+
+4.6 Reading BBoards
+
+
+
+Two special-purpose programs are utilized in reading BBoards. The
first is
+
+bbc, which is used to check a list of BBoards for new messages.
The list of
+
+messages may be given on the command line, or if not, it will be taken from
+
+the BBoards: list in your .mh_profile. You may obtain a list of
all the
+
+available BBoards by typing the command
+
+
+ % bbc -topics
+
+
+For each BBoard with unseen messages, bbc will invoke the MH shell,
msh,
+
+whose prompt is
+
+
+ (msh)
+
+
+The msh program allows you to read BBoard mail as if it were normal mes-
+
+sages in one of your folders. Almost all the MH commands will
work just
+
+as the normally do. Typing the command "quit" to msh causes it to
stop
+
+reading the current BBoard and go on to the next one containing
unseen
+
+messages, or to exit if there are no more such BBoards. Typing
control-D
+
+causes msh to exit unconditionally. The command mark followed by a
mes-
+
+sage number causes msh to act as if you have seen that message
and all
+
+previous ones.
+
+
+
+ 14
+
+
+
+
+4.7 Checking for Mail
+
+
+
+Under Unix, there are about a dozen different ways to check for
new mail.
+
+The easiest way to do it is to set the csh variable named "mail"
to tell csh
+
+to check for new mail for you periodically. To do this, add the line
+
+
+ set mail=(60 /usr/spool/mail/$USER)
+
+
+to your .login file in your home directory. This command says to
check
+
+for mail if csh is about to prompt you with a % sign, and if it
has been at
+
+least 60 seconds since it last checked for mail. The advantage of this method
+
+of mail notification, besides simplicity, is that you will never be
interrupted
+
+by a mail notification. You will only be notified of new mail when
you are
+
+between commands, when the shell is about to prompt you.
+
+
+If you desire asynchronous mail notification, which will print to your terminal
+
+regardless of what you are currently doing, you may make use of a "Receive
+
+Mail Hook" called "rcvtty". To do this, create a file in your home directory
+
+called ".maildelivery". In this file, put the line
+
+
+ * - pipe R /usr/uci/lib/mh/rcvtty
+
+
+Then each time new mail arrives, you will receive a one-line "scan"
listing
+
+of the mail if your terminal is world-writable. For more
information on
+
+"maildelivery" files, type:
+
+
+ % man 5 maildelivery
+
+
+
+4.8 Saving Drafts
+
+
+
+Normally when you use comp, it creates the message being composed
in a
+
+file called "draft" in your MH directory. If you use the "quit"
option at
+
+the "What now?" prompt, this file will remain there. You may later use the
+
+command
+
+
+ % comp -use
+
+
+to resume composing the message.
+
+
+
+ 15
+
+
+
+
+If you begin composing a new message and there is already a "draft"
file,_you___
+
+will be asked for the disposition of this file. Typing ?
__return____ _will give you
+
+a list of the options at this point. Normally you will either replace (delete)
+
+the old draft and begin a new one or use the old one.
+
+
+The -file switch to comp may be used to specify the name of a draft other
+
+than "draft". For example, one might type
+
+
+ % comp -file mary
+
+
+to begin composing a message maintained in the draft file "mary". Typing
+
+
+ % comp -file mary -use
+
+
+would cause comp to resume composing this same draft after a "quit" com-
+
+mand to the "What now?" prompt.
+
+
+Very advanced users of MH maintain multiple draft files in a draft
folder.
+
+This is a normal folder which holds all your drafts, rather than
having just
+
+one draft in your MH directory named "draft". If you feel that you need to
+
+use draft folders, you should consult the MH User's Manual for
additional
+
+information.
+
+
+
+ 16
diff --git a/docs/historical/mh6.pdf b/docs/historical/mh6.pdf
new file mode 100644
index 0000000..482ccc5
Binary files /dev/null and b/docs/historical/mh6.pdf differ
diff --git a/docs/historical/mh6.txt b/docs/historical/mh6.txt
new file mode 100644
index 0000000..46c0ca0
--- /dev/null
+++ b/docs/historical/mh6.txt
@@ -0,0 +1,1030 @@
+
+
+
+
+ Changes to
+
+
+ The Rand MH Message Handling System:
+
+
+ MH #6.5 for 4.3BSD UNIX
+
+
+
+ Marshall T. Rose
+
+ Northrop Research and Technology Center
+
+ One Research Park
+
+ Palos Verdes Peninsula, CA 90274
+
+
+
+ April 12, 1990
+
+
+
+ Abstract
+
+ This document describes the user-visible change to the
UCI ver-
+ sion of the Rand MH system that were made from mh.5 to MH
#6.5.
+ It is based on the mh.6 changes document, but has been
updated to
+ accurately reflect the MH distributed with 4.3bsd UNIX1 . This
docu-
+ ment does not describe bug-fixes, per se, or internal
changes, unless
+ these activities resulted in a visible change for the MH user.
+ This document is meant to supplement, not supersede, the
stan-
+ dard MH User's manual[MRose85 ].
+ Comments concerning this documentation should be addressed to
+ the Internet mailbox address@hidden
+
+
+
+________________________________________________
+ T0his document (version #2.10) was LaTEX set April 12, 1990 with lplain
v2.09-10/29/85.
+ 1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ 1
+
+
+
+
+Acknowledgements
+
+
+The MH system described herein is based on the original Rand MH system.
+
+It has been extensively developed (perhaps too much so) by Marshall T. Rose
+
+and John L. Romine at the University of California, Irvine. Einar
A. Stef-
+
+ferud, Jerry N. Sweet, and Terry P. Domae provided numerous
suggestions
+
+to improve the UCI version of MH . Of course, a large number of people have
+
+helped MH along. The list of "MH immortals" is too long to list here.
How-
+
+ever, Van Jacobson deserves a special acknowledgement for his tireless work
+
+in improving the performance of MH . Some programs have been speeded-up
+
+by a factor of 10 or 20. All of users of MH , everywhere, owe a special
thanks
+
+to Van.
+
+
+
+Disclaimer
+
+
+The Regents of the University of California wish to make it known that:
+
+
+ Although each program has been tested by its contributor, no
+
+ warranty, express or implied, is made by the contributor or
the
+
+ University of California, as to the accuracy and functioning
of
+
+ the program and related program material, nor shall the fact
of
+
+ distribution constitute any such warranty, and no
responsibility
+
+ is assumed by the contributor or the University of
California in
+
+ connection herewith.
+
+
+
+ 2
+
+
+
+
+Conventions
+
+
+In this document, certainaL TE X -formatting conventions are adhered to:
+
+
+ 1. The names of UNIX commands, such as comp , are presented
in text
+
+ italics.
+
+
+ 2. Arguments to programs, such as `msgs', are presented in
typewriter
+
+ style and delimited by single-quotes.
+
+
+ 3. UNIX pathnames and envariables, such as
+
+
+ /usr/uci/ and
$SIGNATURE ;
+
+
+ are presented in slanted roman.
+
+
+ 4. Text presenting an example, such as
+
+
+
+ comp -editor zz
+
+
+
+ is presented in typewriter style.
+
+
+
+ 3
+
+
+
+
+General Changes
+
+
+Unlike the changes between mh.4 and mh.5 , a large number of
user-visible
+
+changes have been made in mh.6 . These changes have been in the
form of
+
+bug fixes and several generalizations. The majority of these will
not affect
+
+novice users. In addition, mh.6 is a great deal faster than mh.5 :
all programs
+
+have been speeded-up significantly, thanks to work done by Van Jacobson as
+
+part of the process of including mh.6 in the 4.3bsd UNIX distribution.
+
+ This document describes all user-visible changes to mh.5 from it's
initial
+
+release to the intermediate release of MH #6.5.
+
+
+
+System-5 Support
+
+
+In addition to support for bsd UNIX, V7 UNIX and Xenix2 variants of UNIX,
+
+MH finally has support for the AT&T variant of UNIX, System 5. Hopefully
+
+this will greatly expand the number of system which can run MH .
Ironically,
+
+it appears that five ports of earlier versions of MH (including
mh.5 ) were
+
+done, but news of the work was not widespread.3
+
+
+
+Documentation
+
+
+Several new documents have been included in the mh.6 distribution:
The
+
+paper MH.5: How to process 200 messages a day and still get some real work
+
+done was presented at the 1985 Summer Usenix Conference and
Exhibition
+
+in Portland, Orgeon. Another paper, MH: A Multifarious User Agent,
has
+
+been accepted for publication by Computer Networks. Both describe MH , the
+
+former from a more technical and somewhat humorous perspective, the latter
+
+from a more serious and research-oriented perspective. In addition, a
third
+
+paper has been included, Design of the TTI Prototype Trusted Mail
Agent,
+
+which describes a so-called "trusted" mail agent built on top of MH
. This
+
+paper was presented at the Second International Symposium on Computer
+
+Message Systems in Washington, D.C. A fourth paper, MZnet: Mail Service
+
+for Personal Micro-Computer Systems, is also included. This paper,
which
+________________________________________________
+ 2 Xenix is a trademark of Microsoft Corporation.
+ 3 In fact, three groups in one large organization ported MH
independently, each without
+
+knowledge of the others' work.
+
+
+
+ 4
+
+
+
+
+was presented at the First International Symposium on Computer Message
+
+Systems in Nottingham, U.K., describes a CP/M4 -based version of MH .
+
+ In addition, the MH tutorial, The Rand MH Message Handling
System:
+
+Tutorial, and, The Rand MH Message Handling System: The UCI BBoards
+
+Facility, have both been updated by Jerry N. Sweet.
+
+ For MH administrators (PostMasters and the like), there's an
entirely
+
+new document, The Rand MH Message Handling System: Administrator's
+
+Guide. It explains most of the "ins and outs" of maintaining an MH system.
+
+ Finally, all of the manual entries and the MH manual have had a
thorough
+
+working over. The documentation is expanded, more accurate, and more
+
+detailed.
+
+
+
+Help Listings
+
+
+When any MH command is invoked with the `-help' switch, in
addition to
+
+listing the syntax of the command and version information, the MH
config-
+
+uration options will be listed. MH has so many configuration
options, that
+
+when debugging problems, this information is invaluable.
+
+
+
+The MH Profile
+
+
+There are two new profile entries worth noting: MH-Sequences tells MH the
+
+name of the file to record public sequences in. Users of vm , a
proprietary,
+
+visual front-end to MH , make use of this to disable the public
sequences
+
+feature of MH .
+
+ The profile entry Unseen-Sequence names those sequences which should
+
+be defined as those messages recently incorporated by inc . The show
program
+
+knows to remove messages from this sequence once it thinks they have been
+
+seen. If this profile entry is not present, or is empty, then no
sequences are
+
+defined. Otherwise, for each name given, the sequence is first zero'd and then
+
+each message incorporated is added to the sequence. As such, this
profile
+
+entry is rather analogous to the Previous-Sequence entry in the user's MH
+
+profile.
+
+ In addition, the Alternate-Mailboxes entry in the profile has
been ex-
+
+panded to support simple wild-carding. Also, the default for this profile
entry
+________________________________________________
+ 4 CP/M is a trademark of Digital Research Corporation.
+
+
+
+ 5
+
+
+
+
+is now the user's mail-id at any host. This change was made since
MH can
+
+no longer reliably figure out what the user's real outgoing address looks like.
+
+ Finally, when the install-mh program is automatically invoked by
MH , it
+
+won't prompt the user for information. Instead, it notes that it's setting up
+
+the default environment. In addition, the MH administrator may
set-up a
+
+file called mh.profile in the MH library area which is consulted by
install-mh
+
+when initializing the user's .mh__profile .
+
+
+
+The MH Context
+
+
+The folder , scan , and show programs have been modified to update the
user's
+
+MH context prior to writing to the user's terminal. This allows the MH
user
+
+interrupt output to the terminal and still have the expected context. This is
+
+especially useful to interrupt long scan listings. This change also
introduces
+
+a subtle bug between show and messages denoted by the Unseen-Sequence.
+
+See show (1) for the details.
+
+
+
+Addresses and 822 support
+
+
+MH now fully supports the RFC-822 routing syntax for addresses (it used to
+
+recognize the syntax, but ignore the information present). In addition, there
+
+are three major modes for support of non-822 addressing in MH :
+
+
+ - BERK
+
+ This is useful on sites running SendMail . It doesn't
support full 822-
+
+ style addressing, in favor of recognizing such formats as
ACSnet, and
+
+ so on. For sites that can't run in an 822-compliant environment,
this is
+
+ the option to use (at the price of sacrificing some of the power of
822-
+
+ style addressing). This also drastically reduces the address
formatting
+
+ facilities described below.
+
+
+ - DUMB
+
+ Although not as liberal as BERK, the DUMB option is useful on sites
+
+ in which the message transport system conforms to the 822
standard,
+
+ but wants to do all the defaulting itself.
+
+
+ - BANG
+
+ From out in left field, the BANG option favors UUCP -style
addressing
+
+
+
+ 6
+
+
+
+
+ over 822-style addressing. Hopefully when all the UUCP
sites around
+
+ get around to adopting domain-style addresses, this option
won't be
+
+ needed.
+
+
+ The ap program (mentioned momentarily) and the ali program both sup-
+
+port a `-normalize' switch indicate if addresses should be resolved
to their
+
+"official" hostnames.
+
+
+
+New Programs
+
+
+There are five new programs available: The ap program is the MH
stand-
+
+alone address parser. It's useful for printing address in various formats (and
+
+for debugging address strings). The dp program is similar, but
works on
+
+dates instead of addresses.
+
+ The msgchk program checks for new mail, possibly using the Post
Office
+
+Protocol, POP, described below.
+
+ A new receive mail hook, the rcvstore program, which was
written by
+
+Julian L. Onions is available.
+
+ Finally, a visual front-end to msh called vmh has been
included. (This
+
+program is discussed in greater detail later on.)
+
+
+
+Message Numbering
+
+
+MH now no longer restricts the number of messages which may
reside in a
+
+folder (beyond that of system memory constraints). This means that message
+
+numbers larger than 2000 are permissible. Hopefully this will make life easier
+
+for people reading the network news using MH .
+
+
+
+The WhatNow Shell
+
+
+In mh.6 , there is now the concept of a unified What now?
processor that
+
+the four composition programs, comp , dist , forw , and repl
all invoke. This
+
+permits a greater flexibility in building mail applications with MH
. As a
+
+result, there's a new program, whatnow , which acts as the default What
now?
+
+program. Consult the whatnow (1) manual entry for all the details. The
only
+
+important user-visible change is the headers option went away, which wasn't
+
+used that much anyway.
+
+
+
+ 7
+
+
+
+
+ The only other thing worth noting is that unless MH has
been compiled
+
+with the UCI option, the user's $HOME/.signature file is
not consulted for
+
+the user's personal name.
+
+
+
+Format Strings
+
+
+A general format string facility has been added to allow MH
users to tailor
+
+the output of certain commands.
+
+ The inc , scan , ap , and dp programs all consult a file
containing format
+
+strings. Format strings, which look a lot like printf (3) strings, give
these MH
+
+commands precise instructions on how to format their output.
+
+ As a result, the inc and scan programs no longer have the
`-size', `-
+
+nosize', `-time', `-notime', `-numdate', and `-nonumdate' switches.
These
+
+switches have been replaced with the `-form formatfile' switch and the
+
+`-format string' switch. The former directs the program to consult
the
+
+named file for the format strings. The latter directs the program to use the
+
+named string as the format. To get the behavior of the old `-time'
option,
+
+use the `-form scan.time' option. Similarly, to get the effect of `-size', use
+
+`-form scan.size'.
+
+ A fun form to use is `-form scan.timely' with scan . Try it sometime.
+
+ The repl command uses a file containing format files to indicate how
the
+
+reply draft should be constructed. Note that reply templates prior
to mh.6
+
+are incompatible with mh.5 .5 Don't worry though, it's quite easy to
convert
+
+the templates by hand. (Those clever enough to have written a reply template
+
+to begin with won't have any problem.)
+
+ Similarly, when the forw program is constructing a digest, it
uses a file
+
+containing format strings to indicate how to build the encapsulating draft.
+
+ Finally, you can use these facilities in mhl as well.
+
+
+
+News
+
+
+The depreciated MH news system (from mh.1 ) is now de-supported. Use
the
+
+"hoopy" BBoards facility instead.
+________________________________________________
+ 5 In fact, reply templates between mh.6 and MH #6.5 are imcompatible.
+
+
+
+ 8
+
+
+
+
+BBoards
+
+
+MH maintainers take note: the default home directory for the bboards login
+
+has changed from /usr/bboards/ to /usr/spool/bboards/
. Use the bbhome
+
+directive in your MH configuration file to set it back to the
old value if you
+
+wish.
+
+ In addition, the aliases field for a BBoard in the BBoards
file is now
+
+deemed useful only for addressing, not for user input to bbc .
This means
+
+when giving the name of a BBoard to bbc , only the official name
should be
+
+used.
+
+ A final note for mailsystem maintainers: the MMDF-II
BBoards chan-
+
+nel and the SendMail BBoards mailer have been modified to use
the stan-
+
+dard message encapsulation format when returning failed messages to the list
+
+maintainer. This means that the failure notices that the maintainer receives
+
+can simply be burst .
+
+
+
+New Switches in bbc
+
+
+The bbc program permits you to specify the mshproc to use on the command
+
+line by using the `-mshproc program' option. There's also a `-rcfile file'
+
+option which does "the obvious thing". In addition, options which
aren't
+
+understood by bbc are passed along to the mshproc.
+
+ In addition, the following commands pass any unrecognized
switches on
+
+to the program that they invoke: bbc , next , show , prev , and vmh
.
+
+
+
+Distributed BBoards
+
+
+If both BBoards and POP (see the next section) are enabled, then distributed
+
+BBoards can be supported on top of the POP service. This allows
the MH
+
+user to read BBoards on a server machine instead of the local host
(which
+
+saves a lot of wasted disk space when the same BBoards are
replicated sev-
+
+eral times at a site with several hosts). See the Administrator's
Guide for
+
+information on how this can be made completely transparent to the MH user.
+
+ If you have several machines at your site running 4.2bsd UNIX and con-
+
+nected by an Ethernet6 (or other high-speed LAN), you want this software.
+________________________________________________
+ 6 Ethernet is a trademark of the Xerox Corporation.
+
+
+
+ 9
+
+
+
+
+Visual Front-End to msh
+
+
+A simple window management protocol has been implemented for MH
pro-
+
+grams that might wish to act as a back-end to a sophisticated
visual front-
+
+end.
+
+ The first implementation of a server side (front-end) program
is vmh ,
+
+which uses curses (3) to maintain a split-screen interface. Perhaps look
for a
+
+mhtool program for the SUN next!
+
+ The msh program has been modified to speak the client side
(back-end)
+
+of this protocol, if so directed. At present, msh is the only
program in the
+
+MH distribution which implements the client side of the window management
+
+protocol.
+
+
+
+Updates in msh
+
+
+Prior to quitting, the msh command now asks if the packf 'd file you've
been
+
+perusing should be updated if you've modified it and the file is
writable by
+
+you. The file can be modified by using burst , rmm , rmm , or sortm
commands.
+
+The file can also be modified by using the refile command without the `-link'
+
+option. (Or course, the `-link' option doesn't actually link anything
to the
+
+file.)
+
+
+
+Distributed Mail
+
+
+MH now contains a powerful facility for doing distributed mail
(having MH
+
+reside on a host different than the message transport agent). For
general
+
+information, consult either the MH.5: How to process 200 messages a
day
+
+and still get some real work done paper, or the MH: A Multifarious
User
+
+Agent paper. For specific information, consult the Administrator's
Guide.
+
+Here's a brief synopsis:
+
+ This POP facility in MH is based on a modification of the
ARPA Post
+
+Office Protocol (POP). A POP subscriber is a remote user, on a POP client
+
+host, that wishes to pick-up mail on a POP service host.
+
+ There are two ways to administer POP:
+
+
+ - Naive Mode
+
+ Each user-id in the passwd (5) file is considered a POP
subscriber. No
+
+
+
+ 10
+
+
+
+
+ changes are required for the mailsystem on the POP service host. How-
+
+ ever, this method requires that each POP subscriber have an
entry in
+
+ the password file. The POP server will fetch the user's mail from
wher-
+
+ ever maildrops are kept on the POP service host. This means
that if
+
+ maildrops are kept in the user's home directory, then each
POP sub-
+
+ scriber must have a home directory.
+
+
+ - Smart Mode
+
+ This is based on the notion that the list of POP
subscribers and the
+
+ list of login users are completely separate name spaces. A
separate
+
+ database (similar to the BBoards (5) file) is used to record
information
+
+ about each POP subscriber. Unfortunately, the local mailsystem must
+
+ be changed to reflect this. This requires two changes (both
of which
+
+ are simple):
+
+
+ 1. Aliasing
+
+ The aliasing mechanism is augmented so that POP subscriber ad-
+
+ dresses are diverted to a special delivery mechanism.
MH comes
+
+ with a program, popaka (8), which generates the
additional infor-
+
+ mation to be put in the mailsystem's alias file.
+
+ 2. Delivery
+
+ A special POP delivery channel (for MMDF-II ) or POP
mailer (for
+
+ SendMail ) performs the actual delivery (mh.6
supplies both). All
+
+ it really does is just place the mail in the POP spool area.
+
+
+ Clever mailsystem people will note that the POP mechanism is
really
+
+ a special case of the more general BBoards mechanism.
+
+
+These two different philosophies are not compatible on the same POP service
+
+host: one or the other, but not both, may be run.
+
+ In addition, there is one user-visible difference, which the
administrator
+
+controls the availability of. The difference is whether the POP
subscriber
+
+must supply a password to the POP server:
+
+
+ - ARPA standard method
+
+ This uses the standard ARPA technique of sending a username
and a
+
+ password. The appropriate programs (inc , msgchk , and
possibly bbc )
+
+ will prompt the user for this information.
+
+
+
+ 11
+
+
+
+
+ - UNIX remote method
+
+ This uses the Berkeley UNIX reserved port method for authentication.
+
+ This requires that the two or three mentioned above programs be setuid
+
+ to root. (There are no known holes in any of these programs.)
+
+
+These two different philosophies are compatible on the same POP
service
+
+host: to selectively disable RPOP for hosts which aren't trusted, either mod-
+
+ify the .rhosts file in the case of POP subscribers being UNIX logins, or
zero
+
+the contents of network address field of the pop (5) file for the
desired POP
+
+subscribers.
+
+ The inc command also has two other switches when MH is
enabled for
+
+POP: `-pack file' and `-nopack'. Normally, inc will use the POP to incor-
+
+porate mail from a POP service host into an MH folder (+inbox). However,
+
+there are some misguided individuals who prefer to msh to read
their mail-
+
+drop. By using the `-pack file' option, these individuals can direct
inc to
+
+fetch their maildrop from the POP service host and store it locally
in the
+
+named file. As expected, inc will treat the local file as a maildrop,
performing
+
+the appropriate locking protocols. And, if the file doesn't exist,
the user is
+
+now asked for confirmation.
+
+
+
+Rcvmail hooks
+
+
+In order to offer users of MH increased rcvmail hook functionality, the
slocal
+
+program has been upgraded to support the semantics of the MMDF-II mail-
+
+delivery mechanism. This means that users of mh.6 can maintain
identi-
+
+cal .maildelivery files regardless of the underlying transport
system. See
+
+mhook (1) for all the details.
+
+
+
+Change in rcvdist
+
+
+The rcvdist rcvmail hook now uses the MH formatting facility
when redis-
+
+tributing a message.
+
+
+
+Field change in rcvpack
+
+
+The rcvpack rcvmail hook now adds the field name Delivery-Date: instead
+
+of Cron-Date: to messages it pack s.
+
+
+
+ 12
+
+
+
+
+GNU Emacs Support
+
+
+James Larus' mh-e macro package for GNU Emacs (version 17) is
included
+
+in the distribution. When loaded in Emacs, this provides a handy front-end.
+
+
+
+Other Changes
+
+
+Here's the miscellany:
+
+
+
+Continuation Lines
+
+
+Alias files used by MH , display templates used by mhl , and format files
used
+
+by forw , repl , and scan all support a standard continuation
line syntax. To
+
+continue a line in one of these files, simply end the line with
the backslash
+
+character (`n'). All the other files used by MH are in
822-format, so the
+
+822-continuation mechanism is used.7
+
+
+
+Default Date Format
+
+
+MH now uses numeric timezones instead of locally-meaningful alpha
time-
+
+zones when generating mail. This change was made to encourage the
use
+
+of unambiguous, globally-meaningful timezone strings. A local
configura-
+
+tion option can disable this correct behavior. All of the mhl templates
have
+
+been modified to use locally-meaningful alpha timezones when displaying
+
+messages.
+
+
+
+New switch in ali
+
+
+The ali command now has a `-noalias' switch to prevent system-wide aliases
+
+from being interpreted.
+
+
+
+Modifications to show
+
+
+The `-format', `-noformat', `-pr', and `-nopr' options to show have gone
away
+
+in favor of a more general mechanism. The `-showproc program' option tells
+________________________________________________
+ 7 Looking back, it would have been best had all files in MH used the
822-format.
+
+
+
+ 13
+
+
+
+
+show (or next or prev ) to use the named program as the
showproc. The
+
+`-noshowproc' option tells show , et. al., to use the cat (1) program
instead of
+
+a showproc. As a result, the profile entry prproc is no longer used.
+
+
+
+Switch change in inc
+
+
+The `-ms ms-file' switch in inc has been changed to `-file name' to
be
+
+more consistent.
+
+
+
+Front-End to mhl
+
+
+When outputting to a terminal, the mhl program now runs the
program
+
+denoted by the profile entry moreproc. If this entry is not
present, the
+
+default is the UCB more program. If the entry is non-empty,
then that
+
+program is spliced between mhl and the user's terminal. The author uses the
+
+less program as his moreproc.
+
+ Of course, if mhl isn't outputting to a terminal, then
moreproc is not
+
+invoked.
+
+ Finally, to aid in the construction of replies, a prefix string may be
speci-
+
+fied for the body component of the message being replied-to. Simply use the
+
+component= construct in mhl for body:.
+
+
+
+Confirmation in packf
+
+
+If the file specified by the `-file name' switch doesn't exist, the user is now
+
+asked for confirmation.
+
+
+
+Complex Expressions in pick
+
+
+The pick command now handles complex boolean expressions.
+
+
+
+Defaults change in prompter and burst
+
+
+The `-prepend' option is now the default in prompter . The
`-noinplace'
+
+option is now the default in burst .
+
+
+
+ 14
+
+
+
+
+Fcc:s and post
+
+
+If multiple Fcc:s for a message are specified during posting, post will try
much
+
+harder to preserve links.
+
+
+
+Interactive option in rmf
+
+
+The rmf program has been changed to support an `-interactive'
switch.
+
+If given, then the user is prompted regarding whether the folder
should be
+
+deleted. If the folder to be removed is not given by the user,
this switch is
+
+defaulted to on.
+
+
+
+Trusted Mail Interface
+
+
+MH now has an interface for so-called "trusted mail" applications.
Although
+
+the modifications to MH to support this are in the public domain, the
actual
+
+library that MH uses is not. Contact Professor David J. Farber
(address@hidden)
+
+for more information.
+
+
+
+References
+
+
+[MRose85] Marshall T. Rose and John L. Romine. The Rand MH
Message
+
+ Handling System: User's Manual. Department of
Information
+
+ and Computer Science, University of California, Irvine,
mh.6 edi-
+
+ tion, November, 1985. UCI Version.
+
+
+
+ 15
diff --git a/docs/historical/multifarious.pdf b/docs/historical/multifarious.pdf
new file mode 100644
index 0000000..25d07ed
Binary files /dev/null and b/docs/historical/multifarious.pdf differ
diff --git a/docs/historical/multifarious.txt b/docs/historical/multifarious.txt
new file mode 100644
index 0000000..195c2aa
--- /dev/null
+++ b/docs/historical/multifarious.txt
@@ -0,0 +1,2284 @@
+
+
+
+
+ MH: A Multifarious User Agent
+
+
+ Marshall T. Rose
+
+ Member, Research Technical Staff
+
+ Northrop Research and Technology Centery
+
+
+
+ Einar A. Stefferud
+
+ President, Network Management Associatesz
+
+ and Visiting Lecturer, University of California, Irvine
+
+
+
+ Jerry N. Sweet
+
+ Member, Technical Staff
+
+ Local Network Systems./
+
+
+
+ Abstract
+
+
+The UCI version of the Rand Message Handling System (MH) is discussed,
including
+
+important extensions. MH is a powerful user agent which operates in
the ARPA
+
+Internet and UUCP environments. In addition to the basic functions
provided
+
+by a user agent, such as reading and sending mail, MH has several
distinguishing
+
+characteristics which give the user additional message handling
capabilities. In
+
+particular, MH provides mechanisms for organizing messages, tailoring
its own
+
+behavior, and extending its functions.
+
+
+This document describes MH from several perspectives. Particular
emphasis is
+
+given to: the MH user environment, advanced features of MH which have proven
to
+
+be particularly useful for sophisticated users of electronic mail, MH's
potential as
+
+a record manager, and MH as a part of a distributed mail environment. Although
+
+MH as been widely used since its creation in 1979, a discussion of its
perspectives
+
+and functionality has not appeared in the open literature.
+
+
+________________________________________
+y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
+
+Computer mail: MRose% address@hidden
+z 17301 Drey Lane, Huntington Beach, CA 92647. Telephone: 714/842-3711.
+
+Computer mail: address@hidden
+./ 130 McCormick Avenue, Suite 102, Costa Mesa, CA 92626. Telephone:
714/754-6631.
+
+Computer mail: address@hidden
+
+
+ MH: A Multifarious User Agent
+
+
+
+Introduction
+
+ The UCI version of the Rand Message Handling System, MH, is a user
agent.
+
+In the interests of brevity, we dispense with the usual definition of terms,
refer the
+
+reader to Figure 1, and simply note that MH is not responsible for delivering
mail.
+
+Rather, it interacts with a message transport system, MTS, at two
interfaces: it
+
+sends mail by placing it through a posting slot to the MTS, and it receives
mail by
+
+retrieving it through a delivery slot from the MTS. Besides these two
MTS-specific
+
+activities, the tasks which MH addresses are: the composition of messages
(which
+
+may, or may not, be in reference to previously sent messages), the
reading of
+
+messages, and the organization of messages.
+
+
+ MH was originally developed by the Rand Corporation, and
initially was
+
+proprietary software. The Department of Information and Computer
Science
+
+at University of California, Irvine, shortly after joining the
Computer Science
+
+Network (CSnet), acquired a copy of MH, and began additional
development of
+
+the software. Since that time, the Rand Corporation has declared MH to be in
the
+
+public domain, and the UCI version of MH has passed through four major
releases.
+
+
+ Much credit must be given to the initial designers and implementors of
MH:
+
+Bruce Borden, Stockton Gaines, and Norman Shapiro. Although MH has suffered
+
+significant development at UCI since Rand's initial release, the
fundamental
+
+concepts of MH's environs have remained nearly unchanged. In
addition, the
+
+current maintainers of MH gratefully acknowledge the comments of the many sites
+
+which have run various releases of MH in the past.
+
+
+ MH runs on different versions of the UNIX1 operating system
(such as
+
+4.2bsd UNIX and various flavors of v7 UNIX). In addition, MH
supports four
+
+different MTS interfaces: SendMail[EAllm83], the standard mailer for
4.2bsd
+
+systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel Memo
+
+Distribution Facility developed by the University of Delaware which
forms the
+
+software-backbone for CSnet[DCome83] mail relays service; SMTP, the
ARPA
+
+Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery
system.
+
+
+ The organization of this paper is straight-forward, given space
considerations.
+
+Initially, the MH philosophy of mail handling is presented, along with a
description
+
+of the environment which the MH user is given to process mail.
Following this,
+
+certain advanced features of MH are discussed in more detail. In particular,
the
+
+
+________________________________________
+1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ Copyright fcl1985, North Holland Publishing Company
1
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
2
+______________________________________________________________________________________________________________________
+
+
+
+ UA
UA
+
+
+
+ POSTING
RECEIPT
+
+
+
+ MTS
+
+
+
+ MTA MTA : : :
: : : MTA
+
+ RELAYING
+
+
+
+ Figure 1
+
+___________________________________________________MTS_model__________________________________________________________
+
+
+
+notion of a draft folder is introduced, which permits the handling of multiple
drafts
+
+during composition. In addition, message selection facilities are described.
Next,
+
+two different aspects of MH's power as a software system are
discussed: record
+
+handling, in which MH facilitates record processing systems; and, how MH can be
+
+employed in a distributed mail environment. This latter section raises
questions
+
+as to the location of the posting and delivery slots, along with
authentication
+
+mechanisms. Finally, we conclude by discussing areas of future development
which
+
+MH may endure.
+
+
+ Although familiarity with MH is not assumed on the part of
the reader,
+
+some knowledge of the UNIX operating system is useful. Appendix A gives a
short
+
+synopsis of the MH commands.
+
+
+
+The MH Philosophy
+
+ Although MH has many traits which tend to differ it from other user
agents,
+
+the design aspect which fundamentally influences the interface between MH and
+
+the user is that it is composed of many small programs instead of one very
large
+
+one. This architecture gives MH much of its strength, since
intermediate and
+
+advanced users are able to take advantage of this flexibility.
+
+
+ The key to this flexibility is that the UNIX shell (usually the C shell
or the
+
+Bourne shell), is the user's interface to MH. This means that when handling
mail,
+
+the entire power of the shell is at the user's disposal in addition to the
facilities
+
+which MH provides. Hence, the user may intersperse mail handling
commands
+
+with other commands in an arbitrary fashion, making use of command handling
+
+capabilities that the user's shell provides.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
3
+
+
+ Furthermore, rather than storing messages in a complicated data
structure
+
+within a monolithic file, in MH, each message is a UNIX file, and each folder
(an
+
+object which holds groups of messages) is a UNIX directory. That is, the
directory
+
+and file structure of UNIX is used directly. As a result, any UNIX
file-handling
+
+command can be applied to any message.
+
+
+ To the novice, this may not make much sense or may not seem important.
+
+From three years of observation, we have seen that as users of MH have become
+
+more experienced they have found this capability to be quite
attractive. In
+
+addition, this approach is often quite pleasing to system
implementors, because
+
+it minimizes the amount of coding to be performed and, given a modular design,
+
+changes to the software system can be maintained easily. Our empirical
findings
+
+confirm our theoretical expectations regarding the MH architecture.
+
+
+ Having described how MH fits into the UNIX environment, we now discuss
+
+the mail handling environment which is available to the MH user.
+
+
+The MH Environs
+
+ MH provides a complementary environment to the user's shell.
While the
+
+shell maintains a context related to the user's focus in the file system (a
current
+
+working directory ), mail handling is performed in a separate mail folder
context.
+
+Operations on mail can therefore be performed entirely without regard
to the
+
+current file system context, although MH does not prevent the user from making
+
+use of that context. Certain mail handling functions do make use of
information
+
+maintained by the shell. For instance, by setting certain shell parameters,
called
+
+environment variables, alternate mail handling contexts can be selected.
+
+
+ MH conventions often have direct analogs to shell or file system
conventions.
+
+The shell has a current working directory; MH has a current mail folder. When
+
+the user begins a session on the system, the user's "home directory" is the
base
+
+context; MH's default base area, the Mail directory, is found under the user's
home
+
+directory. The user's default shell parameters are set upon beginning a new
session
+
+from a startup profile (called .profile for sh users or .cshrc for csh
users); the default
+
+parameters for MH commands are taken from a file called .mh_profile in
the user's
+
+home directory. The shell has an environment ; MH has a context file.
Each of the
+
+user's directories has files; each of the user's MH folders has messages.
+
+
+ These parallels have a basis not only in MH's high level mail handling
model,
+
+but also in the way low level shell and file system conventions have been
abstracted
+
+to implement MH conventions. Directories are folders; files are messages.
The Mail
+
+directory forms the root of a virtual file subsystem within which the user
operates
+
+on mail without disturbing files outside this mail handling domain.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
4
+______________________________________________________________________________________________________________________
+
+
+
+ $HOME/ (user's home directory)
+
+
+
+ .mh_profile Mail
+
+
+
+ context inbox/ mhl.format replcomps
drafts/ chron/
+
+
+
+ 1 2 3 1
+ sequences
yr.1984/ yr.1985/
+
+
+
+ Figure 2
+
+ MH File Subsystem
+
+__________________________________________(directories_are_shaded)____________________________________________________
+
+
+
+The MH Profile
+
+ The .mh_profile contains plaintext that describes the user's
default mail
+
+handling parameters. An example of an elaborated profile is shown in Figure 3.
+
+
+ Each line in the profile consists of an MH parameter name terminated
with
+
+a colon (`:') followed by parameter values. In this example, "global"
parameters
+
+are listed in the first few lines, with program-specific parameters following.
Each
+
+MH program examines global parameters as well as any parameter with the same
+
+name by which the program was invoked. For example, the comp program, which
+
+is used to compose new messages to be sent, examines the entries:
+
+
+
+ Path___: The path parameter specifies the name of the MH root
directory.
+
+ This is normally named Mail.
+
+
+ Editor____: The editor parameter specifies which text editor
is first invoked
+
+ to create the header information and body of a message
draft. In
+
+ most cases, this editor is the MH default editor,
prompter.
+
+
+ Draft-Folder______: This parameter specifies a folder within which new
message drafts
+
+ are to be created. The draft folder mechanism
is an advanced
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
5
+______________________________________________________________________________________________________________________
+
+Path: Mail
+Editor: prompter
+prompter-next: emacs
+Folder-Protect: 700
+Msg-Protect: 600
+Previous-Sequence: pseq
+Alternate-Mailboxes: address@hidden, address@hidden
+Draft-Folder: drafts
+Sequence-Negation: not
+bbc: -quiet
+bboards: system mh-workers sf-lovers whimsey
+comp: -form mycomponents
+dist: -annotate -inplace
+folder: -noheader
+forw: -annotate -inplace -format
+mhl: -noclear
+next: -noheader
+prev: -noheader
+prompter: -prepend
+repl: -annotate -inplace -cc me
+send: -format -msgid
+scan: -noheader -time
+show: -noheader -format
+showproc: mhl
+
+
+ Figure 3
+
+___________________________________________Elaborated_MH_Profile______________________________________________________
+
+
+
+ feature of MH that is given separate treatment in a
later segment
+
+ of this paper.
+
+
+ comp____: The program-specific parameter examined by comp
lists user-
+
+ default options.
+
+
+
+Other programs invoked by comp (e.g. prompter and send ) would examine their
+
+own profile entries as well. MH programs have reasonable compiled-in
defaults
+
+and also permit options to be specified on the shell command line with which
the
+
+programs are invoked. The order of override precedence is: command line
options
+
+first, .mh_profile options second, and compiled-in defaults last.
+
+
+ Each program option is prefixed by a dash (`-') following the UNIX
convention.
+
+Unlike most UNIX-style options, however, the options are words rather than
single
+
+letters. An option may be abbreviated to an unambiguous prefix.
Each MH
+
+program has a `-help' option that displays a brief summary of
the program's
+
+available options.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
6
+
+
+Folders and Messages
+
+ In a typical paper-oriented office, new correspondence arrives and is
stacked
+
+in an "in box", while outgoing correspondence is placed in an "out box".
Processed
+
+material is stored in appropriately labelled folders and filed away
for future
+
+reference. This state of affairs is modelled in MH with folders and messages,
which
+
+are simply text files (one message per file) stored under the folder
directories. Most
+
+of the user's folders are kept under the Mail directory.
+
+
+ A folder is given an alphanumeric name permissible within the
UNIX file
+
+system structure, and each message stored therein is given a numeric name in
the
+
+range 1..1999. The upper bound on message numbers was selected for
efficient
+
+access to an internal representation, an array of bits (a "bit set"), with
each bit
+
+indicating the presence or absence of a message with a number in the range
1..1999.
+
+This internal representation also restricts the order of multiple message
reference
+
+to an ascending numerical sequence. Other representations have been
studied
+
+(e.g., an unsorted sparse array of integers), but have been rejected for
reasons of
+
+efficiency. Folders may contain subfolders, corresponding to UNIX
tree-structured
+
+directories. For the sake of completeness, it might be said that
"sub-messages"
+
+exist insofar as message "digests", which nest messages inside other messages,
are
+
+supported by certain advanced MH functions.
+
+
+ The current working folder is the default folder selected for almost
all MH
+
+commands. To select explicitly a folder for mail handling commands
entails
+
+specifying the name of the folder, prefixing the name with a plus-symbol
(`+'). An
+
+example is:
+
+
+ refile 1 2 3 +chron/yr.1984
+
+
+This command re-files the selected messages (1 , 2, and 3 here) from the
current
+
+working folder to a subfolder under the folder chron named yr.1984 .
To see the
+
+folder/subfolder relationship, refer to Figure 2.
+
+
+ The plus-symbol notation is specific to those folders immediately
subordinate
+
+to the Mail directory. This is analogous to "absolute pathnames" in UNIX_those
+
+files whose positions in the file system hierarchy are given starting with the
system
+
+root, names prefixed with the slash character (`/'). To specify folders
subordinate to
+
+the current working folder, an at-sign (`@') is substituted for (`+'). It is
permitted
+
+to use UNIX dot notation to specify parent folders. Referring to Figure 2,
if the
+
+current working folder were ``+chron/yr.1985'' , then the command
+
+
+ folder @../yr.1984
+
+
+selects the subfolder yr.1984 in the parent directory chron , as
the new current
+
+working folder. While the current working folder is normally the default, it
may
+
+be specified explicitly as address@hidden'' .
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
7
+______________________________________________________________________________________________________________________
+
+To: <reply-to_from>
+cc: <?to_cc_me><to>,<cc>,<me>
+Subject: <?subject>Re: <subject>
+In-reply-to: <?date><?message-id>Your message of <date>.
+ <message-id>
+In-reply-to: <?date><!message-id>Your message of <date>.
+Fcc: <?fcc><fcc>
+--------
+
+
+ Figure 4
+
+_______________________________________Elaborated_Reply_Template______________________________________________________
+
+
+
+The Context File
+
+ The .mh_profile contains static information about the user's
preferences. A
+
+context file, contained in the Mail directory, contains the current
mail handling
+
+environment information, which changes as different folders, messages, and
named
+
+message lists (called message sequences ) are selected, created, and updated.
This
+
+information is retained between invocations of MH commands, and is
preserved
+
+across system sessions.
+
+
+Templates
+
+ The message draft composition functions (comp, repl, forw, and
dist ) use
+
+certain default header formats, which may be changed by the user through the
use
+
+of message templates. The exact format of a template may vary among commands.
+
+An example of an elaborated template for the reply command repl is
shown in
+
+Figure 4.
+
+
+ This template specifies how the automatically-generated header for a
draft
+
+message in reply to a source message is to be formatted. The syntax is
capable of
+
+directing output of header lines based on the presence or absence of other
header
+
+lines in the source message.
+
+
+ Other kinds of templates are used to specify the display formats of
messages,
+
+or to specify the way that messages are to be included in other messages.
This is
+
+similar to the functionality provided by BBN Hermes[HERMES], another powerful
+
+mail handling system for Tops202 based systems.
+
+
+Explaining All This to New Users
+
+ There do exist people who do not like MH.3 The emerging
pattern of
+
+complaints from such people indicates that MH accentuates their perceptions of
+
+the deficiencies of UNIX, to wit, lack of interactivity and lack of easily
found help
+
+facilities. Also, some feel that the proximity of the mail handling
environment
+
+to the operating system is a distraction, rather than an asset. There have
been
+
+________________________________________
+2 Tops20 is a trademark of Digital Equipment Corporation.
+3 At UCI, these people are reported to be weeded out at an early stage and
quietly taken to the
+
+Ministry of Love to be made uncrimethinkful.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
8
+
+
+some attempts to make MH more accessible to users who prefer menu-oriented or
+
+monolithic mail system interfaces.4
+
+
+ In truth, users new to UNIX do not always acclimate to MH
easily. The
+
+command set is undistinguishably mixed in with all other UNIX
utilities, and it
+
+is not easy, without aid of a manual, to pick out the necessary
commands. MH
+
+does not provide any "hand-holding" to guide the user through a minimally
useful
+
+command subset.
+
+
+ Another problem is that the initial default user profile is
too often sparse,
+
+containing only a ``Path:'' parameter. MH commands will perform
adequately
+
+without specific information in the profile, so new users often neglect
optionally
+
+useful MH capabilities, eventually becoming frustrated with the
limited default
+
+capabilities, yet unable to determine without researching through the
user's
+
+manual, the necessary options that would solve their problems.
+
+
+ The currently available means for learning how to use MH are:
+
+
+
+ - One-on-one tutoring by knowledgeable MH users, which
has so far
+
+ shown the best results with new users.
+
+
+ - Consulting the MH Tutorial [MRose84b], or the MH
User's
+
+ Manual [MRose85a].
+
+
+ - Using the msh ("MH shell") program as a training shell
to read
+
+ bulletin boards. The msh command is an interactive
program that
+
+ provides some help messages and can list available MH
commands.
+
+
+
+No on-line tutorial materials are presently distributed with the mh.5
system,
+
+although there are some plans in the works to provide a program to
help with
+
+setting up the user profile that would also provide operational tips
for MH and
+
+UNIX.
+
+
+ It should be noted that these perceived defects of MH do not affect its
utility
+
+any more than analogous problems with any operating system will
diminish its
+
+actual capabilities. Users may quarrel with the means chosen for
orchestrating
+
+MH, but the fact remains that MH is a very useful set of mail handling tools
that
+
+is flexible, infinitely interoperable with other UNIX text handling
tools, and yet
+
+simple enough for new users to grasp once they are given the proper start. The
+
+fact that better tutorial materials and training do not exist only means that
some
+
+further work needs to be done in the area of user-education.
+
+
+
+________________________________________
+4 For example, mhe from Brian Reid of Stanford University and emh
from Marshall Rose are
+
+instances of macro packages for James Gosling's EMACS extensible editor, while
the hm program
+from Jim Guyton of the Rand Corporation is a monolithic MH interface. As of
this writing, none
+of these programs is documented in the literature.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
9
+
+
+A Few Advanced Features
+
+ We now consider certain advanced features in MH. These features have
been
+
+chosen to demonstrate some useful capabilities available to the MH user. It
should
+
+be noted that many capabilities of MH, such as shell scripts for
extensibility, mail
+
+delivery hooks, the personal aliasing facility, and so forth, are not
described here
+
+for lack of space.
+
+
+Draft Folders
+
+ The draft folder facility provides a method by which several message
drafts can
+
+be simultaneously composed and maintained until sent. The rationale for this
is that
+
+partially composed message drafts, perhaps elaborate sets of separate
messages,
+
+can be incrementally completed, while a folder provides a consistent
organization
+
+for drafts in progress. This is comparable to similar situations in the
"paper world"
+
+where contracts, business correspondence, and other communications, rather than
+
+being created serially with each posted in turn before composing the
next, are
+
+usually left in various stages of completion before they are eventually mailed.
+
+
+ The ``Draft-Folder:'' parameter value in the MH profile is
used to specify
+
+a default draft folder, where each draft is given a number and an "artificial"
date
+
+stamp. Provided that the proper header fields have been completed, a scan
listing
+
+of the draft folder provides a summary of each draft in progress:
to whom the
+
+message is to be sent, the subject, the date of the draft's
initial creation and
+
+optionally, the current size of the draft in terms of characters. Experienced
users
+
+of MH may often keep as many as five to ten unfinished drafts in their draft
folder.
+
+"Draft clutter" can be remedied easily with the rmm command.
+
+
+Message Selection
+
+ MH commands accept message sequence specifications to specify which
`msg'
+
+or `msgs' are to be operated upon. Here are some examples:
+
+
+ scan 1 3 5 19 185
+
+
+to get a scan listing of messages 1, 3, 5, 19 and 185.
+
+
+ scan pseq
+
+
+to get a scan listing of whatever message sequence was given to the previous MH
+
+command (in this case 1, 3, 5, 19, and 185).
+
+
+ show first last
+
+
+to get a display of the first and last messages in the folder.
The MH sequences
+
+named ``first'' and ``last'' are system defined pseudo sequences
which act like
+
+explicit sequences when given to MH commands. Others are ``cur'' ,
``next'' ,
+
+``prev'' , and ``all'' which respectively specify the "current"
message, the
+
+"next" after cur, the "previous" message before cur, or "all"
messages in the
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
10
+
+
+current-folder. The scan assumes ``all'' while show assumes
``cur'' , unless
+
+overridden on the command line. Over-ride precedence is: command-line
first,
+
+.mh_profile second, and compiled-in default last.
+
+
+ Users can define additional sequences for similar use, but must avoid
using
+
+reserved names. A few optional sequence names have been preempted by MH, such
+
+as ``pseq'' to mean the "sequence used by the previous MH
command," and
+
+``unseen'' to mean the "messages not yet seen by the user." Sometimes
these
+
+preempted names can be changed by resetting them in the user's MH profile, but
+
+these facilities are beyond the scope of this discussion.
+
+
+ The mark command can be used to set the values for user-defined
sequences:
+
+
+ mark 1 3 5 -seq zzz
+
+ mark 4 5 9 -seq zzz -nozero
+
+
+will create a user-sequence named ``zzz'' and put the sequence ``1 3
5'' in it.
+
+The mark command assumes that any prior content in an existing user-sequence
+
+should be "zeroed" before the new sequence value is recorded. This
can be
+
+prevented with a `-nozero' switch on the command line, to add ``4 5
9'' to
+
+the original ``1 3 5'' to yield ``1 3 4 5 9'' .
+
+
+ mark pseq zzz -seq zzznew
+
+
+will create a new sequence named ``zzznew'' and set its value to the
combined
+
+(inclusive or) of the existing user-sequences in ``pseq'' and ``zzz''
for its value.
+
+
+ Another more powerful way to set the values of a user-sequence is with
the
+
+pick command, which provides full string search capabilities:
+
+
+ pick -from mrose -seq yyy
+
+ pick -from mrose -seq yyy -list
+
+
+will search though all the ``From:'' fields in the current
folder for the string
+
+``mrose'' and place the list of "hits" in the sequence named
``yyy'' . The
+
+`-list' switch will cause the resulting list to also be
displayed on the user's
+
+terminal. If no `-seq name' switch is given, pick will assume
`-list' and will
+
+simply display the resulting list of hits on the user's terminal.
+
+
+ This `-list' behavior of pick allows users to take advantage of
the UNIX
+
+backquoting facility to embed searches in other MH commands.
+
+
+ scan `pick -from mrose`
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
11
+
+
+will produce a scan listing of `-from mrose' hits because the
UNIX shell will
+
+spawn a process to execute the ``pick -from mrose'' segment and
return the
+
+`-list' results as the message sequence to be scanned.
+
+
+ mark pseq -seq zzz
+
+
+could then be used to capture the "previous sequence" in zzz for later use.
+
+
+ One last facility should be mentioned here. It is also
possible to negate a
+
+sequence to specify a new sequence. The default negation string is ``not''
.
+
+
+ scan notzzz
+
+ mark notzzz -seq zzznot
+
+
+will give the user a scan listing of all the messages in the current folder
that are
+
+not included in the sequence ``zzz'' . The mark example will of
course record
+
+the negation of zzz in zzznot. It is a bad idea to use the
string ``not'' as the
+
+beginning of any user-sequence name, if ``not'' is defined as the
negation string.
+
+(Users can choose a different negation string.)
+
+
+ From this discussion, it should be clear that MH provides a uniform
set of
+
+ways to capture and use sequences to augment the user's short- and
long-term
+
+memory and to manipulate lists of interesting messages.
User-sequences are
+
+normally stored as RFC822 labeled text lines in a file (e.g., sequences) in
the folder
+
+with the messages referred to in the sequence. If a user does not have write
access
+
+to a folder, then the MH mark and pick commands will create a "private"
sequence
+
+in the user's context file. Switches are available to give the user
control over the
+
+choice of `-private' or `-public' sequence options.
+
+
+ Since user-sequences are stored as ordinary text lines in RFC822
labeled fields,
+
+there is no prohibition against someone writing programs to perform any kind of
+
+useful manipulation on MH sequences. Boolean operators can be
implemented,
+
+or complex indexing structures could be developed to serve special purposes.
If a
+
+DBMS can utilize UNIX pathnames or MH `+folder' and message names, then
+
+the full power of the DBMS might be applied. The intention of MH development
+
+teams has always been to leave open the widest possible array of
options for
+
+later extension. The only restrictions should be the user's ingenuity,
programming
+
+prowess, and the available machine resources. Unfortunately these resources
always
+
+seem to be available in limited quantities.
+
+
+Distribution Lists
+
+ MH has a convenient interface to the UCI BBoards facility[MRose84a].5
This
+
+facility permits the efficient distribution of interest group messages
on a single
+
+
+
+________________________________________
+5 The UCI BBoards facility can run under either the MMDF or SendMail, or in a
more restricted
+
+form under stand-alone MH.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
12
+
+
+host, to a group of hosts under a single administration, and to the ARPA
Internet
+
+community.
+
+
+ Described simply, an interest group is composed of a number of
subscribers
+
+with a common interest. These subscribers post mail to a single address, known
+
+as a distribution address (e.g., address@hidden). From this distribution
address,
+
+a copy of the message is sent to each subscriber. Each group has
a moderator,
+
+which is the person that runs the group. This moderator can usually be reached
+
+at a special address, known as a request address (e.g., address@hidden).
+
+Usually, the responsibilities of the moderator are quite simple,
since the mail
+
+system handles distribution to subscribers automatically. In some interest
groups,
+
+instead of each separate message being distributed directly to subscribers, a
batch
+
+of (related) messages are put into a digest format by the moderator and then
sent
+
+to the subscribers. Although this requires more work on the part of the
moderator
+
+and introduces delays, such groups tend to be better organized.
+
+
+ Unfortunately, some problems arise with the scheme outlined above.
First, if
+
+two users on the same host subscribe to the same interest group, two copies of
the
+
+message will be delivered. This is wasteful of both processor and disk
resources at
+
+that host.
+
+
+ Second, some groups carry a lot of traffic. Although subscription to a
group
+
+does indicate interest on the part of a subscriber, it is usually not
interesting to get
+
+50 messages or so delivered to the user's private maildrop each day,
interspersed
+
+with personal mail, that is likely to be of a much more important
and timely
+
+nature.
+
+
+ Third, if a subscriber's address in a distribution list becomes "bad"
somehow
+
+and causes failed mail to be returned, the originator of the message is
normally
+
+notified. It is not uncommon for a large list to have several bogus
addresses. This
+
+results in the originator being flooded with "error messages" from mailers
across
+
+the Internet stating that a given address on the list was bad. Needless to
say, the
+
+originator usually does not care if the bogus addresses got a copy of the
message
+
+or not. The originator is merely interested in posting a message to the group
at
+
+large. On the other hand, the moderator of the group does care if there are
bogus
+
+addresses on the list, but ironically does not receive notification.
+
+
+ To solve all of these problems, the UCI BBoards facility
introduces a new
+
+entity into the picture: all interest group mail is handled by a special
component of
+
+the mail system. The distribution address maps to a special channel that
performs
+
+several actions. First, if local delivery is to be performed, then
a copy of the
+
+message is placed in a global maildrop for the interest group with a timestamp
and
+
+a unique number. Local users can read messages posted for the interest group
by
+
+reading this "public" maildrop. Second, if further distribution is to take
place, a
+
+copy of the message is sent to the distribution address in such a way that if
any of
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
13
+
+
+the addresses are bogus, failure notices will be returned to the local
maintainer of
+
+the group address list, rather than the originator of the message.
+
+
+ This scheme has several advantages: First, messages delivered
to the local
+
+host are processed and saved once in a globally accessible area. The UCI
BBoards
+
+facility supports software which allows a user to query an interest group for
new
+
+messages and to read and process those messages in the MH-style. Second, once
+
+a host administrator subscribes to an interest group, each user can
join or quit
+
+the list's readership without contacting anyone. Third, a hierarchical
distribution
+
+scheme can be constructed to reduce the amount of delivery effort. Fourth,
errors
+
+are prevented from propagating. When an address on the distribution
list goes
+
+bad, the list moderator who is immediately responsible for the address is
notified.
+
+If a local moderator does not exist, then the local PostMaster is notified
(not the
+
+global group moderator).
+
+
+ In addition to solving the problems outlined above, the UCI BBoards
facility
+
+supports several other capabilities. BBoards may be automatically
archived in
+
+order to conserve disk space and reduce processing time when reading
current
+
+items. Also, the archives can be separately maintained on tape for
access by
+
+interested researchers.
+
+
+ Special alias files may be generated which allow the MH user
to shorten
+
+address type-in. For example, instead of sending to address@hidden, a user
+
+of MH usually sends to ``SF-Lovers'' and the MH aliasing facility
automatically
+
+makes the appropriate expansion in the headers of the outgoing message. Hence,
+
+the user need only know the name of an interest group and not its global
network
+
+address.
+
+
+ Finally, the UCI BBoards facility supports private interest groups
using the
+
+UNIX group access mechanism. This allows a group of people on the
same or
+
+different machines to conduct a private discussion.
+
+
+ The practical upshot of all this is that the UCI BBoards facility
automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+ MH provides three programs to deal with interest groups. The bbc
program
+
+is used to check on the status of one or more groups, and to optionally start
an
+
+MH shell on those groups which the user is interested in. The bbl program can
be
+
+used to perform manual maintenance on a discussion group beyond the
normal
+
+automatic capabilities of the UCI BBoards facility. Finally, the msh
program
+
+implements an MH shell for reading BBoards, in which nearly all of
the MH
+
+commands are implemented in a single program.
+
+
+ Observant readers may note that the use of msh is contrary
to the MH
+
+philosophy of using relatively small, single-purposed programs. Sadly, the
authors
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
14
+
+
+admit that this is true. In an effort to avoid some problems with
shared-access and
+
+message naming conventions (which are beyond the scope of this paper), BBoards
+
+are kept in maildrop format (monolithic) instead of folders. Some
research has
+
+gone into overcoming this problem in order to restore MH's purity of purpose,
but
+
+all solutions proposed to date are either unworkable or require significant
recoding
+
+of MH's internals.
+
+
+Encapsulation
+
+ As described above, some interest groups appear in digest
form. This
+
+means that the messages which appear in such a forum actually encapsulate other
+
+messages in their body. It turns out that the generation of a
digest is not at
+
+all unlike the generation of a draft which forwards one or more
messages. In
+
+RFC934[MRose85b], a method is proposed to standardize message encapsulation
+
+for the ARPA Internet community. MH uses this method for the
generation of
+
+digests, forwardings, and blind-carbon-copies.
+
+
+ A key requisite for using an encapsulation technique for
digests and
+
+forwardings is the ability to later decapsulate the contents. Without this
ability,
+
+the forwarded messages are of little use to the recipients because they can
not be
+
+distributed, forwarded, replied-to, searched-for, or otherwise processed as
separate
+
+individual messages. In the case of a digest, a bursting capability
is especially
+
+useful. Not only does the ability to burst a digest permit a recipient of the
digest
+
+to reply to an individual digestified message, but it also allows
the recipient to
+
+selectively process the other messages encapsulated in the digest.
+
+
+ For example, a single digest issue usually contains more than one
topic. A
+
+subscriber may only be interested in a subset of the topic discussed in a
particular
+
+issue. With a bursting capability, the subscriber can burst the
digest, scan the
+
+headers, and process those messages which are of interest. The
others can be
+
+ignored, if the user so desires.
+
+
+ Note that with proper encapsulation technology, one can argue
for the
+
+re-distribution of messages simply becoming special cases of message
forwarding.
+
+For example, the NBS Standard for Mail Interchange[FIPS98] and the
recent
+
+CCITT draft on Mail Handling Systems standards[X.400] both discourage
the
+
+re-distribution facility in favor of forwarding by encapsulation.
+
+
+Encapsulation and Blind-Carbon-Copies
+
+ Many user agents support a blind-carbon-copy facility. MH implements
this
+
+using a form of encapsulation. It may not be apparent to the
reader as to why
+
+encapsulation of the original message is a good way to deliver
blind-carbon-copies.
+
+With a blind-carbon-copy facility, two types of addressees are possible in the
draft
+
+to be sent: visible and blind. The visible recipients are listed as
addresses in the
+
+``To:'' and ``cc:'' fields, and the blind recipients are listed in
the ``Bcc:''
+
+fields of the draft. The idea behind this facility is that copies of the
draft which are
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
15
+
+
+delivered to the ``To:'' and ``cc:'' recipients should show the
visible recipients
+
+only.
+
+
+ A major concern with a blind-carbon-copy facility is that
blind recipients
+
+should be prevented from accidentally replying to the message in such a way
that
+
+the visible recipients are included as addressees in the reply.
+
+
+ There are several methods to implement this facility. Most rely on
posting
+
+two drafts with the MTS. One draft is destined for visible recipients, and
simply
+
+lacks the ``Bcc:'' fields of the original draft. The second draft is
destined for the
+
+blind recipients. The question then arises as to what form this latter draft
posted
+
+should take.
+
+
+ One approach might be to disable the ``To:'' and ``cc:''
fields of the
+
+draft sent to the blind recipients (e.g., by prefixing the string ``BCC-''
to these
+
+fields). Unfortunately, this is often very confusing to the blind recipients
because
+
+it differs from what the visible recipients got. Although accidental replies
are not
+
+possible, it is often difficult to tell that the message received
is the result of a
+
+blind-carbon-copy.
+
+
+ The method used by MH is to post two drafts, a visible draft for the
visible
+
+recipients, and a blind draft for the blind recipients. The visible
draft consists
+
+of the original draft without any ``Bcc:'' fields. The blind
draft contains the
+
+visible message as a forwarded message. The headers for the blind draft
contain
+
+the minimal RFC822 headers (``From:'' and ``Date:'' ) and,
if the original
+
+draft had a "Subject:" field, then this header field is also included. In
addition,
+
+MH alerts the recipient that the message is a blind-carbon-copy by
placing this
+
+information in the initial encapsulation information in the blind recipient's
copy.
+
+This scheme prevents inadvertent replies while allowing the recipient full
access to
+
+an exact copy of what was sent to the visible recipients.
+
+
+
+MH as a Record Handler
+
+ Although message format standards such as RFC822 (and its predecessors)
+
+were originally devised to facilitate computer processing of interpersonal
messages,
+
+there is no special reason why the concept should be limited to
interpersonal
+
+message processing. Messages are just one of a variety of useful record forms
that
+
+might be created in one place and transfered to another for
processing. In this
+
+regard, RFC822 wisely left open the option for higher level
applications to use
+
+arbitrary header names or field contents by proscribing MTS use of header names
+
+beginning with ``X-'' .
+
+
+ MH carries though on this idea by allowing the pick command to accept
any
+
+arbitrary field name for string searches, so MH users can select on any
arbitrary
+
+field name without prior definition. Beyond this, since all messages are
simply files
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
16
+
+
+in UNIX directories, applications can be developed to apply any
programmable
+
+process to any selected message.
+
+
+ For example, a Time Card Form might be called up by an MH user with
+
+
+ comp -form timecomps
+
+
+to enter time and attendance information into ``X-time: : ::''
fields in a draft
+
+message record. The timecomps form would include the address of a
supervisor
+
+who should validate the information, along with empty fields to be filled in
with
+
+data. In fancy applications, this might be done with a sophisticated
interactive
+
+data entry tool which would validate entered information, but this is an open
choice
+
+within the MH framework. Another alternative would be to use a received
message
+
+as the blank form to add a degree of central control over time
and attendance
+
+reporting forms.
+
+
+ Receiving supervisors could simply register approval by using
the MH dist
+
+command to resend subordinates' time cards to higher approval levels, or to
send
+
+them to a time card collection address. The MH dist command
automatically
+
+inserts "ReSent" header fields showing who resent it and the
resending date.
+
+Alternatively, the MH forw command could be used to transfer a batch of
approved
+
+time cards to the next processing station. If desired, a new "approval"
command
+
+could be programmed to provide a more trusted authentication, perhaps
with
+
+encryption of the content. Trusted mail systems, such as Trusted Mail6
[MRose85c],
+
+are becoming available for this purpose.
+
+
+ At the final collection destination, an automated User Agent
could be
+
+programmed to directly load the data into the Time and Attendance DBMS by
+
+parsing and decoding the data contained in the ``X-time: : ::'' fields.
It might be
+
+noted that while the RFC822 does not restrict the internal forms of messages,
it is
+
+necessary to conform to the interchange standard if specialized filters for
message
+
+headers are not to be built to serve as export laundries (a term originating
with
+
+Stephen H. Willson to describe conformance transformations in Ada7 ).
+
+
+Mapping Between Record Modes (DBMS/MHS)
+
+ This time and attendance example suggests that it is possible to define
one-to-
+
+one mappings between RFC822 fields and DBMS data elements. For every DBMS
+
+data element definition, there is a potential corresponding RFC822
transferable
+
+equivalent definition which can facilitate mail transfers of record
information.
+
+Indeed, a large portion of the definitional work is already done where a Data
Base
+
+has already been defined. All that remains is to define the RFC822
equivalents.
+
+
+
+________________________________________
+6 Trusted Mail is a trademark of Trusted Technologies, Incorporated.
+7 Ada is a trademark of the Department of Defense (Ada Joint Program Office).
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
17
+
+
+ The suggestion that a batch of time cards be forwarded inside
a "cover"
+
+message implies that it is possible in the MH framework to
recursively bundle
+
+messages within messages, and be able to recover the originals for
separate
+
+processing at a receiving destination. The MH burst command can be
applied
+
+recursively for this purpose because MH encapsulation uses an unambiguous
scheme
+
+to delimit messages that are enclosed inside other messages. Thus, it should
be
+
+possible to extract a structured set of records from a DBMS and mail the set
to a
+
+foreign site for processing, or reinsertion into another DBMS. As long as the
DBMS
+
+data element definitions correctly correspond to the RFC822 definitions, it is
not
+
+even necessary for the source and destination DBMS systems to be the same.
+
+
+ From this discussion, it is concluded that the MH framework can be
useful
+
+for building distributed record handling systems where people at widely
scattered
+
+locations must create and submit record forms for processing at distant
locations.
+
+This might prove to be especially effective when a mail system is
also needed
+
+for other communication purposes. A network of sales offices is a good
example,
+
+where general message service would be used for communications with
remote
+
+manufacturing and distribution centers, and could also be used for an order
entry
+
+system.
+
+
+ Another example might be for structured communications, as
occur in
+
+requisition and purchasing systems. Requisitions could be filled in and
mailed to
+
+approval offices, and resent or forwarded to others for action. At some
point, the
+
+requisitions could flow into other other more suitable processing systems as
needed.
+
+At the very least, the ability to originate requisitions can be distributed to
anyone
+
+with access to a mail system that can originate a proper requisition form.
+
+
+ As a last example, MH already supports group discussions with its BBoard
+
+facilities which allow for automatic sorting of mail by group address, with
shared
+
+private or public group access to contributed items. As has been
shown to be
+
+possible with administrative record systems, there is no obvious limit to the
ways
+
+that group discussion traffic might be organized into structured collections
with
+
+indices, annotations, or reference pointers to aid in making
conference archives
+
+more useful. Indeed, MH tools could even be used to feed discussion
items into
+
+existing conference systems.
+
+
+
+Distributed Mail
+
+ Next, we consider how MH might be used in a distributed mail
environment.
+
+Two schemes are discussed: one in which connectivity is high and
connections
+
+are relatively "cheap", and one in which connectivity is low and connections
are
+
+"expensive".
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
18
+
+
+The ARPA Internet Environs
+
+ The ARPA Internet community consists of many types of
heterogeneous
+
+nodes. Some hosts are large mainframe computers, others are personal
work-
+
+stations. All communicate using the milstd TCP/IP protocol suite[IP,
TCP].
+
+Messages which conform to the Standard for the Format of ARPA Internet Text
+
+Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
+
+
+ On smaller nodes in the ARPA Internet it is often impractical to
maintain
+
+a message transport agent. For example, a workstation may not have
sufficient
+
+resources (cycles, disk space) in order to permit an SMTP server and associated
+
+local mail delivery system to be kept resident and continuously
running.
+
+Furthermore, the workstation could be off-net for extended periods of
time.
+
+Similarly, it may be expensive (or impossible) to keep a personal
computer
+
+interconnected to an IP-style network for long periods of time. In other
words, the
+
+node is lacking the resource known as "connectivity".
+
+
+ Despite this, it is often desirable to be able to process
mail with MH on
+
+these smaller nodes, and they often support a user agent to aid the tasks of
mail
+
+handling. To solve this problem, a network node which can support a
message
+
+transport entity (known as service host) offers a maildrop service
to these less
+
+endowed nodes (known as client hosts). The Post Office Protocol[JReyn84] (POP)
+
+is intended to permit a workstation to dynamically access a maildrop on a
service
+
+host to pick-up mail.8 The level of access includes the ability to
determine the
+
+number of messages in the maildrop and the size of each message,
as well as to
+
+retrieve and delete individual messages. More sophisticated implementations
of the
+
+POP server are able to distinguish between the header and body portion of each
+
+message, and send n lines of a message to the POP client. This capability is
useful
+
+in thinly connected environments where conservation of bandwidth is important.
+
+By utilizing a more intelligent POP client, a user may generate "scan
listings" and
+
+dynamically decide which messages are worth taking delivery on. The philosophy
+
+of the POP is to put intelligence in the POP clients and not the POP servers.
+
+
+ The underlying paradigm in which the POP functions is that of
a split-
+
+slot/remote-UA model. The client host (such as a workstation) is
without a
+
+co-resident message transport agent (MTA), and thus makes use of a service
host
+
+with an MTA to obtain posting (SMTP) and delivery (POP) services. The entity
+
+which supports this type of environment is called a remote-UA since the user
agent
+
+resides on a different host than its associated message transport agent.
+
+
+
+________________________________________
+8 Actually, there are three different descriptions of the POP. The first,
cited in [JReyn84], was the
+
+original description of the protocol, which suffered from certain problems.
Since then, two alternate
+descriptions have been developed. The official revision of the POP[MButl85],
and the revision of the
+POP which MH uses (which is documented in an internal memorandum in the MH
release). This
+paper considers the POP in the context of the MH release.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
19
+
+
+ One very important issue which must be raised at this point
is one of
+
+authentication. The POP requires that a client identify itself to the server
using
+
+a server-specific user-id and a server/user-specific password. This
authentication
+
+is required to prevent unauthorized entities from accessing a maildrop on a POP
+
+service host. It must be emphasized that the POP client is not a "trusted"
entity
+
+of the MTS in any sense at all.
+
+
+ Ideally, one would also like to authenticate mail as it is posted on
the POP
+
+service host using the SMTP. Currently, in the ARPA Internet
community, no
+
+authentication is done with SMTP transactions. This is considered a
shortcoming
+
+by those interested in researching the split-UA model of distributed
mail. The
+
+MZnet environment, discussed in the next section, has authentication
facilities for
+
+posting mail.
+
+
+ The current release of MH supports the above model fully: a
POP client
+
+program is available to retrieve a maildrop on a POP service host. In
addition,
+
+using the SMTP configuration for delivery in MH, a user is able to
specify a
+
+search-list of service hosts (and networks) with which to try to post mail.
Using
+
+this search-list, when an MH user posts a draft, the post program
will attempt
+
+to establish an SMTP connection with each host in the list to post the message
+
+until it succeeds. Initial experimentation with the split-UA in a
local network
+
+environment has proved quite successful.
+
+
+The MZnet Environs
+
+ In 1983, the MZnet project[EStef84] at the University of California,
Irvine
+
+set out to study the problems involved with bringing Internet-class mail
handling
+
+facilities to personal computers. The project used Apple II computers running
the
+
+CP/M 2.2 operating system. Programming was done in a subset of the C language
+
+called BDS C. The transport system was based on the MMDF PhoneNet software,
+
+and implemented a split-slot arrangement between a personal computer
and a
+
+larger, centralized mail distribution system that performed user
authentication and
+
+provided a relatively secure mail transfer channel. The user agent, CP/MH, was
+
+based on MH.
+
+
+ A conclusion of the experiment was that small personal
computer systems
+
+with dial-up phone connections constrain user agent systems design in ways that
+
+require use of a split-slot interface between the UA and its supporting MTA,
and that
+
+this interface best provides the required services if it has error controlled
command
+
+and data transfer facilities, with interactive behavior. Another conclusion
indicated
+
+that a good design for a user agent in such a small personal computer
environment
+
+could be based on a very modular architecture, such as MH. A final conclusion
was
+
+that session-level authentication of the client UA is required for both
posting and
+
+delivery.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
20
+
+
+ It should be noted that the MZnet project had a profound influence on
the
+
+development of the POP used by MH. A somewhat more detailed
discussion of
+
+the relations between the two environments can be found in the POP description
+
+contained in the MH release.
+
+
+
+A Final Note
+
+ With the fifth major release of the MH system, it has become clear that
most
+
+major increases in functionality can come only at the expense of either
efficiency or
+
+portability. Although there has been great effort to keep MH portable to a
number
+
+of UNIX implementations,9 the divergence in process management
facilities, file
+
+system enhancements, and even C compiler capabilities has already
presented
+
+obstacles to some attempts to rehost the MH code.
+
+
+ There has been some discussion of implementing specialized MH
daemons
+
+that maintain context information over one or more sessions, thus decreasing
the
+
+amount of overhead involved in starting each MH command. Unfortunately, even
+
+if such daemons were to be implemented, they would be very difficult to move to
+
+versions of UNIX without sophisticated process management facilities,
and even
+
+then the differences in "philosophies" of process management[WJoy83,
EOlse84]
+
+would tend to keep such daemons system specific. A better solution seems to be
+
+simply to tune existing code.
+
+
+
+Acknowledgements
+
+ The authors would like to thank Norman Z. Shapiro and Phyllis Kantar of
+
+the Rand Corporation for their invaluable comments during the preparation of
this
+
+paper.
+
+
+
+Distribution Information
+
+ For information concerning distribution mechanics for the current
release of
+
+MH, please contact:
+
+
+ Support Group
+
+ Attn: MH Distribution
+
+ Department of Information and Computer Science
+
+ University of California, Irvine
+
+ Irvine, CA 92717 USA
+
+
+
+ 714/856-6852
+
+
+
+________________________________________
+9 As of this writing, there are approximately 75 sites running mh.5 on five
different implementations
+
+of UNIX.
+
+
+ References
+
+
+
+[DCome83] D. Comer. The Computer Science Research Network
CSnet: A
+
+ History and Status Report. Communications of the ACM
26, 10
+
+ (October, 1983), 747-753.
+
+
+
+[DCroc79] D.H. Crocker, E.S. Szurkowski, D.J. Farber. An
Internetwork
+
+ Memo Distribution Facility _ MMDF. Appearing in
Proceedings,
+
+ Sixth Data Communications Symposium, Asilomar, 1979, pp.
18-25.
+
+
+
+[DCroc82] D.H. Crocker. Standard for the Format of ARPA
Internet Text
+
+ Messages. Request for Comments 822. ARPA Internet
Network
+
+ Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DKing84] D.P. Kingston, III. MMDFII: A Technical Review.
Appearing in
+
+ Proceedings Usenix Summer '84 Conference, Salt Lake
City, Utah,
+
+ 1984, pp. 32-41.
+
+
+
+[EAllm83] E. Allman. SENDMAIL _ An Internetwork Mail Router.
+
+ Britton-Lee, Inc., Berkeley, California (July, 1983).
+
+
+
+[EOlse84] E.W. Olsen. NetOS Concepts and Facilities. Local Network
Systems,
+
+ Inc., Costa Mesa, California (August, 1984).
+
+
+
+[EStef84] E.A. Stefferud, J.N. Sweet, T.P. Domae. MZnet: Mail Service
for
+
+ Personal Micro-Computer Systems. Appearing in Proceedings,
Second
+
+ International Symposium on Computer Message Systems,
Nottingham,
+
+ U.K, 1984, pp. 293-302.
+
+
+
+[FIPS98] Specification for Message Format for Computer Based
Message
+
+ Systems. National Bureau of Standards (January, 1983).
+
+
+
+[HERMES] Bolt, Beranek, and Newman. Hermes User's Manual. for TOPS-20.
+
+ Bolt, Beranek, and Newman, Boston, MA (January, 1979).
+
+
+
+[IP] Internet Protocol. Request for Comments 791 (milstd
1777).
+
+ Appearing in Internet Protocol Transition Workbook, ARPA
Internet
+
+ Network Information Center (NIC), SRI International, 1981.
+
+
+
+[JReyn84] J.K. Reynolds. Post Office Protocol. Request for
Comments 918.
+
+ ARPA Internet Network Information Center (NIC), SRI
International
+
+ (October, 1984).
+
+
+
+ Copyright fcl1985, North Holland Publishing Company
21
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September, 1985
22
+
+
+[MButl85] M. Butler, J.B. Postel, et. al. Post Office Protocol
- Version 2.
+
+ Request for Comments 937. ARPA Internet Network
Information
+
+ Center (NIC), SRI International (February, 1985).
+
+
+
+[MRose84a] M.T. Rose. The Rand MH Message Handling System: The
UCI
+
+ BBoards Facility. Department of Computer and Information
Sciences,
+
+ University of Delaware (October, 1984).
+
+
+
+[MRose84b] M.T. Rose. The Rand MH Message Handling System:
Tutorial.
+
+ Department of Computer and Information Sciences,
University of
+
+ Delaware (October, 1984).
+
+
+
+[MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
+
+ User's Manual. UCI Version. Department of Information and
Computer
+
+ Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85b] M.T. Rose, E.A. Stefferud. Proposed Standard for
Message
+
+ Encapsulation. Request for Comments 934. ARPA Internet Network
+
+ Information Center (NIC), SRI International (January, 1985).
+
+
+
+[MRose85c] M.T. Rose, D.J. Farber, S.T. Walker. Design of the TTI
Prototype
+
+ Trusted Mail Agent. Appearing in Proceedings, Second
International
+
+ Symposium on Computer Message Systems, Washington, D.C., 1985
+
+ (to appear).
+
+
+
+[SMTP] Simple Mail Transfer Protocol. Request for Comments
821. ARPA
+
+ Internet Network Information Center (NIC), SRI
International
+
+ (August, 1982).
+
+
+
+[TCP] Transmission Control Protocol. Request for Comments 793
(milstd
+
+ 1778). Appearing in Internet Protocol Transition
Workbook, ARPA
+
+ Internet Network Information Center (NIC), SRI International,
1981.
+
+
+
+[WJoy83] W.N. Joy, E. Cooper, R.S. Fabry, S.J. Leffler, K.
McKusick,
+
+ D. Mosher. 4.2bsd System Manual. Technical Report
Number 5.
+
+ Computer Systems Research Group, University of California,
Berkeley.
+
+
+
+[X.400] Message Handling Systems: System Model-Service Elements,
+
+ Recommendation X.400, International Telegraph and
Telephone
+
+ Consultative Committee (CCITT).
+
+
+ Appendix A
+
+ MH Commands
+
+
+
+ MH is composed of several UNIX programs, which in theory are
fairly simple
+
+ and single-purposed. These commands are functionally grouped below:
+
+
+ Composing_Mail__________
+
+ comp: compose a message
+
+ A program to originate a message. Usually, a special prompting
editor front-
+
+ end, prompter, is used to fill-in a composition template with
the addressees
+
+ of the message, subject, and so forth.
+
+
+ dist : redistribute a message to additional addresses
+
+ A program that re-enters a message previously received by the
user into the
+
+ message transport system. Only new addresses are added; the
body of the
+
+ message is not changed in any way.
+
+
+ forw : forward messages
+
+ A program that encapsulates one or more messages in a new
message draft.
+
+ In addition, the user may add initial and/or closing comments.
+
+
+ repl : reply to a message
+
+ A program that constructs a reply to a message using a reply
template. The
+
+ template mechanism has sufficient generality to permit the user
to "program"
+
+ the form of the reply draft based on the contents of
the message being
+
+ replied-to.
+
+
+ send : send a message
+
+ A program that posts a draft with the message
transport system. The
+
+ send program is usually invoked by one of the four preceding
programs, and
+
+ performs simple front-end pre-processing prior to invoking the
post program.
+
+ For example, if invoked in push'd mode, send will
immediately relinquish
+
+ control of the user's terminal and post the message in
the background. If
+
+ the posting fails, send will send back a failure notice to the
user. If the user
+
+ had push'd the sending of the draft, then by default the draft
being sent is
+
+ encapsulated in the failure notice. This permits easy
burst'ing of the failure
+
+ notice to retrieve the original draft. Otherwise, if the
posting was successful,
+
+ the draft is marked as having been sent.
+
+
+whatnow : prompting front-end for send
+
+ A program which is called by comp, et. al., after the initial
draft has been
+
+
+
+ Copyright fcl1985, North Holland Publishing Company
23
+ Reprinted from Computer Networks and ISDN Systems, 10(2),
September, 1985 24
+
+
+ generated. The MH user can specify a different
whatnow program, which
+
+ yields considerable extensibility.
+
+
+ whom: report to whom a message would go
+
+ A program which examines the addresses of the draft and
expands all user-
+
+ defined aliases contained therein. Optionally, whom may
actually interact
+
+ with the message transport system to determine the
validity of the final
+
+ addresses. This program is also usually invoked by comp, et.
al.
+
+
+ Posting_Mail_______
+
+ ali : list mail aliases
+
+ A simple front-end to the MH aliasing mechanism.
+
+
+ ap: parse addresses 822-style
+
+ A useful debugging tool for PostMasters who wish to
examine how MH
+
+ interprets an Internet address.
+
+
+ conflict : search for alias/password conflicts
+
+ Another program used by system administrators to check the
consistency of
+
+ MH alias files, and portions of the local message transport
agent.
+
+
+install-mh: initialize the MH environment
+
+ A program which is automatically executed the first time a
user issues an MH
+
+ command. This program performs once-only initialization of
the user's MH
+
+ environment.
+
+
+ mhmail : send or read mail
+
+ A simple program generally used by other programs to generate
messages.
+
+ The mhmail command is similar in purpose to the old BellMail
program.
+
+
+ post : deliver a message
+
+ A complex MH back-end that interacts with the local
message transport
+
+ agent to enter messages through the posting slot. (See the
description of send
+
+ above).
+
+
+ Reading_Mail________
+
+ inc: incorporate new mail
+
+ A program that interacts with the local message transport
agent to retrieve
+
+ messages from the user's maildrop.
+
+
+ msgchk : check for waiting mail
+
+ A program which reports the status of mail waiting in the
user's maildrop.
+
+
+ show : show (list) messages
+
+ A program which lists messages to its standard output
(usually the user's
+
+ terminal), possibly invoking another program to do the actual
listing. Most
+
+ users of MH have show automatically call the mhl
program to format the
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September,
1985 25
+
+
+ message. The next and prev programs are simply ``show
next'' and
+
+ ``show prev'' , respectively.
+
+
+ mhl : produce formatted listings of MH messages
+
+ A program which displays a message as directed by a template.
This permits
+
+ the user to filter out uninteresting headers and re-arrange other
headers to a
+
+ particular preference. In addition to being invoked by show, the
mhl program
+
+ is optionally also invoked by forw to format each message being
forwarded;
+
+ invoked by repl to format the body of a message being
replied-to, if that
+
+ message is being included in the reply draft; and, invoked by post
to format
+
+ a message being sent as a blind-carbon-copy.
+
+
+ rmm: remove messages
+
+ A program that removes messages from an MH folder, optionally
running a
+
+ user-defined program instead of deleting them. If no program is
given, the
+
+ messages are "softly" removed, so they may possibly be recovered
later.
+
+
+ scan: produce a one-line-per-message scan listing
+
+ A program that generates a scan listing for messages. Each line
of the listing
+
+ contains date, source, subject, and possibly the initial body of
the message.
+
+
+ Folder_Handling________
+
+ folder : set/list current folder/message
+
+ A program used to list information concerning the current folder,
or set the
+
+ current folder and/or message.
+
+
+folders : list all folders
+
+ A program to list information on all folders (actually, just a
special case of
+
+ the folder command). Since the MH folder structure may be
recursive, the
+
+ user can indicate that folders should recursively examine all
folders.
+
+
+ refile: file message(s) in (an)other folder(s)
+
+ A program to move (or copy) messages from a source folder to one
or more
+
+ destination folders.
+
+
+ rmf : remove folder
+
+ A program that deletes a folder and all messages therein.
+
+
+ Message_Selection_________
+
+ anno: annotate messages
+
+ A program to arbitrarily annotate messages. If the user
so desires, after
+
+ distributing, forwarding, or replying-to a message, MH will
automatically
+
+ attach an annotation to the original message indicating the date
and addresses.
+
+
+ mark : mark messages
+
+ A program to manipulate user-defined sequences (lists of
messages). Usually,
+
+ mark is not employed directly by the MH user.
+ Reprinted from Computer Networks and ISDN Systems, 10(2), September,
1985 26
+
+
+ pick : select messages by content
+
+ A program to examine a list of messages and choose
those which meet
+
+ a particular selection criterion. The pick program is
often used in UNIX
+
+ back-quoted operations to pass message sequences to other MH
commands.
+
+
+ sortm: sort messages
+
+ A program to sort a list of messages according to the date given
in a particular
+
+ field.
+
+
+
Distribution_List_Handling____________
+
+ bbc: check on BBoards
+
+ A front-end to run msh on a list of distribution lists
which the user isn't
+
+ current on.
+
+
+ bbl : manage a BBoard
+
+ A (depreciated) program used to manually manage the local
archives of
+
+ a distribution list. These functions (archiving, expunging)
are performed
+
+ automatically by MH.
+
+
+ burst : explode digests into messages
+
+ A program used to decapsulate messages from ARPA Internet
digests. In
+
+ addition, messages which have been encapsulated during
forwarding (i.e.,
+
+ with forw ) can also be decapsulated using burst.10
+
+
+ msh: MH shell (and BBoard reader)
+
+ A monolithic program used to implement MH commands on
messages
+
+ arranged in a single file (maildrop format). Useful since
distribution lists are
+
+ kept in this format to minimize consumption of system resources.
+
+
+ pack : compress a folder into a single file
+
+ A program which takes messages stored in MH format and places
them in a
+
+ single file (using the same format known by msh).
+
+
+
Interface_to_the_UNIX_File_System________________
+
+mhpath: print full pathnames of MH messages and folders
+
+ A program which maps MH-style names into the UNIX file naming
convention.
+
+
+
+ ________________________________________
+ 10 Similarly, blind-carbon-copies may be decapsulated, though only
socially mature users should do
+
+ so.
+
+
+
+
+ Contents
+
+
+
+
Page
+
+Introduction . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .*
+ * 1
+
+The MH Philosophy . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 2
+
+ The MH Environs . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 3
+
+ The MH Profile . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 4
+
+ Folders and Messages . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 6
+
+ The Context File . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 7
+
+ Templates . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ * 7
+
+ Explaining All This to New Users . . . . . . . . . . . . .
. . . . . . . . . . 7
+
+A Few Advanced Features . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 9
+
+ Draft Folders . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ * 9
+
+ Message Selection . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 9
+
+ Distribution Lists . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 11
+
+ Encapsulation . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . *
+ *14
+
+ Encapsulation and Blind-Carbon-Copies . . . . . . . . . . .
. . . . . . . . 14
+
+MH as a Record Handler . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 15
+
+ Mapping Between Record Modes (DBMS/MHS) . . . . . . . . . . .
. . . 16
+
+Distributed Mail . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ * 17
+
+ The ARPA Internet Environs . . . . . . . . . . . . . . .
. . . . . . . . . . . 18
+
+ The MZnet Environs . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 19
+
+A Final Note . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ * 20
+
+Acknowledgements . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 20
+
+Distribution Information . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 20
+
+References . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ *. 21
+
+Appendix A: MH Commands . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 23
+
+
+
+________________________________________
+This document (version #1.54) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+
i
diff --git a/docs/historical/mznet.pdf b/docs/historical/mznet.pdf
new file mode 100644
index 0000000..e8fbfc3
Binary files /dev/null and b/docs/historical/mznet.pdf differ
diff --git a/docs/historical/mznet.txt b/docs/historical/mznet.txt
new file mode 100644
index 0000000..7a6b9a8
--- /dev/null
+++ b/docs/historical/mznet.txt
@@ -0,0 +1,1103 @@
+
+
+
+
+ MZnet: Mail Service for Personal
+
+
+ Micro-Computer Systems
+
+
+
+ Einar Stefferud
+
+ President,
+
+ Network Management Associates
+
+ and
+
+ Visiting Lecturer,
+
+ in Information and Computer Science
+
+ University of California at Irvine
+
+
+
+ Jerry Sweet
+
+Department of Information and Computer Science
+
+ University of California at Irvine
+
+
+
+ Terrance Domae
+
+ School of Engineering
+
+ University of California at Los Angeles
+
+
+
+ 0
+
+
+
+
+ Abstract
+
+ Traditional computer mail systems involve a co-resident User Agent
+(UA) and Mail Transfer System (MTS) on a time-shared host com-
+puter which may be connected to other hosts in a network, with new
+mail posted or delivered directly through co-resident mail-slot pro-
+grams. To introduce personal micro-computers (PCs) into this envi-
+ronment requires modification of the traditional mail system architec-
+ture. To this end, the MZnet project uses a split-slot model, placing
+UA programs on the PCs while leaving MTA programs on a mail relay
+host which can provide authentication and buffering. The split-slot
+arrangement might be viewed as a new protocol level which operates
+somewhere between the currently defined MTS-MTS and UA-UA lev-
+els.
+
+
+
+
+Introduction
+
+
+Mail systems were born and have grown up on large central time
sharing
+
+systems, often imbedded in large networks of inter-operating computers with
+
+a set of distributed processes automatically transferring mail between users.
+
+This is certainly the case with the U.S. Department of Defense
(DoD) Ad-
+
+vanced Research Projects Agency Network (ARPANET) [1 ] where much of
+
+the original computer network mail systems research and development
has
+
+taken place. Other mail networks such as the Computer Science
Network
+
+[2 ] sponsored by the U.S. National Science Foundation, have also
used rela-
+
+tively large shared computers lodged in an institutional setting, though they
+
+are often connected together with ordinary dial-up telephone links to form a
+
+large geographic network. Another U.S. example is USENET [3 ] which con-
+
+nects thousands of Unix1 systems together with informally-supported
dial
+
+telephone links. Although there have been several attempts, there appear to
+
+be no successful mail networks based on small personal computers,
such as
+
+those that use the CP/M2 or MS-DOS3 operating systems.
+
+ The accepted architectural model (see Figure 1) for computer
network
+
+mail (first articulated by the IFIP 6.5 Systems Environment Working Group)
+
+involves a User Agent (UA) which posts new mail items through a mail slot
+
+[4 , 5, 6, 7] to a Mail Transfer Agent (MTA) which delivers posted
items to
+
+designated UA recipients through corresponding delivery slots. When
mail
+
+is to be delivered to a UA on another host, it is transferred
first to another
+
+MTA on the recipient user's host, which in turn puts the mail item through
+
+its local delivery slot. In this model, a Mail Transfer System
(MTS) may
+
+be viewed as a collection of MTAs with network connections among them to
+
+provide Mail Transfer Services for a large number of users on
different host
+
+computers.
+
+ Replicating this UA/MTA/MTS model on a personal micro-computer
+
+(PC) is not an easy task. Aspects of PCs that make support of
this model
+
+difficult include limited storage capacities, limited processing
capabilities,
+
+and the fact that PCs are geared to support a single user rather than several
+
+users at once. A PC with limited secondary diskette storage and
limited
+________________________________________________
+ 1 UNIX is a Trademark of Bell Laboratories, Inc.
+ 2 CP/M is a Trademark of Digital Research, Inc.
+ 3 MS-DOS is a Trademark of Microsoft Corporation.
+
+
+
+ 1
+
+
+
+
+processing capacity (often single-thread) is not well suited to support the
full
+
+range of automatic interactions between a UA and an MTA, or the necessary
+
+interactions between MTAs in an MTS. For example, we do not see any way
+
+to certify PC systems for authentication of posted mail. A PC can
change
+
+its entire character and behavior with insertion of a new program
diskette,
+
+suggesting that it is the operating system diskettes and their users that must
+
+be certified, rather than the computers. Review of certification issues shows
+
+that it is not the computer, but its operators and managers that
must be
+
+certified, and this involves the notions of central management and
control.
+
+All this is lost in the maze of PCs that we see proliferating on
and off our
+
+campuses, in and out of our offices and homes.
+
+ Thus, we see a need for a new arrangement with the UA separated from
+
+its MTA, and using communication protocols to interact with it in
ways
+
+that resemble MTA-to-MTA interactions. The UA is placed on the PC end,
+
+while the more complex tasks performed by the MTA are relegated to
the
+
+remote host end. The remote MTA must authenticate mail items offered by
+
+the PC-based UA, just as it would for a co-located UA, but the task is more
+
+difficult because the PC UA is potentially anyone among the public telephone
+
+connectable population. This can be handled with password systems,
but
+
+recognition and identification are not the only services to be provided at the
+
+posting slot. Posting also requires some validation of recipient
addresses,
+
+and validation of the syntax and semantics of certain header fields. Example
+
+standards are provided by the U.S. National Bureau of Standards (NBS) and
+
+the U.S. DoD ARPANET for the format of mail to be transferred [8 , 9 , 10 ].
+
+ The new arrangement described in this paper might be called a split mail
+
+slot in that the UA side of the slot is split away from the MTA side. Although
+
+the UA and MTA may be on opposite ends of a telephone connection,
they
+
+must still act together as a single processing unit to move mail
from one
+
+to the other, with all that this may entail. This gives rise to
a number of
+
+new MTA/UA requirements such as error control for service requests,
user
+
+intervention to select items for delivery, and user postponement or rejection
+
+of delivery without triggering failure notices to senders. These are not
serious
+
+problems when both MTA and UA are programs running on a single
host.
+
+For example, with both UA and MTA on the same host, unwanted junk mail
+
+is simply deleted at low cost, compared to the cost of deletion
after a long
+
+delivery transmission time. Better that our PC users be able to discard items
+
+without delivery transmission.
+
+
+
+ 2
+
+
+
+
+Overview of the MZnet Environment
+
+
+The MZnet project is an undergraduate student effort sponsored within the
+
+Information and Computer Science (ICS) Department of the University of
+
+California at Irvine (UCI) in Southern California. For the past 2
years, the
+
+UCI mail network, known as ZOTnet, has been connected into the Computer
+
+Science Network (CSnet) and in 1984, has joined the DoD ARPA
Internet
+
+with a Split-Gateway connection [11 ] to the University of Southern California
+
+Information Sciences Institute (USC-ISI). The MZnet split-slot arrangement
+
+may have some similarities to the Split-Slot Internet Gateway at
least in
+
+name, but the problems and the implementations are quite different.
+
+ The UCI ZOTnet environment [13 ] gives the MZnet project a full-fledged
+
+Internet-class mail system as its foundation. The MZnet project objective is
+
+to extend this class of mail service to personal computers located in student
+
+and faculty residences, offices and laboratories, without waiting for
full-blown
+
+local area networking to first provide connections. This follows a pattern of
+
+making the most of existing facilities to provide a reasonable level of
service.
+
+ The UCI ZOTnet uses the CSnet-provided MMDF (Multi-channel Memo
+
+Distribution Facility) software [12 ] from the University of Delaware to
inter-
+
+connect two VAX 750 Unix systems with two DEC TOPS-20 systems through
+
+a port selector, with dial telephone connection to a CSnet relay
[14 ]. The
+
+ZOTnet has since evolved into an ethernet-connected local area network with
+
+the aforementioned gateway connection into the DoD Internet. The ZOTnet
+
+also connects to USENET with the UUCP protocols, and provides format
+
+transformations for mail flowing between protocol domains [15 , 16 ]. Adding
+
+to the reach of the ZOTnet with MZnet is a natural part of its evolution4 .
+
+ To this point we have set the context of the MZnet project. The
remainder
+
+of this paper is devoted to relatively technical discussions of implementation
+
+of the PC user agent programs and the split-slot UA/MTA interface.
+________________________________________________
+ 4 For those who are properly curious about such things, the name
"ZOTnet" derives
+
+from the cry of the UCI mascot which is the Anteater from the
B.C. comic strip, and
+MZnet is simply a contraction for Micro-ZOTnet.
+
+
+
+ 3
+
+
+
+
+The MZnet User Agent: CP/MH
+
+
+CP/MH is a collection of programs designed to work in conjunction
with
+
+the Micro ZOTnet (MZnet) as an extension of the UCI ZOTnet. CP/MH
+
+programs permit a user of a CP/M 2.2-based microcomputer to send and re-
+
+ceive ZOTnet mail messages, as well as to manipulate them locally on floppy
+
+disks. The CP/MH programs are written in the C programming language
+
+and should be portable to similar operating environments, such as MS-DOS,
+
+etc.
+
+ CP/MH is based on the UCI version of the Rand MH message
handling
+
+system [17 ] for the Unix operating system. The major philosophical
dif-
+
+ferences between CP/MH and typical user agents such as MSG [4 ] and
its
+
+descendants are those of modularity and of user interface. In CP/MH
(as
+
+in MH) the user does not invoke a single monolithic program to
deal with
+
+mail, but rather invokes individual, non-interactive programs with
common
+
+knowledge of the way messages are stored. Each program has default behav-
+
+ior which can be modified by using Unix-style command line options at time
+
+of invocation or through a user profile. Help messages can also be
evoked
+
+from CP/MH programs.
+
+
+
+Messages and Folders
+
+
+The format of a CP/MH message adheres more or less to the syntax described
+
+in RFC 822 in which a message consists of headers containing
information
+
+pertaining to the message source and destination, and the message
body,
+
+separated from the headers by a blank line. An example of such a
message
+
+might be:
+
+
+
+ Date: 02 Nov 83 23:04:53 PST (Wed)
+
+ To: Toto <address@hidden>
+
+ From: The Great And Powerful Oz <address@hidden>
+
+ Subject: What Be Your Excuse?
+
+
+
+ What's the matter? I ask you for a simple thing like
+
+ "distribute this to address@hidden," and you can't do it.
+
+ You undergrads will do anything to get out of work!
+
+
+
+ 4
+
+
+
+
+ --ozzie
+
+
+ Following the MH convention, each message is kept in a
separate file.
+
+Since a message is simply ASCII text, it can be operated upon by
non-
+
+CP/MH programs (such as text editors, in particular).
+
+ Collections of messages are called folders. Under CP/MH,
folders are
+
+represented by several files: an info file, containing maintenance information
+
+about the folder, and a set of message files with the same name
as the info
+
+file, but with unique numeric suffixes (extensions in CP/M parlance).
An
+
+example of this naming scheme might be:
+
+
+DRAFT the info file for the DRAFT folder
+
+
+DRAFT.001 message 1 in the folder
+
+
+DRAFT.002 message 2 in the folder
+
+
+DRAFT.003 message 3 in the folder
+
+
+ The number of messages that may be stored in a folder is limited
primarily
+
+by the storage capacity of a floppy disk, but also by the
three-digit limit of
+
+a CP/M extension.
+
+ The info file contains a field named CURRENT: specifying the current mes-
+
+sage number. The current message number signifies the default message
+
+operated upon by CP/MH commands using a particular folder. The current
+
+message number may be modified by some commands. An example of the
+
+contents of the info file DRAFT might be
+
+
+ CURRENT: 3
+
+
+ This indicates that the file DRAFT.003 would be operated upon
when
+
+default conditions apply (i.e. when no message number is explicitly given to
+
+a CP/MH command).
+
+ Possible future uses for the info file include named message sequences (a
+
+set of messages to which commands may be applied as a whole) and
user
+
+profile information for application to particular folders (there is
presently a
+
+single user profile, described shortly).
+
+ A floppy diskette may contain more than one folder, but
folders do not
+
+extend over more than one floppy diskette; therefore two different
diskettes
+
+may contain folders with the same name.
+
+
+
+ 5
+
+
+
+
+CP/MH Commands
+
+
+Commands operating on messages can be divided into several general
cate-
+
+gories:
+
+
+
+Transporting: sending, receiving
+
+
+Viewing: selecting for display, showing header summaries
+
+
+Creating: composing, replying, forwarding
+
+
+Archiving: categorizing, refiling, deleting, sorting
+
+
+
+ The architecture of CP/MH permits the simulation of some of these cat-
+
+egories using standard CP/M commands when CP/MH, in its present prim-
+
+itive state, does not cover them.
+
+ A minimal functionality is presently provided by the following four com-
+
+mands:
+
+
+
+COMP composes mail items: creates a file containing header
information
+
+ taken from a standard or user-specified template. This
newly-created
+
+ file may be edited to fill in the header fields and body.
+
+
+REPL replies to mail items: creates a file containing header
information
+
+ appropriate for answering a given mail item. This
newly-created file
+
+ may be edited to change header fields and fill in the body.
+
+
+SEND sends mail items: posts selected items through the split-slot
from a
+
+ draft folder.
+
+
+INC receives mail items: takes delivery of selected items across
the split-
+
+ slot, incorporating them into a mailbox folder.
+
+
+
+These commands, with a few enhancements and modifications appropriate
+
+to the CP/M environment, are functionally almost identical to their
Unix
+
+MH counterparts.
+
+ CP/MH commands are invoked like any other CP/M commands such as
+
+ED, PIP, or DIR. Command line options are generally preceded by a
dash
+
+(e.g. -editor A:ED), and may be abbreviated. Folder names are
preceded
+
+
+
+ 6
+
+
+
+
+by a plus (e.g. +B:DRAFT). Messages are identified by numbers or
by the
+
+special names first, last, current, next, and previous.
+
+ An example of use of a CP/MH command is:
+
+
+
+ comp -edit a:ed -use last +b:draft -log
+
+
+
+ This particular example will edit the last-composed message (the
-use
+
+last option) in the folder DRAFT on disk drive B: (the +b:draft
option),
+
+using the standard CP/M editor ED on disk drive A: (the -edit a:ed
op-
+
+tion), and prompting the user when it is appropriate to change
disks (the
+
+-log option).
+
+ All CP/MH commands have a -help option which displays all
available
+
+options for the particular command invoked. Another common option is
+
+-log which permits the user to change (relog) diskettes after
invoking a
+
+command, for purposes of selecting diskettes with message folders or
with
+
+editor programs. This is particularly useful on single-drive systems
or on
+
+systems with diskettes of low storage capacity.
+
+
+
+The Profile
+
+
+If there are options commonly used with a particular CP/MH command,
+
+they may be entered in the user profile contained in the file called (naturally
+
+enough) PROFILE, which must exist on the same diskette on which
CP/MH
+
+commands reside and from which the commands are invoked. A profile entry
+
+consists of a program name followed by a colon and the options to
be used
+
+with that program, for example:
+
+
+
+ comp: -editor A:VEDIT +B:outbox -log
+
+ repl: -editor A:VEDIT -log
+
+ send: +B:outbox
+
+ inc: +B:inbox -log
+
+
+
+ Individual profile components are overridden by options given at the time
+
+of invocation (e.g. -noedit given on the command line will override
the
+
+-editor profile component for a particular command).
+
+
+
+ 7
+
+
+
+
+The MZnet Split-Slot Mail Transfer System
+
+
+The MZnet split-slot software implements a peer-to-peer communication pro-
+
+tocol between a time-sharing host's MTA and a personal micro-computer
+
+(PC) UA. This MZnet protocol extends the UA/MTA/UA model of computer-
+
+based message systems (CBMS) to provide a split gateway function between
+
+individual PCs and the ZOTnet similar to the UCI ICS split Internet gateway
+
+described previously (see Figure 2).
+
+
+
+The Structure of the Split-Slot
+
+
+The MZnet Split Gateway consists of three distributed processing
compo-
+
+nents:
+
+
+
+ - A PC running a UA (in MZnet, CP/MH) acting as the mail server.
+
+
+ - A mini/mainframe host running a full MTA (MMDF in MZnet)
pro-
+
+ viding mail relay services.
+
+
+ - A communication protocol (a modified version of MMDF PhoneNet)
+
+ to connect the two ends of the split-slot.
+
+
+
+Although this combination may not be unique, the method by which the
+
+MZnet split-slot bonds these parts together uniquely deals with the
prob-
+
+lems of remote user agents. In addition to overcoming limited
storage and
+
+processing capacities, remote user agents must deal with noisy modem lines,
+
+mail software certification, and mail system security problems. The
MZnet
+
+architecture appears to solve these problems with a clean mail
interface for
+
+PCs.
+
+
+
+The MZnet Mail Server
+
+
+The split-slot mail server consists of a set of command packet programs run
+
+from the PC. These programs simply present commands through the Phone-
+
+Net communication protocol to the mail relay slave program on the
host.
+
+Some basic commands are:
+
+
+
+PostMail posts mail drafts to MTA
+
+
+
+ 8
+
+
+
+
+GetMail accepts mail from MTA
+
+
+RemoteScan displays information about waiting mail
+
+
+Quit drops connection between PC and Host
+
+
+
+ Each command has the form:
+
+
+
+ Command Request
+
+ Data Transmission
+
+ Command Termination
+
+
+
+ For example, the PostMail command is a small program that:
+
+
+
+ - initiates a command with the Mail Slave by sending the command name
+
+ (PostMail) encoded within a PhoneNet packet;
+
+
+ - sends a series of PhoneNet packets that contain pieces of the mail
item
+
+ to be posted;
+
+
+ - finally sends a command termination signal to end the transaction
with-
+
+ out terminating the connection between host and PC.
+
+
+
+The MZnet Channel To MMDF
+
+
+The MZnet Channel runs on the MTA host under the University of Delaware's
+
+MMDF (Version 1) and is responsible for both delivery of received
mail to
+
+MZnet users, and posting of MZnet user-originated mail. The MMDF MZnet
+
+channel maintains a unique message queue for each registered MZnet
user.
+
+As new mail items arrive, they are posted to the appropriate queues, where
+
+MZnet holds the mail items for pickup by their registered recipients.
+
+ To send or receive mail, the MZnet user must attach to the host, log into
+
+the public MZnet account, and identify (authenticate) himself. During
the
+
+MZnet session with the host, the user has access only to that
restricted set
+
+of functions provided by the MZnet split gateway protocol: he may
request
+
+delivery of queued mail with GetMail, or post new mail with PostMail. Prior
+
+to taking delivery of queued mail, a survey of waiting mail also
may be
+
+
+
+ 9
+
+
+
+
+requested with RemoteScan to obtain message size information (among other
+
+data) to allow intelligent disposition of mail in the queue.
+
+ Hidden within these activities are issues of security and certification.
To
+
+certify and establish the identity of the user, a second password is requested
+
+after logging into the public MZnet account. This certification
procedure
+
+allows MZnet to certify the source of originated mail. A relatively
secure
+
+environment is provided by MZnet, as it is the only interface to
the host
+
+permitted to MZnet users (once beyond the public login procedure),
and it
+
+offers only the severely restricted set of PhoneNet-encoded commands. Aside
+
+from security issues, using a single account to handle all MZnet users reduces
+
+demands on system resources.
+
+
+
+The MZnet-PhoneNet Protocol
+
+
+A unique facet of the MZnet system derives from the PhoneNet File Transfer
+
+Protocol (FTP). PhoneNet FTP is a simple error-checked packet protocol
+
+which transfers ASCII plaintext. PhoneNet encodes any non-plaintext char-
+
+acter (or any other character "forbidden" by the idiosyncrasies of
the com-
+
+municating systems) by mapping it onto an "accepted" character set.
The
+
+accepted character set mapping is determined by a "negotiating" session be-
+
+tween the two systems at the start of the PhoneNet session.
+
+ MZnet transfers all information (both commands and data) in PhoneNet
+
+packets to obtain error control. The MZnet-PhoneNet command FTP toler-
+
+ates noise with a high degree of success, and in effect, connects both ends of
+
+the Split Slot together with a reliable set of virtual wires.
+
+
+
+MZnet Session Example
+
+
+Here, a typical MZnet session is presented, with the UA commands
issued
+
+from the PC side of the connection printed in a typewriter
typeface, and
+
+the responses from the host side printed in an italic typeface.
PhoneNet
+
+interactions are indented. The initial connection to the host is accomplished
+
+with the term program, which provides a simple terminal emulation function.
+
+The prompt of the PC for a UA command is "Ai". Note that passwords are
+
+never echoed by the host system.
+
+
+
+ Ai term
+
+
+
+ 10
+
+
+
+
+ login: mznet
+
+ password:
+
+ MZ-Password:
+
+ PhoneNet packet negotiation
+
+ Connected.
+
+ exit terminal mode
+
+ Ai send cur
+
+ PostMail command
+
+ message text packet transmission
+
+ command terminator
+
+ Ai quit
+
+ Quit command
+
+ Disconnecting.
+
+
+
+Conclusions
+
+
+The main conclusions of this paper are that small personal computer systems
+
+with dial-up phone connections constrain User Agent systems design in ways
+
+that require use of a split-slot interface between the UA and its
supporting
+
+Mail Transfer Agent (MTA), and that this interface will best provide the re-
+
+quired services if it has error controlled command and data transfer
facilities,
+
+with interactive behavior.
+
+ It is also believed that a good design for the small PC UA
is based on
+
+a very modular architecture, such as the Rand MH system, which has
been
+
+used as a pattern for the MZnet UA.
+
+ By bringing these concepts together, we expect MZnet to provide reliable
+
+UA/MTA service to a distributed set of small personal computers, to match
+
+the quality of service that is normally only available from larger
mainframe
+
+host systems with co-resident UA/MTA pairs.
+
+
+
+References
+
+
+ [1] SRI-NIC, ARPANET Directory, Network Information Center, SRI In-
+
+ ternational, Menlo Park, California (November 1980).
+
+
+
+ 11
+
+
+
+
+ [2] Comer, D., A Computer Science Research Network CSNET: A History
+
+ and Status Report, Communications of the ACM, volume 26, number 10
+
+ (October 1983) 747-753.
+
+
+ [3] Emerson, S. L., USENET: A Bulletin Board for Unix Users. BYTE,
+
+ volume 8, number 10 (October 1983) 219-236.
+
+
+ [4] Vittal, J., MSG: A Simple Message System, in: Uhlig (editor), Proceed-
+
+ ings of the IFIP TC-6 International Symposium on Computer
Message
+
+ Systems (North-Holland, April 1981).
+
+
+ [5] Deutsch, D., Design of a Message Format Standard, in: Uhlig
(editor),
+
+ Proceedings of the IFIP TC-6 International Symposium on Computer
+
+ Message Systems (North-Holland, April 1981).
+
+
+ [6] v.Bochmann, G. and Pickens, J. R., A Methodology for the
Specifica-
+
+ tion of a Message Transport System, in: Uhlig (editor),
Proceedings of
+
+ the IFIP TC-6 International Symposium on Computer Message Systems
+
+ (North-Holland, April 1981).
+
+
+ [7] Kerr, I. H., Interconnection of Electronic Mail Systems, in:
Uhlig (edi-
+
+ tor), Proceedings of the IFIP TC-6 International Symposium on
Com-
+
+ puter Message Systems (North-Holland, April 1981).
+
+
+ [8] Crocker, D., Standard for the Format of ARPA Internet Text
Messages
+
+ (RFC 822) Network Information Center, SRI International, Menlo Park,
+
+ California (August 1982).
+
+
+ [9] NBS, Message Format for Computer-Based Message Systems, U.S. Na-
+
+ tional Bureau of Standards FIPS Publication 98 (March 1983).
+
+
+[10] CCITT Study Group VII/5, Draft Recommendation X.MHS1: Mes-
+
+ sage Handling Systems: System Model_Service Elements (version
2),
+
+ Technical Report, International Telegraph and Telephone
Consultative
+
+ Committee (CCITT) (December 1982).
+
+
+[11] Rose, M., Low Tech Connections into the ARPA Internet: The
Raw-
+
+ Packet Split-Gateway, University of California Irvine Techical
Report
+
+ number 216 (February 1984).
+
+
+
+ 12
+
+
+
+
+[12] Crocker, D., Szurkowski, E., Farber, D. J., An Internet Memo Distribu-
+
+ tion Facility_MMDF, Proceedings of the Sixth IEEE Data Communi-
+
+ cations Symposium (November 1979).
+
+
+[13] Rose, M., The ZOTnet_A Local Area Mailing Network, University
of
+
+ California Irvine Technical Report number 200 (January 1983).
+
+
+[14] CSNET-CIC, Focus on the University of California, Irvine, CSNET
+
+ News 2, Bolt, Beranek, and Newman, Cambridge, Massachusetts (Octo-
+
+ ber 1983).
+
+
+[15] Rose, M., Achieving Interoperability Between Two
Domains_
+
+ Connecting the ZOTnet and UUCP Computer Mail Networks, University
+
+ of California Irvine Technical Report number 201 (January 1983).
+
+
+[16] Rose, M., Proposed Standard for Message Munging (RFC 886), Network
+
+ Information Center, SRI International, Menlo Park, California (Decem-
+
+ ber 1983).
+
+
+[17] Borden, B. S., Gaines, R. S., and Shapiro, N.Z., The Rand MH Message
+
+ Handling System: User's Manual (Rand Corporation, March 1983).
+
+
+
+ 13
+
+
+
+
+________________________________________________________________________________________________________________________
+
+Any Host Relay Host
Any Other Host
+
+
+
+ user
user
+
+
+
+ UA
UA
+
+
+
+ slot
slot
+
+
+
+ MTA MTA MTA
MTA
+
+
+
+PhoneNet PhoneNet PhoneNet
PhoneNet
+
+
+
+ modem modem modem
modem
+
+
+
+_______________________________________Figure_1:__The_MHS_Model_________________________________________________________
+
+
+
+ 14
+
+
+
+
+________________________________________________________________________________________________________________________
+
+Any Host MZnet Host
PC
+
+
+
+ user
user
+
+
+
+ UA
UA
+
+
+
+ slot
split slot
+ MZnet
MZnet
+
+
+
+ MTA MTA
+
+
+
+PhoneNet PhoneNet PhoneNet
PhoneNet
+
+
+
+ modem modem modem
modem
+
+
+
+____________________________________Figure_2:__The_Split-Slot_Model_____________________________________________________
+
+
+
+ 15
diff --git a/docs/historical/realwork.pdf b/docs/historical/realwork.pdf
new file mode 100644
index 0000000..4c56b91
Binary files /dev/null and b/docs/historical/realwork.pdf differ
diff --git a/docs/historical/realwork.txt b/docs/historical/realwork.txt
new file mode 100644
index 0000000..4e69868
--- /dev/null
+++ b/docs/historical/realwork.txt
@@ -0,0 +1,2445 @@
+
+
+
+
+ MH.5:
+
+ How to process 200 messages a day
+
+ and still get some real work done./
+
+
+ Marshall T. Rose
+
+ Member, Research Technical Staff
+
+ Northrop Research and Technology Centery
+
+
+
+ John L. Romine
+
+ Computing Support Group
+
+ Department of Information and Computer Science
+
+ University of California, Irvinez
+
+
+
+ Abstract
+
+
+ The UCI version of the Rand Message Handling System (MH) is
dis-
+
+ cussed. MH is a powerful user agent which operates in the ARPA
Internet
+
+ and UUCP environments. In addition to the usual functions provided
+
+ by similar programs, MH has several distinguishing characteristics
which
+
+ give the user additional message handling capability. In particular,
MH
+
+ provides mechanisms for maintaining an organized mail
environment,
+
+ tailoring its behavior, and extending its functions.
+
+
+ This document describes MH from several perspectives. Particular em-
+
+ phasis is given to: the MH user environment, advanced features of MH
+
+ which have proven to be particularly useful for sophisticated
users of
+
+ electronic mail, the user interface issues in MH, and the mh.5
distribu-
+
+ tion. The paper concludes with a summary of the authors' experiences
+
+ with MH, and a discussion of future areas of enhancement.
+
+
+
+_____________________________________
+./ Alternate title: MH: Your Key to Success.
+y One Research Park, Palos Verdes Peninsula, CA 90274. Telephone: 213/377-4811.
+
+Computer mail: MRose% address@hidden, : : :!fucbvax!ucivax,trwrbg!nrtc!mrose.
+z University of California at Irvine, Irvine, CA 92717. Telephone:
714/856-6852.
+
+Computer mail: address@hidden, : : :!fucbvax,trwrbg!ucivax!jromine.
+
+
+ MH.5:
+
+ How to process 200 messages a day
+
+ and still get some real work done
+
+
+
+Introduction
+
+ The UCI version of the Rand Message Handling System, MH, is a software
+
+system that performs two functions: first_, it interfaces a user to
a message
+
+transport system, so the user may receive and send mail; second___, it permits
the
+
+user to maintain an organized mail environment to facilitate the composition of
+
+new messages and the reading of old messages. In short, while not responsible
for
+
+the delivery of messages, MH aids the user in handling mail.
+
+
+ MH was originally developed by the Rand Corporation, and
initially was
+
+proprietary software. The Department of Information and Computer
Science
+
+at University of California, Irvine, shortly after joining the
Computer Science
+
+Network (CSnet), acquired a copy of MH, and began additional development of
+
+the software. Since that time, the Rand Corporation has declared MH to be in
the
+
+public domain, and the UCI version of MH has passed through four major
releases.
+
+The current version, mh.5, is available from U.C. Irvine for a nominal
distribution
+
+fee, or may be retrieved from the University of Delaware via anonymous FTP.
+
+
+ Much credit must be given to the initial designers and implementors of
MH:
+
+Bruce Borden, Stockton Gaines, and Norman Shapiro. Although MH has suffered
+
+significant development at UCI since Rand's initial release, the
fundamental
+
+concepts of MH's environs have remained nearly unchanged. In
addition, the
+
+authors of the current release gratefully acknowledge the comments of the many
+
+sites which have run various releases of MH in the past. In particular, the
dozen
+
+or so beta test sites for mh.5 provided tremendous help in stabilizing the
current
+
+release.
+
+
+ MH runs on different versions of the UNIX1 operating system
(such as
+
+Berkeley 4.2bsd and various flavors of v7). In addition, MH
supports four
+
+different message transport interfaces: SendMail[EAllm83], the standard
mailer
+
+for 4.2bsd systems; MMDF[DCroc79] and MMDF-II[DKing84], the Multi-Channel
+
+Memo Distribution Facility developed by the University of Delaware which forms
+
+the software-backbone for CSnet[DCome83] mail relay service; SMTP, the ARPA
+
+Internet Simple Mail Transfer Protocol[SMTP]; and, a stand-alone delivery
system.
+
+
+
+_____________________________________
+1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ 1
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 2
+
+
+ This paper is organized in a straight-forward fashion:
Initially, the MH
+
+philosophy of mail handling is presented, along with a description
of the
+
+environment which the MH user is given to process mail. Following this,
certain
+
+advanced features of MH are discussed in more detail, such as facilities for
selecting
+
+messages, and "advanced" concepts in draft handling. In addition, user
interface
+
+issues in mail handling are addressed, and the merits of MH's approach is
critically
+
+examined. Next, the mh.5 distribution package is described. Finally, we
conclude
+
+by discussing the authors' experience with MH development and introducing areas
+
+where MH may be further developed.
+
+
+ Although familiarity with MH is not assumed on the part of
the reader,
+
+some knowledge of the UNIX operating system is useful. Appendix A gives a
short
+
+synopsis of the MH commands.
+
+
+
+The MH Philosophy
+
+ Although MH has many traits which tend to distinguish it from other
systems
+
+which handle mail, there is a single fundamental design decision which
influences
+
+the interface between MH and the user: MH differs from most other systems in
+
+that it is composed of many small programs instead of one very large one. This
+
+architecture gives MH much of its strength, since intermediate and advanced
users
+
+are able to take advantage of this flexibility.
+
+
+ The key to this flexibility is that the UNIX shell (usually the C
shell or the
+
+Bourne shell), is the user's interface to MH. This means that when handling
mail,
+
+the entire power of the shell is at the user's disposal, in addition to the
facilities
+
+which MH provides. Hence, the user may intersperse mail handling commands
+
+with other commands in an arbitrary fashion, making use of command handling
+
+capabilities which the user's shell provides.
+
+
+ Furthermore, rather than storing messages in a complicated data
structure
+
+within a monolithic file, each message in MH is a UNIX file, and each folder
(an
+
+object which holds groups of messages) in MH is a UNIX directory.
That is,
+
+the directory- and file-structure of UNIX is used directly. As a result, any
UNIX
+
+file-handling command can be applied to any message.
+
+
+ To the novice, this may not make much sense or may not seem important.
+
+However, as users of MH become more experienced, they find this
capability
+
+attractive. In addition, this approach is often quite pleasing to system
implemen-
+
+tors, because it minimizes the amount of coding to be performed,
and given a
+
+modular design, changes to the software system can be maintained easily. There
+
+are, however, performance penalties to be paid with this scheme. This issue
is
+
+considered later in the paper.
+
+
+ Having described how MH fits into the UNIX environment, we now discuss
+
+the mail handling environment which is available to the MH user.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 3
+
+
+The MH Environs
+
+ In the $ HOME directory of each MH user, a file named
.mh_profile contains
+
+static information about the user's MH environment, and default arguments for
+
+MH programs. For the latter case, each line of profile takes the form:
+
+
+ program-name: options
+
+
+Each MH program consults the user's .mh_profile for its options. These
options
+
+are consulted prior to evaluating any command-line arguments, and so provide
the
+
+MH user the capability to customize the defaults for each command. Futher, by
+
+using the UNIX link facility, different names can be given to the same command.
+
+Since each MH command looks in the .mh_profile for a component with the
name
+
+by which it was invoked, it's possible to have different defaults
for the same
+
+program. For example, it is not uncommon to link prompter (a simple prompting
+
+editor front-end) under the name rapid in the user's bin/ directory, and add
to the
+
+.mh_profile :
+
+
+ rapid: -prepend -rapid
+
+
+As a result, when prompter is invoked as rapid, it automatically uses the
`-prepend'
+
+and `-rapid' options.
+
+
+ The profile component ``Path:'' is the path to the user's
MH-directory,
+
+usually Mail. In addition to containing the user's folders, the MH-directory
also
+
+contains skeletons and templates used by the MH programs, and the user's
context
+
+file. This latter file has the same format as the user's .mh_profile , and
contains the
+
+dynamic, context-dependent information about the user's environment. Whenever
+
+MH looks for an MH-specific file, such as a template or skeleton, it first
consults
+
+the user's MH-directory, and then a system-wide library area.
+
+
+ The MH user always has a current folder, which is the folder in which
the user
+
+is currently (or was last) working. Since any MH program which deals with
folders
+
+implicitly manipulates this information, the name of the current folder is
stored in
+
+the context component ``Current-Folder:'' . Every folder has a
current message
+
+known as `cur' . These values are the defaults for MH commands which accept
+
+folder and/or messages arguments.
+
+
+ MH programs make use of a set of envariables which further customize
their
+
+behavior. The $ MH envariable, if present, specifies the name of an
alternate profile
+
+for the user. This allows a user of MH to easily maintain multiple
mail-handling
+
+environments.
+
+
+ In terms of command syntax, most MH commands accept an optional folder
+
+argument, such as `+outbox' . Unlike most UNIX commands, all MH commands
+
+have switches which are words, rather than single letters. Switches
may be
+
+abbreviated to the least unambiguous prefix. All MH commands also
support
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 4
+
_______________________________________________________________________________________________________________
+
+ 1 % inc
+ 2 Incorporating new mail into inbox...
+ 3
+ 4 1+ 03/16 Rand MH System MH transcript <<Here's the
body of a sample m
+ 5
+ 6 % show
+ 7 (Message inbox:1)
+ 8 To: address@hidden
+ 9 Subject: MH transcript
+10 Date: 16 Mar 85 18:28:59 PST (Sat)
+11 From: Rand MH System <address@hidden>
+12
+13 Here's the body of a sample message.
+14 % repl
+15 To: Rand MH System <address@hidden>
+16 cc: address@hidden
+17 Subject: Re: MH transcript
+18 In-reply-to: Your message of 16 Mar 85 18:28:59 PST (Sat).
+19 --------
+20 Thanks for the test.
+21
+22 /JLR
+23 ^D
+24
+25 What now? send
+26 % comp
+27 To: address@hidden
+28 cc:
+29 Subject: sample comp
+30 --------
+31 Here's a sample compose for the MH transcript.
+32
+33 /JLR
+34 ^D
+35
+36 What now? send -verbose
+37 -- Posting for All Recipients --
+38 -- Local Recipients --
+39 MRose: address ok
+40 -- Recipient Copies Posted --
+41 Message Processed
+
+
+ Figure 1
+
+
_____________________________________________An_MH_Session_____________________________________________________
+
+
+
+ a `-help' switch, which lists the syntax of the command along
with available
+
+ switches, and the version number of the command. Most MH commands also take
+
+ a `msg' or `msgs' argument which takes the form of a message number
(``1'' ), a
+
+ message range (``1-2'' ), a standard sequence name (``cur'' ), or a
user-defined
+
+ sequence name (``select'' ).
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 5
+
+
+An MH Transcript
+
+ Figure 1 contains a transcript of a simple MH session. First, inc is
run to
+
+incorporate the new mail into the user's ``+inbox'' folder.
+
+
+ A scan listing of the mail is printed while it is being
incorporated. (The
+
+user could run scan explicitly to generate additional scan listings later on.)
The
+
+scan listing gives the message number, followed by the date, message
sender,
+
+and subject. (If the message originated from the user generating the listing,
the
+
+``to:'' addressee is displayed instead of the sender.) If the subject is
short, the
+
+first part of the message body is displayed after the characters ``<<'' .
The plus
+
+sign (`+') after the message number indicates the current message.
+
+
+ The user show s the message, and decides to repl y. A reply draft is
created
+
+using the headers of the message being replied-to, using the default
replcomps
+
+template. The default editor, prompter, is called to edit the draft.
When an
+
+EOT is typed, prompter exits and the user is left at the What now? prompt.
The
+
+option send is chosen. Since there were no problems in posting the draft with
the
+
+message transport system, no additional output is produced. (MH is not verbose
+
+by default.)
+
+
+ The user then decides to compose a new message. The default
skeleton,
+
+components , is copied to the draft, and prompter is once again
called. After
+
+entering the addresses, subject, and body, the user then send s the draft
from the
+
+What now? prompt, using ``send -verbose'' , which causes MH to
list out the
+
+message addresses as it submits them to the message transport system.
+
+
+
+Some MH Features
+
+ We now consider certain advanced features in MH. These features have
been
+
+chosen to demonstrate some useful capabilities available to the MH user.
+
+
+Message Sequences and Selection
+
+ MH has several built-in message sequence names, which may be
used
+
+anywhere a `msg' or `msgs' argument is expected. These are: `cur'
, `next' ,
+
+`prev' , `first' , `last' , and `all' . Message ranges may also
be specified. For
+
+example, `all' is actually `first-last' , and `+mh last:5'
references the last
+
+five messages in your `+mh' folder. A powerful capability of MH is the
ability to use
+
+not only the pre-defined message sequence names, but also arbitrary
user-defined
+
+message sequence names.
+
+
+ Although all MH programs recognize user-defined sequences when
appropriate,
+
+the pick and mark commands can create and modify user-defined message
+
+sequences. The mark command allows low-level manipulation of sequences, and is
+
+not particularly interesting in our discussion.
+
+
+ The pick command selects certain messages out of a folder. The
criteria used
+
+for selection may be a search string and/or a date range.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 6
+
+
+ Searching is performed on either a specific header in the
message (e.g.,
+
+``To:'' ), or anywhere within the message. By default, pick lists out the
message
+
+numbers that matched the selection criteria. Thus, pick is useful in
backquoted
+
+operations to the shell. For example, to scan all the messages in the current
folder
+
+from "frated", the MH user issues the command:
+
+
+ scan `pick -from frated`
+
+
+To perform more complicated message selection, user-defined sequences
are
+
+employed. Supplying a `-sequence name' argument to pick, will cause
it to define
+
+the sequence `name' as those messages matched.
+
+
+ Giving pick a list of messages causes it to limit its
search to just those
+
+messages. For example, to find all the messages in the current folder from
"frated"
+
+also dated before friday:
+
+
+ pick -from frated -sequence select
+
+ pick select -before friday -sequence select
+
+
+With the first pick command, the sequence ``select'' is defined to be
all those
+
+messages from "frated". In the second command, only those messages already in
+
+the ``select'' sequence are searched, and the ``select'' sequence
is redefined
+
+to be only those messages which are also dated before friday. Those messages
could
+
+then be show n with:
+
+
+ show select
+
+
+When a `-sequence name' argument is given to pick, the
default behavior _
+
+listing the message numbers matched _ is inhibited. To re-enable this
behavior,
+
+the `-list' option may be given. As a result, advanced users of MH often
put the
+
+following line in their .mh_profile :
+
+
+ pick: -sequence select -list
+
+
+which allows them to easily make use of the `select' sequence as the
messages
+
+last selected with pick.
+
+
+ Often it is desirable to act upon those messages which are not members
of
+
+a given sequence. For this purpose, the ``Sequence-Negation:''
profile entry
+
+is useful. If the name of a user-defined sequence is prefixed with the value
of the
+
+sequence-negation profile entry, MH commands will operate upon those messages
+
+which are not members of that sequence. For example, given a profile entry of:
+
+
+ Sequence-Negation: not
+
+
+those messages which are not in the `select' sequence could be scan'd
with:
+
+
+ scan notselect
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 7
+
+
+ Obviously, some confusion could result if an attempt was made to
define a se-
+
+quence name which began with the sequence-negation string (e.g., ``notselect''
).
+
+For this reason, MH users will often use a single character, which their shell
doesn't
+
+interpret, as their sequence-negation string (e.g., up-caret (`^') for C Shell
users,
+
+and exclamation-mark (`!') for Bourne shell users).
+
+
+ MH also provides a way of automatically remembering the last message
list
+
+given to an MH command. This facility is implemented by using a profile entry
+
+called ``Previous-Sequence:'' .
+
+
+Draft Handling
+
+ After the initial edit of a message draft, the comp, dist,
forw, and repl
+
+programs give the user a What now? prompt. The valid responses include:
edit to
+
+re-edit the draft, quit to exit without sending the draft, send to send the
draft, and
+
+push to send the draft in the background.
+
+
+ When the send option is given, the draft is posted with the message
transport
+
+system. If there problems posting the draft, the What now? prompt is
re-issued, so
+
+errors in the draft may be corrected.
+
+
+ Since posting the draft can be slow, the push option allows the MH
user to
+
+send the draft in the background, and return immediately to the shell. If
there are
+
+problems posting the message, the user will not see the diagnostics produced by
+
+the message transport system. For this reason, if push is used instead of
send, and
+
+the message is not successfully posted, MH mails a message to the user
containing
+
+any diagnostics which the message transport system produced along with a copy
+
+of the message. Later, the draft may be re-edited by entering ``comp -use''
.
+
+
+ A relatively new feature of MH is the ability to use a folder to store
multiple
+
+drafts. These drafts are kept in an ordinary MH folder, and may be operated
upon
+
+by MH commands. To enable this feature, the MH user selects a folder-name for
+
+the draft-folder, and creates an entry in the .mh_profile :
+
+
+ Draft-Folder: +foldername
+
+
+From this point on, when a message is composed, the draft will be created as a
+
+message in that folder, instead of using the draft file in the user's MH
directory.
+
+Unfortunately, if posting problems occur on a message which has been push'd, it
+
+may be difficult to re-edit the draft with ``comp -use'' . This might
be the case
+
+if the user had started composing another message, while that first draft was
being
+
+posted. In that event, the current-message in the draft-folder would
no longer
+
+point to the failed draft.
+
+
+ There is a solution for this problem, however. By default, push
assumes the
+
+`-forward' option, which says that if the message draft fails
to be posted, it
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 8
+
+
+should be forwarded back to the user in the error report which push generates.
+
+The failed draft may then be extracted with the burst program (discussed
later).
+
+
+BBoards
+
+ MH has a convenient interface to the UCI BBoards facility[MRose84a].2
This
+
+facility permits the efficient distribution of interest group messages
on a single
+
+host, to a group of hosts under a single administration, and to the ARPA
Internet
+
+community.
+
+
+ Although most readers are probably familiar with the concept of an
interest
+
+group in the Internet context, a brief description is now given. Observant
readers
+
+will notice that the distributed nature of the "network news" (a.k.a. USENET)
+
+tends to avoid many of the problems described below.
+
+
+ Described simply, an interest group is composed of a number of
subscribers
+
+with a common interest. These subscribers post mail to a single address, known
+
+as the distribution address (e.g., address@hidden From this distribution
address,
+
+a copy of the message is sent to each subscriber. Each group has a moderator,
+
+who is the person that runs the group. This moderator can usually be reached
at
+
+a special address, known as the request address (e.g., address@hidden).
+
+Usually, the responsibilities of the moderator are quite simple,
since the mail
+
+system handles distribution to subscribers automatically. In some interest
groups,
+
+instead of each separate message being distributed directly to subscribers, a
batch
+
+of (hopefully related) messages are put into a digest format by the moderator
and
+
+then sent to the subscribers. (This is similar to a newsletter format.)
Although
+
+this requires more work on the part of the moderator and introduces delays,
such
+
+groups tend to be better organized.
+
+
+ Unfortunately, some problems arise with the scheme outlined above.
First,
+
+if two users on the same host subscribe to the same interest group, two copies
of
+
+the message are delivered. This is wasteful of both processor and disk
resources at
+
+that host.
+
+
+ Second, some groups carry a lot of traffic. Although subscription to
a group
+
+does indicate interest on the part of a subscriber, it is usually not
interesting to get
+
+50 or so messages delivered each day to the user's private maildrop,
interspersed
+
+with personal mail, which is likely to be of a much more important and timely
+
+nature.
+
+
+ Third, if a subscriber's address in a distribution list becomes "bad"
somehow
+
+and causes failed mail to be returned, the originator of the message is
normally
+
+notified. It is not uncommon for a large list to have several bogus
addresses. This
+
+results in the originator being flooded with "error messages" from mailers
across
+
+
+_____________________________________
+2 The UCI BBoards facility can run under either the MMDF or SendMail, or in a
more restricted
+
+form under stand-alone MH.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 9
+
+
+the Internet stating that a given address on the list was bad. Needless to
say, the
+
+originator usually does not care if the bogus addresses got a copy of the
message
+
+or not. The originator is merely interested in posting a message to the group
at
+
+large. On the other hand, the moderator of the group does care if there are
bogus
+
+addresses on the list, but ironically does not receive notification.
+
+
+ To solve these problems, the UCI BBoards facility introduces a new
entity
+
+into the picture: a distribution channel. All interest group mail is handled
by the
+
+special mail system component. The distribution address for an interest-group
+
+maps mail for that interest-group to the distribution channel, which then
performs
+
+several actions. First, if local delivery is to be performed, a copy of the
message is
+
+placed in a global maildrop for the interest group with a timestamp and a
unique
+
+number. Local users can read messages posted for the interest group by reading
+
+this "public" maildrop. Second, if further distribution is to take place, a
copy of
+
+the message is sent to the distribution address in such a way that if any of
the
+
+addresses are bogus, failure notices will be returned to the local maintainer
of the
+
+group address list, rather than the originator of the message.
+
+
+ This scheme has several advantages: First, messages delivered to the
local
+
+host are processed and saved once in a globally accessible area. The UCI
BBoards
+
+facility supports software which allows a user to query an interest group for
new
+
+messages and to read and process those messages in the MH-style. Second, once
+
+a host administrator subscribes to an interest group, each user may join or
quit
+
+the list's readership without contacting anyone. Third, a hierarchical
distribution
+
+scheme can be constructed to reduce the amount of delivery effort. Finally,
errors
+
+are prevented from propagating. When an address on the distribution list goes
+
+bad, the list moderator who is responsible for the address is notified. If a
local
+
+moderator does not exist, then the local PostMaster is notified (not the
global
+
+group moderator).
+
+
+ In addition to solving the problems outlined above, the UCI BBoards
facility
+
+supports several other capabilities. BBoards may be automatically archived in
+
+order to conserve disk space and reduce processing time when reading
current
+
+items. Also, the archives can be separately maintained on tape for
access by
+
+interested researchers.
+
+
+ Special alias files may be generated which allow the MH user
to shorten
+
+address entry. For example, instead of sending to address@hidden, a user of
+
+MH usually sends to ``SF-Lovers'' and the MH aliasing facility
automatically
+
+makes the appropriate expansion in the headers of the outgoing message. Hence,
+
+the user need only know the name of an interest group and not its global
network
+
+address.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 10
+
+
+ Finally, the UCI BBoards facility supports private interest groups
using the
+
+UNIX group access mechanism. This allows a group of people on the
same or
+
+different machines to conduct a private discussion.
+
+
+ The practical upshot of all this is that the UCI BBoards facility
automates the
+
+vast majority of BBoards handling from the point of view of both the PostMaster
+
+and the user.
+
+
+ MH provides three programs to deal with interest groups. The bbc
program
+
+is used to check on the status of one or more groups, and to optionally start
an
+
+MH shell on those groups which the user is interested in. The bbl program can
be
+
+used to manually perform maintenance on a discussion group beyond the normal
+
+automatic capabilities of the UCI BBoards facility. Finally, the msh
program
+
+implements an MH shell for reading BBoards, in which nearly all of
the MH
+
+commands are implemented in a single program.
+
+
+ Observant readers may note that the use of msh is contrary
to the MH
+
+philosophy of using relatively small, single-purpose programs. Sadly, the
authors
+
+admit that this is true. In an effort to minimize use of system resources
however,
+
+BBoards are kept in maildrop format instead of folders.3 Some research has
gone
+
+into overcoming this problem to restore MH's purity of purpose, but all
solutions
+
+proposed to date are either unworkable or require significant
recoding of MH's
+
+internals.
+
+
+Bursting
+
+ Internet interest group mail is often sent out in digest form. The
experienced
+
+MH user may wish to deal with the digest messages on an individual basis,
however.
+
+The burst program allows the MH user to extract these digest messages, and
store
+
+each as an individual MH message.
+
+
+ Burst will also extract forwarded messages generated by forw (or the
forwarded
+
+message in the error report generated by push, as described above).
Although
+
+burst cannot always decapsulate messages encapsulated by sites not running MH,
+
+it adheres to the proposed standard described in [MRose85b].
+
+
+
+_____________________________________
+3 When the message transport system delivers a message to a user it stores it
in a single file, called
+
+a maildrop. Since many messages may be present in a single maildrop, (in
theory) there is a unique
+string acting as a separator between messages in the maildrop. Although this
is convenient for
+storage of messages, it makes retrieval more difficult unless a separate index
into the maildrop is
+kept. This latter approach is taken by the msg program available with MMDF-II
and by msh as well.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 11
+
+
+Distributed Mail
+
+ The ARPA Internet community consists of many types of
heterogeneous
+
+nodes. Some hosts are large mainframe computers, others are personal
work-
+
+stations. All communicate using the milstd TCP/IP protocol suite[IP,
TCP].
+
+Messages which conform to the Standard for the Format of ARPA Internet Text
+
+Messages[DCroc82] are exchanged using the Simple Mail Transfer Protocol[SMTP].
+
+
+ On smaller nodes in the ARPA Internet, it is often impractical to
maintain
+
+a message transport system (e.g., SendMail). For example, a workstation may
not
+
+have sufficient resources (cycles, disk space) in order to permit an SMTP
server
+
+and associated local mail delivery system to be kept resident and continuously
+
+running. Furthermore, the workstation could be off-net for extended periods of
+
+time. Similarly, it may be expensive (or impossible) to keep a personal
computer
+
+interconnected to an IP-style network for long periods of time. In other
words, the
+
+node is lacking the resource known as "connectivity".
+
+
+ Despite this, it is often desirable to be able to manage
mail with MH on
+
+these smaller nodes, and they often support a user agent to aid the tasks of
mail
+
+handling. To solve this problem, a network node which can support a message
+
+transport entity (known as service host) offers a maildrop service
to these less
+
+endowed nodes (known as client hosts). The Post Office Protocol[JReyn84] (POP)
+
+is intended to permit a workstation to dynamically access a maildrop on a
service
+
+host to pick-up mail.4 The level of access includes the ability to determine
the
+
+number of messages in the maildrop and the size of each message, as well as to
+
+retrieve and delete individual messages. More sophisticated implementations
of the
+
+POP server are able to distinguish between the header and body portion of each
+
+message, and send n lines of a message to the POP client. This capability is
useful
+
+in thinly connected environments where conservation of bandwidth is important.
+
+By utilizing a more intelligent POP client, a user may generate "scan
listings" and
+
+decide dynamically which messages are worth taking delivery on. The philosophy
+
+of the POP is to put intelligence in the POP clients and not the POP servers.
+
+
+ The current release of MH supports the above model fully. A POP client
+
+program is available to retrieve a maildrop from a POP service host. In
addition,
+
+using the SMTP configuration for delivery in MH (either in
conjunction with
+
+SendMail or the MMDF), a user is able to specify a search-list of
service hosts
+
+(and/or networks) to try to post mail. Using this search-list, when an MH user
+
+posts a draft, the post program will attempt to establish an SMTP connection
+
+with each host in the search-list to post the message until it
succeeds. Initial
+
+
+_____________________________________
+4 Actually, there are three different descriptions of the POP. The first,
cited in [JReyn84], was the
+
+original description of the protocol, which suffered from certain problems.
Since then, two alternate
+descriptions have been developed. The official revision of the POP[MButl85],
and the revision of the
+POP which MH uses (which is documented in an internal memorandum in the MH
release). This
+paper considers the POP in the context of the MH release.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 12
+
+
+experimentation using the POP and MH in a local network environment
has
+
+proved quite successful.
+
+
+
+User Interface Issues in MH
+
+ At this point, it is perhaps useful to take a step backwards and
examine the
+
+success and problems of MH's approach to user interfaces.
+
+
+Creeping Featurism
+
+ A complaint often heard about systems which undergo substantial
develop-
+
+ment by many people over a number of years, is that more and more options are
+
+introduced which add little to the functionality but greatly increase the
amount of
+
+information a user needs to know in order to get useful work done. This is
usually
+
+referred to as creeping featurism.
+
+
+ Unfortunately MH, having undergone six years of off-and-on development
by
+
+ten or so well-meaning programmers (the present authors included), suffers
mightily
+
+from this. For example, the send command has twenty-five visible switches,
and at
+
+least nine hidden switches, for a total of thirty-four. The poor user who
types
+
+
+ send -help
+
+
+watches the options scroll off the screen (since the `-help' switch also
lists out
+
+four other lines of information).5 The sad part is that all of these
switches are
+
+useful in one form or another.
+
+
+ There are a lot of good things to be said for the "one program, one
function"
+
+philosophy of system design. In the MH case, however, each program really does
+
+only one mail handling activity (with a few minor exceptions). The
options
+
+associated with each command are present to modify the program's behavior to
+
+perform similar, but slightly different tasks. In further defense of MH, note
that
+
+there are 32 MH commands at present, all performing different tasks.
+
+
+ The problem with creeping featurism though, is that while the
functionality
+
+of the system increases sub-linearly, the complexity of the system increases
linearly.
+
+That is, although the number of switches that a program takes might double, it
is
+
+unlikely that the program's functionality or capabilities will double.
+
+
+
+_____________________________________
+5 Recently, this was fixed by compressing the way in which switches are
presented. The solution is
+
+only temporary however, as send will no doubt acquire an endless number of
switches in the years
+to come.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 13
+_______________________________________________________________________________________________________________
+
+To:
+cc:
+Bcc:
+Fcc: outbox
+Fcc:
+Subject:
+Reply-To:
+--------
+
+
+ Figure 2
+
+______________________________________________Draft_Skeleton___________________________________________________
+
+_______________________________________________________________________________________________________________
+
+To: <reply-to_from>
+cc: <?to_cc><to>,<cc>
+Fcc: +outbox
+Fcc: <?fcc><fcc>
+Subject: <?subject>Re: <subject>
+In-reply-to: <?date><?message-id>Your message of <date>.
+ <message-id>
+In-reply-to: <?date><!message-id>Your message of <date>.
+--------
+
+
+ Figure 3
+
+_____________________________________________Reply_Template____________________________________________________
+
+
+
+Templates versus Switches
+
+ One way to trim the explosion of available options, while
still increasing
+
+functionality, is to introduce options with a richer domain. Hence, instead
of using
+
+options which take on or off forms or simple numeric or string values, the
possible
+
+values which an option might take on is given a large space. There are
several ways
+
+that this might be accomplished.
+
+
+ The comp, dist, and forw programs use draft skeletons (simple form
fill-in
+
+files) to construct the general format of the draft being composed. An
example of
+
+a draft skeleton used for composing new messages (by comp) is shown in Figure
2.
+
+The approach is to let the user specify (and later edit) both arbitrary
headers of
+
+draft and the body of the draft. Note while most of the fields are empty, the
first
+
+``Fcc:'' field already contains a value. By using the simple prompting
editor,
+
+prompter, the user can speedily enter the headers of the message. The prompter
+
+program given the skeleton in Figure 2 would prompt the user for the contents
+
+of each field, except for the second ``fcc:'' , which it would include
verbatim.
+
+It would then read the body of the message up to an end-of-file. Naturally,
the
+
+MH user is free to use any editor to edit any part of the draft (headers or
body).
+
+This example demonstrates the flexibility achieved by not limiting what
headers a
+
+draft may contain (which most mail sending programs do), while still retaining
the
+
+simplicity of being able to treat the entire message draft as a UNIX file.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 14
+_______________________________________________________________________________________________________________
+
+From: <?me>Message Agent "<<me>>
+To: <reply-to_from>
+Fcc: +rcvtrip
+Fcc: <?fcc><fcc>
+Subject: <?subject>BEEP! Re: <subject>
+Subject: <!subject>BEEP!
+In-reply-to: <?date><?message-id>Your message of <date>.
+ <message-id>
+In-reply-to: <?date><!message-id>Your message of <date>.
+--------
+
+
+ This is an automatic reply. Feel free to send additional
mail, as only
+ this one notice will be generated.
+
+
+ I am attending the USENIX Summer '85 conference in Portland,
Oregon.
+ I expect to be reading mail again on the 16th of June.
+
+
+/mtr
+
+
+ Figure 4
+
+__________________________________The_tripcomps______Reply_Template____________________________________________
+
+
+
+ Another more interesting approach is used by the repl
command, which
+
+constructs a draft in reply-to a previously received message. Instead of
adding
+
+switches to indicate which fields of the draft should be derived from the
message
+
+being replied-to, and how they should be derived, a single option, the ability
to
+
+specify a template, was made available. An example of a reply template is
shown
+
+in Figure 3. Put simply, based on the presence of certain fields in the
message
+
+being replied-to, and a few switches given by the user, using the reply
template,
+
+repl generates the reply draft automatically.
+
+
+ This facility, for example, can be used to generate automatic
replies.6 One
+
+function might be to write a rcvtrip shell script which
automatically answered
+
+messages when mail wasn't being read for a period of time (e.g., while
attending a
+
+conference). An example of a reply template at the heart of such a script is
shown
+
+in Figure 4.
+
+
+ Finally, another application might be to utilize the highly useful
letter bomb
+
+protocol.7 The important thing to note about this template is that it
generates
+
+not only the headers of the reply draft (with a creative ``Reply-to:''
address),
+
+but the body as well. Hence, the commands
+
+
+ repl -form bombcomps -noedit ; rmm
+
+
+_____________________________________
+6 MH supports the notion of a user-defined mail hook which is invoked each
time a user receives
+
+mail.
+7 The authors wish to credit Ron Natalie of the Ballistics Research
Laboratory in Aberdeen,
+
+Maryland for formalizing the use of this protocol in the ARPA Internet
community.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 15
+_______________________________________________________________________________________________________________
+
+To: <reply-to_from>
+cc: <?to_cc><to>,<cc>
+Fcc: +outbox
+Fcc: <?fcc><fcc>
+Subject: <?subject>Re: <subject>
+In-reply-to: <?date><?message-id>Your message of <date>.
+ <message-id>
+In-reply-to: <?date><!message-id>Your message of <date>.
+Reply-To: /dev/null
+--------
+
+
+ "
+ *-XXX
+ / XX
+ X
+ X
+ X
+ X
+ X
+ IIIIIIIII
+ IIIIIIIII
+ IIIIIIIII
+ IIIIIIIII
+ XXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXXXXXXXXXXXXXXXX
+ XXXXXXXXX
+
+
+ Figure 5
+
+_________________________________The_bombcomps________Reply_Template___________________________________________
+
+
+
+ What now? push
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 16
+_______________________________________________________________________________________________________________
+
+width=80,length=0,overflowtext=,overflowoffset=10
+Date:leftadjust,compress,compwidth=9
+Subject:leftadjust,compress,compwidth=9
+From:leftadjust,compress,compwidth=9
+To:leftadjust,compress,compwidth=9
+cc:leftadjust,compress,compwidth=9
+Resent-Note:leftadjust,compwidth=9
+:
+body:nocomponent,overflowoffset=0
+
+
+ Figure 6
+
+____________________________________________Display_Template___________________________________________________
+
+
+
+are very handy for dealing with disturbing mail in a straight-forward manner.
Of
+
+course, repl could be linked to bomb in the user's bin/ directory and an
appropriate
+
+line could be added to the user's MH profile, in order to further shorten
type-in.
+
+
+ A variation on the reply template is the display template. A display
template,
+
+as used by the mhl program, contains instructions on how to format a message.
In
+
+addition to being used by show, et. al., the forw program can also use a
display
+
+template to format each message being forwarded. Similarly, although repl
uses a
+
+reply template to construct the draft being composed, it also may use a display
+
+template to format the body of the message being replied-to for enclosure in
the
+
+reply. Furthermore, the post program may use a display template to format the
+
+body of a blind-carbon-copy. An example of a display template used for
formatting
+
+forwarded messages is shown in Figure 6.
+
+
+ As with reply templates, display templates can offer a lot of
functionality.
+
+For example, the one line display template:
+
+
+ body:nocomponent,overflowtext=,overflowoffset=0,width=10000
+
+
+can be used to extract the body of a message, while ignoring the headers.
Hence,
+
+if a shar archive arrived in the mail, a convenient way to unpack it, assuming
the
+
+above display template was called mhl.body , would be:
+
+
+ show -form mhl.body _ sh
+
+
+
+ The biggest win with display templates, of course, is that all those
annoying
+
+header lines which mailers everywhere generate can be simply and easily
filtered
+
+out.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 17
+
+
+Modularity versus Monolithicity
+
+ Since MH is a set of programs which perform separate tasks, as opposed
to
+
+being a single, monolithic program, the power of the shell is used directly to
aid in
+
+mail-handling. One powerful capability which this design achieves is the
ability to
+
+extend the MH command set, by developing shell scripts which use the standard
+
+MH programs to accomplish complicated or specialized tasks.
+
+
+ For example, in the MH distribution there is a shell script
called mpick
+
+(shown in Figure 7) which tries to locate all the messages which pertain to a
given
+
+discussion, by looking at the ``Message-ID:'' and ``In-reply-to:''
headers,
+
+to find matching message-ids.8
+
+
+ Unfortunately, some parts of MH are somewhat monolithic. An example of
+
+this is the What now? prompt. There are only a few options at this prompt,
and
+
+one cannot give a normal shell command. Some MH users seem to feel that more
+
+options should be added to the What now? prompt, such as an insert-file
option. It
+
+was argued that just about any editor would allow you to insert a file, and
another
+
+What now? option was not needed. These users persisted, however, so the
problem
+
+was solved, by writing a trivial shell script "editor" (see Figure 8) which
could be
+
+invoked by the edit option:
+
+
+ What now? edit append filename
+
+
+
+ A better interface at this point is really needed, however. One
possibility is to
+
+simply pass any unrecognized commands on to a shell for interpretation,
supplying
+
+the path name of the draft file as an argument. A solution which
shows more
+
+promise is to give you a sub-shell instead of the What now? prompt, and
setup
+
+certain envariables so that the MH commands would act upon the draft by
default.
+
+For example, show with no `msgs' arguments would show the draft instead of
the
+
+current message. This alternative has recently been implemented and is under
+
+testing.
+
+
+
+The MH Distribution
+
+ The mh.5 distribution is now briefly described, both in terms
of static
+
+configuration methods and dynamic tailoring. Appendix B describes the
mechanics
+
+of receiving an mh.5 distribution.
+
+
+
+_____________________________________
+8 Note that the shell scripts included in the MH distribution are written for
the Bourne shell, and
+
+have a `:' as the first character of the first line, so they will be portable
to all versions of UNIX, not
+just those which support the Berkeley `# !' enhancement.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 18
+_______________________________________________________________________________________________________________
+
+: 'mpick - relate messages /mtr'
+PATH=:/bin:/usr/bin:/usr/ucb:/usr/local:/usr/local/lib/mh; export PATH
+F="" M="" S=""
+
+
+for A in $*
+do
+ case $A in
+ -*) S="$S $A" ;;
+
+
+ address@hidden) case $F in
+ "") F=$A ;;
+ *) echo "mpick: only one folder at a
time" 1>&2
+ exit 1 ;;
+ esac ;;
+
+
+ *) M="$M $A" ;;
+ esac
+done
+
+
+S="$S -sequence hits -list -nozero"
+
+
+if mark $F all -add -sequence hits;
+ then mark $F all -delete -sequence hits;
+ else exit 1;
+fi
+
+
+for A in $-M-cur"
+do
+ for C in `mhpath $F $A`
+ do
+ if [ -r $C ];
+ then
+ I=`mhl -form mhl.msgid $C`;
+ case $I in
+ "") echo "no message-id in message `basename
$C`" 1>&2 ;;
+ *) pick --in-reply-to "$I" $S ;;
+ esac
+ else
+ echo "message $A doesn't exist" 1>&2; exit 1;
+ fi
+ done
+done
+
+
+exit 0
+
+
+ Figure 7
+
+____________________________________________The_mpick_Script___________________________________________________
+
+
+
+Configurable MH
+
+ The MH distribution currently runs on a large number of
different UNIX
+
+versions, ranging from MicroSoft XENIX to Berkeley 4.2bsd. All the code which
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 19
+_______________________________________________________________________________________________________________
+
+: 'append - stupid append editor for MH - /jlr'
+case $# in
+ 1_2) case $# in
+ 1) F=$1; echo -n "Append file: " 1>&2; read A ;;
+ 2) F=$2; A=$1 ;;
+ esac
+ cat $A < /dev/null >> $F ;;
+ *) echo "append: arg count" 1>&2 ; exit 1 ;;
+esac
+exit
+
+
+ Figure 8
+
+___________________________________________The_append_Editor___________________________________________________
+
+_______________________________________________________________________________________________________________
+
+bin /usr/local
+bboards on
+editor /usr/local/prompter
+etc /usr/local/lib/mh
+mail /usr/spool/mail
+manuals local
+mts sendmail/smtp
+news off
+options BSD42
+options MHE NETWORK
+options UCI
+
+
+ Figure 9
+
+___________________________________Sample_MH_Configuration_File________________________________________________
+
+
+
+is specific to a particular target environment is enabled via the
C-preprocessor
+
+``# ifdef'' mechanism, so compilation under different versions of UNIX
is trivial.
+
+There are, however, a large number of compile-time options which may vary from
+
+site to site, so an automated configuration method was needed.
+
+
+ The MH-installer must create a configuration file, which contains a
list of
+
+the compile-time options and the values which are desired for them.
Compile-time
+
+options include the installation location for MH, what kind of message
transport
+
+system is to be used, and the default editor for the installation. An example
of
+
+such a configuration file is shown in Figure 9.
+
+
+ After creating this file (several examples are included in the
distribution), the
+
+installer runs the mhconfig program, which customizes the Makefile s and
some of
+
+the programs, for that site's particular installation. No hand-editing of any
source
+
+code should be necessary, under normal circumstances.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 20
+_______________________________________________________________________________________________________________
+
+mmdfldir: /usr/spool/mail
+mmdflfil:
+mmdelim1: "001"001"001"001"n
+mmdelim2: "001"001"001"001"n
+mmailid: 0
+lockstyle: 0
+lockldir:
+
+
+hostable: /usr/local/lib/mh/hosts
+servers: localhost "01localnet
+
+
+ Figure 10
+
+_______________________________________Sample_MTS_Tailor_File__________________________________________________
+
+
+
+Interface to the Message Transport System
+
+ MH will run with a number of message transport systems, including
SendMail,
+
+MMDF-II, and a small stand-alone system. One flexible method of posting mail
+
+is through an SMTP connection. There are a couple of major wins in using this
+
+configuration: First, none of the MH programs need to know where the interface
+
+programs to the message transport system are located, which makes them easier
+
+to move between systems. Second, mail can be posted on relay hosts, and the
local
+
+host of an MH user may not need a message transport system at all (as alluded
to
+
+in the preceeding discussion on the POP).
+
+
+ Those parts of MH which interact with the local message transport agent
+
+read additional tailoring information when they start.9 This information
includes
+
+the location of standard and alternate maildrops, maildrop delimiter strings,
the
+
+locking directory and locking style, and other tailoring information
specific for
+
+the particular message transport system in use (e.g., the default server
search-list
+
+when mail is posted with the SMTP). In most cases, by using a tailor file,
each site
+
+running a similar MH configuration is able to simply transfer MH binaries
between
+
+hosts. An example of such a tailor file is shown in Figure 10.
+
+
+ A continuing question which is often raised is how
intelligent should user
+
+agents (like MH and UCB Mail ) be with respect to the environment in which they
+
+operate. At present, MH likes to determine the official hostnames for
addresses
+
+when posting mail. Many argue that this is improper or unnecessary behavior
+
+for a user agent, and that the local message transport agent should
handle
+
+these functions. Unfortunately, this implies that the message
transport agent
+
+should munge headers when mail is posted to remove local host aliases and only
+
+permit address fields with fully-qualified addresses. Sadly, neither SendMail
nor
+
+MMDF-II really gets this right (flames to /dev/null please). The
current MH
+
+maintainers believe that the resolution of host aliases to official names
should be
+
+a well-supported interface with the local message transport agent. However,
to
+
+_____________________________________
+9 This simple facility is based on a more extensive tailoring capability
found in MMDF-II.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 21
+
+
+provide equal time to those who hold opposite views, MH supports a
configuration
+
+option called ``DUMB'' which disables MH's attempts to resolve addresses
into
+
+fully-qualified strings.
+
+
+
+Concluding Remarks
+
+ While MH has undergone significant development since the original Rand
+
+release, the authors have tried to keep the fundamental concepts of MH
unchanged.
+
+The authors have continually had to battle against well-meaning MH users who
+
+wanted to make MH more like other (less powerful) user agents. More and more
+
+"features" were often suggested for MH, usually at the expense of
making MH
+
+less general, and more specific. In nearly all cases, the "features"
which these
+
+users wanted were already present in MH in a slightly different form, or could
be
+
+realized by simply writing a short shell script. A classic example is the
repeated
+
+requests by one user to have dist take a list of messages rather
than a single
+
+message and distribute each one of them in turn. A simple shell script which
called
+
+dist repeatedly, perhaps with "canned" arguments so the user typed in
addressing
+
+information only once, would easily meet this request.
+
+
+ A number of MH comands have a large number of options. When adding
+
+options, the authors have tried to make the options general, while still
accomodating
+
+the requests of specific users. An example of a specific request
which was
+
+implemented as a general feature is the ``Previous-Sequence''
profile entry
+
+(mentioned above). If you use this profile entry, every MH command is forced
to
+
+write out context changes, making every command somewhat slower. Since
only a
+
+few users wanted this capability, it was implemented in such a way that users
who
+
+didn't want it, didn't have to pay the cost of slowing down every MH command.
+
+
+ MH has a powerful tailoring capability provided by the .mh_profile
. Using
+
+profile entries, users may customize their own environment without affecting
others.
+
+Novice users often take advantage of the MH-tailoring capabilities to try to
make
+
+MH work similarly to other user agents they've used. This has the advantage of
+
+allowing them to quickly begin using MH to handle their mail. However, since
these
+
+novice users don't take advantange of all the capabilities of MH, they
frequently
+
+will complain about things they think can't be done with MH, or could be done
+
+"better" some other way. Fortunately, as these users become more experienced
+
+with both MH and UNIX, they can modify their environment to take
better
+
+advantage of all of MH's capabilities. Novice MH users who see features
lacking
+
+are encouraged to take a better look at what MH can do, instead of trying to
make
+
+MH into something it isn't. This may sound rather inflammatory, but it would
+
+really be a much nicer world for us all if users of software systems would
read the
+
+manual prior to asking questions.
+
+
+ For a moment, let's consider the evolution of one MH feature
which has
+
+proved itself to be very useful. As users began employing MH to
handle their
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 22
+
+
+mail, the number of messages that could be processed in a given amount of time
+
+increased greatly. As the volume of messages increased however, it became
clear
+
+that some MH operations were too slow, in particular the interaction
with the
+
+(slow) message transport system. To overcome this problem, the push option was
+
+added at the What now? prompt. Originally, this option was hidden from
novice
+
+users and did little more than send the message in the background: any output
+
+generated by the background send process would be printed asyncronously on the
+
+terminal. If a message failed posting with the message transport system, it
would
+
+simply be left in the draft file.
+
+
+ Gradually, other features were added to push. Since users wanted to
be able
+
+to send more than one draft at a time, push was changed to optionally rename
+
+the draft file before posting it. (This is what the hidden `-unique'
option does.)
+
+Having message transport system diagnostics written asyncronously on the user's
+
+terminal was annoying, so push was made to intercept these diagnostics, and
mail
+
+the user a report containing them. Although the diagnostic report mailed back
by
+
+push contains the name of the draft which failed, a useful added feature was
the
+
+ability to have push include the failed draft as well. Eventually, the
draft-folder
+
+mechanism was implemented to make handling multiple message drafts
much
+
+easier.
+
+
+TODO
+
+ There are, no doubt, a number of improvements which could be made to
MH.
+
+At the present time, what further development should MH suffer? Although not
+
+by any means inclusive, here's a list:
+
+
+ 1. Performance Enhancements
+
+ Hardware gets faster all the time, but people always
complain that
+
+ software is too slow. Owing to its user interface style, MH is
somewhat
+
+ slower than monolithic programs like UCB Mail. It would be
nice if MH
+
+ could be tuned or accelerated somehow.
+
+
+ 2. Port to System 5
+
+ MH runs on 4.2bsd UNIX and Version 7 variants. It
should not be
+
+ difficult to port MH to a SYS5 environment. This should
significantly
+
+ increase the number of hosts on which MH can run. The authors,
lacking
+
+ a SYS5 machine (and experience with SYS5) to perform the port,
are
+
+ actively seeking a System 5 guru to attempt this feat.
+
+
+ 3. Interface to the Network News
+
+ Not all sites that run MH are in the ARPA Internet, and as such
the
+
+ UCI BBoards facility may not be of much use to them. A good MH
+
+ interface to the network news would allow users on hosts with a
news
+
+ feed to employ the same interface for reading and sending both
mail
+
+ and news.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 23
+
+
+ 4. Programmed Instruction for Beginners
+
+ The complexity of MH is often intimidating to new users. It
would be
+
+ nice to develop a set of learn lessons for those users who don't
like man
+
+ pages and non-interactive tutorials.
+
+
+ 5. Message List Expansion
+
+ At present, when a list of messages is given to an MH
command, it
+
+ expands the list and processes each message in numerical order
rather
+
+ than the order in which the messages were given (e.g., ``show 2
1''
+
+ show s message 1 and then message 2). It would be nice if MH
processed
+
+ messages in the order they were given.
+
+
+ 6. Context Changes
+
+ In nearly all cases, an MH command does not write out context
changes
+
+ until it is about to exit successfully. There is some
controversy as to
+
+ whether this is the correct behavior in all cases. Some argue
that once
+
+ an MH command has fully parsed its argument list, the context
should
+
+ be updated.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 24
+
+
+ References
+
+
+
+[DCome83] D. Comer. The Computer Science Research Network
CSnet: A
+
+ History and Status Report. Communications of the ACM
26, 10
+
+ (October, 1983), 747-753.
+
+
+
+[DCroc79] D.H. Crocker, E.S. Szurkowski, D.J. Farber. An
Internetwork
+
+ Memo Distribution Facility _ MMDF. Appearing in
Proceedings,
+
+ Sixth Data Communications Symposium, Asilomar, 1979, pp.
18-25.
+
+
+
+[DCroc82] D.H. Crocker. Standard for the Format of ARPA
Internet Text
+
+ Messages. Request for Comments 822. ARPA Internet
Network
+
+ Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DKing84] D.P. Kingston, III. MMDFII: A Technical Review.
Appearing in
+
+ Proceedings Usenix Summer '84 Conference, Salt Lake
City, Utah,
+
+ 1984, pp. 32-41.
+
+
+
+[EAllm83] E. Allman. SENDMAIL _ An Internetwork Mail Router.
+
+ Britton-Lee, Inc., Berkeley, California (July, 1983).
+
+
+
+[IP] Internet Protocol. Request for Comments 791 (milstd
1777).
+
+ Appearing in Internet Protocol Transition Workbook, ARPA
Internet
+
+ Network Information Center (NIC), SRI International, 1981.
+
+
+
+[JReyn84] J.K. Reynolds. Post Office Protocol. Request for
Comments 918.
+
+ ARPA Internet Network Information Center (NIC), SRI
International
+
+ (October, 1984).
+
+
+
+[MButl85] M. Butler, J.B. Postel, et. al. Post Office Protocol -
Version 2.
+
+ Request for Comments 937. ARPA Internet Network
Information
+
+ Center (NIC), SRI International (February, 1985).
+
+
+
+[MRose84a] M.T. Rose. The Rand MH Message Handling System: The
UCI
+
+ BBoards Facility. Department of Computer and Information
Sciences,
+
+ University of Delaware (October, 1984).
+
+
+
+[MRose85b] M.T. Rose, E.A. Stefferud. Proposed Standard for
Message
+
+ Encapsulation. Request for Comments 934. ARPA Internet Network
+
+ Information Center (NIC), SRI International (January, 1985).
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 25
+
+
+[SMTP] Simple Mail Transfer Protocol. Request for Comments
821. ARPA
+
+ Internet Network Information Center (NIC), SRI
International
+
+ (August, 1982).
+
+
+
+[TCP] Transmission Control Protocol. Request for Comments 793
(milstd
+
+ 1778). Appearing in Internet Protocol Transition Workbook,
ARPA
+
+ Internet Network Information Center (NIC), SRI International,
1981.
+
+
+ Appendix A
+
+ MH Commands
+
+
+
+ MH is composed of several UNIX programs, which in theory are
fairly simple
+
+ and single-purposed. These commands are functionally grouped below:
+
+
+ Composing_Mail_________
+
+ comp: compose a message
+
+ A program to originate a message. Usually, a special prompting
editor front-
+
+ end, prompter, is used to fill-in a composition template with
the addressees
+
+ of the message, subject, and so forth.
+
+
+ dist : redistribute a message to additional addresses
+
+ A program that re-enters a message previously received by the
user into the
+
+ message transport system. Only new addresses are added; the
body of the
+
+ message is not changed in any way.
+
+
+ forw : forward messages
+
+ A program that encapsulates one or more messages in a new
message draft.
+
+ In addition, the user may add initial and/or closing comments.
+
+
+ repl : reply to a message
+
+ A program that constructs a reply to a message using a reply
template. The
+
+ template mechanism has sufficient generality to permit the user
to "program"
+
+ the form of the reply draft based on the contents of
the message being
+
+ replied-to.
+
+
+ send : send a message
+
+ A program that posts a draft with the message
transport system. The
+
+ send program is usually invoked by one of the four preceding
programs, and
+
+ performs simple front-end pre-processing prior to invoking the
post program.
+
+ For example, if invoked in push'd mode, send will
immediately relinquish
+
+ control of the user's terminal and post the message in the
background. If
+
+ the posting fails, send will send back a failure notice to the
user. If the user
+
+ had push'd the sending of the draft, then by default the draft
being sent is
+
+ encapsulated in the failure notice. This permits easy
burst'ing of the failure
+
+ notice to retrieve the original draft. Otherwise, if the
posting was successful,
+
+ the draft is marked as having been sent.
+
+
+whatnow : prompting front-end for send
+
+ A program which is called by comp, et. al., after the initial
draft has been
+
+
+
+ 26
+ Reprinted from Proceedings, Summer Usenix Conference and
Exhibition, Portland, Oregon, June, 1985 27
+
+
+ generated. The MH user can specify a different
whatnow program, which
+
+ yields considerable extensibility.
+
+
+ whom: report to whom a message would go
+
+ A program which examines the addresses of the draft and
expands all user-
+
+ defined aliases contained therein. Optionally, whom may
actually interact
+
+ with the message transport system to determine the
validity of the final
+
+ addresses. This program is also usually invoked by comp, et.
al.
+
+
+ Posting_Mail______
+
+ ali : list mail aliases
+
+ A simple front-end to the MH aliasing mechanism.
+
+
+ ap: parse addresses 822-style
+
+ A useful debugging tool for PostMasters who wish to
examine how MH
+
+ interprets an Internet address.
+
+
+ conflict : search for alias/password conflicts
+
+ Another program used by system administrators to check the
consistency of
+
+ MH alias files, and portions of the local message transport
agent.
+
+
+install-mh: initialize the MH environment
+
+ A program which is automatically executed the first time a
user issues an MH
+
+ command. This program performs once-only initialization of
the user's MH
+
+ environment.
+
+
+ mhmail : send or read mail
+
+ A simple program generally used by other programs to generate
messages.
+
+ The mhmail command is similar in purpose to the old BellMail
program.
+
+
+ post : deliver a message
+
+ A complex MH back-end that interacts with the local
message transport
+
+ agent to enter messages through the posting slot. (See the
description of send
+
+ above).
+
+
+ Reading_Mail_______
+
+ inc: incorporate new mail
+
+ A program that interacts with the local message transport
agent to retrieve
+
+ messages from the user's maildrop.
+
+
+ msgchk : check for waiting mail
+
+ A program which reports the status of mail waiting in the
user's maildrop.
+
+
+ show : show (list) messages
+
+ A program which lists messages to its standard output
(usually the user's
+
+ terminal), possibly invoking another program to do the actual
listing. Most
+
+ users of MH have show automatically call the mhl program to
format the
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 28
+
+
+ message. The next and prev programs are simply ``show
next'' and
+
+ ``show prev'' , respectively.
+
+
+ mhl : produce formatted listings of MH messages
+
+ A program which displays a message as directed by a template.
This permits
+
+ the user to filter out uninteresting headers and re-arrange other
headers to a
+
+ particular preference. In addition to being invoked by show, the
mhl program
+
+ is optionally also invoked by forw to format each message being
forwarded;
+
+ invoked by repl to format the body of a message being
replied-to, if that
+
+ message is being included in the reply draft; and, invoked by post
to format
+
+ a message being sent as a blind-carbon-copy.
+
+
+ rmm: remove messages
+
+ A program that removes messages from an MH folder, optionally
running a
+
+ user-defined program instead of deleting them. If no program is
given, the
+
+ messages are "softly" removed, so they may possibly be recovered
later.
+
+
+ scan: produce a one-line-per-message scan listing
+
+ A program that generates a scan listing for messages. Each line
of the listing
+
+ contains date, source, subject, and possibly the initial body of
the message.
+
+
+ Folder_Handling_______
+
+ folder : set/list current folder/message
+
+ A program used to list information concerning the current folder,
or set the
+
+ current folder and/or message.
+
+
+folders : list all folders
+
+ A program to list information on all folders (actually, just a
special case of
+
+ the folder command). Since the MH folder structure may be
recursive, the
+
+ user can indicate that folders should recursively examine all
folders.
+
+
+ refile: file message(s) in (an)other folder(s)
+
+ A program to move (or copy) messages from a source folder to one
or more
+
+ destination folders.
+
+
+ rmf : remove folder
+
+ A program that deletes a folder and all messages therein.
+
+
+ Message_Selection_______
+
+ anno: annotate messages
+
+ A program to arbitrarily annotate messages. If the user
so desires, after
+
+ distributing, forwarding, or replying-to a message, MH will
automatically
+
+ attach an annotation to the original message indicating the date
and addresses.
+
+
+ mark : mark messages
+
+ A program to manipulate user-defined sequences (lists of
messages). Usually,
+
+ mark is not employed directly by the MH user.
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 29
+
+
+ pick : select messages by content
+
+ A program to examine a list of messages and choose
those which meet
+
+ a particular selection criterion. The pick program is
often used in UNIX
+
+ back-quoted operations to pass message sequences to other MH
commands.
+
+
+ sortm: sort messages
+
+ A program to sort a list of messages according to the date given
in a particular
+
+ field.
+
+
+ Distribution_List_Handling__________
+
+ bbc: check on BBoards
+
+ A front-end to run msh on a list of distribution lists
which the user isn't
+
+ current on.
+
+
+ bbl : manage a BBoard
+
+ A (depreciated) program used to manually manage the local
archives of
+
+ a distribution list. These functions (archiving, expunging)
are performed
+
+ automatically by MH.
+
+
+ burst : explode digests into messages
+
+ A program used to decapsulate messages from ARPA Internet
digests. In
+
+ addition, messages which have been encapsulated during
forwarding (i.e.,
+
+ with forw ) can also be decapsulated using burst.10
+
+
+ msh: MH shell (and BBoard reader)
+
+ A monolithic program used to implement MH commands on
messages
+
+ arranged in a single file (maildrop format). Useful since
distribution lists are
+
+ kept in this format to minimize consumption of system resources.
+
+
+ pack : compress a folder into a single file
+
+ A program which takes messages stored in MH format and places
them in a
+
+ single file (using the same format known by msh).
+
+
+
Interface_to_the_UNIX_File_System_____________
+
+mhpath: print full pathnames of MH messages and folders
+
+ A program which maps MH-style names into the UNIX file naming
convention.
+
+
+
+ _____________________________________
+ 10 Similarly, blind-carbon-copies may be decapsulated, though only
socially mature users should do
+
+ so.
+
+
+ Appendix B
+
+ Distribution Mechanics
+
+
+
+ The mh.5 distribution is available in two forms:
+
+
+ 1. Anonymous FTP
+
+ If you can FTP to the ARPA Internet, use anonymous
FTP to the
+
+ ARPAnet host UDel-Huey [10.2.0.96] and retrieve the file
portal/mh.5-
+
+ tar. This is a tar image of size 2.1 MB (approximately).
+
+
+ 2. 9-track tape, 1600 bpi, tar format
+
+ Otherwise, you can send $ 50.00 to the address below. This
covers the
+
+ cost of a magtape, handling, and shipping. In addition,
you'll get a
+
+ laser-printed hard-copy of the MH documentation. The
documentation
+
+ includes installation guide, MH Tutorial, MH User's Manual,
changes
+
+ document (from mh.4 to mh.5), and BBoards Manual.
+
+
+ If you go with this option, be sure to include your USPS
address with
+
+ your check. Checks should be made payable to
+
+
+ Regents of the University of California
+
+
+ It's also a good idea (though not mandatory) to send a computer
mail
+
+ message to address@hidden when you send your check via USPS to
ensure
+
+ minimal turn-around time. The distribution address is:
+
+
+ Support Group
+
+ Attn: MH Distribution
+
+ Department of Information and Computer Science
+
+ University of California, Irvine
+
+ Irvine, CA 92717
+
+
+
+ 714/856-6852
+
+
+
+ Sadly, if you just want the hard-copies of the documentation,
you still
+
+ have to pay the $ 50.00. The tar image has the documentation
source
+
+ (the man is in ROFF format, but the rest are in TEX format).
+
+
+In addition, there is some hope that mh.5, or a successor, might be found
in a
+
+future 4.x Berkeley distribution.
+
+
+
+ 30
+ Reprinted from Proceedings, Summer Usenix Conference and Exhibition,
Portland, Oregon, June, 1985 31
+
+
+ Although MH is not "supported" per se, it does have a bug reporting
address.
+
+Normally, the address address@hidden is used to report bugs and bug fixes.
There are
+
+however, two discussion groups which concern themselves with MH:
+
+
+ 1. address@hidden
+
+ A discussion group for the MH user community at large.
Appropriate
+
+ topics include: questions about how to use MH, tips on MH
usage, and
+
+ exchange of MH shell scripts. All requests to be added to or
deleted
+
+ from this list, along with problems, questions and suggestions,
should
+
+ be sent to address@hidden
+
+
+ 2. address@hidden
+
+ A discussion group for MH maintainers and experts. Appropriate
topics
+
+ include: questions on how to configure MH, tips on MH
configuration,
+
+ exchange of MH bug reports (and fixes). All requests to be
added to or
+
+ deleted from this list, along with problems, questions and
suggestions,
+
+ should be sent to address@hidden
+
+
+The ``UCI'' host is also known as ``ucivax'' , so a possible UUCP
path might
+
+be : : :!ucbvax!ucivax!bug-mh.
+
+
+ Updates to MH are published on the MH-Workers list in the form of
context
+
+diffs, and the appropriate distribution images are updated as well.
+
+
+
+
+ Contents
+
+
+
+
Page
+
+Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 1
+
+The MH Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 2
+
+ The MH Environs . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 3
+
+ An MH Transcript. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 5
+
+Some MH Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 5
+
+ Message Sequences and Selection . . . . . . . . . . . . . . . . . . .
. . . . 5
+
+ Draft Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 7
+
+ BBoards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 8
+
+ Bursting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 10
+
+ Distributed Mail . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 11
+
+User Interface Issues in MH . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 12
+
+ Creeping Featurism . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 12
+
+ Templates versus Switches. . . . . . . . . . . . . . . . . . . . . . .
. . . . . 13
+
+ Modularity versus Monolithicity . . . . . . . . . . . . . . . . . . .
. . . . . 17
+
+The MH Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 17
+
+ Configurable MH . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 18
+
+ Interface to the Message Transport System . . . . . . . . . . . . . .
. . . 20
+
+Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 21
+
+ TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 22
+
+References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 24
+
+Appendix A: MH Commands . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 26
+
+Appendix B: Distribution Mechanics. . . . . . . . . . . . . . . . . . . . . .
. . . 30
+
+
+
+_____________________________________
+This document (version #1.43) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+ i
diff --git a/docs/historical/trusted.pdf b/docs/historical/trusted.pdf
new file mode 100644
index 0000000..3398763
Binary files /dev/null and b/docs/historical/trusted.pdf differ
diff --git a/docs/historical/trusted.txt b/docs/historical/trusted.txt
new file mode 100644
index 0000000..aea5b71
--- /dev/null
+++ b/docs/historical/trusted.txt
@@ -0,0 +1,2283 @@
+
+
+
+
+ Design of the TTI Prototype
+
+ Trusted Mail Agent
+
+
+ Marshall T. Rosey
+
+ David J. Farber
+
+ Stephen T. Walker
+
+
+
+ Abstract
+
+
+ The design of the TTI prototype Trusted Mail Agent (TMA)
+
+ is discussed. This agent interfaces between two entities: a
key
+
+ distribution center (KDC) and a user agent (UA). The
KDC
+
+ manages keys for the encryption of text messages, which two
+
+ subscribers to a key distribution service (KDS) may exchange.
+
+ The TMA is independent of any underlying message transport
+
+ system.
+
+
+ Subscribers to the KDC are known by unique identifiers,
+
+ known as IDs. In addition to distributing keys, the KDC also
+
+ offers a simple directory lookup service, in which the
"real-
+
+ world" name of a subscriber may be mapped to an ID, or the
+
+ inverse mapping may be performed.
+
+
+ This document details three software components: first_,
a
+
+ prototype key distribution service, which has been
running
+
+ in a TCP/IP environment since December, 1984;
second____, a
+
+ prototype trusted mail agent; and, third___, modifications to an
+
+ existing UA, the Rand MH Message Handling system, which
+
+ permit interaction with the prototype TMA.
+
+
+
+________________________________________
+y All three authors are with Trusted Technologies, Incorporated, POB 45,
Glenwood, MD 21738,
+
+USA. Telephone: 301/854-6889. In addition, Professor Farber is with the
University of Delaware.
+
+
+ Design of the TTI Prototype
+
+ Trusted Mail Agent
+
+
+
+Introduction
+
+ Initially, a brief model of a user community employing a trusted mail
service
+
+is introduced. Following this introduction, a prototype system is described
which
+
+attempts to meet the needs of a user community. Finally, open issues are
discussed,
+
+which are currently not satisfied by the prototype system or its model of
operation.
+
+
+ Two or more entities, called users, wish to communicate in a
secure
+
+environment. Depending on their available resources, different levels
of security
+
+are possible. At the extreme, two parties with substantial resources may wish
to
+
+communicate in a fashion which prevents any third parties, known as
adversaries,
+
+from observing their communication. At this level, not only is an
adversary
+
+unable to capture the communication for analysis, but in fact, the
adversary is
+
+unaware that any communication is occurring at all. In most
applications, this
+
+level of security is prohibitively expensive. A more economic method is to
translate
+
+messages into a form which is useless to an adversary and then to communicate
+
+those messages on an insecure medium.
+
+
+ This latter method requires the two users to have some sort of key with
which
+
+to "lock" the plaintext into ciphertext when transmitting, and then to
"unlock"
+
+the ciphertext back into useful form when receiving. Hence, there are two
central
+
+issues to deal with: first_, keys must be generated, distributed, and
maintained in
+
+a secure fashion; and, second____, the keys must be "intricate" enough so
that sense
+
+can't be made out of the ciphertext without knowledge of the key. The first
part
+
+is handled by a key distribution center (KDC), which maintains a
list of users
+
+and a set of keys for each pair of users. The second part relies on
sophisticated
+
+encryption and decryption algorithms. It is beyond the scope of this
paper to
+
+describe cryptographic techniques in detail. For a detailed survey of this
area, the
+
+reader should consult [VVoyd83].
+
+
+ In the context of our discussion (using the terminology of
[X.400]), the
+
+medium used to transport is supplied by a message transport system (MTS), which
+
+is composed of one or more message transport agents (MTAs). Usually, the
entire
+
+MTS is distributed in nature, and not under a single administrative
entity; in
+
+contrast, an MTA is usually controlled by a single administration and resides
in a
+
+particular domain. At every end-point in the medium, a user agent (UA) acts on
+
+behalf of a user and interfaces to a local MTA. This model is briefly
summarized in
+
+Figure 1.
+
+
+
+ Copyright fcl1985, IFIP TC-6
1
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 2
+______________________________________________________________________________________________________________________
+
+
+
+ UA
UA
+
+
+
+ POSTING
RECEIPT
+
+
+
+ MTS
+
+
+
+ MTA MTA : : :
: : : MTA
+
+ RELAYING
+
+
+
+ Figure 1
+
+_______________________________________________The_MTS_Model__________________________________________________________
+
+
+
+ A message, in our context, consists of two parts: the headers and the
body.
+
+The headers are rigorously structured; they contain addressing
information and
+
+other forms useful to a UA. The body is freely formatted and is
usually not
+
+meaningful to a UA.
+
+
+ When a message is sent from one user to another, the
following activities
+
+occur: The originating user indicates to the UA the address of the recipient;
the
+
+UA then posts the message through a posting slot to an MTA, which
involves
+
+a posting protocol in which the validity of the address and the
syntax of the
+
+message are considered. Upon successful completion of the protocol,
the MTA
+
+accepts responsibility for delivering the message, or if delivery fails, to
inform the
+
+originating user of the failure. The MTA then decides if it can deliver the
message
+
+directly to the recipient; if so, it delivers the message through a
delivery slot to
+
+the recipient's UA, using a delivery protocol. If not, it contacts an
adjacent MTA,
+
+closer to the recipient, and negotiates its transfer (using a protocol similar
to the
+
+posting protocol). This process repeats until an MTA is able to deliver the
message,
+
+or an MTA determines that the message can't be delivered. In this latter
case, a
+
+failure notice is sent to the originating user.
+
+
+ It is important to note that there are two mappings which occur here.
The
+
+first, which is performed implicitly by the originating user, maps the name of
the
+
+recipient into the recipient's address; the second, which is performed
explicitly by
+
+the MTS, maps the address of the recipient into a route to get from the
originator's
+
+MTA to the recipient's MTA. These mappings are depicted in Figure 2.
+
+
+ Obviously, there is no guarantee that the MTS can be made secure, in any
+
+sense of the word. This is particularly true if it is under several
administrations.
+
+Regardless of the number of administrations in the MTS, this problem
quickly
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 3
+______________________________________________________________________________________________________________________
+
+
+
+ user
user
+
+
+
+ name ! address
+
+
+
+ UA
UA
+
+
+
+ MTS
+ address ! route
+
+
+
+ MTA MTA : : :
: : : MTA
+
+
+
+ Figure 2
+
+______________________________________Mappings_in_the_MTS_model_______________________________________________________
+
+
+
+degenerates to a problem of Byzantine generals[LLamp82]. Further, trying to
secure
+
+each MTA in the path that a message travels is equally questionable.
+
+
+ To support secure communications in this environment, a new
entity, the
+
+trusted mail agent (TMA) is introduced into our model. A solution is to have
the
+
+UA interact with this entity both when posting a message and when taking
delivery
+
+of a message. The UA first contacts a TMA to encrypt the body of the message
for
+
+the recipient, prior to pushing it through the posting slot. Upon receipt
from the
+
+destination MTA, the UA examines the message and contacts the TMA to decipher
+
+the body of the message from the source. An overview of the relationship
between
+
+the standard MTS model and the augmentations made for the Trusted Mail1 system
+
+is shown in Figure 3.
+
+
+ To achieve these tasks, the TMA interacts with a key
distribution service
+
+(KDS), which manages keys between pairwise users. At this point, a third
mapping
+
+takes place: the UA must be able to map addresses into the identifier(s) by
which
+
+the originator and recipient are known by the TMA and KDS. These
identifiers
+
+are known as KDS IDs, or simply IDs. Usually, a fourth mapping
also occurs,
+
+________________________________________
+1 Trusted Mail is a trademark of Trusted Technologies, Incorporated.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 4
+______________________________________________________________________________________________________________________
+
+
+
+ UA TMA KDS
TMA UA
+
+
+
+ MTS
+
+
+
+ MTA MTA : : :
: : : MTA
+
+
+
+ Figure 3
+
+____________________________________Modifications_to_the_MTS_model____________________________________________________
+
+
+
+which maps the ID of a user into the name of a user. In our context, there is
an
+
+exact one-to-one mapping between the name of a user and the ID of that user.
In
+
+contrast, there may be a one-to-many mapping between the name of a user and
+
+that user's address in the MTS. Further, there are usually many different
routes
+
+which a message may traverse when going from an originating user to a recipient
+
+user.
+
+
+ The TMA is said to be trusted because it can be relied on to perform
only
+
+those actions specifically requested by the user. In the context of
this paper,
+
+this means, given proper construction and maintenance of the TMA,
that the
+
+software will communicate with the KDC in some secure fashion to negotiate key
+
+relationships and that it will not disclose those key relationships to other
parties.
+
+Furthermore, the body of mail messages exchanged between users which employ a
+
+trusted mail agent will be unintelligible to other parties. Finally, a
recipient of a
+
+message receives authenticated information from the trusted mail agent as to
the
+
+identify of the sender.
+
+
+ Hence, when each user employs a TMA, end-to-end encryption occurs at the
+
+UA level (to avoid any problems with malicious MTAs).2 Any adversary listening
+
+in on the MTS, may observe messages, but make no sense out of them (other than
+
+rudimentary traffic analysis). Note, however, that since the medium itself is
not
+
+secure, an adversary may still introduce new messages, corrupt messages, or
remove
+
+
+________________________________________
+2 Note that in the scope of this system, the end-points are the user agents,
not the hosts they reside
+
+on. In fact, it may very well be the case that the user agent and the local
message transport agent
+do not reside on the same host.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 5
+
+
+messages, as they traverse the MTS. In the first two cases, however, the
recipient
+
+would be suspicious because the adversary lacks the encrypting key employed by
+
+the source user. In the third case, the source user can retransmit the
message after
+
+a suitable time. Of course, there is no built-in retransmission policy _ this
aspect
+
+depends on the user's sending mail and is beyond the scope of the system.
+
+
+ It is important to understand the target community for the
Trusted Mail
+
+system described herein. In particular, the TMA is intended for a
commercial
+
+and not a military environment. This distinction is important, since
it is the
+
+fundamental assumption of this paper that the latter community has much
stricter
+
+requirements than the former. Because of this, the prototype system
is able to
+
+make certain simplifying assumptions which permit it to operate in a mode which
+
+is less secure than military applications would permit. Although these issues
are
+
+explored in greater detail at the end of the paper, for the moment recall
that, like
+
+most qualities, trustedness is not absolute: there are varying degrees of
trustedness,
+
+and as a system becomes more trusted, it becomes more expensive, in some sense,
+
+to operate and maintain.
+
+
+ It is perhaps instructive at this point to consider why the
introduction of a key
+
+distribution center is appropriate in this environment, and why the
fundamental
+
+assumption that trusted mail agents do not directly communicate with each other
+
+is necessary. Although a user agent is able to converse with the
local message
+
+transport agent in real-time, it is frequently not able to communicate with
other
+
+user agents in real-time. Furthermore, considering the vast problems and
overhead
+
+of trying to establish secure communications from "scratch" (a problem far
beyond
+
+the scope of this paper), it is would not be a good idea to try and communicate
+
+key relationships with other user agents, even if it were always possible to
do so.
+
+In addition, by separating the trusted aspects of the message
transport system
+
+from the system itself, many other advantages can be seen. These are
presented in
+
+greater detail at the end of the paper.
+
+
+ The discussion thus far has considered only a single recipient. In
practice, a
+
+user might wish to send to several others, using a different key for each.
Hence each
+
+copy of the message is encrypted differently, depending on the particular
recipient
+
+in question. Note that this has the effect of un-bundling message transfer in
the
+
+MTS, as advanced MTAs tend to keep only a single copy of the message for any
+
+number of recipients in order to save both cpu, disk, and I/O resources.
+
+
+ For example, in some existing mail systems, if a message was sent to n
users
+
+on a remote system, then the n addresses would be sent from the source MTA to
+
+the remote MTA along with one copy of the message. Upon delivery, the remote
+
+MTA would deliver a copy to each of the n recipients, but the virtual wire
between
+
+the source MTA and the recipient MTA was burdened with only one copy of the
+
+message. But in a secure environment, since a different key is used by the
source
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 6
+
+
+user when communicating with each of the n recipients, n different messages
will
+
+be posted with the local MTA, and the advantages of recipient bundling are
lost.
+
+
+ Along these lines however, private discussion groups may wish
to avoid
+
+this problem by establishing access to a single ID for their use.
In this case, a
+
+subscriber to the KDS may actually have more than one ID, one for
"personal"
+
+use and one for each discussion group. The appropriate ID is used when posting
+
+messages to the discussion group. Naturally the administrative policy for
deciding
+
+who is allowed to use the KDS ID of a discussion group is left to the moderator
+
+of the group. Observant readers will note that this vastly decreases
the aspect
+
+of secure communications for the discussion group. This method is
suggested
+
+as a compromise which permits the bundling of messages for multiple recipients
+
+to reduce MTS traffic. The price is high however, as a compromise
on behalf
+
+of any member of the discussion group compromises the entire group. For large
+
+discussion groups and a bandwidth limited MTS, this price may be worth paying.
+
+The prototype implementation of the TMA supports multiple recipients but not
+
+multiple KDS IDs.
+
+
+ Having described this environment for communication, the designs of a
KDS
+
+and TMA which form the heart of the TTI Trusted Mail system are
discussed.
+
+The prototype system was developed on a VAX3 -11/780 running 4.2bsd
UNIX4 .
+
+The system is based on the ansi draft[FIKM] for financial key management, but
+
+diverges somewhat in operation owing to the differences between the electronic
mail
+
+(CBMS) and electronic funds (EFT) environments. Note however that the ansi
+
+data encryption algorithm[DEA, FIPS46] is used in the current implementation.
A
+
+public-key cipher system was not considered as the basis for the prototype
since,
+
+to the authors' knowledge, an open standard for a public-key system has yet to
be
+
+adopted by the commercial community. In contrast, the ansi draft for
financial key
+
+management appears to be receiving wide support from the commercial community.
+
+
+ In the description that follows, a large number of acronyms are
employed to
+
+denote commonly used terms. In order to aid the reader, these are summarized
in
+
+Table 1.
+
+
+
+The Key Distribution Service
+
+ The prototype version of the KDS was designed to provide key
distribution
+
+services for user agents under both the same or different
administrations. As a
+
+result, the means by which a trusted mail agent connects to a key
distribution
+
+server is quite flexible. For example, the prototype system supports
connections
+
+via standard terminal lines, dial-ups (e.g., over a toll-free 800 number),
UNIX pipes,
+
+and over TCP sockets[IP, TCP]. In the interests of simplicity, for
the remainder
+
+of this paper, a TCP/IP model of communication is used. Initially, a server
on a
+
+________________________________________
+3 VAX is a trademark of Digital Equipment Corporation.
+4 UNIX is a trademark of AT&T Bell Laboratories.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 7
+______________________________________________________________________________________________________________________
+
______________________________________________________________________________________________
+
+
__Abbrev.________________________________Term_____________________________Context_______________
+
+ _ CBC _ Cipher Block Chaining
_ DES _
+ _ CBMS _ Computer Based Message System
_ _
+ _ CKD _ Key Distribution Center
_ EFT _
+ _ CKS _ Checksumming
_ DES _
+ _ CSM _ Cryptographic Service Message
_ _
+ _ DEA _ Data Encryption Algorithm
_ _
+ _ DES _ Data Encryption Standard
_ _
+ _ DSM _ Disconnect Service Message
_ MCL _
+ _ ECB _ Electronic Code Book
_ DES _
+ _ EFT _ Electronic Funds Transfer
_ _
+ _ IDK _ Key Identifier
_ CSM _
+ _ ID _ Identifier
_ KDS _
+ _ IP _ Internet Protocol
_ _
+ _ IV _ Initialization Vector
_ CSM _
+ _ KA _ Authentication Key
_ CSM _
+ _ KDC _ Key Distribution Center
_ CBMS _
+ _ KDS _ Key Distribution Server
_ CBMS _
+ _ KD _ Data-encrypting Key
_ CSM _
+ _ KK _ Key-encrypting Key
_ CSM _
+ _ MAC _ Message Authentication Code
_ CSM _
+ _ MCL _ Message Class
_ CSM _
+ _ MH _ The Rand Message Handling System
_ _
+ _ MIC _ Message Integrity Code
_ CSM _
+ _ MK _ Master Key
_ CSM _
+ _ MTA _ Message Transport Agent
_ CBMS _
+ _ MTS _ Message Transport System
_ CBMS _
+ _ ORG _ Message Originator
_ CSM _
+ _ RCV _ Message Receiver
_ CSM _
+ _ RIU _ Request Identified User
_ MCL _
+ _ RSI _ Request Service Initialization
_ MCL _
+ _ RUI _ Request User Identification
_ MCL _
+ _ TCP _ Transmission Control Protocol
_ _
+ _ TMA _ Trusted Mail Agent
_ CBMS _
+ _ TTI _ Trusted Technologies, Inc.
_ _
+
______UA___________User_Agent_______________________________________________CBMS____________
+
+
+ Table 1
+
+____________________________________Abbreviations_used_in_this_paper__________________________________________________
+
+
+
+well-known service host in the ARPA Internet community listens for connections
+
+on a well-known port.5 As each connection is established, it services one or
more
+
+transactions over the lifetime of the session. When all transactions for a
session
+
+have been made, the connection is closed. If the necessary locking operations
are
+
+performed by the server to avoid the usual database problems, then more than
one
+
+connection may be in progress simultaneously. Of course, a time-out facility
should
+
+________________________________________
+5 The term well known in this context means that the location of the service
is known a priori to
+
+the clients.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 8
+
+
+also be employed to prevent a rogue agent from monopolizing the key
distribution
+
+server.
+
+
+ Once a session has been started, the client (a.k.a. TMA) initiates
transactions
+
+with the server (a.k.a. KDS). Each transaction consists of the
exchange of two
+
+or three cryptographic service messages (CSMs): the client sends a
request,
+
+the server attempts to honor the request and sends a response, and,
if the
+
+server responded positively, the client then acknowledges the
transaction. By
+
+exchanging these cryptographic service messages, the KDS and the TMA are able
+
+to communicate key relationships. Obviously, the relationships themselves
must
+
+be transmitted in encrypted form.6 Hence, not only are key relationships
between
+
+two TMAs communicated, but key relationships between the KDS and the TMA
+
+are communicated as well.
+
+
+ This leads us to consider the key relationships that exist between a
TMA and
+
+the KDS. A client usually has three keys dedicated for use with the server.
The
+
+first is the master key (denoted MK), which has an infinite cryptoperiod,
and is
+
+rarely used. This key is distributed manually. The second is the
key-encrypting key
+
+(denoted KK), which has a shorter cryptoperiod. Whenever a KK is transmitted
+
+to the TMA, it is encrypted with the master key. The third is the
authentication
+
+key (denoted KA), which is used to authenticate transactions that do not
contain
+
+data keys (a count field is also used to avoid play-back attacks).
Whenever a
+
+KA is transmitted to the TMA, it is encrypted with the
key-encrypting key.
+
+When transactions contain keys, an associated count field is included to
indicate
+
+the number of keys encrypted with the key-encrypting key used.
Although not
+
+used by the prototype implementation, a production system would employ audit
+
+mechanisms to monitor usage histories.
+
+
+ Currently four types of requests are honored by the KDS: two key
relationship
+
+primitives, and two name service primitives. The type is indicated by the
message
+
+class (MCL) of the first cryptographic service message sent in the
transaction.
+
+As each message class is discussed, the appropriate datastructures
used by the
+
+KDS are introduced. Space considerations prevent a detailed
description of the
+
+information exchanged in each transaction. Appendix B of this paper presents a
+
+short example of an interaction between the KDS and a TMA.
+
+
+ The first two requests are used to create (or retrieve) key
relationships, and
+
+to destroy key relationships:
+
+
+ The request service initialization (RSI) message class is used
to establish
+
+a key-encrypting key (KK) relationship between the TMA and another
TMA, or
+
+between the TMA and the KDS. As implied by the name, a key-encrypting key is
+
+
+
+________________________________________
+6 Otherwise an adversary could simply impersonate a TMA and ask for the
desired key relationships.
+
+Similarly, this also prevents an adversary from successfully impersonating a
key distribution server.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 9
+
+
+used to cipher keys which are used to cipher data exchanged between peers.
These
+
+other keys are called data keys (KDs).
+
+
+ The disconnect service message (DSM) message class is used to
discontinue
+
+a KK-relationship between the TMA and another TMA, or between the TMA and
+
+the KDS. This prevents keys which are felt to have been
compromised, or are
+
+vulnerable to compromise, from receiving further use in the system.
It should
+
+be noted that, owing to mail messages (not CSMs) in transit, a discontinued key
+
+relationship may be needed to decipher the key used to encipher a mail message.
+
+The prototype KDS supports this capability.
+
+
+ In addition to maintaining an MK/KK/KA triple for each TMA,
the KDS
+
+also remembers KK-relationships between TMAs. The reason for this stems from a
+
+fundamental difference between the electronic funds transfer and computer-based
+
+message system worlds. The KDS assumes that no two arbitrarily chosen TMAs can
+
+communicate in real-time, and as a result, TMAs do not exchange cryptographic
+
+service messages. (See Appendix C for a more detailed discussion.) This means
+
+that when a TMA establishes a KK-relationship with another TMA, the
former
+
+TMA may start using the KK before the latter TMA knows of the new
KK-
+
+relationship. In fact, it is quite possible for a KK-relationship to be
established,
+
+used, and then discontinued, all unilaterally on the part of one TMA. It is up
to
+
+the KDS to retain old cryptographic material (possibly for an
indefinite period
+
+of time), and aid the latter TMA in reconstructing KK-relationships as the need
+
+arises. Naturally, discontinued KKs are not used to encode any new
information,
+
+but rather to decode old information. (Again, refer to Appendix C for
additional
+
+details.)
+
+
+ The other two requests are used to query the directory service aspects
of the
+
+key distribution server:
+
+
+ The request user identification (RUI) message class is used to
identify a
+
+subscriber to the KDS. Both the KDS and TMA are independent of any underlying
+
+mail transport system (MTS). As a result, a subscriber to the KDS
is known
+
+by two unique attributes: a "real-world" name, and a KDS identifier
(ID). The
+
+user of a mail system, or the UA, is responsible for mapping an
MTS-specific
+
+address (e.g., address@hidden) to the person associated with that maildrop
(e.g.,
+
+``Marshall T. Rose'' ). When conversing with the KDS, the TMA
uses the KDS
+
+ID of another user to reference that person's TMA. Since it is
inconvenient to
+
+remember the IDs (as opposed to people's names), the KDS provides
the RUI
+
+message class to permit a TMA to query the mapping between names
and IDs.
+
+If the KDS cannot return an exact match, it may respond with a list of possible
+
+matches (if the identifying information given was ambiguous), or it may respond
+
+with a response that there is no matching user.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 10
+
+
+ Finally, the request identified user (RIU) message class performs the
inverse
+
+operation: given a KDS ID, a "real-world" name is returned. This request is
useful
+
+for disambiguating unsuccessful RUI requests and in boot-strapping a TMA.
+
+
+ The KDS maintains two directories: a private directory and a public
directory.
+
+The private directory contains all information on all clients to the KDS. The
public
+
+directory is a subset of this, and is used by the KDS when
processing RUI and
+
+RIU requests.7 As a result, certain clients of the KDS may have unlisted IDs
and
+
+names.
+
+
+
+The Trusted Mail Agent
+
+ The prototype version of the TMA was designed to interface directly to
the
+
+user agent in order to maximize transparency to the user. In
present form, the
+
+TMA is available as a load-time library under 4.2bsd UNIX, although efforts are
+
+currently underway to transport the TMA to a PC-based environment.
+
+
+ The software modules which compose the TMA contain a rich set of
interfaces
+
+to the KDS. In addition, the TMA manages a local database, so responses from
the
+
+KDS may be cached and used at a later time. In all cases, the KDS is consulted
+
+only if the information is not present in the TMA database, or if the
information
+
+in question has expired (e.g., KK-relationships). This caching activity
minimizes
+
+connections to the KDS. Although connections are relatively cheap in the ARPA
+
+Internet, substantial savings are achieved for PCs which contact the KDS over a
+
+public phone network (dial-up) connection.
+
+
+ The TMA performs mappings between pairs of the following
objects: user
+
+names, KDS IDs, and MTS addresses. The TMA considers all trusted mail agents,
+
+including itself, as a user name, KDS ID, and one or more MTS addresses.
Although
+
+the TMA does not interpret addresses itself, in order to simplify
mail handling,
+
+the TMA remembers the relationship between these objects so the user enters
this
+
+information only once.
+
+
+ Initially, when a TMA is booted, the user supplies it with the master
key and
+
+the user's KDS ID. Both of these quantities are assigned by the personnel at
the
+
+key distribution center, and subsequently transmitted to the user via an
alternate,
+
+bonded service.8 The TMA connects with the KDS and verifies its identity.
From
+
+this point on, the TMA manages its KK-relationships between the KDS and other
+
+TMAs without user intervention.
+
+
+ The current implementation of the TMA assumes a "general memo framework"
+
+in the context of the Standards for ARPA Internet Text Messages[DCroc82]:
+
+
+
+________________________________________
+7 In the prototype implementation, the two directories are, for the moment,
identical.
+8 In this fashion, the problems of boot-strapping over an unsecure medium are
avoided.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 11
+
+
+ 1. A message consists of two parts: the headers and the body. A
blank line
+
+ separates the headers from the body.
+
+
+ 2. Each (virtual) line in the headers consists of a
keyword/value pair,
+
+ in which the keyword is separated from the value by a
colon (:).
+
+ The headers are rigorously structured in the sense that
they contain
+
+ addressing and other information useful to a user agent.
+
+
+ 3. The body is freely formatted and must not be
meaningful to a user
+
+ agent. However, as will be seen momentarily, the body
of encrypted
+
+ messages must have an initial fixed format which the TMA
enforces.
+
+
+This format is widely called "822" after the number assigned to the
defining
+
+report[DCroc82].9
+
+
+ To support the cipher activities described below, the TMA contains
internal
+
+routines to perform the following DES functions: electronic code book
(ECB)
+
+for key encryption, cipher block chaining (CBC) for mail message
encryption,
+
+checksumming (CKS) for mail message and CSM authentication. Readers interested
+
+in these different modes of operation for the DES should consult [FIPS81].
+
+
+Encrypting Mail
+
+ To encipher a message, the method used is a straightforward
adaptation
+
+of the standard encrypting/authentication techniques (though the terminology is
+
+tedious). Consider the following notation:
+
+
+ ax (s): the checksum of the string s using the key x (DEA
checksumming
+
+ authentication)
+
+
+ ax+y (s): the checksum of the string s using the exclusive-or of
the two keys x
+
+ and y
+
+
+ ex (y): the encryption of the key y using the key x (DEA electronic
code book
+
+ encryption)
+
+
+ ex;y (s): the encryption of the string s using the key x and
initialization vector
+
+ y (DEA cipher block chaining encryption)
+
+
+ h: the headers of the message
+
+
+ and,
+
+
+ b: the body of the message
+
+
+
+________________________________________
+9 Although an 822-style framework is employed by the TMA prototype, the 822
``Encrypted:''
+
+header is not currently present in encrypted messages. This is due
to a design decision which
+assumes that nothing in the headers of a message is sacred to the
transport system, and that
+"helpful" munging might occur at any time. In the real world, such helpfulness
is often a problem.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 12
+
+
+For each message to be encrypted, a data key, initialization vector,
authentication
+
+key (KD/IV/KA) triple is generated by a random process. (It goes without
saying
+
+that the integrity of the system depends on the process being random). Then,
for
+
+each user to receive a copy of the encrypted message, the following
actions are
+
+taken:
+
+
+ First, the headers of the message are output in the clear.
Then, a banner
+
+string, i, is constructed and placed at the beginning of the body of the
message:
+
+
+ ENCRYPTED MESSAGE: TTI TMA
+
+
+which identifies the message as being encrypted by the TTI TMA.
Following
+
+the banner string is a structure, m, which takes on the syntax and
most of the
+
+semantics of a cryptographic service message:
+
+
+ MCL/ MAIL
+
+ RCV/ rcvid
+
+ ORG/ orgid
+
+ IDK/ kkid
+
+ KD/ ekk (ka)
+
+ KD/ ekk (kd)
+
+ IV/ ekd (iv)
+
+ MIC/ aka (b)
+
+ MAC/ akd+ka (m)
+
+
+After this, the encrypted body is output, ekd;iv (b). In short, the
entire output
+
+consists of
+
+ h + i + m + ekd;iv (b):
+
+
+
+ The purpose of the structure m is many-fold. The MCL field indicates
the
+
+structure m's type; currently only the type MAIL is generated and
understood.
+
+The RCV and ORG fields identify the intended recipient of the message and the
+
+originator. The IDK field identifies the key-encrypting key, KK, used to
encrypt
+
+the next two fields. The first KD field has the encrypted authentication key,
KA,
+
+used to calculate the MIC of the plaintext of the body of the
message. After
+
+the body of the message is deciphered, aka (b) is calculated and compared to
the
+
+value of the MIC field. Hence, the MIC field authenticates the message body.
The
+
+second KD field has the encrypted data encrypting key, KD, which along with the
+
+encrypted initialization vector in the IV field was used to generate the
ciphertext
+
+of the body. Finally, the MAC field authenticates the m structure itself.
The use
+
+of a data key, initialization vector, authentication key (KD/IV/KA) triple
permits
+
+us to perform key distribution in a hierarchical fashion and allows the system
to
+
+use a KK-relationship over a longer cryptoperiod without fear of compromise.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 13
+
+
+ The TMA provides three primary interfaces to a UA to send encrypted
mail:
+
+ the first takes a file-descriptor to a message and returns a
structure g (called a
+
+ group) describing the ciphertext version of the body (this structure contains
a KD,
+
+ IV, and KA generated at random, along with a file-descriptor to
the plaintext
+
+ headers, a file-descriptor to the ciphertext body, and the checksum of the
plaintext
+
+ body); the second takes a user entry (or MTS address) and g, and
returns a
+
+ file-descriptor to the encrypted message for that user (or MTS address); the
third
+
+ takes g and performs clean-up operations. The chief advantage to this
scheme of
+
+ encryption is that if the message is to be sent to more than one recipient,
then the
+
+ MIC and the encrypted body need only be calculated once, since the KD, IV, and
+
+ KA remain constant (only the KK's change with each recipient, hence
for each
+
+ copy of the encrypted message, only the structure m need be re-calculated).
+
+
+ There are, however, a few subtleties involved: first_, the MTS
usually accepts
+
+ only 7-bit characters, so the encrypted text is exploded to consist of only
printable
+
+ characters;10 second____, since the MTS may impose limits on the
length of a line,
+
+ each line of output is limited to 64 characters; and, third___,
since the body may
+
+ require trailing padding, during encryption one last unit of 8
bytes is written
+
+ (and encrypted), naming the number of characters (presently, nulls) padded in
the
+
+ previous 8 bytes (0 : : :7).
+
+
+ Decrypting Mail
+
+ To decipher a message, the method is also straightforward: The
headers are
+
+ output in the clear. The banner string is essentially ignored, and the
structure m
+
+ is consulted to identify the correct key-encrypting key. The TMA checks to
see if
+
+ it knows of that KK. If not, it asks the KDS to supply it. From that point,
the
+
+ KA, KD, and IV are deciphered. The m structure is then authenticated. With
the
+
+ correct key, the remainder of the body is deciphered, and all except for
the last
+
+ 16 bytes are output. The last 8 bytes indicate how many of the previous 8
bytes
+
+ should be output. So, the appropriate number of bytes is output, and the
plaintext
+
+ body is authenticated and compared to the MIC. Needless to say, as the body is
+
+ deciphered, it is imploded back to 8-bit characters and lines are restored to
their
+
+ previous lengths. To indicate that the message was correctly
deciphered, a new
+
+ header of the form
+
+
+ X-KDS-ID: orgid (originator's name)
+
+
+ is appended to the headers of the message. Note that this provides an
authentication
+
+ mechanism. Note, further, that the UA did not have to know the identity of
the
+
+ sender of the message.
+
+
+
+ ________________________________________
+10 As a rule, in all CSMs, when encrypted information is transmitted, it is
exploded after encryption
+
+ by the sender, and imploded prior to decryption by the receiver.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 14
+
+
+ Modifications to MH
+
+ MH is a public domain UA for UNIX, which is widely used in
dealing with
+
+ both a large number of electronic mail application and a large number of
messages.
+
+ Although this document does not intend to describe MH, parts of the system are
+
+ described as they relate to the TMA. Readers interested in MH
should consult
+
+ either the user's manual[MRose85a] for a detailed description, or [MRose85d]
for a
+
+ higher-level description.
+
+
+ To modify MH in order to make use of a TMA, three programs were changed
+
+ (with a high degree of transparency to the user), and two new
programs were
+
+ introduced.
+
+
+ In MH, when a user wishes to send a composed draft (which
may be an
+
+ entirely new message, a re-distribution of a message, a forwarding of
messages, or
+
+ a reply to a message), the user invokes the send program. This program
performs
+
+ some minor front-end work for a program called post which actually interacts
with
+
+ the MTS. A new option to the send and post programs, the `-encrypt'
switch, is
+
+ introduced. If the user indicates
+
+
+ send -encrypt
+
+
+ then post encrypts the messages it sends.
+
+
+ When sending an encrypted message, post first checks that
each addressee
+
+ has a mapping to a KDS ID during address verification. Then, instead of
batching
+
+ all addresses for a message in a single posting transaction, for each
addressee, post
+
+ consults the TMA for the appropriately encrypted text and posts
that instead.
+
+ (Appendix A discusses the reasons for this more fully.) Hence, assuming the
user
+
+ has established mappings between MTS addresses and KDS IDs, the TMA
does
+
+ all the work necessary to encrypt the message, including contacting the KDS
as
+
+ necessary.11
+
+
+ In MH, when a user is notified that new mail has arrived, the inc
program is
+
+ run. As each message is incorporated into the user's message handling area,
a scan
+
+ (one-line) listing of the message is generated.
+
+
+ By default, the inc program upon detecting one or more encrypted
messages,
+
+ after the scanning process, asks the TMA to decipher the message, and if
successful,
+
+ scans the deciphered messages. This action can be inhibited with the
`-nodecrypt'
+
+ switch. Hence, if the user wishes to retain messages in encrypted
form, inc can
+
+ be told to note the presence of encrypted messages, but otherwise not to
process
+
+ them. By using the MH user profile mechanism, inc can be easily customized to
+
+ ________________________________________
+11 Once the TMA establishes a connection to the KDS, it retains
that connection until the UA
+
+ terminates. This is done to minimize connections to the KDS. In the context
of MH, since the
+ trusted mail agent is active over the lifetime of an invocation of a program
such as post, this means
+ that the connection is terminated just before the program terminates.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 15
+
+
+reflect the user's tastes. Again, the actions of the TMA are transparent to
the user.
+
+In fact, if encrypted mail is received from users unknown to the TMA, it
queries
+
+the KDS as to their identity prior to retrieving the KK-relationship.
+
+
+ If inc fails to decrypt a message for some reason, or if
inc was told not to
+
+decrypt a message, the decipher program can be used. This simple program
merely
+
+deciphers each message given in its argument list. The decipher program can be
+
+given the `-insitu' switch, which directs it to replace the ciphertext
version of
+
+the message with the plaintext version; or, the `-noinsitu' switch
can be used
+
+indicating that the ciphertext version of the message should be left untouched
and
+
+the plaintext version should be listed on the standard output.
+
+
+ Finally, the tma program is used to manipulate the TMA database,
containing
+
+commands to boot the database, add new users to the database, and to establish
+
+mappings between addresses and users in the TMA database. This program can
+
+also be used to disconnect KKs between other TMAs, and the KK/KA between
+
+itself and the KDS.
+
+
+ Appendix A of this paper contains a transcript of an MH session.
+
+
+
+Remarks
+
+ We now consider the merit of the system described. After presenting
some
+
+of the basic strengths of the system and a few unresolved questions, the
discussion
+
+centers on the simplifying assumptions made by the system, and how these can be
+
+defended in a non-military environment.
+
+
+Strengths
+
+ It can be argued that the prototype system (and the augmented
model in
+
+which it finds its basis) present many strengths.
+
+
+ Perhaps the most important is the high-level of independence from the
MTS
+
+enjoyed by the system. As a result, since the TMA does not
interact directly
+
+with the MTS, it can be made to be completely free from any
MTS-specific
+
+attributes, such as naming, addressing, and routing conventions.
Furthermore,
+
+when interfacing a Trusted Mail system, no modifications need be made to the
MTS
+
+or local MTA.
+
+
+ In addition to the systems-level advantage to this scheme, users of the
system
+
+profit as well, since many disjoint MTSs can be employed by a user with a
single
+
+TMA. This reduces the number of weaknesses in the system and allows a user to
+
+keep a single database of "trusted" correspondents. It should also make
analysis
+
+and verification of the TMA easier.
+
+
+ Of course from the user-viewpoint, once the TMA has been initially
booted,
+
+all key management is automatic. Not only does this reduce the risk of
compromise
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 16
+
+
+ of cryptographic material (given proper construction and maintenance
of the
+
+ TMA), but it relieves the user of a tedious and error-prone task.
+
+
+ Finally, although the KDS described herein is used to support Trusted
Mail,
+
+ other applications which require key management, could employ the services
offered
+
+ by the key distribution center.
+
+
+ Open Questions
+
+ At present, there are many restrictions on the prototype
implementation
+
+ described. Some of these result from that fact that the
implementation is a
+
+ prototype and not a production system. Others deal with more
fundamental
+
+ issues.
+
+
+ In terms of the TMA, the expiration delay for keys is hard-wired in;
it should
+
+ be user-settable. In the prototype version, the KK and KA with the KDS are
good
+
+ for 2 days or 10 uses (whichever comes first), while a KK for
use with another
+
+ TMA is good for 1 day or 5 uses. In actual practice, keys with long
cryptoperiods
+
+ might be good for 6 months or 100 uses, while keys with short cryptoperiods
might
+
+ be good for 1 month or 25 uses. The choice of actual values is an open
question
+
+ beyond the scope of prototype system.12 In many respects, this issue is a
classic
+
+ trade-off: with relatively small cryptoperiods, an adversary has less
chance of
+
+ breaking a key, but with longer cryptoperiods less connections have to be
made to
+
+ the key distribution server.
+
+
+ A fundamental issue, owing to differences between the EFT and
CBMS
+
+ environments, is that the KDS implements only a subset of the ansi draft and
the
+
+ semantics of certain operations have changed somewhat. It would be nice to
unify
+
+ the CBMS and EFT views of a key distribution center (in the former
environment,
+
+ the center is called a KDC, while in the latter environment, the center is
known
+
+ as a CKD). Appendix C of this paper discusses the differences
between the two
+
+ perspectives in greater detail.
+
+
+ At present, the relationship between errors in the TMA and
the posting
+
+ process is an open question. For example, if an address doesn't have a
mapping in
+
+ the TMA database, post treats this as an address verification error. This
prevents
+
+ the draft from being posted. The philosophy of the UA is unclear at this
point,
+
+ with respect to how recovery should occur. A second area, also in question,
deals
+
+ with the way in which plaintext and ciphertext versions of a message are
present
+
+ in a system. Clearly, it is a bad idea to make both versions available,
but since
+
+ the TMA doesn't try to concern itself with first party observation, there
seems to
+
+ be little possibility of preventing this behavior. The best that can be
done, at this
+
+ stage, is simply to choose a consistent policy that user's should attempt to
adhere
+
+
+
+ ________________________________________
+12 The current values were chosen by guess work. Although not necessarily
technically sound, the
+
+ small numbers were very good for debugging purposes.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 17
+
+
+to. The software can help somewhat in implementing this policy, but it
certainly
+
+can't circumvent the user.
+
+
+ The prototype is built on the assumption that a single key distribution
server
+
+is present. Since the ansi draft[FIKM] makes provisions for key translation
centers,
+
+the Trusted Mail prototype should perhaps be made to operate in a more diverse
+
+environment. Until the issues become clearer, this remains open.
+
+
+ Finally, for distribution lists, a large number of people would need to
share
+
+the same KDS ID. The current implementation doesn't support this. Each TMA
+
+database is for a particular ID. A user with multiple IDs would
need multiple
+
+databases, or the database should be re-organized.
+
+
+Weaknesses
+
+ As pointed out earlier, this prototype system situates itself in a
commercial,
+
+not military, environment. With respect to this decision, several
aspects of
+
+the system are now discussed, which we feel are acceptable in a
commercial
+
+environment, but which would be considered weaknesses in a military
environment:
+
+
+ 1. Traffic Flow
+
+ The prototype TMA makes no attempt whatsoever to prevent or
confuse
+
+ traffic analysis by augmenting traffic flow.
+
+
+ 2. The Database of KDS Subscribers
+
+ Since information returned by the request user identification
(RUI) and
+
+ request identified user (RIU) MCLs are returned in the clear,
this allows
+
+ an adversary to ascertain subscribers to the KDS, and perhaps
deduce
+
+ some information about the system. Without knowledge of the master key
+
+ however, an adversary could not impersonate a subscriber though.
Still, in
+
+ the military sense, this is a weakness. However, all this
assumes that the
+
+ database maintained by the KDS accurately reflects the real-world.
+
+
+ 3. Multiple Recipients
+
+ It is possible, though not proven to the authors' knowledge, that the
scheme
+
+ used to avoid encrypting the body of a message more than once for
multiple
+
+ recipients might permit one of the recipients who is also an
adversary to
+
+ compromise the key relationship between the sender and another
recipient.
+
+
+ The scenario goes like this: When a message is being prepared for
encryption,
+
+ a single KD/IV/KA triple is generated to encrypt the body. Since the
sender
+
+ has a different key relationship with each recipient, each
message sent is
+
+ different, since the structure m depends not only on the KD/IV/KA
triple
+
+ but also on the key relation between the sender and a particular
recipient.
+
+ Now suppose that one of the recipients, r1 , in addition to receiving
the copy
+
+ of the message meant for him/her also intercepts a copy of
the message
+
+ destined for another recipient, r2 . At this point, the
recipient r1 has both
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 18
+
+
+ the plaintext and ciphertext version of the body, the plaintext version
of the
+
+ KD/IV/KA triple, and the ciphertext version of the KD/IV/KA triple that
+
+ was generated using the key relationship between the sender and the
recipient
+
+ r2 . The question is: can r1 now deduce the key relationship
between the
+
+ sender and r2 ?
+
+
+ If so, then the way that the TMA attempts to minimize the use of
encryption
+
+ resources is a weakness. But, even if this is possible, given
relatively short
+
+ cryptoperiods for key relationships between TMA peers, this
becomes a
+
+ non-problem.
+
+
+ 4. Discussion Groups
+
+ As discussed earlier, the proposed method of associating a single KDS
ID with
+
+ the membership of a discussion group does introduce a significant
weakness
+
+ for the security of messages sent to the discussion group.
Since the TMA
+
+ does not assume a general broadcast facility, it appears that
there are no
+
+ good solutions to the problem of discussion group traffic. Of course,
it is easy
+
+ enough to simply send to each member of the group.
+
+
+ For the sake of argument, let's assume that the discussion
group has n
+
+ members. Now, since a different key relationship would exist
between the
+
+ sender and each of the n recipients, the structure m would be
different for
+
+ each recipient and so a different message would have to be
sent to each
+
+ recipient. To make matters worse, if one rejects the way the TMA
handles
+
+ multiple recipients, not only does the MTS get burdened with
n different
+
+ messages, but the sender's TMA gets burdened by having to encrypt the
body
+
+ of the message n times. For meaningful values of n (say on the order
of 500,
+
+ or even 25), the amount of resources required for any trusted
discussion group
+
+ are simply too costly.
+
+
+Compromises, Compromises
+
+ Each of the possible weaknesses discussed above represent a
compromise
+
+between the expense of the system and the level of security it can provide.
+
+
+ The first two areas, if addressed by the TMA, could result
in much less
+
+background information being available to an adversary. In an application
where it
+
+is important that an adversary not know who is talking to whom, or who can talk
+
+at all, this is very important. It is the authors' position that in the
commercial
+
+environment, this issue is not paramount. By ignoring the issue of traffic
flow, the
+
+TMA has a lot less work to do and the MTS is kept clear of "useless" messages.
+
+By keeping the information returned by the RUI and RIU MCLs in the clear, the
+
+complexity of the TMA is significantly reduced.
+
+
+ The second two areas, if addressed by the TMA, could result
in a lesser
+
+probability of traffic being deciphered by an adversary. Regardless
of the
+
+application, this is always extremely important. However, the
authors' feel
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 19
+
+
+that the compromise made by the TMA in these two issues is not
substantial,
+
+and does not result in an explicit weakness when a message is sent
to multiple
+
+recipients (note that when there is only a single recipient of a message,
these two
+
+policies can not introduce weaknesses). In return, efficient use can
be made of
+
+both the MTS and the TMA when messages are being sent to multiple recipients.
+
+Given scarce resources or large numbers of recipients, this approach may prove
to
+
+be quite winning.
+
+
+ Of course, much work remains to be done to prove the success of the TMA
in
+
+all four of these areas.
+
+
+
+Acknowledgements
+
+ The prototype implementation described herein utilizes a public
domain
+
+implementation of the DES algorithm[DEA] which was originally implemented by
+
+James J. Gillogly in May, 1977 (who at that time was with the Rand Corporation,
+
+and is now affiliated with Gillogly Software). Interfaces to Dr.
Gillogly's
+
+implementation were subsequently coded by Richard W. Outerbridge in September,
+
+1984 (who at that time was with the Computer Systems Research Institute at the
+
+University of Toronto, and is now affiliated with Perle Systems, Incorporated).
+
+
+ The authors would like to acknowledge Dennis Branstad, Elaine
Barker,
+
+and David Balensen of the National Bureau of Standards for their
comments
+
+on the prototype system and insights on the ANSI draft[FIKM]. In
particular,
+
+Dr. Branstad originally suggested the method used for encrypting a single
message
+
+for multiple recipients under different keys.
+
+
+ The authors (and all those who have read this paper) would like to
thank Willis
+
+H. Ware of the Rand Corporation, and Jonathon B. Postel of the USC/Information
+
+Sciences Institute. Their extensive comments resulted in a much more
readable
+
+paper. In addition, the authors would like to thank Dr. Stephen P.
Smith and
+
+Major Douglas A. Brothers for their insightful comments.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 20
+
+
+ References
+
+
+
+[DCroc82] D.H. Crocker. Standard for the Format of ARPA
Internet Text
+
+ Messages. Request for Comments 822. ARPA Internet
Network
+
+ Information Center (NIC), SRI International (August, 1982).
+
+
+
+[DEA] Data Encryption Algorithm, X3.92-1981, American National
+
+ Standards Institute, 1981.
+
+
+
+[FIKM] Financial Institution Key Management, X9.17-198_ (draft),
American
+
+ National Standards Institute, 198_.
+
+
+
+[FIPS46] Data Encryption Standard, Federal Information Processing
Standards,
+
+ Publication 46, 1977.
+
+
+
+[FIPS81] DES Modes of Operation, Federal Information Processing
Standards,
+
+ Publication 81, 1980.
+
+
+
+[IP] Internet Protocol. Request for Comments 791 (milstd
1777).
+
+ Appearing in Internet Protocol Transition Workbook, ARPA
Internet
+
+ Network Information Center (NIC), SRI International, 1981.
+
+
+
+[LLamp82] L. Lamport, R. Shostak, M. Pease. The Byzantine Generals
Problem.
+
+ ACM Transactions on Programming Languages and Systems 4
(July,
+
+ 1982), 382-401.
+
+
+
+[MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
+
+ User's Manual. UCI Version. Department of Information and
Computer
+
+ Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85d] M.T. Rose, E.A. Stefferud, J.N. Sweet. MH: A Multifarious
User
+
+ Agent. Computer Networks (to appear).
+
+
+
+[TCP] Transmission Control Protocol. Request for Comments 793
(milstd
+
+ 1778). Appearing in Internet Protocol Transition
Workbook, ARPA
+
+ Internet Network Information Center (NIC), SRI International,
1981.
+
+
+
+[VVoyd83] V.L. Voydock, S.T. Kent. Security Mechanisms in
High-Level
+
+ Network Protocols. Computing Surveys 15, 2 (June, 1983),
135-171.
+
+
+
+[X.400] Message Handling Systems: System Model-Service Elements,
+
+ Recommendation X.400, International Telegraph and
Telephone
+
+ Consultative Committee (CCITT).
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 21
+
______________________________________________________________________________________________________________________
+
+ 1 % tma -add -user "UCI Portal" address@hidden
+ 2 3: "UCI Portal"
+ 3 address@hidden
+ 4
+ 5 % comp
+ 6 To: uci
+ 7 Fcc: +outbox
+ 8 Subject: test message
+ 9 --------
+10 mumble, mumble.
+11 ^D
+12
+13 What now? send -encrypt
+14 -- Address Verification --
+15 -- Local Recipients --
+16 uci: address ok
+17 -- Address Verification Successful --
+18 -- Posting for All Recipients --
+19 -- Local Recipients --
+20 uci: address ok
+21 -- Recipient Copies Posted --
+22 -- Filing Folder Copies --
+23 Fcc outbox: folder ok
+24 -- Folder Copies Filed --
+25 Message Processed
+
+
+ Figure 4
+
+
__________________________________________Sending_Encrypted_Mail______________________________________________________
+
+
+
+ Appendix A: An MH Session
+
+ In the following, the user ``Marshall T. Rose''
logged onto host
+
+ ``udel-dewey'' , wishes to send a message to a user known as the
``UCI Portal''
+
+ (a system maintenance account). As shown in Figure 4, line 1, the user first
estab-
+
+ lishes a mapping between the name ``UCI Portal'' and the address
address@hidden
+
+ dewey. Once this mapping is performed, it remains in effect until the user
indicates
+
+ otherwise to the TMA. When the tma program is invoked, it consults
the TMA
+
+ database to see if that user is known. If not, it contacts the KDS to ask
for the
+
+ KDS ID associated with the user. If the response is successful (in this
case, the
+
+ KDS ID is ``3'' ), then the TMA updates its database. The tma program
indicates
+
+ in its output the KDS ID associated with the user, along with all known
addresses
+
+ (in this case, only one). So, once the name to address mapping has been
described
+
+ the user, the user agent, MH, deals only with the address, while the trusted
mail
+
+ agent deals with the name and KDS ID aspects of the user.
+
+
+ Next, the comp program is invoked to compose a new draft on line 5.
The
+
+ user addresses the local user ``uci'' in the To: field, and indicates
that a plaintext
+
+ copy should be kept in the folder ``+outbox'' . After entering
the subject and
+
+ text of the draft, the user enters What now? level on line 13. At this
point, the
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 22
+______________________________________________________________________________________________________________________
+
+ 1 % inc
+ 2 Incorporating new mail into inbox...
+ 3
+ 4 1+E02/28 0227-EST mrose test message
<<ENCRYPTED MESSAGE: TTI
+ 5
+ 6 Incorporating encrypted mail into inbox...
+ 7
+ 8 1+ 02/28 0227-EST mrose test message
<<mumble, mumble. >>
+
+
+ Figure 5
+
+________________________________________Receiving_Encrypted_Mail______________________________________________________
+
+
+
+user directs MH to send the draft in encrypted form. The resulting
output is
+
+verbose (a default for send for this user) but instructive. Initially, all
addresses in
+
+the draft are verified on lines 14 to 17. Two forms of verification occur:
first, the
+
+MTS is asked to verify the address as much as possible. For local addresses,
the
+
+MTS decides if the name has a maildrop associated with it. For remote
addresses,
+
+the MTS decides if the host is known to it. The second type of verification
occurs
+
+with the TMA. For all addresses, the TMA is asked if it can find a mapping from
+
+the address to a KDS ID.
+
+
+ The reason MH goes to all this trouble is a philosophical
issue. Since the
+
+copy of the encrypted draft is different for each recipient, post tries to
verify that
+
+all recipients can be successfully posted prior to actually posting
the different
+
+ciphertext versions of the draft. This behavior is not optimal in terms of
cycles,
+
+but is perhaps "correct" from a UA perspective.
+
+
+ Finally, the draft is actually posted, and the folder carbon-copy is
filed.
+
+
+ Some time later, the UCI portal is informed that new mail has arrived.
As
+
+shown in Figure 5, the inc program is run. The ``E'' prior to
the date of the
+
+message indicates that inc has detected the message to be encrypted. Since the
+
+user did not inhibit inc from deciphering the message, it proceeds to do so.
+
+
+ Finally, it may be instructive to see what the encrypted
message looked
+
+like when it was delivered to the portal's maildrop, and the final
message after
+
+deciphering. Figures 6 and 7 show these respectively. In particular, note
that the
+
+``X-KDS-ID:'' field has been introduced in Figure 7 after
successfully deciphering
+
+the message. The presence of this field authenticates the sender of the
message.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 23
+______________________________________________________________________________________________________________________
+
+Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
+ ;28 Feb 85 2:27 EST
+To: address@hidden
+Subject: test message
+Date: 28 Feb 85 02:27:16 EST (Thu)
+Message-ID: <address@hidden>
+From: address@hidden
+
+
+ENCRYPTED MESSAGE: TTI TMA
+(
+MCL/MAIL
+RCV/3
+ORG/17
+IDK/850228072730
+KD/e36813a3882eebd1
+KD/fa8b8ac657476669
+IV/Ef9d283565431b103
+MIC/fdb927fb
+MAC/50e9de30
+)
+a13774f652d844762c4fc03c2f4e201b9d2f57eadb00546c
+
+
+ Figure 6
+
+______________________________________Message_Prior_to_Decryption_____________________________________________________
+
+______________________________________________________________________________________________________________________
+Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
+ ;28 Feb 85 2:27 EST
+To: address@hidden
+Subject: test message
+Date: 28 Feb 85 02:27:16 EST (Thu)
+Message-ID: <address@hidden>
+From: address@hidden
+X-KDS-ID: 17 (Marshall T. Rose)
+
+
+mumble, mumble.
+
+
+ Figure 7
+
+________________________________________Message_After_Decryption______________________________________________________
+
+
+
+Appendix B: A Short Exchange
+
+ The simple nature of the interchange between the user and MH in
Appendix A
+
+completely hides any interactions between the TMA and the KDS. Let us briefly
+
+examine an exchange that might occur after the destination TMA
receives the
+
+message shown in Figure 6.
+
+
+ To begin, the TMA must ascertain what it knows about the
sender of the
+
+message, which claims to have a KDS ID of 17. That is, the TMA
must first
+
+consider what key relationships it has with the sender. For the sake of
argument,
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 24
+
______________________________________________________________________________________________________________________
+
+ 1 <--- (
+ 2 <--- MCL/RIU
+ 3 <--- RCV/17
+ 4 <--- ORG/3
+ 5 <--- KDC/TTI
+ 6 <--- EDC/1a1fbbba
+ 7 <--- )
+ 8 ---> (
+ 9 ---> MCL/RTR
+10 ---> RCV/17
+11 ---> ORG/3
+12 ---> CTA/1
+13 ---> USR/"Marshall T. Rose"
+14 ---> KDC/TTI
+15 ---> MAC/2ebde134
+16 ---> EDC/96b183de
+17 ---> )
+18 <--- (
+19 <--- MCL/ACK
+20 <--- RCV/17
+21 <--- ORG/3
+22 <--- KDC/TTI
+23 <--- EDC/59a8ddcc
+24 <--- )
+
+
+ Figure 8
+
+
__________________________________________Ascertaining_the_Sender_____________________________________________________
+
+
+
+ suppose that this purported subscriber is unknown to the TMA. In this case,
the
+
+ first step it must undertake is to ascertain the validity of this subscriber.
+
+
+ As shown in Figure 8 on lines 1-7, the TMA does this by
establishing a
+
+ connection to the KDS and issuing an request identified user (RUI)
MCL.13 If
+
+ the response by the KDS is positive, the TMA will use the information
returned
+
+ when generating the ``X-KDS-ID:'' field for authentication. The
response CSM
+
+ returned by the KDS includes an authentication checksum (the MAC
field on
+
+ line 15) and a transaction count (the CTA field on line 12) to prevent
spoofing by a
+
+ process pretending to be the KDS. The TMA then acknowledges that the response
+
+ from the server was acceptable on lines 18-24.
+
+
+ The next step is to ascertain the actual key relationship used to
encrypt the
+
+ structure m, which appears after the identifying string. The TMA
consults the
+
+
+ ________________________________________
+13 In point of fact, the very first thing that the TMA does after connecting
to the KDS is verify
+
+ that the key relationships between the KDS and the TMA are valid
(have not expired). If the
+ key relationship between the two has expired, the TMA issues a request
service initialization RSI
+ MCL to establish a new key relationship. This relationship contains a
key-encrypting key (KK) and
+ an authentication key (KA). Once a valid key relationship exists between the
KDS and the TMA,
+ transactions concerning other key relationships may take place.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 25
+
______________________________________________________________________________________________________________________
+
+ 1 <--- (
+ 2 <--- MCL/RSI
+ 3 <--- RCV/17
+ 4 <--- ORG/3
+ 5 <--- IDK/850228072730
+ 6 <--- KDC/TTI
+ 7 <--- SVR/KD.IV.KK
+ 8 <--- EDC/83679e14
+ 9 <--- )
+10 ---> (
+11 ---> MCL/RTR
+12 ---> RCV/17
+13 ---> ORG/3
+14 ---> KK/095f9d6b87f57871
+15 ---> CTA/2
+16 ---> KD/527fbb5593efd318
+17 ---> KD/1dcab338be1e7a09
+18 ---> IV/E02db5e598b2823ae
+19 ---> EDK/850618075332
+20 ---> KDC/TTI
+21 ---> MAC/12cbbdf5
+22 ---> EDC/8cd0c4a8
+23 ---> )
+24 <--- (
+25 <--- MCL/ACK
+26 <--- RCV/17
+27 <--- ORG/3
+28 <--- KDC/TTI
+29 <--- EDC/59a8ddcc
+30 <--- )
+
+
+ Figure 9
+
+
__________________________________Ascertaining_the_Key_Relationship___________________________________________________
+
+
+
+ IDK field in m, and if this relationship is unknown to it, then the KDS is
asked to
+
+ disclose the key relationship.
+
+
+ As shown in Figure 9 on lines 1-9, This is done by issuing a request
service
+
+ initialization (RSI) MCL and specifying the particular key relationship of
interest.
+
+ The KDS consults its database, and if the exact key relationship
between the
+
+ two indicated TMAs can be ascertained, it returns this information.
The key
+
+ relationship is encrypted using the key relationship between the KDS
and the
+
+ TMA, and the usual count and authentication fields are included.
+
+
+ Once the TMA knows the key relationship used to encrypt the structure
m,
+
+ it can decider the structure and ascertain the KD/IV/KA triple used to encrypt
+
+ the body of the message.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 26
+
+
+ Appendix C: Differences between the ANSI and TTI drafts
+
+ The differences between the ansi draft standard for financial
institution key
+
+ management, and the TTI draft's specification for trusted mail
handling, are
+
+ considered.
+
+
+ The concept of a key distribution center (CKD in the ansi draft, KDC
in the
+
+ TTI draft) environment differs. In the ansi draft, only one party talks to
the key
+
+ distribution server (KDS); in the TTI draft, both parties talk to
the KDS. This
+
+ leads to a number of differences in the two protocols. The reason
for this shift
+
+ in the TTI draft is somewhat subtle: although both parties can talk to the
KDS,
+
+ the mail transfer system (MTS) environment is such that both user agents (UAs)
+
+ are unable to contact each other in real-time. Hence, a detailed two-way
protocol
+
+ between them is prohibitively expensive.14
+
+
+ Before discussing the differences between the two drafts, let us
consider the
+
+ differences in the two environments: in the electronic mail environment, the
two
+
+ end-to-end peers need not be simultaneously online. Electronic mail
relies on a
+
+ communication service with potentially large delays in transit
between message
+
+ transfer agents (MTAs). A basic concept of "mail" is that an originator must
release
+
+ the enveloped message to a "transfer agent" before delivery can be attempted
to a
+
+ recipient. In contrast, in the electronic funds environment, the two peers
make use
+
+ of a virtual-circuit service. This means that they can synchronize much
easier and
+
+ inter-operate in a more direct fashion.
+
+
+ Service protocols are based on the notion of requests and responses.
A client
+
+ issues a request to a server, the server processes the request and returns a
response.
+
+ Depending on the complexity of the protocol, the client may now respond to the
+
+ server's message, or might issue a new request, or might terminate the
connection.
+
+
+ As delays in the network increase, along with the possibility
of loss or
+
+ corruption or re-ordering of messages, it becomes more difficult to
implement a
+
+ service protocol. In the case of a high-level protocol making use
of a virtual-
+
+ circuit service, most problems can be ignored, as the virtual-circuit service
masks
+
+ out problems in the network by using sequences, positive (and/or
negative)
+
+ acknowledgments, windows, and so on.
+
+
+ Sadly, electronic mail cannot utilize a virtual-circuit
throughout the MTS
+
+ (although individual MTA-wise connections are (in theory) virtual-circuit
based).
+
+ This means that implementing a real-time or interactive service protocol
between
+
+ two endpoints (a.k.a. UAs) in the MTS is very difficult. As a result, the
complexity
+
+ of an end-to-end protocol in the MTS (in terms of requests and
responses) is
+
+ severely constrained. For all practical purposes, an MTA can assume
datagram
+
+ service and nothing else: messages might be re-ordered; messages might not
reach
+
+ ________________________________________
+14 In the words of Einar A. Stefferud: "Every interesting connection has at
least two end-points _
+
+ connections with only one end-point are always uninteresting."
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 27
+
+
+their destination; messages might be corrupted (though this is unlikely); in
cases
+
+of failure, a notice might be generated, or might not.
+
+
+ In terms of the environment in which cryptographic service messages
(CSMs)
+
+must flow, the high degree of delay and uncertainty make the implementation of
a
+
+complex end-to-end protocol between UAs prohibitively expensive. Hence, a KDC
+
+is needed, to which each UA can connect using a virtual-circuit service, at
posting
+
+and delivery time. The TTI draft terms such a user agent a trusted
mail agent
+
+(TMA). Since both TMAs can connect to the KDS at different times using
different
+
+media, the KDS maintains state information about the key relationships between
+
+different TMAs and manages those relationships appropriately. Since
connections
+
+to the KDS can be expensive in terms of resources, each TMA caches information
+
+received from the KDS appropriately.
+
+
+ That's the gist of the argument as to why the TTI draft differs from
the ansi
+
+draft. It might be possible to include CSMs in the messages which UAs
exchange,
+
+but management of these CSMs can not be done reliably or in a straightforward
+
+fashion owing to the datagram nature of the service offered by the MTS.
Finally, it
+
+should be noted that in the TTI draft, the KDS never initiates a connection
with
+
+a TMA, rather it is the TMAs which connect to the KDS.
+
+
+ In the following, the differences between the two drafts are
highlighted. Minor
+
+differences between the two are not discussed.
+
+
+ In the ansi draft, x 4:2 (p. 22) discusses the requirements for the
automated
+
+key management architecture. The TTI draft has somewhat more "depth", since
+
+the ansi draft does not make use of a master key (MK) to fully
automate the
+
+distribution of key-encrypting keys (KK).
+
+
+ The ansi draft states that once a KK-relationship is discontinued by
either
+
+of that pair, the relation is not to be re-used for any subsequent
activity. This
+
+can't be guaranteed in the prototype implementation. If one of the TMAs wishes
+
+to discontinue a key, not only does it have to inform the KDS, but the other
TMA
+
+as well. Since the TTI draft does not permit CSMs between TMA-peers, the
latter
+
+action doesn't seem possible. However, there is a solution. Whenever a
message is
+
+deciphered, the TMA checks the effective date of the key used to encrypt a
message
+
+it has received, and if the key is newer than the one it currently uses, it
considers
+
+the older key to be discontinued.
+
+
+ Furthermore, although the environment in the TTI draft is that
of a key
+
+distribution center, the notion of an ultimate recipient is not present, since
all clients
+
+connect to the KDS at one time or another. In addition, the differences
between
+
+the environs envisioned by the two drafts become even more
pronounced when
+
+one considers that the KDS distributes key-encrypting keys to TMAs, although
the
+
+ansi draft specifically prohibits this.
+ Reprinted from Proceedings, Second International Symposium on Computer
Message Systems, 1985 28
+
+
+ Finally, there is another important technical difference between
the two
+
+drafts: every request to the KDS by the TMA results in a
specifically defined
+
+response from the KDS to the TMA. Furthermore, if the KDS responds in a
positive
+
+manner, then the TMA acknowledges this. This three-way interaction is used to
+
+ensure consistency between the states of the KDS and the TMA. The ansi draft
+
+does not require such behavior, and might profit from some finite-state
analysis to
+
+ascertain unsafe (in terms of correctness) states which are reachable.
+
+
+
+
+ Contents
+
+
+
+
Page
+
+ Introduction . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ *. 1
+
+ The Key Distribution Service . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 6
+
+ The Trusted Mail Agent . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 10
+
+ Encrypting Mail . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 11
+
+ Decrypting Mail . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 13
+
+ Modifications to MH . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 14
+
+ Remarks . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . *
+ * . 15
+
+ Strengths . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .*
+ * 15
+
+ Open Questions . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 16
+
+ Weaknesses . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . *
+ * 17
+
+ Compromises, Compromises. . . . . . . . . . . . . . . .
. . . . . . . . . . . 18
+
+ Acknowledgements . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 19
+
+ References . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . *
+ * . 20
+
+ Appendix A: An MH Session . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 21
+
+ Appendix B: A Short Exchange . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 23
+
+ Appendix C: Differences between the ANSI and TTI drafts . . . . . . .
. . . 26
+
+
+
+ ________________________________________
+This document (version #2.60) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+
i
diff --git a/docs/historical/tutorial.pdf b/docs/historical/tutorial.pdf
new file mode 100644
index 0000000..97b088c
Binary files /dev/null and b/docs/historical/tutorial.pdf differ
diff --git a/docs/historical/tutorial.txt b/docs/historical/tutorial.txt
new file mode 100644
index 0000000..f7c3f45
--- /dev/null
+++ b/docs/historical/tutorial.txt
@@ -0,0 +1,1389 @@
+
+
+
+
+ The Rand MH Message Handling System:
+
+
+
+ Tutorial
+
+
+ Marshall T. Rosey
+
+ Jerry N. Sweetz
+
+ Wed May 21 21:04:08 PDT 1986
+
+
+
+ Abstract
+
+
+ This document introduces the UCI version of the Rand MH
+
+ system to novice users. In particular, this tutorial discusses
+
+ how to read, send, reply to, and review mail; aspects of the
+
+ MH user profile affecting these activities; and other reference
+
+ works on MH.
+
+
+ Although this document is based on the standard MH
+
+ user manual[MRose85a], this document is meant to supple-
+
+ ment, not supersede, that lengthier work.
+
+
+ Comments concerning this documentation should be ad-
+
+ dressed to the Internet mailbox address@hidden
+
+
+
+_____________________________________
+Computer Mail: y address@hidden, z address@hidden
+
+
+ The Rand MH Message Handling System:
+
+
+
+ Tutorial
+
+
+
+Acknowledgements
+
+ The MH system described herein is based on the original Rand MH system.
+
+It has been extensively developed (perhaps too much so) by Marshall Rose and
+
+John Romine at the University of California, Irvine. Einar Stefferud, Jerry
Sweet,
+
+and Terry Domae provided numerous suggestions to improve the UCI version of
+
+MH.
+
+
+ Parts of this document are taken from a Rand tutorial
[SPayn85] by Sue
+
+Payne.
+
+
+
+Disclaimer
+
+ The Regents of the University of California issue the
following disclaimer
+
+concerning the UCI version of MH:
+
+
+
+ "Although each program has been tested by its contributor, no warranty,
express or
+ implied, is made by the contributor or the University of California,
as to the accuracy
+ and functioning of the program and related program material, nor shall
the fact of
+ distribution constitute any such warranty, and no responsibility is
assumed by the
+ contributor or the University of California in connection herewith."
+
+
+
+Scope
+
+ This document assumes that you have no knowledge of MH. However, to use
+
+MH you should have some familiarity with the UNIX1 operating system,
particularly
+
+with the way commands are given, how files are named, the jargon (e.g.
shell,
+
+argument, home directory, pathname), and how to use a text editor (such as ex,
vi,
+
+or emacs ).
+
+
+ This tutorial covers only basic material. For additional information
about
+
+MH, consult the User's Manual [MRose85a]. Other documents of possible interest
+
+to you include The UCI BBoards Facility [MRose84] and the MH Administrator's
+
+Guide [MRose85b].
+
+
+
+_____________________________________
+1 UNIX is a trademark of AT&T Bell Laboratories.
+
+
+
+ 1
+
2
+
+
+How To Use This Tutorial
+
+ Different typefaces and symbols are used in this document to
denote the
+
+kinds of things you (the user) must type on your keyboard.
+
+
+ 1. The names of programs are given in text italics:
+
+
+ comp
+
+
+ 2. Arguments to programs are given in typewriter style, delimited
by
+
+ single-quotes:
+
+
+ `msgs'
+
+
+ 3. UNIX pathnames are given in slanted roman:
+
+
+ /usr/uci/
+
+
+ 4. Text giving a full example is presented in typewriter style:
+
+
+ comp -editor vi
+
+
+ The " " glyph is used to indicate an explicit space (the kind
you make
+
+ with the space bar on your keyboard).
+
+
+
+Introduction
+
+ With MH you can send messages to other people on your system and read
+
+messages that other people send to you. Depending on how things
have been
+
+set up on your system, it may be possible for you to send messages to people on
+
+remote systems. You can also reply to messages that you have received, review
+
+them, organize them in folders, and delete them.
+
+
+ MH differs from other mail programs in that it is composed of many
small
+
+programs instead of just one very large program. Among new users this
sometimes
+
+causes some confusion along the lines of "what program do I run?" With MH, you
+
+use the shell to invoke one program at a time. This means that when you handle
+
+mail, the entire power of the shell is at your disposal in addition to the
facilities
+
+that MH provides. In the beginning, this may not make much sense or may not
+
+seem important. However, we have found that as new users of MH gain
experience,
+
+they find this style of interface to be very useful.
+
3
+
+
+Summary
+
+ The most minimal list of MH commands that you can get by with is:
+
+
+ inc - incorporate mail (get new mail)
+
+
+ show - show the first message
+
+
+ next - show the next message
+
+
+ prev - show the previous message
+
+
+ comp - compose a new message to send
+
+
+ repl - reply to a received message
+
+
+ Comp and repl give enough prompting possibly to get you along.
However,
+
+it is suggested that you take the time to peruse this tutorial before leaping
into
+
+things.
+
+
+
+Messages and Folders
+
+ A message takes the form of a memorandum, and is composed
of two
+
+major parts: a header, which contains such information as ``To'' and
``From''
+
+addresses, ``Subject'' , ``Date'' , etc.; and the body, which is the
actual text of
+
+the message. Each component in the header starts with a keyword followed by a
+
+colon and additional information. For example, in the message:
+
+
+ Date: 10 Oct 84 17:41:14 EDT (Wed)
+
+ To: address@hidden
+
+ Subject: UCI Software Talk
+
+ From: UCI Portal (agent: Marshall Rose) <address@hidden>
+
+
+
+ This is the text.
+
+
+there are four header items, and one line of text in the body. Note that a
blank
+
+line separates the body from the headers.
+
+
+ MH stores a message as an ordinary file in a UNIX directory. This
directory is
+
+called a folder. If you choose to keep and organize your messages, you may
create
+
+as many folders as you wish. There is no limit as to the number of messages
in a
+
+folder. Typically messages are numbered from 1 up. All of your personal
folders,
+
+along with some other information that MH needs to know, are kept in a special
+
+directory called Mail under your home directory. Normally, MH manages
these
+
+files and directories automatically, so you needn't muck around with them
directly
+
+unless you really want to.
+
4
+
+
+ You won't have any folders until somebody sends mail to you, as a
rule. If
+
+you are anxious to try out MH, but no one has sent you mail yet, try sending
mail
+
+to yourself to start out with.
+
+
+
+Reading New Mail
+
+ When you are notified that you have mail (usually when you log in),
perhaps
+
+with the message
+
+
+ You have mail.
+
+
+then you know that messages are waiting in your maildrop. To read these
messages,
+
+you first have to incorporate the mail into your "in-box" by typing the
command:
+
+
+ inc
+
+
+This incorporates the new mail from your mail drop to your in-box, which is a
+
+folder named (naturally enough) `+inbox' . As inc incorporates your new
mail, it
+
+generates a scan listing of the mail:
+
+Incorporating new mail into inbox...
+
+2 + 10/10 WESTINE% USC-ISIF RFC 916 Now Available <<A
new Request for Co
+3 10/10 G B Reilly Gosling EMACS manual
<<Marshall, I am lookin
+4 10/11 WESTINE% USC-ISIF Internet Monthly Report
+
+
+Each time inc is invoked, any new messages are added to the end
of your
+
+``+inbox'' folder.
+
+
+ To read the first message, use the show command:
+
+
+ show
+
+
+This displays the current message. To read each subsequent message, use the
next
+
+command:
+
+
+ next
+
+
+If you want to back up, the command prev shows the previous message. Another
+
+way to read your messages is to name them all at once:
+
+
+ show all
+
+
+This command displays them all, one after the other. The `all' argument to
show
+
+above might also be replaced with `next' or `prev' , as in
+
+
+ show next
+
+ show prev
+
+
+which are respectively equivalent to the next and prev commands.
+
5
+
+
+ If you have had occasion to type inc more than once, then you will
find that
+
+``show all'' is showing not only the new messages, but also the old
messages
+
+that you've already seen. Therefore, you might find it better to use
+
+
+ show cur-last
+
+
+instead. This command displays messages from the current message (`cur' )
to the
+
+last message (`last' ). Each time inc is invoked, it makes the first new
message the
+
+current message. It should be noted here that the name `all' given in a
previous
+
+example is equivalent to the message range `first-last' , where `first'
is the
+
+name of the first message in `+inbox' . Also, ``show'' by itself is
equivalent to
+
+
+ show cur
+
+
+
+ As mentioned earlier, with the UNIX shell as your interface to MH, it
becomes
+
+easy to list a message on a line printer or to another file. For example,
+
+
+ show all _ lpr
+
+
+lists all the messages in the current folder to the line printer.
+
+
+ To summarize, the preceding has introduced these important
concepts:
+
+folders (in particular, the `+inbox' folder), messages, message
names (e.g.
+
+`prev' , `next' , `cur' , `last' ), and message ranges (e.g.
`cur-last' , `all' ).
+
+More will be said about folders and messages in succeeding sections.
+
+
+
+Sending Messages
+
+ To send a message, you compose a message draft, either by
replying to a
+
+message that someone sent to you, or by creating a draft from scratch. The
send
+
+command is used after completing the final draft of a message, in the same way
+
+that you mail a paper letter only after you are finished writing it. This is
a common
+
+source of confusion among new MH users who may have had experience with other
+
+mail systems.
+
+
+ This section discusses how to originate messages and how to reply to
messages
+
+that were previously received, along with a word or two about addresses.
+
+
+Originating Messages
+
+ To create a message draft from scratch, use the comp program. You
will be
+
+prompted for the header components and then the body of the message. If you
+
+make a mistake, you may correct it later with a text editor. The draft will
be sent
+
+only if you give an explicit send command, so you do not have to worry about
the
+
+draft getting away from you prematurely.
+
+
+ To start, you simply type:
+
+
+ comp
+
6
+
+
+ To: First, the prompt `To:' appears. Here you type the address of
the person
+
+to whom you wish the message sent. If this person is on the same computer
system
+
+as you, then that person's login ID should serve as the address (e.g. `mrose'
or
+
+`jsweet' ).
+
+
+ Here we digress briefly to discuss addresses. A full discussion of
addresses
+
+is beyond the scope of this tutorial, but it should be mentioned
that there
+
+are other kinds of addresses besides login IDs. To send messages
to people
+
+on remote systems, the usual way is to type address@hidden'
in the `To:'
+
+component, as in address@hidden' . Examples of `host' names at
UCI include
+
+`uci-icsa' , `uci-icse' , and `uci-cip1' . Upper and lower
case letters may be
+
+used interchangeably. Sometimes a person's last name (e.g. `Rose' ,
`Sweet' ) can
+
+be used instead of a login ID, but this cannot be relied upon in a world
without
+
+unique surnames.
+
+
+ cc: After you have given an address to the `To:' prompt, you are
prompted
+
+for the `cc:' ("carbon copy"-an archaism) address. It is customary,
but not
+
+required, to put your own address here so that you get a copy of the message
when
+
+it is sent.
+
+
+ To put more than one address in the `To:' and `cc:' components,
just use
+
+a comma (",") between each address on a line.
+
+
+ Subject: The third prompt is for the `Subject:' component.
Here a line
+
+of any descriptive text will do. Once you have typed a line of text, a dashed
line
+
+is printed, and you are then expected to type the body of the message. End the
+
+body with EOT (usually CTRL-D).
+
+
+ An example of a complete message draft, as it appears on your screen,
might
+
+be:
+
+
+ To: News
+
+ cc: farber, mrose
+
+ Subject: UCI Software Talk
+
+ --------
+
+ A presentation on the UCI software suite, including
+
+ the Rand/UCI Mail Handling System (MH), will be given
+
+ in CS220 on October 31st at 2:30 PM. Refreshments
+
+ will be served afterward.
+
+
+
+ /mtr
+
+ ^D
+
+
+(The "^D" does not appear in the draft.)
+
7
+
+
+ At this point, you are asked
+
+
+ What now?
+
+
+This is known as being at What now? level. For now, there are probably only
four
+
+options that will interest you:
+
+
+ edit - edit the draft
+
+
+ list - list the draft on your screen
+
+
+ quit - quit, without sending the draft
+
+
+ send - send the draft, then quit
+
+
+
+All of these options take various arguments, but only edit really needs an
argument.
+
+
+ Edit: The edit option will let you edit the draft before sending it.
If your
+
+favorite text editor is vi, then you would use the edit option as:
+
+
+ edit vi
+
+
+Just specifying edit with no argument will only let you append text to the body
+
+of the message draft. Another editor (e.g. vi, ex, emacs ) should really be
run to
+
+finish the draft up. When you leave the editor, you will come back to the What
+
+now? level, where you can re-edit the draft, send it, list it, or simply quit
without
+
+sending the draft at all.
+
+
+ Caution: while in the editor, you should not delete colons in the
headers or
+
+change the spelling of `To:' , `cc:' , or `Subject:' ; and do not
leave blank lines
+
+between these lines. Feel free to change the addresses that you typed
previously, or
+
+to add these lines if they are missing. Do not delete the dashes that
separate the
+
+header lines from the text of the message. You should not add additional
header
+
+lines unless you understand precisely what you are doing. This means
particularly
+
+that you should not type or fill in a `From:' line. When the message is
sent, the
+
+system automatically adds this line. Also, you should not type a `Date:'
line in
+
+the header. When the message is sent, the system automatically adds the
current
+
+date and time.
+
+
+ Quit: If you quit without sending the draft, the draft is saved in a
file called
+
+Mail/draft under your home directory. This file can be recalled later
using the
+
+`-use' argument to comp:
+
+
+ comp -use
+
+
+The What now? level will permit you to do further editing and to send the
final
+
+draft when you are ready.
+
8
+
+
+ Send: When it is time to send the draft on its way, use the send
option by
+
+itself. If there are any problems with the draft (for example, if one or more
of the
+
+people whom you specified in the `To:' and `cc:' components do not
exist) then
+
+you will be notified at this time.
+
+
+Replying to Messages
+
+ To reply to a message, use the repl command. For example,
+
+
+ repl
+
+
+creates a reply to the current message. You may also reply to a specific
message
+
+(other than the current one) by giving a message number (e.g. `1' , `4' ,
etc.) or a
+
+message name (e.g. `first' , `last' , `prev' ):
+
+
+ repl prev
+
+
+We haven't really introduced message numbers yet. They will be discussed in
the
+
+next section.
+
+
+ The process of replying to a message is very similar to composing a
message
+
+from scratch (see the previous section), but repl conveniently
constructs and
+
+displays the header of the reply draft for you. You need only type in the
text of
+
+the reply. An EOT (usually CTRL-D) indicates that you are done typing. If you
+
+make a mistake, you may correct it later with a text editor. The draft will
be sent
+
+only if you give an explicit send command, so you do not have to worry about
the
+
+draft getting away from you prematurely.
+
+
+ An example of a complete reply draft, as it appears on your screen
might be:
+
+
+ To: MRose
+
+ cc: JSweet
+
+ Subject: Re: UCI Software Talk
+
+ In-reply-to: Your message of 10 Oct 84 18:15:08 PDT (Wed).
+
+ --------
+
+ I'll be there.
+
+ -jns
+
+ ^D
+
+
+(The "^D" does not appear in the draft.)
+
+
+ At this point, you are asked
+
+
+ What now?
+
+
+This is known as being at What now? level. Refer to the previous section
regarding
+
+how to edit, display, or send the draft at this point.
+
9
+
+
+ As with comp, if you quit without sending the reply draft, the draft
is saved
+
+in a file called Mail/draft under your home directory. This file can be
recalled later
+
+using the `-use' argument to comp:
+
+
+ comp -use
+
+
+The What now? level will permit you to do further editing and to send the
final
+
+draft when you are ready.
+
+
+
+Scanning Messages
+
+ The scan listing created by inc shows the message number, the date on
which
+
+the message was sent, the sender, and the subject of the message.
If there is
+
+sufficient space remaining on the line, the beginning of the text of the
message is
+
+displayed as well, preceded by two left angle brackets (" <<"). An example of
a
+
+scan listing is:
+
+ 1+ 10/10 WESTINE% USC-ISIF RFC 916 Now Available
<<A new Request for Co
+ 2 10/10 G B Reilly Gosling EMACS manual
<<Marshall, I am lookin
+ 3 10/11 WESTINE% USC-ISIF Internet Monthly Report
+
+
+Note that all messages have message numbers.
+
+
+ To generate your own scan listing, use the scan program. Typing simply
+
+
+ scan
+
+
+will list all the messages in the current folder. To scan a subset of these
messages,
+
+you can specify the numbers of the messages that you consider interesting,
e.g.,
+
+
+ scan 2 3
+
+
+Message names may be specified in addition to discrete message numbers. The
+
+built-in message names recognized by MH are:
+
+
+ all_: all messages in the folder (`first-last' )
+
+
+ first_: the first message in the folder
+
+
+ last_: the last message in the folder
+
+
+ prev__: the message immediately before the current message
+
+
+ cur__: the current message
+
+
+ next__: the message immediately after the current message
+
10
+
+
+ Message ranges may be specified in addition to discrete message
numbers or
+
+names by separating the beginning and final message numbers with a dash ("-").
+
+For example,
+
+
+ scan 5-10
+
+
+scans messages 5 through 10 inclusive. A range of messages may also be
specified
+
+by separating a beginning message number and a relative number of messages with
+
+a colon (":"). For example,
+
+
+ scan last:3
+
+
+scans the last three messages in the folder. Similarly,
+
+
+ scan first:3
+
+
+scans the first three messages in the folder;
+
+
+ scan next:3
+
+
+scans the next three messages;
+
+
+ scan cur:3
+
+
+scans the three messages beginning from the current message;
+
+
+ scan 100:4
+
+
+scans four messages beginning from message number 100.
+
+
+ To summarize, the important concepts that have been discussed
in the
+
+section are: message ranges, message numbers, and message names. When an MH
+
+command is described as taking a `msg' argument, it accepts either a
message
+
+name or a message number. Most MH commands are described as taking `msgs'
+
+arguments, meaning that more than one message or message range is accepted.
+
+
+
+Deleting Messages
+
+ To delete a message, use the rmm program. By default, rmm deletes
the
+
+current message, but you can give rmm a list of messages to be removed as well.
+
+There is no corresponding "unrmm" program, but clever users with a need will
+
+find out how to change the way rmm works so that it simply moves messages to
+
+another folder (say, `+wastebasket' ).
+
11
+
+
+Filing Messages
+
+ The possibility of having folders other than ``+inbox'' has been
mentioned
+
+previously. The methods for moving messages between folders and manipulating
+
+folders are discussed here.
+
+
+ The refile command moves messages from a source folder to
one or more
+
+destination folders. By default, the current message is moved from the
current
+
+folder (typically `+inbox' ) to another folder specified as an argument to
refile.
+
+For example,
+
+
+ refile +todo
+
+
+moves the current message from the current folder to the folder ``+todo''
. To
+
+move messages from a folder other than the current folder, use the `-src
+folder'
+
+switch, as in
+
+
+ refile -src +todo last +save +notes
+
+
+which moves the last message in the ``+todo'' folder to the folders
``+save''
+
+and ``+notes'' . Note that this operation is a move, not a copy; it
removes the
+
+message from the source folder. To keep a copy in the source folder as well,
use the
+
+`-link' switch
+
+
+ refile -link -src +todo last +save +notes
+
+
+
+ Whenever a folder argument is given to an MH command, that folder
becomes
+
+the current folder. To find out which folder is current, use the command
+
+
+ folder
+
+
+The inc command sets the current folder back to `+inbox' by default. To
find out
+
+about all of a user's folders, use the command
+
+
+ folders
+
+
+Since folders can contain other folders, the command
+
+
+ folders -recurse
+
+
+will recursively examine each folder for you.
+
+
+ To set the current folder, without doing anything else, use the folder
program
+
+with a folder argument. Hence,
+
+
+ folder +inbox
+
+
+makes ``+inbox'' the current folder.
+
12
+
+
+ After a using rmm and refile on a folder a number of times,
there tend to be
+
+ gaps in the numbering sequence. To compress the numbers for the all
messages in
+
+ a folder, use
+
+
+ folder -pack
+
+
+
+ The Profile
+
+ You can customize the MH environment by editing your
.mh_profile file.
+
+ Although there are lots of options, here are the most useful:
+
+
+ Editor___: lists the default editor that comp and repl should use.
The default is
+
+
+ editor: prompter
+
+
+ but another editor might be preferred.
+
+
+ editor-next____: lists the editor that should be used after the last edit
with editor. Hence,
+
+ if you have a profile entry
+
+
+ prompter-next: vi
+
+
+ after editing a draft with prompter, and being at What
now? level, you
+
+ could say ``edit'' (instead of ``edit vi'' )
to continue to edit the
+
+ draft with vi.
+
+
+ Msg-Protect________:Whenever MH creates a message (for example, with inc),
this is the
+
+ octal protection mode that the message is created with.
The default is
+
+
+ Msg-Protect: 644
+
+
+ This protection mode permits all other users on
the system to read
+
+ your messages. To maintain privacy, the mode 600
should be used.
+
+ Note that changing the mode in the profile does not
change the modes
+
+ of messages that have been created already. Use the
UNIX command
+
+ chmod to change the modes of your existing messages.
+
+
+Folder-Protect______________:Whenever MH creates a folder (for example,
with refile), this is the
+
+ octal mode that the folder is created with. The default
is
+
+
+ Folder-Protect: 711
+
+
+ This mode permits other users on the system to make
access to specific
+
+ messages in your folders. To maintain stricter privacy,
the mode 700
+
+ should be used.
+
13
+
+
+ program____: Each MH program that reads user's .mh_profile file looks
for an entry
+
+ beginning with its own name to determine its initial
defaults. For
+
+ example, if you want the default editor for repl to be emacs,
the line
+
+
+ repl: -editor emacs
+
+
+ is sufficient. Command line arguments tend to override profile
settings.
+
+ Given the profile setting for repl above, if you invoked repl
with
+
+
+ repl -editor vi
+
+
+ repl would use the vi editor instead of emacs.
+
+
+signature____: When MH posts mail for you, it looks for this profile entry
for your
+
+ "real world" name. For example,
+
+
+ signature: Marshall Rose
+
+
+ The contents of the ``signature:'' entry in the
profile should be a
+
+ simple phrase, with no embedded periods (e.g. "Marshall T.
Rose").
+
+
+
+Note that your profile resembles the header portion of a message. Be sure
that it is
+
+properly formatted by placing a colon after each entry name, and keep each
entry
+
+on a single line.
+
+
+
+Conventions
+
+ Now let's summarize the conventions that MH programs use:
+
+
+ 1. Any MH command that deals with messages can be given a `+folder'
+
+ argument to say which folder to use. However, only one
`+folder'
+
+ argument may be given per command in most cases.
+
+
+ 2. If an MH command accepts a `msgs' argument, then any number
of
+
+ messages can be given to the command. The MH command will
expand
+
+ all the ranges and process each message, starting with
the lowest
+
+ numbered one and working its way to the message with
the highest
+
+ number.
+
+
+ 3. If an MH command accepts a `msg' argument, then at most one
message
+
+ can be given.
+
+
+ 4. Switches (options) to MH commands start with a dash.
Unlike the
+
+ standard UNIX convention, each switch consists of more
than one
+
+ character, for example `-header' . To minimize typing,
only a unique
+
+ abbreviation of the switch need be typed; thus for `-header'
, `-hea'
+
+ is probably sufficient, depending on the other switches
accepted by the
+
+ command.
+
14
+
+
+ 5. All MH commands have a `-help' switch, which
must be spelled
+
+ out fully. When an MH command encounters the `-help'
switch, it
+
+ prints out the syntax of the command, the switches
that it accepts,
+
+ and version information. In the list of switches,
parentheses indicate
+
+ required characters. For example, all `-help'
switches will appear as
+
+ `-(help)' , indicating that no abbreviation is
accepted.
+
+
+ 6. Many MH switches have both on and off forms, such as
`-format' and
+
+ `-noformat' . In these cases, the last occurrence
of the switch on the
+
+ command line determines the setting of the option.
+
+
+ 7. All MH commands that read your MH profile operate the same
way:
+
+ first_, the profile is consulted for an entry matching the
name with which
+
+ the command was invoked; second___, if such an entry was
found, then the
+
+ command immediately uses the arguments listed; third__,
any arguments
+
+ on the command line are then interpreted. Since most
switches have
+
+ both on and off forms, it's easy to customize the default
options for each
+
+ MH command in the .mh_profile , and to override those
defaults on the
+
+ command line.
+
+
+
+ Online Documentation
+
+ Each MH program has its own UNIX manual entry. For
example, to get
+
+ information about comp, type
+
+
+ man comp
+
+
+ The manual entry for mh(1) lists all MH commands, while the manual entry
for
+
+ mh-chart (1) lists the syntax and switches for all MH commands.
+
+
+ In addition, here are a few other manual entries might be found
useful:
+
+
+ mh-alias (5) to find out how aliases in MH work;
+
+
+ mh-mail (5) to find out how MH stores and interprets messages (this
manual entry
+
+ explains all of the standard header components);
+
+
+mh-profile(5) to find out about the MH user-environment.
+
+
+ The manual pages for MH are in the standard UNIX
format, but contain
+
+ additional sections unique to MH. Here's a summary of the sections one
might find
+
+ in an MH manual entry:
+
+
+ Name command name and one-line description.
+
+
+ Synopsis syntax of the command.
+
+ All commands accept a `-help' switch.
+
15
+
+
+Description semantics of the command.
+
+
+ Files files used by the command
+
+ Almost always this includes .mh_profile .
+
+
+ Profile entries in the .mh_profile used by the command;
+
+Components these do not include the profile entry for the command
itself.
+
+
+ See Also other UNIX manual entries (usually MH programs) that are
related to
+
+ this command.
+
+
+ Defaults default arguments for the command
+
+ If the command takes a `+folder' argument,
this defaults to the
+
+ current folder. If the command takes a `msg'
argument, this defaults
+
+ to the current message. If the command takes a `msgs'
argument, this
+
+ defaults to the current message or all messages,
depending on which one
+
+ makes more sense.
+
+
+ Context changes to your MH context made by the command.
+
+
+ Hints Helpful hints discussing the easy way to do things.
+
+
+ History A historical perspective on why MH works the way it does.
+
+
+ Bugs Too embarrassing to mention.
+
+ Just kidding.
+
+
+
+ Obviously, not all MH manual entries may have all of these sections.
+
+
+
+ Reporting Problems
+
+ If problems are encountered with an MH program, the problems
should be
+
+ reported to the local maintainers of MH. When doing this, the name of
the program
+
+ should be reported, along with the version information for the program.
To find
+
+ out what version of an MH program is being run, invoke the program with
the
+
+ `-help' switch. In addition to listing the syntax of the command,
the program
+
+ will list information pertaining to its version. This information
includes the version
+
+ of MH, the host it was generated on, the date the program was loaded,
and the
+
+ configuration options in effect when MH was generated. For example,
+
+
+ version: MH 6.1 #1[UCI] (gremlin) of Wed Nov 6
01:13:53 PST 1985
+
+ options: [BSD42] [MHE] [NETWORK] [SENDMTS] [MMDFII]
[SMTP] [POP]
+
+
+ The ``6.1 # 1[UCI]'' indicates that the program is from
the UCI mh.6
+
+ version of MH. The program was generated on the host
``gremlin'' on
+
+ ``Wed Nov 6 01:13:53 PST 1985'' . It's usually a good
idea to send the output
+
+ of the `-help' switch along with your report.
+
16
+
+
+ If there is no local MH maintainer, try the address Bug-MH. If that
fails, use
+
+the Internet mailbox address@hidden
+
+
+
+More on MH
+
+ There are myriad aspects of MH that this tutorial hasn't touched upon.
Here
+
+are a few to whet your appetite:
+
+
+ 1. user-defined sequences
+
+ Define meaningful message names and shorten type-in
considerably (see
+
+ pick (1) for details).
+
+
+ 2. draft folders
+
+ Maintain a folder of drafts so that more than one draft can be
edited
+
+ at a time, and allow a draft to be edited over several UNIX
sessions
+
+ independently of other drafts (see the Advanced Features
section of
+
+ the MH user's manual for details).
+
+
+ 3. draft pushing
+
+ Post a draft in the background and immediately free your
terminal for
+
+ other activities (see the Advanced Features section of the MH
user's
+
+ manual for details).
+
+
+ 4. aliases
+
+ Maintain one or more alias files containing the addresses of
the people
+
+ frequently (or infrequently) sent to. This lets you shorten
type-in of
+
+ addressees and saves you from looking up their addresses all
the time.
+
+ (see mh-alias (5) for details).
+
17
+
+
+ References
+
+
+
+[MRose84] M.T. Rose. The Rand MH Message Handling System: The
UCI
+
+ BBoards Facility. Department of Computer and Information
Sciences,
+
+ University of Delaware (October, 1984).
+
+
+
+[MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
+
+ User's Manual. UCI Version. Department of Information and
Computer
+
+ Science, University of California, Irvine (January, 1985).
+
+
+
+[MRose85b] M.T. Rose. The Rand MH Message Handling System:
Administrator's
+
+ Guide. UCI Version, MH Classic. Northrop Corporation,
Research and
+
+ Technology Center (July, 1985).
+
+
+
+[SPayn85] S. Payne MH5: Electronic Mail. Rand Note #N-2281-RCC.
The
+
+ Rand Computation Center, Rand, 1700 Main St., Santa Monica, CA
+
+ 90406-2138 (May, 1985).
+
+
+
+
+ Contents
+
+
+
+
Page
+
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 1
+
+ Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1
+
+ Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1
+
+ How To Use This Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 2
+
+ Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 2
+
+ Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 3
+
+ Messages and Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 3
+
+ Reading New Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 4
+
+ Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 5
+
+ Originating Messages . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 5
+
+ Replying to Messages . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 8
+
+ Scanning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 9
+
+ Deleting Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 10
+
+ Filing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 11
+
+ The Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 12
+
+ Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 13
+
+ Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 14
+
+ Reporting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 15
+
+ More on MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 16
+
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 17
+
+
+
+ _____________________________________
+This document (version #2.8) was TEXset April 12, 1990 with DISS.STY v103.
+
+
+
+ i
-----------------------------------------------------------------------
Summary of changes:
docs/historical/ADMIN-19910201.txt | 2729 ++++
docs/historical/ADMIN.pdf | Bin 0 -> 73969 bytes
docs/historical/ADMIN.txt | 2904 +++++
docs/historical/MH-19910201.txt |11145 +++++++++++++++++
docs/historical/MH-19921214.pdf | Bin 0 -> 370626 bytes
docs/historical/MH-19921214.txt |13134 ++++++++++++++++++++
docs/historical/MH.pdf | Bin 0 -> 335164 bytes
docs/historical/MH.txt |11880 ++++++++++++++++++
docs/historical/README | 108 +
docs/historical/bboards.pdf | Bin 0 -> 177140 bytes
docs/historical/bboards.txt | 965 ++
docs/historical/beginners.pdf | Bin 0 -> 177216 bytes
docs/historical/beginners.txt | 1011 ++
docs/historical/changes.pdf | Bin 0 -> 43780 bytes
.../changes.txt} | 1029 ++-
docs/historical/designOfMH.pdf | Bin 0 -> 780758 bytes
docs/historical/mh-gen.pdf | Bin 0 -> 51927 bytes
docs/historical/mh-gen.txt | 1452 +++
docs/historical/mh4mm.pdf | Bin 0 -> 154597 bytes
docs/historical/mh4mm.txt | 1168 ++
docs/historical/mh6.pdf | Bin 0 -> 204281 bytes
docs/historical/mh6.txt | 1030 ++
docs/historical/multifarious.pdf | Bin 0 -> 322114 bytes
docs/historical/multifarious.txt | 2284 ++++
docs/historical/mznet.pdf | Bin 0 -> 182926 bytes
docs/historical/mznet.txt | 1103 ++
docs/historical/realwork.pdf | Bin 0 -> 327146 bytes
docs/historical/realwork.txt | 2445 ++++
docs/historical/trusted.pdf | Bin 0 -> 315670 bytes
docs/historical/trusted.txt | 2283 ++++
docs/historical/tutorial.pdf | Bin 0 -> 196888 bytes
docs/historical/tutorial.txt | 1389 +++
32 files changed, 57728 insertions(+), 331 deletions(-)
create mode 100644 docs/historical/ADMIN-19910201.txt
create mode 100644 docs/historical/ADMIN.pdf
create mode 100644 docs/historical/ADMIN.txt
create mode 100644 docs/historical/MH-19910201.txt
create mode 100644 docs/historical/MH-19921214.pdf
create mode 100644 docs/historical/MH-19921214.txt
create mode 100644 docs/historical/MH.pdf
create mode 100644 docs/historical/MH.txt
create mode 100644 docs/historical/README
create mode 100644 docs/historical/bboards.pdf
create mode 100644 docs/historical/bboards.txt
create mode 100644 docs/historical/beginners.pdf
create mode 100644 docs/historical/beginners.txt
create mode 100644 docs/historical/changes.pdf
copy docs/{ChangeLog_MH-6.7.0_to_MH-6.8.4.html => historical/changes.txt} (53%)
create mode 100644 docs/historical/designOfMH.pdf
create mode 100644 docs/historical/mh-gen.pdf
create mode 100644 docs/historical/mh-gen.txt
create mode 100644 docs/historical/mh4mm.pdf
create mode 100644 docs/historical/mh4mm.txt
create mode 100644 docs/historical/mh6.pdf
create mode 100644 docs/historical/mh6.txt
create mode 100644 docs/historical/multifarious.pdf
create mode 100644 docs/historical/multifarious.txt
create mode 100644 docs/historical/mznet.pdf
create mode 100644 docs/historical/mznet.txt
create mode 100644 docs/historical/realwork.pdf
create mode 100644 docs/historical/realwork.txt
create mode 100644 docs/historical/trusted.pdf
create mode 100644 docs/historical/trusted.txt
create mode 100644 docs/historical/tutorial.pdf
create mode 100644 docs/historical/tutorial.txt
hooks/post-receive
--
The nmh Mail Handling System
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 9b152e23db633c49c43313a2ef26ebc0951cc874,
David Levine <=