docs/master
view intro.roff @ 211:ff303d854771
style: Aligned Chapters in the TOC.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Thu, 12 Jul 2012 20:01:46 +0200 |
| parents | fead1fc981f0 |
| children | 9317d789cef9 |
line source
1 .RN 1
2 .H0 "Introduction
3 .Id introduction
5 .P
6 MH is a set of mail handling tools with a common concept, similar to
7 the Unix tool chest, which is a set of file handling tools with a common
8 concept. \fInmh\fP is the currently most popular implementation of an
9 MH-like mail handling system.
10 This thesis describes an experimental version of nmh, named \fImmh\fP.
11 .P
12 This chapter introduces MH, its history, concepts and how it is used.
13 It describes nmh's code base and community to give the reader
14 a better understanding of the state of mmh when it started off.
15 Furthermore, this chapter outlines the mmh project itself,
16 describing the motivation for it and its goals.
19 .H1 "MH \(en the Mail Handler
20 .Id mh
21 .P
22 MH is a conceptual email system design and its concrete implementation.
23 Notably, MH had started as a design proposal at RAND Corporation,
24 where the first implementation followed later.
25 In spirit, MH is similar to Unix, which
26 influenced the world more in being a set of system design concepts
27 than in being a specific software product.
28 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
29 .[
30 gancarz unix philosophy
31 .]
32 MH follows this philosophy.
34 .U2 "History
35 .P
36 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
37 proposed the design of a new mail handling system,
38 .[
39 shapiro gaines mh proposal
40 .]
41 to superseed RAND's old monolithic \fIMail System\fP (MS).
42 More than one year later, in late 1978, Bruce Borden returned to the
43 proposal and implemented a prototype, which he called
44 \fIMail Handler\fP (MH).
45 Before the prototype's existence, the concept was
46 believed to be practically unusable.
47 But the prototype \(en written in only three weeks \(en
48 proved successful and replaced MS within six months.\&
49 .[ [
50 rand note design of mh
51 .], p. 4]
52 .P
53 In the early eighties,
54 the University of California at Irvine (UCI) started to use MH.
55 Marshall T. Rose and John L. Romine then became the driving force.
56 They took over the development and pushed MH forward.
57 .[ [
58 rand note design of mh
59 .], p. 4]
60 RAND had put the code into the public domain by then.
61 MH was developed at UCI at the time when the Internet appeared,
62 the BSD started to include TCP/IP networking,
63 and Eric Allman wrote Sendmail.
64 MH was extended as emailing became more featured.
65 The development of MH was closely related to the development of email RFCs.
66 In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
67 MH was one of the first implementations of the new email standard.
68 MH grew to provide anything necessary for emailing.
69 .P
70 In the nineties, the Internet became popular and in December 1996,
71 Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
72 Nmh is a fork of MH 6.8.3 and bases strongly on the
73 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
74 .[
75 lbl changes
76 .]
77 Colman intended to modernize MH and improve its portability and
78 MIME handling capabilities.
79 This should be done openly within the Internet community.
80 The development of MH at UCI stopped after the 6.8.4 release in
81 February 1996, soon after the development of nmh had started.
82 Today, nmh has almost completely replaced the original MH.
83 Some systems might still provide old MH, but mainly for historical reasons.
84 .P
85 In the last years, the changes in nmh were mostly maintenance work.
86 However, the development was revived in December 2011
87 and stayed busy since then.
90 .U2 "Concepts
91 .P
92 MH consists of a set of tools, each covering a specific task of
93 email handling, such as composing a message, replying to a message,
94 refiling a message to a different folder, listing the messages in a folder.
95 The tools are invoked directly from the Unix shell.
96 .[
97 a rand note design of mh
98 .]
99 .P
100 The tools operate on a common mail storage, which consists of
101 \fImail folders\fP (directories) and \fPmessages\fP (regular files).
102 Each message is stored in a separate file.
103 .[
104 a rand note design of mh
105 .]
106 The files are named with ascending numbers in each folder.
107 The specific format of the mail storage characterizes MH in the same way
108 as the format of the file system characterizes Unix.
109 .P
110 MH tools maintain a \fIcontext\fP, which includes for instance the
111 current mail folder.
112 Processes in Unix have a similar context, containing the current working
113 directory, for instance. In contrast, the process context is maintained
114 by the Unix kernel automatically, whereas MH tools need to maintain the MH
115 context themselves.
116 The user can have one MH context or multiple ones; he can even share it
117 with others.
118 .P
119 Messages are named by their numeric filename,
120 but they can have symbolic names, as well.
121 These are either one of six system-controlled position names
122 and a shorthand for the range of all messages,
123 or user-settable group names for arbitrary sets of messages.
124 These names are called sequences.
125 Automatically updated position names exist for the
126 first, last, previous, next, current message, and for the number
127 one beyond the last message.
128 (In mmh, the names of these sequences are abbreviated to the
129 first character.)
130 User-definded sequences can be bound to the folder containing the
131 messages (\fIpublic sequences\fP) or to the user's context
132 (\fIprivate sequences\fP).
133 .P
134 The user's \fIprofile\fP is the file that contains his MH configuration.
135 Default switches for the individual tools can be specified to
136 adjust them to the user's personal preferences.
137 These switches will be automatically supplied whenever the specific
138 tool is invoked.
139 Additionally, a single command can be linked under different names
140 with different default values.
141 Form templates for new messages and replies, as well as format files
142 to adjust the output of tools are easily exchanged in the profile.
143 .P
144 Switches consist of a single dash (`\fL-\fP') followed by a word.
145 To ease typing, the word can be abbreviated, given the remaining
146 prefix remains unambiguous.
147 If no other switch starts with the letter `t', then any of
148 .Cl "-truncate" ,
149 .Cl "-trunc" ,
150 .Cl "-tr" ,
151 and
152 .Cl "-t
153 is equal.
154 As a result, switches can neither be grouped (as in
155 .Cl "ls -ltr" )
156 nor can switch arguments be appended directly to the switch (as in
157 .Cl "sendmail -q30m" ).
158 Many switches have negating counter-parts, which start with `no'.
159 For example
160 .Cl "-notruncate
161 inverts the
162 .Cl "-truncate
163 switch.
164 They exist to override the effect of default switches in the profile.
165 .P
166 The system is well scriptable and extensible.
167 Almost every part of the system can be adjusted to personal preference.
168 New MH tools are built out of or on top of existing ones quickly.
169 Furthermore, MH encourages the user to tailor, extend, and automate
170 the system.
171 As the MH tool chest was modeled after the Unix tool chest, the
172 properties of the latter apply to the former as well.
176 .U2 "Using MH
177 .P
178 Many tutorials to using MH
179 .[
180 rose sweet mh tutorial
181 .]
182 .[
183 moss jackson user's guide for mh
184 .]
185 .[
186 hegardt mh for beginners
187 .]
188 are old, but they still teach the basics.
189 Rose and Romine introduce MH deeper and more technical in two dozen pages.
190 .[
191 rose romine real work
192 .]
193 For a more recent introduction, it is strongly recommended to have
194 a look at the \fIMH Book\fP.
195 .[ [
196 peek mh book
197 .], Part II]
198 The online version of the book was updated on in May 2006.
199 .P
200 Following here is an example mail handling session.
201 Although it uses mmh, it is mostly compatible with nmh and the
202 original MH.
203 Details might vary but the look and feel is the same.
205 .so input/mh-session
208 .H1 "nmh
209 .P
210 In order to understand the condition, goals and dynamics of a project,
211 one needs to know the reasons behind them.
212 This section explains the background.
213 .P
214 MH predates the Internet;
215 it comes from times before networking was universal,
216 it comes from times when emailing was small, short and simple.
217 Then it grew, spread and adapted to the changes email went through.
218 Its core-concepts, however, remained the same.
219 During the eighties, students at UCI actively worked on MH.
220 They added new features and optimized the code for the systems
221 popular at that time.
222 All this still was in times before POSIX and ANSI C.
223 As large parts of the code stem from this time, today's nmh source code
224 still contains many ancient parts.
225 BSD-specific code and constructs tailored for hardware of that time
226 are frequent.
227 .P
228 Nmh started about a decade after the POSIX and ANSI C standards were
229 established. A more modern coding style entered the code base, but still
230 a part of the developers came from ``the old days''. The developer
231 base became more diverse, thus broadening the range of different
232 coding styles.
233 Programming practices from different decades merged in the project.
234 As several peers added code, the system became more a conglomeration
235 of single tools rather than a homogeneous of-one-cast mail system.
236 Still, the existing basic concepts held it together.
237 They were mostly untouched throughout the years.
238 .P
239 Despite the separation of the tool chest approach at the surface
240 \(en a collection of small, separate programs \(en
241 on the source code level, it is much more interwoven.
242 Several separate components were compiled into one program
243 for efficiency reasons.
244 This led to intricate innards.
245 While clearly separated on the outside,
246 the programs turned out to be fairly interwoven inside.
247 .\" XXX FIXME rewrite...
248 .\" nicht zweimal ``interwoven''
249 .\" Unfortunately, the clear separation on the outside turned out to be
250 .\" fairly interwoven inside.
251 .P
252 The advent of MIME raised the complexity of email by a magnitude.
253 This is visible in nmh. The MIME-related parts are the most complex ones.
254 It is also visible that MIME support was added on top of the old MH core.
255 MH's tool chest style made this easily possible and encourages
256 such approaches, but unfortunately, it led to duplicated functions
257 and half-hearted implementation of the concepts.
258 .P
259 To provide backward-compatibility, it is a common understanding not to
260 change the default settings.
261 In consequence, the user needs to activate modern features explicitly
262 to be able to use them.
263 This puts a burden on new users, because out-of-the-box nmh remains
264 in the same ancient style.
265 If nmh is seen to be a back-end,
266 then this compatibility surely is important.
267 However, at the same time, new users have difficulties using nmh for
268 modern emailing.
269 The small but mature community around nmh needs little change
270 as they have had their convenient setups for decades.
271 .\" XXX Explain more
274 .H1 "mmh
275 .P
276 I started to work on my experimental version in October 2011,
277 basing my work on nmh version \fInmh-1.3-dev\fP.
278 At that time no more than three commits were made to nmh
279 since the beginning of the year, the latest one being
280 .Ci a01a41d031c796b526329a4170eb23f0ac93b949
281 on 2011-04-13.
282 In December, when I announced my work in progress on the
283 nmh-workers mailing list,
284 .[
285 nmh-workers mmh announce December
286 .]
287 nmh's community became active, all of a sudden.
288 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
289 .[
290 nmh-workers vixie edginess
291 .]
292 After long years of stagnation, nmh became actively developed again.
293 Hence, while I was working on mmh, the community was working on nmh,
294 in parallel.
295 .P
296 The name \fImmh\fP may stand for \fImodern mail handler\fP,
297 because the project tries to modernize nmh.
298 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
299 emphasizing that the project is my version of nmh,
300 following my visions and preferences.
301 (My login name is \fImeillo\fP.)
302 This project model was inspired by \fIdwm\fP,
303 .[
304 dwm website
305 .]
306 which is Anselm Garbe's personal window manager \(en
307 targeted to satisfy Garbe's personal needs whenever conflicts appear.
308 Dwm had retained its lean elegance and its focused character, whereas
309 its community-driven predecessor \fIwmii\fP
310 .[
311 wmii website
312 .]
313 had grown fat over time.
314 The development of mmh should remain focused.
317 .U2 "Motivation
318 .P
319 MH is the most important of very few email systems in a tool chest style.
320 Tool chests are powerful because they can be perfectly automated and
321 extended. They allow arbitrary kinds of front-ends to be
322 implemented on top of them quickly and without internal knowledge.
323 Additionally, tool chests are easier to maintain than monolithic
324 programs.
325 As there are few tool chests for emailing and as MH-like ones are the most
326 popular among them, they should be developed further.
327 This keeps their
328 conceptional elegance and unique scripting qualities available to users.
329 Mmh creates a modern and convenient entry point to MH-like systems
330 for new and interested users.
331 .P
332 The mmh project is motivated by deficits of nmh and
333 my wish for general changes, combined
334 with the nmh community's reluctancy to change.
335 .P
336 At that time, nmh had not adjusted to modern emailing needs well enough.
337 The default setup was completely unusable for modern emailing.
338 Too much setup work was required.
339 Several modern features were already available but the community
340 did not want to have them as default.
341 Mmh is a way to change this.
342 .P
343 In my eyes, MH's concepts could be exploited even better and
344 the style of the tools could be improved. Both would simplify
345 and generalize the system, providing cleaner interfaces and more
346 software leverage at the same time.
347 Mmh is a way to demonstrate this.
348 .P
349 In providing several parts of an email system, nmh can hardly
350 compete with the large specialized projects that focus
351 on only one of the components.
352 The situation can be improved by concentrating the development power
353 on the most unique part of MH and letting the user pick his preferred
354 set of other mail components.
355 Today's pre-packaged software components encourage this model.
356 Mmh is a way to go for this approach.
357 .P
358 It is worthwhile to fork nmh for the development of mmh,
359 because the two projects focus on different goals and differ in
360 fundamental questions.
361 The nmh community's reluctance regarding change conflicts
362 with my strong desire for it.
363 .[
364 nmh-workers schnalke understanding nmh
365 .]
366 In developing a separate experimental version new approaches can
367 easily be tried out without the need to discuss changes beforehand.
368 In fact, revolutionary changes are hardly possible otherwise.
369 .P
370 The mmh project provides the basis on which the aforementioned
371 ideas can be implemented and demonstrated,
372 without the need to change the nmh project or its community.
373 Of course, the results of the mmh project shall improve nmh, in the end.
374 By no means it is my intent to work against the nmh project.
377 .U2 "Target Field
378 .P
379 Any effort needs to be targeted towards a specific goal
380 in order to be successful.
381 Therefore, a description of an imagined typical mmh user follows.
382 Mmh should satisfy his needs.
383 Actually, as mmh is my personal version of MH, this is a description
384 of myself.
385 Writing software for oneself is a reliable way to produce software
386 that matches the user's desires.
387 .P
388 The target user of mmh likes Unix and its philosophy.
389 He appreciates to use programs that are conceptionally appealing.
390 He is familiar with the command line and enjoys its power.
391 He is capable of shell scripting and wants to improve his
392 productivity by scripting the mail system.
393 He uses modern email features, such as attachments,
394 non-ASCII text, digital signatures and message encryption in a natural way.
395 He is able to set up mail system components,
396 and like to have the choice to pick the ones he prefers.
397 He has a reasonably modern operating system that complies to the
398 POSIX and ANSI C standards.
399 .P
400 The typical user invokes mmh commands directly in an interactive
401 shell session, but he uses them to automate mail handling tasks as well.
402 Likely, he runs his mail setup on a server machine,
403 to which he connects via ssh.
404 He might also have a local mmh installation on his workstation.
405 Still, he tend to use mmh directly in the shell instead
406 of using graphical front-ends.
407 He definitely wants to be flexible and thus be able to change
408 his setup to suit his needs.
409 .P
410 The typical mmh user is a programmer.
411 He likes to, occasionally, take the opportunity of free software to put
412 hands on and get involved in the software he uses.
413 In consequence, he likes small and clean code bases and cares for
414 code quality.
415 In general, he believes that:
416 .BU
417 The elegance of source code is most important.
418 .BU
419 Concepts are more important than concrete implementations.
420 .BU
421 Code optimizations for anything but readability should be avoided.
422 .BU
423 Having a lot of choice is bad.
424 .BU
425 Removed code is debugged code.
428 .U2 "Goals
429 .P
430 The general goals for the mmh project are the following:
431 .IP "Streamlining
432 Mmh should be stripped down to its core, which is the user agent (MUA).
433 The feature set should be distilled to the indispensable ones,
434 effectively removing corner cases.
435 Parts that do not add to the main task of being a conceptionally
436 appealing user agent should be removed.
437 This includes the mail submission and mail retrieval facilities.
438 Choice should be reduced to the main options.
439 All tools should be tightly shaped.
440 .IP "Modernizing
441 Mmh's feature set needs to become more modern.
442 Better support for attachments, digital signatures and message encryption
443 should be added.
444 MIME support should be integrated deeper and more naturally.
445 The modern email features need to be readily available, out-of-the-box.
446 On the other hand,
447 bulletin board support and similar obsolete facilities can be dropped out.
448 Likewise, ancient technologies should not be supported any further.
449 The available concepts need to be expanded as far as possible.
450 A small set of concepts should recur consistently.
451 .IP "Styling
452 Mmh's source code needs to be updated to modern standards.
453 Standardized library functions should replace non-standard versions
454 whenever possible.
455 Code should be separated into distinct modules when feasible.
456 Time and space optimizations should to be replaced by
457 clear and readable code.
458 A uniform programming style should prevail.
459 The whole system should appear to be of-one-style;
460 it should feel like being cast as one.