|
0
|
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}
|
