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