docs/master

annotate ch01.roff @ 32:6a9abf543297

Rework in the Introduction (about MH).
author markus schnalke <meillo@marmaro.de>
date Mon, 14 May 2012 17:10:43 +0200
parents 6c63083b4c19
children 22ae3981a76b
rev   line source
meillo@0 1 .H0 "Introduction
meillo@0 2 .P
meillo@32 3 This chapter introduces MH, its history, concepts and how it is used.
meillo@32 4 Then, it describes nmh's code base and community to give the reader
meillo@32 5 a better understanding of the state from which mmh started off.
meillo@32 6 Further more, this chapter lists the motivation and goals of the mmh project.
meillo@32 7 This chapter introduces MH, nmh and mmh to the reader and outlines
meillo@32 8 the mmh project itself.
meillo@8 9
meillo@0 10
meillo@28 11 .H1 "MH \(en the Mail Handler
meillo@0 12 .P
meillo@2 13 MH is an electronic mail system, originating in the RAND Corporation.
meillo@32 14 Most important for this thesis is that MH defines a mail handling concept.
meillo@32 15 In fact, MH had started as a design proposal, not as an implementation,
meillo@32 16 and in spirit it had remained this way. This is similar to Unix, which
meillo@32 17 influenced the world rather in being a set of system design concepts
meillo@32 18 than in being a specific software product.
meillo@27 19 .P
meillo@27 20 XXX Link to the Unix phil.
meillo@27 21 .P
meillo@27 22 XXX comparision to monolithic mail systems.
meillo@27 23 .P
meillo@27 24 XXX Differenciation of MUA and mail system.
meillo@2 25
meillo@11 26 .U2 "History
meillo@2 27 .P
meillo@2 28 MH is an electronic mail system, originating in the RAND Corporation.
meillo@32 29 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
meillo@32 30 had proposed the design
meillo@32 31 of a new mail handling system, called ``Mail Handler'' (MH),
meillo@32 32 to superseed RAND's old monolithic ``Mail System'' (MS).
meillo@27 33 Two years later, in 1979, Bruce Borden took the proposal and implemented a
meillo@32 34 prototype of MH.
meillo@32 35 Before the prototype had been available, the concept was
meillo@32 36 believed to be practically unusable because of being too slow.
meillo@32 37 But the prototype proved successful and replaced MS thereafter.
meillo@32 38 In replacing MS, MH became an all-in-one mail system.
meillo@2 39 .P
meillo@32 40 A decade later, the University of California at Irvine had started to use MH.
meillo@2 41 They also took over its development and pushed MH forward.
meillo@32 42 This was the time when the Internet appeared, UCB implemented
meillo@32 43 the TCP/IP stack, and Allman wrote Sendmail.
meillo@32 44 MH was extended as emailing got more features.
meillo@32 45 The development of MH was closely related to the development of email
meillo@32 46 RFCs. In the advent of MIME, MH was the first implementation of this new
meillo@32 47 email standard.
meillo@2 48 .P
meillo@2 49 In the nineties, MH had been moved into the public domain, making it
meillo@32 50 attractive to Free Software developers.
meillo@32 51 The Internet had started to become popular and in 1997,
meillo@32 52 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
meillo@32 53 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
meillo@32 54 and Craig Leres.
meillo@32 55 Colman intended to modernize MH and improve its portability and
meillo@32 56 MIME handling capabilities.
meillo@32 57 This should be done openly within the Internet community.
meillo@32 58 The development of MH stopped soon after the development of nmh had started.
meillo@32 59 Today, nmh almost completely replaced the original MH.
meillo@0 60
meillo@11 61 .U2 "Concepts
meillo@0 62 .P
meillo@8 63 MH is a toolchest, modelled after the Unix toolchest. It consists of a
meillo@32 64 set of tools, each covering a specific task of email handling. The programs
meillo@8 65 operate on a common mail storage. The specific format of the mail storage
meillo@32 66 characterizes MH in the same way like the format of the file system
meillo@32 67 characterizes Unix.
meillo@32 68 The mail storage consists of \fImail folders\fP (directories) and
meillo@32 69 \fPmessages\fP (regular files).
meillo@32 70 Each message is stored in a separate file in the format it had been
meillo@32 71 received (i.e. transfer format). The files are named with ascending numbers
meillo@32 72 in each folder.
meillo@32 73 MH tools maintain a \fIcontext\fP, which includes
meillo@32 74 the current mail folder and current message.
meillo@32 75 Processes in Unix have a similar context, containing the current working
meillo@32 76 directory, for instance. In contrast, the process context is maintained
meillo@32 77 by the Unix kernel automatically, whereas MH tools need to maintain the MH
meillo@32 78 context themselves.
meillo@32 79 The user can have one MH context or multiple ones, he can even share it
meillo@32 80 with other users.
meillo@32 81 Messages can have symbolic names. These can be automatically updated
meillo@32 82 position names like being the next or the last message,
meillo@32 83 or user-settable group names for arbitrary sets of messages.
meillo@32 84 These names are called sequences.
meillo@32 85 Sequences can be bound to the folder or to the context.
meillo@2 86 .P
meillo@32 87 New MH tools are built out of or on top of existing ones easily \(en
meillo@32 88 a property common to toolchests.
meillo@32 89 Multiple versions of the same command with different default values
meillo@32 90 are created very easily. This provides shortcuts and tayloring.
meillo@32 91 Form templates for new messages or for replies are easily exchangable.
meillo@32 92 Generally, output is adjustable with format files.
meillo@32 93 The configuration is stored in a file that is called the user's \fIprofile\fP.
meillo@32 94 MH encourages the user to taylor and automate the mail handling.
meillo@32 95 Almost everypart of the system can be adjusted to personal preference.
meillo@32 96 The system is well scriptable and extendable.
meillo@32 97 As the MH toolchest was modelled after the Unix toolchest, the
meillo@32 98 properties of the latter apply to the former as well.
meillo@8 99
meillo@32 100 .U2 "Versions
meillo@27 101 .P
meillo@27 102 Three versions of MH are available today:
meillo@32 103 .IP "Old MH"
meillo@32 104 In most cases this version had been replaced by nmh,
meillo@32 105 but some systems might still provide old MH.
meillo@32 106 The main reasons to still use old MH are historical reasons.
meillo@32 107 MH provides hardly any benefits over nmh.
meillo@27 108 The development of old MH has stopped after the 6.8.4 release in
meillo@27 109 February 1996.
meillo@32 110 .IP nmh\0
meillo@27 111 The most widespread version of MH was forked off version 6.8.3 in December
meillo@32 112 1996. It is based on the \fILBL changes\fP.
meillo@32 113 Backward-compatibility to old MH is provided by having new featues deactivated
meillo@32 114 by default. In consequence, the user needs to activate them explicitely to
meillo@32 115 be able to use them.
meillo@32 116 Throughout the previous years, the work on nmh was mostly maintenance work.
meillo@32 117 Development revived in December 2011 and stayed busy since then.
meillo@32 118 .IP mmh
meillo@32 119 This descendent of nmh is the subject of this thesis.
meillo@32 120 It had started as an experimental version, but became de facto a fork.
meillo@8 121
meillo@27 122 .U2 "Example Session
meillo@27 123 .P
meillo@32 124 Following is an example mail handling session with mmh.
meillo@32 125 It should be mostly compatible with nmh and old MH.
meillo@32 126 Details might vary but the look'n'feel is the same.
meillo@32 127 .P
meillo@32 128 XXX shell mail handling session follows ...
meillo@27 129
meillo@27 130
meillo@28 131 .H1 "nmh: Code and Community
meillo@2 132 .P
meillo@8 133 In order to understand the state, goals and dynamics of a project,
meillo@8 134 one needs to know its history. MH comes from a time before the
meillo@8 135 Internet, a time before networking became universal, a time when
meillo@8 136 emailing was small, short and simple. Then it grew, spread and
meillo@8 137 adopted to the changes. The core-concepts, however, remained the
meillo@8 138 same. During the XXX a small group of students at the University of
meillo@8 139 California, actively worked on MH. They added features and optimized,
meillo@8 140 like it is common for scientific work. This is still in pre-ANSI C
meillo@8 141 times. The source code contains many ancient parts. Code constructs
meillo@8 142 specific to BSD or hardware of that time are usual.
meillo@2 143 .P
meillo@8 144 Nmh started eight years after the ANSI C standard had been
meillo@8 145 established. A more modern coding style entered the code base. Still
meillo@8 146 a part of the developers come from ``the old days''. The developer
meillo@8 147 base became more diverse and thus the code. Programming practices
meillo@8 148 from different decades merged into the project. Different coding
meillo@8 149 styles came together. It appears as if multiple peers added code
meillo@8 150 parts, resulting in a conclomeration rather than an homogenic
meillo@8 151 of-one-cast mail system. Still, the basic concepts hold it together.
meillo@8 152 They were mostly untouched throughout the years.
meillo@8 153 .P
meillo@8 154 Although, at the surface, nmh is a toolchest, meaning a collection
meillo@8 155 of completely modularized small programs, on the source code level,
meillo@8 156 it is much more interweaved. Parts of the basic functions are
meillo@8 157 collected in a MH standard library, which is good, but often
meillo@8 158 separate functions are compiled into programs, for effiency reasons.
meillo@8 159 This lead to intricate innards.
meillo@8 160 The advent of MIME rose the complexity of email by a magnitude. This
meillo@8 161 is visible in nmh. The MIME-related parts are the most complex ones.
meillo@8 162 It's also visible that MIME support had been added on top of the
meillo@32 163 old MH later. The MH style made this easily possible, but it
meillo@8 164 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
meillo@8 165 and had not been thoroughly included into the concepts (e.g. the
meillo@8 166 user-visible access to whole messages and MIME parts are inherently
meillo@8 167 different).
meillo@8 168 .P
meillo@8 169 For compatibility's sake, it is a common understanding to have the
meillo@8 170 default settings to be compatible, requiring any new feature to be
meillo@8 171 explicitely enabled. This puts a burden on new users, because nmh
meillo@8 172 out-of-the-box keeps staying in the same ancient style, where users
meillo@8 173 usually want to have it practical for modern emailing.
meillo@8 174 But of course, this depends on if nmh is seen to be a front-end or a
meillo@8 175 back-end.
meillo@8 176
meillo@8 177
meillo@27 178 .H1 "mmh
meillo@28 179 .P
meillo@28 180 I started to work on my experimental version, which I call
meillo@28 181 \fImmh\fP (for \fImeillo's mail handler\fP), in Fall 2011.
meillo@28 182 In December, when I announced that I would work on an experimental
meillo@28 183 version, the activity in nmh suddenly rose. Suddently the community
meillo@28 184 started to move.
meillo@28 185 After long years of mostly idling, nmh became actively developed again.
meillo@28 186 What a great result!
meillo@28 187 Hence, while I was working on mmh, the community was working on nmh
meillo@28 188 too. My own work went in parallel and mostly unrelated.
meillo@28 189 .P
meillo@28 190 Because of several circumstances, my experimental version is rather
meillo@28 191 a fork today, although this may change again in the future.
meillo@27 192
meillo@27 193 .U2 "Motivation
meillo@27 194 .P
meillo@27 195 XXX
meillo@27 196
meillo@27 197 .U2 "Why it is worth it
meillo@27 198 .P
meillo@27 199 XXX
meillo@27 200
meillo@27 201 .U2 "Target Field
meillo@27 202 .P
meillo@27 203 XXX Target field and scenarios
meillo@27 204 .P
meillo@27 205 The target user in mind likes Unix and its philosophy.
meillo@27 206 He likes to use programs that are conceptionally appealing.
meillo@27 207 He's familiar with the command line and enjoys its power.
meillo@27 208 He is at least capable of shell scripting and wants to improve his
meillo@27 209 productivity by scripting the mail system.
meillo@27 210 His computer and operating system are from post-ANSI C times.
meillo@27 211 He likes to attach files, exchanges text containing non-ASCII
meillo@27 212 characters, signs or encrypts his messages.
meillo@27 213 He does not use bulletin boards anymore, nor non-mbox style mail
meillo@27 214 drops, nor does he rely on compatibility to nmh.
meillo@27 215 He already has and MTA/MSA and MRA running or is able to set them
meillo@27 216 up.
meillo@27 217 He does not want to have to read a book in order to make his MUA
meillo@27 218 usable.
meillo@27 219 .P
meillo@27 220 XXX Limitations
meillo@27 221
meillo@27 222 .U2 "The Vision
meillo@8 223 .P
meillo@8 224 The general goals of the mmh project are the following:
meillo@8 225 .BU
meillo@8 226 I believe that mmh should be perfectly suited for modern emailing,
meillo@8 227 out-of-the-box.
meillo@8 228 .BU
meillo@8 229 I care less about compatibility and more about conceptionally elegant
meillo@8 230 approaches.
meillo@8 231 .BU
meillo@8 232 I care for general, clear, and simple concepts.
meillo@8 233 .BU
meillo@8 234 I like to create an of-one-style email system. It should feel like
meillo@8 235 cast as one.
meillo@8 236 .BU
meillo@8 237 I plan to remove any optimizations that rises obscurity, unless it
meillo@8 238 appears to be neccessary to make mmh usable at all.
meillo@8 239
meillo@27 240 .U2 "Work to do
meillo@8 241 .BU
meillo@27 242 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
meillo@8 243 task. Mail shall enter mmh's mail storage via the system mail drop
meillo@8 244 and it shall leave mmh via the local \fLsendmail\fP command.
meillo@8 245 .BU
meillo@8 246 Remove any further functions that are not related to mmh's main task.
meillo@8 247 Bulletin board support is on example. Also remove support for ancient
meillo@8 248 technologies, like hardcopy terminals.
meillo@8 249 .BU
meillo@8 250 Refactor the source code to meet modern style criteria. Use
meillo@8 251 standardized library functions when possible.
meillo@8 252 .BU
meillo@8 253 Replace performance optimizations by clear and readable code.
meillo@8 254 .BU
meillo@8 255 Reduce the feature set to the commonly used one, removing
meillo@8 256 corner-cases. Set sane default values.
meillo@8 257 .BU
meillo@8 258 Add better attachment support. Add support for digital signatures and
meillo@8 259 encryption.
meillo@8 260 .BU
meillo@8 261 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
meillo@8 262 Integrate MIME support deeper and more natural into MH.
meillo@8 263 .BU
meillo@8 264 Provide a ready-to-use setup out-of-the-box.
meillo@27 265
meillo@27 266
meillo@27 267 .H1 "Goals of this Thesis
meillo@27 268
meillo@27 269 .U2 "Methods
meillo@27 270 .P
meillo@27 271 foo