1.1 --- a/ch01.roff	Mon May 14 11:11:24 2012 +0200
     1.2 +++ b/ch01.roff	Mon May 14 17:10:43 2012 +0200
     1.3 @@ -1,26 +1,21 @@
     1.4  .H0 "Introduction
     1.5  .P
     1.6 -This chapter describes the background of the topics in this thesis.
     1.7 -General knowledge of electronic mail is assumed.
     1.8 -It explains the situation at the start of the project.
     1.9 -It tries to describe from what state the project lifted of and where
    1.10 -it headed to. This shall give an overview.
    1.11 +This chapter introduces MH, its history, concepts and how it is used.
    1.12 +Then, it describes nmh's code base and community to give the reader
    1.13 +a better understanding of the state from which mmh started off.
    1.14 +Further more, this chapter lists the motivation and goals of the mmh project.
    1.15 +This chapter introduces MH, nmh and mmh to the reader and outlines
    1.16 +the mmh project itself.
    1.17  
    1.18  
    1.19  .H1 "MH \(en the Mail Handler
    1.20  .P
    1.21  MH is an electronic mail system, originating in the RAND Corporation.
    1.22 -Historically, it had been a all-in-one mail system, with both Mail Transfer
    1.23 -Agent (MTA) and Mail User Agent (MUA).
    1.24 -Later, when email setups changed, Mail Submission Agent (MSA)
    1.25 -and Mail Retrieval Agent (MRA) facilities were added.
    1.26 -The MTA became less important, whereas the MUA became even more the
    1.27 -central part.
    1.28 -.P
    1.29 -MH defines a mail handling concept.
    1.30 -It had started as a design proposal, not as an implementation, and 
    1.31 -in spirit had remained this way. This is similar to Unix, which
    1.32 -rather is a style of system design than specific software product.
    1.33 +Most important for this thesis is that MH defines a mail handling concept.
    1.34 +In fact, MH had started as a design proposal, not as an implementation,
    1.35 +and in spirit it had remained this way. This is similar to Unix, which
    1.36 +influenced the world rather in being a set of system design concepts
    1.37 +than in being a specific software product.
    1.38  .P
    1.39  XXX Link to the Unix phil.
    1.40  .P
    1.41 @@ -31,77 +26,106 @@
    1.42  .U2 "History
    1.43  .P
    1.44  MH is an electronic mail system, originating in the RAND Corporation.
    1.45 -In 1977, Norman Shapiro and Stockton Gaines had proposed the design
    1.46 -of a new mail handling system, called ``Mail Handler'' (MH) for RAND,
    1.47 -to superseed their ``Mail System'' (MS).
    1.48 +In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
    1.49 +had proposed the design
    1.50 +of a new mail handling system, called ``Mail Handler'' (MH),
    1.51 +to superseed RAND's old monolithic ``Mail System'' (MS).
    1.52  Two years later, in 1979, Bruce Borden took the proposal and implemented a
    1.53 -prototype of MH. It proved successful and replaced MS thereafter.
    1.54 +prototype of MH.
    1.55 +Before the prototype had been available, the concept was
    1.56 +believed to be practically unusable because of being too slow.
    1.57 +But the prototype proved successful and replaced MS thereafter.
    1.58 +In replacing MS, MH became an all-in-one mail system.
    1.59  .P
    1.60 -A decade later, the University of California had started to use MH.
    1.61 +A decade later, the University of California at Irvine had started to use MH.
    1.62  They also took over its development and pushed MH forward.
    1.63 -This had been the time when the Internet appeared, Berkeley implemented
    1.64 -the TCP stack, and Sendmail was born. MH had often contained the first
    1.65 -implementation of new RFCs.
    1.66 +This was the time when the Internet appeared, UCB implemented
    1.67 +the TCP/IP stack, and Allman wrote Sendmail.
    1.68 +MH was extended as emailing got more features.
    1.69 +The development of MH was closely related to the development of email
    1.70 +RFCs. In the advent of MIME, MH was the first implementation of this new
    1.71 +email standard.
    1.72  .P
    1.73  In the nineties, MH had been moved into the public domain, making it
    1.74 -attractive to Free Software developers. The Internet had started to become
    1.75 -mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler''
    1.76 -(nmh), a fork of MH. He intended to modernize MH, improve its MIME
    1.77 -capabilities, and this should be done openly within the Internet
    1.78 -community. Today, nmh almost completely replaced the original MH.
    1.79 +attractive to Free Software developers.
    1.80 +The Internet had started to become popular and in 1997,
    1.81 +Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
    1.82 +a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
    1.83 +and Craig Leres.
    1.84 +Colman intended to modernize MH and improve its portability and
    1.85 +MIME handling capabilities.
    1.86 +This should be done openly within the Internet community.
    1.87 +The development of MH stopped soon after the development of nmh had started.
    1.88 +Today, nmh almost completely replaced the original MH.
    1.89  
    1.90  .U2 "Concepts
    1.91  .P
    1.92  MH is a toolchest, modelled after the Unix toolchest. It consists of a
    1.93 -bunch of tools, each covering one task of email handling. These programs
    1.94 +set of tools, each covering a specific task of email handling. The programs
    1.95  operate on a common mail storage. The specific format of the mail storage
    1.96 -also defines MH, like the file system structure defines Unix. It
    1.97 -consists of directories (mail folders) and files (mail messages).
    1.98 -Each file contains exactly one message in the format it had been
    1.99 -received (i.e. transfer format). MH tools carry a state (context),
   1.100 -consisting of current mail folder and current message. Messages can
   1.101 -have symbolic names, like the next or last message or for some
   1.102 -arbitrary group of messages. These names are called sequences.
   1.103 +characterizes MH in the same way like the format of the file system
   1.104 +characterizes Unix.
   1.105 +The mail storage consists of \fImail folders\fP (directories) and
   1.106 +\fPmessages\fP (regular files).
   1.107 +Each message is stored in a separate file in the format it had been
   1.108 +received (i.e. transfer format). The files are named with ascending numbers
   1.109 +in each folder.
   1.110 +MH tools maintain a \fIcontext\fP, which includes
   1.111 +the current mail folder and current message.
   1.112 +Processes in Unix have a similar context, containing the current working
   1.113 +directory, for instance. In contrast, the process context is maintained
   1.114 +by the Unix kernel automatically, whereas MH tools need to maintain the MH
   1.115 +context themselves.
   1.116 +The user can have one MH context or multiple ones, he can even share it
   1.117 +with other users.
   1.118 +Messages can have symbolic names. These can be automatically updated
   1.119 +position names like being the next or the last message,
   1.120 +or user-settable group names for arbitrary sets of messages.
   1.121 +These names are called sequences.
   1.122 +Sequences can be bound to the folder or to the context.
   1.123  .P
   1.124 -New MH tools can be build out of existing ones easily. Default values to
   1.125 -commands are stored on a command name-basis, making it trivial to have
   1.126 -different versions of the same command with different defaults. Most
   1.127 -of the configuration is stored in the user's profile. Form templates,
   1.128 -e.g. for new messages or replies, are exchangeable and output is generally
   1.129 -adjustable with format files.
   1.130 -.P
   1.131 -MH allows the user to automate almost everything and to modify amost
   1.132 -any behavior. The system is scriptable and extendable.
   1.133 +New MH tools are built out of or on top of existing ones easily \(en
   1.134 +a property common to toolchests.
   1.135 +Multiple versions of the same command with different default values
   1.136 +are created very easily. This provides shortcuts and tayloring.
   1.137 +Form templates for new messages or for replies are easily exchangable.
   1.138 +Generally, output is adjustable with format files.
   1.139 +The configuration is stored in a file that is called the user's \fIprofile\fP.
   1.140 +MH encourages the user to taylor and automate the mail handling.
   1.141 +Almost everypart of the system can be adjusted to personal preference.
   1.142 +The system is well scriptable and extendable.
   1.143 +As the MH toolchest was modelled after the Unix toolchest, the
   1.144 +properties of the latter apply to the former as well.
   1.145  
   1.146 -.U2 "Available Versions
   1.147 +.U2 "Versions
   1.148  .P
   1.149  Three versions of MH are available today:
   1.150 -.BU
   1.151 -.I "Original MH" .
   1.152 -In most cases it has been replaced by nmh, but some systems still
   1.153 -provide old MH. As nmh is old MH-compatible, there exist few reasons
   1.154 -not to upgrade to new.
   1.155 +.IP "Old MH"
   1.156 +In most cases this version had been replaced by nmh,
   1.157 +but some systems might still provide old MH.
   1.158 +The main reasons to still use old MH are historical reasons.
   1.159 +MH provides hardly any benefits over nmh.
   1.160  The development of old MH has stopped after the 6.8.4 release in
   1.161  February 1996.
   1.162 -.BU
   1.163 -.I nmh .
   1.164 +.IP nmh\0
   1.165  The most widespread version of MH was forked off version 6.8.3 in December
   1.166 -1996. It incorporated the \fILBL changes\fP.
   1.167 -It provides backward-compatible to old MH by having new featues deactivated
   1.168 -by default. To use them, the user needs to activate them explicitely.
   1.169 -Its development went slowly in the previous years, but had revived
   1.170 -in December 2011.
   1.171 -.BU
   1.172 -.I mmh .
   1.173 -This version is the subject of this thesis.
   1.174 -It is a descendent of nmh. It had started as a non-compatible experimental
   1.175 -version, but became de facto a fork. It tries to expand the same
   1.176 -principle concepts in a more modern way.
   1.177 +1996. It is based on the \fILBL changes\fP.
   1.178 +Backward-compatibility to old MH is provided by having new featues deactivated
   1.179 +by default. In consequence, the user needs to activate them explicitely to
   1.180 +be able to use them.
   1.181 +Throughout the previous years, the work on nmh was mostly maintenance work.
   1.182 +Development revived in December 2011 and stayed busy since then.
   1.183 +.IP mmh
   1.184 +This descendent of nmh is the subject of this thesis.
   1.185 +It had started as an experimental version, but became de facto a fork.
   1.186  
   1.187  .U2 "Example Session
   1.188  .P
   1.189 -Example mail handling session with mmh, but mostly compatible with nmh
   1.190 -and old MH. The look'n'feel is common among them.
   1.191 +Following is an example mail handling session with mmh.
   1.192 +It should be mostly compatible with nmh and old MH.
   1.193 +Details might vary but the look'n'feel is the same.
   1.194 +.P
   1.195 +XXX shell mail handling session follows ...
   1.196  
   1.197  
   1.198  .H1 "nmh: Code and Community
   1.199 @@ -136,7 +160,7 @@
   1.200  The advent of MIME rose the complexity of email by a magnitude. This
   1.201  is visible in nmh. The MIME-related parts are the most complex ones.
   1.202  It's also visible that MIME support had been added on top of the
   1.203 -original MH later. The MH style made this easily possible, but it
   1.204 +old MH later. The MH style made this easily possible, but it
   1.205  also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
   1.206  and had not been thoroughly included into the concepts (e.g. the
   1.207  user-visible access to whole messages and MIME parts are inherently