docs/master
view ch01.roff @ 53:01d06ca2eb1b
Rework based on comments by Lydi.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 20 May 2012 17:34:40 +0200 |
| parents | 49cf68506b5d |
| children | d9c18bd9ed92 |
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 from which mmh started off.
14 Further more, 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 where the first implementation followed later.
23 In spirit, MH is similar to Unix, which
24 influenced the world more in being a set of system design concepts
25 than in being a specific software product.
26 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
27 MH follows this philosophy.
29 .U2 "History
30 .P
31 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
32 had proposed the design
33 of a new mail handling system, called ``Mail Handler'' (MH),
34 to superseed RAND's old monolithic ``Mail System'' (MS).
35 Two years later, in 1979, Bruce Borden took the proposal and implemented a
36 prototype of MH.
37 Before the prototype had been available, the concept was
38 believed to be practically unusable.
39 But the prototype had proven successful and replaced MS thereafter.
40 In replacing MS, MH grew to an all-in-one mail system.
41 .P
42 In the early Eighties,
43 the University of California at Irvine (UCI) had started to use MH.
44 They also took over its development and pushed MH forward.
45 Marshall T. Rose and John L. Romine became the driving force then.
46 This was the time when the Internet appeared, when UCB implemented
47 the TCP/IP stack, and when Allman wrote Sendmail.
48 MH was extended as emailing became more featured.
49 The development of MH was closely related to the development of email
50 RFCs. In the advent of MIME, MH was the first implementation of this new
51 email standard.
52 .P
53 In the Nineties, MH had been moved into the public domain, making it
54 attractive to Free Software developers.
55 The Internet had became popular and in December 1996,
56 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
57 The project 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 almost completely replaces the original MH.
65 Some systems might still provide old MH, but mainly for historical reasons.
66 .P
67 In the last years, the work on nmh was mostly maintenance work.
68 However, the development revived in December 2011 and stayed busy since then.
70 .U2 "Concepts
71 .P
72 MH consists of a set of tools, each covering a specific task of
73 email handling, like composing a message, replying to a message,
74 refiling a message to a different folder, listing the messages in a folder.
75 All of the programs operate on a common mail storage.
76 .P
77 The mail storage consists of \fImail folders\fP (directories) and
78 \fPmessages\fP (regular files).
79 Each message is stored in a separate file in the format it had been
80 received (i.e. transfer format).
81 The files are named with ascending numbers in each folder.
82 The specific format of the mail storage characterizes MH in the same way
83 like the format of the file system characterizes Unix.
84 .P
85 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
86 Processes in Unix have a similar context, containing the current working
87 directory, for instance. In contrast, the process context is maintained
88 by the Unix kernel automatically, whereas MH tools need to maintain the MH
89 context themselves.
90 The user can have one MH context or multiple ones, he can even share it
91 with other users.
92 .P
93 Messages are named by their numeric filename, but they can have symbolic names,
94 too. These are either automatically updated
95 position names like being the next or the last message,
96 or user-settable group names for arbitrary sets of messages.
97 These names are called sequences.
98 Sequences can be bound to the containing folder or to the context.
99 .P
100 The user's \fIprofile\fP is a file that contains his MH configuration.
101 Default switches for the individual tools can be specified to
102 adjust them to the user's personal preferences.
103 Multiple versions of the same command with different
104 default values can also be created very easily.
105 Form templates for new messages or for replies are easily changeable,
106 and output is adjustable with format files.
107 Almost every part of the system can be adjusted to personal preference.
108 .P
109 The system is well scriptable and extensible.
110 New MH tools are built out of or on top of existing ones quickly.
111 Further more, MH encourages the user to tailor, extend and automate the system.
112 As the MH tool chest was modeled after the Unix tool chest, the
113 properties of the latter apply to the former as well.
115 .U2 "A Tour through MH
116 .P
117 XXX cf. peek; why UP still matters; real work.
119 .U2 "Example Session
120 .P
121 Following is an example mail handling session.
122 It uses mmh but is mostly compatible with nmh and old MH.
123 Details might vary but the look'n'feel is the same.
124 .DS
125 $ \f(CBinc\fP
126 Incorporating new mail into inbox...
128 1+ 2012-05-16 11:16 meillo@dream.home Hello
129 2 2012-05-16 11:17 meillo@dream.home book
131 $ \f(CBshow\fP
132 Date: Wed, 16 May 2012 11:16:00 +0200
133 To: meillo
134 From: <meillo@dream.home.schnalke.org>
135 Subject: Hello
137 part text/plain 13
138 mmh is great
140 $ \f(CBnext\fP
141 Date: Wed, 16 May 2012 11:17:24 +0200
142 To: meillo
143 From: <meillo@dream.home.schnalke.org>
144 Subject: book
146 part text/plain 79
147 Hello meillo,
149 have a look at the ``Daemon book''. You need to read that!
151 foo
153 $ \f(CBrmm 1\fP
155 $ \f(CBscan\fP
156 2+ 2012-05-16 11:17 meillo@dream.home book
158 $
159 .DE
162 .H1 "nmh: Code and Community
163 .P
164 In order to understand the condition, goals and dynamics of a project,
165 one needs to know the reasons.
166 This section explains the background.
167 .P
168 MH predates the Internet, it comes from times before networking was universal,
169 it comes from times when emailing was small, short and simple.
170 Then it grew, spread and adopted to the changes email went through.
171 Its core-concepts, however, remained the same.
172 During the Eighties students at UCI actively worked on MH.
173 They added new features and optimized the code for the then popular systems.
174 All this still was in times before POSIX and ANSI C.
175 As large parts of the code stem from this time, today's nmh source code
176 still contains many ancient parts.
177 BSD-specific code and constructs tailored for hardware of that time
178 are frequent.
179 .P
180 Nmh started about a decade after the POSIX and ANSI C standards had been
181 established. A more modern coding style entered the code base, but still
182 a part of the developers came from ``the old days''. The developer
183 base became more diverse and thus resulted in code of different style.
184 Programming practices from different decades merged in the project.
185 As several peers added code, the system became more a conglomeration
186 of single tools rather than a homogeneous of-one-cast mail system.
187 Still, the existing basic concepts held it together.
188 They were mostly untouched throughout the years.
189 .P
190 Despite the tool chest approach at the surface \(en a collection
191 of separate small programs \(en on the source code level
192 it is much more interweaved.
193 Several separate components were compiled into one program
194 for efficiency reasons.
195 This lead to intricate innards.
196 Unfortunately, the clear separation on the outside appeared as being
197 pretty interweaved inside.
198 .P
199 The advent of MIME rose the complexity of email by a magnitude.
200 This is visible in nmh. The MIME-related parts are the most complex ones.
201 It's also visible that MIME support had been added on top of the old MH core.
202 MH's tool chest style made this easily possible and encourages
203 such approaches, but unfortunately, it lead to duplicated functions
204 and half-hearted implementation of the concepts.
205 .P
206 To provide backward-compatibility, it is a common understanding to not
207 change the default settings.
208 In consequence, the user needs to activate modern features explicitly
209 to be able to use them.
210 This puts a burden on new users, because out-of-the-box nmh remains
211 in the same ancient style.
212 If nmh is seen to be a back-end, then this compatibility surely is important.
213 However, in the same go, new users have difficulties to use nmh for modern
214 emailing.
215 The small but matured community around nmh hardly needs much change
216 as they have their convenient setups since decades.
219 .H1 "mmh
220 .P
221 I started to work on my experimental version in October 2011,
222 at a time when there were no more than three commits to nmh
223 since the beginning of the year.
224 In December, when I announced my work in progress on the
225 nmh-workers mailing list,
226 .[
227 nmh-workers mmh announce December
228 .]
229 nmh's community became active, too.
230 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
231 .[
232 nmh-workers vixie edginess
233 .]
234 After long years of stagnation, nmh became actively developed again.
235 Hence, while I was working on mmh, the community was working on nmh,
236 in parallel.
237 .P
238 The name \fImmh\fP may stand for \fImodern mail handler\fP,
239 because the project tries to modernize nmh.
240 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
241 emphasizing that the project follows my visions and preferences.
242 (My login name is \fImeillo\fP.)
243 This project model was inspired by \fIdwm\fP,
244 which is Anselm Garbe's personal window manager \(en
245 targeted to satisfy Garbe's personal needs whenever conflicts appear.
246 Dwm had retained its lean elegance and its focused character, whereas
247 its community-driven predecessor \fIwmii\fP had grown fat over time.
248 The development of mmh should remain focused.
251 .U2 "Motivation
252 .P
253 MH is the most important of very few command line tool chest email systems.
254 Tool chests are powerful because they can be perfectly automated and
255 extended. They allow arbitrary kinds of front-ends to be
256 implemented on top of them quickly and without internal knowledge.
257 Additionally, tool chests are much better to maintain than monolithic
258 programs.
259 As there are few tool chests for emailing and as MH-like ones are the most
260 popular among them they should be developed further.
261 This keeps their
262 conceptional elegance and unique scripting qualities available to users.
263 Mmh will create a modern and convenient entry point to MH-like systems
264 for new and interested users.
265 .P
266 The mmh project is motivated by deficits of nmh and
267 my wish for general changes, combined
268 with the nmh community's reluctancy to change.
269 .P
270 nmh hadn't adjusted to modern emailing needs well enough.
271 The default setup was completely unusable for modern emailing.
272 Too much setup work was required.
273 Several modern features were already available but the community
274 didn't wanted to have them as default.
275 mmh is a way to change this.
276 .P
277 In my eyes, MH's concepts could be exploited even better and
278 the style of the tools could be improved. Both would simplify
279 and generalize the system, providing cleaner interfaces and more
280 software leverage at the same time.
281 mmh is a way to demonstrate this.
282 .P
283 In providing several parts of an email system, nmh can hardly
284 compete with the large specialized projects that focus
285 on only one of the components.
286 The situation can be improved by concentrating the development power
287 on the most unique part of MH and letting the user pick his preferred
288 set of other mail components.
289 Today's pre-packaged software components encourage this model.
290 mmh is a way to go for this approach.
291 .P
292 It's worthwhile to fork nmh for the development of mmh, because
293 the two projects focus on different goals and differ in fundamental questions.
294 The nmh community's reluctance to change conflicts
295 with my strong will to change.
296 In developing a separate experimental version new approaches can
297 easily be tried out without the need to discuss changes beforehand.
298 In fact, revolutionary changes are hardly possible otherwise.
299 .P
300 The mmh project provides the basis to implemented and demonstrated
301 the listed ideas without the need to change nmh or its community.
302 Of course, the results of the mmh project shall improve nmh, in the end.
304 .U2 "Target Field
305 .P
306 Any effort needs to be targeted towards a specific goal
307 in order to be successful.
308 Following is a description of the imagined typical mmh user.
309 mmh should satisfy his needs.
310 .\" XXX Remove the next sentence?
311 Actually, as mmh is my personal version of MH, this is a description
312 of myself.
313 .P
314 The target user of mmh likes Unix and its philosophy.
315 He likes to use programs that are conceptionally appealing.
316 He's familiar with the command line and enjoys its power.
317 He is at least capable of shell scripting and wants to improve his
318 productivity by scripting the mail system.
319 He naturally uses modern email features, like attachments,
320 non-ASCII text, and digital cryptography.
321 He is able to setup email system components besides mmh,
322 and actually likes the choice to pick the ones he prefers.
323 He has a reasonably modern system that complies to standards,
324 like POSIX and ANSI C.
325 .P
326 The typical user invokes mmh commands directly in an interactive
327 shell session, but as well, he uses them to automate mail handling tasks.
328 Likely, he runs his mail setup on a server machine, to which he connects
329 via ssh. He might also have local mmh installations on his workstations,
330 but does rather not rely on graphical front-ends. He definitely wants
331 to be flexible and thus be able to change his setup to suite his needs.
332 .P
333 The typical mmh user is a programmer himself.
334 He likes to, occasionally, take the opportunity of Free Software to put
335 hands on and get involved in the software he uses.
336 Hence, he likes small and clean code bases and he cares for code quality.
337 In general, he believes that:
338 .BU
339 Elegance \(en i.e. simplicity, clarity and generality \(en
340 is most important.
341 .BU
342 Concepts are more important than the concrete implementation.
343 .BU
344 Code optimizations for anything but readability should be avoided
345 if possible.
346 .BU
347 Having a lot of choice is bad.
348 .BU
349 Removed code is debugged code.
351 .U2 "Goals
352 .P
353 The general goals for the mmh project are the following:
354 .IP "Stream-lining
355 Mmh should be stripped down to its core, which is the MUA part of emailing.
356 The feature set should be distilled to the ones really needed,
357 effectively removing corner-cases.
358 Parts that don't add to the main task of being a conceptionally
359 appealing MUA should be removed.
360 This includes, the MTA and MRA facilities.
361 Choice should be reduced to the main options.
362 .IP "Modernizing
363 Mmh's feature set needs to become more modern.
364 Better support for attachment and digital cryptography needs to be added.
365 MIME support needs to be integrated deeper and more naturally.
366 The modern email features need to be readily available, out-of-the-box.
367 And on the other hand,
368 bulletin board support and similar obsolete facilities need to be dropped
369 out.
370 Likewise, ancient technologies, like hardcopy terminals, should not
371 be supported any further.
372 .IP "Code style
373 Mmh's source code needs to be updated to modern standards.
374 Standardized library functions should replace non-standard versions
375 whenever possible.
376 Code should be separated into distinct modules when possible.
377 Time and space optimizations should to be replaced by
378 clear and readable code.
379 A uniform programming style should prevail.
380 .IP "Homogeneity
381 The available concepts need to be expanded as far as possible.
382 A small set of concepts should prevail thoroughly throughout the system.
383 The whole system should appear to be of-one-style.
384 It should feel like being cast as one.