4.4BSD/usr/src/contrib/mh-6.8/papers/realwork/text.tex

Compare this file to the similar file:
Show the results in this format: 

% begin text

\banner

\section{Introduction}				% mtr
The UCI version of the Rand Message Handling System, \MH/,
is a software system that performs two functions:
\underbar{first},
it interfaces a user to a message transport system,
so the user may receive and send mail;
\underbar{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, \mh5,
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 \mh5
provided tremendous help in stabilizing the current release.

\MH/ runs on different versions of the \unix/ operating system
(such as Berkeley~4.2\bsd/ and various flavors of v7).
In addition,
\MH/ supports four different message transport interfaces:
\SendMail/\cite{EAllm83},
the standard mailer for 4.2\bsd/ systems;
\MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84},
the Multi-Channel Memo Distribution Facility developed by the University of
Delaware
which forms the software-backbone for CSnet\cite{DCome83} mail relay service;
SMTP,
the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
and,
a stand-alone delivery system.

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 {\it draft} handling.
In addition,
user interface issues in mail handling are addressed,
and the merits of \MH/'s approach is critically examined.
Next,
the \mh5 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.

\section{The \MH/ Philosophy}			% mtr
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 {\it C} shell or the {\it 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 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.
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.

\subsection{The \MH/ Environs}			% jlr
In the \file{\$HOME} directory of each \MH/ user, a file named
\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:
\example program-name:\ options\endexample
Each \MH/ program consults the user's \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 \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 \pgm{prompter}
(a simple prompting editor front-end)
under the name \pgm{rapid} in the
user's \file{bin/} directory, and add to the \profile/:
\example rapid:\ -prepend\ -rapid\endexample
As a result,
when \pgm{prompter} is invoked as \pgm{rapid},
it automatically uses the \switch{prepend} and \switch{rapid} options.

The profile component \eg{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 {\it skeletons} and
{\it templates} used by the \MH/ programs,
and the user's \context/ file.
This latter file has the same format as the user's \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 {\it 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 \file{context}
component \eg{Current-Folder:}.
Every folder has a {\it current message} known as \arg{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 \file{\$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 {\it folder} argument,
such as \arg{+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 a \switch{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 \arg{msg} or \arg{msgs} argument
which takes the form of a message number (\eg{1}), a message range (\eg{1-2}),
a standard sequence name (\eg{cur}),
or a user-defined sequence name (\eg{select}).

\tagdiagram{1}{An \MH/ Session}{session}
\subsection{An \MH/ Transcript}			% jlr
Figure~\session\ contains a transcript of a simple \MH/ session.
First, \pgm{inc} is run to incorporate the new mail into the 
user's \eg{+inbox} folder.

A \pgm{scan} listing of the mail is printed while
it is being incorporated.
(The user could run \pgm{scan} explicitly to generate additional \pgm{scan}
listings later on.)
The \pgm{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 \eg{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 \eg{<<}.
The plus sign (`+') after
the message number indicates the current message.

The user \pgm{show\/}s the message, and decides to \pgm{repl\/}y.
A reply draft
is created using the headers of the message being replied-to,
using the default \file{replcomps} template.
The default editor, \pgm{prompter}, is called to edit the draft.
When an EOT is typed, \pgm{prompter} exits and the
user is left at the \whatnow/ prompt.
The option \pgm{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, \file{components}, is copied to the draft,
and \pgm{prompter} is once again called.
After entering the addresses, subject, and body,
the user then \pgm{send\/}s the \file{draft} from the \whatnow/ prompt,
using \eg{send\ -verbose}, which causes
\MH/ to list out the message addresses as it submits them
to the message transport system.

\section{Some \MH/ Features}			% mtr
We now consider certain advanced features in \MH/.
These features have been chosen to demonstrate some useful capabilities
available to the \MH/ user.

\subsection{Message Sequences and Selection}	% jlr
\MH/ has several built-in message sequence names, which may
be used anywhere a \arg{msg} or \arg{msgs} argument is expected.
These are:
\arg{cur}, \arg{next}, \arg{prev}, \arg{first}, \arg{last}, and \arg{all}.
Message ranges may also be specified.
For example, \arg{all} is actually \arg{first-last}, and
\arg{+mh\ last:5} references the last five messages in your
\arg{+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 \pgm{pick} and \pgm{mark} commands can create and modify 
user-defined message sequences.
The \pgm{mark} command allows low-level manipulation of sequences,
and is not particularly interesting in our discussion.

The \pgm{pick} command selects certain messages out of a folder.
The criteria used for selection may be a search string and/or a date range.

Searching is performed on either a specific header in the message
(e.g., \eg{To:}),
or anywhere within the message.
By default,
\pgm{pick} lists out the message numbers that matched
the selection criteria.
Thus, \pgm{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:
\example scan\ \bq{pick\ -from\ frated}\endexample
To perform more complicated message selection,
user-defined sequences are employed.
Supplying a \switch{sequence\ name}
argument to \pgm{pick}, will cause it to define the
sequence \arg{name} as those messages matched.

Giving \pgm{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:
\example pick\ -from\ frated\ -sequence\ select\\
	 pick\ select\ -before\ friday\ -sequence\ select\endexample
With the first \pgm{pick} command,
the sequence \eg{select} is defined
to be all those messages from ``frated''.
In the second command, only those messages already in the \eg{select}
sequence are searched, and the \eg{select} sequence is redefined to be
only those messages which are also
dated before friday.
Those messages could then be \pgm{show\/}n with:
\example show\ select\endexample
When a \switch{sequence\ name} argument is given to \pgm{pick},
the default behavior --- listing the message numbers
matched --- is inhibited.
To re-enable this behavior, the \switch{list} option may be given.
As a result,
advanced users of \MH/ often put the following line in their \profile/:
\example pick:\ -sequence\ select\ -list\endexample
which allows them to easily make use of the \arg{select} sequence as the
messages last selected with \pgm{pick}.

Often it is desirable to act upon those messages which
are {\it not} members of a given sequence.
For this purpose,
the \eg{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 {\it not} members
of that sequence.
For example, given a profile entry of:
\example Sequence-Negation:\ not\endexample
those messages which
are not in the \arg{select} sequence could be \pgm{scan\/}'d with:
\example scan\ notselect\endexample

Obviously, some confusion could result if an attempt was made
to define a sequence name
which began with the sequence-negation string (e.g., \eg{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 {\it C} Shell users,
and exclamation-mark (`!') for {\it 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
\eg{Previous-Sequence:}.

\subsection{Draft Handling}			% jlr
After the initial edit of a message draft,
the \pgm{comp}, \pgm{dist}, \pgm{forw}, and \pgm{repl} programs
give the user a \whatnow/ prompt.
The valid responses include:
\pgm{edit} to re-edit the draft,
\pgm{quit} to exit without sending the draft,
\pgm{send} to send the draft, and
\pgm{push} to send the draft in the background.

When the \pgm{send} option is given,
the draft is posted with the message transport system.
If there problems posting the draft,
the \whatnow/ prompt is re-issued,
so errors in the draft may be corrected.

Since posting the draft can be slow,
the \pgm{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 \pgm{push} is used instead of \pgm{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 \eg{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 \profile/:
\example Draft-Folder:\ +foldername\endexample
From this point on,
when a message is composed,
the draft will be created as a message in that folder,
instead of using the \file{draft} file in the user's \MH/ directory.
Unfortunately,
if posting problems occur on a message which has been \pgm{push\/}'d,
it may be difficult to re-edit the draft with
\eg{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,
\pgm{push} assumes the \switch{forward} option,
which says that if the message draft fails to be posted,
it should be forwarded back to the user in the
error report which \pgm{push} generates.
The failed draft may then be extracted with the \pgm{burst} program
(discussed later).

\subsection{BBoards}				% 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.

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
{\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},
who is the person that runs the group.
This moderator can usually be reached at a special address,
known as the {\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 (hopefully related) messages
are put into a {\it 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 {\it 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 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 {\it 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 {\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 manually perform 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-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.%
\nfootnote{When the message transport system delivers a message to a user
it stores it in a single file, called a {\it 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 \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/
programs to accomplish complicated or specialized tasks.

\tagdiagram{7}{The \pgm{mpick} Script}{mpick}
For example,
in the \MH/ distribution there is a shell script
called \pgm{mpick} (shown in Figure~\mpick)
which tries to locate all the messages which pertain to a given discussion,
by looking at the \eg{Message-ID:} and \eg{In-reply-to:} headers,
to find matching message-ids.%
\nfootnote{Note that the shell scripts included in the \MH/ distribution
are written for the {\it 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.}

\tagdiagram{8}{The \pgm{append} Editor}{appended}
Unfortunately, some parts of \MH/ are somewhat monolithic.
An example of this is the \whatnow/ 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 \whatnow/ prompt, such as an \pgm{insert-file} option.
It was argued that just about any editor would allow you to 
insert a file, and another \whatnow/ option was not needed.
These users persisted, however, so the
problem was solved, by writing a trivial shell
script ``editor'' (see Figure~\appended)
which could be invoked by the \pgm{edit} option:
\example What now?\ edit\ append\ filename\endexample

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
{\it instead} of the \whatnow/ prompt,
and setup certain envariables so that
the \MH/ commands would act upon the \file{draft} by default.
For example, \pgm{show} with no \arg{msgs} arguments
would show the draft instead of the current message.
This alternative has recently been implemented and is under testing.

\section{The \MH/ Distribution}			% mtr
The \mh5 distribution is now briefly described,
both in terms of static configuration methods
and dynamic tailoring.
Appendix~B describes the mechanics of receiving an \mh5 distribution.

\subsection{Configurable \MH/}			% jlr
The \MH/ distribution currently runs on a large number of different \unix/
versions,
ranging from MicroSoft XENIX to Berkeley 4.2\bsd/.
All the code which is specific to a particular target environment is
enabled via the C-preprocessor \eg{\#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.

\tagdiagram{9}{Sample \MH/ Configuration File}{mhconfig}
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~\mhconfig.

After creating this file (several examples are included in the distribution),
the installer runs the \pgm{mhconfig} program,
which customizes the \file{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.

\subsection{Interface to the Message Transport System}	% jlr & mtr
\MH/ will run with a number of message transport systems,
including \SendMail/, \MMDFII/, 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).

\tagdiagram{10}{Sample MTS Tailor File}{mtstailor}
Those parts of \MH/ which interact with the local message transport agent
read additional tailoring information when they start.%
\nfootnote{This simple facility is based on a more extensive
tailoring capability found in \MMDFII/.}
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~\mtstailor.

A continuing question which is often raised is how intelligent should user
agents (like \MH/ and UCB \pgm{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 \MMDFII/ really gets this right
(flames to \file{/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 provide equal time to those who hold opposite views,
\MH/ supports a configuration option called \eg{DUMB} which disables \MH/'s
attempts to resolve addresses into fully-qualified strings.

\section{Concluding Remarks}			% jlr and mtr
While \MH/ has undergone significant development since
the original
Rand release, the authors have
tried to keep the fundamental concepts of
\MH/ unchanged.
						% specific vs. general
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 \pgm{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 \pgm{dist} repeatedly,
perhaps with ``canned'' arguments so the user typed in addressing information
only once, would easily meet this request.

						% generality
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 \eg{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.

						% naive user :: MH
\MH/ has a powerful tailoring capability provided by the \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/ {\it 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.

						% speed consideration
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 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 \pgm{push} option
was added at the \whatnow/ 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 \pgm{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 \file{draft} file.

Gradually, other features were added to \pgm{push}.
Since users wanted to be able to send more than one draft
at a time, \pgm{push} was changed to optionally
rename the draft file before posting it.
(This is what the hidden \switch{unique} option does.)
Having message transport system diagnostics
written asyncronously on the user's terminal was annoying,
so \pgm{push} was made to intercept these diagnostics,
and mail the user a report containing them.
Although the diagnostic report mailed back by \pgm{push} contains
the name of the draft which failed,
a useful added feature was the ability to have \pgm{push}
include the failed draft as well.
Eventually, the draft-folder mechanism was implemented to make
handling multiple message drafts much easier.


\subsection{TODO}				% mtr
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:
\smallskip
{\advance\leftskip by\parindent
\item{1.} Performance Enhancements\hbreak
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 \pgm{Mail}.
It would be nice if \MH/ could be tuned or accelerated somehow.

\item{2.} Port to System~5\hbreak
\MH/ runs on 4.2\bsd/~\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.

\item{3.} Interface to the Network News\hbreak
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.

\item{4.} Programmed Instruction for Beginners\hbreak
The complexity of \MH/ is often intimidating to new users.
It would be nice to develop a set of \pgm{learn} lessons for those users who
don't like \pgm{man} pages and non-interactive tutorials.

\item{5.} Message List Expansion\hbreak
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., \eg{show\ 2\ 1} \pgm{show\/}s message~1
and then message~2).
It would be nice if \MH/ processed messages in the order
they were given.

\item{6.} Context Changes\hbreak
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.
\par}