docs/master
view ch01.roff @ 45:7a33b5adb672
Rework in the Intro.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Thu, 17 May 2012 16:17:09 +0200 |
| parents | c21ff903c71c |
| children | eae5e50381ce |
line source
1 .RN 1
3 .H0 "Introduction
4 .P
5 This chapter introduces MH, its history, concepts and how it is used.
6 Then, it describes nmh's code base and community to give the reader
7 a better understanding of the state from which mmh started off.
8 Further more, this chapter lists the motivation and goals of the mmh project.
9 This chapter introduces MH, nmh and mmh to the reader and outlines
10 the mmh project itself.
13 .H1 "MH \(en the Mail Handler
14 .P
15 MH is an electronic mail system, originating in the RAND Corporation.
16 Most important for this thesis is that MH defines a mail handling concept.
17 In fact, MH had started as a design proposal, not as an implementation,
18 and in spirit it had remained this way. This is similar to Unix, which
19 influenced the world more in being a set of system design concepts
20 than in being a specific software product.
21 These ideas behind Unix are summarized in the \fIUnix philosophy\fP.
22 MH follows this philosophy.
24 .U2 "History
25 .P
26 MH is an electronic mail system, originating in the RAND Corporation.
27 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
28 had proposed the design
29 of a new mail handling system, called ``Mail Handler'' (MH),
30 to superseed RAND's old monolithic ``Mail System'' (MS).
31 Two years later, in 1979, Bruce Borden took the proposal and implemented a
32 prototype of MH.
33 Before the prototype had been available, the concept was
34 believed to be practically unusable because of being too slow.
35 But the prototype proved successful and replaced MS thereafter.
36 In replacing MS, MH became an all-in-one mail system.
37 .P
38 A decade later, the University of California at Irvine had started to use MH.
39 They also took over its development and pushed MH forward.
40 This was the time when the Internet appeared, UCB implemented
41 the TCP/IP stack, and Allman wrote Sendmail.
42 MH was extended as emailing got more features.
43 The development of MH was closely related to the development of email
44 RFCs. In the advent of MIME, MH was the first implementation of this new
45 email standard.
46 .P
47 In the nineties, MH had been moved into the public domain, making it
48 attractive to Free Software developers.
49 The Internet had started to become popular and in 1997,
50 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
51 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
52 and Craig Leres.
53 Colman intended to modernize MH and improve its portability and
54 MIME handling capabilities.
55 This should be done openly within the Internet community.
56 The development of MH stopped soon after the development of nmh had started.
57 Today, nmh almost completely replaced the original MH.
59 .U2 "Concepts
60 .P
61 MH is a toolchest, modelled after the Unix toolchest. It consists of a
62 set of tools, each covering a specific task of email handling.
63 The programs
64 operate on a common mail storage. The specific format of the mail storage
65 characterizes MH in the same way like the format of the file system
66 characterizes Unix.
67 .P
68 The mail storage consists of \fImail folders\fP (directories) and
69 \fPmessages\fP (regular files).
70 Each message is stored in a separate file in the format it had been
71 received (i.e. transfer format). The files are named with ascending numbers
72 in each folder.
73 .P
74 MH tools maintain a \fIcontext\fP, which includes
75 the current mail folder and current message.
76 Processes in Unix have a similar context, containing the current working
77 directory, for instance. In contrast, the process context is maintained
78 by the Unix kernel automatically, whereas MH tools need to maintain the MH
79 context themselves.
80 The user can have one MH context or multiple ones, he can even share it
81 with other users.
82 .P
83 Messages can have symbolic names. These can be automatically updated
84 position names like being the next or the last message,
85 or user-settable group names for arbitrary sets of messages.
86 These names are called sequences.
87 Sequences can be bound to the folder or to the context.
88 .P
89 New MH tools are built out of or on top of existing ones easily \(en
90 a property common to toolchests.
91 Multiple versions of the same command with different default values
92 are created very easily. This provides shortcuts and tayloring.
93 Form templates for new messages or for replies are easily exchangable.
94 Generally, output is adjustable with format files.
95 .P
96 The configuration is stored in a file that is called the user's \fIprofile\fP.
97 MH encourages the user to taylor and automate the mail handling.
98 Almost every part of the system can be adjusted to personal preference.
99 The system is well scriptable and extendable.
100 As the MH toolchest was modelled after the Unix toolchest, the
101 properties of the latter apply to the former as well.
103 .U2 "Versions
104 .P
105 Three versions of MH are available today:
106 .IP "Old MH"
107 .br
108 In most cases this version had been replaced by nmh,
109 but some systems might still provide old MH.
110 The main reasons to still use old MH are historical reasons.
111 MH provides hardly any benefits over nmh.
112 The development of old MH has stopped after the 6.8.4 release in
113 February 1996.
114 .IP nmh
115 .br
116 The most widespread version of MH was forked off version 6.8.3 in December
117 1996. It is based on the \fILBL changes\fP.
118 Backward-compatibility to old MH is provided by having new featues deactivated
119 by default. In consequence, the user needs to activate them explicitely to
120 be able to use them.
121 Throughout the previous years, the work on nmh was mostly maintenance work.
122 Development revived in December 2011 and stayed busy since then.
123 .IP mmh
124 .br
125 This descendent of nmh is the subject of this thesis.
126 It had started as an experimental version, but became de facto a fork.
128 .U2 "Example Session
129 .P
130 Following is an example mail handling session with mmh.
131 It should be mostly compatible with nmh and old MH.
132 Details might vary but the look'n'feel is the same.
133 .DS
134 $ \f(CBinc\fP
135 Incorporating new mail into inbox...
137 1+ 2012-05-16 11:16 meillo@dream.home Hello
138 2 2012-05-16 11:17 meillo@dream.home book
140 $ \f(CBshow\fP
141 Date: Wed, 16 May 2012 11:16:00 +0200
142 To: meillo
143 From: <meillo@dream.home.schnalke.org>
144 Subject: Hello
146 part text/plain 13
147 mmh is great
149 $ \f(CBnext\fP
150 Date: Wed, 16 May 2012 11:17:24 +0200
151 To: meillo
152 From: <meillo@dream.home.schnalke.org>
153 Subject: book
155 part text/plain 79
156 Hello meillo,
158 have a look at the ``Daemon book''. You need to read that!
160 foo
162 $ \f(CBrmm 1\fP
164 $ \f(CBscan\fP
165 2+ 2012-05-16 11:17 meillo@dream.home book
167 $
168 .DE
171 .H1 "nmh: Code and Community
172 .P
173 In order to understand the state, goals and dynamics of a project,
174 one needs to know its history. MH predates the Internet,
175 it comes from times before networking was universal,
176 times when emailing was small, short and simple.
177 Then it grew, spread and adopted to the changes email went through.
178 The core-concepts, however, remained the same.
179 During the 80s a small group of students at the University of
180 California, actively worked on MH. They added features and optimized,
181 like it is common for scientific work. This is still in pre-ANSI C
182 times. The source code contains many ancient parts. Code constructs
183 specific to BSD or hardware of that time are usual.
184 .P
185 Nmh started eight years after the ANSI C standard had been
186 established. A more modern coding style entered the code base. Still
187 a part of the developers come from ``the old days''. The developer
188 base became more diverse and thus the code had different style.
189 Programming practices
190 from different decades merged into the project. Different coding
191 styles came together. It appears as if multiple peers added code
192 parts, resulting in a conclomeration rather than a homogenic
193 of-one-cast mail system. Still, the basic concepts hold it together.
194 They were mostly untouched throughout the years.
195 .P
196 Although, at the surface, nmh is a toolchest, meaning a collection
197 of completely modularized small programs, on the source code level,
198 it is much more interweaved. Parts of the basic functions are
199 collected in a MH standard library, which is good, but often
200 separate functions are compiled into programs, for effiency reasons.
201 This lead to intricate innards.
202 The advent of MIME rose the complexity of email by a magnitude. This
203 is visible in nmh. The MIME-related parts are the most complex ones.
204 It's also visible that MIME support had been added on top of the
205 old MH later. The MH style made this easily possible, but it
206 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
207 and had not been thoroughly included into the concepts (e.g. the
208 user-visible access to whole messages and MIME parts are inherently
209 different).
210 .P
211 For compatibility's sake, it is a common understanding to have the
212 default settings to be compatible, requiring any new feature to be
213 explicitely enabled. This puts a burden on new users, because nmh
214 out-of-the-box keeps staying in the same ancient style, where users
215 usually want to have it practical for modern emailing.
216 But of course, this depends on if nmh is seen to be a front-end or a
217 back-end.
220 .H1 "mmh
221 .P
222 I started to work on my experimental version in Fall 2011.
223 In December, when I announced my work on the nmh-workers mailing list,
224 .[
225 nmh-workers mmh announce december
226 .]
227 the activity in nmh rose heavily.
228 Suddently the community started to move.
229 This movement was pushed much by Paul Vixie's ``edginess'' message.
230 .[
231 nmh-workers vixie edginess
232 .]
233 After long years of much stagnation, nmh became actively developed again.
234 Hence, while I was working on mmh, the community was working on nmh,
235 in parallel.
236 .P
237 The name \fImmh\fP stands for \fImeillo's mail handler\fP,
238 because mmh is my own version of MH.
239 (My login name is \fImeillo\fP.)
240 The project follows my personal considerations and preferences.
241 By calling it a personal project, I don't need to justify my decisions,
242 though, still I do.
243 This enabled me to follow my vision staightly and thus produce
244 a result of greater pureness.
245 This project model was inspired by the window manager \fIdwm\fP,
246 which is Anselm Garbe's personal window manager \(en
247 targeted to satisfy Garbe's personal needs whenever conflicts appear.
248 dwm had remained much more focused on its original goals,
249 whereas its community-driven predecessor \fIwmii\fP had
250 grown large and lost it's leanness.
251 This should not happen to mmh.
252 .P
253 mmh can also stand for \fImodern mail handler\fP, and this is
254 the variant chosen as titel for this document. One main focus of the
255 project was to modernize nmh. Another main goal is resembled in the
256 name \fIminimized mail handler\fP: Drop any parts that don't add
257 to the main task of mmh, being a MUA.
258 .P
259 It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true.
260 Although mmh bases on nmh, it is likely seen as a step backward.
261 I agree.
262 However, this step backward actually is a step forward,
263 although in another direction.
266 .H1 "This Thesis
268 .U2 "Motivation
269 .P
270 MH is the most important of very few command line toolchest email systems.
271 (There's also \fIim\fP by Tatsuya Kinoshita,
272 which operates on an MH mail storage.)
273 Toolchests are powerful because they can be perfectly automated and
274 extended. Toolchests are good back-ends for various sorts of front-ends.
275 They allow multiple front-ends for different special needs
276 to be implemented quickly and withough internal knowledge on emailing.
277 Further more, toolchests are much better to maintain than large monolithic
278 programs.
279 As there are few toolchests for emailing and MH-like ones are the most
280 popular amoung them, they should be developed further to keep their
281 conceptional elegance and unique scripting qualities available to users.
282 mmh will create a modern and convenient entry point for new, interested
283 users to MH-like systems.
284 .P
285 The mmh project is motivated by deficites of nmh and
286 my wish for general changes, combined
287 with the nmh community's reluctancy to change.
288 .P
289 nmh hadn't adjusted to modern emailing needs well enough.
290 The default setup was completely unusable for modern emailing.
291 Too much setup work was required.
292 Several modern features were already available but the community
293 didn't wanted to have them as default.
294 mmh is a way to change this.
295 .P
296 In my eyes, MH's concepts could be exploited even better and
297 the style of the tools could be improved. Both would simplify
298 and generalize the system, providing cleaner interfaces and more
299 software leverage, at the same time.
300 mmh is a way to demonstrate this.
301 .P
302 In providing several parts of an email system, nmh can hardly
303 compete with the large specialized projects that focus
304 on only one of the components.
305 The situation can be improved by concentrating the development power
306 on the most unique part of MH and letting the user pick his prefered
307 set of other mail components.
308 Today's pre-packaged software components encourage this model.
309 mmh is a way to go for this approach.
310 .P
311 It's worthwhile to fork nmh for the development of mmh, because
312 the two projects focus on different goals and differ in fundamental questions.
313 The nmh community's reluctance to change conflicts
314 with my strong will to change.
315 In developing a separate experimental version new approaches can
316 easily be tried out without the need to discuss changes beforehand.
317 In fact, revolutionary changes are hardly possible otherwise.
318 These reasons support the decision to start mmh as a fork of nmh.
319 .P
320 The mmh project provides the basis to implemented and demonstrated
321 the listed ideas without the need to change nmh or its community.
322 Of course, the results of the mmh project shall improve nmh, in the end.
324 .U2 "Target Field
325 .P
326 Any effort needs to be targeted towards a specific goal
327 in order to be successful.
328 Following is a description of the imagined typical mmh user.
329 mmh should satisfy his needs.
330 .P
331 The target user of mmh likes Unix and its philosophy.
332 He likes to use programs that are conceptionally appealing.
333 He's familiar with the command line and enjoys its power.
334 He is at least capable of shell scripting and wants to improve his
335 productivity by scripting the mail system.
336 He naturally uses modern email features, like attachments,
337 non-ASCII text, and digital cryptrography.
338 He is able to setup email system components besides mmh,
339 and actually likes the choice to pick the ones he preferes.
340 He has a reasonably modern system that complies to standards,
341 like POSIX and ANSI C.
342 .P
343 XXX common scenarios?
344 .P
345 General assumptions of the project are:
346 .BU
347 Elegance \(en being simplicity, clarity and generality \(en is most important.
348 .BU
349 Concepts are more important than concrete implementations.
350 .BU
351 Time and space optimizations are only useful if absolutely needed to make
352 the software usable.
353 .BU
354 Having a lot of choice is bad.
356 .U2 "Work to do
357 .P
358 The general goals for the mmh project are the following:
359 .BU
360 mmh should be perfectly suited for modern emailing, out-of-the-box.
361 This is a necessity to spread among new users.
362 .BU
363 The system shall be of-one-style. It should feel like cast as one.
364 .P
365 To do list:
366 .BU
367 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
368 task. Mail shall enter mmh's mail storage via the system mail drop
369 and it shall leave mmh via the local \fLsendmail\fP command.
370 .BU
371 Remove any further functions that are not related to mmh's main task.
372 Bulletin board support is on example. Also remove support for ancient
373 technologies, like hardcopy terminals.
374 .BU
375 Refactor the source code to meet modern style criteria. Use
376 standardized library functions when possible.
377 .BU
378 Replace performance optimizations by clear and readable code.
379 .BU
380 Reduce the feature set to the commonly used one, removing
381 corner-cases. Set sane default values.
382 .BU
383 Add better attachment support. Add support for digital signatures and
384 encryption.
385 .BU
386 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
387 Integrate MIME support deeper and more natural into MH.
388 .BU
389 Provide a ready-to-use setup out-of-the-box.
391 .U2 "Methods
392 .P
393 foo