1.1 --- a/bib	Fri Jul 13 18:35:36 2012 +0200
     1.2 +++ b/bib	Sat Jul 14 18:04:32 2012 +0200
     1.3 @@ -94,14 +94,14 @@
     1.4  %O \fU http://\:en.wikisource.org/\:wiki/\:On_the_Origin_of_Species_(1859)
     1.5  
     1.6  %A Bryan Costales
     1.7 -%A Claus Assmann
     1.8 +%A Claus A\[germandbls]mann
     1.9  %A George Jansen
    1.10  %A Gregory N. Shapiro
    1.11  %T sendmail
    1.12 -%D 2007
    1.13 +%D 2008
    1.14  %V Fourth Edition
    1.15  %I O'Reilly
    1.16 -%O \s-1ISBN\s0: 0596510292
    1.17 +%O \s-1ISBN\s0: 0-596-51029-2
    1.18  
    1.19  %A Peter H. Salus
    1.20  %T A Quarter Century of UNIX
    1.21 @@ -282,3 +282,8 @@
    1.22  %D May 21 1986
    1.23  %O \fU http://\:git.savannah.gnu.org/\:cgit/\:nmh.git/\:plain/\:docs/\:historical/\:tutorial.pdf
    1.24  
    1.25 +%T The qmail Handbook
    1.26 +%A Dave Sill
    1.27 +%I Apress
    1.28 +%D 2002
    1.29 +%O \s-1ISBN\s0: 1-893115-40-2

     2.1 --- a/discussion.roff	Fri Jul 13 18:35:36 2012 +0200
     2.2 +++ b/discussion.roff	Sat Jul 14 18:04:32 2012 +0200
     2.3 @@ -2,53 +2,60 @@
     2.4  .P
     2.5  This main chapter discusses the practical work accomplished in the
     2.6  mmh project.
     2.7 -It is structured along the goals set for the project.
     2.8 -The concrete work undertaken
     2.9 -is described in the examples of how the general goals were achieved.
    2.10 -The discussion compares the current version of mmh with the state of
    2.11 -nmh just before the mmh project started, i.e. fall 2011.
    2.12 -Current changes of nmh will be mentioned only as side notes.
    2.13 -.\" XXX where do I discuss the parallel development of nmh?
    2.14 +It is structured along the goals chosen for the project.
    2.15 +A selection of the work undertaken
    2.16 +is described.
    2.17 +.P
    2.18 +This discussion compares the present version of mmh with the state of
    2.19 +nmh at the time when the mmh project had started, i.e. fall 2011.
    2.20 +Recent changes in nmh are seldom part of the discussion.
    2.21 +Sometimes they are mentioned in side notes.
    2.22  .P
    2.23  For the reader's convenience, the structure of modern email systems
    2.24 -is depicted in the figure.
    2.25 +is depicted in the following figure.
    2.26  It illustrates the path a message takes from sender to recipient.
    2.27 -.sp
    2.28 +
    2.29 +.sp 1.5
    2.30  .KS
    2.31  .in 2c
    2.32  .so input/mail-agents.pic
    2.33  .KE
    2.34 -.sp
    2.35 +.sp 1.5
    2.36 +
    2.37  .LP
    2.38 -The ellipses denote mail agents, i.e. different jobs in email processing:
    2.39 +The ellipses denote mail agents, i.e. different jobs in email processing.
    2.40 +These are:
    2.41  .IP "Mail User Agent (MUA)
    2.42 -The only program the user interacts directly with.
    2.43 +The only program users directly interact with.
    2.44  It includes functions to compose new mail, display received mail,
    2.45  and to manage the mail storage.
    2.46 -Also called \fImail client\fP.
    2.47 +It is called a \fImail client\fP as well.
    2.48  .IP "Mail Submission Agent (MSA)
    2.49  A special kind of Mail Transfer Agent, used to submit mail into the
    2.50  mail transport system.
    2.51 +Often it is also called an MTA.
    2.52  .IP "Mail Transfer Agent (MTA)
    2.53  A node in the mail transport system.
    2.54 -Transfers incoming mail to a transport node nearer to the final destination.
    2.55 -It may be the final destination itself.
    2.56 +It transfers incoming mail to a transport node nearer to the
    2.57 +final destination.
    2.58 +An MTA may be the final destination itself.
    2.59  .IP "Mail Delivery Agent (MDA)
    2.60 -Delivers mail by storing it onto disk, usually according to a set of rules.
    2.61 +Delivers mail according to a set of rules.
    2.62 +Usually, the messages are stored to disk.
    2.63  .IP "Mail Retrieval Agent (MRA)
    2.64 -Initiates the transfer of mail from a remote server to the local machine.
    2.65 -(The dashed arrow represents the pull request.)
    2.66 -.P
    2.67 -The dashed boxes represent groups that usually reside on single machines.
    2.68 -The box on the lower left represents the sender's local system.
    2.69 +Initiates the transfer of mail from a remote location to the local machine.
    2.70 +(The dashed arrow in the figure represents the pull request.)
    2.71 +.LP
    2.72 +The dashed boxes represent entities that usually reside on single machines.
    2.73 +The box on the lower left represents the sender's system.
    2.74  The box on the upper left represents the first mail transfer node.
    2.75  The box on the upper right represents the transfer node responsible for the
    2.76  destination address.
    2.77 -The box on the lower right represents the recipient's local system.
    2.78 +The box on the lower right represents the recipient's system.
    2.79  Often, the boxes above the dotted line are servers on the Internet.
    2.80 -Many mail clients, including nmh, have all of the components below
    2.81 -the dotted line implemented.
    2.82 -Not so in mmh, which is an MUA only.
    2.83 +Many mail clients, including nmh, include all of the components below
    2.84 +the dotted line.
    2.85 +This is not the case for mmh; it implements the MUA only.
    2.86  
    2.87  
    2.88  
    2.89 @@ -59,9 +66,8 @@
    2.90  .H1 "Streamlining
    2.91  
    2.92  .P
    2.93 -MH once provided anything necessary for email handling.
    2.94 -The community around nmh has the similar understanding that nmh should
    2.95 -provide a complete email system.
    2.96 +MH once provided a complete email system.
    2.97 +The community around nmh tries to keep nmh in similar shape.
    2.98  In fundamental contrast, mmh shall be an MUA only.
    2.99  I believe that the development of all-in-one mail systems is obsolete.
   2.100  Today, email is too complex to be fully covered by a single project.
   2.101 @@ -69,28 +75,37 @@
   2.102  Instead, the aspects of email should be covered by multiple projects,
   2.103  which then can be combined to form a complete system.
   2.104  Excellent implementations for the various aspects of email already exist.
   2.105 -Just to name three examples: Postfix is a specialized MTA,
   2.106 -.\" XXX homepages verlinken
   2.107 -Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
   2.108 +Just to name three examples: Postfix
   2.109 +.[
   2.110 +postfix website
   2.111 +.]
   2.112 +is a specialized MTA, Procmail
   2.113 +.[
   2.114 +procmail website
   2.115 +.]
   2.116 +is a specialized MDA, and Fetchmail
   2.117 +.[
   2.118 +fetchmail website
   2.119 +.]
   2.120 +is a specialized MRA.
   2.121  I believe that it is best to use such specialized tools instead of
   2.122 -providing the same function again as a side-component in the project.
   2.123 -.\" XXX mail agent picture here
   2.124 +providing the same function once more as a side component.
   2.125  .P
   2.126  Doing something well requires focusing on a small set of specific aspects.
   2.127 -Under the assumption that development focussed on a particular area
   2.128 -produces better results there, specialized projects will be superior
   2.129 +Under the assumption that development which is focussed on a particular
   2.130 +area produces better results there, specialized projects will be superior
   2.131  in their field of focus.
   2.132  Hence, all-in-one mail system projects \(en no matter if monolithic
   2.133  or modular \(en will never be the best choice in any of the fields.
   2.134 -Even in providing the best consistent all-in-one system, they are likely
   2.135 -to be beaten by projects that focus only on integrating existing mail
   2.136 -components to create a homogeneous system.
   2.137 +Even in providing the most consistent all-in-one system, they are likely
   2.138 +to be beaten by projects that focus exclusively on the creation
   2.139 +of a homogeneous system by integrating existing mail components.
   2.140  .P
   2.141 -The limiting resource in the community development of free software
   2.142 -is usually man power.
   2.143 +Usually, the limiting resource in the community development of
   2.144 +free software is man power.
   2.145  .\" XXX FIXME ref!
   2.146 -If the development power is spread over a large development area,
   2.147 -it becomes even more difficult to compete with the specialists in the
   2.148 +If the development effort is spread over a large development area,
   2.149 +it becomes more difficult to compete with the specialists in the
   2.150  various fields.
   2.151  The concrete situation for MH-based mail systems is even tougher,
   2.152  given their small and aged community, concerning both developers and users.
   2.153 @@ -104,23 +119,24 @@
   2.154  .H2 "Mail Transfer Facilities
   2.155  .Id mail-transfer-facilities
   2.156  .P
   2.157 -In contrast to nmh, which also provides mail submission and mail retrieval
   2.158 -agents, mmh is an MUA only.
   2.159 -This general difference initiated the development of mmh.
   2.160 -The removal of the mail transfer facilities was the first work task
   2.161 -in the mmh project.
   2.162 +The removal of the mail transfer facilities, effectively dropping the
   2.163 +MSA and MRA, had been the first work task in the mmh project.
   2.164 +The desire for this change initiated the creation of the mmh project.
   2.165  .P
   2.166  Focusing on one mail agent role only, is motivated by Eric Allman's
   2.167  experience with Sendmail.
   2.168 -He identified the limitation of Sendmail to the MTA task as one reason for
   2.169 -its success:
   2.170 +He identified the limitation of Sendmail
   2.171 +.[
   2.172 +sendmail website
   2.173 +.]
   2.174 +to the MTA task as one reason for its success:
   2.175  .[ [
   2.176  costales sendmail
   2.177  .], p. xviii]
   2.178  .QS
   2.179  Second, I limited myself to the routing function \(en
   2.180  I wouldn't write user agents or delivery back-ends.
   2.181 -This was a departure of the dominant through of the time,
   2.182 +This was a departure of the dominant thought of the time,
   2.183  in which routing logic, local delivery, and often the network code
   2.184  were incorporated directly into the user agents.
   2.185  .QE
   2.186 @@ -128,49 +144,52 @@
   2.187  In nmh, the MSA is called \fIMessage Transfer Service\fP (MTS).
   2.188  This facility, implemented by the
   2.189  .Pn post
   2.190 -command, established network connections and spoke SMTP to submit
   2.191 +command, establishes network connections and spoke SMTP to submit
   2.192  messages to be relayed to the outside world.
   2.193 -The changes in email demanded changes in this part of nmh as well.
   2.194 +When email transfer changed, this part needed to be changed as well.
   2.195  Encryption and authentication for network connections
   2.196  needed to be supported, hence TLS and SASL were introduced into nmh.
   2.197 -This added complexity to nmh without improving it in its core functions.
   2.198 -Also, keeping up with recent developments in the field of
   2.199 +This added complexity without improving the core functions.
   2.200 +Furthermore, keeping up with recent developments in the field of
   2.201  mail transfer requires development power and specialists.
   2.202 -In mmh, this whole facility was simply cut off.
   2.203 +In mmh, this whole facility was simply cut off
   2.204  .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
   2.205  .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
   2.206 -.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
   2.207 +.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b .
   2.208  Instead, mmh depends on an external MSA.
   2.209 -The only outgoing interface available to mmh is the
   2.210 +All outgoing mail in mmh goes through the
   2.211  .Pn sendmail
   2.212  command, which almost any MSA provides.
   2.213  If not, a wrapper program can be written.
   2.214  It must read the message from the standard input, extract the
   2.215  recipient addresses from the message header, and hand the message
   2.216  over to the MSA.
   2.217 -For example, a wrapper script for qmail would be:
   2.218 +For example, a wrapper script for qmail
   2.219 +.[
   2.220 +qmail website
   2.221 +.]
   2.222 +would be:
   2.223  .VS
   2.224  #!/bin/sh
   2.225  exec qmail-inject  # ignore command line arguments
   2.226  VE
   2.227  The requirement to parse the recipient addresses out of the message header 
   2.228 -is likely to be removed in the future.
   2.229 -Then mmh would pass the recipient addresses as command line arguments.
   2.230 +may be removed in the future.
   2.231 +Mmh could pass the recipient addresses as command line arguments.
   2.232  This appears to be the better interface.
   2.233 -.\" XXX implement it
   2.234  .P
   2.235  To retrieve mail, the
   2.236  .Pn inc
   2.237 -command acted as an MRA.
   2.238 -It established network connections
   2.239 -and spoke POP3 to retrieve mail from remote servers.
   2.240 +command in nmh acts as MRA.
   2.241 +It establishes network connections
   2.242 +and speaks POP3 to retrieve mail from remote servers.
   2.243  As with mail submission, the network connections required encryption and
   2.244 -authentication, thus TLS and SASL were added.
   2.245 +authentication, thus TLS and SASL were added to nmh.
   2.246  Support for message retrieval through IMAP will soon become necessary
   2.247  additions, too, and likewise for any other changes in mail transfer.
   2.248 -Not so for mmh because it has dropped the support for retrieving mail
   2.249 -from remote locations.
   2.250 -.Ci ab7b48411962d26439f92f35ed084d3d6275459c
   2.251 +But not in mmh because it has dropped the support for retrieving mail
   2.252 +from remote locations
   2.253 +.Ci ab7b48411962d26439f92f35ed084d3d6275459c .
   2.254  Instead, it depends on an external tool to cover this task.
   2.255  Mmh has two paths for messages to enter mmh's mail storage:
   2.256  (1) Mail can be incorporated with
   2.257 @@ -179,19 +198,20 @@
   2.258  .Pn rcvstore
   2.259  by reading them, one at a time, from the standard input.
   2.260  .P
   2.261 -With the removal of the MSA and MRA, mmh converted from an all-in-one
   2.262 -mail system to being an MUA only.
   2.263 +With the removal of the MSA and MRA, mmh converted from a complete
   2.264 +mail system to only an MUA.
   2.265  Now, of course, mmh depends on third-party software.
   2.266  An external MSA is required to transfer mail to the outside world;
   2.267  an external MRA is required to retrieve mail from remote machines.
   2.268 -Excellent implementations of such software exist,
   2.269 -which likely are superior than the internal version.
   2.270 -Additionally, the best suiting programs can be freely chosen.
   2.271 +Excellent implementations of such software exist.
   2.272 +They likely are superior to the internal versions that were removed.
   2.273 +Additionally, the best suiting programs can be chosen freely.
   2.274  .P
   2.275 -As it had already been possible to use an external MSA or MRA,
   2.276 -why not keep the internal version for convenience?
   2.277 -.\" XXX ueberleitung
   2.278 -The question whether there is sense in having a fall-back pager in all
   2.279 +As it had already been possible to use an external MSA and MRA,
   2.280 +why should the internal version not be kept for convenience?
   2.281 +.\" XXX commas correct?
   2.282 +Transfered to a different area,
   2.283 +the question whether there is sense in having a fall-back pager in all
   2.284  the command line tools, for the cases when
   2.285  .Pn more
   2.286  or
   2.287 @@ -199,7 +219,7 @@
   2.288  are not available, appears to be ridiculous.
   2.289  Of course, MSAs and MRAs are more complex than text pagers
   2.290  and not necessarily available but still the concept of orthogonal
   2.291 -design holds: ``Write programs that do one thing and do it well.''
   2.292 +design holds: ``Write programs that do one thing and do it well''.
   2.293  .[
   2.294  mcilroy unix phil
   2.295  p. 53
   2.296 @@ -215,61 +235,61 @@
   2.297  reasons that programs which have grown complex should be split.
   2.298  If it is conceptionally more elegant to have the MSA and MRA as
   2.299  separate projects then they should be separated.
   2.300 -In my opinion, this is the case here.
   2.301 -The RFCs propose this separation by clearly distinguishing the different
   2.302 -mail handling tasks [RFC\|821].
   2.303 -The small interfaces between the mail agents support the separation.
   2.304 +In my opinion, this is the case.
   2.305 +The RFCs suggest this separation by clearly distinguishing the
   2.306 +different mail handling tasks [RFC\|821].
   2.307 +The small interfaces between the mail agents support the
   2.308 +separation as well.
   2.309  .P
   2.310 -Email once had been small and simple.
   2.311 +Once, email had been small and simple.
   2.312  At that time,
   2.313  .Pn /bin/mail
   2.314  had covered everything there was to email and still was small and simple.
   2.315  Later, the essential complexity of email increased.
   2.316 -(Essential complexity is the complexity defined by the problem itself.\0
   2.317 -.[[
   2.318 +(Essential complexity is the complexity defined by the problem itself.\&
   2.319 +.[ [
   2.320  brooks no silver bullet
   2.321  .]])
   2.322 -Email systems reacted to this change: they grew.
   2.323 +Consequently, email systems grew.
   2.324  RFCs started to introduce the concept of mail agents to separate the
   2.325 -various tasks because they became more extensive and new tasks appeared.
   2.326 -As the mail systems grew even more, parts were split off.
   2.327 +various roles because they became more extensive and because
   2.328 +new roles appeared.
   2.329 +As mail system implementations grew, parts of them were split off.
   2.330  For instance, a POP server was included in the original MH;
   2.331  it was removed in nmh.
   2.332 -Now is the time to go one step further and split off the MSA and MRA, too.
   2.333 +Now is the time to go one step further and split off the MSA and MRA,
   2.334 +as well.
   2.335  Not only does this decrease the code size of the project,
   2.336  more importantly, it unburdens mmh of the whole field of
   2.337 -message transfer with all its implications for the project.
   2.338 +message transfer, with all its implications for the project.
   2.339  There is no more need for concern with changes in network transfer.
   2.340 -This independence is gained by depending on an external program
   2.341 -that covers the field.
   2.342 -Today, this is a reasonable exchange.
   2.343 +This independence is gained by depending on external components
   2.344 +that cover the field.
   2.345  .P
   2.346 -.\" XXX ueberleitung ???
   2.347 -Functionality can be added in three different ways:
   2.348 +In general, functionality can be added in three different ways:
   2.349  .LI 1
   2.350 -Implementing the function in the project itself.
   2.351 +By implementing the function in the project itself.
   2.352  .LI 2
   2.353 -Depending on a library that provides the function.
   2.354 +By depending on a library that provides the function.
   2.355  .LI 3
   2.356 -Depending on a program that provides the function.
   2.357 +By depending on a program that provides the function.
   2.358  .LP
   2.359  .\" XXX Rework sentence
   2.360  While implementing the function in the project itself leads to the
   2.361  largest increase in code size and requires the most maintenance
   2.362  and development work,
   2.363 -it increases the project's independence of other software the most.
   2.364 +it keeps the project's dependence on other software lowest.
   2.365  Using libraries or external programs requires less maintenance work
   2.366 -but introduces dependencies on external software.
   2.367 +but introduces dependencies on external projects.
   2.368  Programs have the smallest interfaces and provide the best separation,
   2.369  but possibly limit the information exchange.
   2.370  External libraries are more strongly connected than external programs,
   2.371  thus information can be exchanged in a more flexible manner.
   2.372  Adding code to a project increases maintenance work.
   2.373  .\" XXX ref
   2.374 -Implementing complex functions in the project itself adds
   2.375 -a lot of code.
   2.376 -This should be avoided if possible.
   2.377 -Hence, the dependencies only change in their character,
   2.378 +As implementing complex functions in the project itself adds
   2.379 +a lot of code, this should be avoided if possible.
   2.380 +Thus, the dependencies only change in their character,
   2.381  not in their existence.
   2.382  In mmh, library dependencies on
   2.383  .Pn libsasl2
   2.384 @@ -291,40 +311,54 @@
   2.385  Users of MH should not have problems setting up an external MSA and MRA.
   2.386  Also, the popular MSAs and MRAs have large communities and a lot
   2.387  of available documentation.
   2.388 -Choices for MSAs range from full-featured MTAs such as
   2.389 -.\" XXX refs
   2.390 -.I Postfix ,
   2.391 -over mid-size MTAs such as
   2.392 -.I masqmail
   2.393 -and
   2.394 -.I dma ,
   2.395 -to small forwarders such as
   2.396 -.I ssmtp
   2.397 -and
   2.398 -.I nullmailer .
   2.399 -Choices for MRAs include
   2.400 -.I fetchmail ,
   2.401 -.I getmail ,
   2.402 -.I mpop
   2.403 -and
   2.404 -.I fdm .
   2.405 +
   2.406 +Choices for MSAs range from small forwarders such as
   2.407 +.[
   2.408 +ssmtp website
   2.409 +.]
   2.410 +and,
   2.411 +.[
   2.412 +nullmailer website
   2.413 +.]
   2.414 +over mid-size MTAs including
   2.415 +.[
   2.416 +masqmail website
   2.417 +.]
   2.418 +and,
   2.419 +.[
   2.420 +dma dragonfly mail agent website
   2.421 +.]
   2.422 +up to full-featured MTAs as for instance.
   2.423 +.[
   2.424 +postfix website
   2.425 +.]
   2.426 +MRAs are provided for example by
   2.427 +.[ [
   2.428 +fetchmail website
   2.429 +.]
   2.430 +.[
   2.431 +getmail website
   2.432 +.]
   2.433 +.[
   2.434 +mpop website
   2.435 +.]
   2.436 +.[
   2.437 +fdm website
   2.438 +.]].
   2.439  
   2.440  
   2.441  .H2 "Non-MUA Tools
   2.442  .P
   2.443 -One goal of mmh is to remove the tools that are not part of the MUA's task.
   2.444 -Furthermore, any tools that do not significantly improve the MUA's job
   2.445 -should be removed.
   2.446 -Loosely related and rarely used tools distract from the lean appearance.
   2.447 -They require maintenance work without adding much to the core task.
   2.448 -By removing these tools, the project shall become more streamlined
   2.449 -and focused.
   2.450 -In mmh, the following tools are not available anymore:
   2.451 +One goal of mmh is to remove the tools that do not significantly
   2.452 +contribute to the MUA's job.
   2.453 +Loosely related and rarely used tools distract from a lean appearance,
   2.454 +and require maintenance work without adding much to the core task.
   2.455 +By removing these tools, mmh became more streamlined and focused.
   2.456  .BU
   2.457  .Pn conflict
   2.458  was removed
   2.459  .Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9
   2.460 -because it is a mail system maintenance tool that is not MUA-related.
   2.461 +because it is a mail system maintenance tool and not MUA-related.
   2.462  It even checked
   2.463  .Fn /etc/passwd
   2.464  and
   2.465 @@ -343,7 +377,7 @@
   2.466  If users like to be informed of new mail, the shell's
   2.467  .Ev MAILPATH
   2.468  variable or graphical notifications are technically more appealing.
   2.469 -Writing directly to terminals is hardly ever desired today.
   2.470 +Writing to terminals directly is hardly ever desired today.
   2.471  If, though, one prefers this approach, the standard tool
   2.472  .Pn write
   2.473  can be used in a way similar to:
   2.474 @@ -375,7 +409,7 @@
   2.475  .VS
   2.476  ls -l /var/mail/meillo
   2.477  VE
   2.478 -It did distinguish between old and new mail, but
   2.479 +Yet, it distinguished between old and new mail, but
   2.480  these details can be retrieved with
   2.481  .Pn stat (1),
   2.482  too.
   2.483 @@ -391,10 +425,10 @@
   2.484  was removed
   2.485  .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
   2.486  because the tool was in conflict with the philosophy of MH.
   2.487 -It provided an interactive shell to access the features of MH,
   2.488 -but it was not just a shell tailored to the needs of mail handling.
   2.489 -Instead, it was one large program that had several MH tools built in.
   2.490 -This conflicts with the major feature of MH of being a tool chest.
   2.491 +It provided an interactive shell to access the features of MH.
   2.492 +However, it was not just a shell tailored to the needs of mail handling,
   2.493 +but one large program that had several MH tools built in.
   2.494 +This conflicted with the major feature of MH of being a tool chest.
   2.495  .Pn msh 's
   2.496  main use case had been accessing Bulletin Boards, which have ceased to
   2.497  be popular.
   2.498 @@ -416,11 +450,11 @@
   2.499  .Pn msgchk
   2.500  are assumed to be rarely used and can be implemented in different ways,
   2.501  why should one keep them?
   2.502 -Removing them streamlines mmh.
   2.503 +Removing them streamlined mmh.
   2.504  .Pn viamail 's
   2.505  use case is now partly obsolete and partly covered by
   2.506  .Pn forw ,
   2.507 -hence there's no reason to still maintain it.
   2.508 +hence there is no reason to still maintain it.
   2.509  .Pn conflict
   2.510  is not related to the mail client, and
   2.511  .Pn msh
   2.512 @@ -428,13 +462,10 @@
   2.513  These two tools might still be useful, but they should not be part of mmh.
   2.514  .P
   2.515  Finally, there is
   2.516 -.Pn slocal .
   2.517 -.Pn slocal
   2.518 -is an MDA and thus not directly MUA-related.
   2.519 -It should be removed from mmh, because including it conflicts with
   2.520 +.Pn slocal ,
   2.521 +which is an MDA and thus not directly MUA-related.
   2.522 +It should be removed from mmh because including it conflicts with
   2.523  the idea that mmh is an MUA only.
   2.524 -.Pn slocal
   2.525 -should rather become a separate project.
   2.526  However,
   2.527  .Pn slocal
   2.528  provides rule-based processing of messages, like filing them into
   2.529 @@ -456,10 +487,10 @@
   2.530  .I procmail .
   2.531  Then
   2.532  .Pn slocal
   2.533 -could be installed without the complete MH system.
   2.534 +could be installed without a complete MH system.
   2.535  Likewise, mmh users could decide to use
   2.536  .I procmail
   2.537 -without having a second, unused MDA,
   2.538 +without having a second, unused MDA, i.e.
   2.539  .Pn slocal ,
   2.540  installed.
   2.541  That appears to be conceptionally the best solution.
   2.542 @@ -469,8 +500,8 @@
   2.543  I defer the decision over
   2.544  .Pn slocal
   2.545  out of a need for deeper investigation.
   2.546 -In the meanwhile, it remains part of mmh.
   2.547 -However, its continued existence is not significant because
   2.548 +In the meanwhile, it remains part of mmh
   2.549 +as its continued existence is not significant;
   2.550  .Pn slocal
   2.551  is unrelated to the rest of the project.
   2.552  
   2.553 @@ -488,16 +519,16 @@
   2.554  .Pn mhl
   2.555  to have the files formatted.
   2.556  With MIME, this approach was not sufficient anymore.
   2.557 -MIME messages can consist of multiple parts. Some parts are not
   2.558 -directly displayable and text content might be encoded in
   2.559 -foreign charsets.
   2.560 +MIME messages can consist of multiple parts.
   2.561 +Some parts, like binary attachments or text content in foreign charsets,
   2.562 +are not directly displayable.
   2.563  .Pn show 's
   2.564  understanding of messages and
   2.565  .Pn mhl 's
   2.566  display capabilities could not cope with the task any longer.
   2.567  .P
   2.568  Instead of extending these tools, additional tools were written from
   2.569 -scratch and added to the MH tool chest.
   2.570 +scratch and were added to the MH tool chest.
   2.571  Doing so is encouraged by the tool chest approach.
   2.572  Modular design is a great advantage for extending a system,
   2.573  as new tools can be added without interfering with existing ones.
   2.574 @@ -505,7 +536,9 @@
   2.575  .Pn mhn .
   2.576  The command
   2.577  .Cl "mhn -show 42
   2.578 -would show the MIME message numbered 42.
   2.579 +had then shown the message number
   2.580 +.Fn 42 ,
   2.581 +interpreting MIME.
   2.582  With the 1.0 release of nmh in February 1999, Richard Coleman finished
   2.583  the split of
   2.584  .Pn mhn
   2.585 @@ -540,13 +573,13 @@
   2.586  .Pn mhshow ,
   2.587  whatever was more appropriate.
   2.588  .P
   2.589 -Having two similar tools for essentially the same task is redundant.
   2.590 -Usually, users would not distinguish between
   2.591 +Having two similar tools for basically the same task is redundancy.
   2.592 +Usually, users do not distinguish between
   2.593  .Pn show
   2.594  and
   2.595  .Pn mhshow
   2.596  in their daily mail reading.
   2.597 -Having two separate display programs was therefore mainly unnecessary
   2.598 +Having two separate display programs was therefore unnecessary
   2.599  from a user's point of view.
   2.600  Besides, the development of both programs needed to be in sync,
   2.601  to ensure that the programs behaved in a similar way,
   2.602 @@ -557,19 +590,19 @@
   2.603  MIME messages, although it is the other way round.
   2.604  As
   2.605  .Pn mhshow
   2.606 -had already been able to display non-MIME messages, it appeared natural
   2.607 +already had been able to display non-MIME messages, it appeared natural
   2.608  to drop
   2.609  .Pn show
   2.610  in favor of using
   2.611  .Pn mhshow
   2.612 -exclusively.
   2.613 -.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
   2.614 +exclusively
   2.615 +.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 .
   2.616  Removing
   2.617  .Pn show
   2.618 -is no loss in function, because functionally
   2.619 +is no loss in function, because
   2.620  .Pn mhshow
   2.621  covers it completely.
   2.622 -The old behavior of
   2.623 +Yet, the old behavior of
   2.624  .Pn show
   2.625  can still be emulated with the simple command line:
   2.626  .VS
   2.627 @@ -586,27 +619,24 @@
   2.628  It is clear that such a rename may confuse future developers when
   2.629  trying to understand the history.
   2.630  Nevertheless, I consider the convenience on the user's side,
   2.631 -to call
   2.632 -.Pn show
   2.633 -when they want a message to be displayed, to outweigh the inconvenience
   2.634 -on the developer's side when understanding the project history.
   2.635 +to outweigh the inconvenience for understanding the evolution
   2.636 +of the tools.
   2.637  .P
   2.638  To prepare for the transition,
   2.639  .Pn mhshow
   2.640  was reworked to behave more like
   2.641  .Pn show
   2.642 -first.
   2.643 -(cf. Sec.
   2.644 -.Cf mhshow )
   2.645 +first (cf. Sec.
   2.646 +.Cf mhshow ).
   2.647  .\" XXX code commits?
   2.648  Once the tools behaved more alike, the replacing appeared to be
   2.649  even more natural.
   2.650  Today, mmh's new
   2.651  .Pn show
   2.652 -has become the one single message display program once more,
   2.653 +has become the one single message display program once again,
   2.654  with the difference
   2.655  that today it handles MIME messages as well as non-MIME messages.
   2.656 -The outcome of the transition is one program less to maintain,
   2.657 +The outcomes of the transition are one program less to maintain,
   2.658  no second display program for users to deal with,
   2.659  and less system complexity.
   2.660  .P
   2.661 @@ -645,16 +675,16 @@
   2.662  Additionally, there is the cost of choice itself.
   2.663  The code complexity directly affects the developers.
   2.664  Less tested code affects both users and developers.
   2.665 -The problem of choice affects the users, for once by having to choose,
   2.666 +The problem of choice affects the users, for once by having to choose
   2.667  but also by more complex interfaces that require more documentation.
   2.668  Whenever options add few advantages but increase the complexity of the
   2.669  system, they should be considered for removal.
   2.670  I have reduced the number of project-specific configure options from 
   2.671 -fifteen to three.
   2.672 +15 to 3.
   2.673  
   2.674  .U3 "Mail Transfer Facilities
   2.675  .P
   2.676 -With the removal of the mail transfer facilities five configure
   2.677 +With the removal of the mail transfer facilities 5 configure
   2.678  options vanished:
   2.679  .P
   2.680  The switches
   2.681 @@ -664,7 +694,7 @@
   2.682  had activated the support for transfer encryption and authentication.
   2.683  .\" XXX cf
   2.684  .\" XXX gruende kurz wiederholen
   2.685 -This is not needed anymore.
   2.686 +They are not needed anymore.
   2.687  .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
   2.688  .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
   2.689  .P
   2.690 @@ -673,11 +703,11 @@
   2.691  The configure switch
   2.692  .Sw --enable-pop
   2.693  activated the message retrieval facility.
   2.694 -The code area that would be conditionally compiled in for TLS and SASL
   2.695 -support had been small.
   2.696 -The conditionally compiled code area for POP support had been much larger.
   2.697 -Whereas the code base changes would only slightly change on toggling
   2.698 -TLS or SASL support, it changed much on toggling POP support.
   2.699 +Whereas the code area that had been conditionally compiled in
   2.700 +for TLS and SASL support was small,
   2.701 +the conditionally compiled code area for POP support was much larger.
   2.702 +The code base had only changed slightly on toggling TLS or SASL
   2.703 +support but it had changed much on toggling POP support.
   2.704  The changes in the code base could hardly be overviewed.
   2.705  By having POP support togglable, a second code base had been created,
   2.706  one that needed to be tested.
   2.707 @@ -689,12 +719,12 @@
   2.708  .P
   2.709  Two other options only specified default configuration values:
   2.710  .Sw --with-mts
   2.711 -defined the default transport service.
   2.712 -.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
   2.713 +defined the default transport service
   2.714 +.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 .
   2.715  With
   2.716  .Sw --with-smtpservers
   2.717 -default SMTP servers could be specified.
   2.718 -.Ci 128545e06224233b7e91fc4c83f8830252fe16c9
   2.719 +default SMTP servers could be specified
   2.720 +.Ci 128545e06224233b7e91fc4c83f8830252fe16c9 .
   2.721  Both of them became irrelevant when the SMTP transport service was removed.
   2.722  .\" XXX code ref
   2.723  In mmh, all messages are handed over to
   2.724 @@ -712,38 +742,29 @@
   2.725  the configure option
   2.726  .Sw --with-hash-backup
   2.727  to change the default to the hash character `\f(CW#\fP'.
   2.728 -The choice was probably personal preference, because first, the
   2.729 -option was named
   2.730 -.Sw --with-backup-prefix.
   2.731 -and had the prefix character as argument.
   2.732 -But giving the hash character as argument caused too many problems
   2.733 -for Autoconf,
   2.734 -thus the option was limited to use the hash character as the default prefix.
   2.735 -This supports the assumption, that the choice for the hash was
   2.736 -personal preference only.
   2.737 -Being related or not, words that start with the hash character
   2.738 +This choice was probably personal preference, but,
   2.739 +being related or not, words that start with the hash character
   2.740  introduce a comment in the Unix shell.
   2.741  Thus, the command line
   2.742  .Cl "rm #13 #15
   2.743  calls
   2.744  .Pn rm
   2.745 -without arguments because the first hash character starts the comment
   2.746 +without arguments because the first hash character starts a comment
   2.747  that reaches until the end of the line.
   2.748  To delete the backup files,
   2.749  .Cl "rm ./#13 ./#15"
   2.750  needs to be used.
   2.751 -Using the hash as backup prefix can be seen as a precaution against
   2.752 -data loss.
   2.753 +Thus, using the hash as backup prefix may be seen as a precaution
   2.754 +against backup loss.
   2.755  .P
   2.756  First, I removed the configure option but added the profile entry
   2.757 -.Pe backup-prefix ,
   2.758 -which allows to specify an arbitrary string as backup prefix.
   2.759 -.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
   2.760 -Profile entries are the common method to change mmh's behavior.
   2.761 +.Pe Backup-Prefix ,
   2.762 +which allowed to specify an arbitrary string as backup prefix
   2.763 +.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086 .
   2.764  This change did not remove the choice but moved it to a location where
   2.765 -it suited better.
   2.766 +it suited better, in my eyes.
   2.767  .P
   2.768 -Eventually, however, the new trash folder concept
   2.769 +Eventually however, the new trash folder concept
   2.770  (cf. Sec.
   2.771  .Cf trash-folder )
   2.772  removed the need for the backup prefix completely.
   2.773 @@ -780,21 +801,22 @@
   2.774  posix 1992
   2.775  .]
   2.776  respectively.)
   2.777 -As a first step, these two tools were hard-coded as defaults.
   2.778 -.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
   2.779 +As a first step, these two tools were hard-coded as defaults
   2.780 +.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f .
   2.781  Not changed were the
   2.782  .Pe editor
   2.783  and
   2.784  .Pe moreproc
   2.785  profile entries, which allowed the user to override the system defaults.
   2.786 -Later, the concept was reworked to respect the standard environment
   2.787 -variables
   2.788 +Later, the concept was reworked again to respect the standard
   2.789 +environment variables
   2.790  .Ev VISUAL
   2.791  and
   2.792  .Ev PAGER
   2.793  if they are set.
   2.794  Today, mmh determines the editor to use in the following order,
   2.795 -taking the first available and non-empty item:
   2.796 +taking the first available and non-empty item
   2.797 +.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b :
   2.798  .LI 1
   2.799  Environment variable
   2.800  .Ev MMHEDITOR
   2.801 @@ -811,10 +833,8 @@
   2.802  Command
   2.803  .Pn vi .
   2.804  .LP
   2.805 -.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
   2.806 -.P
   2.807 -The pager to use is determined in a similar order,
   2.808 -also taking the first available and non-empty item:
   2.809 +The pager to use is determined in a similar order
   2.810 +.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e :
   2.811  .LI 1
   2.812  Environment variable
   2.813  .Ev MMHPAGER
   2.814 @@ -830,99 +850,98 @@
   2.815  Command
   2.816  .Pn more .
   2.817  .LP
   2.818 -.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
   2.819 -.P
   2.820  By respecting the
   2.821  .Ev VISUAL /\c
   2.822  .Ev EDITOR
   2.823  and
   2.824  .Ev PAGER
   2.825  environment variables,
   2.826 -the new behavior confirms better to the common style on Unix systems.
   2.827 -Additionally, the new approach is more uniform and clearer to users.
   2.828 +the new behavior complies with the common style on Unix systems.
   2.829 +It is more uniform and clearer for users.
   2.830  
   2.831  
   2.832  .U3 "ndbm
   2.833  .P
   2.834  .Pn slocal
   2.835 -used to depend on
   2.836 -.I ndbm ,
   2.837 -a database library.
   2.838 -The database is used to store the `\fLMessage-ID\fP's of all
   2.839 -messages delivered.
   2.840 -This enables
   2.841 +used to depend on the database library
   2.842 +.I ndbm .
   2.843 +The database is used to store the
   2.844 +.Hd Message-ID
   2.845 +header field values of all messages delivered.
   2.846 +This enabled
   2.847  .Pn slocal
   2.848  to suppress delivering the same message to the same user twice.
   2.849 -(This features was enabled by the
   2.850 +This features was enabled by the
   2.851  .Sw -suppressdup
   2.852 -switch.)
   2.853 +switch.
   2.854  .P
   2.855 -A variety of versions of the database library exist.
   2.856 +As a variety of versions of the database library exist,
   2.857  .[
   2.858  wolter unix incompat notes dbm
   2.859  .]
   2.860 -Complicated autoconf code was needed to detect them correctly.
   2.861 +complicated autoconf code was needed to detect them correctly.
   2.862  Furthermore, the configure switches
   2.863  .Sw --with-ndbm=ARG
   2.864  and
   2.865  .Sw --with-ndbmheader=ARG
   2.866  were added to help with difficult setups that would
   2.867 -not be detected automatically or correctly.
   2.868 +not be detected automatically or not correctly.
   2.869  .P
   2.870  By removing the suppress duplicates feature of
   2.871  .Pn slocal ,
   2.872  the dependency on
   2.873  .I ndbm
   2.874 -vanished and 120 lines of complex autoconf code could be saved.
   2.875 -.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
   2.876 -The change removed functionality too, but that is minor to the
   2.877 -improvement by dropping the dependency and the complex autoconf code.
   2.878 +vanished and 120 lines of complex autoconf code could be saved
   2.879 +.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf .
   2.880 +The change removed functionality but that is considered minor to the
   2.881 +improvement of dropping the dependency and the complex autoconf code.
   2.882  .\" XXX argument: slocal ist sowieso nicht teil vom mmh kern
   2.883  
   2.884 -.U3 "mh-e Support
   2.885 +.U3 "MH-E Support
   2.886  .P
   2.887  The configure option
   2.888  .Sw --disable-mhe
   2.889 -was removed when the mh-e support was reworked. 
   2.890 -Mh-e is the Emacs front-end to MH.
   2.891 +was removed when the MH-E support was reworked. 
   2.892 +MH-E is the Emacs front-end to MH.
   2.893 +.[
   2.894 +mh-e emacs website
   2.895 +.]
   2.896  It requires MH to provide minor additional functions.
   2.897  The
   2.898  .Sw --disable-mhe
   2.899 -configure option could switch these extensions off.
   2.900 -After removing the support for old versions of mh-e,
   2.901 +configure option had switched off these extensions.
   2.902 +After removing the support for old versions of MH-E,
   2.903  only the
   2.904  .Sw -build
   2.905  switches of
   2.906  .Pn forw
   2.907  and
   2.908  .Pn repl
   2.909 -are left to be mh-e extensions.
   2.910 +are left to be MH-E extensions.
   2.911  They are now always built in because they add little code and complexity.
   2.912  In consequence, the
   2.913  .Sw --disable-mhe
   2.914  configure option was removed
   2.915 -.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
   2.916 -Removing the option removed a second code setup that would have
   2.917 -needed to be tested.
   2.918 -.\" XXX datum?
   2.919 -This change was first accomplished in nmh and thereafter merged into mmh.
   2.920 -.P
   2.921 -The interface changes in mmh require mh-e to be adjusted in order
   2.922 -to be able to use mmh as back-end.
   2.923 -This will require minor changes to mh-e, but removing the
   2.924 -.Sw -build
   2.925 -switches would require more rework.
   2.926 +.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643 .
   2.927 +Dropping the option also removed a variant of the code base
   2.928 +that would have needed to be tested.
   2.929 +This change was undertaken in January 2012 in nmh and
   2.930 +thereafter merged into mmh.
   2.931 +
   2.932  
   2.933  .U3 "Masquerading
   2.934  .P
   2.935  The configure option
   2.936  .Sw --enable-masquerade
   2.937  could take up to three arguments:
   2.938 -`draft_from', `mmailid', and `username_extension'.
   2.939 +.Ar draft_from ,
   2.940 +.Ar mmailid ,
   2.941 +and
   2.942 +.Ar username_extension .
   2.943  They activated different types of address masquerading.
   2.944  All of them were implemented in the SMTP-speaking
   2.945  .Pn post
   2.946 -command, which provided an MSA.
   2.947 +command.
   2.948  Address masquerading is an MTA's task and mmh does not cover
   2.949  this field anymore.
   2.950  Hence, true masquerading needs to be implemented in the external MTA.
   2.951 @@ -935,8 +954,10 @@
   2.952  .I username
   2.953  to
   2.954  .I fakeusername
   2.955 -mapping, based on the password file's GECOS field.
   2.956 -The man page
   2.957 +mapping, based on the
   2.958 +.Fn passwd 's
   2.959 +GECOS field.
   2.960 +Nmh's man page
   2.961  .Mp mh-tailor (5)
   2.962  described the use case as being the following:
   2.963  .QS
   2.964 @@ -965,17 +986,24 @@
   2.965  environment variable, to it.
   2.966  This provided support for the
   2.967  .I user-extension
   2.968 -feature of qmail and the similar
   2.969 +feature of qmail
   2.970 +.[ [
   2.971 +sill qmail handbook
   2.972 +.], p. 141]
   2.973 +and the similar
   2.974  .I "plussed user
   2.975 -processing of sendmail.
   2.976 -The decision to remove this username_extension masquerading was
   2.977 -motivated by the fact that
   2.978 +processing of Sendmail.
   2.979 +.[ [
   2.980 +sendmail costales
   2.981 +.], p. 476]
   2.982 +The decision to remove this username_extension masquerading
   2.983 +was motivated by the fact that
   2.984  .Pn spost
   2.985 -had not supported it already.
   2.986 -.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
   2.987 -Username extensions are possible in mmh, but less convenient to use.
   2.988 +had not supported it yet.
   2.989 +Username extensions can be used in mmh, but less convenient.
   2.990  .\" XXX covered by next paragraph
   2.991  .\" XXX format file %(getenv USERNAME_EXTENSION)
   2.992 +.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
   2.993  .P
   2.994  The
   2.995  .I draft_from
   2.996 @@ -985,20 +1013,19 @@
   2.997  .Hd From
   2.998  header field as SMTP envelope sender.
   2.999  Sender addresses could be replaced completely.
  2.1000 -.Ci b14ea6073f77b4359aaf3fddd0e105989db9
  2.1001  Mmh offers a kind of masquerading similar in effect, but
  2.1002  with technical differences.
  2.1003  As mmh does not transfer messages itself, the local MTA has final control
  2.1004 -over the sender's address. Any masquerading mmh introduces may be reverted
  2.1005 -by the MTA.
  2.1006 +over the sender's address.
  2.1007 +Any masquerading mmh introduces may be reverted by the MTA.
  2.1008  In times of pedantic spam checking, an MTA will take care to use
  2.1009  sensible envelope sender addresses to keep its own reputation up.
  2.1010  Nonetheless, the MUA can set the
  2.1011  .Hd From
  2.1012 -header field and thereby propose
  2.1013 -a sender address to the MTA.
  2.1014 +header field and thereby propose a sender address to the MTA.
  2.1015  The MTA may then decide to take that one or generate the canonical sender
  2.1016  address for use as envelope sender address.
  2.1017 +.Ci b14ea6073f77b4359aaf3fddd0e105989db9
  2.1018  .P
  2.1019  In mmh, the MTA will always extract the recipient and sender from the
  2.1020  message header (\c
  2.1021 @@ -1015,12 +1042,13 @@
  2.1022  Two configure options remain in mmh.
  2.1023  One is the locking method to use:
  2.1024  .Sw --with-locking=[dot|fcntl|flock|lockf] .
  2.1025 -The idea of removing all methods except the portable dot locking
  2.1026 +The idea of removing all methods except the portable
  2.1027 +.I "dot locking
  2.1028  and having that one as the default is appealing, but this change
  2.1029  requires deeper technical investigation into the topic.
  2.1030  The other option,
  2.1031  .Sw --enable-debug ,
  2.1032 -compiles the programs with debugging symbols and does not strip them.
  2.1033 +compiles the programs with debugging symbols.
  2.1034  This option is likely to stay.
  2.1035  
  2.1036  
  2.1037 @@ -1028,11 +1056,14 @@
  2.1038  
  2.1039  .H2 "Command Line Switches
  2.1040  .P
  2.1041 -The command line switches of MH tools are similar to the X Window style.
  2.1042 +The command line switches of MH tools follow a style similar to
  2.1043 +the X Window System style.
  2.1044  .\" XXX ref
  2.1045 -They consist of a single dash (`\fL-\fP') followed by a word.
  2.1046 +The switches consist of a single dash (`\fL-\fP') followed by a word.
  2.1047 +For example
  2.1048 +.Cl -truncate .
  2.1049  To ease typing, the word can be abbreviated, given the remaining
  2.1050 -prefix remains unambiguous.
  2.1051 +prefix is unambiguous.
  2.1052  If no other switch starts with the letter `t', then any of
  2.1053  .Cl "-truncate" ,
  2.1054  .Cl "-trunc" ,
  2.1055 @@ -1060,16 +1091,15 @@
  2.1056  Switches change the behavior of programs.
  2.1057  Programs that do one thing in one way require no switches.
  2.1058  In most cases, doing something in exactly one way is too limiting.
  2.1059 -If there is basically one task to accomplish, but it should be done
  2.1060 -in various ways, switches are a good approach to alter the behavior
  2.1061 -of a program.
  2.1062 +If one task should be accomplished in various ways,
  2.1063 +switches are a good approach to alter the behavior of a program.
  2.1064  Changing the behavior of programs provides flexibility and customization
  2.1065 -to users, but at the same time it complicates the code, documentation and
  2.1066 -usage of the program.
  2.1067 +to users, but at the same time it complicates the code,
  2.1068 +the documentation, and the usage of the program.
  2.1069  .\" XXX: Ref
  2.1070  Therefore, the number of switches should be kept small.
  2.1071 -A small set of well-chosen switches does no harm.
  2.1072 -But usually, the number of switches increases over time.
  2.1073 +A small set of well-chosen switches is best.
  2.1074 +Usually, the number of switches increases over time.
  2.1075  Already in 1985, Rose and Romine have identified this as a major
  2.1076  problem of MH:
  2.1077  .[ [
  2.1078 @@ -1087,11 +1117,11 @@
  2.1079  suffers mightily from this.
  2.1080  .QE
  2.1081  .P
  2.1082 -Being reluctant to adding new switches \(en or `options',
  2.1083 -as Rose and Romine call them \(en is one part of a counter-action,
  2.1084 +Being reluctant to adding new switches (or \fIoptions\fP,
  2.1085 +as Rose and Romine call them) is one part of a counter-action,
  2.1086  the other part is removing hardly used switches.
  2.1087 -Nmh's tools had lots of switches already implemented,
  2.1088 -hence, cleaning up by removing some of them was the more important part
  2.1089 +Nmh's tools have lots of switches already implemented.
  2.1090 +Hence, cleaning up by removing some of them was the more important part
  2.1091  of the counter-action.
  2.1092  Removing existing functionality is always difficult because it
  2.1093  breaks programs that use these functions.
  2.1094 @@ -1105,7 +1135,10 @@
  2.1095  Rose and Romine added in a footnote,
  2.1096  ``[...]
  2.1097  .Pn send
  2.1098 -will no doubt acquire an endless number of switches in the years to come.''
  2.1099 +will no doubt acquire an endless number of switches in the years to come''
  2.1100 +.[ [
  2.1101 +rose romine real work
  2.1102 +.], p. 12].
  2.1103  Although clearly humorous, the comment points to the nature of the problem.
  2.1104  Refusing to add any new switches would encounter the problem at its root,
  2.1105  but this is not practical.
  2.1106 @@ -1123,20 +1156,21 @@
  2.1107  At the time of writing, no more than 4 visible switches and 1 hidden switch
  2.1108  have remained in mmh's
  2.1109  .Pn send .
  2.1110 -These numbers include two generic switches,
  2.1111 +These numbers include the two generic switches,
  2.1112  .Sw -help
  2.1113  and
  2.1114  .Sw -Version .
  2.1115 +.P
  2.1116  Hidden switches are ones not documented.
  2.1117  In mmh, 12 tools have hidden switches.
  2.1118  9 of them are
  2.1119  .Sw -debug
  2.1120  switches, the other 6 provide special interfaces for internal use.
  2.1121  .P
  2.1122 -The figure displays the number of switches for each of the tools
  2.1123 +The following figure displays the number of switches for each of the tools
  2.1124  that is available in both nmh and mmh.
  2.1125  The tools are sorted by the number of switches they had in nmh.
  2.1126 -Visible and hidden switches were counted,
  2.1127 +Both visible and hidden switches were counted,
  2.1128  but not the generic help and version switches.
  2.1129  Whereas in the beginning of the project, the average tool had 11 switches,
  2.1130  now it has no more than 5 \(en only half as many.
  2.1131 @@ -1158,39 +1192,37 @@
  2.1132  I looked through the
  2.1133  .Mp mh-chart (7)
  2.1134  man page to identify the tools with apparently too many switches.
  2.1135 -Then considering the value of each of the switches by examining
  2.1136 -the tool's man page and source code, aided by recherche and testing.
  2.1137 -This way, the removal of functions was suggested by the aim to reduce
  2.1138 -the number of switches per command.
  2.1139 +Then I considered the benefit of each switch by examining
  2.1140 +the tool's man page and source code, aided by literature research
  2.1141 +and testing.
  2.1142  
  2.1143  
  2.1144  .U3 "Draft Folder Facility
  2.1145  .P
  2.1146  A change early in the project was the complete transition from
  2.1147 -the single draft message to the draft folder facility.
  2.1148 -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
  2.1149 +the single draft message to the draft folder facility
  2.1150 +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
  2.1151  .\" XXX ref to section ...
  2.1152  The draft folder facility was introduced in the mid-eighties, when
  2.1153  Rose and Romine called it a ``relatively new feature''.
  2.1154  .[
  2.1155  rose romine real work
  2.1156  .]
  2.1157 -Since then, the facility had existed but was inactive by default.
  2.1158 -The default activation and the related rework of the tools made it
  2.1159 -possible to remove the
  2.1160 +Since then, the facility was included, inactive by default.
  2.1161 +By making it permanently active and by related rework of the tools, the
  2.1162  .Sw -[no]draftfolder ,
  2.1163  and
  2.1164  .Sw -draftmessage
  2.1165 -switches from
  2.1166 +switches could be removed from
  2.1167  .Pn comp ,
  2.1168  .Pn repl ,
  2.1169  .Pn forw ,
  2.1170  .Pn dist ,
  2.1171  .Pn whatnow ,
  2.1172  and
  2.1173 -.Pn send .
  2.1174 -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
  2.1175 -The only flexibility removed with this change is having multiple
  2.1176 +.Pn send
  2.1177 +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
  2.1178 +The only flexibility lost with this change is having multiple
  2.1179  draft folders within one profile.
  2.1180  I consider this a theoretical problem only.
  2.1181  At the same time, the
  2.1182 @@ -1202,9 +1234,9 @@
  2.1183  .Pn send
  2.1184  was removed.
  2.1185  The special treatment of \fIthe\fP draft message became irrelevant after
  2.1186 -the rework of the draft system.
  2.1187 +the rework of the draft system
  2.1188  (cf. Sec.
  2.1189 -.Cf draft-folder )
  2.1190 +.Cf draft-folder ).
  2.1191  Furthermore,
  2.1192  .Pn comp
  2.1193  no longer needs a
  2.1194 @@ -1220,14 +1252,15 @@
  2.1195  had the switches
  2.1196  .Sw -[no]inplace
  2.1197  to either annotate the message in place and thus preserve hard links,
  2.1198 -or annotate a copy to replace the original message, breaking hard links.
  2.1199 +or annotate a copy to replace the original message.
  2.1200 +The latter approach broke hard links.
  2.1201  Following the assumption that linked messages should truly be the
  2.1202 -same message, and annotating it should not break the link, the
  2.1203 +same message and annotating it should not break the link, the
  2.1204  .Sw -[no]inplace
  2.1205  switches were removed and the previous default
  2.1206  .Sw -inplace
  2.1207 -was made the only behavior.
  2.1208 -.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
  2.1209 +was made the definitive behavior
  2.1210 +.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0 .
  2.1211  The
  2.1212  .Sw -[no]inplace
  2.1213  switches of
  2.1214 @@ -1235,13 +1268,13 @@
  2.1215  .Pn forw ,
  2.1216  and
  2.1217  .Pn dist
  2.1218 -could be removed, too, as they were simply passed through to
  2.1219 +could be removed, as well, as they were simply passed through to
  2.1220  .Pn anno .
  2.1221  .P
  2.1222  .Pn burst
  2.1223  also had
  2.1224  .Sw -[no]inplace
  2.1225 -switches, but with different meaning.
  2.1226 +switches, but with a different meaning.
  2.1227  With
  2.1228  .Sw -inplace ,
  2.1229  the digest had been replaced by the table of contents (i.e. the
  2.1230 @@ -1249,7 +1282,7 @@
  2.1231  after this message, renumbering all following messages.
  2.1232  Also, any trailing text of the digest was lost, though,
  2.1233  in practice, it usually consists of an end-of-digest marker only.
  2.1234 -Nontheless, this behavior appeared less elegant than the
  2.1235 +Nonetheless, this behavior appeared less elegant than the
  2.1236  .Sw -noinplace
  2.1237  behavior, which already had been the default.
  2.1238  Nmh's
  2.1239 @@ -1284,68 +1317,64 @@
  2.1240  In consequence, the following two lines equaled:
  2.1241  .VS
  2.1242  scan -form scan.mailx
  2.1243 -scan -format "`cat .../scan.mailx`"
  2.1244 +scan -format "`cat /path/to/scan.mailx`"
  2.1245  VE
  2.1246  The
  2.1247  .Sw -format
  2.1248  switches were dropped in favor for extending the
  2.1249  .Sw -form
  2.1250 -switches.
  2.1251 -.Ci f51956be123db66b00138f80464d06f030dbb88d
  2.1252 -If their argument starts with an equal sign (`='),
  2.1253 +switches
  2.1254 +.Ci f51956be123db66b00138f80464d06f030dbb88d .
  2.1255 +If their argument starts with an equal sign (`\fL=\fP'),
  2.1256  then the rest of the argument is taken as a format string,
  2.1257  otherwise the arguments is treated as the name of a format file.
  2.1258  Thus, now the following two lines equal:
  2.1259  .VS
  2.1260  scan -form scan.mailx
  2.1261 -scan -form "=`cat .../scan.mailx`"
  2.1262 +scan -form "=`cat /path/to/scan.mailx`"
  2.1263  VE
  2.1264  This rework removed the prefix collision between
  2.1265  .Sw -form
  2.1266  and
  2.1267  .Sw -format .
  2.1268 -Now, typing
  2.1269 -.Sw -fo
  2.1270 -suffices to specify form or format string.
  2.1271 +Typing `\fL-fo\fP' is sufficient to specify form file or format string.
  2.1272  .P
  2.1273  The different meaning of
  2.1274  .Sw -format
  2.1275  for
  2.1276 +.Pn forw
  2.1277 +and
  2.1278  .Pn repl
  2.1279 -and
  2.1280 -.Pn forw
  2.1281  was removed in mmh.
  2.1282  .Pn forw
  2.1283  was completely switched to MIME-type forwarding, thus removing the
  2.1284 -.Sw -[no]format .
  2.1285 -.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
  2.1286 +.Sw -[no]format
  2.1287 +.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 .
  2.1288  For
  2.1289  .Pn repl ,
  2.1290  the
  2.1291  .Sw -[no]format
  2.1292  switches were reworked to
  2.1293  .Sw -[no]filter
  2.1294 -switches.
  2.1295 -.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
  2.1296 +switches
  2.1297 +.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 .
  2.1298  The
  2.1299  .Sw -format
  2.1300  switches of
  2.1301  .Pn send
  2.1302  and
  2.1303  .Pn post ,
  2.1304 -which had a third meaning,
  2.1305 -were removed likewise.
  2.1306 -.Ci f3cb7cde0e6f10451b6848678d95860d512224b9
  2.1307 +which had a third meaning, were removed likewise
  2.1308 +.Ci f3cb7cde0e6f10451b6848678d95860d512224b9 .
  2.1309  Eventually, the ambiguity of the
  2.1310  .Sw -format
  2.1311 -switches was resolved by not anymore having any such switch in mmh.
  2.1312 +switches is resolved by not having such switches anymore in mmh.
  2.1313  
  2.1314  
  2.1315  .U3 "MIME Tools
  2.1316  .P
  2.1317 -The MIME tools, which were once part of
  2.1318 +The MIME tools, which once were part of
  2.1319  .Pn mhn
  2.1320 -.\" XXX
  2.1321  (whatever that stood for),
  2.1322  had several switches that added little practical value to the programs.
  2.1323  The
  2.1324 @@ -1354,22 +1383,22 @@
  2.1325  .Pn mhbuild
  2.1326  and
  2.1327  .Pn mhlist
  2.1328 -were removed, doing real size calculations always now
  2.1329 -.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
  2.1330 -as nmh's
  2.1331 +were removed
  2.1332 +.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c .
  2.1333 +Real size calculations are done always now because nmh's
  2.1334  .Mp mhbuild (1)
  2.1335 -man page states
  2.1336 -``This provides an accurate count at the expense of a small delay.''
  2.1337 -This small delay is not noticable on modern systems.
  2.1338 +man page states that
  2.1339 +``This provides an accurate count at the expense of a small delay''
  2.1340 +with the small delay not being noticable on modern systems.
  2.1341  .P
  2.1342  The
  2.1343  .Sw -[no]check
  2.1344  switches were removed together with the support for
  2.1345  .Hd Content-MD5
  2.1346 -header fields [RFC\|1864].
  2.1347 -.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
  2.1348 +header fields [RFC\|1864]
  2.1349  (cf. Sec.
  2.1350  .Cf content-md5 )
  2.1351 +.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda .
  2.1352  .P
  2.1353  The
  2.1354  .Sw -[no]ebcdicsafe
  2.1355 @@ -1377,16 +1406,16 @@
  2.1356  .Sw -[no]rfc934mode
  2.1357  switches of
  2.1358  .Pn mhbuild
  2.1359 -were removed because they are considered obsolete.
  2.1360 +were removed because they are considered obsolete
  2.1361  .Ci 01a3480928da485b4d6109d36d751dfa71799d58
  2.1362 -.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88
  2.1363 +.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88 .
  2.1364  .P
  2.1365  Content caching of external MIME parts, activated with the
  2.1366  .Sw -rcache
  2.1367  and
  2.1368  .Sw -wcache
  2.1369 -switches was completely removed.
  2.1370 -.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
  2.1371 +switches was completely removed
  2.1372 +.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269 .
  2.1373  External MIME parts are rare today, having a caching facility
  2.1374  for them appears to be unnecessary.
  2.1375  .P
  2.1376 @@ -1396,9 +1425,9 @@
  2.1377  Therefore,
  2.1378  .Pn mhl
  2.1379  could be simplified to a large extend, reducing the number of its
  2.1380 -switches from 21 to 6.
  2.1381 +switches from 21 to 6
  2.1382  .Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6
  2.1383 -.Ci 0e46503be3c855bddaeae3843e1b659279c35d70
  2.1384 +.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 .
  2.1385  
  2.1386  
  2.1387  
  2.1388 @@ -1410,31 +1439,31 @@
  2.1389  displaying the header line makes little sense.
  2.1390  Hence, the
  2.1391  .Sw -[no]header
  2.1392 -switch was removed and headers are never printed.
  2.1393 -.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
  2.1394 +switch was removed and headers are never printed
  2.1395 +.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7 .
  2.1396  .P
  2.1397  In
  2.1398  .Pn mhlist ,
  2.1399  the
  2.1400  .Sw -[no]header
  2.1401 -switches were removed, too.
  2.1402 -.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f
  2.1403 -But in this case headers are always printed,
  2.1404 -because the output is not self-explaining.
  2.1405 +switches were removed, as well
  2.1406 +.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f .
  2.1407 +In this case, the headers are printed always because the output
  2.1408 +is not self-explaining.
  2.1409  .P
  2.1410  .Pn scan
  2.1411  also had
  2.1412  .Sw -[no]header
  2.1413  switches.
  2.1414 -Printing the header had been sensible until the introduction of
  2.1415 -format strings made it impossible to display the column headings.
  2.1416 +Printing this header had been sensible until the introduction of
  2.1417 +format strings made it impossible to display column headings.
  2.1418  Only the folder name and the current date remained to be printed.
  2.1419 -As this information can be perfectly retrieved by
  2.1420 +As this information can be perfectly generated with
  2.1421  .Pn folder
  2.1422  and
  2.1423  .Pn date ,
  2.1424 -consequently, the switches were removed.
  2.1425 -.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e
  2.1426 +the switches were removed
  2.1427 +.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e .
  2.1428  .P
  2.1429  By removing all
  2.1430  .Sw -header
  2.1431 @@ -1459,20 +1488,20 @@
  2.1432  .Pn dist ,
  2.1433  and
  2.1434  .Pn whatnow
  2.1435 -was removed, but it can now be replaced by specifying
  2.1436 +was removed and replaced by specifying
  2.1437  .Sw -editor
  2.1438 -with an empty argument.
  2.1439 -.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
  2.1440 +with an empty argument
  2.1441 +.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9 .
  2.1442  (Specifying
  2.1443  .Cl "-editor /bin/true
  2.1444 -is nearly the same, only differing by the previous editor being set.)
  2.1445 +is nearly the same. It differs only in setting the previous editor.)
  2.1446  .P
  2.1447  The more important change is the removal of the
  2.1448  .Sw -nowhatnowproc
  2.1449 -switch.
  2.1450 -.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622
  2.1451 -This switch had introduced an awkward behavior, as explained in nmh's
  2.1452 -man page for
  2.1453 +switch
  2.1454 +.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622 .
  2.1455 +This switch had once introduced an awkward behavior,
  2.1456 +as explained in nmh's man page for
  2.1457  .Mp comp (1):
  2.1458  .QS
  2.1459  The
  2.1460 @@ -1499,15 +1528,12 @@
  2.1461  .P
  2.1462  Effectively, the
  2.1463  .Sw -nowhatnowproc
  2.1464 -switch creates only a draft message.
  2.1465 +switch caused only only a draft message to be created.
  2.1466  As
  2.1467  .Cl "-whatnowproc /bin/true
  2.1468 -causes the same behavior, the
  2.1469 +does the same, the
  2.1470  .Sw -nowhatnowproc
  2.1471  switch was removed for being redundant.
  2.1472 -Likely, the
  2.1473 -.Sw -nowhatnowproc
  2.1474 -switch was intended to be used by front-ends.
  2.1475  
  2.1476  
  2.1477  
  2.1478 @@ -1522,16 +1548,17 @@
  2.1479  and
  2.1480  .Sw -mmdf
  2.1481  switches.
  2.1482 +The behavior of
  2.1483  .Sw -mbox
  2.1484 -is the sole behavior now.
  2.1485 -.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
  2.1486 +is the sole behavior now
  2.1487 +.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 .
  2.1488  Further rework in both tools made the
  2.1489  .Sw -file
  2.1490 -switch unnecessary.
  2.1491 -.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e
  2.1492 +switch unnecessary
  2.1493 +.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e .
  2.1494  
  2.1495  .BU
  2.1496 -Mmh's tools will no longer clear the screen (\c
  2.1497 +Mmh's tools do no longer clear the screen (\c
  2.1498  .Pn scan 's
  2.1499  and
  2.1500  .Pn mhl 's
  2.1501 @@ -1539,12 +1566,12 @@
  2.1502  switches
  2.1503  .Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270
  2.1504  .Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ).
  2.1505 -Neither will
  2.1506 +Neither does
  2.1507  .Pn mhl
  2.1508  ring the bell (\c
  2.1509  .Sw -[no]bell
  2.1510  .Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
  2.1511 -nor page the output itself (\c
  2.1512 +nor does it page the output itself (\c
  2.1513  .Sw -length
  2.1514  .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
  2.1515  .\" XXX Ref
  2.1516 @@ -1554,16 +1581,16 @@
  2.1517  .Pn mhl
  2.1518  and
  2.1519  .Pn show /\c
  2.1520 -.Pn mhshow .
  2.1521 -.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a
  2.1522 +.Pn mhshow
  2.1523 +.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a .
  2.1524  
  2.1525  .BU
  2.1526  In order to avoid prefix collisions among switch names, the
  2.1527  .Sw -version
  2.1528  switch was renamed to
  2.1529  .Sw -Version
  2.1530 -(with capital `V').
  2.1531 -.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
  2.1532 +(with capital `V')
  2.1533 +.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a .
  2.1534  Every program has the
  2.1535  .Sw -version
  2.1536  switch but its first three letters collided with the
  2.1537 @@ -1604,61 +1631,17 @@
  2.1538  switches of
  2.1539  .Pn scan
  2.1540  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
  2.1541 -is a bug fix, supported by the comments
  2.1542 +is a bug fix.
  2.1543 +This is supported by the comments
  2.1544  ``\-[no]reverse under #ifdef BERK (I really HATE this)''
  2.1545  by Rose and
  2.1546  ``Lists messages in reverse order with the `\-reverse' switch.
  2.1547 -This should be considered a bug.'' by Romine in the documentation.
  2.1548 -.\" XXX Ref: welche datei genau.
  2.1549 -The question remains why neither Rose and Romine had fixed this
  2.1550 -bug in the eighties when they wrote these comments nor has anyone
  2.1551 -thereafter.
  2.1552 +This should be considered a bug'' by Romine in the changelogs.
  2.1553 +The question remains why neither Rose nor Romine have fixed this
  2.1554 +bug in the eighties when they wrote these comments.
  2.1555  
  2.1556  
  2.1557 -.ig
  2.1558  
  2.1559 -forw: [no]dashstuffing(mhl)
  2.1560 -
  2.1561 -mhshow: [no]pause [no]serialonly
  2.1562 -
  2.1563 -mhmail: resent queued
  2.1564 -inc: snoop, (pop)
  2.1565 -
  2.1566 -mhl: [no]faceproc folder sleep
  2.1567 -	[no]dashstuffing(forw) digest list volume number issue number
  2.1568 -
  2.1569 -prompter: [no]doteof
  2.1570 -
  2.1571 -refile: [no]preserve [no]unlink [no]rmmproc
  2.1572 -
  2.1573 -send: [no]forward [no]mime [no]msgid
  2.1574 -	[no]push split [no]unique (sasl) width snoop [no]dashstuffing
  2.1575 -	attach attachformat
  2.1576 -whatnow: (noedit) attach
  2.1577 -
  2.1578 -slocal: [no]suppressdups
  2.1579 -
  2.1580 -spost: [no]filter [no]backup width [no]push idanno
  2.1581 -	[no]check(whom) whom(whom)
  2.1582 -
  2.1583 -whom: ???
  2.1584 -
  2.1585 -..
  2.1586 -
  2.1587 -
  2.1588 -.ig
  2.1589 -
  2.1590 -.P
  2.1591 -In the best case, all switches are unambiguous on the first character,
  2.1592 -or on the three-letter prefix for the `no' variants.
  2.1593 -Reducing switch prefix collisions, shortens the necessary prefix length
  2.1594 -the user must type.
  2.1595 -Having less switches helps best.
  2.1596 -
  2.1597 -..
  2.1598 -
  2.1599 -
  2.1600 -.\" XXX: whatnow prompt commands
  2.1601  
  2.1602  
  2.1603  
  2.1604 @@ -1670,7 +1653,7 @@
  2.1605  increasingly extended.
  2.1606  New features entered the project and became alternatives to the
  2.1607  existing behavior.
  2.1608 -Relics from several decades have gathered in the code base,
  2.1609 +Relics from several decades have gathered in the code base
  2.1610  but seldom obsolete features were dropped.
  2.1611  This section describes the removing of old code
  2.1612  and the modernizing of the default setup.
  2.1613 @@ -1681,15 +1664,14 @@
  2.1614  
  2.1615  .H2 "Code Relics
  2.1616  .P
  2.1617 -My position regarding the removal of obsolete functions of mmh,
  2.1618 -.\" XXX ``in order to remove old code,''
  2.1619 +My position regarding the removal of obsolete code
  2.1620  is much more revolutional than the nmh community appreciates.
  2.1621 -Working on an experimental version, I was quickly able to drop
  2.1622 -functionality I considered ancient.
  2.1623 +Working on an experimental version, I was able to quickly drop
  2.1624 +functionality that I considered ancient.
  2.1625  The need for consensus with peers would have slowed this process down.
  2.1626  Without the need to justify my decisions, I was able to rush forward.
  2.1627 +.P
  2.1628  In December 2011, Paul Vixie motivated the nmh developers to just
  2.1629 -.\" XXX ugs
  2.1630  do the work:
  2.1631  .[
  2.1632  paul vixie edginess nmh-workers
  2.1633 @@ -1724,7 +1706,7 @@
  2.1634  .\" XXX ``exp. work'' schon oft gesagt
  2.1635  
  2.1636  
  2.1637 -.U3 "Forking
  2.1638 +.U3 "Process Forking
  2.1639  .P
  2.1640  Being a tool chest, MH creates many processes.
  2.1641  In earlier times
  2.1642 @@ -1766,8 +1748,8 @@
  2.1643  I replaced all calls to
  2.1644  .Fu vfork()
  2.1645  with calls to
  2.1646 -.Fu fork() .
  2.1647 -.Ci 40821f5c1316e9205a08375e7075909cc9968e7d
  2.1648 +.Fu fork()
  2.1649 +.Ci 40821f5c1316e9205a08375e7075909cc9968e7d .
  2.1650  .P
  2.1651  Related to the costs of
  2.1652  .Fu fork()
  2.1653 @@ -1779,14 +1761,14 @@
  2.1654  .Fu fork()
  2.1655  calls in the code were wrapped into loops to retry the
  2.1656  .Fu fork()
  2.1657 -several times, to increase the chances to succeed, eventually.
  2.1658 +several times, to increase the chances to succeed eventually.
  2.1659  On modern systems, a failing
  2.1660  .Fu fork()
  2.1661  call is unusual.
  2.1662  Hence, in the rare case when
  2.1663  .Fu fork()
  2.1664 -fails, mmh programs simply abort.
  2.1665 -.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6
  2.1666 +fails, mmh programs simply abort
  2.1667 +.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6 .
  2.1668  
  2.1669  
  2.1670  .U3 "Header Fields
  2.1671 @@ -1799,13 +1781,13 @@
  2.1672  messages [RFC\|4880, RFC\|3156].
  2.1673  Hence, the support for
  2.1674  .Hd Encrypted
  2.1675 -header fields is removed in mmh.
  2.1676 -.Ci 064527f7b57ab050e5af13e15ad99aeeab125857
  2.1677 +header fields is removed in mmh
  2.1678 +.Ci 064527f7b57ab050e5af13e15ad99aeeab125857 .
  2.1679  .BU
  2.1680  The native support for
  2.1681  .Hd Face
  2.1682 -header fields has been removed, as well.
  2.1683 -.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23
  2.1684 +header fields has been removed, as well
  2.1685 +.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23 .
  2.1686  This feature is similar to the
  2.1687  .Hd X-Face
  2.1688  header field in its intent,
  2.1689 @@ -1818,7 +1800,7 @@
  2.1690  .Hd X-Face ,
  2.1691  although it re-uses the
  2.1692  .Hd Face
  2.1693 -header field.
  2.1694 +header field name.
  2.1695  It was invented in 2005 and supports colored PNG images.
  2.1696  None of the Face systems described here is popular today.
  2.1697  Hence, mmh has no direct support for them.
  2.1698 @@ -1840,26 +1822,29 @@
  2.1699  .Hd Content-MD5
  2.1700  header field superfluous.
  2.1701  Not a single one out of 4\|200 messages from two decades
  2.1702 -in an nmh-workers mailing list archive contains a
  2.1703 +in the nmh-workers mailing list archive
  2.1704 +.[
  2.1705 +nmh-workers mailing list archive website
  2.1706 +.]
  2.1707 +contains a
  2.1708  .Hd Content-MD5
  2.1709  header field.
  2.1710  Neither did any of the 60\|000 messages in my personal mail storage.
  2.1711 -Removing the support for this header field,
  2.1712 +Removing the support for this header field
  2.1713 +.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda ,
  2.1714  removed the last place where MD5 computation was needed.
  2.1715 -.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
  2.1716  Hence, the MD5 code could be removed as well.
  2.1717  Over 500 lines of code vanished by this one change.
  2.1718  
  2.1719  
  2.1720  .U3 "MMDF maildrop support
  2.1721  .P
  2.1722 -This type of format is conceptionally similar to the mbox format,
  2.1723 +This type of maildrop format is conceptionally similar to the mbox format,
  2.1724  but uses a different message delimiter (`\fL\\1\\1\\1\\1\fP',
  2.1725  commonly written as `\fL^A^A^A^A\fP', instead of `\fLFrom\0\fP').
  2.1726  Mbox is the de-facto standard maildrop format on Unix,
  2.1727  whereas the MMDF maildrop format is now forgotten.
  2.1728 -By dropping the MMDF maildrop format support,
  2.1729 -mbox became the only packed mailbox format supported in mmh.
  2.1730 +Mbox remains as the only packed mailbox format, supported in mmh.
  2.1731  .P
  2.1732  The simplifications within the code were moderate.
  2.1733  Mainly, the reading and writing of MMDF mailbox files was removed.
  2.1734 @@ -1867,12 +1852,12 @@
  2.1735  .Pn packf
  2.1736  and
  2.1737  .Pn rcvpack
  2.1738 -could be removed.
  2.1739 -.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
  2.1740 +could be removed
  2.1741 +.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 .
  2.1742  In the message parsing function
  2.1743  .Fn sbr/m_getfld.c ,
  2.1744 -knowledge of MMDF packed mail boxes was removed.
  2.1745 -.Ci 684ec30d81e1223a282764452f4902ed4ad1c754
  2.1746 +knowledge of MMDF packed mail boxes was removed
  2.1747 +.Ci 684ec30d81e1223a282764452f4902ed4ad1c754 .
  2.1748  Further code structure simplifications may be possible there,
  2.1749  because only one single packed mailbox format is left to be supported.
  2.1750  I have not worked on them yet because
  2.1751 @@ -1887,9 +1872,7 @@
  2.1752  The program
  2.1753  .Pn prompter
  2.1754  queries the user to fill in a message form.
  2.1755 -When used by
  2.1756 -.Pn comp
  2.1757 -as
  2.1758 +When used as
  2.1759  .Cl "comp -editor prompter" ,
  2.1760  the resulting behavior is similar to
  2.1761  .Pn mailx .
  2.1762 @@ -1940,9 +1923,8 @@
  2.1763  .H2 "Attachments
  2.1764  .P
  2.1765  The mind model of email attachments is unrelated to MIME.
  2.1766 -Although the MIME RFCs [RFC\|2045\(enRFC\|2049] define the technical
  2.1767 -requirements for having attachments, they do not mention the word
  2.1768 -attachment.
  2.1769 +Although the MIME RFCs [RFC\|2045\(en2049] define the technical
  2.1770 +requirements for having attachments, they do not mention the term.
  2.1771  Instead of attachments, MIME talks about ``multi-part message bodies''
  2.1772  [RFC\|2045], a more general concept.
  2.1773  Multi-part messages are messages
  2.1774 @@ -1951,7 +1933,7 @@
  2.1775  [RFC\|2046].
  2.1776  MIME keeps its descriptions generic;
  2.1777  it does not imply specific usage models.
  2.1778 -One usage model became prevalent: attachments.
  2.1779 +Today, one usage model is prevalent: attachments.
  2.1780  The idea is having a main text document with files of arbitrary kind
  2.1781  attached to it.
  2.1782  In MIME terms, this is a multi-part message having a text part first
  2.1783 @@ -1970,11 +1952,11 @@
  2.1784  .U3 "Composing MIME Messages
  2.1785  .P
  2.1786  In order to improve the situation on the message composing side,
  2.1787 -Jon Steinhart had added an attachment system to nmh in 2002.
  2.1788 -.Ci 7480dbc14bc90f2d872d434205c0784704213252
  2.1789 +Jon Steinhart had added an attachment system to nmh in 2002
  2.1790 +.Ci 7480dbc14bc90f2d872d434205c0784704213252 .
  2.1791  In the file
  2.1792  .Fn docs/README-ATTACHMENTS ,
  2.1793 -he described his motivation to do so as such:
  2.1794 +he described his motivation to do so:
  2.1795  .QS
  2.1796  Although nmh contains the necessary functionality for MIME message
  2.1797  handing [sic!], the interface to this functionality is pretty obtuse.
  2.1798 @@ -1992,18 +1974,17 @@
  2.1799  are sent.
  2.1800  .QE
  2.1801  .LP
  2.1802 -Unfortunately, the attachment system,
  2.1803 -like any new facilities in nmh,
  2.1804 +Unfortunately, the attachment system, like every new facilities in nmh,
  2.1805  was inactive by default.
  2.1806  .P
  2.1807 -During my work in Argentina, I tried to improve the attachment system.
  2.1808 -But, because of great opposition in the nmh community,
  2.1809 -my patch died as a proposal on the mailing list, after long discussions.
  2.1810 +During my time in Argentina, I tried to improve the attachment system.
  2.1811 +But, after long discussions my patch died as a proposal on the
  2.1812 +mailing list because of great opposition in the nmh community.
  2.1813  .[
  2.1814  nmh-workers attachment proposal
  2.1815  .]
  2.1816 -In January 2012, I extended the patch and applied it to mmh.
  2.1817 -.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
  2.1818 +In January 2012, I extended the patch and applied it to mmh
  2.1819 +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 .
  2.1820  In mmh, the attachment system is active by default.
  2.1821  Instead of command line switches, the
  2.1822  .Pe Attachment-Header
  2.1823 @@ -2041,11 +2022,11 @@
  2.1824  .Cl "Attach: +bob 30 42" ,
  2.1825  the given messages in the specified folder will be attached.
  2.1826  This allowed to simplify
  2.1827 -.Pn forw .
  2.1828 -.Ci f41f04cf4ceca7355232cf7413e59afafccc9550
  2.1829 +.Pn forw
  2.1830 +.Ci f41f04cf4ceca7355232cf7413e59afafccc9550 .
  2.1831  .P
  2.1832  Closely related to attachments is non-ASCII text content,
  2.1833 -because it requires MIME too.
  2.1834 +because it requires MIME as well.
  2.1835  In nmh, the user needed to call `mime' at the WhatNow prompt
  2.1836  to have the draft converted to MIME.
  2.1837  This was necessary whenever the draft contained non-ASCII characters.
  2.1838 @@ -2084,13 +2065,13 @@
  2.1839  compositions directly, the full power of
  2.1840  .Pn mhbuild
  2.1841  can still be accessed.
  2.1842 -Given no attachment headers are included, the user can create
  2.1843 +Given no attachment headers are included, users can create
  2.1844  .Pn mhbuild
  2.1845  composition drafts like in nmh.
  2.1846 -Then, at the WhatNow prompt, he needs to invoke
  2.1847 +Then, at the WhatNow prompt, they can invoke
  2.1848  .Cl "edit mhbuild
  2.1849 -to convert it to MIME.
  2.1850 -Because the resulting draft does neither contain non-ASCII characters
  2.1851 +to convert the draft to MIME.
  2.1852 +Because the resulting draft neither contains non-ASCII characters
  2.1853  nor has it attachment headers, the attachment system will not touch it.
  2.1854  .P
  2.1855  The approach taken in mmh is tailored towards today's most common case:
  2.1856 @@ -2104,24 +2085,26 @@
  2.1857  .Pn mhbuild
  2.1858  composition drafts had one notable advantage over attachment headers:
  2.1859  The user provides the appropriate MIME types for files to include.
  2.1860 -The attachment system needs to find out the correct MIME type itself.
  2.1861 -This is a difficult task, yet it spares the user irritating work.
  2.1862 +The new attachment system needs to find out the correct MIME type itself.
  2.1863 +This is a difficult task.
  2.1864  Determining the correct MIME type of content is partly mechanical,
  2.1865  partly intelligent work.
  2.1866  Forcing the user to find out the correct MIME type,
  2.1867  forces him to do partly mechanical work.
  2.1868  Letting the computer do the work can lead to bad choices for difficult
  2.1869  content.
  2.1870 -For mmh, the latter option was chosen.
  2.1871 +For mmh, the latter option was chosen to spare the user the work
  2.1872 +.Ci 3baec236a39c5c89a9bda8dbd988d643a21decc6 .
  2.1873  .P
  2.1874  Determining the MIME type by the suffix of the file name is a dumb
  2.1875  approach, yet it is simple to implement and provides good results
  2.1876  for the common cases.
  2.1877 +If no MIME type can be determined, text content is sent as `text/plain',
  2.1878 +anything else under the generic fall-back type `application/octet-stream'.
  2.1879  Mmh implements this approach in the
  2.1880  .Pn print-mimetype
  2.1881 -script.
  2.1882 -.Ci 4b5944268ea0da7bb30598a27857304758ea9b44
  2.1883 -Using it is the default choice.
  2.1884 +script
  2.1885 +.Ci 4b5944268ea0da7bb30598a27857304758ea9b44 .
  2.1886  .P
  2.1887  A far better, though less portable, approach is the use of
  2.1888  .Pn file .
  2.1889 @@ -2129,41 +2112,36 @@
  2.1890  Unfortunately, its capabilities and accuracy varies from system to system.
  2.1891  Additionally, its output was only intended for human beings,
  2.1892  but not to be used by programs.
  2.1893 -It varies much.
  2.1894  Nevertheless, modern versions of GNU
  2.1895  .Pn file ,
  2.1896 -which is prevalent on the popular GNU/Linux systems,
  2.1897 +which are prevalent on the popular GNU/Linux systems,
  2.1898  provide MIME type output in machine-readable form.
  2.1899 -Although this solution is highly system-dependent,
  2.1900 +Although this solution is system-dependent,
  2.1901  it solves the difficult problem well.
  2.1902  On systems where GNU
  2.1903  .Pn file ,
  2.1904  version 5.04 or higher, is available it should be used.
  2.1905  One needs to specify the following profile entry to do so:
  2.1906 -.Ci 3baec236a39c5c89a9bda8dbd988d643a21decc6
  2.1907  .VS
  2.1908  Mime-Type-Query: file -b --mime
  2.1909  VE
  2.1910  .LP
  2.1911  Other versions of
  2.1912  .Pn file
  2.1913 -might possibly be usable with wrapper scripts to reformat the output.
  2.1914 +might possibly be usable with wrapper scripts that reformat the output.
  2.1915  The diversity among
  2.1916  .Pn file
  2.1917  implementations is great; one needs to check the local variant.
  2.1918  .P
  2.1919 -If no MIME type can be determined, text content gets sent as
  2.1920 -`text/plain' and anything else under the generic fall-back type
  2.1921 -`application/octet-stream'.
  2.1922  It is not possible in mmh to override the automatic MIME type guessing
  2.1923  for a specific file.
  2.1924  To do so, either the user would need to know in advance for which file
  2.1925 -the automatic guessing fails, or the system would require interaction.
  2.1926 +the automatic guessing fails or the system would require interaction.
  2.1927  I consider both cases impractical.
  2.1928  The existing solution should be sufficient.
  2.1929  If not, the user may always fall back to
  2.1930  .Pn mhbuild
  2.1931 -composition drafts and ignore the attachment system.
  2.1932 +composition drafts and bypass the attachment system.
  2.1933  
  2.1934  
  2.1935  .U3 "Storing Attachments
  2.1936 @@ -2208,23 +2186,22 @@
  2.1937  Tar files are not extracted automatically any more.
  2.1938  Thus, the rest of the file system will not be touched.
  2.1939  .Ci 94c80042eae3383c812d9552089953f9846b1bb6
  2.1940 -.LP
  2.1941 -Now, the outcome of mmh's
  2.1942 +.P
  2.1943 +In mmh, the result of
  2.1944  .Cl "mhstore -auto
  2.1945  can be foreseen from the output of
  2.1946  .Cl "mhlist -verbose" .
  2.1947 -.P
  2.1948 -The
  2.1949 +Although the
  2.1950  .Sw -noauto
  2.1951 -mode is seen to be more powerful but less convenient.
  2.1952 -On the other hand,
  2.1953 +mode is considered to be more powerful, it is less convenient and
  2.1954  .Sw -auto
  2.1955 -is safe now and
  2.1956 -storing attachments under their original name is intuitive.
  2.1957 +is safe now.
  2.1958 +Additionally, storing attachments under their original name
  2.1959 +is intuitive.
  2.1960  Hence,
  2.1961  .Sw -auto
  2.1962 -serves better as the default option.
  2.1963 -.Ci 3410b680416c49a7617491af38bc1929855a331d
  2.1964 +serves better as the default option
  2.1965 +.Ci 3410b680416c49a7617491af38bc1929855a331d .
  2.1966  .P
  2.1967  Files are stored into the directory given by the
  2.1968  .Pe Nmh-Storage
  2.1969 @@ -2234,12 +2211,12 @@
  2.1970  .Pe mhstore-store-*
  2.1971  profile entries.
  2.1972  .P
  2.1973 -Still, in both modes, existing files get overwritten silently.
  2.1974 +Still existing files get overwritten silently in both modes.
  2.1975  This can be considered a bug.
  2.1976  Yet, each other behavior has its draw-backs, too.
  2.1977  Refusing to replace files requires adding a
  2.1978  .Sw -force
  2.1979 -option.
  2.1980 +switch.
  2.1981  Users will likely need to invoke
  2.1982  .Pn mhstore
  2.1983  a second time with
  2.1984 @@ -2260,16 +2237,16 @@
  2.1985  MIME parts of type message/external-body are not automatically retrieved
  2.1986  anymore.
  2.1987  Instead, information on how to retrieve them is output.
  2.1988 -Not supporting this rare case saved nearly one thousand lines of code.
  2.1989 -.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
  2.1990 +Not supporting this rare case saved nearly one thousand lines of code
  2.1991 +.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32 .
  2.1992  .\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
  2.1993  .\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
  2.1994 -`application/octet-stream; type=tar' is not special anymore.
  2.1995 -Automatically extracting such MIME parts had been the dangerous part
  2.1996 -of the
  2.1997 +The MIME type `application/octet-stream; type=tar' is not special anymore.
  2.1998 +The automatically extracting of such MIME parts had been the
  2.1999 +dangerous part of the
  2.2000  .Sw -auto
  2.2001 -mode.
  2.2002 -.Ci 94c80042eae3383c812d9552089953f9846b1bb6
  2.2003 +mode
  2.2004 +.Ci 94c80042eae3383c812d9552089953f9846b1bb6 .
  2.2005  
  2.2006  
  2.2007  
  2.2008 @@ -2277,23 +2254,23 @@
  2.2009  .P
  2.2010  The program
  2.2011  .Pn mhshow
  2.2012 -had been written to display MIME messages.
  2.2013 +was written to display MIME messages.
  2.2014  It implemented the conceptional view of the MIME RFCs.
  2.2015  Nmh's
  2.2016  .Pn mhshow
  2.2017 -handled each MIME part independently, presenting them separately
  2.2018 +handles each MIME part independently, presenting them separately
  2.2019  to the user.
  2.2020  This does not match today's understanding of email attachments,
  2.2021  where displaying a message is seen to be a single, integrated operation.
  2.2022  Today, email messages are expected to consist of a main text part
  2.2023  plus possibly attachments.
  2.2024 -They are not any more seen to be arbitrary MIME hierarchies with
  2.2025 +They are no more seen to be arbitrary MIME hierarchies with
  2.2026  information on how to display the individual parts.
  2.2027  I adjusted
  2.2028  .Pn mhshow 's
  2.2029  behavior to the modern view on the topic.
  2.2030  .P
  2.2031 -One should note that this section completely ignores the original
  2.2032 +(One should note that this section completely ignores the original
  2.2033  .Pn show
  2.2034  program, because it was not capable to display MIME messages
  2.2035  and is no longer part of mmh.
  2.2036 @@ -2304,7 +2281,7 @@
  2.2037  .Pn show
  2.2038  in mmh, this section uses the name
  2.2039  .Pn mhshow ,
  2.2040 -in order to avoid confusion.
  2.2041 +in order to avoid confusion.)
  2.2042  .P
  2.2043  In mmh, the basic idea is that
  2.2044  .Pn mhshow
  2.2045 @@ -2312,19 +2289,19 @@
  2.2046  Therefore,
  2.2047  .Pn mhshow
  2.2048  invokes a pager session for all its output,
  2.2049 -whenever it prints to a terminal.
  2.2050 -.Ci a4197ea6ffc5c1550e8b52d5a654bcaaaee04a4e
  2.2051 +whenever it prints to a terminal
  2.2052 +.Ci a4197ea6ffc5c1550e8b52d5a654bcaaaee04a4e .
  2.2053  In consequence,
  2.2054  .Pn mhl
  2.2055 -does no more invoke a pager.
  2.2056 -.Ci 0e46503be3c855bddaeae3843e1b659279c35d70
  2.2057 +does no more invoke a pager
  2.2058 +.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 .
  2.2059  With
  2.2060  .Pn mhshow
  2.2061  replacing the original
  2.2062  .Pn show ,
  2.2063 -output from
  2.2064 +the output of
  2.2065  .Pn mhl
  2.2066 -does not go to the terminal directly, but through
  2.2067 +no longer goes to the terminal directly, but through
  2.2068  .Pn mhshow .
  2.2069  Hence,
  2.2070  .Pn mhl
  2.2071 @@ -2335,30 +2312,32 @@
  2.2072  The only place in mmh, where a pager is invoked is
  2.2073  .Pn mhshow .
  2.2074  .P
  2.2075 +In the intended setup, only text content is be displayed,
  2.2076 +in a single pager session.
  2.2077 +Non-text content needs to be converted to text by appropriate
  2.2078 +.Pe mhshow-show-*
  2.2079 +profile entries before, if this is possible and wanted.
  2.2080 +A common example for this are PDF files.
  2.2081 +.ig \"XXX
  2.2082  .Pe mhshow-show-*
  2.2083  profile entries can be used to display MIME parts in a specific way.
  2.2084 -For instance, PDF and Postscript files could be converted to plain text
  2.2085  to display them in the terminal.
  2.2086 -In mmh, MIME parts will always be displayed serially.
  2.2087 +..
  2.2088 +In mmh, MIME parts are always displayed serially.
  2.2089  The request to display the MIME type `multipart/parallel' in parallel
  2.2090  is ignored.
  2.2091 -It is simply treated as `multipart/mixed'.
  2.2092 -.Ci d0581ba306a7299113a346f9b4c46ce97bc4cef6
  2.2093 -This could already be requested with the, now removed,
  2.2094 +It is simply treated as `multipart/mixed'
  2.2095 +.Ci d0581ba306a7299113a346f9b4c46ce97bc4cef6 .
  2.2096 +This was already possible to requested with the, now removed,
  2.2097  .Sw -serialonly
  2.2098  switch of
  2.2099  .Pn mhshow .
  2.2100  As MIME parts are always processed exclusively, i.e. serially,
  2.2101 -the `%e' escape in
  2.2102 +the `\fL%e\fP' escape in
  2.2103  .Pe mhshow-show-*
  2.2104 -profile entries became useless and was thus removed.
  2.2105 -.Ci a20d405db09b7ccca74d3e8c57550883da49e1ae
  2.2106 +profile entries became useless and was thus removed
  2.2107 +.Ci a20d405db09b7ccca74d3e8c57550883da49e1ae .
  2.2108  .P
  2.2109 -In the intended setup, only text content would be displayed.
  2.2110 -Non-text content would be converted to text by appropriate
  2.2111 -.Pe mhshow-show-*
  2.2112 -profile entries before, if possible and wanted.
  2.2113 -All output would be displayed in a single pager session.
  2.2114  Other kinds of attachments are ignored.
  2.2115  With
  2.2116  .Pe mhshow-show-*
  2.2117 @@ -2370,12 +2349,12 @@
  2.2118  to the native charset.
  2.2119  Therefore,
  2.2120  .Pe mhshow-charset-*
  2.2121 -profile entries used to be needed.
  2.2122 +profile entries were needed.
  2.2123  In mmh, the conversion is performed automatically by piping the
  2.2124  text through the
  2.2125  .Pn iconv
  2.2126 -command, if necessary.
  2.2127 -.Ci 2433122c20baccb10b70b49c04c6b0497b5b3b60
  2.2128 +command, if necessary
  2.2129 +.Ci 2433122c20baccb10b70b49c04c6b0497b5b3b60 .
  2.2130  Custom
  2.2131  .Pe mhshow-show-*
  2.2132  rules for textual content might need a
  2.2133 @@ -2411,9 +2390,9 @@
  2.2134  .P
  2.2135  Nmh offers no direct support for digital signatures and message encryption.
  2.2136  This functionality needed to be added through third-party software.
  2.2137 -In mmh, the functionality should be included because it
  2.2138 -is a part of modern email and likely wanted by users of mmh.
  2.2139 -A fresh mmh installation should support signing and encrypting
  2.2140 +In mmh, the functionality is included because it
  2.2141 +is a part of modern email and is likely wanted by users of mmh.
  2.2142 +A fresh mmh installation supports signing and encrypting
  2.2143  out-of-the-box.
  2.2144  Therefore, Neil Rickert's
  2.2145  .Pn mhsign
  2.2146 @@ -2423,24 +2402,26 @@
  2.2147  .[
  2.2148  neil rickert mhsign mhpgp
  2.2149  .]
  2.2150 -were included into mmh
  2.2151 +were included
  2.2152  .Ci f45cdc98117a84f071759462c7ae212f4bc5ab2e
  2.2153  .Ci 58cf09aa36e9f7f352a127158bbf1c5678bc6ed8 .
  2.2154  The scripts fit well because they are lightweight and
  2.2155  similar of style to the existing tools.
  2.2156 -Additionally, no licensing difficulties appeared,
  2.2157 +Additionally, no licensing difficulties appeared
  2.2158  as they are part of the public domain.
  2.2159  .P
  2.2160  .Pn mhsign
  2.2161  handles the signing and encrypting part.
  2.2162  It comprises about 250 lines of shell code and interfaces between
  2.2163 -.Pn gnupg
  2.2164 -and
  2.2165 -the MH system.
  2.2166 +.Pn gnupg "
  2.2167 +.[
  2.2168 +gnupg website
  2.2169 +.]
  2.2170 +and the MH system.
  2.2171  It was meant to be invoked manually at the WhatNow prompt, but in mmh,
  2.2172  .Pn send
  2.2173  invokes
  2.2174 -.pn mhsign
  2.2175 +.Pn mhsign
  2.2176  automatically
  2.2177  .Ci c7b5e1df086bcc37ff40163ee67571f076cf6683 .
  2.2178  Special header fields were introduced to request this action.
  2.2179 @@ -2449,14 +2430,14 @@
  2.2180  header field,
  2.2181  .Pn send
  2.2182  will initiate the signing.
  2.2183 -The signing key is either chosen automatically or specified by the
  2.2184 +The signing key is either chosen automatically or it is specified by the
  2.2185  .Pe Pgpkey
  2.2186  profile entry.
  2.2187  .Pn send
  2.2188 -always create signatures using the PGP/MIME standard, \" REF XXX
  2.2189 -but by manually invoking
  2.2190 -.Pn mhsign ,
  2.2191 -old-style non-MIME signatures can be created as well.
  2.2192 +always create signatures using the PGP/MIME standard [RFC\|4880],
  2.2193 +but by invoking
  2.2194 +.Pn mhsign
  2.2195 +manually, old-style non-MIME signatures can be created as well.
  2.2196  To encrypt an outgoing message, the draft needs to contain an
  2.2197  .Hd Enc
  2.2198  header field.
  2.2199 @@ -2475,7 +2456,7 @@
  2.2200  is the companion to
  2.2201  .Pn mhsign .
  2.2202  It verifies signatures and decrypts messages.
  2.2203 -Encrypted messages can either be temporarily decrypted for display
  2.2204 +Encrypted messages can be either temporarily decrypted and displayed
  2.2205  or permanently decrypted and stored into the current folder.
  2.2206  Currently,
  2.2207  .Pn mhpgp
  2.2208 @@ -2484,21 +2465,21 @@
  2.2209  .Pn show
  2.2210  and
  2.2211  .Pn mhstore
  2.2212 -to verify signatures and decrypt messages as needs
  2.2213 -is planned but not realized yet.
  2.2214 +to verify signatures and decrypt messages as needed
  2.2215 +is planned but not yet realized.
  2.2216  .P
  2.2217 -Both scripts were written for nmh, hence they needed to be adjust
  2.2218 +Both scripts were written for nmh.
  2.2219 +Hence they needed to be adjust
  2.2220  according to the differences between nmh and mmh.
  2.2221  For instance, they use the backup prefix no longer.
  2.2222  Furthermore, compatibility support for old PGP features was dropped.
  2.2223  .P
  2.2224  The integrated message signing and encrypting support is one of the
  2.2225  most recent features in mmh.
  2.2226 -It has not yet had the time to mature.
  2.2227 +It has not had the time to mature.
  2.2228  User feedback and personal experience need to be accumulated to
  2.2229  direct the further development of the facility.
  2.2230 -Although the feedback and experience is still missing,
  2.2231 -it seems to be worthwhile to consider adding
  2.2232 +Already it seems to be worthwhile to consider adding
  2.2233  .Sw -[no]sign
  2.2234  and
  2.2235  .Sw -[no]enc
  2.2236 @@ -2527,9 +2508,9 @@
  2.2237  .Id draft-folder
  2.2238  .P
  2.2239  In the beginning, MH had the concept of a draft message.
  2.2240 -This is the file
  2.2241 +This was a file named
  2.2242  .Fn draft
  2.2243 -in the MH directory, which is treated special.
  2.2244 +in the MH directory, which was treated special.
  2.2245  On composing a message, this draft file was used.
  2.2246  When starting to compose another message before the former one was sent,
  2.2247  the user had to decide among:
  2.2248 @@ -2540,8 +2521,8 @@
  2.2249  .LI 3
  2.2250  Preserving the old draft by refiling it to a folder.
  2.2251  .LP
  2.2252 -It was only possible to work in alternation on multiple drafts.
  2.2253 -Therefore, the current draft needed to be refiled to a folder and
  2.2254 +Working on multiple drafts was only possible in alternation.
  2.2255 +For that, the current draft needed to be refiled to a folder and
  2.2256  another one re-used for editing.
  2.2257  Working on multiple drafts at the same time was impossible.
  2.2258  The usual approach of switching to a different MH context did not
  2.2259 @@ -2561,7 +2542,8 @@
  2.2260  the draft file at a static location.
  2.2261  This is simple in simple cases but the concept does not scale for more
  2.2262  complex cases.
  2.2263 -The concept of the draft message is too limited for the problem.
  2.2264 +The concept of the draft message is too limited for the problem
  2.2265 +it tries to solve.
  2.2266  Therefore the draft folder was introduced.
  2.2267  It is the more powerful and more natural concept.
  2.2268  The draft folder is a folder like any other folder in MH.
  2.2269 @@ -2573,7 +2555,7 @@
  2.2270  The trivial part of the work was activating the draft folder with a
  2.2271  default name.
  2.2272  I chose the name
  2.2273 -.Fn +drafts
  2.2274 +.Fn +drafts ,
  2.2275  for obvious reasons.
  2.2276  In consequence, the command line switches
  2.2277  .Sw -draftfolder
  2.2278 @@ -2584,8 +2566,8 @@
  2.2279  new concept.
  2.2280  For nearly three decades, the tools needed to support two draft handling
  2.2281  approaches.
  2.2282 -By fully switching to the draft folder, the tools could be simplified
  2.2283 -by dropping the awkward draft message handling code.
  2.2284 +By fully switching to the draft folder, the tools could be
  2.2285 +simplified by dropping the awkward draft message handling code.
  2.2286  .Sw -draft
  2.2287  switches were removed because operating on a draft message is no longer
  2.2288  special.
  2.2289 @@ -2603,11 +2585,13 @@
  2.2290  .Sw -[no]use
  2.2291  for switching between two modes:
  2.2292  .LI 1
  2.2293 -.Sw -use
  2.2294 -to modify an existing draft.
  2.2295 +Modifying an existing draft, with
  2.2296 +.Sw -use .
  2.2297  .LI 2
  2.2298 -.Sw -nouse
  2.2299 -to compose a new draft, possibly taking some existing message as template.
  2.2300 +Composing a new draft, possibly taking some existing message as template,
  2.2301 +with
  2.2302 +.Sw -nouse ,
  2.2303 +the default.
  2.2304  .LP
  2.2305  In either case, the behavior of
  2.2306  .Pn comp
  2.2307 @@ -2623,17 +2607,19 @@
  2.2308  takes the draft folder as its default folder.
  2.2309  .P
  2.2310  Dropping the draft message concept in favor for the draft folder concept,
  2.2311 -removed special cases with regular cases.
  2.2312 +replaced special cases with regular cases.
  2.2313  This simplified the source code of the tools, as well as the concepts.
  2.2314  In mmh, draft management does not break with the MH concepts
  2.2315  but applies them.
  2.2316  .Cl "scan +drafts" ,
  2.2317  for instance, is a truly natural request.
  2.2318 +.P
  2.2319  Most of the work was already performed by Rose in the eighties.
  2.2320  The original improvement of mmh is dropping the old draft message approach
  2.2321 -and thus simplifying the tools, the documentation and the system as a whole.
  2.2322 +and thus simplifying the tools, the documentation,
  2.2323 +and the system as a whole.
  2.2324  Although my part in the draft handling improvement was small,
  2.2325 -it was an important one.
  2.2326 +it was important.
  2.2327  
  2.2328  
  2.2329  .U3 "Trash Folder
  2.2330 @@ -2655,8 +2641,7 @@
  2.2331  VE
  2.2332  In such a setup, the original message could be restored
  2.2333  within the grace time interval by stripping the
  2.2334 -backup prefix from the file name.
  2.2335 -But the user could not rely on this statement.
  2.2336 +backup prefix from the file name \(en usually but not always.
  2.2337  If the last message of a folder with six messages (\fL1-6\fP) was removed,
  2.2338  message
  2.2339  .Fn 6 ,
  2.2340 @@ -2665,10 +2650,10 @@
  2.2341  If then a new message entered the same folder, it would be named with
  2.2342  the number one above the highest existing message number.
  2.2343  In this case the message would be named
  2.2344 -.Fn 6
  2.2345 -then.
  2.2346 +.Fn 6 ,
  2.2347 +reusing the number.
  2.2348  If this new message would be removed as well,
  2.2349 -then the backup of the former message is overwritten.
  2.2350 +then the backup of the former message becomes overwritten.
  2.2351  Hence, the ability to restore removed messages did not only depend on
  2.2352  the sweeping cron job but also on the removing of further messages.
  2.2353  It is undesirable to have such obscure and complex mechanisms.
  2.2354 @@ -2676,17 +2661,16 @@
  2.2355  ``Removed files are restorable within a seven-day grace time.''
  2.2356  With the addition ``... unless a message with the same name in the
  2.2357  same folder is removed before.'' the statement becomes complex.
  2.2358 -A user will hardly be able to keep track of any removal to know
  2.2359 +A user will hardly be able to keep track of all removals to know
  2.2360  if the assertion still holds true for a specific file.
  2.2361  In practice, the real mechanism is unclear to the user.
  2.2362 -The consequences of further removals are not obvious.
  2.2363  .P
  2.2364 -Furthermore, the backup files are scattered within the whole mail storage.
  2.2365 -This complicates managing them.
  2.2366 -It is possible with the help of
  2.2367 +Furthermore, the backup files were scattered within the whole mail storage.
  2.2368 +This complicated managing them.
  2.2369 +It was possible with the help of
  2.2370  .Pn find ,
  2.2371 -but everything would be more convenient
  2.2372 -if the deleted messages would be collected in one place.
  2.2373 +but everything is more convenient
  2.2374 +if the deleted messages are collected in one place.
  2.2375  .P
  2.2376  The profile entry
  2.2377  .Pe rmmproc
  2.2378 @@ -2695,27 +2679,30 @@
  2.2379  was introduced very early to improve the situation.
  2.2380  It could be set to any command, which would be executed to remove
  2.2381  the specified messages.
  2.2382 -This would override the default action described above.
  2.2383 -Refiling the to-be-removed files to a trash folder is the usual example.
  2.2384 +This had overridden the default action, described above.
  2.2385 +Refiling the to-be-removed files to a trash folder was the usual example.
  2.2386  Nmh's man page
  2.2387  .Mp rmm (1)
  2.2388  proposes to set the
  2.2389  .Pe rmmproc
  2.2390  to
  2.2391  .Cl "refile +d
  2.2392 -to move messages to the trash folder,
  2.2393 -.Fn +d ,
  2.2394 +to move messages to the trash folder
  2.2395 +.Fn +d
  2.2396  instead of renaming them with the backup prefix.
  2.2397 -The man page proposes additionally the expunge command
  2.2398 +The man page additionally proposes the expunge command
  2.2399  .Cl "rm `mhpath +d all`
  2.2400  to empty the trash folder.
  2.2401  .P
  2.2402 -Removing messages in such a way has advantages.
  2.2403 +Removing messages in such a way has advantages:
  2.2404 +.LI 1
  2.2405  The mail storage is prevented from being cluttered with removed messages
  2.2406  because they are all collected in one place.
  2.2407  Existing and removed messages are thus separated more strictly.
  2.2408 +.LI 2
  2.2409  No backup files are silently overwritten.
  2.2410 -But most important is the ability to keep removed messages in the MH domain.
  2.2411 +.LI 3
  2.2412 +Most important, however, removed messages are kept in the MH domain.
  2.2413  Messages in the trash folder can be listed like those in any other folder.
  2.2414  Deleted messages can be displayed like any other messages.
  2.2415  .Pn refile
  2.2416 @@ -2740,8 +2727,8 @@
  2.2417  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
  2.2418  .Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
  2.2419  .P
  2.2420 -Dropping the legacy approach and converting to the new approach completely
  2.2421 -simplified the code base.
  2.2422 +Dropping the legacy approach and converting to the new approach
  2.2423 +completely, simplified the code base.
  2.2424  The relationship between
  2.2425  .Pn rmm
  2.2426  and
  2.2427 @@ -2750,8 +2737,8 @@
  2.2428  In mmh,
  2.2429  .Pn rmm
  2.2430  invokes
  2.2431 -.Pn refile ,
  2.2432 -which used to be the other way round.
  2.2433 +.Pn refile .
  2.2434 +That used to be the other way round.
  2.2435  Yet, the relationship is simpler now.
  2.2436  Loops, like described in nmh's man page for
  2.2437  .Mp refile (1),
  2.2438 @@ -2789,52 +2776,53 @@
  2.2439  .H2 "Modern Defaults
  2.2440  .P
  2.2441  Nmh has a bunch of convenience-improving features inactive by default,
  2.2442 -although one can expect every new user wanting to have them active.
  2.2443 +although one can expect every new user to want them active.
  2.2444  The reason they are inactive by default is the wish to stay compatible
  2.2445  with old versions.
  2.2446 -But what is the definition for old versions?
  2.2447 +But what are old versions?
  2.2448  Still, the highly useful draft folder facility has not been activated
  2.2449  by default although it was introduced over twenty-five years ago.
  2.2450  .[
  2.2451  rose romine real work
  2.2452  .]
  2.2453  The community seems not to care.
  2.2454 -This is one of several examples that require new users to first build up
  2.2455 -a profile before they can access the modern features of nmh.
  2.2456 +.P
  2.2457 +In nmh, new users are required to first build up
  2.2458 +a profile before they can access the modern features.
  2.2459  Without an extensive profile, the setup is hardly usable
  2.2460  for modern emailing.
  2.2461  The point is not the customization of the setup,
  2.2462  but the need to activate generally useful facilities.
  2.2463 -.P
  2.2464 -Yet, the real problem lies less in enabling the features, as this is
  2.2465 -straight forward as soon as one knows what he wants.
  2.2466 +Yet, the real problem lies less in enabling the features,
  2.2467 +as this is straight forward as soon as one knows what he wants.
  2.2468  The real problem is that new users need deep insight into the project
  2.2469 -to find out about inactive features nmh already provides.
  2.2470 +to discover the available but inactive features.
  2.2471  To give an example, I needed one year of using nmh
  2.2472  before I became aware of the existence of the attachment system.
  2.2473  One could argue that this fact disqualifies my reading of the
  2.2474  documentation.
  2.2475  If I would have installed nmh from source back then, I could agree.
  2.2476 -Yet, I had used a prepackaged version and had expected that it would
  2.2477 +Yet, I had used a pre-packaged version and had expected that it would
  2.2478  just work.
  2.2479  Nevertheless, I had been convinced by the concepts of MH already
  2.2480  and I am a software developer,
  2.2481  still I required a lot of time to discover the cool features.
  2.2482  How can we expect users to be even more advanced than me,
  2.2483 -just to allow them use MH in a convenient and modern way?
  2.2484 +just to enable them to use MH in a convenient and modern way?
  2.2485  Unless they are strongly convinced of the concepts, they will fail.
  2.2486  I have seen friends of me giving up disappointed
  2.2487  before they truly used the system,
  2.2488  although they had been motivated in the beginning.
  2.2489 -They suffer hard enough to get used to the tool chest approach,
  2.2490 +New users suffer hard enough to get used to the tool chest approach,
  2.2491  we developers should spare them further inconveniences.
  2.2492  .P
  2.2493  Maintaining compatibility for its own sake is bad,
  2.2494 -because the code base collects more and more compatibility code.
  2.2495 +because the code base will collect more and more compatibility code.
  2.2496  Sticking to the compatibility code means remaining limited;
  2.2497  whereas adjusting to the changes renders the compatibility unnecessary.
  2.2498 -Keeping unused alternatives in the code is a bad choice as they likely
  2.2499 -gather bugs, by not being well tested.
  2.2500 +Keeping unused alternatives in the code for longer than a short
  2.2501 +grace time is a bad choice as they likely
  2.2502 +gather bugs by not being constantly tested.
  2.2503  Also, the increased code size and the greater number of conditions
  2.2504  increase the maintenance costs.
  2.2505  If any MH implementation would be the back-end of widespread
  2.2506 @@ -2842,42 +2830,42 @@
  2.2507  important.
  2.2508  Yet, it appears as if this is not the case.
  2.2509  Hence, compatibility is hardly important for technical reasons.
  2.2510 -Its importance originates rather from personal reasons.
  2.2511 +Its importance originates from personal reasons rather.
  2.2512  Nmh's user base is small and old.
  2.2513 -Changing the interfaces would cause inconvenience to long-term users of MH.
  2.2514 -It would force them to change their many years old MH configurations.
  2.2515 +Changing the interfaces causes inconvenience to long-term users of MH.
  2.2516 +It forces them to change their many years old MH configurations.
  2.2517  I do understand this aspect, but by sticking to the old users,
  2.2518 -new users are kept away.
  2.2519 -Yet, the future lies in new users.
  2.2520 +new users are kept from entering the world of MH.
  2.2521 +But the future lies in new users.
  2.2522  In consequence, mmh invites new users by providing a convenient
  2.2523  and modern setup, readily usable out-of-the-box.
  2.2524  .P
  2.2525  In mmh, all modern features are active by default and many previous
  2.2526 -approaches are removed or only accessible in manual ways.
  2.2527 +approaches are removed or only accessible in a manual way.
  2.2528  New default features include:
  2.2529  .BU
  2.2530  The attachment system (\c
  2.2531 -.Hd Attach ).
  2.2532 -.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
  2.2533 +.Hd Attach )
  2.2534 +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 .
  2.2535  .BU
  2.2536  The draft folder facility (\c
  2.2537 -.Fn +drafts ).
  2.2538 -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
  2.2539 +.Fn +drafts )
  2.2540 +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
  2.2541  .BU
  2.2542  The unseen sequence (`u')
  2.2543  .Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
  2.2544 -and the sequence negation prefix (`!').
  2.2545 -.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
  2.2546 +and the sequence negation prefix (`!')
  2.2547 +.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc .
  2.2548  .BU
  2.2549 -Quoting the original message in the reply.
  2.2550 -.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
  2.2551 +Quoting the original message in the reply
  2.2552 +.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 .
  2.2553  .BU
  2.2554 -Forwarding messages using MIME.
  2.2555 -.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
  2.2556 +Forwarding messages using MIME
  2.2557 +.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 .
  2.2558  .LP
  2.2559 -In consequence, a setup with a profile that defines only the path to the
  2.2560 +An mmh setup with a profile that defines only the path to the
  2.2561  mail storage, is already convenient to use.
  2.2562 -Again, Paul Vixie's ``edginess'' call supports the direction I took:
  2.2563 +Again, Paul Vixie's supports the direction I took:
  2.2564  ``the `main branch' should just be modern''.
  2.2565  .[
  2.2566  paul vixie edginess nmh-workers

     3.1 --- a/web.bib	Fri Jul 13 18:35:36 2012 +0200
     3.2 +++ b/web.bib	Sat Jul 14 18:04:32 2012 +0200
     3.3 @@ -86,3 +86,73 @@
     3.4  %H Website of
     3.5  %T wmii
     3.6  %O \fU http://\:wmii.suckless.org
     3.7 +
     3.8 +%L web:\|postfix
     3.9 +%H Website of
    3.10 +%T Postfix
    3.11 +%O \fU http://\:www.postfix.org
    3.12 +
    3.13 +%L web:\|procmail
    3.14 +%H Website of
    3.15 +%T Procmail
    3.16 +%O \fU http://\:www.procmail.org
    3.17 +
    3.18 +%L web:\|fetchmail
    3.19 +%H Website of
    3.20 +%T Fetchmail
    3.21 +%O \fU http://\:www.fetchmail.info
    3.22 +
    3.23 +%L web:\|sendmail
    3.24 +%H Website of
    3.25 +%T Sendmail
    3.26 +%O \fU http://\:www.sendmail.com
    3.27 +
    3.28 +%L web:\|qmail
    3.29 +%H Website of
    3.30 +%T qmail
    3.31 +%O \fU http://\:cr.yp.to/\:qmail.html
    3.32 +
    3.33 +%L web:\|dma
    3.34 +%H Website of
    3.35 +%T dma, the DragonFly Mail Agent
    3.36 +%O \fU https://github.com/corecode/dma
    3.37 +
    3.38 +%L web:\|mpop
    3.39 +%H Website of
    3.40 +%T mpop
    3.41 +%O \fU http://mpop.sourceforge.net
    3.42 +
    3.43 +%L web:\|getmail
    3.44 +%H Website of
    3.45 +%T getmail
    3.46 +%O \fU http://pyropus.ca/software/getmail/
    3.47 +
    3.48 +%L web:\|fdm
    3.49 +%H Website of
    3.50 +%T fdm
    3.51 +%O \fU http://fdm.sourceforge.net
    3.52 +
    3.53 +%L web:\|masqmail
    3.54 +%H Website of
    3.55 +%T masqmail
    3.56 +%O \fU http://marmaro.de/prog/masqmail/
    3.57 +
    3.58 +%L web:\|nullmailer
    3.59 +%H Website of
    3.60 +%T nullmailer
    3.61 +%O \fU http://untroubled.org/nullmailer/
    3.62 +
    3.63 +%L web:\|ssmtp
    3.64 +%H Website of
    3.65 +%T ssmtp
    3.66 +%O \fU http://packages.qa.debian.org/s/ssmtp.html
    3.67 +
    3.68 +%L web:\|mh-e
    3.69 +%H Website of
    3.70 +%T MH-E, the Emacs Interface to the MH Mail System
    3.71 +%O \fU http://mh-e.sourceforge.net
    3.72 +
    3.73 +%L web:\|gpg
    3.74 +%H Website of
    3.75 +%T GnuPG
    3.76 +%O \fU http://www.gnupg.org