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