docs/master

annotate ch01.roff @ 30:d996f130e279

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