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