![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to text.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / multifarious|
Return to text.tex CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / multifarious |
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.