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