Correct email port number. While here, fix title capitalization and

contractions.

PR:		docs/188845
Submitted by:	Ondra Knezour <knezour@weboutsourcing.cz>

1 files changed, 20 insertions, 20 deletions

diff --git a/en_US.ISO8859-1/articles/ldap-auth/article.xml b/en_US.ISO8859-1/articles/ldap-auth/article.xml
index 0660586c86..491c6da726 100644
--- a/en_US.ISO8859-1/articles/ldap-auth/article.xml
+++ b/en_US.ISO8859-1/articles/ldap-auth/article.xml
@@ -129,7 +129,7 @@
 	<para>SSL stands for <quote>Secure Sockets Layer</quote>, and
 	  services that implement SSL do <emphasis>not</emphasis> listen on
 	  the same ports as their non-SSL counterparts.  Thus SMTPS listens
-	  on port 465 (not 45), HTTPS listens on 443, and LDAPS on
+	  on port 465 (not 25), HTTPS listens on 443, and LDAPS on
 	  636.</para>
 
 	<para>The reason SSL uses a different port than TLS is because a
@@ -171,7 +171,7 @@ TLSCACertificateFile /path/to/your/cacert.crt</programlisting>
 	  self-signed certificate with OpenSSL:</para>
 
 	<example xml:id="genrsa">
-	  <title>Generating an RSA key</title>
+	  <title>Generating an RSA Key</title>
 
 	  <screen>&prompt.user; <userinput>openssl genrsa -out cert.key 1024</userinput>
 Generating RSA private key, 1024 bit long modulus
@@ -196,7 +196,7 @@ e is 65537 (0x10001)
 	  signed:</para>
 
 	<example xml:id="self-sign">
-	  <title>Self-signing the certificate</title>
+	  <title>Self-signing the Certificate</title>
 
 	  <screen>&prompt.user; <userinput>openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt</userinput>
 Signature ok
@@ -335,7 +335,7 @@ cn: tuser</programlisting>
 
       <para>I start my LDAP users' UIDs at 10000 to avoid collisions with
 	system accounts; you can configure whatever number you wish here,
-	as long as it's less than 65536.</para>
+	as long as it is less than 65536.</para>
 
       <para>We also need group entries.  They are as configurable as
 	user entries, but we will use the defaults below:</para>
@@ -555,7 +555,7 @@ passwd: files ldap</programlisting>
 	you should be made aware of; see <xref linkend="security-passwd"/></para>
 
       <example xml:id="chpw-shell">
-	<title>Shell script for changing passwords</title>
+	<title>Shell Script for Changing Passwords</title>
 
 	<programlisting><![CDATA[#!/bin/sh
 
@@ -593,7 +593,7 @@ ldappasswd -D uid="$USER",ou=people,dc=example,dc=org \
 	line, and on the web.</para>
 
       <example xml:id="chpw-ruby">
-	<title>Ruby script for changing passwords</title>
+	<title>Ruby Script for Changing Passwords</title>
 
 	<programlisting><![CDATA[require 'ldap'
 require 'base64'
@@ -654,7 +654,7 @@ conn.modify(luser, [replace])]]></programlisting>
       improvements.</para>
 
     <sect2 xml:id="secure-readonly">
-      <title>Setting attributes read-only</title>
+      <title>Setting Attributes Read-only</title>
 
       <para>Several attributes in LDAP should be read-only.  If left
 	writable by the user, for example, a user could change his
@@ -667,7 +667,7 @@ conn.modify(luser, [replace])]]></programlisting>
 	the following in <filename>slapd.conf</filename>:</para>
 
       <example xml:id="hide-userpass">
-	<title>Hide passwords</title>
+	<title>Hide Passwords</title>
 
 	<programlisting>access to dn.subtree="ou=people,dc=example,dc=org"
   attrs=userPassword
@@ -691,7 +691,7 @@ access to *
 	hole, modify the above to</para>
 
       <example xml:id="attrib-readonly">
