text.tex

早期freebsd实现

\subsection{Distribution Lists}			% mtr
\MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.%
\nfootnote{The UCI BBoards facility can run under either the \MMDF/ or
\SendMail/,
or in a more restricted form under stand-alone \MH/.}
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.

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
{\it distribution} address (e.g., {\tx MH-Workers@UCI}).
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 group.
This moderator can usually be reached at a special address,
known as a {\it request} address (e.g., {\tx MH-Workers-Request@UCI}).
Usually, the responsibilities of the moderator are quite simple,
since the mail system handles distribution to subscribers automatically.
In some interest groups,
instead of each separate message being distributed directly to subscribers,
a batch of (related) messages are put into a {\it 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 {\it 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 {\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 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 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 {\tx 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,
the user need only know the name of an interest group and not its global
network 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.

\MH/ provides three programs to deal with interest groups.
The \pgm{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 \pgm{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 \pgm{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 \pgm{msh} is contrary to the \MH/
philosophy of using relatively small, single-purposed programs.
Sadly,
the authors 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.

\subsection{Encapsulation}			% mtr
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\cite{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\cite{FIPS98}
and the recent CCITT draft on Mail Handling Systems standards\cite{X.400}
both discourage the re-distribution facility in favor of forwarding
by encapsulation.

\subsection{Encapsulation and Blind-Carbon-Copies} % mtr
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:
{\it visible} and {\it blind}.
The visible recipients are listed as addresses in the \eg{To:} and \eg{cc:}
fields,
and the blind recipients are listed in the \eg{Bcc:} fields of the draft.
The idea behind this facility is that copies of the draft which are
delivered to the \eg{To:} and \eg{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 \eg{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 \eg{To:} and \eg{cc:} fields of the
draft sent to the blind recipients
(e.g., by prefixing the string \eg{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 \eg{Bcc:} fields.
The blind draft contains the visible message as a forwarded message.
The headers for the blind draft contain the minimal RFC822 headers
(\eg{From:} and \eg{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.

\section{\MH/ as a Record Handler}		% stef
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 \eg{X-}.

\MH/ carries though on this idea by allowing the \pgm{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 in \unix/ directories,
applications can be developed to apply any programmable process to
any selected message.

For example,
a {\it Time Card Form} might be called up by an \MH/ user with
\example comp\ -form\ timecomps\endexample
to enter time and attendance information into \eg{X-time$\tdots$:} fields in a
draft message record.
The \file{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