rev |
line source |
meillo@39
|
1 .RN 1
|
meillo@39
|
2
|
meillo@0
|
3 .H0 "Introduction
|
meillo@0
|
4 .P
|
meillo@32
|
5 This chapter introduces MH, its history, concepts and how it is used.
|
meillo@32
|
6 Then, it describes nmh's code base and community to give the reader
|
meillo@32
|
7 a better understanding of the state from which mmh started off.
|
meillo@32
|
8 Further more, this chapter lists the motivation and goals of the mmh project.
|
meillo@32
|
9 This chapter introduces MH, nmh and mmh to the reader and outlines
|
meillo@32
|
10 the mmh project itself.
|
meillo@8
|
11
|
meillo@0
|
12
|
meillo@28
|
13 .H1 "MH \(en the Mail Handler
|
meillo@0
|
14 .P
|
meillo@2
|
15 MH is an electronic mail system, originating in the RAND Corporation.
|
meillo@32
|
16 Most important for this thesis is that MH defines a mail handling concept.
|
meillo@32
|
17 In fact, MH had started as a design proposal, not as an implementation,
|
meillo@32
|
18 and in spirit it had remained this way. This is similar to Unix, which
|
meillo@32
|
19 influenced the world rather in being a set of system design concepts
|
meillo@32
|
20 than in being a specific software product.
|
meillo@27
|
21 .P
|
meillo@27
|
22 XXX Link to the Unix phil.
|
meillo@27
|
23 .P
|
meillo@27
|
24 XXX comparision to monolithic mail systems.
|
meillo@27
|
25 .P
|
meillo@27
|
26 XXX Differenciation of MUA and mail system.
|
meillo@2
|
27
|
meillo@11
|
28 .U2 "History
|
meillo@2
|
29 .P
|
meillo@2
|
30 MH is an electronic mail system, originating in the RAND Corporation.
|
meillo@32
|
31 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
|
meillo@32
|
32 had proposed the design
|
meillo@32
|
33 of a new mail handling system, called ``Mail Handler'' (MH),
|
meillo@32
|
34 to superseed RAND's old monolithic ``Mail System'' (MS).
|
meillo@27
|
35 Two years later, in 1979, Bruce Borden took the proposal and implemented a
|
meillo@32
|
36 prototype of MH.
|
meillo@32
|
37 Before the prototype had been available, the concept was
|
meillo@32
|
38 believed to be practically unusable because of being too slow.
|
meillo@32
|
39 But the prototype proved successful and replaced MS thereafter.
|
meillo@32
|
40 In replacing MS, MH became an all-in-one mail system.
|
meillo@2
|
41 .P
|
meillo@32
|
42 A decade later, the University of California at Irvine had started to use MH.
|
meillo@2
|
43 They also took over its development and pushed MH forward.
|
meillo@32
|
44 This was the time when the Internet appeared, UCB implemented
|
meillo@32
|
45 the TCP/IP stack, and Allman wrote Sendmail.
|
meillo@32
|
46 MH was extended as emailing got more features.
|
meillo@32
|
47 The development of MH was closely related to the development of email
|
meillo@32
|
48 RFCs. In the advent of MIME, MH was the first implementation of this new
|
meillo@32
|
49 email standard.
|
meillo@2
|
50 .P
|
meillo@2
|
51 In the nineties, MH had been moved into the public domain, making it
|
meillo@32
|
52 attractive to Free Software developers.
|
meillo@32
|
53 The Internet had started to become popular and in 1997,
|
meillo@32
|
54 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
|
meillo@32
|
55 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
|
meillo@32
|
56 and Craig Leres.
|
meillo@32
|
57 Colman intended to modernize MH and improve its portability and
|
meillo@32
|
58 MIME handling capabilities.
|
meillo@32
|
59 This should be done openly within the Internet community.
|
meillo@32
|
60 The development of MH stopped soon after the development of nmh had started.
|
meillo@32
|
61 Today, nmh almost completely replaced the original MH.
|
meillo@0
|
62
|
meillo@11
|
63 .U2 "Concepts
|
meillo@0
|
64 .P
|
meillo@8
|
65 MH is a toolchest, modelled after the Unix toolchest. It consists of a
|
meillo@32
|
66 set of tools, each covering a specific task of email handling. The programs
|
meillo@8
|
67 operate on a common mail storage. The specific format of the mail storage
|
meillo@32
|
68 characterizes MH in the same way like the format of the file system
|
meillo@32
|
69 characterizes Unix.
|
meillo@32
|
70 The mail storage consists of \fImail folders\fP (directories) and
|
meillo@32
|
71 \fPmessages\fP (regular files).
|
meillo@32
|
72 Each message is stored in a separate file in the format it had been
|
meillo@32
|
73 received (i.e. transfer format). The files are named with ascending numbers
|
meillo@32
|
74 in each folder.
|
meillo@32
|
75 MH tools maintain a \fIcontext\fP, which includes
|
meillo@32
|
76 the current mail folder and current message.
|
meillo@32
|
77 Processes in Unix have a similar context, containing the current working
|
meillo@32
|
78 directory, for instance. In contrast, the process context is maintained
|
meillo@32
|
79 by the Unix kernel automatically, whereas MH tools need to maintain the MH
|
meillo@32
|
80 context themselves.
|
meillo@32
|
81 The user can have one MH context or multiple ones, he can even share it
|
meillo@32
|
82 with other users.
|
meillo@32
|
83 Messages can have symbolic names. These can be automatically updated
|
meillo@32
|
84 position names like being the next or the last message,
|
meillo@32
|
85 or user-settable group names for arbitrary sets of messages.
|
meillo@32
|
86 These names are called sequences.
|
meillo@32
|
87 Sequences can be bound to the folder or to the context.
|
meillo@2
|
88 .P
|
meillo@32
|
89 New MH tools are built out of or on top of existing ones easily \(en
|
meillo@32
|
90 a property common to toolchests.
|
meillo@32
|
91 Multiple versions of the same command with different default values
|
meillo@32
|
92 are created very easily. This provides shortcuts and tayloring.
|
meillo@32
|
93 Form templates for new messages or for replies are easily exchangable.
|
meillo@32
|
94 Generally, output is adjustable with format files.
|
meillo@32
|
95 The configuration is stored in a file that is called the user's \fIprofile\fP.
|
meillo@32
|
96 MH encourages the user to taylor and automate the mail handling.
|
meillo@32
|
97 Almost everypart of the system can be adjusted to personal preference.
|
meillo@32
|
98 The system is well scriptable and extendable.
|
meillo@32
|
99 As the MH toolchest was modelled after the Unix toolchest, the
|
meillo@32
|
100 properties of the latter apply to the former as well.
|
meillo@8
|
101
|
meillo@32
|
102 .U2 "Versions
|
meillo@27
|
103 .P
|
meillo@27
|
104 Three versions of MH are available today:
|
meillo@32
|
105 .IP "Old MH"
|
meillo@32
|
106 In most cases this version had been replaced by nmh,
|
meillo@32
|
107 but some systems might still provide old MH.
|
meillo@32
|
108 The main reasons to still use old MH are historical reasons.
|
meillo@32
|
109 MH provides hardly any benefits over nmh.
|
meillo@27
|
110 The development of old MH has stopped after the 6.8.4 release in
|
meillo@27
|
111 February 1996.
|
meillo@32
|
112 .IP nmh\0
|
meillo@27
|
113 The most widespread version of MH was forked off version 6.8.3 in December
|
meillo@32
|
114 1996. It is based on the \fILBL changes\fP.
|
meillo@32
|
115 Backward-compatibility to old MH is provided by having new featues deactivated
|
meillo@32
|
116 by default. In consequence, the user needs to activate them explicitely to
|
meillo@32
|
117 be able to use them.
|
meillo@32
|
118 Throughout the previous years, the work on nmh was mostly maintenance work.
|
meillo@32
|
119 Development revived in December 2011 and stayed busy since then.
|
meillo@32
|
120 .IP mmh
|
meillo@32
|
121 This descendent of nmh is the subject of this thesis.
|
meillo@32
|
122 It had started as an experimental version, but became de facto a fork.
|
meillo@8
|
123
|
meillo@27
|
124 .U2 "Example Session
|
meillo@27
|
125 .P
|
meillo@32
|
126 Following is an example mail handling session with mmh.
|
meillo@32
|
127 It should be mostly compatible with nmh and old MH.
|
meillo@32
|
128 Details might vary but the look'n'feel is the same.
|
meillo@32
|
129 .P
|
meillo@32
|
130 XXX shell mail handling session follows ...
|
meillo@27
|
131
|
meillo@27
|
132
|
meillo@28
|
133 .H1 "nmh: Code and Community
|
meillo@2
|
134 .P
|
meillo@8
|
135 In order to understand the state, goals and dynamics of a project,
|
meillo@8
|
136 one needs to know its history. MH comes from a time before the
|
meillo@8
|
137 Internet, a time before networking became universal, a time when
|
meillo@8
|
138 emailing was small, short and simple. Then it grew, spread and
|
meillo@8
|
139 adopted to the changes. The core-concepts, however, remained the
|
meillo@8
|
140 same. During the XXX a small group of students at the University of
|
meillo@8
|
141 California, actively worked on MH. They added features and optimized,
|
meillo@8
|
142 like it is common for scientific work. This is still in pre-ANSI C
|
meillo@8
|
143 times. The source code contains many ancient parts. Code constructs
|
meillo@8
|
144 specific to BSD or hardware of that time are usual.
|
meillo@2
|
145 .P
|
meillo@8
|
146 Nmh started eight years after the ANSI C standard had been
|
meillo@8
|
147 established. A more modern coding style entered the code base. Still
|
meillo@8
|
148 a part of the developers come from ``the old days''. The developer
|
meillo@8
|
149 base became more diverse and thus the code. Programming practices
|
meillo@8
|
150 from different decades merged into the project. Different coding
|
meillo@8
|
151 styles came together. It appears as if multiple peers added code
|
meillo@8
|
152 parts, resulting in a conclomeration rather than an homogenic
|
meillo@8
|
153 of-one-cast mail system. Still, the basic concepts hold it together.
|
meillo@8
|
154 They were mostly untouched throughout the years.
|
meillo@8
|
155 .P
|
meillo@8
|
156 Although, at the surface, nmh is a toolchest, meaning a collection
|
meillo@8
|
157 of completely modularized small programs, on the source code level,
|
meillo@8
|
158 it is much more interweaved. Parts of the basic functions are
|
meillo@8
|
159 collected in a MH standard library, which is good, but often
|
meillo@8
|
160 separate functions are compiled into programs, for effiency reasons.
|
meillo@8
|
161 This lead to intricate innards.
|
meillo@8
|
162 The advent of MIME rose the complexity of email by a magnitude. This
|
meillo@8
|
163 is visible in nmh. The MIME-related parts are the most complex ones.
|
meillo@8
|
164 It's also visible that MIME support had been added on top of the
|
meillo@32
|
165 old MH later. The MH style made this easily possible, but it
|
meillo@8
|
166 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
|
meillo@8
|
167 and had not been thoroughly included into the concepts (e.g. the
|
meillo@8
|
168 user-visible access to whole messages and MIME parts are inherently
|
meillo@8
|
169 different).
|
meillo@8
|
170 .P
|
meillo@8
|
171 For compatibility's sake, it is a common understanding to have the
|
meillo@8
|
172 default settings to be compatible, requiring any new feature to be
|
meillo@8
|
173 explicitely enabled. This puts a burden on new users, because nmh
|
meillo@8
|
174 out-of-the-box keeps staying in the same ancient style, where users
|
meillo@8
|
175 usually want to have it practical for modern emailing.
|
meillo@8
|
176 But of course, this depends on if nmh is seen to be a front-end or a
|
meillo@8
|
177 back-end.
|
meillo@8
|
178
|
meillo@8
|
179
|
meillo@27
|
180 .H1 "mmh
|
meillo@28
|
181 .P
|
meillo@28
|
182 I started to work on my experimental version, which I call
|
meillo@28
|
183 \fImmh\fP (for \fImeillo's mail handler\fP), in Fall 2011.
|
meillo@28
|
184 In December, when I announced that I would work on an experimental
|
meillo@28
|
185 version, the activity in nmh suddenly rose. Suddently the community
|
meillo@28
|
186 started to move.
|
meillo@28
|
187 After long years of mostly idling, nmh became actively developed again.
|
meillo@28
|
188 What a great result!
|
meillo@28
|
189 Hence, while I was working on mmh, the community was working on nmh
|
meillo@28
|
190 too. My own work went in parallel and mostly unrelated.
|
meillo@28
|
191 .P
|
meillo@28
|
192 Because of several circumstances, my experimental version is rather
|
meillo@28
|
193 a fork today, although this may change again in the future.
|
meillo@27
|
194
|
meillo@27
|
195 .U2 "Motivation
|
meillo@27
|
196 .P
|
meillo@27
|
197 XXX
|
meillo@27
|
198
|
meillo@27
|
199 .U2 "Why it is worth it
|
meillo@27
|
200 .P
|
meillo@27
|
201 XXX
|
meillo@27
|
202
|
meillo@27
|
203 .U2 "Target Field
|
meillo@27
|
204 .P
|
meillo@27
|
205 XXX Target field and scenarios
|
meillo@27
|
206 .P
|
meillo@27
|
207 The target user in mind likes Unix and its philosophy.
|
meillo@27
|
208 He likes to use programs that are conceptionally appealing.
|
meillo@27
|
209 He's familiar with the command line and enjoys its power.
|
meillo@27
|
210 He is at least capable of shell scripting and wants to improve his
|
meillo@27
|
211 productivity by scripting the mail system.
|
meillo@27
|
212 His computer and operating system are from post-ANSI C times.
|
meillo@27
|
213 He likes to attach files, exchanges text containing non-ASCII
|
meillo@27
|
214 characters, signs or encrypts his messages.
|
meillo@27
|
215 He does not use bulletin boards anymore, nor non-mbox style mail
|
meillo@27
|
216 drops, nor does he rely on compatibility to nmh.
|
meillo@27
|
217 He already has and MTA/MSA and MRA running or is able to set them
|
meillo@27
|
218 up.
|
meillo@27
|
219 He does not want to have to read a book in order to make his MUA
|
meillo@27
|
220 usable.
|
meillo@27
|
221 .P
|
meillo@27
|
222 XXX Limitations
|
meillo@27
|
223
|
meillo@27
|
224 .U2 "The Vision
|
meillo@8
|
225 .P
|
meillo@8
|
226 The general goals of the mmh project are the following:
|
meillo@8
|
227 .BU
|
meillo@8
|
228 I believe that mmh should be perfectly suited for modern emailing,
|
meillo@8
|
229 out-of-the-box.
|
meillo@8
|
230 .BU
|
meillo@8
|
231 I care less about compatibility and more about conceptionally elegant
|
meillo@8
|
232 approaches.
|
meillo@8
|
233 .BU
|
meillo@8
|
234 I care for general, clear, and simple concepts.
|
meillo@8
|
235 .BU
|
meillo@8
|
236 I like to create an of-one-style email system. It should feel like
|
meillo@8
|
237 cast as one.
|
meillo@8
|
238 .BU
|
meillo@8
|
239 I plan to remove any optimizations that rises obscurity, unless it
|
meillo@8
|
240 appears to be neccessary to make mmh usable at all.
|
meillo@8
|
241
|
meillo@27
|
242 .U2 "Work to do
|
meillo@8
|
243 .BU
|
meillo@27
|
244 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
|
meillo@8
|
245 task. Mail shall enter mmh's mail storage via the system mail drop
|
meillo@8
|
246 and it shall leave mmh via the local \fLsendmail\fP command.
|
meillo@8
|
247 .BU
|
meillo@8
|
248 Remove any further functions that are not related to mmh's main task.
|
meillo@8
|
249 Bulletin board support is on example. Also remove support for ancient
|
meillo@8
|
250 technologies, like hardcopy terminals.
|
meillo@8
|
251 .BU
|
meillo@8
|
252 Refactor the source code to meet modern style criteria. Use
|
meillo@8
|
253 standardized library functions when possible.
|
meillo@8
|
254 .BU
|
meillo@8
|
255 Replace performance optimizations by clear and readable code.
|
meillo@8
|
256 .BU
|
meillo@8
|
257 Reduce the feature set to the commonly used one, removing
|
meillo@8
|
258 corner-cases. Set sane default values.
|
meillo@8
|
259 .BU
|
meillo@8
|
260 Add better attachment support. Add support for digital signatures and
|
meillo@8
|
261 encryption.
|
meillo@8
|
262 .BU
|
meillo@8
|
263 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
|
meillo@8
|
264 Integrate MIME support deeper and more natural into MH.
|
meillo@8
|
265 .BU
|
meillo@8
|
266 Provide a ready-to-use setup out-of-the-box.
|
meillo@27
|
267
|
meillo@27
|
268
|
meillo@27
|
269 .H1 "Goals of this Thesis
|
meillo@27
|
270
|
meillo@27
|
271 .U2 "Methods
|
meillo@27
|
272 .P
|
meillo@27
|
273 foo
|