docs/master: discussion.roff comparison

comparison discussion.roff @ 217:f3f65376bef9

A big bunch of corrections in 2.1 and 2.2.

author	markus schnalke <meillo@marmaro.de>
date	Sat, 14 Jul 2012 18:04:32 +0200
parents	9317d789cef9
children	8c537982d718

comparison

equal deleted inserted replaced

-:91999f2cddeb
+:f3f65376bef9
 .H0 "Discussion
 .P
 This main chapter discusses the practical work accomplished in the
 mmh project.
-It is structured along the goals set for the project.
+It is structured along the goals chosen for the project.
-The concrete work undertaken
+A selection of the work undertaken
-is described in the examples of how the general goals were achieved.
+is described.
-The discussion compares the current version of mmh with the state of
+.P
-nmh just before the mmh project started, i.e. fall 2011.
+This discussion compares the present version of mmh with the state of
-Current changes of nmh will be mentioned only as side notes.
+nmh at the time when the mmh project had started, i.e. fall 2011.
-.\" XXX where do I discuss the parallel development of nmh?
+Recent changes in nmh are seldom part of the discussion.
+Sometimes they are mentioned in side notes.
 .P
 For the reader's convenience, the structure of modern email systems
-is depicted in the figure.
+is depicted in the following figure.
 It illustrates the path a message takes from sender to recipient.
-.sp
+.sp 1.5
 .KS
 .in 2c
 .so input/mail-agents.pic
 .KE
-.sp
+.sp 1.5
 .LP
-The ellipses denote mail agents, i.e. different jobs in email processing:
+The ellipses denote mail agents, i.e. different jobs in email processing.
+These are:
 .IP "Mail User Agent (MUA)
-The only program the user interacts directly with.
+The only program users directly interact with.
 It includes functions to compose new mail, display received mail,
 and to manage the mail storage.
-Also called \fImail client\fP.
+It is called a \fImail client\fP as well.
 .IP "Mail Submission Agent (MSA)
 A special kind of Mail Transfer Agent, used to submit mail into the
 mail transport system.
+Often it is also called an MTA.
 .IP "Mail Transfer Agent (MTA)
 A node in the mail transport system.
-Transfers incoming mail to a transport node nearer to the final destination.
+It transfers incoming mail to a transport node nearer to the
-It may be the final destination itself.
+final destination.
+An MTA may be the final destination itself.
 .IP "Mail Delivery Agent (MDA)
-Delivers mail by storing it onto disk, usually according to a set of rules.
+Delivers mail according to a set of rules.
+Usually, the messages are stored to disk.
 .IP "Mail Retrieval Agent (MRA)
-Initiates the transfer of mail from a remote server to the local machine.
+Initiates the transfer of mail from a remote location to the local machine.
-(The dashed arrow represents the pull request.)
+(The dashed arrow in the figure represents the pull request.)
-.P
+.LP
-The dashed boxes represent groups that usually reside on single machines.
+The dashed boxes represent entities that usually reside on single machines.
-The box on the lower left represents the sender's local system.
+The box on the lower left represents the sender's system.
 The box on the upper left represents the first mail transfer node.
 The box on the upper right represents the transfer node responsible for the
 destination address.
-The box on the lower right represents the recipient's local system.
+The box on the lower right represents the recipient's system.
 Often, the boxes above the dotted line are servers on the Internet.
-Many mail clients, including nmh, have all of the components below
+Many mail clients, including nmh, include all of the components below
-the dotted line implemented.
+the dotted line.
-Not so in mmh, which is an MUA only.
+This is not the case for mmh; it implements the MUA only.
 .\" --------------------------------------------------------------
 .H1 "Streamlining
 .P
-MH once provided anything necessary for email handling.
+MH once provided a complete email system.
-The community around nmh has the similar understanding that nmh should
+The community around nmh tries to keep nmh in similar shape.
-provide a complete email system.
 In fundamental contrast, mmh shall be an MUA only.
 I believe that the development of all-in-one mail systems is obsolete.
 Today, email is too complex to be fully covered by a single project.
 Such a project will not be able to excel in all aspects.
 Instead, the aspects of email should be covered by multiple projects,
 which then can be combined to form a complete system.
 Excellent implementations for the various aspects of email already exist.
-Just to name three examples: Postfix is a specialized MTA,
+Just to name three examples: Postfix
-.\" XXX homepages verlinken
+.[
-Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
+postfix website
+.]
+is a specialized MTA, Procmail
+.[
+procmail website
+.]
+is a specialized MDA, and Fetchmail
+.[
+fetchmail website
+.]
+is a specialized MRA.
 I believe that it is best to use such specialized tools instead of
-providing the same function again as a side-component in the project.
+providing the same function once more as a side component.
-.\" XXX mail agent picture here
 .P
 Doing something well requires focusing on a small set of specific aspects.
