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