text.tex

早期freebsd实现

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 \pgm{msg} program available with \MMDFII/
and by \pgm{msh} as well.}
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.

\subsection{Bursting}			% jlr
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 \pgm{burst} program allows the \MH/ user to extract these digest
messages,
and store each as an individual \MH/ message.

\pgm{Burst} will also extract forwarded messages generated by \pgm{forw}
(or the forwarded message in the error report generated by \pgm{push},
as described above).
Although \pgm{burst} cannot always decapsulate
messages encapsulated by sites not running \MH/,
it adheres to the proposed standard described in \cite{MRose85b}.

\subsection{Distributed Mail}			% mtr
The ARPA Internet community consists of many types of heterogeneous nodes.
Some hosts are large mainframe computers,
others are personal workstations.
All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}.
Messages which conform to the Standard for the Format of ARPA Internet Text
Messages\cite{DCroc82}
are exchanged using the Simple Mail Transfer Protocol\cite{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 {\it service} host) offers
a maildrop service to these less endowed nodes
(known as {\it client} hosts).
The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a
workstation to dynamically access a maildrop on a service host to pick-up
mail.%
\nfootnote{Actually,
there are three different descriptions of the POP.
The first, cited in \cite{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\cite{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.}
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 \pgm{post} program will attempt to establish an SMTP connection
with each host in the search-list to post the message until it succeeds.
Initial experimentation using the POP and \MH/
in a local network environment has proved quite successful.

\section{User Interface Issues in \MH/}		% mtr
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.

\subsection{Creeping Featurism}			% mtr
A complaint often heard about systems which undergo substantial development
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 {\it 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 \pgm{send} command has twenty-five visible switches,
and at least nine hidden switches,
for a total of thirty-four.
The poor user who types \example send\ -help\endexample watches the options
scroll off the screen
(since the \switch{help} switch also lists out four other lines of
information).%
\nfootnote{Recently,
this was fixed by compressing the way in which switches are presented.
The solution is only temporary however,
as \pgm{send} will no doubt acquire an {\it endless} number of switches in
the years to come.}
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.

\subsection{Templates versus Switches}		% mtr
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 {\it on} or {\it 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.

\tagdiagram{2}{Draft Skeleton}{components}
The \pgm{comp}, \pgm{dist}, and \pgm{forw} programs
use draft {\it 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 \pgm{comp\/}) is shown in Figure~\components.
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 \eg{Fcc:} field already contains a value.
By using the simple prompting editor, \pgm{prompter},
the user can speedily enter the headers of the message.
The \pgm{prompter} program given the skeleton in Figure~\components\ would
prompt the user for the contents of each field,
except for the second \eg{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 {\it any} editor to edit {\it 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.

\tagdiagram{3}{Reply Template}{replcomps}
Another more interesting approach is used by the \pgm{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 {\it template}, was made available.
An example of a reply template is shown in Figure~\replcomps.
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,
\pgm{repl} generates the reply draft automatically.

\tagdiagram{4}{The \file{tripcomps} Reply Template}{tripcomps}
This facility, for example,
can be used to generate automatic replies.%
\nfootnote{\MH/ supports the notion of a user-defined {\it mail hook}
which is invoked each time a user receives mail.}
One function might be to write a \pgm{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~\tripcomps.

\tagdiagram{5}{The \file{bombcomps} Reply Template}{bombcomps}
Finally,
another application might be to utilize
the highly useful letter bomb protocol.%
\nfootnote{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.}
The important thing to note about this template is that it generates not only
the headers of the reply draft (with a creative \eg{Reply-to:} address),
but the body as well.
Hence,
the commands
\example
    repl\ -form\ bombcomps\ -noedit\ ;\ rmm\\
    What\ now?\ push%
\endexample
are very handy for dealing with disturbing mail in a straight-forward manner.
Of course, \pgm{repl} could be linked to \pgm{bomb} in the user's \file{bin/}
directory and an appropriate line could be added to the user's \MH/ profile,
in order to further shorten type-in.

\tagdiagram{6}{Display Template}{mhlforward}
A variation on the reply template is the {\it display template}.
A display template, as used by the \pgm{mhl} program,
contains instructions on how to format a message.
In addition to being used by \pgm{show}, et.~al.,
the \pgm{forw} program can also use a display template to format each
message being forwarded.
Similarly,
although \pgm{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 \pgm{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~\mhlforward.

As with reply templates,
display templates can offer a lot of functionality.
For example,
the one line display template:
\example
    body:nocomponent,overflowtext=,overflowoffset=0,width=10000%
\endexample
can be used to extract the body of a message,
while ignoring the headers.
Hence,
if a \pgm{shar} archive arrived in the mail,
a convenient way to unpack it,
assuming the above display template was called \file{mhl.body},
would be:
\example show\ -form\ mhl.body\ |\ sh\endexample

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.

\subsection{Modularity versus Monolithicity}	% jlr
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/