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