1.1 --- a/ch03.roff	Tue Jun 05 11:15:18 2012 +0200
     1.2 +++ b/ch03.roff	Tue Jun 05 19:00:15 2012 +0200
     1.3 @@ -12,21 +12,22 @@
     1.4  .P
     1.5  MH had been considered an all-in-one system for mail handling.
     1.6  The community around nmh has a similar understanding.
     1.7 -In fundamental difference, I believe that mmh should be a MUA but
     1.8 -nothing more. I believe that all-in-one mail systems are not the way
     1.9 -to go. There are excellent specialized MTAs, like Postfix;
    1.10 +In fundamental difference, should be a MUA only.
    1.11 +I believe that all-in-one mail systems are obsolete.
    1.12 +There are excellent specialized MTAs, like Postfix;
    1.13  there are specialized MDAs, like Procmail; there are specialized
    1.14  MRAs, like Fetchmail. I believe it's best to use them instead of
    1.15 -providing the same function ourselves. Doing something well requires to
    1.16 -focus on this particular aspect or a small set of aspects. The more
    1.17 +providing the same function ourselves. Doing something well, requires to
    1.18 +focus on a small set of aspects. The more
    1.19  it is possible to focus, the better the result in this particular
    1.20 -area will be. The limiting resource in Free Software community development
    1.21 -usually is human power. If the low development power is even parted
    1.22 -into multiple development areas, it will hardly be possible to 
    1.23 +area will be. Usually, the limiting resource in Free Software
    1.24 +community development is man power.
    1.25 +If the development power is even spread over a large
    1.26 +development area, it becomes more difficult to
    1.27  compete with the specialists in the various fields. This is even
    1.28  increased, given the small community \(en developers and users \(en
    1.29  that MH-based mail systems have. In consequence, I believe that the
    1.30 -available resources should be concentrated at the point where MH is
    1.31 +available resources should be focused to the point where MH is
    1.32  most unique. This is clearly the MUA part.
    1.33  .P
    1.34  The goal for mmh was to remove peripheral parts and stream-line
    1.35 @@ -38,100 +39,121 @@
    1.36  In contrast to nmh, which also provides mail submission and mail retrieval
    1.37  facilities, mmh is a MUA only.
    1.38  This general difference in the view on the character of nmh
    1.39 -strongly supported the development of mmh.
    1.40 +initiated the development of mmh.
    1.41  Removing the mail transfer facilities had been the first work task
    1.42 -for the mmh project.
    1.43 +in the mmh project.
    1.44  .P
    1.45  The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
    1.46 -The facility establishes TCP/IP connections and speaks SMTP to submit
    1.47 +The facility established network connections and spoke SMTP to submit
    1.48  messages for relay to the outside world.
    1.49 -This part is implemented in the
    1.50 +This part was implemented by the
    1.51  .Pn post
    1.52  command.
    1.53 -Demanded by the changes in
    1.54 -emailing, this part of nmh required changes in the last years.
    1.55 -Encrypted connections needed to be supported, hence SASL was introduced
    1.56 +The changes in emailing
    1.57 +demanded changes in this part of nmh in the last years.
    1.58 +Encryption and authetication for network connections
    1.59 +needed to be supported, hence TLS and SASL were introduced
    1.60  into nmh. This added complexity to the nmh without improving it in
    1.61  its core functions. Also, keeping up with recent developments in
    1.62 -this field needs requires development power and specialists.
    1.63 -Mmh cuts this whole facility off and depends on an external MTA instead.
    1.64 +this field requires development power and specialists.
    1.65 +For mmh this whole facility was cut off.
    1.66 +.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
    1.67 +.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
    1.68 +.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
    1.69 +Instead, mmh depends on an external MTA.
    1.70  The only outgoing interface available to mmh is the
    1.71  .Pn sendmail
    1.72  command.
    1.73  Almost any MTA provides a
    1.74  .Pn sendmail
    1.75  command.
    1.76 -It not, any program can be substituted if it reads the
    1.77 +If not, any program can be substituted if it reads the
    1.78  message from the standard input, extracts the recipient addresses
    1.79  from the message header and does not conflict
    1.80 -with sendmail-specific command line arguments.
    1.81 +with sendmail-specific command line options.
    1.82  .P
    1.83  To retrieve mail, the
    1.84  .Pn inc
    1.85 -command in nmh has the ability to establish TCP/IP connections
    1.86 -and speaks POP3 to retrieve mail from remote servers.
    1.87 -As with mail submission, here encrypted connections are required
    1.88 -today, thus SASL support was added.
    1.89 -As POP3 is superseded by IMAP more and more, support for message
    1.90 -retrieval through IMAP will become necessary to be added soon.
    1.91 -Mmh has no support for retrieving mail from remote locations.
    1.92 -It depends on an external tool to cover this task.
    1.93 -There are two ways for messages to enter mmh's mail storage:
    1.94 -Incorporate them with
    1.95 +command established network connections
    1.96 +and spoke POP3 to retrieve mail from remote servers.
    1.97 +As with mail submission, the network connections required encryption and
    1.98 +authentication, thus TLS and SASL was added.
    1.99 +As POP3 becomes more and more superseded by IMAP, support for message
   1.100 +retrieval through IMAP will become necessary to be added soon, too.
   1.101 +Mmh has dropped the support for retrieving mail from remote locations.
   1.102 +.Ci ab7b48411962d26439f92f35ed084d3d6275459c
   1.103 +Instead, it depends on an external tool to cover this task.
   1.104 +There exist two paths for messages to enter mmh's mail storage:
   1.105 +They can be incorporate with
   1.106  .Pn inc
   1.107 -from the system maildrop, or with
   1.108 +from the system maildrop, or
   1.109  .Pn rcvstore
   1.110 -from the standard input.
   1.111 -In consequence, mmh has not any longer networking code
   1.112 -and thus does no more need to do transfer encryption and authentication.
   1.113 -Two large functional units are removed.
   1.114 +reads them from the standard input.
   1.115  .P
   1.116  With the removal of the MSA and MRA, mmh converted from an all-in-one
   1.117  mail system to being only a MUA.
   1.118 -Following the Unix philosophy, it focuses on one job and to do that well.
   1.119 +Following the Unix philosophy, it focuses on one job and
   1.120 +tries to do that one well.
   1.121 +Not only the programs follow that tenet but also the project itself does so.
   1.122  Now, of course, mmh depends on third-party software.
   1.123  An external MTA/MSA is required to transfer mail to the outside world;
   1.124  an external MRA is required to retrieve mail from remote machines.
   1.125  There exist excellent implementations of such software,
   1.126 -which do this specific task likely much better than the internal
   1.127 -versions of nmh do it. Also, this provides the choice for the best
   1.128 -suiting one of the available implementation.
   1.129 +which do this specific task likely better than the internal
   1.130 +versions had done it. Also, the best suiting programs can be freely chosen.
   1.131  .P
   1.132  As it had already been possible to use an external MSA or MRA,
   1.133  why not keep the internal version for convenience?
   1.134 -If this would question the sense in having a fall-back pager in all
   1.135 -the command line tools, in case
   1.136 +The question whether there is sense in having a fall-back pager in all
   1.137 +the command line tools, for the cases when
   1.138  .Pn more
   1.139  or
   1.140  .Pn less
   1.141 -wouldn't be available, the answer is intuitively seen.
   1.142 -Now, an MSA or MRA is clearly more complex than a text pager, but
   1.143 -still the concept holds: If programs become complex, split them;
   1.144 -if projects become complex, split them.
   1.145 -Complexity is demanded by the problem to solve. Decades ago,
   1.146 -emailing had been small and simple.
   1.147 -(Remember,
   1.148 +aren't available, appears to be ridiculous.
   1.149 +Now, an MSA or MRA is clearly more complex than a text pager,
   1.150 +and not necessarily available but still the concept holds:
   1.151 +design the system orthogonally.
   1.152 +If it is conceptionally more elegant to have the MTA to be a separate tool
   1.153 +\(en as the RFCs propose this split, this is likely the case \(en
   1.154 +then separate.
   1.155 +.P
   1.156 +Further more, if programs become complex, they should be split;
   1.157 +and if projects become complex, they should be split, too.
   1.158 +Essential complexity is defined by the problem.
   1.159 +Decades ago, emailing had been small and simple.
   1.160 +(\c
   1.161  .Pn /bin/mail
   1.162 -had once covered anything there was to email and still had been small.)
   1.163 -As the complexity in emailing increased, MH remainded mostly unchanged.
   1.164 -Nontheless, in nmh the POP server, which the original MH had included,
   1.165 -was removed. Now is the time to take one step further and remove
   1.166 -the MSA and MRA.
   1.167 +had once covered anything there was to email and still had been small
   1.168 +and simple.)
   1.169 +Then the essential complexity of email increased.
   1.170 +Email tools needed to react.
   1.171 +In nmh, for instance, the POP server, which the original MH had included,
   1.172 +was removed.
   1.173 +Now is the time to go one step further and remove the MSA and MRA.
   1.174  Not only does it decrease the code amount of the project,
   1.175  but more important, it removes the whole field of message transfer
   1.176 -with all its implications from the project.
   1.177 +with all its implications for the project.
   1.178 +It removes the need to adjust to any changes concerning network transfer.
   1.179 +This independence is received by depending on an external program
   1.180 +that covers the field.
   1.181 +Today, this is a reasonable exchange.
   1.182  .P
   1.183 -If a project needs some kind of function, there's always the choice
   1.184 -between implementing the the function in the project directly or
   1.185 -depending on a library that provides the function or depending on
   1.186 +To add some kind of function, there's always the choice
   1.187 +among implementing the function in the project directly,
   1.188 +depending on a library that provides the function, or depending on
   1.189  a program that provides the function.
   1.190  Whereas adding the function directly to the project increases the
   1.191 -code size most, it makes the project most independent.
   1.192 -On the other end, interfacing external programs keeps the interface
   1.193 -smallest, but the depencency highest.
   1.194 -Using a library is in the middle.
   1.195 -Adding the function directly to the project is a bad choice for
   1.196 -any function of higher complexity, unless it's not available in other ways.
   1.197 +code size most and requires most maintenance and development work,
   1.198 +it makes the project most independent.
   1.199 +Using libraries or external programs require less
   1.200 +maintenance work.
   1.201 +Programs have the smallest interfaces, providing the most separation
   1.202 +but possibly limiting the information exchange.
   1.203 +External libraries are stronger connected than external programs but 
   1.204 +allow better information exchange.
   1.205 +Adding more code to a project does always increase maintenance work.
   1.206 +Implementing complex functions directly in the project will add
   1.207 +a lot of code. This should be avoided if possible.
   1.208  Hence, the dependencies only change in kind, not in their existence.
   1.209  In mmh, library dependencies on
   1.210  .Pn libsasl2
   1.211 @@ -145,11 +167,12 @@
   1.212  This made mmh's code base about 12\|% smaller.
   1.213  Reducing the projects code size by such an amount without actually
   1.214  losing function is a convincing argument.
   1.215 +Actually, as external MSAs and MRAs are likely better
   1.216 +than the project's internal version, the user even gains functionality.
   1.217  .P
   1.218 -Users of MH should have not problem to set up an external MSA and MRA.
   1.219 +Users of MH should not have problems to set up an external MSA and MRA.
   1.220  Also, the popular MSAs and MRAs have large communities and a lot
   1.221  of documentation available.
   1.222 -.P
   1.223  Choices for MSAs range from the full-featured
   1.224  .I Postfix
   1.225  over mid-size solutions like
   1.226 @@ -170,25 +193,32 @@
   1.227  
   1.228  .H2 "Removal of non-MUA Tools
   1.229  .P
   1.230 -Some of nmh's tools were removed from mmh because they didn't
   1.231 -match the main focus of adding to the MUA's task.
   1.232 +Some MH tools were removed because they didn't add to the MUA's job.
   1.233 +It is a design goal of mmh to remove the parts that are rarely used.
   1.234 +The project shall become more stream-lined and focused.
   1.235 +Rarely used and loosely related tools distract from the lean appearance.
   1.236 +They require maintenance work without adding to the core task.
   1.237 +In mmh the following tools are not available anymore:
   1.238  .BU
   1.239  .Pn conflict
   1.240  was removed because it is a mail system maintenance tool.
   1.241 +.Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9
   1.242  Besides, it even checks
   1.243  .Fn /etc/passwd
   1.244  and
   1.245  .Fn /etc/group
   1.246  for consistency, which has nothing at all to do with emailing.
   1.247  The tool might be useful, but it should not be shipped with mmh.
   1.248 +.\" XXX historic reasons?
   1.249  .BU
   1.250  .Pn rcvtty
   1.251  was removed because its usecase of writing to the user's terminal
   1.252 -on receiving of mail is hardly wanted today. If users like to be
   1.253 -informed of new mail, then using the shell's
   1.254 +on receiving of mail is obsolete.
   1.255 +.Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
   1.256 +If users like to be
   1.257 +informed of new mail, the shell's
   1.258  .Ev MAILPATH
   1.259 -variable or graphical notifications are likely more
   1.260 -appealing.
   1.261 +variable or graphical notifications are more appealing.
   1.262  Writing directly to a terminals is hardly ever wanted today.
   1.263  If though one wants to have it this way, the standard tool
   1.264  .Pn write
   1.265 @@ -198,100 +228,139 @@
   1.266  .DE
   1.267  .BU
   1.268  .Pn viamail
   1.269 -was removed when the new attachment system was introduced, because
   1.270 +was removed when the new attachment system was activated, because
   1.271  .Pn forw
   1.272 -could can now the task itself.
   1.273 +could then cover the task itself.
   1.274 +.Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
   1.275  The program
   1.276  .Pn sendfiles
   1.277  was rewritten as a shell script wrapper around
   1.278  .Pn forw .
   1.279 +.Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
   1.280  .BU
   1.281  .Pn msgchk
   1.282 -was removed, because it lost its usefulness when POP support was removed.
   1.283 +was removed, because it lost its use case when POP support was removed.
   1.284 +.Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe
   1.285 +A call to
   1.286  .Pn msgchk
   1.287 -provides hardly more information than:
   1.288 +provided hardly more information than
   1.289  .DS
   1.290  ls -l /var/mail/meillo
   1.291  .DE
   1.292 -It does separate between old and new mail, but that's merely a detail
   1.293 -and can be done with
   1.294 -.Pn stat (1)
   1.295 +though it distinguished between old and new mail.
   1.296 +This detail information and can be retrieved with
   1.297 +.Pn stat (1),
   1.298  too.
   1.299  A very small shell script could be written to output the information
   1.300 -in a convenient way, if truly necessary.
   1.301 -As mmh's inc only incorporates mail from the user's local maildrop
   1.302 +in a similar way, if truly necessary.
   1.303 +As mmh's
   1.304 +.Pn inc
   1.305 +only incorporates mail from the user's local maildrop
   1.306  and thus no data transfers over slow networks are involved,
   1.307 -there's hardly need to check for new mail before incorporating it.
   1.308 +there's hardly any need to check for new mail before incorporating it.
   1.309  .BU
   1.310  .Pn msh
   1.311 -was removed because the tool was in conflict with the
   1.312 -philosophy of MH. It provided an interactive shell to access the
   1.313 -features of MH. One major feature of MH is being a tool chest.
   1.314 -.Pn msh
   1.315 -wouldn't be just another shell, tailored to the needs of mail
   1.316 -handling, but one large program to have the MH tools built in.
   1.317 -It's main use was for accessing Bulletin Boards, which have seized to
   1.318 +was removed because the tool was in conflict with the philosophy of MH.
   1.319 +.Ci 916690191222433a6923a4be54b0d8f6ac01bd02
   1.320 +It provided an interactive shell to access the features of MH,
   1.321 +but it wasn't just a shell, tailored to the needs of mail handling.
   1.322 +Instead it was one large program that had several MH tools built in.
   1.323 +This conflicts with the major feature of MH of being a tool chest.
   1.324 +.Pn msh 's
   1.325 +main use case had been accessing Bulletin Boards, which have seized to
   1.326  be popular.
   1.327  .P
   1.328  Removing
   1.329  .Pn msh ,
   1.330 -together with the truly obsolete code relicts
   1.331 +together with the truly archaic code relicts
   1.332  .Pn vmh
   1.333  and
   1.334  .Pn wmh ,
   1.335  saved more than 7\|000 lines of C code \(en
   1.336  about 15\|% of the project's original source code amount.
   1.337 -Having the same functionality in less code (with equal readability,
   1.338 -of course) is an advantage.
   1.339 +.P
   1.340 +Having less code (with equal readability, of course)
   1.341 +for the same functionality is an advantage.
   1.342  Less code means less bugs and less maintenance work.
   1.343 -If
   1.344 +As
   1.345  .Pn rcvtty
   1.346  and
   1.347  .Pn msgchk
   1.348  are rarely used and can be implemented in different ways,
   1.349  then why should one keep them?
   1.350 +Removing them stream-lines mmh.
   1.351  .Pn viamail 's
   1.352  use case is now partly obsolete and partly covered by
   1.353  .Pn forw ,
   1.354 -hence there's no reason to still have
   1.355 -.Pn viamail
   1.356 -around.
   1.357 +hence there's no reason to still maintain it.
   1.358  .Pn conflict
   1.359 -is not related with the mail client, and
   1.360 +is not related to the mail client, and
   1.361  .Pn msh
   1.362  conflicts with the basic concept of MH.
   1.363 -Both tools could still be useful, but not as part of mmh.
   1.364 +Theses two tools might still be useful, but they should not be part of mmh.
   1.365  .P
   1.366 -It is a design goal of mmh to remove those parts that are rarely used.
   1.367 -The project shall become more stream-lined.
   1.368 -Rarely used and loosely related tools distract from the lean appearance.
   1.369 -They require maintenance cost without adding to the core task.
   1.370 -Therefore they were removed.
   1.371 +Finally, there's
   1.372 +.Pn slocal .
   1.373 +.Pn slocal
   1.374 +is an MDA and thus not directly MUA-related.
   1.375 +Conceptionally, it should be removed.
   1.376 +But
   1.377 +.Pn slocal
   1.378 +provides rule-based processing of messages, like filing them into
   1.379 +different folders, which is otherwise not available in mmh.
   1.380 +Further more,
   1.381 +.Pn slocal
   1.382 +does neither pull dependencies nor a whole new technical area
   1.383 +into the project.
   1.384 +(See section XXX for the removing of the ndbm dependency.)
   1.385 +Still,
   1.386 +.Pn slocal
   1.387 +accounts for about 1\|000 lines of code that need to be maintained.
   1.388 +As
   1.389 +.Pn slocal
   1.390 +is almost self-standing, it should be split off into a separate project.
   1.391 +This would cut the strong connection between the MUA mmh and the MDA
   1.392 +.Pn slocal .
   1.393 +The MDA would become an alternative to
   1.394 +.I procmail ,
   1.395 +as it would no longer be the need to install a complete MH system, too.
   1.396 +Likewise, mmh users could decide to use
   1.397 +.I procmail
   1.398 +without having a second, unused MDA (\c
   1.399 +.Pn slocal )
   1.400 +installed.
   1.401 +That's conceptionally the best solution.
   1.402 +Yet,
   1.403 +.Pn slocal
   1.404 +is not removed,
   1.405 +but as its existence does not affect the rest of mmh,
   1.406 +it can be removed at any time.
   1.407  
   1.408  
   1.409 -.H2 "Merge of \f(CWshow\fP and \f(CWmhshow\fP
   1.410 +.H2 "\fLshow\fP and \fPmhshow\fP
   1.411  .P
   1.412  Since the very beginning \(en already in the first concept paper \(en
   1.413  .Pn show
   1.414  had been MH's message display program.
   1.415  .Pn show
   1.416 -found out which pathnames the relevant messages had and invoked
   1.417 +mapped message numbers and sequences to files and invoked
   1.418  .Pn mhl
   1.419 -then to have the content formated.
   1.420 -With the advent of MIME, this approach wasn't sufficient anymore.
   1.421 +to have the files formated.
   1.422 +For MIME, this approach wasn't sufficient anymore.
   1.423  MIME messages can consist of multiple parts, some of which aren't
   1.424  directly displayable, and text content might be encoded in
   1.425  foreign charsets.
   1.426  .Pn show 's
   1.427 -simple approach and
   1.428 +understanding of messages and
   1.429  .Pn mhl 's
   1.430  limited display facilities couldn't cope with the task any longer.
   1.431  .P
   1.432 -Instead of extending these tools, additional ones were written from scratch
   1.433 +Instead of extending these tools, additional tools were written from scratch
   1.434  and then added to the MH tool chest. Doing so is encouraged by the
   1.435  tool chest approach. The new tools could be added without interfering
   1.436 -with the existing ones. This is great. The ease of adding new tools
   1.437 -even made MH the first MUA to implement MIME.
   1.438 +with the existing ones. This is an advantage. The ease of adding new tools
   1.439 +made MH the first MUA to implement MIME.
   1.440 +.\" XXX ref
   1.441  .P
   1.442  First, the new MIME features were added in form of the single program
   1.443  .Pn mhn .
   1.444 @@ -307,9 +376,13 @@
   1.445  which replaced the
   1.446  .Cl "mhn \-show
   1.447  call.
   1.448 +It was capable to display a MIME message appropriately.
   1.449  .P
   1.450 -From then on, two message display tools were part of nmh.
   1.451 -Because it should not require user actions to invoke the right tool
   1.452 +From then on, two message display tools were part of nmh:
   1.453 +.Pn show
   1.454 +and
   1.455 +.Pn mhshow .
   1.456 +Because the user should not need to invoke the right tool
   1.457  whether the message uses MIME or not,
   1.458  .Pn show
   1.459  was extended to automatically hand the job over to
   1.460 @@ -317,10 +390,6 @@
   1.461  if displaying the message would be beyond
   1.462  .Pn show 's
   1.463  abilities.
   1.464 -For convenience,
   1.465 -.Pn show
   1.466 -would still display MIME messages if they contained only a single text
   1.467 -part.
   1.468  In consequence, the user would invoke
   1.469  .Pn show
   1.470  (possibly through
   1.471 @@ -335,16 +404,20 @@
   1.472  (There was also a switch for
   1.473  .Pn show
   1.474  to never invoke
   1.475 -.Pn mhshow .)
   1.476 +.Pn mhshow .
   1.477 +.Pn show
   1.478 +was able to display MIME messages if they contained only a single text
   1.479 +part.)
   1.480  .P
   1.481  Having two similar tools for essentially the same task is redundant.
   1.482 -Both programs needed to be developed syncronously as they were
   1.483 -used as a single tool by the user. Thus they needed to act in a
   1.484 -similar way to not distract the user.
   1.485 +The development of both programs needed to be in sync,
   1.486 +to ensure that the programs behaved in a similar way,
   1.487 +because they were used like a single tool.
   1.488 +Different behavior would have surprised the user.
   1.489  .P
   1.490  Today, non-MIME messages are rather seen to be a special case of
   1.491  MIME messages, than MIME messages are seen to be an extension to
   1.492 -original mail.
   1.493 +original email.
   1.494  As
   1.495  .Pn mhshow
   1.496  had already be able to display non-MIME messages, it was natural
   1.497 @@ -353,24 +426,28 @@
   1.498  in favor of using
   1.499  .Pn mhshow
   1.500  exclusively.
   1.501 +This decision followed the idea of orthogonal design.
   1.502 +For convenience,
   1.503 +.Pn mhshow
   1.504 +was then renamed to
   1.505 +.Pn show .
   1.506  .Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
   1.507 -This decision follows the idea of orthogonal design.
   1.508  .P
   1.509 -To allow this replacement,
   1.510 +To prepare for this transition,
   1.511  .Pn mhshow
   1.512  was reworked to behave more like
   1.513  .Pn show
   1.514  first.
   1.515 -Section XXX describes this rework from a different perspective.
   1.516 +(Section XXX describes this rework from a different perspective.)
   1.517  Once the tools behaved similar, the replacing became a natural decision.
   1.518  In mmh,
   1.519  .Pn show
   1.520  is the one single message display program again, but it handles
   1.521  MIME messages as well as non-MIME messages.
   1.522 -There's only one program to maintain and users don't need to deal
   1.523 +Now, there's only one program to maintain, and users don't need to deal
   1.524  with the existance of two display programs.
   1.525  .P
   1.526 -Though, there's one reason why removing the old
   1.527 +There's one reason why removing the old
   1.528  .Pn show
   1.529  hurts: It had been such a simple program.
   1.530  Its lean elegance is missing to
   1.531 @@ -383,24 +460,22 @@
   1.532  
   1.533  .H2 "Removal of Configure Options
   1.534  .P
   1.535 -Choice is a double-edged sword.
   1.536 -It allows customization and thus better suiting solutions,
   1.537 -but that comes with costs.
   1.538 -First, there is the cost of code complexity to have choice.
   1.539 -Second, there is the cost of less tested setups, because there are
   1.540 +Customization is a double-edged sword.
   1.541 +It allows better suiting setups, but not for free.
   1.542 +There is the cost of code complexity to be able to customize.
   1.543 +There is the cost of less tested setups, because there are
   1.544  more possible setups and especially corner-cases.
   1.545 -Third, there is the cost of choice itself.
   1.546 -The code complexity affects the developers.
   1.547 +And, there is the cost of choice itself.
   1.548 +The code complexity directly affects the developers.
   1.549  Less tested code affects both, users and developers.
   1.550 -The problem of choice affects the users, for once simply by having to
   1.551 -choose but also by complexer interfaces that require more documentation.
   1.552 +The problem of choice affects the users, for once by having to
   1.553 +choose, but also by complexer interfaces that require more documentation.
   1.554  Whenever options add little advantages, they should be considered for
   1.555  removal.
   1.556 -.P
   1.557  I have reduced the number of project-specific configure options from 
   1.558  fifteen to three.
   1.559  
   1.560 -.U3 "Mail Transfer Facility Options
   1.561 +.U3 "Mail Transfer Facilities
   1.562  .P
   1.563  With the removal of the mail transfer facilities five option vanished:
   1.564  .IP \f(CW--with-mts=[smtp|sendmail]\fP
   1.565 @@ -417,8 +492,9 @@
   1.566  
   1.567  .U3 "Backup Prefix
   1.568  .P
   1.569 -The default backup prefix, i.e. the string that was prepended to message
   1.570 -filenames to tag them as deleted, had been the comma `\f(CW,\fP'.
   1.571 +The backup prefix is the string that was prepended to message
   1.572 +filenames to tag them as deleted.
   1.573 +By default it had been the comma character `\f(CW,\fP'.
   1.574  There was a configure option to change the default to the hash symbol
   1.575  `\f(CW#\fP':
   1.576  .CW --with-hash-backup .
   1.577 @@ -439,31 +515,31 @@
   1.578  .Pe backup-prefix ,
   1.579  which allows to specify an arbitrary string as backup prefix.
   1.580  .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
   1.581 -This did not remove the choice but moved it to a location where
   1.582 +Profile entries are the common method to change mmh's behavior.
   1.583 +This change did not remove the choice but moved it to a location where
   1.584  it suited better.
   1.585 -Profile entries are the common method to change mmh's behavior.
   1.586 -The name of the
   1.587 -.Fn .mh-sequences ,
   1.588 -for instance, is specified there, too.
   1.589 -Moving the specification of the backup prefix there, appears to be right.
   1.590 -Eventually, the new trash folder obsoleted the concept of the
   1.591 +.P
   1.592 +Eventually, however, the new trash folder obsoleted the concept of the
   1.593  backup prefix completely.
   1.594  (Well, there still are corner-cases to remove until the backup
   1.595  prefix can be layed to rest, eventually.)
   1.596  .\" FIXME: Do this work in the code!
   1.597 +
   1.598 +.U3 "Editor and Pager
   1.599  .P
   1.600  The two configure options
   1.601  .CW --with-editor=EDITOR
   1.602  .CW --with-pager=PAGER
   1.603  were used to specify the default editor and pager at configure time.
   1.604  Doing so at configure time made sense in the Eighties,
   1.605 -when the available editors and pagers varied more across different systems.
   1.606 -Today, the situation is much more homegenic.
   1.607 +when the set of available editors and pagers varied much across
   1.608 +different systems.
   1.609 +Today, the situation is more homegeneic.
   1.610  The programs
   1.611  .Pn vi
   1.612  and
   1.613  .Pn more
   1.614 -can be expected to be available anywhere on every Unix system,
   1.615 +can be expected to be available on every Unix system,
   1.616  as they are specified by POSIX since two decades.
   1.617  (The specifications for
   1.618  .Pn vi
   1.619 @@ -484,14 +560,13 @@
   1.620  .Pe editor
   1.621  and
   1.622  .Pe moreproc
   1.623 -profile entries, which allowed the user to change the default
   1.624 -by personal preference.
   1.625 +profile entries, which allowed the user to override the system defaults.
   1.626  Later, the concept was reworked to respect the standard environment
   1.627  variables
   1.628  .Ev VISUAL
   1.629  and
   1.630  .Ev PAGER
   1.631 -if they were set.
   1.632 +if they are set.
   1.633  Today, mmh determines the editor to use in the following order,
   1.634  taking the first available and non-empty item:
   1.635  .IP (1)
   1.636 @@ -510,7 +585,9 @@
   1.637  Command
   1.638  .Pn vi .
   1.639  .P
   1.640 -The pager to use is deteminded in the following order,
   1.641 +.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
   1.642 +.P
   1.643 +The pager to use is deteminded in a similar order,
   1.644  also taking the first available and non-empty item:
   1.645  .IP (1)
   1.646  Environment variable
   1.647 @@ -527,18 +604,16 @@
   1.648  Command
   1.649  .Pn more .
   1.650  .P
   1.651 -.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
   1.652  .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
   1.653  .P
   1.654 -The new behavior confirms better to the common behavior on Unix
   1.655 -systems, as
   1.656 +By respecting the
   1.657  .Ev VISUAL /\c
   1.658  .Ev EDITOR
   1.659  and
   1.660  .Ev PAGER
   1.661 -are respected.
   1.662 -Additionally, the new approach is more uniform and
   1.663 -without surprise for users.
   1.664 +environment variables,
   1.665 +the new behavior confirms better to the common style on Unix systems.
   1.666 +Additionally, the new approach is more uniform and clearer to users.
   1.667  
   1.668  .U3 "Locale
   1.669  .P
   1.670 @@ -548,7 +623,7 @@
   1.671  support.
   1.672  .Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9
   1.673  
   1.674 -.U3 "\fLslocal\fP Supress Duplicates
   1.675 +.U3 "ndbm
   1.676  .P
   1.677  .Pn slocal
   1.678  is an MDA included in mmh.
   1.679 @@ -559,11 +634,13 @@
   1.680  yet it remains being part of mmh.
   1.681  This is likely to change in the future.
   1.682  Already,
   1.683 -.Pn slocal was stripped down.
   1.684 +.Pn slocal
   1.685 +was stripped down.
   1.686  It used to depend on
   1.687  .I ndbm ,
   1.688  a database library.
   1.689 -The database is used to store the message ids of all messages delivered.
   1.690 +The database is used to store the `\fLMessage-ID\fP's of all
   1.691 +messages delivered.
   1.692  This enables
   1.693  .Pn slocal
   1.694  to suppress delivering the same message to the same user twice.
   1.695 @@ -582,6 +659,7 @@
   1.696  .P
   1.697  By removing the suppress duplicates feature of
   1.698  .Pn slocal ,
   1.699 +.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
   1.700  the dependency on
   1.701  .I ndbm
   1.702  was removed and 120 lines of complex autoconf could be saved.
   1.703 @@ -596,46 +674,46 @@
   1.704  .Sw --disable-mhe
   1.705  was removed when the mh-e support was reworked. 
   1.706  Mh-e is the Emacs front-end to MH.
   1.707 -It requires MH to act different in some minor ways.
   1.708 -The configure option could switch the extension off.
   1.709 -After removing support for old versions of mh-e,
   1.710 +It requires MH to provide minor additional functions.
   1.711 +The
   1.712 +.Sw --disable-mhe
   1.713 +configure option could switch these extensions off.
   1.714 +After removing the support for old versions of mh-e,
   1.715  only the
   1.716  .Sw -build
   1.717 -switches for
   1.718 +switches of
   1.719  .Pn forw
   1.720  and
   1.721  .Pn repl
   1.722 -are left to be mh-e-specific.
   1.723 -They are now always available because they add little code and complexity.
   1.724 -This change was first done in nmh and thereafter merged into mmh.
   1.725 -The interface changes in mmh require mh-e to be adjusted to use mmh
   1.726 -as the back-end. This requires minor changes to mh-e, though removing
   1.727 -the
   1.728 -.Sw -build
   1.729 -switches would require larger adjustments.
   1.730 -The
   1.731 +are left to be mh-e extensions.
   1.732 +They are now always built in because they add little code and complexity.
   1.733 +In consequence, the
   1.734  .Sw --disable-mhe
   1.735 -configure option was removed and the remaining support for mh-e is always
   1.736 -built in.
   1.737 +configure option was removed
   1.738  .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
   1.739  Removing the option removed a second code setup that would have
   1.740  needed to be tested.
   1.741 +This change was first done in nmh and thereafter merged into mmh.
   1.742 +.P
   1.743 +The interface changes in mmh require mh-e to be adjusted in order
   1.744 +to be able to use mmh as back-end.
   1.745 +This will require minor changes to mh-e, but removing the
   1.746 +.Sw -build
   1.747 +switches would require more rework.
   1.748  
   1.749  .U3 "Masquerading
   1.750  .P
   1.751  The configure option
   1.752  .Sw --enable-masquerade
   1.753 -could take up to three items: draft_from, mmailid, username_extension.
   1.754 +could take up to three arguments:
   1.755 +`draft_from', `mmailid', and `username_extension'.
   1.756  They activated different types of address masquerading.
   1.757  All of them were implemented in the SMTP-speaking
   1.758  .Pn post
   1.759 -command.
   1.760 -Mmh no longer speaks SMTP and the replacing
   1.761 -.Pn spost
   1.762 -command no longer does MTA jobs like this one.
   1.763 -Because address masquerading is an MTA's task and mmh does not cover
   1.764 -this field anymore, the funtion needs to be implemented in the
   1.765 -external MTA used.
   1.766 +command, which provided an MSA.
   1.767 +Address masquerading is an MTA's task and mmh does not cover
   1.768 +this field anymore.
   1.769 +Hence, true masquerading needs to be implemented in the external MTA.
   1.770  .P
   1.771  The
   1.772  .I mmailid
   1.773 @@ -645,7 +723,7 @@
   1.774  .I username
   1.775  to
   1.776  .I fakeusername
   1.777 -mapping, based on the value of the password file's GECOS field.
   1.778 +mapping, based on the password file's GECOS field.
   1.779  The man page
   1.780  .Mp mh-tailor(5)
   1.781  described the use case as being the following:
   1.782 @@ -658,21 +736,21 @@
   1.783  ``First [Middle] Last <First.Last>''
   1.784  .P
   1.785  As mmh sends outgoing mail via the local MTA only,
   1.786 -it is the best location to do such global rewrites.
   1.787 +the best location to do such global rewrites is there.
   1.788  Besides, the MTA is conceptionally the right location because it
   1.789  does the reverse mapping for incoming mail (aliasing), too.
   1.790 -The masquerading set up there is set up once for all
   1.791 +Further more, masquerading set up there is readily available for all
   1.792  mail software on the system.
   1.793 +Hence, mmailid masquerading was removed.
   1.794  .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f
   1.795  .P
   1.796  The
   1.797  .I username_extension
   1.798 -masquerading type did not replace the username but could append a suffix
   1.799 -to it.
   1.800 -The suffix needed to be specified by the
   1.801 +masquerading type did not replace the username but would append a suffix,
   1.802 +specified by the
   1.803  .Ev USERNAME_EXTENSION
   1.804 -environment variable.
   1.805 -It provided support for the
   1.806 +environment variable, to it.
   1.807 +This provided support for the
   1.808  .I user-extension
   1.809  feature of qmail and the similar
   1.810  .I "plussed user
   1.811 @@ -680,31 +758,32 @@
   1.812  The decision to remove this username_extension masquerading was
   1.813  motivated by the fact that
   1.814  .Pn spost
   1.815 -hadn't supported it.
   1.816 -.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9_username_extension
   1.817 -Mmh now provides a more general, though in this case less convenient,
   1.818 -kind of masquerading.
   1.819 +hadn't supported it already.
   1.820 +.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
   1.821 +Username extensions are possible in mmh, but less convenient to use.
   1.822 +.\" XXX format file %(getenv USERNAME_EXTENSION)
   1.823  .P
   1.824  The
   1.825  .I draft_from
   1.826  masquerading type instructed
   1.827  .Pn post
   1.828  to use the value of the `From:' header as SMTP envelope sender.
   1.829 -This allowes to replace the sender address completely.
   1.830 +Sender addresses could be replaced completely.
   1.831  .Ci b14ea6073f77b4359aaf3fddd0e105989db9
   1.832 -Mmh now offers a kind of masquerading similar in effect, but
   1.833 +Mmh offers a kind of masquerading similar in effect, but
   1.834  with technical differences.
   1.835 -As mmh does not transfer messages itself, the local MTA has full control
   1.836 -over the sending address. Any masquerading mmh introduces may be reverted
   1.837 -by the MTA. In times of pedantic spam checking, an MTA will likely do so
   1.838 -to keep its own reputation up.
   1.839 -Nonetheless, the MUA can set the `From:' header and thus propose
   1.840 -a sender address to be used to the MTA.
   1.841 +As mmh does not transfer messages itself, the local MTA has final control
   1.842 +over the sender's address. Any masquerading mmh introduces may be reverted
   1.843 +by the MTA.
   1.844 +In times of pedantic spam checking, an MTA will take care to use
   1.845 +sensible envelope sender addresses to keep its own reputation up.
   1.846 +Nonetheless, the MUA can set the `From:' header and thereby propose
   1.847 +a sender address to the MTA.
   1.848  The MTA may then decide to take that one or generate the canonical sender
   1.849  address for use as envelope sender address.
   1.850  .P
   1.851  In mmh, the MTA will always extract the recipient and sender from the
   1.852 -headers (\c
   1.853 +message headers (\c
   1.854  .Pn sendmail 's
   1.855  .Sw -t
   1.856  switch).
   1.857 @@ -716,10 +795,10 @@
   1.858  Two configure options remain in mmh.
   1.859  One is the locking method to use:
   1.860  .Sw --with-locking=[dot|fcntl|flock|lockf] .
   1.861 -Removing all other methods except the portable dot locking and having
   1.862 -that as default is appealing, but requires deeper investigation into the
   1.863 -topic.
   1.864 -The other,
   1.865 +The idea of removing all methods except the portable dot locking
   1.866 +and having that one as the default is appealing, but this change
   1.867 +requires deeper technical investigation into the topic.
   1.868 +The other option,
   1.869  .Sw --enable-debug ,
   1.870  compiles the programs with debugging symbols and does not strip them.
   1.871  This option is likely to stay.