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