1.1 --- a/ch03.roff	Tue Jun 12 20:44:52 2012 +0200
     1.2 +++ b/ch03.roff	Tue Jun 12 21:00:43 2012 +0200
     1.3 @@ -24,7 +24,7 @@
     1.4  Excellent implementations for the various aspects of email exist already.
     1.5  Just to name three examples: Postfix is a specialized MTA,
     1.6  Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
     1.7 -I believe that it is best to use such specilized tools instead of
     1.8 +I believe that it is best to use such specialized tools instead of
     1.9  providing the same function again as a side-component in the project.
    1.10  .P
    1.11  Doing something well, requires to focus on a small set of specific aspects.
    1.12 @@ -35,7 +35,7 @@
    1.13  or modular \(en will never be the best choice in any of the fields.
    1.14  Even in providing the best consistent all-in-one system they are likely
    1.15  to be beaten by projects that focus only on integrating existing mail
    1.16 -components to a homogenious system.
    1.17 +components to a homogeneous system.
    1.18  .P
    1.19  The limiting resource in Free Software community development
    1.20  is usually man power.
    1.21 @@ -69,7 +69,7 @@
    1.22  command.
    1.23  The changes in emailing in the last years
    1.24  demanded changes in this part of nmh too.
    1.25 -Encryption and authetication for network connections
    1.26 +Encryption and authentication for network connections
    1.27  needed to be supported, hence TLS and SASL were introduced into nmh.
    1.28  This added complexity to nmh without improving it in its core functions.
    1.29  Also, keeping up with recent developments in the field of
    1.30 @@ -252,7 +252,7 @@
    1.31  .H2 "Removal of non-MUA Tools
    1.32  .P
    1.33  One goal of mmh is to remove the tools that are not part of the MUA's task.
    1.34 -Further more, any tools that don't improve the MUA's job significently
    1.35 +Further more, any tools that don't improve the MUA's job significantly
    1.36  should be removed.
    1.37  Loosely related and rarely used tools distract from the lean appearance.
    1.38  They require maintenance work without adding much to the core task.
    1.39 @@ -277,7 +277,7 @@
    1.40  .Pn rcvtty
    1.41  was removed
    1.42  .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
    1.43 -because its usecase of writing to the user's terminal
    1.44 +because its use case of writing to the user's terminal
    1.45  on receiving of mail is obsolete.
    1.46  If users like to be informed of new mail, the shell's
    1.47  .Ev MAILPATH
    1.48 @@ -418,7 +418,7 @@
    1.49  .Pn show
    1.50  mapped message numbers and sequences to files and invoked
    1.51  .Pn mhl
    1.52 -to have the files formated.
    1.53 +to have the files formatted.
    1.54  With MIME, this approach wasn't sufficient anymore.
    1.55  MIME messages can consist of multiple parts, some of which aren't
    1.56  directly displayable, further more text content might be encoded in
    1.57 @@ -575,7 +575,7 @@
    1.58  .Sw --with-tls
    1.59  and
    1.60  .Sw --with-cyrus-sasl
    1.61 -had activated the support for transfer encryption and authetication.
    1.62 +had activated the support for transfer encryption and authentication.
    1.63  This is not needed anymore.
    1.64  .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
    1.65  .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
    1.66 @@ -655,7 +655,7 @@
    1.67  obsoleted the concept of the backup prefix completely.
    1.68  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
    1.69  (Well, there still are corner-cases to remove until the backup
    1.70 -prefix can be layed to rest, eventually.)
    1.71 +prefix can be laid to rest, eventually.)
    1.72  .\" FIXME: Do this work in the code!
    1.73  
    1.74  .U3 "Editor and Pager
    1.75 @@ -667,7 +667,7 @@
    1.76  Doing so at configure time made sense in the Eighties,
    1.77  when the set of available editors and pagers varied much across
    1.78  different systems.
    1.79 -Today, the situation is more homegeneic.
    1.80 +Today, the situation is more homogeneous.
    1.81  The programs
    1.82  .Pn vi
    1.83  and
    1.84 @@ -720,7 +720,7 @@
    1.85  .P
    1.86  .Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
    1.87  .P
    1.88 -The pager to use is deteminded in a similar order,
    1.89 +The pager to use is determined in a similar order,
    1.90  also taking the first available and non-empty item:
    1.91  .IP (1)
    1.92  Environment variable
    1.93 @@ -789,7 +789,7 @@
    1.94  .I ndbm
    1.95  vanished and 120 lines of complex autoconf code could be saved.
    1.96  .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
    1.97 -The change removed funtionality too, but that is minor to the
    1.98 +The change removed functionality too, but that is minor to the
    1.99  improvement by dropping the dependency and the complex autoconf code.
   1.100  
   1.101  .U3 "mh-e Support
   1.102 @@ -1103,7 +1103,7 @@
   1.103  change. Even if the
   1.104  .Hd Content-MD5
   1.105  header field is useful sometimes,
   1.106 -I value its usefulnes less than the improvement in maintainability, caused
   1.107 +I value its usefulness less than the improvement in maintainability, caused
   1.108  by the removal.
   1.109  
   1.110  .U2 "Prompter's Control Keys
   1.111 @@ -1317,7 +1317,7 @@
   1.112  
   1.113  
   1.114  
   1.115 -.H1 "Concept Exploitation/Homogeniety
   1.116 +.H1 "Concept Exploitation/Homogeneity
   1.117  
   1.118  
   1.119  .H2 "Draft Folder
   1.120 @@ -1343,7 +1343,7 @@
   1.121  the feature well.
   1.122  .P
   1.123  The only advantage of not using the draft folder facility is the static
   1.124 -name of the draft file. This could be an issue for MH frontends like mh-e.
   1.125 +name of the draft file. This could be an issue for MH front-ends like mh-e.
   1.126  But as they likely want to provide working on multiple drafts in parallel,
   1.127  the issue is only concerning compatibility. The aim of nmh to stay compatible
   1.128  prevented the default activation of the draft folder facility.