-	<title>Read-only attributes</title>
+	<title>Read-only Attributes</title>
 
 	<programlisting>access to dn.subtree="ou=people,dc=example,dc=org"
   attrs=userPassword
@@ -712,7 +712,7 @@ access to *
     </sect2>
 
     <sect2 xml:id="secure-root">
-      <title><systemitem class="username">Root</systemitem> account definition</title>
+      <title><systemitem class="username">root</systemitem> Account Definition</title>
 
       <para>Often the <systemitem class="username">root</systemitem> or manager account for
 	the LDAP service will be defined in the configuration file.
@@ -724,21 +724,21 @@ access to *
 
       <para>Even better is to define accounts that have limited
 	permissions, and omit a <systemitem class="username">root</systemitem> account entirely.
-	For example, users to can add or remove user accounts are added to
+	For example, users that can add or remove user accounts are added to
 	one group, but they cannot themselves change the membership of
 	this group.  Such a security policy would help mitigate the effects
 	of a leaked password.</para>
 
       <sect3 xml:id="manager-acct">
-	<title>Creating a management group</title>
+	<title>Creating a Management Group</title>
 
 	<para>Say you want your IT department to be able to change home
-	  directories for users, but you don't want all of them to be able
+	  directories for users, but you do not want all of them to be able
 	  to add or remove users.  The way to do this is to add a group
 	  for these admins:</para>
 
 	<example xml:id="manager-acct-dn">
-	  <title>Creating a management group</title>
+	  <title>Creating a Management Group</title>
 
 	  <programlisting>dn: cn=homemanagement,dc=example,dc=org
 objectClass: top
@@ -753,7 +753,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
 	  <filename>slapd.conf</filename>:</para>
 
 	<example xml:id="management-acct-acl">
-	  <title>ACLs for a home directory management group</title>
+	  <title>ACLs for a Home Directory Management Group</title>
 
 	<programlisting>access to dn.subtree="ou=people,dc=example,dc=org"
   attr=homeDirectory
@@ -764,7 +764,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
 	<para>Now <systemitem class="username">tuser</systemitem> and <systemitem class="username">user2</systemitem>
         can change other users' home directories.</para>
 
-	<para>In this example we've given a subset of administrative
+	<para>In this example we have given a subset of administrative
 	  power to certain users without giving them power in other
 	  domains.  The idea is that soon no single user account has the
 	  power of a <systemitem class="username">root</systemitem> account, but every power
@@ -774,7 +774,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
     </sect2>
 
     <sect2 xml:id="security-passwd">
-      <title>Password storage</title>
+      <title>Password Storage</title>
 
       <para>By default <application>OpenLDAP</application> will store
 	the value of the <literal>userPassword</literal> attribute as it
@@ -823,7 +823,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
   </appendix>
 
   <appendix xml:id="ssl-ca">
-    <title><application>OpenSSL</application> Certificates For LDAP</title>
+    <title><application>OpenSSL</application> Certificates for LDAP</title>
 
     <para>If you are hosting two or more LDAP servers, you will probably
       not want to use self-signed certificates, since each client will
@@ -841,7 +841,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
       are</para>
 
     <example xml:id="make-cert">
-      <title>Creating a certificate</title>
+      <title>Creating a Certificate</title>
 
       <screen>&prompt.user; <userinput>openssl genrsa -out root.key 1024</userinput>
 &prompt.user; <userinput>openssl req -new -key root.key -out root.csr</userinput>
@@ -872,7 +872,7 @@ memberUid: uid=user2,ou=people,dc=example,dc=org</programlisting>
       <option>-signkey</option>:</para>
 
     <example xml:id="ca-sign">
-      <title>Signing as a certificate authority</title>
+      <title>Signing as a Certificate Authority</title>
 
       <screen>&prompt.user; <userinput>openssl x509 -req -days 1024 \
 -in ldap-server-one.csr -CA root.crt -CAkey root.key \