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