Correct grammar, get rid of apostrophes.

svn path=/branches/BRANCH_6-3/; revision=5426

diff --git a/README.SSL b/README.SSL
index f08c566a8e652fec2eb1fb4293de9210b3f51beb..59e838744a8d92b21a0be7b649ab40057a624d3a 100644 (file)
--- a/README.SSL
+++ b/README.SSL
@@ -43,7 +43,7 @@ and the server in an encrypted form, so that eavesdropping should become
 practically impossible.
 
 This works as following: the server has a key pair (a secret and a public key), 
-and it sends the client it's public key. Messages encrypted with the public key 
+and it sends the client its public key. Messages encrypted with the public key 
 can be decrypted using the private one and vice versa.
 
 A symmetric session key (symmetric means that the same key is used for 
@@ -56,8 +56,8 @@ using the usual POP/IMAP/whatever authentication mechanisms.
 
 However, so called man-in-the-middle attacks are still possible: in such 
 a setting, an attacker pretends to be the server, and thus can e.g. get your 
-authentication information if you don't use a challenge based authentication 
-mechanism (because he is thought to be the real server, fetchmail will try to 
+authentication information if you do not use a challenge based authentication 
+mechanism (because it is thought to be the real server, fetchmail will try to 
 authenticate against it by telling it your password).
 
 So, not only you need to prove your identity to the server, the server likewise 
@@ -77,8 +77,8 @@ you put the CA's certificate into a directory where you keep trusted
 certificates, and point fetchmail to it. Fetchmail will then accept 
 certificates signed by the owner of that certificate with the private key 
 belonging to the public key in the certificate.
-You can specify this path using the "sslcertpath" option if it's different from 
-the one OpenSSL uses by default.
+You can specify this path using the "sslcertpath" option if it is 
+different from the one OpenSSL uses by default.
 
 The idea is that the CA only gives certificates to entities whose identity it 
 has checked and verified (and in this case, that the server name you specify 
@@ -97,7 +97,7 @@ certificate was not granted to the rightful owner).
 The certificate directory must be hashed in a way OpenSSL expects it: each time 
 you modify a file in that directory or add a file to it, you need to use the 
 "c_rehash" perl script that comes with OpenSSL (in the tools/ subdirectory, in 
-case that it isn't installed). Additionally, you might need to convert the 
+case that it is not installed). Additionally, you might need to convert the 
 certificates to different formats (the PEM format is expected and usually is 
 available, DER is another one; you can convert between both using the 
 openssl(1) utility's x509 sub-mode).
@@ -109,7 +109,7 @@ attack", i.e. nobody can generate a second key that hashes to the same value of
 the original key in reasonable time. So, if the fingerprint matches, you can be 
 reasonable sure that you talk to the original server, because only that knows 
 the secret key, and it is very hard to generate a matching secret key from the 
-public key. If it doesn't, it might be an attack, but keep in mind that the 
+public key. If it does not, it might be an attack, but keep in mind that the 
 server key may also have changed legitimately before panicking ;)
 
 Fetchmail will present the fingerprint to you in verbose mode. You can have