Corrected misspelled words and fixed typos.

1 files changed, 22 insertions, 22 deletions

diff --git a/README b/README
index caf1e7c..2ac16b4 100755
--- a/README
+++ b/README
@@ -2,7 +2,7 @@
    ffff  
   ff    firma -  
   ffff  encrypted mailing list manager
-  ff    - a firma cai mas nao quebra 
+  ff    - a firma cai mas nao quebra
   ff    
 
 Index
@@ -21,12 +21,12 @@ The concept
 -----------
 
  In portuguese, "firma" means for signature, signature and trust checking and
- is a slang for strenght and enteprise.
+ is a slang for strength and enterprise.
 
  All this together just can be one thing: an encrypted mailing list manager :P
 
  In the streets, the expression "a firma cai mas nao quebra" (the enterprise
- falls but does not breaks) is commonly used to talk about the strenght of a
+ falls but does not breaks) is commonly used to talk about the strength of a
  group that operates in secrecy. To our list manager, this concept says that
  your encrypted mailing list can stops to work -- if the server goes offline
  or abducted by aliens -- but the system can never be broken. With firma, we
@@ -67,7 +67,7 @@ Everyone has the private key X The server has the private key
  For the firsts releases of Firma, we choose to use just the first option.
  In the future the code should contain support for an one-keypair list,
  but this is not the main behavior we want in an encrypted mailing list.
- This is a question of centralized versus descentralized vulnerability.
+ This is a question of centralized versus decentralized vulnerability.
 
  An one-keypair list is more or less just like a mail alias: someone
  send an encrypted email to the list address and the manager just forwards
@@ -78,16 +78,16 @@ Everyone has the private key X The server has the private key
 
  In the case of a keypair stored in the server, where subscribers has just
  the list pubkey, the list admin just need to remove the correspondent pubkey
- from the list's keyring with in case some user has its keypair compromissed.
+ from the list's keyring with in case some user has its keypair compromised.
 
- These two approaches has a similiar external hole of some private key turned
+ These two approaches has a similar external hole of some private key turned
  public. Designing Firma, we decided for the centralized model, for three main
  reasons:
 
   1 - a server can be safer than any user's ordinary computer.
 
   2 - automation: when some user is removed from the list, we just remove their
-      key from the list keyring; in the descentralized approach, the list admin
+      key from the list keyring; in the decentralized approach, the list admin
       needs to regenerate a new list keypair, otherwise the unsubscribed user
       can still decrypt list messages if he can sniff the mail server traffic.
 
@@ -96,7 +96,7 @@ Everyone has the private key X The server has the private key
 Why Bash
 --------
 
- You may ask why we choosed bash. Its really strange a crypto project using
+ You may ask why we choose bash. Its really strange a crypto project using
  shell scripting language. But bash has many advantages:
 
  - Bash is found in almost all unix-like systems
@@ -106,15 +106,15 @@ Why Bash
    unix commands needed to run firma.
 
  - You can easily put all the tools, scripts and config files in a read-only
-   media to protect againt cracks such as rootkits.
+   media to protect against cracks such as rootkits.
 
- - Keeping your encripted list manager out from a huge and sometimes bugged
+ - Keeping your encrypted list manager out from a huge and sometimes bugged
    mail software prevents insecure use of your mailing list by an excess of
    unwanted functions and routines.
 
  - Firma has a total KISS design, and bash helps to keep it simple.
 
- - Firma adopted the style sugested in the Advanced Bash-Scripting Guide,
+ - Firma adopted the style suggested in the Advanced Bash-Scripting Guide,
    http://www.tldp.org/LDP/abs/html/scrstyle.html
 
 Development Guidelines
@@ -134,18 +134,18 @@ Setup
      but you can use anything, just edit firma and change FIRMA_LIST_PATH
      variable.
  
- 2 - copy firma script to whatever you like, eg. /usr/local/bin and check that
+ 2 - copy firma script to whatever you like, e.g. /usr/local/bin and check that
      it has no write permission 
 
  3 - create a list-wide config file (default is /usr/local/etc/firma.conf) with
      the common definitions for all lists,
 
-       GPG_BINARY= path to the gnupg binary
+       GPG_BINARY= path to the GnuPG binary
        MAIL_AGENT= path to the mail transport agent to be used (e.g., sendmail)
        MAIL_AGENT_ARGS= command-line arguments to be passed to the command above
        LISTS_DIR= path to the mailing lists directory
 
-      all thos variables can be overwritten at each list's own config file;
+      all those variables can be overwritten at each list's own config file;
       firma.conf should be chmoded as 600, chowned nobody.nobdy or whatever
       user your MTA runs.
 
@@ -158,7 +158,7 @@ Setup
 
        LIST_ADDRESS= list's email address
        LIST_ADMIN= list's administrators email addresses (space separated)
-       LIST_HOMEDIR= list's gnupg homedir, where the list's keyrings are located
+       LIST_HOMEDIR= list's GnuPG homedir, where the list's keyrings are located
        PASSPHRASE= passphrase for the list's private keyring
 
      then a gpg keypair and a config file are automatically generated;
@@ -175,7 +175,7 @@ Setup
 
        newaliases
 
-     alternativelly, you can use a virtual ...
+     alternatively, you can use a virtual ...
 
  6 - admin tasks are performed through your-list-request@yourmachine or
      via command-line:
@@ -190,7 +190,7 @@ Setup
          subscribe key-id pubkey from file or keyserver (currently not
          implemented)
 
-       unsub email-address
+       unsure email-address
 
           unsubscribe all keys with email-address IDs (currently not
           implemented)
@@ -215,25 +215,25 @@ Tips
 
  - Use an encrypted swap memory
  - Use a read-only media to store firma and its needed apps
- - Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server frozes
- - Use a big PASSWD, 25+ chars with alpha-numeric and special ascii keys
+ - Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server friezes
+ - Use a big PASSPHRASE, 25+ chars with alpha-numeric and special ascii keys
 
 Design and features
 -------------------
 
- Firma is simple but its simplicity does'nt reflect in lack of design.
+ Firma is simple but its simplicity doesn't reflect in lack of design.
 
  - uses a gpg keyring to store both the keys and the subscribers options
  
  - command line is simple to avoid admin tasks resting in some .bash_history
 
- - non-pgp blocks in a message are discarded since we dont want to deal with
+ - non-pgp blocks in a message are discarded since we don't want to deal with
    unencrypted content
 
  - all unwanted email headers are striped as a privacy measure for who sends
    the message
 
- - firma does'nt use any disk write when processing a message; no temp files
+ - firma doesn't use any disk write when processing a message; no temp files
    that may rest in the system; everything goes in memory (but take care, 
    sometimes it will use the swap and then is best to make it encrypted)