1.1 --- a/ch01.roff	Wed Mar 07 16:03:36 2012 +0100
     1.2 +++ b/ch01.roff	Wed Mar 07 16:04:08 2012 +0100
     1.3 @@ -2,6 +2,10 @@
     1.4  .P
     1.5  This chapter describes the background of the topics in this thesis.
     1.6  General knowledge of electronic mail is assumed.
     1.7 +It explains the situation at the start of the project.
     1.8 +It tries to describe from what state the project lifted of and where
     1.9 +it headed to. This shall give an overview.
    1.10 +
    1.11  
    1.12  .H1 "What is MH?
    1.13  .P
    1.14 @@ -17,15 +21,8 @@
    1.15  It had started as a design proposal, not as an implementation, and 
    1.16  had in spirit remained so. This is similar to Unix, which much less
    1.17  is a specific software product, as it is a style of system design.
    1.18 -MH is a toolchest of programs, modelled after the Unix toolchest,
    1.19 -and it is a specific mail storage format, like Unix has its file system
    1.20 -formats.
    1.21  
    1.22 -.H2 "Concepts of MH" no
    1.23 -.P
    1.24 -FIXME
    1.25 -
    1.26 -.H2 "History of MH" no
    1.27 +.H2 "History" no
    1.28  .P
    1.29  MH is an electronic mail system, originating in the RAND Corporation.
    1.30  In 1977, Norman Shapiro and Stockton Gaines had proposed the design
    1.31 @@ -46,66 +43,155 @@
    1.32  (nmh), a fork of MH. He intended to modernize MH, improve its MIME
    1.33  capabilities, and this should be done openly within the Internet
    1.34  community. Today, nmh almost completely replaced the original MH.
    1.35 +.P
    1.36 +Three versions of MH are currently available:
    1.37 +.BU
    1.38 +.B "Old MH" .
    1.39 +In most cases it has been replaced by nmh, but there are still systems
    1.40 +that provide old MH. As nmh is old MH-compatible, there exist few reasons
    1.41 +not to upgrade to new.
    1.42 +The development of old MH stopped almost completely.
    1.43 +.BU
    1.44 +.B Nmh .
    1.45 +The most widespread version of MH. Backward-compatible to old MH.
    1.46 +Provides new featues, which need to be activated explicitely.
    1.47 +Its development went slowly in the previous years, but had revived
    1.48 +in Fall 2011.
    1.49 +.BU
    1.50 +.B Mmh
    1.51 +A descendent of nmh. Had started as a non-compatible experimental
    1.52 +version, but became de facto a fork. Tries to expand the same
    1.53 +principal concepts in a more modern way. This version of MH is the
    1.54 +subject of this thesis.
    1.55  
    1.56 -.H1 "How the Fun Began
    1.57 +.H2 "Concepts" no
    1.58  .P
    1.59 -I have discovered nmh in XXX. I used to use mutt, like many
    1.60 -command line-attracted Unix users. Nmh had convinced me conceptually
    1.61 -at once. Unfortunately, setting it up to a convenient state became a
    1.62 -tendious task. Learning its different model of email handling had,
    1.63 -in contrast, been relatively easy. Learning to use MH if you are used
    1.64 -to monolithic mail clients is like learning vi if you are used to
    1.65 -modeless editors.
    1.66 -Once having nmh set up, using it was joy because of its conceptional
    1.67 -elegance and scripting capabilities, but on the other hand it was
    1.68 -inconvenient in handling attachments, non-ASCII character encodings,
    1.69 -and similar stuff. I found it wrong to require more and more scripts
    1.70 -and configuration to have it act the expected way. In being a
    1.71 -software developer, I wanted to improve the situation.
    1.72 +MH is a toolchest, modelled after the Unix toolchest. It consists of a
    1.73 +bunch of tools, each covering one task of email handling. These programs
    1.74 +operate on a common mail storage. The specific format of the mail storage
    1.75 +also defines MH, like the file system structure defines Unix. It
    1.76 +consists of directories (mail folders) and files (mail messages).
    1.77 +Each file contains exactly one message in the format it had been
    1.78 +received (i.e. transfer format). MH tools carry a state (context),
    1.79 +consisting of current mail folder and current message. Messages can
    1.80 +have symbolic names, like the next or last message or for some
    1.81 +arbitrary group of messages. These names are called sequences.
    1.82  .P
    1.83 -In Spring 2010, I asked on the nmh-workers mailing list for the
    1.84 -possibility to have a Google Summer of Code project on nmh. Being a
    1.85 -student, this appeared attractive to me. Eventually, it had not been
    1.86 -possible, but the nmh community started to move. In these months
    1.87 -nmh's future was discussed and I became part of a ``Does nmh need an
    1.88 -MTA'' discussion. There, my opinion differed from the opinion of
    1.89 -most others.
    1.90 +New MH tools can be build out of existing ones easily. Default values to
    1.91 +commands are stored on a command name-basis, making it trivial to have
    1.92 +different versions of the same command with different defaults. Most
    1.93 +of the configuration is stored in the user's profile. Form templates,
    1.94 +e.g. for new messages or replies, are exchangeable and output is generally
    1.95 +adjustable with format files.
    1.96  .P
    1.97 -As it hadn't been possible to work on nmh in a way that would be
    1.98 -accepted as part of my official studies, I needed to get my credit
    1.99 -points in some other way. But half a year later I was back. Starting
   1.100 -in Summer 2010, I took one semester off to travel through Latin America.
   1.101 -Within this time, I needed to do practical computer work for three
   1.102 -months. Richard Sandelman, an active nmh user, made it possible for
   1.103 -me to work on nmh during this time. Juan Granda, from Santiago del
   1.104 -Estero in Argentina, provided a computer and Internet connection.
   1.105 -Within these three month, I became familiar with nmh's code base and
   1.106 -its community. I learned how things work. Quickly it was obvious that
   1.107 -I wouldn't succeed to improve on the non-ASCII character encoding
   1.108 -problems, as this is one of the most intricate parts of the system.
   1.109 -Instead I improved code as I read through it. I found minor bugs in
   1.110 -the code and could improve the documentation. When I started with
   1.111 -larger code changes, I had to discover that the community's wish for
   1.112 -compatibility was stronger than its wish for convenient
   1.113 -out-of-the-box setups. This lead to long discussions, again. Finally,
   1.114 -I understand their point of view, but it's not mine.
   1.115 -At the end of my three-month project, I had became familiar with
   1.116 -nmh's code base and community, I had improved both a bit, and I still
   1.117 -was convinced that I wanted to go on with it.
   1.118 +MH allows the user to automate almost everything and to modify amost
   1.119 +any behavior. The system is scriptable and extendable.
   1.120 +
   1.121 +
   1.122 +.H1 "Understanding of the Code and Community
   1.123  .P
   1.124 -Another half a year later, I needed a topic for my master's thesis.
   1.125 -Now it was clear: I wanted to work on nmh. No, not exactly nmh,
   1.126 -because I had accepted that the nmh community has different goals
   1.127 -than I have. The won't be much progress if generally different opinions
   1.128 -lead to long discussions. After careful thought, I had decided to
   1.129 -start an experimental version of nmh. I wanted to go my way and see
   1.130 -where it would lead to. Time would tell if it would prove successful.
   1.131 -Nmh would hardly be hurt by my work, but could profit from my
   1.132 -experiences later.
   1.133 +In order to understand the state, goals and dynamics of a project,
   1.134 +one needs to know its history. MH comes from a time before the
   1.135 +Internet, a time before networking became universal, a time when
   1.136 +emailing was small, short and simple. Then it grew, spread and
   1.137 +adopted to the changes. The core-concepts, however, remained the
   1.138 +same. During the XXX a small group of students at the University of
   1.139 +California, actively worked on MH. They added features and optimized,
   1.140 +like it is common for scientific work. This is still in pre-ANSI C
   1.141 +times. The source code contains many ancient parts. Code constructs
   1.142 +specific to BSD or hardware of that time are usual.
   1.143  .P
   1.144 -When I started to work on mmh, my experimental version, in Fall 2011,
   1.145 -activity in nmh rose suddenly. While I was working on mmh, XXX were
   1.146 -working on nmh. After long years of idleing, nmh was actively
   1.147 -developed again. That was a good sign. My own work went in parallel
   1.148 -and unrelated. Today, my experimental version became de facto a fork.
   1.149 -The mail storage, however, is still compatible.
   1.150 +Nmh started eight years after the ANSI C standard had been
   1.151 +established. A more modern coding style entered the code base. Still
   1.152 +a part of the developers come from ``the old days''. The developer
   1.153 +base became more diverse and thus the code. Programming practices
   1.154 +from different decades merged into the project. Different coding
   1.155 +styles came together. It appears as if multiple peers added code
   1.156 +parts, resulting in a conclomeration rather than an homogenic
   1.157 +of-one-cast mail system. Still, the basic concepts hold it together.
   1.158 +They were mostly untouched throughout the years.
   1.159 +.P
   1.160 +Although, at the surface, nmh is a toolchest, meaning a collection
   1.161 +of completely modularized small programs, on the source code level,
   1.162 +it is much more interweaved. Parts of the basic functions are
   1.163 +collected in a MH standard library, which is good, but often
   1.164 +separate functions are compiled into programs, for effiency reasons.
   1.165 +This lead to intricate innards.
   1.166 +The advent of MIME rose the complexity of email by a magnitude. This
   1.167 +is visible in nmh. The MIME-related parts are the most complex ones.
   1.168 +It's also visible that MIME support had been added on top of the
   1.169 +original MH later. The MH style made this easily possible, but it
   1.170 +also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
   1.171 +and had not been thoroughly included into the concepts (e.g. the
   1.172 +user-visible access to whole messages and MIME parts are inherently
   1.173 +different).
   1.174 +.P
   1.175 +For compatibility's sake, it is a common understanding to have the
   1.176 +default settings to be compatible, requiring any new feature to be
   1.177 +explicitely enabled. This puts a burden on new users, because nmh
   1.178 +out-of-the-box keeps staying in the same ancient style, where users
   1.179 +usually want to have it practical for modern emailing.
   1.180 +But of course, this depends on if nmh is seen to be a front-end or a
   1.181 +back-end.
   1.182 +
   1.183 +
   1.184 +.H1 "My Vision
   1.185 +.P
   1.186 +The general goals of the mmh project are the following:
   1.187 +.BU
   1.188 +I believe that mmh should be perfectly suited for modern emailing,
   1.189 +out-of-the-box.
   1.190 +.BU
   1.191 +I care less about compatibility and more about conceptionally elegant
   1.192 +approaches.
   1.193 +.BU
   1.194 +I care for general, clear, and simple concepts.
   1.195 +.BU
   1.196 +I like to create an of-one-style email system. It should feel like
   1.197 +cast as one.
   1.198 +.BU
   1.199 +I plan to remove any optimizations that rises obscurity, unless it
   1.200 +appears to be neccessary to make mmh usable at all.
   1.201 +.P
   1.202 +.B "The target user in mind
   1.203 +likes Unix and its philosophy.
   1.204 +He likes to use programs that are conceptionally appealing.
   1.205 +He's familiar with the command line and enjoys its power.
   1.206 +He is at least capable of shell scripting and wants to improve his
   1.207 +productivity by scripting the mail system.
   1.208 +His computer and operating system are from post-ANSI C times.
   1.209 +He likes to attach files, exchanges text containing non-ASCII
   1.210 +characters, signs or encrypts his messages.
   1.211 +He does not use bulletin boards anymore, nor non-mbox style mail
   1.212 +drops, nor does he rely on compatibility to nmh.
   1.213 +He already has and MTA/MSA and MRA running or is able to set them
   1.214 +up.
   1.215 +He does not want to have to read a book in order to make his MUA
   1.216 +usable.
   1.217 +
   1.218 +
   1.219 +.H1 "Things to do
   1.220 +.BU
   1.221 +Remove any MTA and MRA facilities. Mmh shall concentrate on the MUA
   1.222 +task. Mail shall enter mmh's mail storage via the system mail drop
   1.223 +and it shall leave mmh via the local \fLsendmail\fP command.
   1.224 +.BU
   1.225 +Remove any further functions that are not related to mmh's main task.
   1.226 +Bulletin board support is on example. Also remove support for ancient 
   1.227 +technologies, like hardcopy terminals.
   1.228 +.BU
   1.229 +Refactor the source code to meet modern style criteria. Use
   1.230 +standardized library functions when possible.
   1.231 +.BU
   1.232 +Replace performance optimizations by clear and readable code.
   1.233 +.BU
   1.234 +Reduce the feature set to the commonly used one, removing
   1.235 +corner-cases. Set sane default values.
   1.236 +.BU
   1.237 +Add better attachment support. Add support for digital signatures and
   1.238 +encryption.
   1.239 +.BU
   1.240 +Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
   1.241 +Integrate MIME support deeper and more natural into MH.
   1.242 +.BU
   1.243 +Provide a ready-to-use setup out-of-the-box.

     2.1 --- a/ch02.roff	Wed Mar 07 16:03:36 2012 +0100
     2.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.3 @@ -1,86 +0,0 @@
     2.4 -.H0 "Previous Situation
     2.5 -.P
     2.6 -foo
     2.7 -
     2.8 -.H1 "Historic Background
     2.9 -.P
    2.10 -In order to understand the state, goals and dynamics of a project,
    2.11 -you need to know its history. MH comes from a time before the
    2.12 -Internet, a time before networking became universal, a time when
    2.13 -emailing was small, short and simple. Then it grew, spread and
    2.14 -adopted to the changes. The core-concepts, however, remained the
    2.15 -same. During the XXX a small group of students at the University of
    2.16 -California, actively worked on MH. They added features and optimized,
    2.17 -like it is common for scientific work. This is still in pre-ANSI C
    2.18 -times. The source code contains many ancient parts. Code constructs
    2.19 -specific to BSD or hardware of that time are usual.
    2.20 -.P
    2.21 -Nmh started eight years after the ANSI C standard had been
    2.22 -established. A more modern coding style entered the code base. Still
    2.23 -a part of the developers come from ``the old days''. The developer
    2.24 -base became more diverse and thus the code. Programming practices
    2.25 -from different decades merged into the project. Different coding
    2.26 -styles came together. It appears as if multiple peers added code
    2.27 -parts, resulting in a conclomeration rather than an homogenic
    2.28 -of-one-cast mail system. Still, the basic concepts hold it together.
    2.29 -They were mostly untouched throughout the years.
    2.30 -.P
    2.31 -Although, at the surface, nmh is a toolchest, meaning a collection
    2.32 -of completely modularized small programs, on the source code level,
    2.33 -it is much more interweaved. Parts of the basic functions are
    2.34 -collected in a MH standard library, which is good, but often
    2.35 -separate functions are compiled into programs, for effiency reasons.
    2.36 -This lead to intricate innards.
    2.37 -The advent of MIME rose the complexity of email by a magnitude. This
    2.38 -is visible in nmh. The MIME-related parts are the most complex ones.
    2.39 -It's also visible that MIME support had been added on top of the
    2.40 -original MH later. The MH style made this easily possible, but it
    2.41 -also lead to duplicated functions (e.g. \f(CWshow\fP, \f(CWmhshow\fP)
    2.42 -and had not been thoroughly included into the concepts (e.g. the
    2.43 -user-visible access to whole messages and MIME parts are inherently
    2.44 -different).
    2.45 -.P
    2.46 -For compatibility's sake, it is a common understanding to have the
    2.47 -default settings to be compatible, requiring any new feature to be
    2.48 -explicitely enabled. This puts a burden on new users, because nmh
    2.49 -out-of-the-box keeps staying in the same ancient style, where users
    2.50 -usually want to have it practical for modern emailing.
    2.51 -But of course, this depends on if nmh is seen to be a front-end or a
    2.52 -back-end.
    2.53 -
    2.54 -.H1 "My Vision
    2.55 -.P
    2.56 -The general goals of the mmh project are the following:
    2.57 -.BU
    2.58 -I believe that mmh should be perfectly suited for modern emailing,
    2.59 -out-of-the-box.
    2.60 -.BU
    2.61 -I care less about compatibility and more about conceptionally elegant
    2.62 -approaches.
    2.63 -.BU
    2.64 -I care for general, clear, and simple concepts.
    2.65 -.BU
    2.66 -I like to create an of-one-style email system.
    2.67 -.BU
    2.68 -I plan to remove any optimizations that rises obscurity, unless it
    2.69 -appears to be neccessary to make mmh usable at all.
    2.70 -.P
    2.71 -.B "The target user in mind
    2.72 -likes Unix and its philosophy.
    2.73 -He likes to use programs that are conceptionally appealing.
    2.74 -He's familiar with the command line and enjoys its power.
    2.75 -He is at least capable of shell scripting and wants to improve his
    2.76 -productivity by scripting the mail system.
    2.77 -His computer and operating system are from post-ANSI C times.
    2.78 -He likes to attach files, exchanges text containing non-ASCII
    2.79 -characters, signs or encrypts his messages.
    2.80 -He does not use bulletin boards anymore, nor non-mbox style mail
    2.81 -drops, nor does he rely on compatibility to nmh.
    2.82 -He already has and MTA/MSA and MRA running or is able to set them
    2.83 -up.
    2.84 -He does not want to have to read a book in order to make his MUA
    2.85 -usable.
    2.86 -
    2.87 -.H1 "Things to do
    2.88 -.P
    2.89 -

     3.1 --- a/preface.roff	Wed Mar 07 16:03:36 2012 +0100
     3.2 +++ b/preface.roff	Wed Mar 07 16:04:08 2012 +0100
     3.3 @@ -1,5 +1,69 @@
     3.4  .H0 "Preface" no
     3.5  
     3.6 +.H1 "How the Fun Began" no
     3.7 +.P
     3.8 +I have discovered nmh in XXX. I used to use mutt, like many
     3.9 +command line-attracted Unix users. Nmh had convinced me conceptually
    3.10 +at once. Unfortunately, setting it up to a convenient state became a
    3.11 +tendious task. Learning its different model of email handling had,
    3.12 +in contrast, been relatively easy. Learning to use MH if you are used
    3.13 +to monolithic mail clients is like learning vi if you are used to
    3.14 +modeless editors.
    3.15 +Once having nmh set up, using it was joy because of its conceptional
    3.16 +elegance and scripting capabilities, but on the other hand it was
    3.17 +inconvenient in handling attachments, non-ASCII character encodings,
    3.18 +and similar stuff. I found it wrong to require more and more scripts
    3.19 +and configuration to have it act the expected way. In being a
    3.20 +software developer, I wanted to improve the situation.
    3.21 +.P
    3.22 +In Spring 2010, I asked on the nmh-workers mailing list for the
    3.23 +possibility to have a Google Summer of Code project on nmh. Being a
    3.24 +student, this appeared attractive to me. Eventually, it had not been
    3.25 +possible, but the nmh community started to move. In these months
    3.26 +nmh's future was discussed and I became part of a ``Does nmh need an
    3.27 +MTA'' discussion. There, my opinion differed from the opinion of
    3.28 +most others.
    3.29 +.P
    3.30 +As it hadn't been possible to work on nmh in a way that would be
    3.31 +accepted as part of my official studies, I needed to get my credit
    3.32 +points in some other way. But half a year later I was back. Starting
    3.33 +in Summer 2010, I took one semester off to travel through Latin America.
    3.34 +Within this time, I needed to do practical computer work for three
    3.35 +months. Richard Sandelman, an active nmh user, made it possible for
    3.36 +me to work on nmh during this time. Juan Granda, from Santiago del
    3.37 +Estero in Argentina, provided a computer and Internet connection.
    3.38 +Within these three month, I became familiar with nmh's code base and
    3.39 +its community. I learned how things work. Quickly it was obvious that
    3.40 +I wouldn't succeed to improve on the non-ASCII character encoding
    3.41 +problems, as this is one of the most intricate parts of the system.
    3.42 +Instead I improved code as I read through it. I found minor bugs in
    3.43 +the code and could improve the documentation. When I started with
    3.44 +larger code changes, I had to discover that the community's wish for
    3.45 +compatibility was stronger than its wish for convenient
    3.46 +out-of-the-box setups. This lead to long discussions, again. Finally,
    3.47 +I understand their point of view, but it's not mine.
    3.48 +At the end of my three-month project, I had became familiar with
    3.49 +nmh's code base and community, I had improved both a bit, and I still
    3.50 +was convinced that I wanted to go on with it.
    3.51 +.P
    3.52 +Another half a year later, I needed a topic for my master's thesis.
    3.53 +Now it was clear: I wanted to work on nmh. No, not exactly nmh,
    3.54 +because I had accepted that the nmh community has different goals
    3.55 +than I have. The won't be much progress if generally different opinions
    3.56 +lead to long discussions. After careful thought, I had decided to
    3.57 +start an experimental version of nmh. I wanted to go my way and see
    3.58 +where it would lead to. Time would tell if it would prove successful.
    3.59 +Nmh would hardly be hurt by my work, but could profit from my
    3.60 +experiences later.
    3.61 +.P
    3.62 +When I started to work on mmh, my experimental version, in Fall 2011,
    3.63 +activity in nmh rose suddenly. While I was working on mmh, XXX were
    3.64 +working on nmh. After long years of idleing, nmh was actively
    3.65 +developed again. That was a good sign. My own work went in parallel
    3.66 +and unrelated. Today, my experimental version became de facto a fork.
    3.67 +The mail storage, however, is still compatible.
    3.68 +
    3.69 +
    3.70  .H1 "Naming Conventions" no
    3.71  .P
    3.72  There are three different versions of MH available currently: original MH,
    3.73 @@ -9,14 +73,6 @@
    3.74  (Mail Handler).
    3.75  Used for any MH-like mail systems, namely the original MH, nmh, and mmh.
    3.76  .P
    3.77 -.B Nmh
    3.78 -(New Mail Handler).
    3.79 -Meaning the currently most widespread version of MH.
    3.80 -.P
    3.81 -.B Mmh
    3.82 -(Modern Mail Handler, or Meillo's Mail Handler).
    3.83 -A descendent of nmh. The version of MH that is covered in this thesis.
    3.84 -.P
    3.85  .B "Mail client" .
    3.86  Synonym for MUA. The part of the mail software the user directly
    3.87  interacts with.
    3.88 @@ -24,6 +80,12 @@
    3.89  
    3.90  .\" End or Preface. Start of the normal text.
    3.91  .\" Switch to arabic page numbers and start on a right page.
    3.92 -.pn 0
    3.93 -.af PN 0
    3.94 -.if o .bp
    3.95 +.if e \{
    3.96 +.	pn 1
    3.97 +.	af PN 1
    3.98 +.\}
    3.99 +.if o \{
   3.100 +.	pn 0
   3.101 +.	af PN 0
   3.102 +.	bp
   3.103 +.\}