5 \section{Introduction} % mtr
6 The UCI version of the Rand Message Handling System, \MH/,
7 is a software system that performs two functions:
9 it interfaces a user to a message transport system,
10 so the user may receive and send mail;
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.
15 while not responsible for the delivery of messages,
16 \MH/ aids the user in handling mail.
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.
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.
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.
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.
41 the dozen or so beta test sites for \mh5
42 provided tremendous help in stabilizing the current release.
44 \MH/ runs on different versions of the \unix/ operating system
45 (such as Berkeley~4.2\bsd/ and various flavors of v7).
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
53 which forms the software-backbone for CSnet\cite{DCome83} mail relay service;
55 the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
57 a stand-alone delivery system.
59 This paper is organized in a straight-forward fashion:
61 the \MH/ philosophy of mail handling is presented,
62 along with a description of the environment which the \MH/ user is given to
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.
69 user interface issues in mail handling are addressed,
70 and the merits of \MH/'s approach is critically examined.
72 the \mh5 distribution package is described.
74 we conclude by discussing the authors' experience with \MH/ development
75 and introducing areas where \MH/ may be further developed.
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.
81 \section{The \MH/ Philosophy} % mtr
82 Although \MH/ has many traits which tend to distinguish it from other systems
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
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,
98 facilities which \MH/ provides.
100 the user may intersperse mail handling commands with other commands in an
102 making use of command handling capabilities which
103 the user's shell provides.
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.
112 the directory- and file-structure of \unix/ is used directly.
114 any \unix/ file-handling command can be applied to any message.
117 this may not make much sense or may not seem important.
119 as users of \MH/ become more experienced,
120 they find this capability attractive.
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.
129 Having described how \MH/ fits into the \unix/ environment,
130 we now discuss the mail handling environment which is available to the \MH/
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.
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
144 Futher, by using the \unix/ link facility,
145 different names can be given to the same command.
146 Since each \MH/ command looks
148 for a component with the name by which it was invoked,
149 it's possible to have different defaults for the same program.
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
157 when \pgm{prompter} is invoked as \pgm{rapid},
158 it automatically uses the \switch{prepend} and \switch{rapid} options.
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.
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
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.
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.
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}).
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.
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}
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.
225 The user \pgm{show\/}s the message, and decides to \pgm{repl\/}y.
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
235 no additional output is produced.
236 (\MH/ is not verbose by default.)
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.
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.
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.
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
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.
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.
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.
274 Searching is performed on either a specific header in the message
276 or anywhere within the message.
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.
290 Giving \pgm{pick} a list of messages causes it to limit its search to just
293 to find all the messages in the current folder from ``frated'' also dated
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
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.
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}.
316 Often it is desirable to act upon those messages which
317 are {\it not} members of a given sequence.
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
324 For example, given a profile entry of:
325 \example Sequence-Negation:\ not\endexample
327 are not in the \arg{select} sequence could be \pgm{scan\/}'d with:
328 \example scan\ notselect\endexample
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
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).
340 \MH/ also provides a way of automatically remembering the last
341 message list given to
343 This facility is implemented by using a profile entry called
344 \eg{Previous-Sequence:}.
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.
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.
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.
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.
375 the draft may be re-edited by entering \eg{comp\ -use}.
377 A relatively new feature of \MH/ is the ability to use a folder to store
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
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.
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
393 This might be the case if the user had started composing another message,
394 while that first draft was being posted.
396 the current-message in the draft-folder would no longer point
399 There is a solution for this problem, however.
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
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
412 or in a more restricted form under stand-alone \MH/.}
413 This facility permits the efficient distribution of interest group messages
415 to a group of hosts under a single administration,
416 and to the ARPA Internet community.
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.
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
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.
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.
452 some groups carry a lot of traffic.
453 Although subscription to a group does indicate interest on the part of a
455 it is usually not interesting to get 50 or so messages delivered
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.
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
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.
474 the moderator of the group does care if there are bogus addresses on the list,
475 but ironically does not receive notification.
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,
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
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.
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
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).
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.
519 the archives can be separately maintained on tape for access by interested
522 Special alias files may be generated which allow the \MH/ user to shorten
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
529 the user need only know the name of an interest group and not its global
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
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.
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
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
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.
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.
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
563 Although this is convenient for storage of messages,
564 it makes retrieval more difficult unless a separate index into the maildrop
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.
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
579 and store each as an individual \MH/ message.
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},
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}.
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}.
597 On smaller nodes in the ARPA Internet,
598 it is often impractical to maintain
599 a message transport system (e.g., \SendMail/).
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.
605 the workstation could be off-net for extended periods of time.
607 it may be expensive (or impossible) to keep a personal computer
608 interconnected to an IP-style network for long periods of time.
610 the node is lacking the resource known as ``connectivity''.
613 it is often desirable to be able to manage mail with \MH/ on these smaller
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
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.
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.
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
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)
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.
664 \section{User Interface Issues in \MH/} % mtr
666 it is perhaps useful to take a step backwards and examine the success
667 and problems of \MH/'s approach to user interfaces.
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}.
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.
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
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
693 The sad part is that all of these switches are useful in one form or another.
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.
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.
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.
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.
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.
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.
741 the \MH/ user is free to use {\it any} editor to edit {\it any} part of the
742 draft (headers or body).
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.
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,
756 the ability to specify a {\it template}, was made available.
757 An example of a reply template is shown in Figure~\replcomps.
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.
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
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.
776 \tagdiagram{5}{The \file{bombcomps} Reply Template}{bombcomps}
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.
789 repl\ -form\ bombcomps\ -noedit\ ;\ rmm\\
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.
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.
805 although \pgm{repl} uses a reply template to construct the draft
807 it also may use a display template to format the body of the message
808 being replied-to for enclosure in the reply.
810 the \pgm{post} program may use a display template to format the body of a
812 An example of a display template used for formatting forwarded messages
813 is shown in Figure~\mhlforward.
815 As with reply templates,
816 display templates can offer a lot of functionality.
818 the one line display template:
820 body:nocomponent,overflowtext=,overflowoffset=0,width=10000%
822 can be used to extract the body of a message,
823 while ignoring the headers.
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},
829 \example show\ -form\ mhl.body\ |\ sh\endexample
831 The biggest win with display templates,
833 is that all those annoying header lines which mailers
834 everywhere generate can be simply and easily filtered out.
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.
846 \tagdiagram{7}{The \pgm{mpick} Script}{mpick}
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.}
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
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
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.
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.
893 \subsection{Configurable \MH/} % jlr
894 The \MH/ distribution currently runs on a large number of different \unix/
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.
902 a large number of compile-time options which may vary from site to site,
903 so an automated configuration method was needed.
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.
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.
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:
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.
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).
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).
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.
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
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.
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
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.
973 \section{Concluding Remarks} % jlr and mtr
974 While \MH/ has undergone significant development since
976 Rand release, the authors have
977 tried to keep the fundamental concepts of
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
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.
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
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.
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.
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.
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.
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.
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,
1075 {\advance\leftskip by\parindent
1076 \item{1.} Performance Enhancements\hbreak
1077 Hardware gets faster all the time, but people always complain that software
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.
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.
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.
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
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.
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
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
1117 There is some controversy as to whether this is the correct behavior
1119 Some argue that once an \MH/ command has fully parsed its argument list,
1120 the context should be updated.