Return to text.tex CVS log

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

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

1.1     ! root        1: % begin text
        !             2: 
        !             3: \banner
        !             4: 
        !             5: \section{Introduction}                         % mtr
        !             6: \tagfigure{0}{\MTS/ model}{mtsmodel}
        !             7: 
        !             8: The UCI version of the Rand Message Handling System, \MH/,
        !             9: is a user agent.
        !            10: In the interests of brevity,
        !            11: we dispense with the usual definition of terms,
        !            12: refer the reader to Figure~\mtsmodel,
        !            13: and simply note that \MH/ is not responsible for delivering mail.
        !            14: Rather,
        !            15: it interacts with a {\it message transport system}, \MTS/,
        !            16: at two interfaces:
        !            17: it sends mail by placing it through a {\it posting slot} to the \MTS/,
        !            18: and it receives mail by retrieving it through a {\it delivery slot} from the
        !            19: \MTS/.
        !            20: Besides these two \MTS/-specific activities,
        !            21: the tasks which \MH/ addresses are:
        !            22: the composition of messages
        !            23: (which may, or may not, be in reference to previously sent messages),
        !            24: the reading of messages,
        !            25: and the organization of messages.
        !            26: 
        !            27: \MH/ was originally developed by the Rand Corporation,
        !            28: and initially was proprietary software.
        !            29: The Department of Information and Computer Science at
        !            30: University of California, Irvine,
        !            31: shortly after joining the Computer Science Network (CSnet),
        !            32: acquired a copy of \MH/,
        !            33: and began additional development of the software.
        !            34: Since that time,
        !            35: the Rand Corporation has declared \MH/ to be in the public domain,
        !            36: and the UCI version of \MH/ has passed through four major releases.
        !            37: 
        !            38: Much credit must be given to the initial designers and implementors of \MH/:
        !            39: Bruce Borden, Stockton Gaines, and Norman Shapiro.
        !            40: Although \MH/ has suffered significant development at UCI
        !            41: since Rand's initial release,
        !            42: the fundamental concepts of \MH/'s environs have remained nearly unchanged.
        !            43: In addition,
        !            44: the current maintainers of \MH/ gratefully acknowledge the comments of the
        !            45: many sites which have run various releases of \MH/ in the past.
        !            46: 
        !            47: \MH/ runs on different versions of the \unix/ operating system
        !            48: (such as 4.2\bsd/~\unix/ and various flavors of v7~\unix/).
        !            49: In addition,
        !            50: \MH/ supports four different \MTS/ interfaces:
        !            51: \SendMail/\cite{EAllm83},
        !            52: the standard mailer for 4.2\bsd/ systems;
        !            53: \MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84},
        !            54: the Multi-Channel Memo Distribution Facility developed by the University of
        !            55: Delaware
        !            56: which forms the software-backbone for CSnet\cite{DCome83} mail relays service;
        !            57: SMTP,
        !            58: the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
        !            59: and,
        !            60: a stand-alone delivery system.
        !            61: 
        !            62: The organization of this paper is straight-forward,
        !            63: given space considerations.
        !            64: Initially,
        !            65: the \MH/ philosophy of mail handling is presented,
        !            66: along with a description of the environment which the \MH/ user is given to
        !            67: process mail.
        !            68: Following this,
        !            69: certain advanced features of \MH/ are discussed in more detail.
        !            70: In particular,
        !            71: the notion of a {\it draft folder} is introduced,
        !            72: which permits the handling of multiple drafts during composition.
        !            73: In addition,
        !            74: message selection facilities are described.
        !            75: Next,
        !            76: two different aspects of \MH/'s power as a software system are discussed:
        !            77: record handling, in which \MH/ facilitates record processing systems;
        !            78: and,
        !            79: how \MH/ can be employed in a distributed mail environment.
        !            80: This latter section raises questions as to the location of the posting and
        !            81: delivery slots,
        !            82: along with authentication mechanisms.
        !            83: Finally,
        !            84: we conclude by discussing areas of future development which \MH/ may endure.
        !            85: 
        !            86: Although familiarity with \MH/ is not assumed on the part of the reader,
        !            87: some knowledge of the \unix/ operating system is useful.
        !            88: Appendix~A gives a short synopsis of the \MH/ commands.
        !            89: 
        !            90: \section{The \MH/ Philosophy}                  % mtr
        !            91: Although \MH/ has many traits which tend to differ it from other user agents,
        !            92: the design aspect which fundamentally influences the interface between \MH/
        !            93: and the user is that it is composed of many small
        !            94: programs instead of one very large one.
        !            95: This architecture gives \MH/ much of its strength,
        !            96: since intermediate and advanced users are able to take advantage of this
        !            97: flexibility.
        !            98: 
        !            99: The key to this flexibility is that the \unix/ shell
        !           100: (usually the {\it C} shell or the {\it Bourne} shell),
        !           101: is the user's interface to \MH/.
        !           102: This means that when handling mail,
        !           103: the entire power of the shell is at the user's disposal in addition to the
        !           104: facilities which \MH/ provides.
        !           105: Hence,
        !           106: the user may intersperse mail handling commands with other commands in an
        !           107: arbitrary fashion,
        !           108: making use of command handling capabilities that the user's shell provides.
        !           109: 
        !           110: Furthermore,
        !           111: rather than storing messages in a complicated data structure
        !           112: within a monolithic file,
        !           113: in \MH/, each message is a \unix/ file,
        !           114: and each folder (an object which holds groups of messages)
        !           115: is a \unix/ directory.
        !           116: That is,
        !           117: the directory and file structure of \unix/ is used directly.
        !           118: As a result,
        !           119: any \unix/ file-handling command can be applied to any message.
        !           120: 
        !           121: To the novice,
        !           122: this may not make much sense or may not seem important.
        !           123: From three years of observation, we have seen that
        !           124: as users of \MH/ have become more experienced
        !           125: they have found this capability to be quite attractive.
        !           126: In addition,
        !           127: this approach is often quite pleasing to system implementors,
        !           128: because it minimizes the amount of coding to be performed
        !           129: and,
        !           130: given a modular design,
        !           131: changes to the software system can be maintained easily.
        !           132: Our empirical findings confirm our theoretical expectations regarding the
        !           133: \MH/ architecture.
        !           134: 
        !           135: Having described how \MH/ fits into the \unix/ environment,
        !           136: we now discuss the mail handling environment which is available to the \MH/
        !           137: user.
        !           138: 
        !           139: \subsection{The \MH/ Environs}                 % jns
        !           140: \MH/ provides a complementary environment to the user's shell.
        !           141: While the shell maintains a context related to the user's focus in the file
        !           142: system (a {\it current working directory\/}),
        !           143: mail handling is performed in a separate mail folder context.
        !           144: Operations on mail can therefore be
        !           145: performed entirely without regard to the current file system context,
        !           146: although \MH/ does not prevent the user from making use of that context.
        !           147: Certain mail handling functions do make use of information
        !           148: maintained by the shell.
        !           149: For instance, by setting certain shell parameters,
        !           150: called {\it environment variables},
        !           151: alternate mail handling contexts can be selected.
        !           152: 
        !           153: \MH/ conventions often have direct analogs to shell or file system
        !           154: conventions.
        !           155: The shell has a current working directory; \MH/ has a current mail folder.
        !           156: When the user begins a session on the system,
        !           157: the user's ``home directory'' is the base context;
        !           158: \MH/'s default base area, the \Mail/ directory, 
        !           159: is found under the user's home directory.
        !           160: The user's default shell parameters are set upon beginning a new
        !           161: session from a startup profile
        !           162: (called \file{.profile} for \pgm{sh} users
        !           163: or \file{.cshrc} for \pgm{csh} users);
        !           164: the default parameters for \MH/ commands are taken from a file called
        !           165: \profile/ in the user's home directory.
        !           166: The shell has an {\it environment\/};
        !           167: \MH/ has a \context/ file.
        !           168: Each of the user's directories has files;
        !           169: each of the user's \MH/ folders has messages.
        !           170: 
        !           171: These parallels have a basis not only in \MH/'s high level mail
        !           172: handling model,
        !           173: but also in the way low level shell and file
        !           174: system conventions have been abstracted to implement \MH/ conventions.
        !           175: Directories are folders; files are messages.
        !           176: The \Mail/ directory forms the root of a virtual file subsystem within
        !           177: which the user operates on mail without disturbing files outside this
        !           178: mail handling domain. 
        !           179: 
        !           180: \tagfigure{1}{\MH/ File Subsystem\\(directories are shaded)}{MHfiles}
        !           181: \tagdiagram{2}{Elaborated \MH/ Profile}{elab}
        !           182: \subsection{The \MH/ Profile}
        !           183: The \profile/ contains plaintext that describes the user's default mail
        !           184: handling parameters.
        !           185: An example of an elaborated profile is shown in Figure~\elab.
        !           186: 
        !           187: Each line in the profile consists of an \MH/ parameter name terminated
        !           188: with a colon (`:') followed by parameter values.
        !           189: In this example,
        !           190: ``global'' parameters are listed in the first few lines,
        !           191: with program-specific parameters following.
        !           192: Each \MH/ program examines global parameters as well as any parameter
        !           193: with the same name by which the program was invoked.
        !           194: For example,
        !           195: the \pgm{comp} program, which is used to compose new messages to be sent,
        !           196: examines the entries:
        !           197: \medskip
        !           198: {\advance\leftskip by2\parindent
        !           199: \uitem{Path}
        !           200: The path parameter specifies the name of the \MH/ root directory.
        !           201: This is normally named \Mail/.
        !           202: 
        !           203: \uitem{Editor}
        !           204: The editor parameter specifies which text editor is first invoked to create
        !           205: the header information and body of a message draft.
        !           206: In most cases, this editor is the \MH/ default editor, \pgm{prompter}.
        !           207: 
        !           208: \uitem{Draft-Folder}
        !           209: This parameter specifies a folder within which new message drafts
        !           210: are to be created.
        !           211: The draft folder mechanism is an advanced feature of \MH/ that is
        !           212: given separate treatment in a later segment of this paper.
        !           213: 
        !           214: \uitem{comp}
        !           215: The program-specific parameter examined by \pgm{comp} lists
        !           216: user-default options.
        !           217: \par}
        !           218: \medskip
        !           219: 
        !           220: \noindent
        !           221: Other programs invoked by \pgm{comp}
        !           222: (e.g. \pgm{prompter} and \pgm{send\/}) would examine their own profile 
        !           223: entries as well.
        !           224: \MH/ programs have reasonable compiled-in defaults and also permit options to
        !           225: be specified on the shell command line with which the programs are invoked.
        !           226: The order of override precedence is: command line options first,
        !           227: \profile/ options second, and compiled-in defaults last.
        !           228: 
        !           229: Each program option is prefixed by a dash (`-') following the \unix/
        !           230: convention.
        !           231: Unlike most \unix/-style options,
        !           232: however, the options are words rather than single letters.
        !           233: An option may be abbreviated to an unambiguous prefix.
        !           234: Each \MH/ program has a \switch{help} option that
        !           235: displays a brief summary of the program's available options.
        !           236: 
        !           237: \subsection{Folders and Messages}
        !           238: In a typical paper-oriented office,
        !           239: new correspondence arrives and is stacked in an ``in box'',
        !           240: while outgoing correspondence is placed in an ``out box''.
        !           241: Processed material is stored in
        !           242: appropriately labelled folders and filed away for future reference.
        !           243: This state of affairs is modelled in \MH/ with {\it folders}
        !           244: and {\it messages},
        !           245: which are simply text files (one message per file) stored
        !           246: under the folder directories.
        !           247: Most of the user's folders are kept under the \Mail/ directory.
        !           248: 
        !           249: A folder is given an alphanumeric name permissible within the \unix/ file
        !           250: system structure,
        !           251: and each message stored therein is given a numeric name in the range 1..1999.
        !           252: The upper bound on message numbers was
        !           253: selected for efficient access to an internal representation,
        !           254: an array of bits (a ``bit set''),
        !           255: with each bit indicating the presence or
        !           256: absence of a message with a number in the range 1..1999.
        !           257: This internal representation also restricts the order of multiple
        !           258: message reference to an ascending numerical sequence.
        !           259: Other representations have been studied
        !           260: (e.g., an unsorted sparse array of integers),
        !           261: but have been rejected for reasons of efficiency.
        !           262: Folders may contain subfolders,
        !           263: corresponding to \unix/ tree-structured directories.
        !           264: For the sake of completeness,
        !           265: it might be said that ``sub-messages'' exist insofar as message ``digests'',
        !           266: which nest messages inside other messages,
        !           267: are supported by certain advanced \MH/ functions.
        !           268: 
        !           269: The current working folder is the default folder selected for almost
        !           270: all \MH/ commands.
        !           271: To select explicitly a folder for mail handling
        !           272: commands entails specifying the name of the folder, prefixing the name
        !           273: with a plus-symbol (`+').
        !           274: An example is: \example refile\ 1\ 2\ 3\ +chron/yr.1984\endexample
        !           275: This command re-files the selected messages
        !           276: (\file{1}, \file{2}, and \file{3} here)
        !           277: from the current working folder to a subfolder under the
        !           278: folder \file{chron} named \file{yr.1984}.
        !           279: To see the folder/subfolder relationship, refer to Figure~\MHfiles.
        !           280: 
        !           281: The plus-symbol notation is specific to those folders immediately
        !           282: subordinate to the \Mail/ directory.
        !           283: This is analogous to ``absolute pathnames'' in \unix/---those
        !           284: files whose positions in the file system
        !           285: hierarchy are given starting with the system root,
        !           286: names prefixed with the slash character (`/').
        !           287: To specify folders subordinate to the current working folder,
        !           288: an at-sign (`@') is substituted for (`+').
        !           289: It is permitted to use \unix/ dot notation to specify parent folders.
        !           290: Referring to Figure~\MHfiles,
        !           291: if the current working folder were \eg{+chron/yr.1985},
        !           292: then the command \example folder\ @../yr.1984\endexample
        !           293: \noindent
        !           294: selects the subfolder \file{yr.1984} in the parent directory
        !           295: \file{chron}, as the new current working folder.
        !           296: While the current working folder is normally the default, it may be
        !           297: specified explicitly as \eg{@.}.
        !           298: 
        !           299: \subsection{The Context File}
        !           300: The \profile/ contains static information about the user's
        !           301: preferences.
        !           302: A \context/ file, contained in the \Mail/ directory,
        !           303: contains the current mail handling environment information,
        !           304: which changes as different folders, messages, and named message lists
        !           305: (called {\it message sequences\/})  are selected, created, and updated.
        !           306: This information is retained between invocations of \MH/ commands,
        !           307: and is preserved across system sessions.
        !           308: 
        !           309: \tagdiagram{3}{Elaborated Reply Template}{replcomps}
        !           310: \subsection{Templates}
        !           311: The message draft composition functions
        !           312: (\pgm{comp}, \pgm{repl}, \pgm{forw}, and \pgm{dist\/})
        !           313: use certain default header formats,
        !           314: which may be changed by the user through the use of message templates.
        !           315: The exact format of a template may vary among commands.
        !           316: An example of an elaborated template for the reply command \pgm{repl} is
        !           317: shown in Figure~\replcomps.
        !           318: 
        !           319: This template specifies how the automatically-generated header for a
        !           320: draft message in reply to a source message is to be formatted.
        !           321: The syntax is capable of directing output of header lines based on the
        !           322: presence or absence of other header lines in the source message.
        !           323: 
        !           324: Other kinds of templates are used to specify the display formats of
        !           325: messages, or to specify the way that messages are to be included in
        !           326: other messages.  This is similar to the functionality provided by BBN
        !           327: Hermes\cite{HERMES},
        !           328: another powerful mail handling system for \tops20/ based systems.
        !           329: 
        !           330: \subsection{Explaining All This to New Users}
        !           331: There do exist people who do not like \MH/.%
        !           332: \nfootnote{At UCI, these
        !           333: people are reported to be weeded out at an early stage and quietly taken to the
        !           334: Ministry of Love to be made {\it uncrimethinkful}.}
        !           335: The emerging pattern of complaints from such people indicates that \MH/
        !           336: accentuates their perceptions of the deficiencies of \unix/,
        !           337: to wit, lack of interactivity and lack of easily found help facilities.
        !           338: Also,
        !           339: some feel that the proximity of the mail handling environment to the
        !           340: operating system is a distraction, rather than an asset.
        !           341: There have been some attempts to make \MH/ more accessible to users who prefer
        !           342: menu-oriented or monolithic mail system interfaces.%
        !           343: \nfootnote{For example,
        !           344: \pgm{mhe} from Brian Reid of Stanford University
        !           345: and \pgm{emh} from Marshall Rose
        !           346: are instances of macro packages for James Gosling's \EMACS/ extensible editor,
        !           347: while the \pgm{hm} program from Jim Guyton of the Rand Corporation is a
        !           348: monolithic \MH/ interface.
        !           349: As of this writing,
        !           350: none of these programs is documented in the literature.}
        !           351: 
        !           352: In truth,
        !           353: users new to \unix/ do not always acclimate to \MH/ easily.
        !           354: The command set is undistinguishably mixed in with all other \unix/
        !           355: utilities, and it is not easy, without aid of a manual,
        !           356: to pick out the necessary commands.
        !           357: \MH/ does not provide any ``hand-holding'' to guide
        !           358: the user through a minimally useful command subset.
        !           359: 
        !           360: Another problem is that the initial default user profile is too often sparse,
        !           361: containing only a \eg{Path:} parameter.
        !           362: \MH/ commands will perform adequately without specific information
        !           363: in the profile,
        !           364: so new users often neglect optionally useful \MH/ capabilities,
        !           365: eventually becoming frustrated with the limited default capabilities,
        !           366: yet unable to determine without researching through the user's manual,
        !           367: the necessary options that would solve their problems.
        !           368: 
        !           369: The currently available means for learning how to use \MH/ are:
        !           370: \medskip
        !           371: {\advance\leftskip by 2\parindent
        !           372: \item{$\bullet$}
        !           373: One-on-one tutoring by knowledgeable \MH/ users,
        !           374: which has so far shown the best results with new users.
        !           375: 
        !           376: \item{$\bullet$}
        !           377: Consulting the {\it \MH/ Tutorial\/}\cite{MRose84b},
        !           378: or the {\it \MH/ User's Manual\/}\cite{MRose85a}.
        !           379: 
        !           380: \item{$\bullet$}
        !           381: Using the \pgm{msh} (``\MH/ shell'') program as a training shell to read
        !           382: bulletin boards.
        !           383: The \pgm{msh} command is an interactive program that provides some help
        !           384: messages and can list available \MH/ commands.
        !           385: \par}
        !           386: \medskip
        !           387: 
        !           388: \noindent
        !           389: No on-line tutorial materials are presently distributed with the \mh5
        !           390: system, although there are some plans in the works to provide a program
        !           391: to help with setting up the user profile that would also provide
        !           392: operational tips for \MH/ and \unix/. 
        !           393: 
        !           394: It should be noted that these perceived defects of \MH/ do not affect its
        !           395: utility any more than analogous problems with any operating system
        !           396: will diminish its actual capabilities.
        !           397: Users may quarrel with the means chosen for orchestrating \MH/,
        !           398: but the fact remains that \MH/ is a very
        !           399: useful set of mail handling tools that is flexible,
        !           400: infinitely interoperable with other \unix/ text handling tools,
        !           401: and yet simple enough for new users to grasp once they are given the 
        !           402: proper start.
        !           403: The fact that better tutorial materials and training do not exist only means
        !           404: that some further work needs to be done in the area of user-education.
        !           405: 
        !           406: \section{A Few Advanced Features}              % mtr
        !           407: We now consider certain advanced features in \MH/.
        !           408: These features have been chosen to demonstrate some useful capabilities
        !           409: available to the \MH/ user.
        !           410: It should be noted that many capabilities of \MH/,
        !           411: such as shell scripts for extensibility,
        !           412: mail delivery hooks,
        !           413: the personal aliasing facility,
        !           414: and so forth,
        !           415: are not described here for lack of space.
        !           416: 
        !           417: \subsection{Draft Folders}                     % jns
        !           418: The {\it draft folder} facility provides a method by which several
        !           419: message drafts can be simultaneously composed and maintained until
        !           420: sent.
        !           421: The rationale for this is that partially composed message drafts,
        !           422: perhaps elaborate sets of separate messages,
        !           423: can be incrementally completed,
        !           424: while a folder provides a consistent organization for drafts in progress.
        !           425: This is comparable to similar situations in the ``paper world'' where
        !           426: contracts, business correspondence, and other communications,
        !           427: rather than being created serially with each posted in turn before composing
        !           428: the next,
        !           429: are usually left in various stages of
        !           430: completion before they are eventually mailed.
        !           431: 
        !           432: The \eg{Draft-Folder:} parameter value in the \MH/ profile is used to
        !           433: specify a default draft folder,
        !           434: where each draft is given a number and an ``artificial'' date stamp.
        !           435: Provided that the proper header fields have been completed,
        !           436: a \pgm{scan} listing of the draft folder provides a summary of
        !           437: each draft in progress:
        !           438: to whom the message is to be sent,
        !           439: the subject,
        !           440: the date of the draft's initial creation and optionally,
        !           441: the current size of the draft in terms of characters.
        !           442: Experienced users of \MH/ may often keep as many as five to ten unfinished
        !           443: drafts in their draft folder.
        !           444: ``Draft clutter'' can be remedied easily with the \pgm{rmm} command.
        !           445: 
        !           446: \subsection{Message Selection}                 % stef
        !           447: \MH/ commands accept {\it message sequence} specifications to specify which
        !           448: \arg{msg} or \arg{msgs} are to be operated upon.
        !           449: Here are some examples:
        !           450: \example scan\ 1\ 3\ 5\ 19\ 185\endexample
        !           451: to get a scan listing of messages 1, 3, 5, 19 and 185.
        !           452: \example scan\ pseq\endexample
        !           453: to get a scan listing of whatever message sequence was given to the previous
        !           454: MH command (in this case 1, 3, 5, 19, and 185).
        !           455: \example show\ first\ last\endexample
        !           456: to get a display of the first and last messages in the folder.
        !           457: The \MH/ sequences named \eg{first} and \eg{last} are system defined pseudo
        !           458: sequences which act like explicit sequences when given to MH commands.
        !           459: Others are \eg{cur}, \eg{next}, \eg{prev},
        !           460: and \eg{all} which respectively specify the ``current'' message,
        !           461: the ``next'' after cur,
        !           462: the ``previous'' message before cur,
        !           463: or ``all'' messages in the current-folder.
        !           464: The \pgm{scan} assumes \eg{all} while show assumes \eg{cur},
        !           465: unless overridden on the command line.
        !           466: Over-ride precedence is: command-line first,
        !           467: \profile/ second,
        !           468: and compiled-in default last.
        !           469: 
        !           470: Users can define additional sequences for similar use,
        !           471: but must avoid using reserved names.
        !           472: A few optional sequence names have been preempted by \MH/,
        !           473: such as \eg{pseq} to mean the
        !           474: ``sequence used by the previous MH command,''
        !           475: and \eg{unseen} to mean the ``messages not yet seen by the user.''
        !           476: Sometimes these preempted names can be changed by resetting them in the
        !           477: user's \MH/ profile,
        !           478: but these facilities are beyond the scope of this discussion.
        !           479: 
        !           480: The mark command can be used to set the values for user-defined sequences:
        !           481: \example mark\ 1\ 3\ 5\ -seq\ zzz\\
        !           482:         mark\ 4\ 5\ 9\ -seq\ zzz\ -nozero\endexample
        !           483: will create a user-sequence named \eg{zzz} and put the sequence \eg{1 3 5}
        !           484: in it.
        !           485: The \pgm{mark} command assumes that any prior content in an
        !           486: existing user-sequence should be ``zeroed'' before the new sequence value is
        !           487: recorded.
        !           488: This can be prevented with a \switch{nozero} switch on the command line,
        !           489: to add \eg{4 5 9} to the original \eg{1 3 5} to yield \eg{1 3 4 5 9}.
        !           490: \example mark\ pseq\ zzz\ -seq\ zzznew\endexample
        !           491: will create a new sequence named \eg{zzznew} and set its value to the combined
        !           492: (inclusive or) of the existing user-sequences in \eg{pseq} and \eg{zzz} for
        !           493: its value.
        !           494: 
        !           495: Another more powerful way to set the values of a user-sequence is with
        !           496: the pick command, which provides full string search capabilities:
        !           497: \example pick\ -from\ mrose\ -seq\ yyy\\
        !           498:         pick\ -from\ mrose\ -seq\ yyy\ -list\endexample
        !           499: will search though all the \eg{From:} fields in the current folder for the
        !           500: string \eg{mrose} and place the list of ``hits''
        !           501: in the sequence named \eg{yyy}.
        !           502: The \switch{list} switch will cause the resulting list to also be displayed on
        !           503: the user's terminal.
        !           504: If no \switch{seq\ name} switch is given,
        !           505: pick will assume \switch{list}
        !           506: and will simply display the resulting list of hits on the user's terminal.
        !           507: 
        !           508: This \switch{list} behavior of pick allows users to take advantage of the
        !           509: \unix/ backquoting facility to embed searches in other \MH/ commands.
        !           510: \example scan\ \bq{pick\ -from\ mrose}\endexample
        !           511: will produce a scan listing of \switch{from\ mrose} hits because the
        !           512: \unix/ shell will spawn a process to execute the
        !           513: \eg{pick\ -from\ mrose} segment and return the \switch{list}
        !           514: results as the message sequence to be scanned.
        !           515: \example mark\ pseq\ -seq\ zzz\endexample
        !           516: could then be used to capture the ``previous sequence'' in zzz for later use.
        !           517: 
        !           518: One last facility should be mentioned here.
        !           519: It is also possible to negate a sequence to specify a new sequence.
        !           520: The default negation string is \eg{not}.
        !           521: \example scan\ notzzz\\
        !           522:         mark\ notzzz\ -seq\ zzznot\endexample
        !           523: will give the user a scan listing of all the messages in the current folder
        !           524: that are not included in the sequence \eg{zzz}.
        !           525: The mark example will of course record the negation of zzz in zzznot.
        !           526: It is a bad idea to use the string \eg{not} as the beginning of any
        !           527: user-sequence name,
        !           528: if \eg{not} is defined as the negation string.
        !           529: (Users can choose a different negation string.)
        !           530: 
        !           531: From this discussion,
        !           532: it should be clear that \MH/ provides a uniform set of ways to capture
        !           533: and use sequences to augment the user's short- and long-term
        !           534: memory and to manipulate lists of interesting messages.
        !           535: User-sequences are normally stored as RFC822 labeled text lines in a file
        !           536: (e.g., \sequences/)
        !           537: in the folder with the messages referred to in the sequence.
        !           538: If a user does not have write access to a folder,
        !           539: then the \MH/ \pgm{mark} and \pgm{pick} commands will
        !           540: create a ``private'' sequence in the user's \context/ file.
        !           541: Switches are available to give the user control over
        !           542: the choice of \switch{private} or \switch{public} sequence options.
        !           543: 
        !           544: Since user-sequences are stored as ordinary text lines in RFC822 labeled
        !           545: fields,
        !           546: there is no prohibition against someone writing programs to perform
        !           547: any kind of useful manipulation on \MH/ sequences.
        !           548: Boolean operators can be implemented,
        !           549: or complex indexing structures could be developed to serve special purposes.
        !           550: If a DBMS can utilize \unix/ pathnames or \MH/ \arg{+folder} and
        !           551: message names,
        !           552: then the full power of the DBMS might be applied.
        !           553: The intention of \MH/ development teams has always been to leave open the
        !           554: widest possible array of options for later extension.
        !           555: The only restrictions should be the user's ingenuity,
        !           556: programming prowess, and the available machine resources.
        !           557: Unfortunately these resources always seem to be available in
        !           558: limited quantities.
        !           559: 
        !           560: \subsection{Distribution Lists}                        % mtr
        !           561: \MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.%
        !           562: \nfootnote{The UCI BBoards facility can run under either the \MMDF/ or
        !           563: \SendMail/,
        !           564: or in a more restricted form under stand-alone \MH/.}
        !           565: This facility permits the efficient distribution of interest group messages
        !           566: on a single host,
        !           567: to a group of hosts under a single administration,
        !           568: and to the ARPA Internet community.
        !           569: 
        !           570: Described simply, an interest group is composed of a number of subscribers
        !           571: with a common interest.
        !           572: These subscribers post mail to a single address, known as a
        !           573: {\it distribution} address (e.g., {\tx MH-Workers@UCI}).
        !           574: From this distribution address, a copy of the message is sent to each
        !           575: subscriber.
        !           576: Each group has a {\it moderator},
        !           577: which is the person that runs the group.
        !           578: This moderator can usually be reached at a special address,
        !           579: known as a {\it request} address (e.g., {\tx MH-Workers-Request@UCI}).
        !           580: Usually, the responsibilities of the moderator are quite simple,
        !           581: since the mail system handles distribution to subscribers automatically.
        !           582: In some interest groups,
        !           583: instead of each separate message being distributed directly to subscribers,
        !           584: a batch of (related) messages are put into a {\it digest} format by the
        !           585: moderator and then sent to the subscribers.
        !           586: Although this requires more work on the part of the moderator
        !           587: and introduces delays,
        !           588: such groups tend to be better organized.
        !           589: 
        !           590: Unfortunately, some problems arise with the scheme outlined above.
        !           591: First, if two users on the same host subscribe to the same interest group,
        !           592: two copies of the message will be delivered.
        !           593: This is wasteful of both processor and disk resources at that host.
        !           594: 
        !           595: Second,
        !           596: some groups carry a lot of traffic.
        !           597: Although subscription to a group does indicate interest on the part of a
        !           598: subscriber,
        !           599: it is usually not interesting to get 50 messages or so delivered to 
        !           600: the user's private maildrop each day,
        !           601: interspersed with {\it personal} mail,
        !           602: that is likely to be of a much more important and timely nature.
        !           603: 
        !           604: Third, if a subscriber's address in a distribution list 
        !           605: becomes ``bad'' somehow and causes failed mail to be returned,
        !           606: the originator of the message is normally notified.
        !           607: It is not uncommon for a large list to have several bogus addresses.
        !           608: This results in the originator being flooded with ``error messages'' from
        !           609: mailers across the Internet stating that a given address on the list was
        !           610: bad.
        !           611: Needless to say,
        !           612: the originator usually does not care if the bogus addresses got a copy
        !           613: of the message or not.
        !           614: The originator is merely interested in posting a message
        !           615: to the group at large.
        !           616: On the other hand,
        !           617: the moderator of the group does care if there are bogus addresses on the list,
        !           618: but ironically does not receive notification.
        !           619: 
        !           620: To solve all of these problems,
        !           621: the UCI BBoards facility introduces a new entity into the picture:
        !           622: all interest group mail is handled by a special component of the mail system.
        !           623: The distribution address maps to a special {\it channel} that performs
        !           624: several actions.
        !           625: First, if local delivery is to be performed,
        !           626: then a copy of the message is placed in a global maildrop for the interest
        !           627: group with a timestamp and a unique number.
        !           628: Local users can read messages posted for the interest group by reading this
        !           629: ``public'' maildrop.
        !           630: Second, if further distribution is to take place,
        !           631: a copy of the message is sent to the distribution address in such a way that
        !           632: if any of the addresses are bogus,
        !           633: failure notices will be returned to the local maintainer of the group
        !           634: address list, rather than the originator of the message.
        !           635: 
        !           636: This scheme has several advantages:
        !           637: First, messages delivered to the local host are processed and saved once
        !           638: in a globally accessible area.
        !           639: The UCI BBoards facility supports software which allows a user to query an
        !           640: interest group for new messages and to read and process
        !           641: those messages in the \MH/-style.
        !           642: Second, once a host administrator subscribes to an interest group,
        !           643: each user can join or quit the list's readership without
        !           644: contacting anyone.
        !           645: Third, a hierarchical distribution scheme can be constructed to
        !           646: reduce the amount of delivery effort.
        !           647: Fourth, errors are prevented from propagating.
        !           648: When an address on the distribution list goes bad,
        !           649: the list moderator who is immediately responsible for the address is notified.
        !           650: If a local moderator does not exist,
        !           651: then the local PostMaster is notified (not the global group moderator).
        !           652: 
        !           653: In addition to solving the problems outlined above,
        !           654: the UCI BBoards facility supports several other capabilities.
        !           655: BBoards may be automatically archived in order to conserve disk space and
        !           656: reduce processing time when reading current items.
        !           657: Also,
        !           658: the archives can be separately maintained on tape for access by interested
        !           659: researchers.
        !           660: 
        !           661: Special alias files may be generated which allow the \MH/ user to shorten
        !           662: address type-in.
        !           663: For example, instead of sending to {\tx SF-Lovers@Rutgers},
        !           664: a user of \MH/ usually sends to \eg{SF-Lovers} and the \MH/ aliasing
        !           665: facility automatically makes the appropriate expansion in the headers of the
        !           666: outgoing message.
        !           667: Hence,
        !           668: the user need only know the name of an interest group and not its global
        !           669: network address.
        !           670: 
        !           671: Finally, the UCI BBoards facility supports {\it private} interest groups
        !           672: using the \unix/ group access mechanism.
        !           673: This allows a group of people on the same or different machines to conduct a
        !           674: private discussion.
        !           675: 
        !           676: The practical upshot of all this is that the UCI BBoards facility automates
        !           677: the vast majority of BBoards handling from the point of view of both the
        !           678: PostMaster and the user.
        !           679: 
        !           680: \MH/ provides three programs to deal with interest groups.
        !           681: The \pgm{bbc} program is used to check on the status of one or more groups,
        !           682: and to optionally start an \MH/ shell on those groups which the user is
        !           683: interested in.
        !           684: The \pgm{bbl} program can be used to perform manual maintenance on a
        !           685: discussion group beyond the normal automatic capabilities of the UCI BBoards
        !           686: facility.
        !           687: Finally,
        !           688: the \pgm{msh} program implements an \MH/ shell for reading BBoards,
        !           689: in which nearly all of the \MH/ commands are implemented in a single program.
        !           690: 
        !           691: Observant readers may note that the use of \pgm{msh} is contrary to the \MH/
        !           692: philosophy of using relatively small, single-purposed programs.
        !           693: Sadly,
        !           694: the authors admit that this is true.
        !           695: In an effort to avoid some problems with shared-access and message naming
        !           696: conventions (which are beyond the scope of this paper),
        !           697: BBoards are kept in maildrop format (monolithic) instead of folders.
        !           698: Some research has gone into overcoming this problem in order to restore
        !           699: \MH/'s purity of purpose,
        !           700: but all solutions proposed to date are either unworkable or require
        !           701: significant recoding of \MH/'s internals.
        !           702: 
        !           703: \subsection{Encapsulation}                     % mtr
        !           704: As described above,
        !           705: some interest groups appear in digest form.
        !           706: This means that the messages which appear in such a forum actually
        !           707: encapsulate other messages in their body.
        !           708: It turns out that the generation of a digest is not at all unlike the
        !           709: generation of a draft which forwards one or more messages.
        !           710: In RFC934\cite{MRose85b},
        !           711: a method is proposed to standardize message encapsulation for the ARPA
        !           712: Internet community.
        !           713: \MH/ uses this method for the generation of digests,
        !           714: forwardings,
        !           715: and blind-carbon-copies.
        !           716: 
        !           717: A key requisite for using an encapsulation technique for digests and
        !           718: forwardings is the ability to later decapsulate the contents.
        !           719: Without this ability,
        !           720: the forwarded messages are of little use to the recipients because they can
        !           721: not be distributed, forwarded, replied-to, searched-for,
        !           722: or otherwise processed as separate individual messages.
        !           723: In the case of a digest,
        !           724: a bursting capability is especially useful.
        !           725: Not only does the ability to burst a digest permit a recipient of the digest
        !           726: to reply to an individual digestified message,
        !           727: but it also allows the recipient to selectively process the other messages
        !           728: encapsulated in the digest.
        !           729: 
        !           730: For example,
        !           731: a single digest issue usually contains more than one topic.
        !           732: A subscriber may only be interested in a subset of the topic discussed in a
        !           733: particular issue.
        !           734: With a bursting capability,
        !           735: the subscriber can burst the digest,
        !           736: scan the headers,
        !           737: and process those messages which are of interest.
        !           738: The others can be ignored,
        !           739: if the user so desires.
        !           740: 
        !           741: Note that with proper encapsulation technology,
        !           742: one can argue for the re-distribution of messages simply becoming
        !           743: special cases of message forwarding.
        !           744: For example,
        !           745: the NBS Standard for Mail Interchange\cite{FIPS98}
        !           746: and the recent CCITT draft on Mail Handling Systems standards\cite{X.400}
        !           747: both discourage the re-distribution facility in favor of forwarding
        !           748: by encapsulation.
        !           749: 
        !           750: \subsection{Encapsulation and Blind-Carbon-Copies} % mtr
        !           751: Many user agents support a blind-carbon-copy facility.
        !           752: \MH/ implements this using a form of encapsulation.
        !           753: It may not be apparent to the reader as to why encapsulation of the original
        !           754: message is a good way to deliver blind-carbon-copies.
        !           755: With a blind-carbon-copy facility,
        !           756: two types of addressees are possible in the draft to be sent:
        !           757: {\it visible} and {\it blind}.
        !           758: The visible recipients are listed as addresses in the \eg{To:} and \eg{cc:}
        !           759: fields,
        !           760: and the blind recipients are listed in the \eg{Bcc:} fields of the draft.
        !           761: The idea behind this facility is that copies of the draft which are
        !           762: delivered to the \eg{To:} and \eg{cc:} recipients should show the visible
        !           763: recipients only.
        !           764: 
        !           765: A major concern with a blind-carbon-copy facility
        !           766: is that blind recipients should be prevented from accidentally replying to the
        !           767: message in such a way that the visible recipients are included as addressees
        !           768: in the reply.
        !           769: 
        !           770: There are several methods to implement this facility.
        !           771: Most rely on posting two drafts with the \MTS/.
        !           772: One draft is destined for visible recipients,
        !           773: and simply lacks the \eg{Bcc:} fields of the original draft.
        !           774: The second draft is destined for the blind recipients.
        !           775: The question then arises as to what form this latter draft posted should take.
        !           776: 
        !           777: One approach might be to disable the \eg{To:} and \eg{cc:} fields of the
        !           778: draft sent to the blind recipients
        !           779: (e.g., by prefixing the string \eg{BCC-} to these fields).
        !           780: Unfortunately,
        !           781: this is often very confusing to the blind recipients
        !           782: because it differs from what the visible recipients got.
        !           783: Although accidental replies are not possible,
        !           784: it is often difficult to tell that the message received is the result of a
        !           785: blind-carbon-copy.
        !           786: 
        !           787: The method used by \MH/ is to post two drafts,
        !           788: a visible draft for the visible recipients,
        !           789: and a blind draft for the blind recipients.
        !           790: The visible draft consists of the original draft without any \eg{Bcc:} fields.
        !           791: The blind draft contains the visible message as a forwarded message.
        !           792: The headers for the blind draft contain the minimal RFC822 headers
        !           793: (\eg{From:} and \eg{Date:})
        !           794: and,
        !           795: if the original draft had a ``Subject:'' field,
        !           796: then this header field is also included.
        !           797: In addition,
        !           798: \MH/ alerts the recipient that the message is a blind-carbon-copy by
        !           799: placing this information in the initial encapsulation information in the
        !           800: blind recipient's copy.
        !           801: This scheme prevents inadvertent replies while allowing the recipient
        !           802: full access to an exact copy of what was sent to the visible recipients.
        !           803: 
        !           804: \section{\MH/ as a Record Handler}             % stef
        !           805: Although message format standards such as RFC822
        !           806: (and its predecessors) were originally devised to facilitate
        !           807: computer processing of interpersonal messages,
        !           808: there is no special reason why the concept should be
        !           809: limited to interpersonal message processing.
        !           810: Messages are just one of a variety of useful record forms that might
        !           811: be created in one place and transfered to another for processing.
        !           812: In this regard,
        !           813: RFC822 wisely left open the option for higher level applications to use
        !           814: arbitrary header names or field contents by proscribing \MTS/ use
        !           815: of header names beginning with \eg{X-}.
        !           816: 
        !           817: \MH/ carries though on this idea by allowing the \pgm{pick} command
        !           818: to accept any arbitrary field name for string searches,
        !           819: so MH users can select on any arbitrary field name without prior definition.
        !           820: Beyond this,
        !           821: since all messages are simply files in \unix/ directories,
        !           822: applications can be developed to apply any programmable process to
        !           823: any selected message.
        !           824: 
        !           825: For example,
        !           826: a {\it Time Card Form} might be called up by an \MH/ user with
        !           827: \example comp\ -form\ timecomps\endexample
        !           828: to enter time and attendance information into \eg{X-time$\tdots$:} fields in a
        !           829: draft message record.
        !           830: The \file{timecomps} form would include the address of a
        !           831: supervisor who should validate the information,
        !           832: along with empty fields to be filled in with data.
        !           833: In fancy applications,
        !           834: this might be done with a sophisticated interactive data entry tool
        !           835: which would validate entered information,
        !           836: but this is an open choice within the \MH/ framework.
        !           837: Another
        !           838: alternative would be to use a received message as the blank form to add a
        !           839: degree of central control over time and attendance reporting forms.
        !           840: 
        !           841: Receiving supervisors could simply register approval by using the \MH/
        !           842: \pgm{dist} command to resend subordinates' time cards to higher approval
        !           843: levels, or
        !           844: to send them to a time card collection address.
        !           845: The \MH/ \pgm{dist} command automatically inserts ``ReSent'' header fields
        !           846: showing who resent it and the resending date.
        !           847: Alternatively,
        !           848: the MH \pgm{forw} command could be used to transfer a batch of approved time
        !           849: cards to the next processing station.
        !           850: If desired, a new ``approval'' command could be programmed to provide a more
        !           851: trusted authentication, perhaps with encryption of the content.
        !           852: Trusted mail systems, such as \trustedmail/\cite{MRose85c},
        !           853: are becoming available for this purpose.
        !           854: 
        !           855: At the final collection destination,
        !           856: an automated User Agent could be programmed to directly load the data into
        !           857: the Time and Attendance DBMS by
        !           858: parsing and decoding the data contained in the \eg{X-time$\tdots$:} fields.
        !           859: It might be noted that while the RFC822 does not restrict the
        !           860: internal forms of messages,
        !           861: it is necessary to conform to the interchange standard if specialized filters
        !           862: for message headers are not to be built to serve as {\it export laundries}
        !           863: (a term originating with Stephen H.~Willson to describe conformance
        !           864: transformations in \Ada/).
        !           865: 
        !           866: \subsection{Mapping Between Record Modes (DBMS/MHS)}
        !           867: This time and attendance example suggests that it is possible to define
        !           868: one-to-one mappings between RFC822 fields and DBMS data elements.
        !           869: For every DBMS data element definition,
        !           870: there is a potential corresponding RFC822 transferable equivalent
        !           871: definition which can facilitate mail transfers of record information.
        !           872: Indeed,
        !           873: a large portion of the definitional work is already done where a Data Base
        !           874: has already been defined.
        !           875: All that remains is to define the RFC822 equivalents.
        !           876: 
        !           877: The suggestion that a batch of time cards be forwarded inside a ``cover''
        !           878: message implies that it is possible in the \MH/ framework to recursively
        !           879: bundle messages within messages, and be able to recover the originals for
        !           880: separate processing at a receiving destination.
        !           881: The \MH/ \pgm{burst} command can be applied recursively for this purpose
        !           882: because \MH/ encapsulation uses an unambiguous scheme to delimit messages
        !           883: that are enclosed inside other messages.
        !           884: Thus,
        !           885: it should be possible to extract a structured set of records from a DBMS
        !           886: and mail the set to a foreign site for processing, or reinsertion into
        !           887: another DBMS.
        !           888: As long as the DBMS data element definitions
        !           889: correctly correspond to the RFC822 definitions,
        !           890: it is not even necessary
        !           891: for the source and destination DBMS systems to be the same.
        !           892: 
        !           893: From this discussion,
        !           894: it is concluded that the \MH/ framework can be useful
        !           895: for building distributed record handling systems where people at widely
        !           896: scattered locations must create and submit record forms for processing
        !           897: at distant locations.
        !           898: This might prove to be especially effective when
        !           899: a mail system is also needed for other communication purposes.
        !           900: A network of sales offices is a good example,
        !           901: where general message service would be used for communications
        !           902: with remote manufacturing and distribution centers,
        !           903: and could also be used for an order entry system.
        !           904: 
        !           905: Another example might be for structured communications, as occur in
        !           906: requisition and purchasing systems.
        !           907: Requisitions could be filled in and mailed to approval offices,
        !           908: and resent or forwarded to others for action.
        !           909: At some point,
        !           910: the requisitions could flow into other other more suitable
        !           911: processing systems as needed.
        !           912: At the very least, the ability to originate
        !           913: requisitions can be distributed to anyone with access to a mail system
        !           914: that can originate a proper requisition form.
        !           915: 
        !           916: As a last example,
        !           917: \MH/ already supports group discussions with its BBoard facilities
        !           918: which allow for automatic sorting of mail by group address,
        !           919: with shared private or public group access to contributed items.
        !           920: As has been shown to be possible with administrative record systems,
        !           921: there is no obvious limit to the ways that group discussion traffic
        !           922: might be organized into structured collections with indices,
        !           923: annotations, or reference pointers
        !           924: to aid in making conference archives more useful.
        !           925: Indeed, \MH/ tools could even be used to feed discussion items into
        !           926: existing conference systems.
        !           927: 
        !           928: \section{Distributed Mail}                     % mtr
        !           929: Next, we consider how \MH/ might be used in a distributed mail environment.
        !           930: Two schemes are discussed:
        !           931: one in which connectivity is high and connections are relatively ``cheap'',
        !           932: and one in which connectivity is low and connections are ``expensive''.
        !           933: 
        !           934: \subsection{The ARPA Internet Environs}                % mtr
        !           935: The ARPA Internet community consists of many types of heterogeneous nodes.
        !           936: Some hosts are large mainframe computers,
        !           937: others are personal workstations.
        !           938: All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}.
        !           939: Messages which conform to the Standard for the Format of ARPA Internet Text
        !           940: Messages\cite{DCroc82}
        !           941: are exchanged using the Simple Mail Transfer Protocol\cite{SMTP}.
        !           942: 
        !           943: On smaller nodes in the ARPA Internet it is often impractical to maintain
        !           944: a message transport agent.
        !           945: For example,
        !           946: a workstation may not have sufficient resources (cycles, disk space)
        !           947: in order to permit an SMTP server and associated local mail delivery system
        !           948: to be kept resident and continuously running.
        !           949: Furthermore,
        !           950: the workstation could be off-net for extended periods of time.
        !           951: Similarly,
        !           952: it may be expensive (or impossible) to keep a personal computer
        !           953: interconnected to an IP-style network for long periods of time.
        !           954: In other words,
        !           955: the node is lacking the resource known as ``connectivity''.
        !           956: 
        !           957: Despite this,
        !           958: it is often desirable to be able to process mail with \MH/ on these smaller
        !           959: nodes,
        !           960: and they often support a user agent to aid the tasks of mail handling.
        !           961: To solve this problem,
        !           962: a network node which can support a message transport entity
        !           963: (known as {\it service} host) offers
        !           964: a maildrop service to these less endowed nodes
        !           965: (known as {\it client} hosts).
        !           966: The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a
        !           967: workstation to dynamically access a maildrop on a service host to pick-up
        !           968: mail.%
        !           969: \nfootnote{Actually,
        !           970: there are three different descriptions of the POP.
        !           971: The first, cited in \cite{JReyn84},
        !           972: was the original description of the protocol,
        !           973: which suffered from certain problems.
        !           974: Since then,
        !           975: two alternate descriptions have been developed.
        !           976: The official revision of the POP\cite{MButl85},
        !           977: and the revision of the POP which \MH/ uses
        !           978: (which is documented in an internal memorandum in the \MH/ release).
        !           979: This paper considers the POP in the context of the \MH/ release.}
        !           980: The level of access includes the ability to
        !           981: determine the number of messages in the maildrop and the size of each message,
        !           982: as well as to retrieve and delete individual messages.
        !           983: More sophisticated implementations of the POP server
        !           984: are able to distinguish between the header and body portion of each message,
        !           985: and send $n$ lines of a message to the POP client.
        !           986: This capability is useful in thinly connected environments where conservation
        !           987: of bandwidth is important.
        !           988: By utilizing a more intelligent POP client,
        !           989: a user may generate ``scan~listings'' and dynamically decide which messages
        !           990: are worth taking delivery on.
        !           991: The philosophy of the POP is to put intelligence in the
        !           992: POP clients and not the POP servers.
        !           993: 
        !           994: The underlying paradigm in which the POP functions is that of a
        !           995: split-slot/remote-\UA/ model.
        !           996: The client host (such as a workstation) is without a co-resident
        !           997: {\it message transport agent} (\MTA/),
        !           998: and thus makes use of a service host with an \MTA/ to obtain posting (SMTP)
        !           999: and delivery (POP) services.
        !          1000: The entity which supports this type of environment is called a remote-\UA/
        !          1001: since the user agent resides on a different host than its associated message
        !          1002: transport agent.
        !          1003: 
        !          1004: One very important issue which must be raised at this point is one of
        !          1005: authentication.
        !          1006: The POP requires that a client identify itself to the server using a
        !          1007: server-specific user-id and a server/user-specific password.
        !          1008: This authentication is required to prevent unauthorized entities from
        !          1009: accessing a maildrop on a POP service host.
        !          1010: It must be emphasized that the POP client is not a ``trusted'' entity of the
        !          1011: \MTS/ in any sense at all.
        !          1012: 
        !          1013: Ideally,
        !          1014: one would also like to authenticate mail as it is posted on the POP service
        !          1015: host using the SMTP.
        !          1016: Currently,
        !          1017: in the ARPA Internet community,
        !          1018: no authentication is done with SMTP transactions.
        !          1019: This is considered a shortcoming by those interested in researching the
        !          1020: split-\UA/ model of distributed mail.
        !          1021: The MZnet environment,
        !          1022: discussed in the next section,
        !          1023: has authentication facilities for posting mail.
        !          1024: 
        !          1025: The current release of \MH/ supports the above model fully:
        !          1026: a POP client program is available to retrieve a maildrop on a POP service
        !          1027: host.
        !          1028: In addition,
        !          1029: using the SMTP configuration for delivery in \MH/,
        !          1030: a user is able to specify a search-list of service hosts (and networks)
        !          1031: with which to try to post mail.
        !          1032: Using this search-list,
        !          1033: when an \MH/ user posts a draft,
        !          1034: the \pgm{post} program will attempt to establish an SMTP connection
        !          1035: with each host in the list to post the message until it succeeds.
        !          1036: Initial experimentation with the split-\UA/
        !          1037: in a local network environment has proved quite successful.
        !          1038: 
        !          1039: \subsection{The MZnet Environs}                        % jns
        !          1040: In 1983,
        !          1041: the MZnet project\cite{EStef84} at the University of California, Irvine
        !          1042: set out to study the problems involved with bringing
        !          1043: Internet-class mail handling facilities to personal computers.
        !          1044: The project used Apple~II computers running the CP/M 2.2 operating system.
        !          1045: Programming was done in a subset of the C language called BDS C.
        !          1046: The transport system was based on the \MMDF/ PhoneNet software,
        !          1047: and implemented a {\it split-slot} arrangement between a personal computer
        !          1048: and a larger,
        !          1049: centralized mail distribution system that performed user
        !          1050: authentication and provided a relatively secure mail transfer channel.
        !          1051: The user agent, CP/MH, was based on \MH/.
        !          1052: 
        !          1053: A conclusion of the experiment was that small personal computer systems
        !          1054: with dial-up phone connections constrain user agent systems design in
        !          1055: ways that require use of a {\it split-slot} interface between the \UA/
        !          1056: and its supporting \MTA/, and that this interface
        !          1057: best provides the required services if it has error controlled command
        !          1058: and data transfer facilities, with interactive behavior. 
        !          1059: Another conclusion indicated that a good design for a user agent in such
        !          1060: a small personal computer
        !          1061: environment could be based on a very modular architecture,
        !          1062: such as \MH/.
        !          1063: A final conclusion was that session-level authentication of the client \UA/
        !          1064: is required for both posting and delivery.
        !          1065: 
        !          1066: It should be noted that the MZnet project had a profound influence on the
        !          1067: development of the POP used by \MH/.
        !          1068: A somewhat more detailed discussion of the relations between the two
        !          1069: environments can be found in the POP description contained
        !          1070: in the \MH/ release.
        !          1071: 
        !          1072: \section{A Final Note}                         % jns
        !          1073: With the fifth major release of the \MH/ system,
        !          1074: it has become clear that most major increases in functionality can come
        !          1075: only at the expense of either efficiency or portability.
        !          1076: Although there has been great effort to keep \MH/ portable to a number of
        !          1077: \unix/ implementations,%
        !          1078: \nfootnote{As of this writing,
        !          1079: there are approximately 75~sites running \mh5
        !          1080: on five different implementations of \unix/.}
        !          1081: the divergence in process management facilities,
        !          1082: file system enhancements,
        !          1083: and even C~compiler capabilities
        !          1084: has already presented obstacles to some attempts to rehost the \MH/ code.
        !          1085: 
        !          1086: There has been some discussion of implementing specialized \MH/ daemons
        !          1087: that maintain context information over one or more sessions,
        !          1088: thus decreasing the amount of overhead involved in starting each \MH/ command.
        !          1089: Unfortunately,
        !          1090: even if such daemons were to be implemented,
        !          1091: they would be very difficult to move to versions of \unix/
        !          1092: without sophisticated process management facilities,
        !          1093: and even then the differences in ``philosophies''
        !          1094: of process management\cite{WJoy83,EOlse84}
        !          1095: would tend to keep such daemons system specific.
        !          1096: A better solution seems to be simply to tune existing code.
        !          1097: 
        !          1098: \section{Acknowledgements}
        !          1099: The authors would like to thank Norman Z.~Shapiro and
        !          1100: Phyllis Kantar of the Rand Corporation for their invaluable comments during
        !          1101: the preparation of this paper.
        !          1102: 
        !          1103: \section{Distribution Information}
        !          1104: For information concerning distribution mechanics for the current release of
        !          1105: \MH/, please contact:
        !          1106: $$\displayindent=\leftskip     \advance\displayindent by1.5\parindent
        !          1107:     \halign{\leftline{#}\cr
        !          1108:        Support Group\cr
        !          1109:        Attn: MH Distribution\cr
        !          1110:        Department of Information and Computer Science\cr
        !          1111:        University of California, Irvine\cr
        !          1112:        Irvine, CA  92717\qquad USA\cr
        !          1113:        \cr
        !          1114:        714/856--6852\cr
        !          1115: }$$

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