--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/papers/realwork/text.tex	Mon Apr 18 23:46:02 2005 +0900
@@ -0,0 +1,1121 @@
+% 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}