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