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