text.tex

早期freebsd实现

% begin text
\banner
\section{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 {\sf SendMail},
and, in a more restricted form, under stand-alone \MH/.

\section{Disclaimer}
The Regents of the University of California wish to make it known that:
\bigquote
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.
\endbigquote

\section{Scope}
This document explains how to use the UCI BBoards facility to a user familiar
with \MH/ and the \unix/ 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 \cite{MH.TUT}).
Additional information on the programs discussed here
(particularly \pgm{bbc\/}) is to be found in \cite{MH}.

\section{Conventions}
In this document,
certain \TeX -formatting conventions are adhered to:
\smallskip
{\advance\leftskip by\parindent
\item{1.} The names of \unix/ commands, such as \pgm{comp},
are presented in {\it text italics}.
\item{2.} Arguments to programs, such as \arg{msgs},
are presented in {\tt typewriter style} and delimited by single-quotes.
\item{3.} \unix/ pathnames and envariables,
such as \file{/usr/uci/} and \file{\$SIGNATURE},
are presented in {\sl slanted roman}.
\item{4.} Text presenting an example, such as
\example comp\ -editor\ zz\endexample
is presented in {\tt typewriter style}.
\smallskip}

\section{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
{\it distribution} address.
From this distribution address, a copy of the message is sent to each
subscriber.
Each group has a {\it moderator},
which is the person that runs the the group.
This moderator can usually be reached at a special address,
known as a {\it 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 {\it 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 {\it personal} mail,
that is likely to be of a much more important and timely nature.

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 {\it 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 \eg{SF-Lovers@Rutgers},
a user of \MH/ usually sends to \eg{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.

Finally, the UCI BBoards facility supports {\it 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.

\section{BBoard Handling}
Usually the term {\it BBoard} is used interchangeably with the terms
{\it discussion group} and {\it 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.%
\nfootnote{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.}
Unlike the user's private maildrop however,
the \pgm{inc} program is not run to incorporate new BBoard messages into
the user's \MH/ \eg{+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 {\it BBoard-ID}, is always ascending.
The BBoard-ID of a message should {\bf 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 \pgm{bbc}.
The \pgm{bbc} program has several switches to direct it's action.
The \switch{topics} switch to \pgm{bbc} tells the \MH/ user about the
status of a BBoard.
The \switch{check} switch to \pgm{bbc} lets the \MH/ user check on the
activity of a BBoard.
The \switch{read} switch to \pgm{bbc} invokes the \pgm{msh} program on the
BBoard.
\pgm{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.

\subsection{BBoard status}
The \switch{topics} option to the \pgm{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 \example bbc\ -topics\endexample
then \pgm{bbc} will list the following information for all BBoards received
on the host:
\smallskip
{\advance\leftskip by\parindent
\item{$\bullet$} the official name of the BBoard
\item{$\bullet$} the number of messages delivered to the BBoard
(but not necessarily present)
\item{$\bullet$} the date and time of the last message delivered to the BBoard
\medskip}
\noindent
In addition to \switch{topics},
if the \switch{verbose} option is given to \pgm{bbc},
then more information is listed:
\smallskip
{\advance\leftskip by\parindent
\item{$\bullet$} any aliases the BBoard is known as
\item{$\bullet$} the local leaders of the BBoard
\item{$\bullet$} the file that the BBoard is locally delivered to
\item{$\bullet$} the ``global'' distribution address
\item{$\bullet$} the ``global'' request address
\item{$\bullet$} the host that distributes the BBoard to the local host
\item{$\bullet$} the addresses to which this host distributes
\item{$\bullet$} miscellaneous information (presently only archiving status)
\medskip}
\noindent
Naturally, \pgm{bbc} can be invoked with the \switch{topics} option and one or
more BBoard names listed on its command line.
For example \example bbc\ -topics\ unix-wizards\endexample is completely
acceptable~---~it tells \pgm{bbc} to report the status of the BBoard
\eg{unix-wizards}.

\subsection{BBoard checking}
The \switch{check} option to the \pgm{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 \example bbc\ -check\endexample and \pgm{bbc} consults
the profile entry for \eg{bboards:} in the user's \profile/ file.
For each BBoard listed,
\pgm{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 \eg{foo\/}):
\smallskip
{\advance\leftskip by\parindent
\item{1.} \eg{foo -- n items unseen}\hbreak
This message indicates items in the BBoard have not been seen by the user.
When \pgm{bbc} is invoked with the \eg{quiet} switch,
this is the only informative message that \pgm{bbc} will print out.
Users of \MH/ usually put \example bbc\ -check\ -quiet\endexample
in their \file{\$HOME/.login} file.

\item{2.} \eg{foo -- empty}\hbreak
The BBoard is empty.

\item{3.} \eg{foo -- n items (none seen)}\hbreak
The BBoard has $n$ items in it, but the user hasn't seen any.

\item{4.} \eg{foo -- n items (all seen)}\hbreak
The BBoard is non-empty, and the user has seen everything in it.

\item{5.} \eg{foo -- n items seen out of m}\hbreak
The BBoard has at most $m-n$ items that the user has not seen.
\medskip}
\noindent