Return to text.tex CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / realwork

Annotation of 43BSD/contrib/mh/papers/realwork/text.tex, revision 1.1

1.1     ! root        1: % begin text
        !             2: 
        !             3: \banner
        !             4: 
        !             5: \section{Introduction}                         % mtr
        !             6: The UCI version of the Rand Message Handling System, \MH/,
        !             7: is a software system that performs two functions:
        !             8: \underbar{first},
        !             9: it interfaces a user to a message transport system,
        !            10: so the user may receive and send mail;
        !            11: \underbar{second},
        !            12: it permits the user to maintain an organized mail environment to facilitate
        !            13: the composition of new messages and the reading of old messages.
        !            14: In short,
        !            15: while not responsible for the delivery of messages,
        !            16: \MH/ aids the user in handling mail.
        !            17: 
        !            18: \MH/ was originally developed by the Rand Corporation,
        !            19: and initially was proprietary software.
        !            20: The Department of Information and Computer Science at
        !            21: University of California, Irvine,
        !            22: shortly after joining the Computer Science Network (CSnet),
        !            23: acquired a copy of \MH/,
        !            24: and began additional development of the software.
        !            25: Since that time,
        !            26: the Rand Corporation has declared \MH/ to be in the public domain,
        !            27: and the UCI version of \MH/ has passed through four major releases.
        !            28: The current version, \mh5,
        !            29: is available from U.C.~Irvine for a nominal distribution fee,
        !            30: or may be retrieved from the University of Delaware via anonymous FTP.
        !            31: 
        !            32: Much credit must be given to the initial designers and implementors of \MH/:
        !            33: Bruce Borden, Stockton Gaines, and Norman Shapiro.
        !            34: Although \MH/ has suffered significant development at UCI
        !            35: since Rand's initial release,
        !            36: the fundamental concepts of \MH/'s environs have remained nearly unchanged.
        !            37: In addition,
        !            38: the authors of the current release gratefully acknowledge the comments of the
        !            39: many sites which have run various releases of \MH/ in the past.
        !            40: In particular,
        !            41: the dozen or so beta test sites for \mh5
        !            42: provided tremendous help in stabilizing the current release.
        !            43: 
        !            44: \MH/ runs on different versions of the \unix/ operating system
        !            45: (such as Berkeley~4.2\bsd/ and various flavors of v7).
        !            46: In addition,
        !            47: \MH/ supports four different message transport interfaces:
        !            48: \SendMail/\cite{EAllm83},
        !            49: the standard mailer for 4.2\bsd/ systems;
        !            50: \MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84},
        !            51: the Multi-Channel Memo Distribution Facility developed by the University of
        !            52: Delaware
        !            53: which forms the software-backbone for CSnet\cite{DCome83} mail relay service;
        !            54: SMTP,
        !            55: the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
        !            56: and,
        !            57: a stand-alone delivery system.
        !            58: 
        !            59: This paper is organized in a straight-forward fashion:
        !            60: Initially,
        !            61: the \MH/ philosophy of mail handling is presented,
        !            62: along with a description of the environment which the \MH/ user is given to
        !            63: process mail.
        !            64: Following this,
        !            65: certain advanced features of \MH/ are discussed in more detail,
        !            66: such as facilities for selecting messages,
        !            67: and ``advanced'' concepts in {\it draft} handling.
        !            68: In addition,
        !            69: user interface issues in mail handling are addressed,
        !            70: and the merits of \MH/'s approach is critically examined.
        !            71: Next,
        !            72: the \mh5 distribution package is described.
        !            73: Finally,
        !            74: we conclude by discussing the authors' experience with \MH/ development
        !            75: and introducing areas where \MH/ may be further developed.
        !            76: 
        !            77: Although familiarity with \MH/ is not assumed on the part of the reader,
        !            78: some knowledge of the \unix/ operating system is useful.
        !            79: Appendix~A gives a short synopsis of the \MH/ commands.
        !            80: 
        !            81: \section{The \MH/ Philosophy}                  % mtr
        !            82: Although \MH/ has many traits which tend to distinguish it from other systems
        !            83: which handle mail,
        !            84: there is a single fundamental design decision which influences the interface
        !            85: between \MH/ and the user:
        !            86: \MH/ differs from most other systems in that it is composed of many small
        !            87: programs instead of one very large one.
        !            88: This architecture gives \MH/ much of its strength,
        !            89: since intermediate and advanced users are able to take advantage of this
        !            90: flexibility.
        !            91: 
        !            92: The key to this flexibility is that the \unix/ shell
        !            93: (usually the {\it C} shell or the {\it Bourne} shell),
        !            94: is the user's interface to \MH/.
        !            95: This means that when handling mail,
        !            96: the entire power of the shell is at the user's disposal,
        !            97: in addition to the
        !            98: facilities which \MH/ provides.
        !            99: Hence,
        !           100: the user may intersperse mail handling commands with other commands in an
        !           101: arbitrary fashion,
        !           102: making use of command handling capabilities which
        !           103: the user's shell provides.
        !           104: 
        !           105: Furthermore,
        !           106: rather than storing messages in a complicated data structure
        !           107: within a monolithic file,
        !           108: each message in \MH/ is a \unix/ file,
        !           109: and each folder (an object which holds groups of messages)
        !           110: in \MH/  is a \unix/ directory.
        !           111: That is,
        !           112: the directory- and file-structure of \unix/ is used directly.
        !           113: As a result,
        !           114: any \unix/ file-handling command can be applied to any message.
        !           115: 
        !           116: To the novice,
        !           117: this may not make much sense or may not seem important.
        !           118: However,
        !           119: as users of \MH/ become more experienced,
        !           120: they find this capability attractive.
        !           121: In addition,
        !           122: this approach is often quite pleasing to system implementors,
        !           123: because it minimizes the amount of coding to be performed,
        !           124: and given a modular design,
        !           125: changes to the software system can be maintained easily.
        !           126: There are, however, performance penalties to be paid with this scheme.
        !           127: This issue is considered later in the paper.
        !           128: 
        !           129: Having described how \MH/ fits into the \unix/ environment,
        !           130: we now discuss the mail handling environment which is available to the \MH/
        !           131: user.
        !           132: 
        !           133: \subsection{The \MH/ Environs}                 % jlr
        !           134: In the \file{\$HOME} directory of each \MH/ user, a file named
        !           135: \profile/ contains static information about the user's \MH/ environment, 
        !           136: and default arguments for \MH/ programs.
        !           137: For the latter case,
        !           138: each line of profile takes the form:
        !           139: \example program-name:\ options\endexample
        !           140: Each \MH/ program consults the user's \profile/ for its options.
        !           141: These options are consulted prior to evaluating any command-line arguments,
        !           142: and so provide the \MH/ user the capability to customize the defaults for each
        !           143: command.
        !           144: Futher, by using the \unix/ link facility,
        !           145: different names can be given to the same command.
        !           146: Since each \MH/ command looks
        !           147: in the \profile/
        !           148: for a component with the name by which it was invoked,
        !           149: it's possible to have different defaults for the same program.
        !           150: For example,
        !           151: it is not uncommon to link \pgm{prompter}
        !           152: (a simple prompting editor front-end)
        !           153: under the name \pgm{rapid} in the
        !           154: user's \file{bin/} directory, and add to the \profile/:
        !           155: \example rapid:\ -prepend\ -rapid\endexample
        !           156: As a result,
        !           157: when \pgm{prompter} is invoked as \pgm{rapid},
        !           158: it automatically uses the \switch{prepend} and \switch{rapid} options.
        !           159: 
        !           160: The profile component \eg{Path:} is the path to the user's
        !           161: \MH/-directory, usually \Mail/.
        !           162: In addition to containing the user's folders,
        !           163: the \MH/-directory also contains {\it skeletons} and
        !           164: {\it templates} used by the \MH/ programs,
        !           165: and the user's \context/ file.
        !           166: This latter file has the same format as the user's \profile/,
        !           167: and contains the dynamic,
        !           168: context-dependent information about the user's environment.
        !           169: Whenever \MH/ looks for an \MH/-specific file,
        !           170: such as a template or skeleton,
        !           171: it first consults the user's \MH/-directory,
        !           172: and then a system-wide library area.
        !           173: 
        !           174: The \MH/ user always has a {\it current folder},
        !           175: which is the folder in which
        !           176: the user is currently (or was last) working.
        !           177: Since any \MH/ program which deals with folders implicitly manipulates this
        !           178: information,
        !           179: the name of the  current folder is stored in the \file{context}
        !           180: component \eg{Current-Folder:}.
        !           181: Every folder has a {\it current message} known as \arg{cur}.
        !           182: These values are the defaults for \MH/ commands which
        !           183: accept folder and/or messages arguments.
        !           184: 
        !           185: \MH/ programs make use of a set of envariables
        !           186: which further customize their behavior.
        !           187: The \file{\$MH} envariable, if present,
        !           188: specifies the name of an alternate profile for the user.
        !           189: This allows a user of \MH/ to
        !           190: easily maintain multiple mail-handling environments.
        !           191: 
        !           192: In terms of command syntax,
        !           193: most \MH/ commands accept an optional {\it folder} argument,
        !           194: such as \arg{+outbox}.
        !           195: Unlike most \unix/ commands,
        !           196: all \MH/ commands have switches which are words, rather than single letters.
        !           197: Switches may be abbreviated to the least unambiguous prefix.
        !           198: All \MH/ commands also support a \switch{help} switch,
        !           199: which lists the syntax of the command along with available switches,
        !           200: and the version number of the command.
        !           201: Most \MH/ commands also take a \arg{msg} or \arg{msgs} argument
        !           202: which takes the form of a message number (\eg{1}), a message range (\eg{1-2}),
        !           203: a standard sequence name (\eg{cur}),
        !           204: or a user-defined sequence name (\eg{select}).
        !           205: 
        !           206: \tagdiagram{1}{An \MH/ Session}{session}
        !           207: \subsection{An \MH/ Transcript}                        % jlr
        !           208: Figure~\session\ contains a transcript of a simple \MH/ session.
        !           209: First, \pgm{inc} is run to incorporate the new mail into the 
        !           210: user's \eg{+inbox} folder.
        !           211: 
        !           212: A \pgm{scan} listing of the mail is printed while
        !           213: it is being incorporated.
        !           214: (The user could run \pgm{scan} explicitly to generate additional \pgm{scan}
        !           215: listings later on.)
        !           216: The \pgm{scan} listing gives the message number, followed
        !           217: by the date, message sender, and subject.
        !           218: (If the message originated from the user generating the listing,
        !           219: the \eg{to:} addressee is displayed instead of the sender.)
        !           220: If the subject is short,
        !           221: the first part of the message body is displayed after the characters \eg{<<}.
        !           222: The plus sign (`+') after
        !           223: the message number indicates the current message.
        !           224: 
        !           225: The user \pgm{show\/}s the message, and decides to \pgm{repl\/}y.
        !           226: A reply draft
        !           227: is created using the headers of the message being replied-to,
        !           228: using the default \file{replcomps} template.
        !           229: The default editor, \pgm{prompter}, is called to edit the draft.
        !           230: When an EOT is typed, \pgm{prompter} exits and the
        !           231: user is left at the \whatnow/ prompt.
        !           232: The option \pgm{send} is chosen.
        !           233: Since there were no problems in posting the draft with the message transport
        !           234: system, 
        !           235: no additional output is produced.
        !           236: (\MH/ is not verbose by default.)
        !           237: 
        !           238: The user then decides to compose a new message.
        !           239: The default skeleton, \file{components}, is copied to the draft,
        !           240: and \pgm{prompter} is once again called.
        !           241: After entering the addresses, subject, and body,
        !           242: the user then \pgm{send\/}s the \file{draft} from the \whatnow/ prompt,
        !           243: using \eg{send\ -verbose}, which causes
        !           244: \MH/ to list out the message addresses as it submits them
        !           245: to the message transport system.
        !           246: 
        !           247: \section{Some \MH/ Features}                   % mtr
        !           248: We now consider certain advanced features in \MH/.
        !           249: These features have been chosen to demonstrate some useful capabilities
        !           250: available to the \MH/ user.
        !           251: 
        !           252: \subsection{Message Sequences and Selection}   % jlr
        !           253: \MH/ has several built-in message sequence names, which may
        !           254: be used anywhere a \arg{msg} or \arg{msgs} argument is expected.
        !           255: These are:
        !           256: \arg{cur}, \arg{next}, \arg{prev}, \arg{first}, \arg{last}, and \arg{all}.
        !           257: Message ranges may also be specified.
        !           258: For example, \arg{all} is actually \arg{first-last}, and
        !           259: \arg{+mh\ last:5} references the last five messages in your
        !           260: \arg{+mh} folder.
        !           261: A powerful capability of \MH/ is the ability to use not only the pre-defined
        !           262: message sequence names,
        !           263: but also arbitrary user-defined message sequence names.
        !           264: 
        !           265: Although all \MH/ programs recognize user-defined sequences when appropriate, 
        !           266: the \pgm{pick} and \pgm{mark} commands can create and modify 
        !           267: user-defined message sequences.
        !           268: The \pgm{mark} command allows low-level manipulation of sequences,
        !           269: and is not particularly interesting in our discussion.
        !           270: 
        !           271: The \pgm{pick} command selects certain messages out of a folder.
        !           272: The criteria used for selection may be a search string and/or a date range.
        !           273: 
        !           274: Searching is performed on either a specific header in the message
        !           275: (e.g., \eg{To:}),
        !           276: or anywhere within the message.
        !           277: By default,
        !           278: \pgm{pick} lists out the message numbers that matched
        !           279: the selection criteria.
        !           280: Thus, \pgm{pick} is useful in backquoted operations to the shell.
        !           281: For example, to scan all the messages in the current folder from ``frated'',
        !           282: the \MH/ user issues the command:
        !           283: \example scan\ \bq{pick\ -from\ frated}\endexample
        !           284: To perform more complicated message selection,
        !           285: user-defined sequences are employed.
        !           286: Supplying a \switch{sequence\ name}
        !           287: argument to \pgm{pick}, will cause it to define the
        !           288: sequence \arg{name} as those messages matched.
        !           289: 
        !           290: Giving \pgm{pick} a list of messages causes it to limit its search to just
        !           291: those messages.
        !           292: For example,
        !           293: to find all the messages in the current folder from ``frated'' also dated
        !           294: before friday:
        !           295: \example pick\ -from\ frated\ -sequence\ select\\
        !           296:         pick\ select\ -before\ friday\ -sequence\ select\endexample
        !           297: With the first \pgm{pick} command,
        !           298: the sequence \eg{select} is defined
        !           299: to be all those messages from ``frated''.
        !           300: In the second command, only those messages already in the \eg{select}
        !           301: sequence are searched, and the \eg{select} sequence is redefined to be
        !           302: only those messages which are also
        !           303: dated before friday.
        !           304: Those messages could then be \pgm{show\/}n with:
        !           305: \example show\ select\endexample
        !           306: When a \switch{sequence\ name} argument is given to \pgm{pick},
        !           307: the default behavior --- listing the message numbers
        !           308: matched --- is inhibited.
        !           309: To re-enable this behavior, the \switch{list} option may be given.
        !           310: As a result,
        !           311: advanced users of \MH/ often put the following line in their \profile/:
        !           312: \example pick:\ -sequence\ select\ -list\endexample
        !           313: which allows them to easily make use of the \arg{select} sequence as the
        !           314: messages last selected with \pgm{pick}.
        !           315: 
        !           316: Often it is desirable to act upon those messages which
        !           317: are {\it not} members of a given sequence.
        !           318: For this purpose,
        !           319: the \eg{Sequence-Negation:} profile entry is useful.
        !           320: If the name of a user-defined sequence is prefixed with the value of the
        !           321: sequence-negation profile entry,
        !           322: \MH/ commands will operate upon those messages which are {\it not} members
        !           323: of that sequence.
        !           324: For example, given a profile entry of:
        !           325: \example Sequence-Negation:\ not\endexample
        !           326: those messages which
        !           327: are not in the \arg{select} sequence could be \pgm{scan\/}'d with:
        !           328: \example scan\ notselect\endexample
        !           329: 
        !           330: Obviously, some confusion could result if an attempt was made
        !           331: to define a sequence name
        !           332: which began with the sequence-negation string (e.g., \eg{notselect}).
        !           333: For this reason, \MH/ users will often use a single
        !           334: character,
        !           335: which their shell doesn't interpret,
        !           336: as their sequence-negation string
        !           337: (e.g., up-caret (`\^{}') for {\it C} Shell users,
        !           338: and exclamation-mark (`!') for {\it Bourne} shell users).
        !           339: 
        !           340: \MH/ also provides a way of automatically remembering the last
        !           341: message list given to
        !           342: an \MH/ command.
        !           343: This facility is implemented by using a profile entry called
        !           344: \eg{Previous-Sequence:}.
        !           345: 
        !           346: \subsection{Draft Handling}                    % jlr
        !           347: After the initial edit of a message draft,
        !           348: the \pgm{comp}, \pgm{dist}, \pgm{forw}, and \pgm{repl} programs
        !           349: give the user a \whatnow/ prompt.
        !           350: The valid responses include:
        !           351: \pgm{edit} to re-edit the draft,
        !           352: \pgm{quit} to exit without sending the draft,
        !           353: \pgm{send} to send the draft, and
        !           354: \pgm{push} to send the draft in the background.
        !           355: 
        !           356: When the \pgm{send} option is given,
        !           357: the draft is posted with the message transport system.
        !           358: If there problems posting the draft,
        !           359: the \whatnow/ prompt is re-issued,
        !           360: so errors in the draft may be corrected.
        !           361: 
        !           362: Since posting the draft can be slow,
        !           363: the \pgm{push} option allows the \MH/ user to send the draft in the
        !           364: background, and return immediately to the shell.
        !           365: If there are problems posting the message,
        !           366: the user will not see the diagnostics produced by
        !           367: the message transport system.
        !           368: For this reason,
        !           369: if \pgm{push} is used instead of \pgm{send},
        !           370: and the message is not successfully posted,
        !           371: \MH/ mails a message to the user
        !           372: containing any diagnostics which the message transport system produced
        !           373: along with a copy of the message.
        !           374: Later,
        !           375: the draft may be re-edited by entering \eg{comp\ -use}.
        !           376: 
        !           377: A relatively new feature of \MH/ is the ability to use a folder to store
        !           378: multiple drafts.
        !           379: These drafts are kept in an ordinary \MH/ folder,
        !           380: and may be operated upon by \MH/ commands.
        !           381: To enable this feature,
        !           382: the \MH/ user selects a folder-name for the draft-folder,
        !           383: and creates an entry in the \profile/:
        !           384: \example Draft-Folder:\ +foldername\endexample
        !           385: From this point on,
        !           386: when a message is composed,
        !           387: the draft will be created as a message in that folder,
        !           388: instead of using the \file{draft} file in the user's \MH/ directory.
        !           389: Unfortunately,
        !           390: if posting problems occur on a message which has been \pgm{push\/}'d,
        !           391: it may be difficult to re-edit the draft with
        !           392: \eg{comp\ -use}.
        !           393: This might be the case if the user had started composing another message,
        !           394: while that first draft was being posted.
        !           395: In that event,
        !           396: the current-message in the draft-folder would no longer point
        !           397: to the failed draft.
        !           398: 
        !           399: There is a solution for this problem, however.
        !           400: By default,
        !           401: \pgm{push} assumes the \switch{forward} option,
        !           402: which says that if the message draft fails to be posted,
        !           403: it should be forwarded back to the user in the
        !           404: error report which \pgm{push} generates.
        !           405: The failed draft may then be extracted with the \pgm{burst} program
        !           406: (discussed later).
        !           407: 
        !           408: \subsection{BBoards}                           % mtr
        !           409: \MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.%
        !           410: \nfootnote{The UCI BBoards facility can run under either the \MMDF/ or
        !           411: \SendMail/,
        !           412: or in a more restricted form under stand-alone \MH/.}
        !           413: This facility permits the efficient distribution of interest group messages
        !           414: on a single host,
        !           415: to a group of hosts under a single administration,
        !           416: and to the ARPA Internet community.
        !           417: 
        !           418: Although most readers are probably familiar with the concept of an interest
        !           419: group in the Internet context, a brief description is now given.
        !           420: Observant readers will notice that the distributed nature of the
        !           421: ``network news'' (a.k.a.~USENET)
        !           422: tends to avoid many of the problems described below.
        !           423: 
        !           424: Described simply, an interest group is composed of a number of subscribers
        !           425: with a common interest.
        !           426: These subscribers post mail to a single address, known as the
        !           427: {\it distribution} address (e.g., {\tx MH-Workers@UCI}.
        !           428: From this distribution address, a copy of the message is sent to each
        !           429: subscriber.
        !           430: Each group has a {\it moderator},
        !           431: who is the person that runs the group.
        !           432: This moderator can usually be reached at a special address,
        !           433: known as the {\it request} address (e.g., {\tx MH-Workers-Request@UCI}).
        !           434: Usually, the responsibilities of the moderator are quite simple,
        !           435: since the mail system handles distribution to subscribers automatically.
        !           436: In some interest groups,
        !           437: instead of each separate message being distributed directly to subscribers,
        !           438: a batch of (hopefully related) messages
        !           439: are put into a {\it digest} format by the
        !           440: moderator and then sent to the subscribers.
        !           441: (This is similar to a newsletter format.)
        !           442: Although this requires more work on the part of the moderator
        !           443: and introduces delays,
        !           444: such groups tend to be better organized.
        !           445: 
        !           446: Unfortunately, some problems arise with the scheme outlined above.
        !           447: First, if two users on the same host subscribe to the same interest group,
        !           448: two copies of the message are delivered.
        !           449: This is wasteful of both processor and disk resources at that host.
        !           450: 
        !           451: Second,
        !           452: some groups carry a lot of traffic.
        !           453: Although subscription to a group does indicate interest on the part of a
        !           454: subscriber,
        !           455: it is usually not interesting to get 50 or so messages delivered
        !           456: each day
        !           457: to the user's private maildrop,
        !           458: interspersed with {\it personal} mail,
        !           459: which is likely to be of a much more important and timely nature.
        !           460: 
        !           461: Third, if a subscriber's address in a distribution list 
        !           462: becomes ``bad'' somehow and causes failed mail to be returned,
        !           463: the originator of the message is normally notified.
        !           464: It is not uncommon for a large list to have several bogus addresses.
        !           465: This results in the originator being flooded with ``error messages'' from
        !           466: mailers across the Internet stating that a given address on the list was
        !           467: bad.
        !           468: Needless to say,
        !           469: the originator usually does not care if the bogus addresses got a copy
        !           470: of the message or not.
        !           471: The originator is merely interested in posting a message
        !           472: to the group at large.
        !           473: On the other hand,
        !           474: the moderator of the group does care if there are bogus addresses on the list,
        !           475: but ironically does not receive notification.
        !           476: 
        !           477: To solve these problems,
        !           478: the UCI BBoards facility introduces a new entity into the picture:
        !           479: a {\it distribution channel}.
        !           480: All interest group mail is handled by 
        !           481: the special mail system component.
        !           482: The distribution address for an interest-group
        !           483: maps mail for that interest-group to the distribution channel,
        !           484: which then performs
        !           485: several actions.
        !           486: First, if local delivery is to be performed,
        !           487: a copy of the message is placed in a global maildrop for the interest
        !           488: group with a timestamp and a unique number.
        !           489: Local users can read messages posted for the interest group by reading this
        !           490: ``public'' maildrop.
        !           491: Second, if further distribution is to take place,
        !           492: a copy of the message is sent to the distribution address in such a way that
        !           493: if any of the addresses are bogus,
        !           494: failure notices will be returned to the local maintainer of the group
        !           495: address list, rather than the originator of the message.
        !           496: 
        !           497: This scheme has several advantages:
        !           498: First, messages delivered to the local host are processed and saved once
        !           499: in a globally accessible area.
        !           500: The UCI BBoards facility supports software which allows a user to query an
        !           501: interest group for new messages and to read and process
        !           502: those messages in the \MH/-style.
        !           503: Second, once a host administrator subscribes to an interest group,
        !           504: each user may join or quit the list's readership without
        !           505: contacting anyone.
        !           506: Third, a hierarchical distribution scheme can be constructed to
        !           507: reduce the amount of delivery effort.
        !           508: Finally, errors are prevented from propagating.
        !           509: When an address on the distribution list goes bad,
        !           510: the list moderator who is responsible for the address is notified.
        !           511: If a local moderator does not exist,
        !           512: then the local PostMaster is notified (not the global group moderator).
        !           513: 
        !           514: In addition to solving the problems outlined above,
        !           515: the UCI BBoards facility supports several other capabilities.
        !           516: BBoards may be automatically archived in order to conserve disk space and
        !           517: reduce processing time when reading current items.
        !           518: Also,
        !           519: the archives can be separately maintained on tape for access by interested
        !           520: researchers.
        !           521: 
        !           522: Special alias files may be generated which allow the \MH/ user to shorten
        !           523: address entry.
        !           524: For example, instead of sending to {\tx SF-Lovers@Rutgers},
        !           525: a user of \MH/ usually sends to \eg{SF-Lovers} and the \MH/ aliasing
        !           526: facility automatically makes the appropriate expansion in the headers of the
        !           527: outgoing message.
        !           528: Hence,
        !           529: the user need only know the name of an interest group and not its global
        !           530: network address.
        !           531: 
        !           532: Finally, the UCI BBoards facility supports {\it private} interest groups
        !           533: using the \unix/ group access mechanism.
        !           534: This allows a group of people on the same or different machines to conduct a
        !           535: private discussion.
        !           536: 
        !           537: The practical upshot of all this is that the UCI BBoards facility automates
        !           538: the vast majority of BBoards handling from the point of view of both the
        !           539: PostMaster and the user.
        !           540: 
        !           541: \MH/ provides three programs to deal with interest groups.
        !           542: The \pgm{bbc} program is used to check on the status of one or more groups,
        !           543: and to optionally start an \MH/ shell on those groups which the user is
        !           544: interested in.
        !           545: The \pgm{bbl} program can be used to manually perform maintenance on a
        !           546: discussion group beyond the normal automatic capabilities of the UCI BBoards
        !           547: facility.
        !           548: Finally,
        !           549: the \pgm{msh} program implements an \MH/ shell for reading BBoards,
        !           550: in which nearly all of the \MH/ commands are implemented in a single program.
        !           551: 
        !           552: Observant readers may note that the use of \pgm{msh} is contrary to the \MH/
        !           553: philosophy of using relatively small, single-purpose programs.
        !           554: Sadly,
        !           555: the authors admit that this is true.
        !           556: In an effort to minimize use of system resources however,
        !           557: BBoards are kept in maildrop format instead of folders.%
        !           558: \nfootnote{When the message transport system delivers a message to a user
        !           559: it stores it in a single file, called a {\it maildrop}.
        !           560: Since many messages may be present in a single maildrop,
        !           561: (in theory) there is a unique string acting as a separator between messages
        !           562: in the maildrop.
        !           563: Although this is convenient for storage of messages,
        !           564: it makes retrieval more difficult unless a separate index into the maildrop
        !           565: is kept.
        !           566: This latter approach is taken by the \pgm{msg} program available with \MMDFII/
        !           567: and by \pgm{msh} as well.}
        !           568: Some research has gone into overcoming this problem to restore
        !           569: \MH/'s purity of purpose,
        !           570: but all solutions proposed to date are either unworkable or require
        !           571: significant recoding of \MH/'s internals.
        !           572: 
        !           573: \subsection{Bursting}                  % jlr
        !           574: Internet interest group mail is often sent out in digest form.
        !           575: The experienced \MH/ user may wish to deal with the digest messages on
        !           576: an individual basis, however.
        !           577: The \pgm{burst} program allows the \MH/ user to extract these digest
        !           578: messages,
        !           579: and store each as an individual \MH/ message.
        !           580: 
        !           581: \pgm{Burst} will also extract forwarded messages generated by \pgm{forw}
        !           582: (or the forwarded message in the error report generated by \pgm{push},
        !           583: as described above).
        !           584: Although \pgm{burst} cannot always decapsulate
        !           585: messages encapsulated by sites not running \MH/,
        !           586: it adheres to the proposed standard described in \cite{MRose85b}.
        !           587: 
        !           588: \subsection{Distributed Mail}                  % mtr
        !           589: The ARPA Internet community consists of many types of heterogeneous nodes.
        !           590: Some hosts are large mainframe computers,
        !           591: others are personal workstations.
        !           592: All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}.
        !           593: Messages which conform to the Standard for the Format of ARPA Internet Text
        !           594: Messages\cite{DCroc82}
        !           595: are exchanged using the Simple Mail Transfer Protocol\cite{SMTP}.
        !           596: 
        !           597: On smaller nodes in the ARPA Internet,
        !           598: it is often impractical to maintain
        !           599: a message transport system (e.g., \SendMail/).
        !           600: For example,
        !           601: a workstation may not have sufficient resources (cycles, disk space)
        !           602: in order to permit an SMTP server and associated local mail delivery system
        !           603: to be kept resident and continuously running.
        !           604: Furthermore,
        !           605: the workstation could be off-net for extended periods of time.
        !           606: Similarly,
        !           607: it may be expensive (or impossible) to keep a personal computer
        !           608: interconnected to an IP-style network for long periods of time.
        !           609: In other words,
        !           610: the node is lacking the resource known as ``connectivity''.
        !           611: 
        !           612: Despite this,
        !           613: it is often desirable to be able to manage mail with \MH/ on these smaller
        !           614: nodes,
        !           615: and they often support a user agent to aid the tasks of mail handling.
        !           616: To solve this problem,
        !           617: a network node which can support a message transport entity
        !           618: (known as {\it service} host) offers
        !           619: a maildrop service to these less endowed nodes
        !           620: (known as {\it client} hosts).
        !           621: The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a
        !           622: workstation to dynamically access a maildrop on a service host to pick-up
        !           623: mail.%
        !           624: \nfootnote{Actually,
        !           625: there are three different descriptions of the POP.
        !           626: The first, cited in \cite{JReyn84},
        !           627: was the original description of the protocol,
        !           628: which suffered from certain problems.
        !           629: Since then,
        !           630: two alternate descriptions have been developed.
        !           631: The official revision of the POP\cite{MButl85},
        !           632: and the revision of the POP which \MH/ uses
        !           633: (which is documented in an internal memorandum in the \MH/ release).
        !           634: This paper considers the POP in the context of the \MH/ release.}
        !           635: The level of access includes the ability to
        !           636: determine the number of messages in the maildrop and the size of each message,
        !           637: as well as to retrieve and delete individual messages.
        !           638: More sophisticated implementations of the POP server
        !           639: are able to distinguish between the header and body portion of each message,
        !           640: and send $n$ lines of a message to the POP client.
        !           641: This capability is useful in thinly connected environments where conservation
        !           642: of bandwidth is important.
        !           643: By utilizing a more intelligent POP client,
        !           644: a user may generate ``scan~listings'' and decide dynamically which messages
        !           645: are worth taking delivery on.
        !           646: The philosophy of the POP is to put intelligence in the 
        !           647: POP clients and not the POP servers.
        !           648: 
        !           649: The current release of \MH/ supports the above model fully.
        !           650: A POP client program is available to retrieve a maildrop from a POP service
        !           651: host.
        !           652: In addition,
        !           653: using the SMTP configuration for delivery in \MH/
        !           654: (either in conjunction with \SendMail/ or the \MMDF/),
        !           655: a user is able to specify a search-list of service hosts (and/or networks)
        !           656: to try to post mail.
        !           657: Using this search-list,
        !           658: when an \MH/ user posts a draft,
        !           659: the \pgm{post} program will attempt to establish an SMTP connection
        !           660: with each host in the search-list to post the message until it succeeds.
        !           661: Initial experimentation using the POP and \MH/
        !           662: in a local network environment has proved quite successful.
        !           663: 
        !           664: \section{User Interface Issues in \MH/}                % mtr
        !           665: At this point,
        !           666: it is perhaps useful to take a step backwards and examine the success
        !           667: and problems of \MH/'s approach to user interfaces.
        !           668: 
        !           669: \subsection{Creeping Featurism}                        % mtr
        !           670: A complaint often heard about systems which undergo substantial development
        !           671: by many people over a number of years, is that more and more options are
        !           672: introduced which add little to the functionality but greatly increase the
        !           673: amount of information a user needs to know in order to get useful work done.
        !           674: This is usually referred to as {\it creeping featurism}.
        !           675: 
        !           676: Unfortunately \MH/,
        !           677: having undergone six years of off-and-on development by ten or so
        !           678: well-meaning programmers (the present authors included),
        !           679: suffers mightily from this.
        !           680: For example,
        !           681: the \pgm{send} command has twenty-five visible switches,
        !           682: and at least nine hidden switches,
        !           683: for a total of thirty-four.
        !           684: The poor user who types \example send\ -help\endexample watches the options
        !           685: scroll off the screen
        !           686: (since the \switch{help} switch also lists out four other lines of
        !           687: information).%
        !           688: \nfootnote{Recently,
        !           689: this was fixed by compressing the way in which switches are presented.
        !           690: The solution is only temporary however,
        !           691: as \pgm{send} will no doubt acquire an {\it endless} number of switches in
        !           692: the years to come.}
        !           693: The sad part is that all of these switches are useful in one form or another.
        !           694: 
        !           695: There are a lot of good things to be said for the
        !           696: ``one program, one function'' philosophy of system design.
        !           697: In the \MH/ case, however,
        !           698: each program really does only one mail handling activity
        !           699: (with a few minor exceptions).
        !           700: The options associated with each command are present to modify the program's
        !           701: behavior to perform similar, but slightly different tasks.
        !           702: In further defense of \MH/,
        !           703: note that there are~32 \MH/ commands at present,
        !           704: all performing different tasks.
        !           705: 
        !           706: The problem with creeping featurism though,
        !           707: is that while the functionality of the system increases sub-linearly,
        !           708: the complexity of the system increases linearly.
        !           709: That is,
        !           710: although the number of switches that a program takes might double,
        !           711: it is unlikely that the program's functionality or capabilities will double.
        !           712: 
        !           713: \subsection{Templates versus Switches}         % mtr
        !           714: One way to trim the explosion of available options,
        !           715: while still increasing functionality,
        !           716: is to introduce options with a richer domain.
        !           717: Hence,
        !           718: instead of using options which take {\it on} or {\it off} forms
        !           719: or simple numeric or string values,
        !           720: the possible values which an option might take on is given a large space.
        !           721: There are several ways that this might be accomplished.
        !           722: 
        !           723: \tagdiagram{2}{Draft Skeleton}{components}
        !           724: The \pgm{comp}, \pgm{dist}, and \pgm{forw} programs
        !           725: use draft {\it skeletons} (simple form fill-in files) to construct the
        !           726: general format of the draft being composed.
        !           727: An example of a draft skeleton used for composing new messages
        !           728: (by \pgm{comp\/}) is shown in Figure~\components.
        !           729: The approach is to let the user specify (and later edit) both arbitrary
        !           730: headers of draft and the body of the draft.
        !           731: Note while most of the fields are empty,
        !           732: the first \eg{Fcc:} field already contains a value.
        !           733: By using the simple prompting editor, \pgm{prompter},
        !           734: the user can speedily enter the headers of the message.
        !           735: The \pgm{prompter} program given the skeleton in Figure~\components\ would
        !           736: prompt the user for the contents of each field,
        !           737: except for the second \eg{fcc:},
        !           738: which it would include verbatim.
        !           739: It would then read the body of the message up to an end-of-file.
        !           740: Naturally,
        !           741: the \MH/ user is free to use {\it any} editor to edit {\it any} part of the
        !           742: draft (headers or body).
        !           743: This example 
        !           744: demonstrates the flexibility achieved by not limiting what headers a
        !           745: draft may contain (which most mail sending programs do),
        !           746: while still retaining the simplicity of being able to treat the entire
        !           747: message draft as a \unix/ file.
        !           748: 
        !           749: \tagdiagram{3}{Reply Template}{replcomps}
        !           750: Another more interesting approach is used by the \pgm{repl} command,
        !           751: which constructs a draft in reply-to a previously received message.
        !           752: Instead of adding switches to indicate which fields of the draft should be
        !           753: derived from the message being replied-to,
        !           754: and how they should be derived,
        !           755: a single option,
        !           756: the ability to specify a {\it template}, was made available.
        !           757: An example of a reply template is shown in Figure~\replcomps.
        !           758: Put simply,
        !           759: based on the presence of certain fields in the message being replied-to,
        !           760: and a few switches given by the user,
        !           761: using the reply template,
        !           762: \pgm{repl} generates the reply draft automatically.
        !           763: 
        !           764: \tagdiagram{4}{The \file{tripcomps} Reply Template}{tripcomps}
        !           765: This facility, for example,
        !           766: can be used to generate automatic replies.%
        !           767: \nfootnote{\MH/ supports the notion of a user-defined {\it mail hook}
        !           768: which is invoked each time a user receives mail.}
        !           769: One function might be to write a \pgm{rcvtrip} shell script
        !           770: which automatically answered messages when mail wasn't being read for a
        !           771: period of time
        !           772: (e.g., while attending a conference).
        !           773: An example of a reply template at the heart of such a script
        !           774: is shown in Figure~\tripcomps.
        !           775: 
        !           776: \tagdiagram{5}{The \file{bombcomps} Reply Template}{bombcomps}
        !           777: Finally,
        !           778: another application might be to utilize
        !           779: the highly useful letter bomb protocol.%
        !           780: \nfootnote{The authors wish to credit Ron Natalie of the Ballistics Research
        !           781: Laboratory in Aberdeen, Maryland for formalizing the
        !           782: use of this protocol in the ARPA Internet community.}
        !           783: The important thing to note about this template is that it generates not only
        !           784: the headers of the reply draft (with a creative \eg{Reply-to:} address),
        !           785: but the body as well.
        !           786: Hence,
        !           787: the commands
        !           788: \example
        !           789:     repl\ -form\ bombcomps\ -noedit\ ;\ rmm\\
        !           790:     What\ now?\ push%
        !           791: \endexample
        !           792: are very handy for dealing with disturbing mail in a straight-forward manner.
        !           793: Of course, \pgm{repl} could be linked to \pgm{bomb} in the user's \file{bin/}
        !           794: directory and an appropriate line could be added to the user's \MH/ profile,
        !           795: in order to further shorten type-in.
        !           796: 
        !           797: \tagdiagram{6}{Display Template}{mhlforward}
        !           798: A variation on the reply template is the {\it display template}.
        !           799: A display template, as used by the \pgm{mhl} program,
        !           800: contains instructions on how to format a message.
        !           801: In addition to being used by \pgm{show}, et.~al.,
        !           802: the \pgm{forw} program can also use a display template to format each
        !           803: message being forwarded.
        !           804: Similarly,
        !           805: although \pgm{repl} uses a reply template to construct the draft
        !           806: being composed,
        !           807: it also may use a display template to format the body of the message
        !           808: being replied-to for enclosure in the reply.
        !           809: Furthermore,
        !           810: the \pgm{post} program may use a display template to format the body of a
        !           811: blind-carbon-copy.
        !           812: An example of a display template used for formatting forwarded messages
        !           813: is shown in Figure~\mhlforward.
        !           814: 
        !           815: As with reply templates,
        !           816: display templates can offer a lot of functionality.
        !           817: For example,
        !           818: the one line display template:
        !           819: \example
        !           820:     body:nocomponent,overflowtext=,overflowoffset=0,width=10000%
        !           821: \endexample
        !           822: can be used to extract the body of a message,
        !           823: while ignoring the headers.
        !           824: Hence,
        !           825: if a \pgm{shar} archive arrived in the mail,
        !           826: a convenient way to unpack it,
        !           827: assuming the above display template was called \file{mhl.body},
        !           828: would be:
        !           829: \example show\ -form\ mhl.body\ |\ sh\endexample
        !           830: 
        !           831: The biggest win with display templates,
        !           832: of course,
        !           833: is that all those annoying header lines which mailers
        !           834: everywhere generate can be simply and easily filtered out.
        !           835: 
        !           836: \subsection{Modularity versus Monolithicity}   % jlr
        !           837: Since \MH/ is a set of programs
        !           838: which perform separate tasks,
        !           839: as opposed to being a single, monolithic program,
        !           840: the power of the shell is used directly to aid in mail-handling.
        !           841: One powerful capability which this design achieves is the ability to extend
        !           842: the \MH/ command set,
        !           843: by developing shell scripts which use the standard \MH/
        !           844: programs to accomplish complicated or specialized tasks.
        !           845: 
        !           846: \tagdiagram{7}{The \pgm{mpick} Script}{mpick}
        !           847: For example,
        !           848: in the \MH/ distribution there is a shell script
        !           849: called \pgm{mpick} (shown in Figure~\mpick)
        !           850: which tries to locate all the messages which pertain to a given discussion,
        !           851: by looking at the \eg{Message-ID:} and \eg{In-reply-to:} headers,
        !           852: to find matching message-ids.%
        !           853: \nfootnote{Note that the shell scripts included in the \MH/ distribution
        !           854: are written for the {\it Bourne} shell,
        !           855: and have a `:' as the first character of the first line,
        !           856: so they will be portable to all versions of \unix/,
        !           857: not just those which support the
        !           858: Berkeley `\#!' enhancement.}
        !           859: 
        !           860: \tagdiagram{8}{The \pgm{append} Editor}{appended}
        !           861: Unfortunately, some parts of \MH/ are somewhat monolithic.
        !           862: An example of this is the \whatnow/ prompt.
        !           863: There are only a few options at this prompt,
        !           864: and one cannot give a normal shell command.
        !           865: Some \MH/ users seem to feel that more options should be added to
        !           866: the \whatnow/ prompt, such as an \pgm{insert-file} option.
        !           867: It was argued that just about any editor would allow you to 
        !           868: insert a file, and another \whatnow/ option was not needed.
        !           869: These users persisted, however, so the
        !           870: problem was solved, by writing a trivial shell
        !           871: script ``editor'' (see Figure~\appended)
        !           872: which could be invoked by the \pgm{edit} option:
        !           873: \example What now?\ edit\ append\ filename\endexample
        !           874: 
        !           875: A better interface at this point is really needed, however.
        !           876: One possibility is to simply pass any unrecognized commands on
        !           877: to a shell for interpretation, supplying the path name of the draft file
        !           878: as an argument.
        !           879: A solution which shows more promise is to give you a sub-shell
        !           880: {\it instead} of the \whatnow/ prompt,
        !           881: and setup certain envariables so that
        !           882: the \MH/ commands would act upon the \file{draft} by default.
        !           883: For example, \pgm{show} with no \arg{msgs} arguments
        !           884: would show the draft instead of the current message.
        !           885: This alternative has recently been implemented and is under testing.
        !           886: 
        !           887: \section{The \MH/ Distribution}                        % mtr
        !           888: The \mh5 distribution is now briefly described,
        !           889: both in terms of static configuration methods
        !           890: and dynamic tailoring.
        !           891: Appendix~B describes the mechanics of receiving an \mh5 distribution.
        !           892: 
        !           893: \subsection{Configurable \MH/}                 % jlr
        !           894: The \MH/ distribution currently runs on a large number of different \unix/
        !           895: versions,
        !           896: ranging from MicroSoft XENIX to Berkeley 4.2\bsd/.
        !           897: All the code which is specific to a particular target environment is
        !           898: enabled via the C-preprocessor \eg{\#ifdef} mechanism,
        !           899: so compilation under different versions of \unix/ is trivial.
        !           900: There are,
        !           901: however,
        !           902: a large number of compile-time options which may vary from site to site,
        !           903: so an automated configuration method was needed.
        !           904: 
        !           905: \tagdiagram{9}{Sample \MH/ Configuration File}{mhconfig}
        !           906: The \MH/-installer must create a configuration file,
        !           907: which contains a list of the compile-time options
        !           908: and the values which are desired for them.
        !           909: Compile-time options include the installation location for \MH/,
        !           910: what kind of message transport system is to be used,
        !           911: and the default editor for the installation.
        !           912: An example of such a configuration file is shown in Figure~\mhconfig.
        !           913: 
        !           914: After creating this file (several examples are included in the distribution),
        !           915: the installer runs the \pgm{mhconfig} program,
        !           916: which customizes the \file{Makefile\/}s and some of the programs,
        !           917: for that site's particular installation.
        !           918: No hand-editing of any source code should be necessary,
        !           919: under normal circumstances.
        !           920: 
        !           921: \subsection{Interface to the Message Transport System} % jlr & mtr
        !           922: \MH/ will run with a number of message transport systems,
        !           923: including \SendMail/, \MMDFII/, and a small stand-alone system.
        !           924: One flexible method of posting mail is through an SMTP connection.
        !           925: There are a couple of major wins in using this configuration: 
        !           926: First,
        !           927: none of the \MH/ programs need to know where the interface programs to
        !           928: the message transport system are located,
        !           929: which makes them easier to move between systems.
        !           930: Second,
        !           931: mail can be posted on relay hosts,
        !           932: and the local host of an \MH/ user may not need a message transport system at
        !           933: all (as alluded to in the preceeding discussion on the POP).
        !           934: 
        !           935: \tagdiagram{10}{Sample MTS Tailor File}{mtstailor}
        !           936: Those parts of \MH/ which interact with the local message transport agent
        !           937: read additional tailoring information when they start.%
        !           938: \nfootnote{This simple facility is based on a more extensive
        !           939: tailoring capability found in \MMDFII/.}
        !           940: This information includes
        !           941: the location of standard and alternate maildrops,
        !           942: maildrop delimiter strings,
        !           943: the locking directory and locking style,
        !           944: and other tailoring information specific for the particular
        !           945: message transport system in use
        !           946: (e.g., the default server search-list when mail is posted with the SMTP).
        !           947: In most cases,
        !           948: by using a tailor file,
        !           949: each site running a similar \MH/ configuration is able to simply transfer
        !           950: \MH/ binaries between hosts.
        !           951: An example of such a tailor file is shown in Figure~\mtstailor.
        !           952: 
        !           953: A continuing question which is often raised is how intelligent should user
        !           954: agents (like \MH/ and UCB \pgm{Mail}\/) be with respect to the environment in
        !           955: which they operate.
        !           956: At present, \MH/ likes to determine 
        !           957: the official hostnames for addresses when posting mail.
        !           958: Many argue that this is improper or unnecessary behavior for a user agent,
        !           959: and that the local message transport agent should handle these functions.
        !           960: Unfortunately,
        !           961: this implies that the message transport agent should munge headers when mail
        !           962: is posted to remove local host aliases and only permit address fields with
        !           963: fully-qualified addresses.
        !           964: Sadly, neither \SendMail/ nor \MMDFII/ really gets this right
        !           965: (flames to \file{/dev/null} please).
        !           966: The current \MH/ maintainers believe that the resolution of host aliases to
        !           967: official names should be a well-supported interface with the local message
        !           968: transport agent.
        !           969: However, to provide equal time to those who hold opposite views,
        !           970: \MH/ supports a configuration option called \eg{DUMB} which disables \MH/'s
        !           971: attempts to resolve addresses into fully-qualified strings.
        !           972: 
        !           973: \section{Concluding Remarks}                   % jlr and mtr
        !           974: While \MH/ has undergone significant development since
        !           975: the original
        !           976: Rand release, the authors have
        !           977: tried to keep the fundamental concepts of
        !           978: \MH/ unchanged.
        !           979:                                                % specific vs. general
        !           980: The authors have continually had to battle against
        !           981: well-meaning \MH/ users who wanted to make \MH/
        !           982: more like other (less powerful) user agents.
        !           983: More and more ``features'' were often suggested for \MH/,
        !           984: usually at the expense of making \MH/ less general, and more specific.
        !           985: In nearly all cases, the ``features'' which these users wanted
        !           986: were already present in \MH/ in a slightly different form,
        !           987: or could be realized by simply writing a short shell script.
        !           988: A classic example is the repeated requests by one user to have \pgm{dist}
        !           989: take a list of messages rather than a single message and distribute each one
        !           990: of them in turn.
        !           991: A simple shell script which called \pgm{dist} repeatedly,
        !           992: perhaps with ``canned'' arguments so the user typed in addressing information
        !           993: only once, would easily meet this request.
        !           994: 
        !           995:                                                % generality
        !           996: A number of \MH/ comands have a large number of options.
        !           997: When adding options, the authors have tried to make the options
        !           998: general, while still accomodating the requests of specific users.
        !           999: An example of a specific request which was implemented as a
        !          1000: general feature is the \eg{Previous-Sequence} profile entry
        !          1001: (mentioned above).
        !          1002: If you use this profile entry, every \MH/ command is forced to write
        !          1003: out \context/ changes, making every command somewhat slower.
        !          1004: Since only a few users wanted this capability, it was implemented
        !          1005: in such a way that users who didn't want it, didn't have to pay
        !          1006: the cost of slowing down every \MH/ command.
        !          1007: 
        !          1008:                                                % naive user :: MH
        !          1009: \MH/ has a powerful tailoring capability provided by the \profile/.
        !          1010: Using profile entries, users may
        !          1011: customize their own environment without affecting others.
        !          1012: Novice users often take advantage of the \MH/-tailoring
        !          1013: capabilities to try to make \MH/ work similarly to
        !          1014: other user agents they've used.
        !          1015: This has the advantage of allowing them to quickly begin
        !          1016: using \MH/ to handle their mail.
        !          1017: However, since these novice users don't take advantange of all the
        !          1018: capabilities of \MH/,
        !          1019: they frequently will complain about things they think can't
        !          1020: be done with \MH/, or could be done ``better'' some other way.
        !          1021: Fortunately,
        !          1022: as these users become more experienced with both \MH/ and \unix/,
        !          1023: they can modify their environment to take better advantage of
        !          1024: all of \MH/'s capabilities.
        !          1025: Novice \MH/ users who see features lacking
        !          1026: are encouraged to take a better look at what \MH/ {\it can} do,
        !          1027: instead of trying to make \MH/ into something it isn't.
        !          1028: This may sound rather inflammatory,
        !          1029: but it would really be a much nicer world for us all if users of software
        !          1030: systems would read the manual prior to asking questions.
        !          1031: 
        !          1032:                                                % speed consideration
        !          1033: For a moment, let's consider the evolution of one \MH/ feature which has
        !          1034: proved itself to be very useful.
        !          1035: As users began employing \MH/ to handle their mail,
        !          1036: the number of messages that could be processed
        !          1037: in a given amount of time increased greatly.
        !          1038: As the volume of messages increased however,
        !          1039: it became clear that some \MH/ operations were too slow,
        !          1040: in particular the interaction with the (slow) message transport system.
        !          1041: To overcome this problem, the \pgm{push} option
        !          1042: was added at the \whatnow/ prompt.
        !          1043: Originally, this option was hidden from novice users
        !          1044: and did little more than send the message in the background:
        !          1045: any output generated by
        !          1046: the background \pgm{send} process would be printed
        !          1047: asyncronously on the terminal.
        !          1048: If a message failed posting with the message transport system,
        !          1049: it would simply be left in the \file{draft} file.
        !          1050: 
        !          1051: Gradually, other features were added to \pgm{push}.
        !          1052: Since users wanted to be able to send more than one draft
        !          1053: at a time, \pgm{push} was changed to optionally
        !          1054: rename the draft file before posting it.
        !          1055: (This is what the hidden \switch{unique} option does.)
        !          1056: Having message transport system diagnostics
        !          1057: written asyncronously on the user's terminal was annoying,
        !          1058: so \pgm{push} was made to intercept these diagnostics,
        !          1059: and mail the user a report containing them.
        !          1060: Although the diagnostic report mailed back by \pgm{push} contains
        !          1061: the name of the draft which failed,
        !          1062: a useful added feature was the ability to have \pgm{push}
        !          1063: include the failed draft as well.
        !          1064: Eventually, the draft-folder mechanism was implemented to make
        !          1065: handling multiple message drafts much easier.
        !          1066: 
        !          1067: 
        !          1068: \subsection{TODO}                              % mtr
        !          1069: There are, no doubt, a number of improvements which could be made to \MH/.
        !          1070: At the present time,
        !          1071: what further development should \MH/ suffer?
        !          1072: Although not by any means inclusive,
        !          1073: here's a list:
        !          1074: \smallskip
        !          1075: {\advance\leftskip by\parindent
        !          1076: \item{1.} Performance Enhancements\hbreak
        !          1077: Hardware gets faster all the time, but people always complain that software
        !          1078: is too slow.
        !          1079: Owing to its user interface style,
        !          1080: \MH/ is somewhat slower than monolithic programs like UCB \pgm{Mail}.
        !          1081: It would be nice if \MH/ could be tuned or accelerated somehow.
        !          1082: 
        !          1083: \item{2.} Port to System~5\hbreak
        !          1084: \MH/ runs on 4.2\bsd/~\unix/ and Version~7 variants.
        !          1085: It should not be difficult to port \MH/ to a SYS5 environment.
        !          1086: This should significantly increase the number of hosts
        !          1087: on which \MH/ can run.
        !          1088: The authors,
        !          1089: lacking a SYS5 machine (and experience with SYS5) to perform the port,
        !          1090: are actively seeking a System~5 guru to attempt this feat.
        !          1091: 
        !          1092: \item{3.} Interface to the Network News\hbreak
        !          1093: Not all sites that run \MH/ are in the ARPA Internet,
        !          1094: and as such the UCI BBoards facility may not be of much use to them.
        !          1095: A good \MH/ interface to the network news would allow users on hosts with a
        !          1096: news feed to employ the same interface for reading and sending both mail and
        !          1097: news.
        !          1098: 
        !          1099: \item{4.} Programmed Instruction for Beginners\hbreak
        !          1100: The complexity of \MH/ is often intimidating to new users.
        !          1101: It would be nice to develop a set of \pgm{learn} lessons for those users who
        !          1102: don't like \pgm{man} pages and non-interactive tutorials.
        !          1103: 
        !          1104: \item{5.} Message List Expansion\hbreak
        !          1105: At present, when a list of messages is given to an \MH/ command,
        !          1106: it expands the list and processes each message in numerical order
        !          1107: rather than the order in which the messages were given
        !          1108: (e.g., \eg{show\ 2\ 1} \pgm{show\/}s message~1
        !          1109: and then message~2).
        !          1110: It would be nice if \MH/ processed messages in the order
        !          1111: they were given.
        !          1112: 
        !          1113: \item{6.} Context Changes\hbreak
        !          1114: In nearly all cases,
        !          1115: an \MH/ command does not write out context changes until it is about to exit
        !          1116: successfully.
        !          1117: There is some controversy as to whether this is the correct behavior
        !          1118: in all cases.
        !          1119: Some argue that once an \MH/ command has fully parsed its argument list,
        !          1120: the context should be updated.
        !          1121: \par}

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.