[system-administrators-guide/21] Improvements to markup mostly
stephenw
stephenw at fedoraproject.org
Thu Jan 15 21:26:30 UTC 2015
commit 61d78acd989ad5f366f119342815e7e8f0c4d8a5
Author: Stephen Wadeley <swadeley at redhat.com>
Date: Mon Dec 15 09:39:04 2014 +0100
Improvements to markup mostly
based on review of upstream version
en-US/Mail_Servers.xml | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
---
diff --git a/en-US/Mail_Servers.xml b/en-US/Mail_Servers.xml
index 614f47b..13cb17c 100644
--- a/en-US/Mail_Servers.xml
+++ b/en-US/Mail_Servers.xml
@@ -108,7 +108,7 @@
inheritnum="ignore">
<listitem>
<para>Edit the <filename>/etc/dovecot/dovecot.conf</filename> configuration file to make sure the <literal>protocols</literal> variable is uncommented (remove the hash sign (<literal>#</literal>) at the beginning of the line) and contains the <literal>pop3</literal> argument. For example:</para>
- <programlisting>protocols = imap imaps pop3 pop3s</programlisting>
+ <screen>protocols = imap pop3 lmtp</screen>
<para>
When the <literal>protocols</literal> variable is left commented out, <command>dovecot</command> will use the default values as described above.
</para>
@@ -258,7 +258,7 @@ ln -s '/usr/lib/systemd/system/dovecot' '/etc/systemd/system/multi-user.target.w
<secondary>default installation</secondary>
</indexterm>
<para>The Postfix executable is <filename>postfix</filename>. This daemon launches all related processes needed to handle mail delivery.</para>
- <para>Postfix stores its configuration files in the <filename>/etc/postfix/</filename> directory. The following is a list of the more commonly used files:</para>
+ <para>Postfix stores its configuration files in the <filename class="directory">/etc/postfix/</filename> directory. The following is a list of the more commonly used files:</para>
<itemizedlist>
<listitem>
<para>
@@ -278,7 +278,7 @@ ln -s '/usr/lib/systemd/system/dovecot' '/etc/systemd/system/multi-user.target.w
</listitem>
</itemizedlist>
<para>
- The <filename>aliases</filename> file can be found in the <filename>/etc/</filename> directory. This file is shared between Postfix and Sendmail. It is a configurable list required by the mail protocol that describes user ID aliases.
+ The <filename>aliases</filename> file can be found in the <filename class="directory">/etc/</filename> directory. This file is shared between Postfix and Sendmail. It is a configurable list required by the mail protocol that describes user ID aliases.
</para>
<important>
<title>Configuring Postfix as a server for other clients</title>
@@ -411,7 +411,7 @@ search_base = dc=<replaceable>example</replaceable>, dc=<replaceable>com</replac
</itemizedlist>
<para>More information on configuring Sendmail can be found in <xref
linkend="s3-email-mta-sendmail-changes"/>.</para>
- <para>Various Sendmail configuration files are installed in the <filename>/etc/mail/</filename> directory including:</para>
+ <para>Various Sendmail configuration files are installed in the <filename class="directory">/etc/mail/</filename> directory including:</para>
<itemizedlist>
<listitem>
<para>
@@ -434,9 +434,9 @@ search_base = dc=<replaceable>example</replaceable>, dc=<replaceable>com</replac
<filename>virtusertable</filename> — Specifies a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.</para>
</listitem>
</itemizedlist>
- <para>Several of the configuration files in <filename>/etc/mail/</filename>, such as <filename>access</filename>, <filename>domaintable</filename>, <filename>mailertable</filename> and <filename>virtusertable</filename>, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following commands, as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>cd /etc/mail</command>
-~]# <command>make all</command></screen>
+ <para>Several of the configuration files in the <filename class="directory">/etc/mail/</filename> directory, such as <filename>access</filename>, <filename>domaintable</filename>, <filename>mailertable</filename> and <filename>virtusertable</filename>, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following commands, as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>cd /etc/mail/</command>
+~]# <command>make all</command></screen>
This will update <filename>virtusertable.db</filename>, <filename>access.db</filename>, <filename>domaintable.db</filename>, <filename>mailertable.db</filename>, <filename>sendmail.cf</filename>, and <filename>submit.cf</filename>.</para>
<para>
To update all the database files listed above and to update a custom database file, use a command in the following format:
@@ -490,7 +490,7 @@ where <replaceable>name.db</replaceable> represents the name of the database fil
<screen>~]# <command>systemctl restart sendmail</command></screen>
</important>
<para>The default configuration in &MAJOROS; works for most <systemitem class="protocol">SMTP</systemitem>-only sites. However, it does not work for <firstterm>UUCP</firstterm> (<firstterm>UNIX-to-UNIX Copy Protocol</firstterm>) sites. If using UUCP mail transfers, the <filename>/etc/mail/sendmail.mc</filename> file must be reconfigured and a new <filename>/etc/mail/sendmail.cf</filename> file must be generated.</para>
- <para>Consult the <filename>/usr/share/sendmail-cf/README</filename> file before editing any files in the directories under the <filename>/usr/share/sendmail-cf</filename> directory, as they can affect the future configuration of the <filename>/etc/mail/sendmail.cf</filename> file.</para>
+ <para>Consult the <filename>/usr/share/sendmail-cf/README</filename> file before editing any files in the directories under the <filename class="directory">/usr/share/sendmail-cf/</filename> directory, as they can affect the future configuration of the <filename>/etc/mail/sendmail.cf</filename> file.</para>
</section>
<section
id="s3-email-sendmail-changes-masquerading">
@@ -897,9 +897,9 @@ poll mail.domain2.com
</indexterm>
<para>Procmail delivers and filters email as it is placed in the mail spool file of the localhost. It is powerful, gentle on system resources, and widely used. Procmail can play a critical role in delivering email to be read by email client applications.</para>
<para>Procmail can be invoked in several different ways. Whenever an MTA places an email into the mail spool file, Procmail is launched. Procmail then filters and files the email for the MUA and quits. Alternatively, the MUA can be configured to execute Procmail any time a message is received so that messages are moved into their correct mailboxes. By default, the presence of <filename>/etc/procmailrc</filename> or of a <filename>~/.procmailrc</filename> file (also called an <firstterm>rc</firstterm> file) in the user's home directory invokes Procmail whenever an MTA receives a new message. </para>
- <para>By default, no system-wide <filename>rc</filename> files exist in the <filename>/etc/</filename> directory and no <filename>.procmailrc</filename> files exist in any user's home directory. Therefore, to use Procmail, each user must construct a <filename>.procmailrc</filename> file with specific environment variables and rules.</para>
+ <para>By default, no system-wide <filename>rc</filename> files exist in the <filename class="directory">/etc/</filename> directory and no <filename>.procmailrc</filename> files exist in any user's home directory. Therefore, to use Procmail, each user must construct a <filename>.procmailrc</filename> file with specific environment variables and rules.</para>
<para>Whether Procmail acts upon an email message depends upon whether the message matches a specified set of conditions or <firstterm>recipes</firstterm> in the <filename>rc</filename> file. If a message matches a recipe, then the email is placed in a specified file, is deleted, or is otherwise processed.</para>
- <para>When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for a <filename>/etc/procmailrc</filename> file and <filename>rc</filename> files in the <filename>/etc/procmailrcs</filename> directory for default, system-wide, Procmail environmental variables and recipes. Procmail then searches for a <filename>.procmailrc</filename> file in the user's home directory. Many users also create additional <filename>rc</filename> files for Procmail that are referred to within the <filename>.procmailrc</filename> file in their home directory.</para>
+ <para>When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for a <filename>/etc/procmailrc</filename> file and <filename>rc</filename> files in the <filename class="directory">/etc/procmailrcs</filename> directory for default, system-wide, Procmail environmental variables and recipes. Procmail then searches for a <filename>.procmailrc</filename> file in the user's home directory. Many users also create additional <filename>rc</filename> files for Procmail that are referred to within the <filename>.procmailrc</filename> file in their home directory.</para>
<section
id="s2-email-procmail-configuration">
<title>Procmail Configuration</title>
@@ -1202,7 +1202,7 @@ tuxlug</screen>
<para>This rule files all email tagged in the header as spam into a mailbox called <filename>spam</filename>.</para>
<para>Since SpamAssassin is a Perl script, it may be necessary on busy servers to use the binary SpamAssassin daemon (<systemitem class="daemon">spamd</systemitem>) and the client application (<application>spamc</application>). Configuring SpamAssassin this way, however, requires <systemitem class="username">root</systemitem> access to the host.</para>
<para>To start the <systemitem class="daemon">spamd</systemitem> daemon, type the following command:</para>
- <screen><command>systemctl start spamassassin.service</command></screen>
+ <screen>~]# <command>systemctl start spamassassin.service</command></screen>
<para>To start the SpamAssassin daemon when the system is booted, run:</para>
<screen><command>systemctl enable spamassassin.service</command></screen>
<para>
@@ -1253,17 +1253,17 @@ tuxlug</screen>
<para>First, create an SSL certificate. This can be done in two ways: by applying to a <firstterm>Certificate Authority</firstterm> (<firstterm>CA</firstterm>) for an SSL certificate or by creating a self-signed certificate.</para>
<warning>
<title>Avoid using self-signed certificates</title>
- <para>Self-signed certificates should be used for testing purposes only. Any server used in a production environment should use an SSL certificate granted by a CA.</para>
+ <para>Self-signed certificates should be used for testing purposes only. Any server used in a production environment should use an SSL certificate signed by a CA.</para>
</warning>
- <para>To create a self-signed SSL certificate for <systemitem class="protocol">IMAP</systemitem> or <systemitem class="protocol">POP</systemitem>, change to the <filename>/etc/pki/dovecot/</filename> directory, edit the certificate parameters in the <filename>/etc/pki/dovecot/dovecot-openssl.conf</filename> configuration file as you prefer, and type the following commands, as <systemitem class="username">root</systemitem>:</para>
- <screen>dovecot]# <command>rm -f certs/dovecot.pem private/dovecot.pem</command>
-dovecot]# <command>/usr/libexec/dovecot/mkcert.sh</command></screen>
+ <para>To create a self-signed SSL certificate for <systemitem class="protocol">IMAP</systemitem> or <systemitem class="protocol">POP</systemitem>, change to the <filename class="directory">/etc/pki/dovecot/</filename> directory, edit the certificate parameters in the <filename>/etc/pki/dovecot/dovecot-openssl.cnf</filename> configuration file as you prefer, and type the following commands, as <systemitem class="username">root</systemitem>:</para>
+ <screen>dovecot]# <command>rm -f certs/dovecot.pem private/dovecot.pem</command>
+dovecot]# <command>/usr/libexec/dovecot/mkcert.sh</command></screen>
<para>Once finished, make sure you have the following configurations in your <filename>/etc/dovecot/conf.d/10-ssl.conf</filename> file:</para>
<programlisting>ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem</programlisting>
<para>Issue the following command to restart the <command>dovecot</command> daemon:</para>
- <screen>~]# <command>systemctl restart dovecot</command></screen>
- <para>Alternatively, the <command>stunnel</command> command can be used as an SSL encryption wrapper around the standard, non-secure connections to <systemitem class="protocol">IMAP</systemitem> or <systemitem class="protocol">POP</systemitem> services.</para>
+ <screen>~]# <command>systemctl restart dovecot</command></screen>
+ <para>Alternatively, the <command>stunnel</command> command can be used as an encryption wrapper around the standard, non-secure connections to <systemitem class="protocol">IMAP</systemitem> or <systemitem class="protocol">POP</systemitem> services.</para>
<para>The <command>stunnel</command> utility uses external OpenSSL libraries included with &MAJOROS; to provide strong cryptography and to protect the network connections. It is recommended to apply to a CA to obtain an SSL certificate, but it is also possible to create a self-signed certificate.</para>
<note>
<title>Installing the stunnel package</title>
More information about the docs-commits
mailing list