Merge branch 'legacy_63'

[~andy/fetchmail] / README.SSL

diff --git a/README.SSL b/README.SSL
index 59e838744a8d92b21a0be7b649ab40057a624d3a..930da8bb5ace9f3db4e2a21ada3f7810453686e3 100644 (file)
--- a/README.SSL
+++ b/README.SSL
@@ -8,8 +8,8 @@ Note: there is a separate document "README.SSL-SERVER" describing the server-
 side requirements for proper SSL support.  It has checklist-style and is not 
 specific to fetchmail.
 
-In case of troubles, mail that other document to your ISP and have them check 
-their server configuration against it.
+In case of troubles, mail the README.SSL-SERVER file to your ISP and 
+have them check their server configuration against it.
 
 Unfortunately, fetchmail confuses SSL/TLS protocol levels with whether 
 a service needs to use in-band negotiation (STLS/STARTTLS for POP3/IMAP4) or is 
@@ -23,17 +23,25 @@ Quickstart
 ----------
 
 For use of SSL or TLS with in-band negotiation on the regular service's port, 
-i. e. with STLS or STARTTLS, use these command line options (in the rcfile, 
-omit the leading "--"):
+i. e. with STLS or STARTTLS, use these command line options
 
     --sslproto tls1 --sslcertck
 
+or these options in the rcfile (after the respective "user"... options)
+
+      sslproto tls1   sslcertck
+
+
 For use of SSL or TLS on a separate port, if the whole TCP connection is 
 SSL-encrypted from the very beginning, use these command line options (in the 
-rcfile, omit the leading "--"):
+rcfile, omit all leading "--"):
 
     --ssl --sslproto ssl3 --sslcertck
 
+or these options in the rcfile (after the respective "user"... options)
+
+      ssl   sslproto ssl3   sslcertck
+
 
 Background and use (long version :-))
 ------------------
@@ -42,7 +50,7 @@ Using fetchmail's "ssl" option, you can have the data transferred between you
 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), 
+This works as follows: the server has a key pair (a secret and a 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.
 
@@ -60,8 +68,8 @@ 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 
-needs to prove (authenticate) its identity to you.
+So, not only do you need to prove your identity to the server, the
+server likewise needs to prove (authenticate) its identity to you.
   In the standard setting, the server has a certificate (the client can have 
 a certificate too to prove its identity, but this is not covered by this 
 document). This certificate contains the server's public key, some data about 
@@ -69,7 +77,7 @@ the server, and a digital signature and data about the signer.
   Digital signatures can also be made using a key pair as described earlier.
 
 To check this certificate, you should use the new option "sslcertck". When it 
-is specified, the signature of server certificate is checked against local 
+is specified, the signature of the server certificate is checked against local 
 trusted certificates to see whether the owner of one of the certificates has 
 signed that server certificate, and if so, whether the signature is valid.
   So, if the server certificate is signed by a Certification Authority (CA), 
@@ -107,10 +115,11 @@ the public key that is used by the server. The fingerprint is a hash of that
 key that (hopefully) has few collisions and is hard to attack using a "birthday 
 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 does not, it might be an attack, but keep in mind that the 
-server key may also have changed legitimately before panicking ;)
+reasonably sure that you are talking to the original server, because 
+only that server knows the secret key, and it is very hard to generate a 
+matching secret key from the public key. If the fingerprint does not 
+match, there might be an attack, but, before panicking, keep in mind 
+that the server key may also have changed legitimately.
 
 Fetchmail will present the fingerprint to you in verbose mode. You can have 
 fetchmail check the fingerprint (using the "sslfingerprint" option, and giving 
@@ -118,9 +127,9 @@ the desired fingerprint as an argument).
 
 The fingerprints fetchmail uses are MD5 sums. You can generate them e.g. using
 openssl(1)'s "x509 -fingerprint" command. The format is a hexadecimal string 
-with a ":" separating two byes (i.e. a ":" every two hex "digits"). The
-match is case insensitive since release 6.3.10 (upper-case digits A to F
-were required up to and including release 6.3.9).
+with a ":" separating two bytes (i.e. a ":" between every two hex "digits"). The 
+match is case insensitive since release 6.3.10 (upper-case digits A to F were 
+required up to and including release 6.3.9).
 
 *CAVEAT*: OpenSSL must be at least version 0.9.7 to be able to check CRLs.