-Under the assumption that development focussed on a particular area
+Under the assumption that development which is focussed on a particular
-produces better results there, specialized projects will be superior
+area produces better results there, specialized projects will be superior
 in their field of focus.
 Hence, all-in-one mail system projects \(en no matter if monolithic
 or modular \(en will never be the best choice in any of the fields.
-Even in providing the best consistent all-in-one system, they are likely
+Even in providing the most consistent all-in-one system, they are likely
-to be beaten by projects that focus only on integrating existing mail
+to be beaten by projects that focus exclusively on the creation
-components to create a homogeneous system.
+of a homogeneous system by integrating existing mail components.
 .P
-The limiting resource in the community development of free software
+Usually, the limiting resource in the community development of
-is usually man power.
+free software is man power.
 .\" XXX FIXME ref!
-If the development power is spread over a large development area,
+If the development effort is spread over a large development area,
-it becomes even more difficult to compete with the specialists in the
+it becomes more difficult to compete with the specialists in the
 various fields.
 The concrete situation for MH-based mail systems is even tougher,
 given their small and aged community, concerning both developers and users.
 .P
 In consequence, I believe that the available development resources
 .H2 "Mail Transfer Facilities
 .Id mail-transfer-facilities
 .P
-In contrast to nmh, which also provides mail submission and mail retrieval
+The removal of the mail transfer facilities, effectively dropping the
-agents, mmh is an MUA only.
+MSA and MRA, had been the first work task in the mmh project.
-This general difference initiated the development of mmh.
+The desire for this change initiated the creation of the mmh project.
-The removal of the mail transfer facilities was the first work task
-in the mmh project.
 .P
 Focusing on one mail agent role only, is motivated by Eric Allman's
 experience with Sendmail.
-He identified the limitation of Sendmail to the MTA task as one reason for
+He identified the limitation of Sendmail
-its success:
+.[
+sendmail website
+.]
+to the MTA task as one reason for its success:
 .[ [
 costales sendmail
 .], p. xviii]
 .QS
 Second, I limited myself to the routing function \(en
 I wouldn't write user agents or delivery back-ends.
-This was a departure of the dominant through of the time,
+This was a departure of the dominant thought of the time,
 in which routing logic, local delivery, and often the network code
 were incorporated directly into the user agents.
 .QE
 .P
 In nmh, the MSA is called \fIMessage Transfer Service\fP (MTS).
 This facility, implemented by the
 .Pn post
-command, established network connections and spoke SMTP to submit
+command, establishes network connections and spoke SMTP to submit
 messages to be relayed to the outside world.
-The changes in email demanded changes in this part of nmh as well.
+When email transfer changed, this part needed to be changed as well.
 Encryption and authentication for network connections
 needed to be supported, hence TLS and SASL were introduced into nmh.
-This added complexity to nmh without improving it in its core functions.
+This added complexity without improving the core functions.
-Also, keeping up with recent developments in the field of
+Furthermore, keeping up with recent developments in the field of
 mail transfer requires development power and specialists.
-In mmh, this whole facility was simply cut off.
+In mmh, this whole facility was simply cut off
 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
-.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
+.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b .
 Instead, mmh depends on an external MSA.
-The only outgoing interface available to mmh is the
+All outgoing mail in mmh goes through the
 .Pn sendmail
 command, which almost any MSA provides.
 If not, a wrapper program can be written.
 It must read the message from the standard input, extract the
 recipient addresses from the message header, and hand the message
 over to the MSA.
-For example, a wrapper script for qmail would be:
+For example, a wrapper script for qmail
+.[
+qmail website
+.]
+would be:
 .VS
 #!/bin/sh
 exec qmail-inject  # ignore command line arguments
 VE
 The requirement to parse the recipient addresses out of the message header
-is likely to be removed in the future.
+may be removed in the future.
-Then mmh would pass the recipient addresses as command line arguments.
+Mmh could pass the recipient addresses as command line arguments.
 This appears to be the better interface.
-.\" XXX implement it
 .P
 To retrieve mail, the
 .Pn inc
-command acted as an MRA.
+command in nmh acts as MRA.
-It established network connections
+It establishes network connections
-and spoke POP3 to retrieve mail from remote servers.
+and speaks POP3 to retrieve mail from remote servers.
 As with mail submission, the network connections required encryption and
-authentication, thus TLS and SASL were added.
+authentication, thus TLS and SASL were added to nmh.
 Support for message retrieval through IMAP will soon become necessary
 additions, too, and likewise for any other changes in mail transfer.
-Not so for mmh because it has dropped the support for retrieving mail
+But not in mmh because it has dropped the support for retrieving mail
-from remote locations.
+from remote locations
-.Ci ab7b48411962d26439f92f35ed084d3d6275459c
+.Ci ab7b48411962d26439f92f35ed084d3d6275459c .
 Instead, it depends on an external tool to cover this task.
 Mmh has two paths for messages to enter mmh's mail storage:
 (1) Mail can be incorporated with
 .Pn inc
 from the system maildrop, or (2) with
 .Pn rcvstore
 by reading them, one at a time, from the standard input.
 .P
-With the removal of the MSA and MRA, mmh converted from an all-in-one
+With the removal of the MSA and MRA, mmh converted from a complete
-mail system to being an MUA only.
+mail system to only an MUA.
 Now, of course, mmh depends on third-party software.
 An external MSA is required to transfer mail to the outside world;
 an external MRA is required to retrieve mail from remote machines.
-Excellent implementations of such software exist,
+Excellent implementations of such software exist.
-which likely are superior than the internal version.
+They likely are superior to the internal versions that were removed.
-Additionally, the best suiting programs can be freely chosen.
+Additionally, the best suiting programs can be chosen freely.
 .P
-As it had already been possible to use an external MSA or MRA,
+As it had already been possible to use an external MSA and MRA,
-why not keep the internal version for convenience?
+why should the internal version not be kept for convenience?
-.\" XXX ueberleitung
+.\" XXX commas correct?
-The question whether there is sense in having a fall-back pager in all
+Transfered to a different area,
+the question whether there is sense in having a fall-back pager in all
 the command line tools, for the cases when
 .Pn more
 or
 .Pn less
 are not available, appears to be ridiculous.
 Of course, MSAs and MRAs are more complex than text pagers
 and not necessarily available but still the concept of orthogonal
-design holds: ``Write programs that do one thing and do it well.''
+design holds: ``Write programs that do one thing and do it well''.
 .[
 mcilroy unix phil
 p. 53
 .]
 .[
 Develop projects that focus on one thing and do it well.
 Projects which have grown complex should be split, for the same
 reasons that programs which have grown complex should be split.
 If it is conceptionally more elegant to have the MSA and MRA as
 separate projects then they should be separated.
-In my opinion, this is the case here.
+In my opinion, this is the case.
-The RFCs propose this separation by clearly distinguishing the different
+The RFCs suggest this separation by clearly distinguishing the
-mail handling tasks [RFC\|821].
+different mail handling tasks [RFC\|821].
-The small interfaces between the mail agents support the separation.
+The small interfaces between the mail agents support the
-.P
+separation as well.
-Email once had been small and simple.
+.P
+Once, email had been small and simple.
 At that time,
 .Pn /bin/mail
 had covered everything there was to email and still was small and simple.
 Later, the essential complexity of email increased.
-(Essential complexity is the complexity defined by the problem itself.\0
+(Essential complexity is the complexity defined by the problem itself.\&
-.[[
+.[ [
 brooks no silver bullet
 .]])
-Email systems reacted to this change: they grew.
+Consequently, email systems grew.
 RFCs started to introduce the concept of mail agents to separate the
-various tasks because they became more extensive and new tasks appeared.
+various roles because they became more extensive and because
-As the mail systems grew even more, parts were split off.
+new roles appeared.
+As mail system implementations grew, parts of them were split off.
 For instance, a POP server was included in the original MH;
 it was removed in nmh.
-Now is the time to go one step further and split off the MSA and MRA, too.
+Now is the time to go one step further and split off the MSA and MRA,
+as well.
 Not only does this decrease the code size of the project,
 more importantly, it unburdens mmh of the whole field of
-message transfer with all its implications for the project.
+message transfer, with all its implications for the project.
 There is no more need for concern with changes in network transfer.
-This independence is gained by depending on an external program
+This independence is gained by depending on external components
-that covers the field.
+that cover the field.
-Today, this is a reasonable exchange.
+.P
-.P
+In general, functionality can be added in three different ways:
-.\" XXX ueberleitung ???
-Functionality can be added in three different ways:
 .LI 1
-Implementing the function in the project itself.
+By implementing the function in the project itself.
 .LI 2
-Depending on a library that provides the function.
+By depending on a library that provides the function.
 .LI 3
-Depending on a program that provides the function.
+By depending on a program that provides the function.
 .LP
 .\" XXX Rework sentence
 While implementing the function in the project itself leads to the
 largest increase in code size and requires the most maintenance
 and development work,
-it increases the project's independence of other software the most.
+it keeps the project's dependence on other software lowest.
 Using libraries or external programs requires less maintenance work
-but introduces dependencies on external software.
+but introduces dependencies on external projects.
 Programs have the smallest interfaces and provide the best separation,
 but possibly limit the information exchange.
 External libraries are more strongly connected than external programs,
 thus information can be exchanged in a more flexible manner.
 Adding code to a project increases maintenance work.
 .\" XXX ref
-Implementing complex functions in the project itself adds
+As implementing complex functions in the project itself adds
-a lot of code.
+a lot of code, this should be avoided if possible.
-This should be avoided if possible.
+Thus, the dependencies only change in their character,
-Hence, the dependencies only change in their character,
 not in their existence.
 In mmh, library dependencies on
 .Pn libsasl2
 and
 .Pn libcrypto /\c
 project's internal versions, the common user even gains functionality.
 .P
 Users of MH should not have problems setting up an external MSA and MRA.
 Also, the popular MSAs and MRAs have large communities and a lot
 of available documentation.
-Choices for MSAs range from full-featured MTAs such as
-.\" XXX refs
+Choices for MSAs range from small forwarders such as
-.I Postfix ,
+.[
-over mid-size MTAs such as
+ssmtp website
-.I masqmail
+.]
-and
+and,
-.I dma ,
+.[
-to small forwarders such as
+nullmailer website
-.I ssmtp
+.]
-and
+over mid-size MTAs including
-.I nullmailer .
+.[
-Choices for MRAs include
+masqmail website
-.I fetchmail ,
+.]
-.I getmail ,
+and,
-.I mpop
+.[
-and
+dma dragonfly mail agent website
-.I fdm .
+.]
+up to full-featured MTAs as for instance.
+.[
+postfix website
+.]
+MRAs are provided for example by
+.[ [
+fetchmail website
+.]
+.[
+getmail website
+.]
+.[
+mpop website
+.]
+.[
+fdm website
+.]].
 .H2 "Non-MUA Tools
 .P
-One goal of mmh is to remove the tools that are not part of the MUA's task.
+One goal of mmh is to remove the tools that do not significantly
-Furthermore, any tools that do not significantly improve the MUA's job
+contribute to the MUA's job.
-should be removed.
+Loosely related and rarely used tools distract from a lean appearance,
-Loosely related and rarely used tools distract from the lean appearance.
+and require maintenance work without adding much to the core task.
-They require maintenance work without adding much to the core task.
+By removing these tools, mmh became more streamlined and focused.
-By removing these tools, the project shall become more streamlined
-and focused.
-In mmh, the following tools are not available anymore:
 .BU
 .Pn conflict
 was removed
 .Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9
-because it is a mail system maintenance tool that is not MUA-related.
+because it is a mail system maintenance tool and not MUA-related.
 It even checked
 .Fn /etc/passwd
 and
 .Fn /etc/group
 for consistency, which is completely unrelated to email.
 because its use case of writing to the user's terminal
 on reception of mail is obsolete.
 If users like to be informed of new mail, the shell's
 .Ev MAILPATH
 variable or graphical notifications are technically more appealing.
-Writing directly to terminals is hardly ever desired today.
+Writing to terminals directly is hardly ever desired today.
 If, though, one prefers this approach, the standard tool
 .Pn write
 can be used in a way similar to:
 .VS
 scan -file - | write `id -un`
 .Pn msgchk
 provided hardly more information than:
 .VS
 ls -l /var/mail/meillo
 VE
-It did distinguish between old and new mail, but
+Yet, it distinguished between old and new mail, but
 these details can be retrieved with
 .Pn stat (1),
 too.
 A small shell script could be written to print the information
 in a similar way, if truly necessary.
 .BU
 .Pn msh
 was removed
 .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
 because the tool was in conflict with the philosophy of MH.
-It provided an interactive shell to access the features of MH,
+It provided an interactive shell to access the features of MH.
-but it was not just a shell tailored to the needs of mail handling.
+However, it was not just a shell tailored to the needs of mail handling,
-Instead, it was one large program that had several MH tools built in.
+but one large program that had several MH tools built in.
-This conflicts with the major feature of MH of being a tool chest.
+This conflicted with the major feature of MH of being a tool chest.
 .Pn msh 's
 main use case had been accessing Bulletin Boards, which have ceased to
 be popular.
 .P
 Removing
 .Pn rcvtty
 and
 .Pn msgchk
 are assumed to be rarely used and can be implemented in different ways,
 why should one keep them?
-Removing them streamlines mmh.
+Removing them streamlined mmh.
 .Pn viamail 's
 use case is now partly obsolete and partly covered by
 .Pn forw ,
-hence there's no reason to still maintain it.
+hence there is no reason to still maintain it.
 .Pn conflict
 is not related to the mail client, and
 .Pn msh
 conflicts with the basic concept of MH.
 These two tools might still be useful, but they should not be part of mmh.
 .P
 Finally, there is
-.Pn slocal .
+.Pn slocal ,
-.Pn slocal
+which is an MDA and thus not directly MUA-related.
-is an MDA and thus not directly MUA-related.
+It should be removed from mmh because including it conflicts with
-It should be removed from mmh, because including it conflicts with
 the idea that mmh is an MUA only.
-.Pn slocal
-should rather become a separate project.
 However,
 .Pn slocal
 provides rule-based processing of messages, like filing them into
 different folders, which is otherwise not available in mmh.
 Although
 .Pn slocal
 would become yet another independent MDA, like
 .I procmail .
 Then
 .Pn slocal
-could be installed without the complete MH system.
+could be installed without a complete MH system.
 Likewise, mmh users could decide to use
 .I procmail
-without having a second, unused MDA,
+without having a second, unused MDA, i.e.
 .Pn slocal ,
 installed.
 That appears to be conceptionally the best solution.
 Yet,
 .Pn slocal
 is not split off.
 I defer the decision over
 .Pn slocal
 out of a need for deeper investigation.
-In the meanwhile, it remains part of mmh.
+In the meanwhile, it remains part of mmh
-However, its continued existence is not significant because
+as its continued existence is not significant;
 .Pn slocal
 is unrelated to the rest of the project.
 .Pn show
 mapped message numbers and sequences to files and invoked
 .Pn mhl
 to have the files formatted.
 With MIME, this approach was not sufficient anymore.
-MIME messages can consist of multiple parts. Some parts are not
+MIME messages can consist of multiple parts.
-directly displayable and text content might be encoded in
+Some parts, like binary attachments or text content in foreign charsets,
-foreign charsets.
+are not directly displayable.
 .Pn show 's
 understanding of messages and
 .Pn mhl 's
 display capabilities could not cope with the task any longer.
 .P
 Instead of extending these tools, additional tools were written from
-scratch and added to the MH tool chest.
+scratch and were added to the MH tool chest.
 Doing so is encouraged by the tool chest approach.
 Modular design is a great advantage for extending a system,
 as new tools can be added without interfering with existing ones.
 First, the new MIME features were added in form of the single program
 .Pn mhn .
 The command
 .Cl "mhn -show 42
-would show the MIME message numbered 42.
+had then shown the message number
+.Fn 42 ,
+interpreting MIME.
 With the 1.0 release of nmh in February 1999, Richard Coleman finished
 the split of
 .Pn mhn
 into a set of specialized tools, which together covered the
 multiple aspects of MIME.
 .Pn show
 or
 .Pn mhshow ,
 whatever was more appropriate.
 .P
-Having two similar tools for essentially the same task is redundant.
+Having two similar tools for basically the same task is redundancy.
-Usually, users would not distinguish between
+Usually, users do not distinguish between
 .Pn show
 and
 .Pn mhshow
 in their daily mail reading.
-Having two separate display programs was therefore mainly unnecessary
+Having two separate display programs was therefore unnecessary
 from a user's point of view.
 Besides, the development of both programs needed to be in sync,
 to ensure that the programs behaved in a similar way,
 because they were used like a single tool.
 Different behavior would have surprised the user.
 .P
 Today, non-MIME messages are rather seen to be a special case of
 MIME messages, although it is the other way round.
 As
 .Pn mhshow
-had already been able to display non-MIME messages, it appeared natural
+already had been able to display non-MIME messages, it appeared natural
 to drop
 .Pn show
 in favor of using
 .Pn mhshow
-exclusively.
+exclusively
-.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
+.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 .
 Removing
 .Pn show
-is no loss in function, because functionally
+is no loss in function, because
 .Pn mhshow
 covers it completely.
-The old behavior of
+Yet, the old behavior of
 .Pn show
 can still be emulated with the simple command line:
 .VS
 mhl `mhpath c`
 VE
 .Pn show
 was gone.
 It is clear that such a rename may confuse future developers when
 trying to understand the history.
 Nevertheless, I consider the convenience on the user's side,
-to call
+to outweigh the inconvenience for understanding the evolution
-.Pn show
+of the tools.
-when they want a message to be displayed, to outweigh the inconvenience
-on the developer's side when understanding the project history.
 .P
 To prepare for the transition,
 .Pn mhshow
 was reworked to behave more like
 .Pn show
-first.
+first (cf. Sec.
-(cf. Sec.
+.Cf mhshow ).
-.Cf mhshow )
 .\" XXX code commits?
 Once the tools behaved more alike, the replacing appeared to be
 even more natural.
 Today, mmh's new
 .Pn show
-has become the one single message display program once more,
+has become the one single message display program once again,
 with the difference
 that today it handles MIME messages as well as non-MIME messages.
-The outcome of the transition is one program less to maintain,
+The outcomes of the transition are one program less to maintain,
 no second display program for users to deal with,
 and less system complexity.
 .P
 Still, removing the old
 .Pn show
 There is the cost of less tested setups, because there are
 more possible setups and especially corner cases.
 Additionally, there is the cost of choice itself.
 The code complexity directly affects the developers.
 Less tested code affects both users and developers.
-The problem of choice affects the users, for once by having to choose,
+The problem of choice affects the users, for once by having to choose
 but also by more complex interfaces that require more documentation.
 Whenever options add few advantages but increase the complexity of the
 system, they should be considered for removal.
 I have reduced the number of project-specific configure options from
-fifteen to three.
+15 to 3.
 .U3 "Mail Transfer Facilities
 .P
-With the removal of the mail transfer facilities five configure
+With the removal of the mail transfer facilities 5 configure
 options vanished:
 .P
 The switches
 .Sw --with-tls
 and
 .Sw --with-cyrus-sasl
 had activated the support for transfer encryption and authentication.
 .\" XXX cf
 .\" XXX gruende kurz wiederholen
-This is not needed anymore.
+They are not needed anymore.
 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
 .P
 .\" XXX cf
 .\" XXX ``For the same reason ...''
 The configure switch
 .Sw --enable-pop
 activated the message retrieval facility.
-The code area that would be conditionally compiled in for TLS and SASL
+Whereas the code area that had been conditionally compiled in
-support had been small.
+for TLS and SASL support was small,
-The conditionally compiled code area for POP support had been much larger.
+the conditionally compiled code area for POP support was much larger.
-Whereas the code base changes would only slightly change on toggling
+The code base had only changed slightly on toggling TLS or SASL
-TLS or SASL support, it changed much on toggling POP support.
+support but it had changed much on toggling POP support.
 The changes in the code base could hardly be overviewed.
 By having POP support togglable, a second code base had been created,
 one that needed to be tested.
 This situation is basically similar for the conditional TLS and SASL
 code, but there the changes are minor and can yet be overviewed.
 of the original program.
 More variations require more testing and maintenance work.
 .P
 Two other options only specified default configuration values:
 .Sw --with-mts
-defined the default transport service.
+defined the default transport service
-.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
+.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 .
 With
 .Sw --with-smtpservers
-default SMTP servers could be specified.
+default SMTP servers could be specified
-.Ci 128545e06224233b7e91fc4c83f8830252fe16c9
+.Ci 128545e06224233b7e91fc4c83f8830252fe16c9 .
 Both of them became irrelevant when the SMTP transport service was removed.
 .\" XXX code ref
 In mmh, all messages are handed over to
 .Pn sendmail
 for transportation.
 .\" XXX Zeitlich ordnen
 In July 2000, Kimmo Suominen introduced
 the configure option
 .Sw --with-hash-backup
 to change the default to the hash character `\f(CW#\fP'.
-The choice was probably personal preference, because first, the
+This choice was probably personal preference, but,
-option was named
+being related or not, words that start with the hash character
-.Sw --with-backup-prefix.
-and had the prefix character as argument.
-But giving the hash character as argument caused too many problems
-for Autoconf,
-thus the option was limited to use the hash character as the default prefix.
-This supports the assumption, that the choice for the hash was
-personal preference only.
-Being related or not, words that start with the hash character
 introduce a comment in the Unix shell.
 Thus, the command line
 .Cl "rm #13 #15
 calls
 .Pn rm
-without arguments because the first hash character starts the comment
+without arguments because the first hash character starts a comment
 that reaches until the end of the line.
 To delete the backup files,
 .Cl "rm ./#13 ./#15"
 needs to be used.
-Using the hash as backup prefix can be seen as a precaution against
+Thus, using the hash as backup prefix may be seen as a precaution
-data loss.
+against backup loss.
 .P
 First, I removed the configure option but added the profile entry
-.Pe backup-prefix ,
+.Pe Backup-Prefix ,
-which allows to specify an arbitrary string as backup prefix.
+which allowed to specify an arbitrary string as backup prefix
-.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
+.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086 .
-Profile entries are the common method to change mmh's behavior.
 This change did not remove the choice but moved it to a location where
-it suited better.
+it suited better, in my eyes.
 .P
-Eventually, however, the new trash folder concept
+Eventually however, the new trash folder concept
 (cf. Sec.
 .Cf trash-folder )
 removed the need for the backup prefix completely.
 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
 .Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
 and,
 .[
 posix 1992
 .]
 respectively.)
-As a first step, these two tools were hard-coded as defaults.
+As a first step, these two tools were hard-coded as defaults
-.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
+.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f .
 Not changed were the
 .Pe editor
 and
 .Pe moreproc
 profile entries, which allowed the user to override the system defaults.
-Later, the concept was reworked to respect the standard environment
+Later, the concept was reworked again to respect the standard
-variables
+environment variables
 .Ev VISUAL
 and
 .Ev PAGER
 if they are set.
 Today, mmh determines the editor to use in the following order,
-taking the first available and non-empty item:
+taking the first available and non-empty item
+.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b :
 .LI 1
 Environment variable
 .Ev MMHEDITOR
 .LI 2
 Profile entry
 .Ev EDITOR
 .LI 5
 Command
 .Pn vi .
 .LP
-.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
+The pager to use is determined in a similar order
-.P
+.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e :
-The pager to use is determined in a similar order,
-also taking the first available and non-empty item:
 .LI 1
 Environment variable
 .Ev MMHPAGER
 .LI 2
 Profile entry
 .Ev PAGER
 .LI 4
 Command
 .Pn more .
 .LP
-.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
-.P
 By respecting the
 .Ev VISUAL /\c
 .Ev EDITOR
 and
 .Ev PAGER
 environment variables,
-the new behavior confirms better to the common style on Unix systems.
+the new behavior complies with the common style on Unix systems.
-Additionally, the new approach is more uniform and clearer to users.
+It is more uniform and clearer for users.
 .U3 "ndbm
 .P
 .Pn slocal
-used to depend on
+used to depend on the database library
-.I ndbm ,
+.I ndbm .
-a database library.
+The database is used to store the
-The database is used to store the `\fLMessage-ID\fP's of all
+.Hd Message-ID
-messages delivered.
+header field values of all messages delivered.
-This enables
+This enabled
 .Pn slocal
 to suppress delivering the same message to the same user twice.
-(This features was enabled by the
+This features was enabled by the
 .Sw -suppressdup
-switch.)
+switch.
 .P
-A variety of versions of the database library exist.
+As a variety of versions of the database library exist,
 .[
 wolter unix incompat notes dbm
 .]
-Complicated autoconf code was needed to detect them correctly.
+complicated autoconf code was needed to detect them correctly.
 Furthermore, the configure switches
 .Sw --with-ndbm=ARG
 and
 .Sw --with-ndbmheader=ARG
 were added to help with difficult setups that would
-not be detected automatically or correctly.
+not be detected automatically or not correctly.
 .P
 By removing the suppress duplicates feature of
 .Pn slocal ,
 the dependency on
 .I ndbm
-vanished and 120 lines of complex autoconf code could be saved.
+vanished and 120 lines of complex autoconf code could be saved
-.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
+.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf .
-The change removed functionality too, but that is minor to the
+The change removed functionality but that is considered minor to the
-improvement by dropping the dependency and the complex autoconf code.
+improvement of dropping the dependency and the complex autoconf code.
 .\" XXX argument: slocal ist sowieso nicht teil vom mmh kern
-.U3 "mh-e Support
+.U3 "MH-E Support
 .P
 The configure option
 .Sw --disable-mhe
-was removed when the mh-e support was reworked.
+was removed when the MH-E support was reworked.
-Mh-e is the Emacs front-end to MH.
+MH-E is the Emacs front-end to MH.
+.[
+mh-e emacs website
+.]
 It requires MH to provide minor additional functions.
 The
 .Sw --disable-mhe
-configure option could switch these extensions off.
+configure option had switched off these extensions.
-After removing the support for old versions of mh-e,
+After removing the support for old versions of MH-E,
 only the
 .Sw -build
 switches of
 .Pn forw
 and
 .Pn repl
-are left to be mh-e extensions.
+are left to be MH-E extensions.
 They are now always built in because they add little code and complexity.
 In consequence, the
 .Sw --disable-mhe
 configure option was removed
-.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
+.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643 .
-Removing the option removed a second code setup that would have
+Dropping the option also removed a variant of the code base
-needed to be tested.
+that would have needed to be tested.
-.\" XXX datum?
+This change was undertaken in January 2012 in nmh and
-This change was first accomplished in nmh and thereafter merged into mmh.
+thereafter merged into mmh.
-.P
-The interface changes in mmh require mh-e to be adjusted in order
-to be able to use mmh as back-end.
-This will require minor changes to mh-e, but removing the
-.Sw -build
-switches would require more rework.
 .U3 "Masquerading
 .P
 The configure option
 .Sw --enable-masquerade
 could take up to three arguments:
-`draft_from', `mmailid', and `username_extension'.
+.Ar draft_from ,
+.Ar mmailid ,
+and
+.Ar username_extension .
 They activated different types of address masquerading.
 All of them were implemented in the SMTP-speaking
 .Pn post
-command, which provided an MSA.
+command.
 Address masquerading is an MTA's task and mmh does not cover
 this field anymore.
 Hence, true masquerading needs to be implemented in the external MTA.
 .P
 The
 available in the original MH.
 It provided a
 .I username
 to
 .I fakeusername
-mapping, based on the password file's GECOS field.
+mapping, based on the
-The man page
+.Fn passwd 's
+GECOS field.
+Nmh's man page
 .Mp mh-tailor (5)
 described the use case as being the following:
 .QS
 This is useful if you want the messages you send to always
 appear to come from the name of an MTA alias rather than your
 specified by the
 .Ev USERNAME_EXTENSION
 environment variable, to it.
 This provided support for the
 .I user-extension
-feature of qmail and the similar
+feature of qmail
+.[ [
+sill qmail handbook
+.], p. 141]
+and the similar
 .I "plussed user
-processing of sendmail.
+processing of Sendmail.
-The decision to remove this username_extension masquerading was
+.[ [
-motivated by the fact that
+sendmail costales
+.], p. 476]
+The decision to remove this username_extension masquerading
+was motivated by the fact that
 .Pn spost
-had not supported it already.
+had not supported it yet.
-.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
+Username extensions can be used in mmh, but less convenient.
-Username extensions are possible in mmh, but less convenient to use.
 .\" XXX covered by next paragraph
 .\" XXX format file %(getenv USERNAME_EXTENSION)
+.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
 .P
 The
 .I draft_from
 masquerading type instructed
 .Pn post
 to use the value of the
 .Hd From
 header field as SMTP envelope sender.
 Sender addresses could be replaced completely.
-.Ci b14ea6073f77b4359aaf3fddd0e105989db9
 Mmh offers a kind of masquerading similar in effect, but
 with technical differences.
 As mmh does not transfer messages itself, the local MTA has final control
-over the sender's address. Any masquerading mmh introduces may be reverted
+over the sender's address.
-by the MTA.
+Any masquerading mmh introduces may be reverted by the MTA.
 In times of pedantic spam checking, an MTA will take care to use
 sensible envelope sender addresses to keep its own reputation up.
 Nonetheless, the MUA can set the
 .Hd From
-header field and thereby propose
+header field and thereby propose a sender address to the MTA.
-a sender address to the MTA.
 The MTA may then decide to take that one or generate the canonical sender
 address for use as envelope sender address.
+.Ci b14ea6073f77b4359aaf3fddd0e105989db9
 .P
 In mmh, the MTA will always extract the recipient and sender from the
 message header (\c
 .Pn sendmail 's
 .Sw -t
 .U3 "Remaining Options
 .P
 Two configure options remain in mmh.
 One is the locking method to use:
 .Sw --with-locking=[dot|fcntl|flock|lockf] .
-The idea of removing all methods except the portable dot locking
+The idea of removing all methods except the portable
+.I "dot locking
 and having that one as the default is appealing, but this change
 requires deeper technical investigation into the topic.
 The other option,
 .Sw --enable-debug ,
-compiles the programs with debugging symbols and does not strip them.
+compiles the programs with debugging symbols.
 This option is likely to stay.
 .H2 "Command Line Switches
 .P
-The command line switches of MH tools are similar to the X Window style.
+The command line switches of MH tools follow a style similar to
+the X Window System style.
 .\" XXX ref
-They consist of a single dash (`\fL-\fP') followed by a word.
+The switches consist of a single dash (`\fL-\fP') followed by a word.
+For example
+.Cl -truncate .
 To ease typing, the word can be abbreviated, given the remaining
-prefix remains unambiguous.
+prefix is unambiguous.
 If no other switch starts with the letter `t', then any of
 .Cl "-truncate" ,
 .Cl "-trunc" ,
 .Cl "-tr" ,
 and
 (with capital `V'), to tell what version of mmh the program belongs to.
 .P
 Switches change the behavior of programs.
 Programs that do one thing in one way require no switches.
 In most cases, doing something in exactly one way is too limiting.
-If there is basically one task to accomplish, but it should be done
+If one task should be accomplished in various ways,
-in various ways, switches are a good approach to alter the behavior
+switches are a good approach to alter the behavior of a program.
-of a program.
 Changing the behavior of programs provides flexibility and customization
-to users, but at the same time it complicates the code, documentation and
+to users, but at the same time it complicates the code,
-usage of the program.
+the documentation, and the usage of the program.
 .\" XXX: Ref
 Therefore, the number of switches should be kept small.
-A small set of well-chosen switches does no harm.
+A small set of well-chosen switches is best.
-But usually, the number of switches increases over time.
+Usually, the number of switches increases over time.
 Already in 1985, Rose and Romine have identified this as a major
 problem of MH:
 .[ [
 rose romine real work
 .], p. 12]
 Unfortunately MH, having undergone six years of off-and-on development by
 ten or so well-meaning programmers (the present authors included),
 suffers mightily from this.
 .QE
 .P
-Being reluctant to adding new switches \(en or `options',
+Being reluctant to adding new switches (or \fIoptions\fP,
-as Rose and Romine call them \(en is one part of a counter-action,
+as Rose and Romine call them) is one part of a counter-action,
 the other part is removing hardly used switches.
-Nmh's tools had lots of switches already implemented,
+Nmh's tools have lots of switches already implemented.
-hence, cleaning up by removing some of them was the more important part
+Hence, cleaning up by removing some of them was the more important part
 of the counter-action.
 Removing existing functionality is always difficult because it
 breaks programs that use these functions.
 Also, for every obsolete feature, there'll always be someone who still
 uses it and thus opposes its removal.
 future needs will demand adding further features,
 worsening the situation more and more.
 Rose and Romine added in a footnote,
 ``[...]
 .Pn send
-will no doubt acquire an endless number of switches in the years to come.''
+will no doubt acquire an endless number of switches in the years to come''
+.[ [
+rose romine real work
+.], p. 12].
 Although clearly humorous, the comment points to the nature of the problem.
 Refusing to add any new switches would encounter the problem at its root,
 but this is not practical.
 New needs will require new switches and it would be unwise to block
 them strictly.
 .Pn send .
 In nmh, they increased up to 32 visible and 12 hidden ones.
 At the time of writing, no more than 4 visible switches and 1 hidden switch
 have remained in mmh's
 .Pn send .
-These numbers include two generic switches,
+These numbers include the two generic switches,
 .Sw -help
 and
 .Sw -Version .
+.P
 Hidden switches are ones not documented.
 In mmh, 12 tools have hidden switches.
 9 of them are
 .Sw -debug
 switches, the other 6 provide special interfaces for internal use.
 .P
-The figure displays the number of switches for each of the tools
+The following figure displays the number of switches for each of the tools
 that is available in both nmh and mmh.
 The tools are sorted by the number of switches they had in nmh.
-Visible and hidden switches were counted,
+Both visible and hidden switches were counted,
 but not the generic help and version switches.
 Whereas in the beginning of the project, the average tool had 11 switches,
 now it has no more than 5 \(en only half as many.
 If the `no' switches and similar inverse variant are folded onto
 their counter-parts, the average tool had 8 switches in pre-mmh times and
 This was the case for network mail transfer, for instance.
 Sometimes, however, the work flow was the other way:
 I looked through the
 .Mp mh-chart (7)
 man page to identify the tools with apparently too many switches.
-Then considering the value of each of the switches by examining
+Then I considered the benefit of each switch by examining
-the tool's man page and source code, aided by recherche and testing.
+the tool's man page and source code, aided by literature research
-This way, the removal of functions was suggested by the aim to reduce
+and testing.
-the number of switches per command.
 .U3 "Draft Folder Facility
 .P
 A change early in the project was the complete transition from
-the single draft message to the draft folder facility.
+the single draft message to the draft folder facility
-.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
 .\" XXX ref to section ...
 The draft folder facility was introduced in the mid-eighties, when
 Rose and Romine called it a ``relatively new feature''.
 .[
 rose romine real work
 .]
-Since then, the facility had existed but was inactive by default.
+Since then, the facility was included, inactive by default.
-The default activation and the related rework of the tools made it
+By making it permanently active and by related rework of the tools, the
-possible to remove the
 .Sw -[no]draftfolder ,
 and
 .Sw -draftmessage
-switches from
+switches could be removed from
 .Pn comp ,
 .Pn repl ,
 .Pn forw ,
 .Pn dist ,
 .Pn whatnow ,
 and
-.Pn send .
+.Pn send
-.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
-The only flexibility removed with this change is having multiple
+The only flexibility lost with this change is having multiple
 draft folders within one profile.
 I consider this a theoretical problem only.
 At the same time, the
 .Sw -draft
 switch of
 .Pn refile ,
 and
 .Pn send
 was removed.
 The special treatment of \fIthe\fP draft message became irrelevant after
-the rework of the draft system.
+the rework of the draft system
 (cf. Sec.
-.Cf draft-folder )
+.Cf draft-folder ).
 Furthermore,
 .Pn comp
 no longer needs a
 .Sw -file
 switch as the draft folder facility together with the
 .P
 .Pn anno
 had the switches
 .Sw -[no]inplace
 to either annotate the message in place and thus preserve hard links,
-or annotate a copy to replace the original message, breaking hard links.
+or annotate a copy to replace the original message.
+The latter approach broke hard links.
 Following the assumption that linked messages should truly be the
-same message, and annotating it should not break the link, the
+same message and annotating it should not break the link, the
 .Sw -[no]inplace
 switches were removed and the previous default
 .Sw -inplace
-was made the only behavior.
+was made the definitive behavior
-.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
+.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0 .
 The
 .Sw -[no]inplace
 switches of
 .Pn repl ,
 .Pn forw ,
 and
 .Pn dist
-could be removed, too, as they were simply passed through to
+could be removed, as well, as they were simply passed through to
 .Pn anno .
 .P
 .Pn burst
 also had
 .Sw -[no]inplace
-switches, but with different meaning.
+switches, but with a different meaning.
 With
 .Sw -inplace ,
 the digest had been replaced by the table of contents (i.e. the
 introduction text) and the burst messages were placed right
 after this message, renumbering all following messages.
 Also, any trailing text of the digest was lost, though,
 in practice, it usually consists of an end-of-digest marker only.
-Nontheless, this behavior appeared less elegant than the
+Nonetheless, this behavior appeared less elegant than the
 .Sw -noinplace
 behavior, which already had been the default.
 Nmh's
 .Mp burst (1)
 man page reads:
 switches as well to supply the contents of a form file as a string
 on the command line directly.
 In consequence, the following two lines equaled:
 .VS
 scan -form scan.mailx
-scan -format "`cat .../scan.mailx`"
+scan -format "`cat /path/to/scan.mailx`"
 VE
 The
 .Sw -format
 switches were dropped in favor for extending the
 .Sw -form
-switches.
+switches
-.Ci f51956be123db66b00138f80464d06f030dbb88d
+.Ci f51956be123db66b00138f80464d06f030dbb88d .
-If their argument starts with an equal sign (`='),
+If their argument starts with an equal sign (`\fL=\fP'),
 then the rest of the argument is taken as a format string,
 otherwise the arguments is treated as the name of a format file.
 Thus, now the following two lines equal:
 .VS
 scan -form scan.mailx
-scan -form "=`cat .../scan.mailx`"
+scan -form "=`cat /path/to/scan.mailx`"
 VE
 This rework removed the prefix collision between
 .Sw -form
 and
 .Sw -format .
-Now, typing
+Typing `\fL-fo\fP' is sufficient to specify form file or format string.
-.Sw -fo
-suffices to specify form or format string.
 .P
 The different meaning of
 .Sw -format
 for
+.Pn forw
+and
 .Pn repl
-and
-.Pn forw
 was removed in mmh.
 .Pn forw
 was completely switched to MIME-type forwarding, thus removing the
-.Sw -[no]format .
+.Sw -[no]format
-.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
+.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 .
 For
 .Pn repl ,
 the
 .Sw -[no]format
 switches were reworked to
 .Sw -[no]filter
-switches.
+switches
-.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
+.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 .
 The
 .Sw -format
 switches of
 .Pn send
 and
 .Pn post ,
-which had a third meaning,
+which had a third meaning, were removed likewise
-were removed likewise.
+.Ci f3cb7cde0e6f10451b6848678d95860d512224b9 .
-.Ci f3cb7cde0e6f10451b6848678d95860d512224b9
 Eventually, the ambiguity of the
 .Sw -format
-switches was resolved by not anymore having any such switch in mmh.
+switches is resolved by not having such switches anymore in mmh.
 .U3 "MIME Tools
 .P
-The MIME tools, which were once part of
+The MIME tools, which once were part of
 .Pn mhn
-.\" XXX
 (whatever that stood for),
 had several switches that added little practical value to the programs.
 The
 .Sw -[no]realsize
 switches of
 .Pn mhbuild
 and
 .Pn mhlist
-were removed, doing real size calculations always now
+were removed
-.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
+.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c .
-as nmh's
+Real size calculations are done always now because nmh's
 .Mp mhbuild (1)
-man page states
+man page states that
-``This provides an accurate count at the expense of a small delay.''
+``This provides an accurate count at the expense of a small delay''
-This small delay is not noticable on modern systems.
+with the small delay not being noticable on modern systems.
 .P
 The
 .Sw -[no]check
 switches were removed together with the support for
 .Hd Content-MD5
-header fields [RFC\|1864].
+header fields [RFC\|1864]
-.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
 (cf. Sec.
 .Cf content-md5 )
+.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda .
 .P
 The
 .Sw -[no]ebcdicsafe
 and
 .Sw -[no]rfc934mode
 switches of
 .Pn mhbuild
-were removed because they are considered obsolete.
+were removed because they are considered obsolete
 .Ci 01a3480928da485b4d6109d36d751dfa71799d58
-.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88
+.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88 .
 .P
 Content caching of external MIME parts, activated with the
 .Sw -rcache
 and
 .Sw -wcache
-switches was completely removed.
+switches was completely removed
-.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
+.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269 .
 External MIME parts are rare today, having a caching facility
 for them appears to be unnecessary.
 .P
 In pre-MIME times,
 .Pn mhl
 had covered many tasks that are part of MIME handling today.
 Therefore,
 .Pn mhl
 could be simplified to a large extend, reducing the number of its
-switches from 21 to 6.
+switches from 21 to 6
 .Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6
-.Ci 0e46503be3c855bddaeae3843e1b659279c35d70
+.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 .
 .U3 "Header Printing
 .Pn folder 's
 data output is self-explaining enough that
 displaying the header line makes little sense.
 Hence, the
 .Sw -[no]header
-switch was removed and headers are never printed.
+switch was removed and headers are never printed
-.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
+.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7 .
 .P
 In
 .Pn mhlist ,
 the
 .Sw -[no]header
-switches were removed, too.
+switches were removed, as well
-.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f
+.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f .
-But in this case headers are always printed,
+In this case, the headers are printed always because the output
-because the output is not self-explaining.
+is not self-explaining.
 .P
 .Pn scan
 also had
 .Sw -[no]header
 switches.
-Printing the header had been sensible until the introduction of
+Printing this header had been sensible until the introduction of
-format strings made it impossible to display the column headings.
+format strings made it impossible to display column headings.
 Only the folder name and the current date remained to be printed.
-As this information can be perfectly retrieved by
+As this information can be perfectly generated with
 .Pn folder
 and
 .Pn date ,
-consequently, the switches were removed.
+the switches were removed
-.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e
+.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e .
 .P
 By removing all
 .Sw -header
 switches, the collision with
 .Sw -help
 .Pn repl ,
 .Pn forw ,
 .Pn dist ,
 and
 .Pn whatnow
-was removed, but it can now be replaced by specifying
+was removed and replaced by specifying
 .Sw -editor
-with an empty argument.
+with an empty argument
-.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
+.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9 .
 (Specifying
 .Cl "-editor /bin/true
-is nearly the same, only differing by the previous editor being set.)
+is nearly the same. It differs only in setting the previous editor.)
 .P
 The more important change is the removal of the
 .Sw -nowhatnowproc
-switch.
+switch
-.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622
+.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622 .
-This switch had introduced an awkward behavior, as explained in nmh's
+This switch had once introduced an awkward behavior,
-man page for
+as explained in nmh's man page for
 .Mp comp (1):
 .QS
 The
 .Sw -editor
 .Ar editor
 will prevent any edit from occurring.)
 .QE
 .P
 Effectively, the
 .Sw -nowhatnowproc
-switch creates only a draft message.
+switch caused only only a draft message to be created.
 As
 .Cl "-whatnowproc /bin/true
-causes the same behavior, the
+does the same, the
 .Sw -nowhatnowproc
 switch was removed for being redundant.
-Likely, the
-.Sw -nowhatnowproc
-switch was intended to be used by front-ends.
 .U3 "Various
 .BU
 no longer needed their
 .Sw -mbox
 and
 .Sw -mmdf
 switches.
+The behavior of
 .Sw -mbox
-is the sole behavior now.
+is the sole behavior now
-.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
+.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 .
 Further rework in both tools made the
 .Sw -file
-switch unnecessary.
+switch unnecessary
-.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e
+.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e .
 .BU
-Mmh's tools will no longer clear the screen (\c
+Mmh's tools do no longer clear the screen (\c
 .Pn scan 's
 and
 .Pn mhl 's
 .Sw -[no]clear
 switches
 .Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270
 .Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ).
-Neither will
+Neither does
 .Pn mhl
 ring the bell (\c
 .Sw -[no]bell
 .Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
-nor page the output itself (\c
+nor does it page the output itself (\c
 .Sw -length
 .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
 .\" XXX Ref
 Generally, the pager to use is no longer specified with the
 .Sw -[no]moreproc
 command line switches for
 .Pn mhl
 and
 .Pn show /\c
-.Pn mhshow .
+.Pn mhshow
-.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a
+.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a .
 .BU
 In order to avoid prefix collisions among switch names, the
 .Sw -version
 switch was renamed to
 .Sw -Version
-(with capital `V').
+(with capital `V')
-.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
+.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a .
 Every program has the
 .Sw -version
 switch but its first three letters collided with the
 .Sw -verbose
 switch, present in many programs.
 The removal of the
 .Sw -[no]reverse
 switches of
 .Pn scan
 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
-is a bug fix, supported by the comments
+is a bug fix.
+This is supported by the comments
 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
 by Rose and
 ``Lists messages in reverse order with the `\-reverse' switch.
-This should be considered a bug.'' by Romine in the documentation.
+This should be considered a bug'' by Romine in the changelogs.
-.\" XXX Ref: welche datei genau.
+The question remains why neither Rose nor Romine have fixed this
-The question remains why neither Rose and Romine had fixed this
+bug in the eighties when they wrote these comments.
-bug in the eighties when they wrote these comments nor has anyone
-thereafter.
-.ig
-forw: [no]dashstuffing(mhl)
-mhshow: [no]pause [no]serialonly
-mhmail: resent queued
-inc: snoop, (pop)
-mhl: [no]faceproc folder sleep
-	[no]dashstuffing(forw) digest list volume number issue number
-prompter: [no]doteof
-refile: [no]preserve [no]unlink [no]rmmproc
-send: [no]forward [no]mime [no]msgid
-	[no]push split [no]unique (sasl) width snoop [no]dashstuffing
-	attach attachformat
-whatnow: (noedit) attach
-slocal: [no]suppressdups
-spost: [no]filter [no]backup width [no]push idanno
-	[no]check(whom) whom(whom)
-whom: ???
-..
-.ig
-.P
-In the best case, all switches are unambiguous on the first character,
-or on the three-letter prefix for the `no' variants.
-Reducing switch prefix collisions, shortens the necessary prefix length
-the user must type.
-Having less switches helps best.
-..
-.\" XXX: whatnow prompt commands
 .\" --------------------------------------------------------------
 .P
 In the more than thirty years of MH's existence, its code base was
 increasingly extended.
 New features entered the project and became alternatives to the
 existing behavior.
-Relics from several decades have gathered in the code base,
+Relics from several decades have gathered in the code base
 but seldom obsolete features were dropped.
 This section describes the removing of old code
 and the modernizing of the default setup.
 It focuses on the functional aspect only;
 the non-functional aspects of code style are discussed in Sec.
 .Cf code-style .
 .H2 "Code Relics
 .P
-My position regarding the removal of obsolete functions of mmh,
+My position regarding the removal of obsolete code
-.\" XXX ``in order to remove old code,''
 is much more revolutional than the nmh community appreciates.
-Working on an experimental version, I was quickly able to drop
+Working on an experimental version, I was able to quickly drop
-functionality I considered ancient.
+functionality that I considered ancient.
 The need for consensus with peers would have slowed this process down.
 Without the need to justify my decisions, I was able to rush forward.
+.P
 In December 2011, Paul Vixie motivated the nmh developers to just
-.\" XXX ugs
 do the work:
 .[
 paul vixie edginess nmh-workers
 .]
 .QS
 I rather include falsely dropped parts again, than going at a slower pace.
 Mmh is experimental work; it requires tough decisions.
 .\" XXX ``exp. work'' schon oft gesagt
-.U3 "Forking
+.U3 "Process Forking
 .P
 Being a tool chest, MH creates many processes.
 In earlier times
 .Fu fork()
 had been an expensive system call, because the process's image needed
 nmh-workers vixie edginess
 .]
 I replaced all calls to
 .Fu vfork()
 with calls to
-.Fu fork() .
+.Fu fork()
-.Ci 40821f5c1316e9205a08375e7075909cc9968e7d
+.Ci 40821f5c1316e9205a08375e7075909cc9968e7d .
 .P
 Related to the costs of
 .Fu fork()
 is the probability of its success.
 In the eighties, on heavy loaded systems, calls to
 were prone to failure.
 Hence, many of the
 .Fu fork()
 calls in the code were wrapped into loops to retry the
 .Fu fork()
-several times, to increase the chances to succeed, eventually.
+several times, to increase the chances to succeed eventually.
 On modern systems, a failing
 .Fu fork()
 call is unusual.
 Hence, in the rare case when
 .Fu fork()
-fails, mmh programs simply abort.
+fails, mmh programs simply abort
-.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6
+.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6 .
 .U3 "Header Fields
 .BU
 The
 but already marked as legacy in RFC\|2822.
 Today, OpenPGP provides the basis for standardized exchange of encrypted
 messages [RFC\|4880, RFC\|3156].
 Hence, the support for
 .Hd Encrypted
-header fields is removed in mmh.
+header fields is removed in mmh
-.Ci 064527f7b57ab050e5af13e15ad99aeeab125857
+.Ci 064527f7b57ab050e5af13e15ad99aeeab125857 .
 .BU
 The native support for
 .Hd Face
-header fields has been removed, as well.
+header fields has been removed, as well
-.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23
+.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23 .
 This feature is similar to the
 .Hd X-Face
 header field in its intent,
 but takes a different approach to store the image.
 Instead of encoding the image data directly into the header field,
 There is even a third Face system,
 which is the successor of
 .Hd X-Face ,
 although it re-uses the
 .Hd Face
-header field.
+header field name.
 It was invented in 2005 and supports colored PNG images.
 None of the Face systems described here is popular today.
 Hence, mmh has no direct support for them.
 .BU
 .Id content-md5
 The TCP includes a checksum field therefore.
 These two approaches in combinations render the
 .Hd Content-MD5
 header field superfluous.
 Not a single one out of 4\|200 messages from two decades
-in an nmh-workers mailing list archive contains a
+in the nmh-workers mailing list archive
+.[
+nmh-workers mailing list archive website
+.]
+contains a
 .Hd Content-MD5
 header field.
 Neither did any of the 60\|000 messages in my personal mail storage.
-Removing the support for this header field,
+Removing the support for this header field
+.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda ,
 removed the last place where MD5 computation was needed.
-.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
 Hence, the MD5 code could be removed as well.
 Over 500 lines of code vanished by this one change.
 .U3 "MMDF maildrop support
 .P
-This type of format is conceptionally similar to the mbox format,
+This type of maildrop format is conceptionally similar to the mbox format,
 but uses a different message delimiter (`\fL\\1\\1\\1\\1\fP',
 commonly written as `\fL^A^A^A^A\fP', instead of `\fLFrom\0\fP').
 Mbox is the de-facto standard maildrop format on Unix,
 whereas the MMDF maildrop format is now forgotten.
-By dropping the MMDF maildrop format support,
+Mbox remains as the only packed mailbox format, supported in mmh.
-mbox became the only packed mailbox format supported in mmh.
 .P
 The simplifications within the code were moderate.
 Mainly, the reading and writing of MMDF mailbox files was removed.
 But also, switches of
 .Pn packf
 and
 .Pn rcvpack
-could be removed.
+could be removed
-.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
+.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 .
 In the message parsing function
 .Fn sbr/m_getfld.c ,
-knowledge of MMDF packed mail boxes was removed.
+knowledge of MMDF packed mail boxes was removed
-.Ci 684ec30d81e1223a282764452f4902ed4ad1c754
+.Ci 684ec30d81e1223a282764452f4902ed4ad1c754 .
 Further code structure simplifications may be possible there,
 because only one single packed mailbox format is left to be supported.
 I have not worked on them yet because
 .Fu m_getfld()
 is heavily optimized and thus dangerous to touch.
 .U3 "Prompter's Control Keys
 .P
 The program
 .Pn prompter
 queries the user to fill in a message form.
-When used by
+When used as
-.Pn comp
-as
 .Cl "comp -editor prompter" ,
 the resulting behavior is similar to
 .Pn mailx .
 Apparently,
 .Pn prompter
 .H2 "Attachments
 .P
 The mind model of email attachments is unrelated to MIME.
-Although the MIME RFCs [RFC\|2045\(enRFC\|2049] define the technical
+Although the MIME RFCs [RFC\|2045\(en2049] define the technical
-requirements for having attachments, they do not mention the word
+requirements for having attachments, they do not mention the term.
-attachment.
 Instead of attachments, MIME talks about ``multi-part message bodies''
 [RFC\|2045], a more general concept.
 Multi-part messages are messages
 ``in which one or more different
 sets of data are combined in a single body''
 [RFC\|2046].
 MIME keeps its descriptions generic;
 it does not imply specific usage models.
-One usage model became prevalent: attachments.
+Today, one usage model is prevalent: attachments.
 The idea is having a main text document with files of arbitrary kind
 attached to it.
 In MIME terms, this is a multi-part message having a text part first
 and parts of arbitrary type following.
 .P
 .U3 "Composing MIME Messages
 .P
 In order to improve the situation on the message composing side,
-Jon Steinhart had added an attachment system to nmh in 2002.
+Jon Steinhart had added an attachment system to nmh in 2002
-.Ci 7480dbc14bc90f2d872d434205c0784704213252
+.Ci 7480dbc14bc90f2d872d434205c0784704213252 .
 In the file
 .Fn docs/README-ATTACHMENTS ,
-he described his motivation to do so as such:
+he described his motivation to do so:
 .QS
 Although nmh contains the necessary functionality for MIME message
 handing [sic!], the interface to this functionality is pretty obtuse.
 There's no way that I'm ever going to convince my partner to write
 .Pn mhbuild
 They allow attachments to be added, listed, and deleted.
 MIME messages are automatically created when drafts with attachments
 are sent.
 .QE
 .LP
-Unfortunately, the attachment system,
+Unfortunately, the attachment system, like every new facilities in nmh,
-like any new facilities in nmh,
 was inactive by default.
 .P
-During my work in Argentina, I tried to improve the attachment system.
+During my time in Argentina, I tried to improve the attachment system.
-But, because of great opposition in the nmh community,
+But, after long discussions my patch died as a proposal on the
-my patch died as a proposal on the mailing list, after long discussions.
+mailing list because of great opposition in the nmh community.
 .[
 nmh-workers attachment proposal
 .]
-In January 2012, I extended the patch and applied it to mmh.
+In January 2012, I extended the patch and applied it to mmh
-.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
+.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 .
 In mmh, the attachment system is active by default.
 Instead of command line switches, the
 .Pe Attachment-Header
 profile entry is used to specify
 the name of the attachment header field.
 If the attachment header value starts with a plus character (`\fL+\fP'),
 like in
 .Cl "Attach: +bob 30 42" ,
 the given messages in the specified folder will be attached.
 This allowed to simplify
-.Pn forw .
+.Pn forw
-.Ci f41f04cf4ceca7355232cf7413e59afafccc9550
+.Ci f41f04cf4ceca7355232cf7413e59afafccc9550 .
 .P
 Closely related to attachments is non-ASCII text content,
-because it requires MIME too.
+because it requires MIME as well.
 In nmh, the user needed to call `mime' at the WhatNow prompt
 to have the draft converted to MIME.
 This was necessary whenever the draft contained non-ASCII characters.
 If the user did not call `mime', a broken message would be sent.
 Therefore, the
 .P
 Although the new approach does not anymore support arbitrary MIME
 compositions directly, the full power of
 .Pn mhbuild
 can still be accessed.
-Given no attachment headers are included, the user can create
+Given no attachment headers are included, users can create
 .Pn mhbuild
 composition drafts like in nmh.
-Then, at the WhatNow prompt, he needs to invoke
+Then, at the WhatNow prompt, they can invoke
 .Cl "edit mhbuild
-to convert it to MIME.
+to convert the draft to MIME.
-Because the resulting draft does neither contain non-ASCII characters
+Because the resulting draft neither contains non-ASCII characters
 nor has it attachment headers, the attachment system will not touch it.
 .P
 The approach taken in mmh is tailored towards today's most common case:
 a text part, possibly with attachments.
 This case was simplified.
 .P
 From the programmer's point of view, the use of
 .Pn mhbuild
 composition drafts had one notable advantage over attachment headers:
 The user provides the appropriate MIME types for files to include.
-The attachment system needs to find out the correct MIME type itself.
+The new attachment system needs to find out the correct MIME type itself.
-This is a difficult task, yet it spares the user irritating work.
+This is a difficult task.
 Determining the correct MIME type of content is partly mechanical,
 partly intelligent work.
 Forcing the user to find out the correct MIME type,
 forces him to do partly mechanical work.
 Letting the computer do the work can lead to bad choices for difficult
 content.
-For mmh, the latter option was chosen.
+For mmh, the latter option was chosen to spare the user the work
+.Ci 3baec236a39c5c89a9bda8dbd988d643a21decc6 .
 .P
 Determining the MIME type by the suffix of the file name is a dumb
 approach, yet it is simple to implement and provides good results
 for the common cases.
+If no MIME type can be determined, text content is sent as `text/plain',
+anything else under the generic fall-back type `application/octet-stream'.
 Mmh implements this approach in the
 .Pn print-mimetype
-script.
+script
-.Ci 4b5944268ea0da7bb30598a27857304758ea9b44
+.Ci 4b5944268ea0da7bb30598a27857304758ea9b44 .
-Using it is the default choice.
 .P
 A far better, though less portable, approach is the use of
 .Pn file .
 This standard tool tries to determine the type of files.
 Unfortunately, its capabilities and accuracy varies from system to system.
 Additionally, its output was only intended for human beings,
 but not to be used by programs.
-It varies much.
 Nevertheless, modern versions of GNU
 .Pn file ,
-which is prevalent on the popular GNU/Linux systems,
+which are prevalent on the popular GNU/Linux systems,
 provide MIME type output in machine-readable form.
-Although this solution is highly system-dependent,
+Although this solution is system-dependent,
 it solves the difficult problem well.
 On systems where GNU
 .Pn file ,
 version 5.04 or higher, is available it should be used.
 One needs to specify the following profile entry to do so:
-.Ci 3baec236a39c5c89a9bda8dbd988d643a21decc6
 .VS
 Mime-Type-Query: file -b --mime
 VE
 .LP
 Other versions of
 .Pn file
-might possibly be usable with wrapper scripts to reformat the output.
+might possibly be usable with wrapper scripts that reformat the output.
 The diversity among
 .Pn file
 implementations is great; one needs to check the local variant.
 .P
-If no MIME type can be determined, text content gets sent as
-`text/plain' and anything else under the generic fall-back type
-`application/octet-stream'.
 It is not possible in mmh to override the automatic MIME type guessing
 for a specific file.
 To do so, either the user would need to know in advance for which file
-the automatic guessing fails, or the system would require interaction.
+the automatic guessing fails or the system would require interaction.
 I consider both cases impractical.
 The existing solution should be sufficient.
 If not, the user may always fall back to
 .Pn mhbuild
-composition drafts and ignore the attachment system.
+composition drafts and bypass the attachment system.
 .U3 "Storing Attachments
 .P
 Extracting MIME parts of a message and storing them to disk is performed by
 .Ci 41b6eadbcecf63c9a66aa5e582011987494abefb
 .LI 2
 Tar files are not extracted automatically any more.
 Thus, the rest of the file system will not be touched.
 .Ci 94c80042eae3383c812d9552089953f9846b1bb6
-.LP
+.P
-Now, the outcome of mmh's
+In mmh, the result of
 .Cl "mhstore -auto
 can be foreseen from the output of
 .Cl "mhlist -verbose" .
-.P
+Although the
-The
 .Sw -noauto
-mode is seen to be more powerful but less convenient.
+mode is considered to be more powerful, it is less convenient and
-On the other hand,
 .Sw -auto
-is safe now and
+is safe now.
-storing attachments under their original name is intuitive.
+Additionally, storing attachments under their original name
+is intuitive.
 Hence,
 .Sw -auto
-serves better as the default option.
+serves better as the default option
-.Ci 3410b680416c49a7617491af38bc1929855a331d
+.Ci 3410b680416c49a7617491af38bc1929855a331d .
 .P
 Files are stored into the directory given by the
 .Pe Nmh-Storage
 profile entry, if set, or
 into the current working directory, otherwise.
 Storing to different directories is only possible with
 .Pe mhstore-store-*
 profile entries.
 .P
-Still, in both modes, existing files get overwritten silently.
+Still existing files get overwritten silently in both modes.
 This can be considered a bug.
 Yet, each other behavior has its draw-backs, too.
 Refusing to replace files requires adding a
 .Sw -force
-option.
+switch.
 Users will likely need to invoke
 .Pn mhstore
 a second time with
 .Sw -force .
 Eventually, only the user can decide in the specific case.
 The same applies to message/partial, although the parts are
 automatically reassembled beforehand.
 MIME parts of type message/external-body are not automatically retrieved
 anymore.
 Instead, information on how to retrieve them is output.
-Not supporting this rare case saved nearly one thousand lines of code.
+Not supporting this rare case saved nearly one thousand lines of code
-.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
+.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32 .
 .\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
 .\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
-`application/octet-stream; type=tar' is not special anymore.
+The MIME type `application/octet-stream; type=tar' is not special anymore.
-Automatically extracting such MIME parts had been the dangerous part
+The automatically extracting of such MIME parts had been the
-of the
+dangerous part of the
 .Sw -auto
-mode.
+mode
-.Ci 94c80042eae3383c812d9552089953f9846b1bb6
+.Ci 94c80042eae3383c812d9552089953f9846b1bb6 .
 .U3 "Showing MIME Messages
 .P
 The program
 .Pn mhshow
-had been written to display MIME messages.
+was written to display MIME messages.
 It implemented the conceptional view of the MIME RFCs.
 Nmh's
 .Pn mhshow
-handled each MIME part independently, presenting them separately
+handles each MIME part independently, presenting them separately
 to the user.
 This does not match today's understanding of email attachments,
 where displaying a message is seen to be a single, integrated operation.
 Today, email messages are expected to consist of a main text part
 plus possibly attachments.
-They are not any more seen to be arbitrary MIME hierarchies with
+They are no more seen to be arbitrary MIME hierarchies with
 information on how to display the individual parts.
 I adjusted
 .Pn mhshow 's
 behavior to the modern view on the topic.
 .P
-One should note that this section completely ignores the original
+(One should note that this section completely ignores the original
 .Pn show
 program, because it was not capable to display MIME messages
 and is no longer part of mmh.
 .\" XXX ref to other section
 Although
 .Pn mhshow
 was renamed to
 .Pn show
 in mmh, this section uses the name
 .Pn mhshow ,
-in order to avoid confusion.
+in order to avoid confusion.)
 .P
 In mmh, the basic idea is that
 .Pn mhshow
 should display a message in one single pager session.
 Therefore,
 .Pn mhshow
 invokes a pager session for all its output,
-whenever it prints to a terminal.
+whenever it prints to a terminal
-.Ci a4197ea6ffc5c1550e8b52d5a654bcaaaee04a4e
+.Ci a4197ea6ffc5c1550e8b52d5a654bcaaaee04a4e .
 In consequence,
 .Pn mhl
-does no more invoke a pager.
+does no more invoke a pager
-.Ci 0e46503be3c855bddaeae3843e1b659279c35d70
+.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 .
 With
 .Pn mhshow
 replacing the original
 .Pn show ,
-output from
+the output of
 .Pn mhl
-does not go to the terminal directly, but through
+no longer goes to the terminal directly, but through
 .Pn mhshow .
 Hence,
 .Pn mhl
 does not need to invoke a pager.
 The one and only job of
 .Pn mhl
 is to format messages or parts of them.
 The only place in mmh, where a pager is invoked is
 .Pn mhshow .
 .P
+In the intended setup, only text content is be displayed,
+in a single pager session.
+Non-text content needs to be converted to text by appropriate
+.Pe mhshow-show-*
+profile entries before, if this is possible and wanted.
+A common example for this are PDF files.
+.ig \"XXX
 .Pe mhshow-show-*
 profile entries can be used to display MIME parts in a specific way.
-For instance, PDF and Postscript files could be converted to plain text
 to display them in the terminal.
-In mmh, MIME parts will always be displayed serially.
+..
+In mmh, MIME parts are always displayed serially.
 The request to display the MIME type `multipart/parallel' in parallel
 is ignored.
-It is simply treated as `multipart/mixed'.
+It is simply treated as `multipart/mixed'
-.Ci d0581ba306a7299113a346f9b4c46ce97bc4cef6
+.Ci d0581ba306a7299113a346f9b4c46ce97bc4cef6 .
-This could already be requested with the, now removed,
+This was already possible to requested with the, now removed,
 .Sw -serialonly
 switch of
 .Pn mhshow .
 As MIME parts are always processed exclusively, i.e. serially,
-the `%e' escape in
+the `\fL%e\fP' escape in
 .Pe mhshow-show-*
-profile entries became useless and was thus removed.
+profile entries became useless and was thus removed
-.Ci a20d405db09b7ccca74d3e8c57550883da49e1ae
+.Ci a20d405db09b7ccca74d3e8c57550883da49e1ae .
 .P
-In the intended setup, only text content would be displayed.
-Non-text content would be converted to text by appropriate
-.Pe mhshow-show-*
-profile entries before, if possible and wanted.
-All output would be displayed in a single pager session.
 Other kinds of attachments are ignored.
 With
 .Pe mhshow-show-*
 profile entries for them, they can be displayed serially along
 the message.
 .P
 To display text content in foreign charsets, they need to be converted
 to the native charset.
 Therefore,
 .Pe mhshow-charset-*
-profile entries used to be needed.
+profile entries were needed.
 In mmh, the conversion is performed automatically by piping the
 text through the
 .Pn iconv
-command, if necessary.
+command, if necessary
-.Ci 2433122c20baccb10b70b49c04c6b0497b5b3b60
+.Ci 2433122c20baccb10b70b49c04c6b0497b5b3b60 .
 Custom
 .Pe mhshow-show-*
 rules for textual content might need a
 .Cl "iconv -f %c %f |
 prefix to have the text converted to the native charset.
 .H2 "Signing and Encrypting
 .P
 Nmh offers no direct support for digital signatures and message encryption.
 This functionality needed to be added through third-party software.
-In mmh, the functionality should be included because it
+In mmh, the functionality is included because it
-is a part of modern email and likely wanted by users of mmh.
+is a part of modern email and is likely wanted by users of mmh.
-A fresh mmh installation should support signing and encrypting
+A fresh mmh installation supports signing and encrypting
 out-of-the-box.
 Therefore, Neil Rickert's
 .Pn mhsign
 and
 .Pn mhpgp
 scripts
 .[
 neil rickert mhsign mhpgp
 .]
-were included into mmh
+were included
 .Ci f45cdc98117a84f071759462c7ae212f4bc5ab2e
 .Ci 58cf09aa36e9f7f352a127158bbf1c5678bc6ed8 .
 The scripts fit well because they are lightweight and
 similar of style to the existing tools.
-Additionally, no licensing difficulties appeared,
+Additionally, no licensing difficulties appeared
 as they are part of the public domain.
 .P
 .Pn mhsign
 handles the signing and encrypting part.
 It comprises about 250 lines of shell code and interfaces between
-.Pn gnupg
+.Pn gnupg "
-and
+.[
-the MH system.
+gnupg website
+.]
+and the MH system.
 It was meant to be invoked manually at the WhatNow prompt, but in mmh,
 .Pn send
 invokes
-.pn mhsign
+.Pn mhsign
 automatically
 .Ci c7b5e1df086bcc37ff40163ee67571f076cf6683 .
 Special header fields were introduced to request this action.
 If a draft contains the
 .Hd Sign
 header field,
 .Pn send
 will initiate the signing.
-The signing key is either chosen automatically or specified by the
+The signing key is either chosen automatically or it is specified by the
 .Pe Pgpkey
 profile entry.
 .Pn send
-always create signatures using the PGP/MIME standard, \" REF XXX
+always create signatures using the PGP/MIME standard [RFC\|4880],
-but by manually invoking
+but by invoking
-.Pn mhsign ,
+.Pn mhsign
-old-style non-MIME signatures can be created as well.
+manually, old-style non-MIME signatures can be created as well.
 To encrypt an outgoing message, the draft needs to contain an
 .Hd Enc
 header field.
 Public keys of all recipients are searched for in the gnupg keyring and
 in a file called
 .P
 .Pn mhpgp
 is the companion to
 .Pn mhsign .
 It verifies signatures and decrypts messages.
-Encrypted messages can either be temporarily decrypted for display
+Encrypted messages can be either temporarily decrypted and displayed
 or permanently decrypted and stored into the current folder.
 Currently,
 .Pn mhpgp
 needs to be invoked manually.
 The integration into
 .Pn show
 and
 .Pn mhstore
-to verify signatures and decrypt messages as needs
+to verify signatures and decrypt messages as needed
-is planned but not realized yet.
+is planned but not yet realized.
 .P
-Both scripts were written for nmh, hence they needed to be adjust
+Both scripts were written for nmh.
+Hence they needed to be adjust
 according to the differences between nmh and mmh.
 For instance, they use the backup prefix no longer.
 Furthermore, compatibility support for old PGP features was dropped.
 .P
 The integrated message signing and encrypting support is one of the
 most recent features in mmh.
-It has not yet had the time to mature.
+It has not had the time to mature.
 User feedback and personal experience need to be accumulated to
 direct the further development of the facility.
-Although the feedback and experience is still missing,
+Already it seems to be worthwhile to consider adding
-it seems to be worthwhile to consider adding
 .Sw -[no]sign
 and
 .Sw -[no]enc
 switches to
 .Pn send ,
 .U3 "Draft Folder
 .Id draft-folder
 .P
 In the beginning, MH had the concept of a draft message.
-This is the file
+This was a file named
 .Fn draft
-in the MH directory, which is treated special.
+in the MH directory, which was treated special.
 On composing a message, this draft file was used.
 When starting to compose another message before the former one was sent,
 the user had to decide among:
 .LI 1
 Using the old draft to finish and send it before starting with a new one.
 .LI 2
 Discarding the old draft and replacing it with a new one.
 .LI 3
 Preserving the old draft by refiling it to a folder.
 .LP
-It was only possible to work in alternation on multiple drafts.
+Working on multiple drafts was only possible in alternation.
-Therefore, the current draft needed to be refiled to a folder and
+For that, the current draft needed to be refiled to a folder and
 another one re-used for editing.
 Working on multiple drafts at the same time was impossible.
 The usual approach of switching to a different MH context did not
 help anything.
 .P
 .P
 Not using the draft folder facility has the single advantage of having
 the draft file at a static location.
 This is simple in simple cases but the concept does not scale for more
 complex cases.
-The concept of the draft message is too limited for the problem.
+The concept of the draft message is too limited for the problem
+it tries to solve.
 Therefore the draft folder was introduced.
 It is the more powerful and more natural concept.
 The draft folder is a folder like any other folder in MH.
 Its messages can be listed like any other messages.
 A draft message is no longer a special case.
 Hence corner cases were removed.
 .P
 The trivial part of the work was activating the draft folder with a
 default name.
 I chose the name
-.Fn +drafts
+.Fn +drafts ,
 for obvious reasons.
 In consequence, the command line switches
 .Sw -draftfolder
 and
 .Sw -draftmessage
 could be removed.
 More difficult but also more improving was updating the tools to the
 new concept.
 For nearly three decades, the tools needed to support two draft handling
 approaches.
-By fully switching to the draft folder, the tools could be simplified
+By fully switching to the draft folder, the tools could be
-by dropping the awkward draft message handling code.
+simplified by dropping the awkward draft message handling code.
 .Sw -draft
 switches were removed because operating on a draft message is no longer
 special.
 It became indistinguishable to operating on any other message.
 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
 .Pn comp
 still has
 .Sw -[no]use
 for switching between two modes:
 .LI 1
-.Sw -use
+Modifying an existing draft, with
-to modify an existing draft.
+.Sw -use .
 .LI 2
-.Sw -nouse
+Composing a new draft, possibly taking some existing message as template,
-to compose a new draft, possibly taking some existing message as template.
+with
+.Sw -nouse ,
+the default.
 .LP
 In either case, the behavior of
 .Pn comp
 is deterministic.
 .P
 In contrast to the other tools,
 .Pn send
 takes the draft folder as its default folder.
 .P
 Dropping the draft message concept in favor for the draft folder concept,
-removed special cases with regular cases.
+replaced special cases with regular cases.
 This simplified the source code of the tools, as well as the concepts.
 In mmh, draft management does not break with the MH concepts
 but applies them.
 .Cl "scan +drafts" ,
 for instance, is a truly natural request.
+.P
 Most of the work was already performed by Rose in the eighties.
 The original improvement of mmh is dropping the old draft message approach
-and thus simplifying the tools, the documentation and the system as a whole.
+and thus simplifying the tools, the documentation,
+and the system as a whole.
 Although my part in the draft handling improvement was small,
-it was an important one.
+it was important.
 .U3 "Trash Folder
 .Id trash-folder
 .P
 .VS
 find $HOME/Mail -type f -name ',*' -ctime +7 -delete
 VE
 In such a setup, the original message could be restored
 within the grace time interval by stripping the
-backup prefix from the file name.
+backup prefix from the file name \(en usually but not always.
-But the user could not rely on this statement.
 If the last message of a folder with six messages (\fL1-6\fP) was removed,
 message
 .Fn 6 ,
 became file
 .Fn ,6 .
 If then a new message entered the same folder, it would be named with
 the number one above the highest existing message number.
 In this case the message would be named
-.Fn 6
+.Fn 6 ,
-then.
+reusing the number.
 If this new message would be removed as well,
-then the backup of the former message is overwritten.
+then the backup of the former message becomes overwritten.
 Hence, the ability to restore removed messages did not only depend on
 the sweeping cron job but also on the removing of further messages.
 It is undesirable to have such obscure and complex mechanisms.
 The user should be given a small set of clear assertions, such as
 ``Removed files are restorable within a seven-day grace time.''
 With the addition ``... unless a message with the same name in the
 same folder is removed before.'' the statement becomes complex.
-A user will hardly be able to keep track of any removal to know
+A user will hardly be able to keep track of all removals to know
 if the assertion still holds true for a specific file.
 In practice, the real mechanism is unclear to the user.
-The consequences of further removals are not obvious.
+.P
-.P
+Furthermore, the backup files were scattered within the whole mail storage.
-Furthermore, the backup files are scattered within the whole mail storage.
+This complicated managing them.
-This complicates managing them.
+It was possible with the help of
-It is possible with the help of
 .Pn find ,
-but everything would be more convenient
+but everything is more convenient
-if the deleted messages would be collected in one place.
+if the deleted messages are collected in one place.
 .P
 The profile entry
 .Pe rmmproc
 (previously named
 .Pe Delete-Prog )
 was introduced very early to improve the situation.
 It could be set to any command, which would be executed to remove
 the specified messages.
-This would override the default action described above.
+This had overridden the default action, described above.
-Refiling the to-be-removed files to a trash folder is the usual example.
+Refiling the to-be-removed files to a trash folder was the usual example.
 Nmh's man page
 .Mp rmm (1)
 proposes to set the
 .Pe rmmproc
 to
 .Cl "refile +d
-to move messages to the trash folder,
+to move messages to the trash folder
-.Fn +d ,
+.Fn +d
 instead of renaming them with the backup prefix.
-The man page proposes additionally the expunge command
+The man page additionally proposes the expunge command
 .Cl "rm `mhpath +d all`
 to empty the trash folder.
 .P
-Removing messages in such a way has advantages.
+Removing messages in such a way has advantages:
+.LI 1
 The mail storage is prevented from being cluttered with removed messages
 because they are all collected in one place.
 Existing and removed messages are thus separated more strictly.
+.LI 2
 No backup files are silently overwritten.
-But most important is the ability to keep removed messages in the MH domain.
+.LI 3
+Most important, however, removed messages are kept in the MH domain.
 Messages in the trash folder can be listed like those in any other folder.
 Deleted messages can be displayed like any other messages.
 .Pn refile
 can restore deleted messages.
 All operations on deleted files are still covered by the MH tools.
 .Sw -unlink
 switch causes the files to be unlinked.
 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
 .Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
 .P
-Dropping the legacy approach and converting to the new approach completely
+Dropping the legacy approach and converting to the new approach
-simplified the code base.
+completely, simplified the code base.
 The relationship between
 .Pn rmm
 and
 .Pn refile
 was inverted.
 In mmh,
 .Pn rmm
 invokes
-.Pn refile ,
+.Pn refile .
-which used to be the other way round.
+That used to be the other way round.
 Yet, the relationship is simpler now.
 Loops, like described in nmh's man page for
 .Mp refile (1),
 can no longer occur:
 .QS
 .H2 "Modern Defaults
 .P
 Nmh has a bunch of convenience-improving features inactive by default,
-although one can expect every new user wanting to have them active.
+although one can expect every new user to want them active.
 The reason they are inactive by default is the wish to stay compatible
 with old versions.
-But what is the definition for old versions?
+But what are old versions?
 Still, the highly useful draft folder facility has not been activated
 by default although it was introduced over twenty-five years ago.
 .[
 rose romine real work
 .]
 The community seems not to care.
-This is one of several examples that require new users to first build up
+.P
-a profile before they can access the modern features of nmh.
+In nmh, new users are required to first build up
+a profile before they can access the modern features.
 Without an extensive profile, the setup is hardly usable
 for modern emailing.
 The point is not the customization of the setup,
 but the need to activate generally useful facilities.
-.P
+Yet, the real problem lies less in enabling the features,
-Yet, the real problem lies less in enabling the features, as this is
+as this is straight forward as soon as one knows what he wants.
-straight forward as soon as one knows what he wants.
 The real problem is that new users need deep insight into the project
-to find out about inactive features nmh already provides.
+to discover the available but inactive features.
 To give an example, I needed one year of using nmh
 before I became aware of the existence of the attachment system.
 One could argue that this fact disqualifies my reading of the
 documentation.
 If I would have installed nmh from source back then, I could agree.
-Yet, I had used a prepackaged version and had expected that it would
+Yet, I had used a pre-packaged version and had expected that it would
 just work.
 Nevertheless, I had been convinced by the concepts of MH already
 and I am a software developer,
 still I required a lot of time to discover the cool features.
 How can we expect users to be even more advanced than me,
-just to allow them use MH in a convenient and modern way?
+just to enable them to use MH in a convenient and modern way?
 Unless they are strongly convinced of the concepts, they will fail.
 I have seen friends of me giving up disappointed
 before they truly used the system,
 although they had been motivated in the beginning.
-They suffer hard enough to get used to the tool chest approach,
+New users suffer hard enough to get used to the tool chest approach,
 we developers should spare them further inconveniences.
 .P
 Maintaining compatibility for its own sake is bad,
-because the code base collects more and more compatibility code.
+because the code base will collect more and more compatibility code.
 Sticking to the compatibility code means remaining limited;
 whereas adjusting to the changes renders the compatibility unnecessary.
-Keeping unused alternatives in the code is a bad choice as they likely
+Keeping unused alternatives in the code for longer than a short
-gather bugs, by not being well tested.
+grace time is a bad choice as they likely
+gather bugs by not being constantly tested.
 Also, the increased code size and the greater number of conditions
 increase the maintenance costs.
 If any MH implementation would be the back-end of widespread
 email clients with large user bases, compatibility would be more
 important.
 Yet, it appears as if this is not the case.
 Hence, compatibility is hardly important for technical reasons.
-Its importance originates rather from personal reasons.
+Its importance originates from personal reasons rather.
 Nmh's user base is small and old.
-Changing the interfaces would cause inconvenience to long-term users of MH.
+Changing the interfaces causes inconvenience to long-term users of MH.
-It would force them to change their many years old MH configurations.
+It forces them to change their many years old MH configurations.
 I do understand this aspect, but by sticking to the old users,
-new users are kept away.
+new users are kept from entering the world of MH.
-Yet, the future lies in new users.
+But the future lies in new users.
 In consequence, mmh invites new users by providing a convenient
 and modern setup, readily usable out-of-the-box.
 .P
 In mmh, all modern features are active by default and many previous
-approaches are removed or only accessible in manual ways.
+approaches are removed or only accessible in a manual way.
 New default features include:
 .BU
 The attachment system (\c
-.Hd Attach ).
+.Hd Attach )
-.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
+.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 .
 .BU
 The draft folder facility (\c
-.Fn +drafts ).
+.Fn +drafts )
-.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 .
 .BU
 The unseen sequence (`u')
 .Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
-and the sequence negation prefix (`!').
+and the sequence negation prefix (`!')
-.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
+.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc .
 .BU
-Quoting the original message in the reply.
+Quoting the original message in the reply
-.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
+.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 .
 .BU
-Forwarding messages using MIME.
+Forwarding messages using MIME
-.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
+.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 .
 .LP
-In consequence, a setup with a profile that defines only the path to the
+An mmh setup with a profile that defines only the path to the
 mail storage, is already convenient to use.
-Again, Paul Vixie's ``edginess'' call supports the direction I took:
+Again, Paul Vixie's supports the direction I took:
 ``the `main branch' should just be modern''.
 .[
 paul vixie edginess nmh-workers
 .]

Mercurial > docs > master

comparison discussion.roff @ 217:f3f65376bef9