doc/en_US.ISO8859-1/books/handbook/mail/chapter.xml
2016-04-03 18:57:15 +00:00

1951 lines
72 KiB
XML

<?xml version="1.0" encoding="iso-8859-1"?>
<!--
The FreeBSD Documentation Project
$FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="mail">
<info>
<title>Electronic Mail</title>
<authorgroup>
<author><personname><firstname>Bill</firstname><surname>Lloyd</surname></personname><contrib>Original
work by </contrib></author>
</authorgroup>
<authorgroup>
<author><personname><firstname>Jim</firstname><surname>Mock</surname></personname><contrib>Rewritten
by </contrib></author>
</authorgroup>
</info>
<sect1 xml:id="mail-synopsis">
<title>Synopsis</title>
<indexterm><primary>email</primary></indexterm>
<para><quote>Electronic Mail</quote>, better known as email, is
one of the most widely used forms of communication today. This
chapter provides a basic introduction to running a mail server
on &os;, as well as an introduction to sending and receiving
email using &os;. For more complete coverage of this subject,
refer to the books listed in <xref
linkend="bibliography"/>.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
<para>Which software components are involved in sending and
receiving electronic mail.</para>
</listitem>
<listitem>
<para>Where basic <application>Sendmail</application>
configuration files are located in &os;.</para>
</listitem>
<listitem>
<para>The difference between remote and local
mailboxes.</para>
</listitem>
<listitem>
<para>How to block spammers from illegally using a mail server
as a relay.</para>
</listitem>
<listitem>
<para>How to install and configure an alternate Mail Transfer
Agent, replacing
<application>Sendmail</application>.</para>
</listitem>
<listitem>
<para>How to troubleshoot common mail server problems.</para>
</listitem>
<listitem>
<para>How to set up the system to send mail only.</para>
</listitem>
<listitem>
<para>How to use mail with a dialup connection.</para>
</listitem>
<listitem>
<para>How to configure SMTP authentication for added
security.</para>
</listitem>
<listitem>
<para>How to install and use a Mail User Agent, such as
<application>mutt</application>, to send and receive
email.</para>
</listitem>
<listitem>
<para>How to download mail from a remote
<acronym>POP</acronym> or <acronym>IMAP</acronym>
server.</para>
</listitem>
<listitem>
<para>How to automatically apply filters and rules to incoming
email.</para>
</listitem>
</itemizedlist>
<para>Before reading this chapter, you should:</para>
<itemizedlist>
<listitem>
<para>Properly set up a network connection (<xref
linkend="advanced-networking"/>).</para>
</listitem>
<listitem>
<para>Properly set up the <acronym>DNS</acronym> information
for a mail host (<xref linkend="network-servers"/>).</para>
</listitem>
<listitem>
<para>Know how to install additional third-party software
(<xref linkend="ports"/>).</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 xml:id="mail-using">
<title>Mail Components</title>
<indexterm><primary>POP</primary></indexterm>
<indexterm><primary>IMAP</primary></indexterm>
<indexterm><primary>DNS</primary></indexterm>
<indexterm>
<primary>mail server daemons</primary>
<secondary><application>Sendmail</application></secondary>
</indexterm>
<indexterm>
<primary>mail server daemons</primary>
<secondary><application>Postfix</application></secondary>
</indexterm>
<indexterm>
<primary>mail server daemons</primary>
<secondary><application>qmail</application></secondary>
</indexterm>
<indexterm>
<primary>mail server daemons</primary>
<secondary><application>Exim</application></secondary>
</indexterm>
<indexterm>
<primary>email</primary>
<secondary>receiving</secondary>
</indexterm>
<indexterm><primary>MX record</primary></indexterm>
<indexterm><primary>mail host</primary></indexterm>
<para>There are five major parts involved in an email exchange:
the Mail User Agent (<acronym>MUA</acronym>), the Mail Transfer
Agent (<acronym>MTA</acronym>), a mail host, a remote or local
mailbox, and <acronym>DNS</acronym>. This section provides an
overview of these components.</para>
<variablelist>
<varlistentry>
<term>Mail User Agent (<acronym>MUA</acronym>)</term>
<listitem>
<para>The Mail User Agent (<acronym>MUA</acronym>) is an
application which is used to compose, send, and receive
emails. This application can be a command line program,
such as the built-in <command>mail</command> utility or a
third-party application from the Ports Collection, such as
<application>mutt</application>,
<application>alpine</application>, or
<application>elm</application>. Dozens of graphical
programs are also available in the Ports Collection,
including <application>Claws Mail</application>,
<application>Evolution</application>, and
<application>Thunderbird</application>. Some
organizations provide a web mail program which can be
accessed through a web browser. More information about
installing and using a <acronym>MUA</acronym> on &os; can
be found in <xref linkend="mail-agents"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Transfer Agent (<acronym>MTA</acronym>)</term>
<listitem>
<para>The Mail Transfer Agent (<acronym>MTA</acronym>) is
responsible for receiving incoming mail and delivering
outgoing mail. &os; ships with
<application>Sendmail</application> as the default
<acronym>MTA</acronym>, but it also supports numerous
other mail server daemons, including
<application>Exim</application>,
<application>Postfix</application>, and
<application>qmail</application>.
<application>Sendmail</application> configuration is
described in <xref linkend="sendmail"/>. If another
<acronym>MTA</acronym> is installed using the Ports
Collection, refer to its post-installation message for
&os;-specific configuration details and the application's
website for more general configuration
instructions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Host and Mailboxes</term>
<listitem>
<para>The mail host is a server that is responsible for
delivering and receiving mail for a host or a network.
The mail host collects all mail sent to the domain and
stores it either in the default <filename>mbox</filename>
or the alternative Maildir format, depending on the
configuration. Once mail has been stored, it may either
be read locally using a <acronym>MUA</acronym> or remotely
accessed and collected using protocols such as
<acronym>POP</acronym> or <acronym>IMAP</acronym>. If
mail is read locally, a <acronym>POP</acronym> or
<acronym>IMAP</acronym> server does not need to be
installed.</para>
<para>To access mailboxes remotely, a <acronym>POP</acronym>
or <acronym>IMAP</acronym> server is required as these
protocols allow users to connect to their mailboxes from
remote locations. <acronym>IMAP</acronym> offers several
advantages over <acronym>POP</acronym>. These include the
ability to store a copy of messages on a remote server
after they are downloaded and concurrent updates.
<acronym>IMAP</acronym> can be useful over low-speed links
as it allows users to fetch the structure of messages
without downloading them. It can also perform tasks such
as searching on the server in order to minimize data
transfer between clients and servers.</para>
<para>Several <acronym>POP</acronym> and
<acronym>IMAP</acronym> servers are available in the Ports
Collection. These include
<package>mail/qpopper</package>,
<package>mail/imap-uw</package>,
<package>mail/courier-imap</package>, and
<package>mail/dovecot2</package>.</para>
<warning>
<para>It should be noted that both <acronym>POP</acronym>
and <acronym>IMAP</acronym> transmit information,
including username and password credentials, in
clear-text. To secure the transmission of information
across these protocols, consider tunneling sessions over
&man.ssh.1; (<xref linkend="security-ssh-tunneling"/>)
or using <acronym>SSL</acronym> (<xref
linkend="openssl"/>).</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term>Domain Name System (<acronym>DNS</acronym>)</term>
<listitem>
<para>The Domain Name System (<acronym>DNS</acronym>) and
its daemon <command>named</command> play a large role in
the delivery of email. In order to deliver mail from one
site to another, the <acronym>MTA</acronym> will look up
the remote site in <acronym>DNS</acronym> to determine
which host will receive mail for the destination. This
process also occurs when mail is sent from a remote host
to the <acronym>MTA</acronym>.</para>
<para>In addition to mapping hostnames to
<acronym>IP</acronym> addresses, <acronym>DNS</acronym> is
responsible for storing information specific to mail
delivery, known as Mail eXchanger
<acronym>MX</acronym> records. The <acronym>MX</acronym>
record specifies which hosts will receive mail for a
particular domain.</para>
<para>To view the <acronym>MX</acronym> records for a
domain, specify the type of record. Refer to
&man.host.1;, for more details about this command:</para>
<screen>&prompt.user; <userinput>host -t mx FreeBSD.org</userinput>
FreeBSD.org mail is handled by 10 mx1.FreeBSD.org</screen>
<para>Refer to <xref linkend="network-dns"/> for more
information about <acronym>DNS</acronym> and its
configuration.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 xml:id="sendmail">
<info>
<title><application>Sendmail</application> Configuration
Files</title>
<authorgroup>
<author>
<personname>
<firstname>Christopher</firstname>
<surname>Shumway</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary><application>Sendmail</application></primary>
</indexterm>
<para><application>Sendmail</application> is the default
<acronym>MTA</acronym> installed with &os;. It accepts mail
from <acronym>MUA</acronym>s and delivers it to the appropriate
mail host, as defined by its configuration.
<application>Sendmail</application> can also accept network
connections and deliver mail to local mailboxes or to another
program.</para>
<para>The configuration files for
<application>Sendmail</application> are located in
<filename>/etc/mail</filename>. This section describes these
files in more detail.</para>
<indexterm>
<primary><filename>/etc/mail/access</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/aliases</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/local-host-names</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/mailer.conf</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/mailertable</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/sendmail.cf</filename></primary>
</indexterm>
<indexterm>
<primary><filename>/etc/mail/virtusertable</filename></primary>
</indexterm>
<variablelist>
<varlistentry>
<term><filename>/etc/mail/access</filename></term>
<listitem>
<para>This access database file defines which hosts or
<acronym>IP</acronym> addresses have access to the local
mail server and what kind of access they have. Hosts
listed as <option>OK</option>, which is the default
option, are allowed to send mail to this host as long as
the mail's final destination is the local machine. Hosts
listed as <option>REJECT</option> are rejected for all
mail connections. Hosts listed as <option>RELAY</option>
are allowed to send mail for any destination using this
mail server. Hosts listed as <option>ERROR</option> will
have their mail returned with the specified mail error.
If a host is listed as <option>SKIP</option>,
<application>Sendmail</application> will abort the current
search for this entry without accepting or rejecting the
mail. Hosts listed as <option>QUARANTINE</option> will
have their messages held and will receive the specified
text as the reason for the hold.</para>
<para>Examples of using these options for both
<acronym>IPv4</acronym> and <acronym>IPv6</acronym>
addresses can be found in the &os; sample configuration,
<filename>/etc/mail/access.sample</filename>:</para>
<programlisting># $FreeBSD$
#
# Mail relay access control list. Default is to reject mail unless the
# destination is local, or listed in /etc/mail/local-host-names
#
## Examples (commented out for safety)
#From:cyberspammer.com ERROR:"550 We don't accept mail from spammers"
#From:okay.cyberspammer.com OK
#Connect:sendmail.org RELAY
#To:sendmail.org RELAY
#Connect:128.32 RELAY
#Connect:128.32.2 SKIP
#Connect:IPv6:1:2:3:4:5:6:7 RELAY
#Connect:suspicious.example.com QUARANTINE:Mail from suspicious host
#Connect:[127.0.0.3] OK
#Connect:[IPv6:1:2:3:4:5:6:7:8] OK</programlisting>
<para>To configure the access database, use the format shown
in the sample to make entries in
<filename>/etc/mail/access</filename>, but do not put a
comment symbol (<literal>#</literal>) in front of the
entries. Create an entry for each host or network whose
access should be configured. Mail senders that match the
left side of the table are affected by the action on the
right side of the table.</para>
<para>Whenever this file is updated, update its database and
restart <application>Sendmail</application>:</para>
<screen>&prompt.root; <userinput>makemap hash /etc/mail/access &lt; /etc/mail/access</userinput>
&prompt.root; <userinput>service sendmail restart</userinput></screen>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/etc/mail/aliases</filename></term>
<listitem>
<para>This database file contains a list of virtual
mailboxes that are expanded to users, files, programs, or
other aliases. Here are a few entries to illustrate the
file format:</para>
<programlisting>root: localuser
ftp-bugs: joe,eric,paul
bit.bucket: /dev/null
procmail: "|/usr/local/bin/procmail"</programlisting>
<para>The mailbox name on the left side of the colon is
expanded to the target(s) on the right. The first entry
expands the <systemitem class="username">root</systemitem>
mailbox to the <systemitem
class="username">localuser</systemitem> mailbox, which
is then looked up in the
<filename>/etc/mail/aliases</filename> database. If no
match is found, the message is delivered to <systemitem
class="username">localuser</systemitem>. The second
entry shows a mail list. Mail to <systemitem
class="username">ftp-bugs</systemitem> is expanded to
the three local mailboxes <systemitem
class="username">joe</systemitem>, <systemitem
class="username">eric</systemitem>, and <systemitem
class="username">paul</systemitem>. A remote mailbox
could be specified as
<replaceable>user@example.com</replaceable>. The third
entry shows how to write mail to a file, in this case
<filename>/dev/null</filename>. The last entry
demonstrates how to send mail to a program,
<filename>/usr/local/bin/procmail</filename>, through a
&unix; pipe. Refer to &man.aliases.5; for more
information about the format of this file.</para>
<para>Whenever this file is updated, run
<command>newaliases</command> to update and initialize the
aliases database.</para>
</listitem>
</varlistentry>
<!--
This section needs to explain that this feature is for hosts with
alternate names, such as a host that MXs for a dynamic set of other
hosts.
It won't work unless freebsd.mc is built with FEATURE(`use_cw_file'),
meaning it needs a section to refer to on how to make mc files.
<varlistentry>
<term><filename>/etc/mail/local-host-names</filename></term>
<listitem>
<para>This is a list of hostnames <application>Sendmail</application> will accept
as the local host name. Place any domains or hosts that
<application>Sendmail</application> will receive mail for.
For example, to configure a mail server to accept mail for the
domain <systemitem
class="fqdomainname">example.com</systemitem> and the host
<systemitem
class="fqdomainname">mail.example.com</systemitem>, add
these entries to
<filename>local-host-names</filename>:</para>
<programlisting>example.com
mail.example.com</programlisting>
<para>Whenever this file is updated, &man.sendmail.8; needs to be
restarted so that it will read the changes.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><filename>/etc/mail/sendmail.cf</filename></term>
<listitem>
<para>This is the master configuration file for
<application>Sendmail</application>. It controls the
overall behavior of <application>Sendmail</application>,
including everything from rewriting email addresses to
printing rejection messages to remote mail servers.
Accordingly, this configuration file is quite complex.
Fortunately, this file rarely needs to be changed for
standard mail servers.</para>
<para>The master <application>Sendmail</application>
configuration file can be built from &man.m4.1; macros
that define the features and behavior of
<application>Sendmail</application>. Refer to
<filename>/usr/src/contrib/sendmail/cf/README</filename>
for some of the details.</para>
<para>Whenever changes to this file are made,
<application>Sendmail</application> needs to be restarted
for the changes to take effect.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/etc/mail/virtusertable</filename></term>
<listitem>
<para>This database file maps mail addresses for virtual
domains and users to real mailboxes. These mailboxes can
be local, remote, aliases defined in
<filename>/etc/mail/aliases</filename>, or files. This
allows multiple virtual domains to be hosted on one
machine.</para>
<para>&os; provides a sample configuration file in
<filename>/etc/mail/virtusertable.sample</filename> to
further demonstrate its format. The following example
demonstrates how to create custom entries using that
format:</para>
<programlisting>root@example.com root
postmaster@example.com postmaster@noc.example.net
@example.com joe</programlisting>
<para>This file is processed in a first match order. When
an email address matches the address on the left, it is
mapped to the local mailbox listed on the right. The
format of the first entry in this example maps a specific
email address to a local mailbox, whereas the format of
the second entry maps a specific email address to a remote
mailbox. Finally, any email address from
<literal>example.com</literal> which has not matched any
of the previous entries will match the last mapping and be
sent to the local mailbox <literal>joe</literal>. When
creating custom entries, use this format and add them to
<filename>/etc/mail/virtusertable</filename>. Whenever
this file is edited, update its database and restart
<application>Sendmail</application>:</para>
<screen>&prompt.root; <userinput>makemap hash /etc/mail/virtusertable &lt; /etc/mail/virtusertable</userinput>
&prompt.root; <userinput>service sendmail restart</userinput></screen>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/etc/mail/relay-domains</filename></term>
<listitem>
<para>In a default &os; installation,
<application>Sendmail</application> is configured to only
send mail from the host it is running on. For example, if
a <acronym>POP</acronym> server is available, users will
be able to check mail from remote locations but they will
not be able to send outgoing emails from outside
locations. Typically, a few moments after the attempt, an
email will be sent from <literal>MAILER-DAEMON</literal>
with a <errorname>5.7 Relaying Denied</errorname>
message.</para>
<para>The most straightforward solution is to add the
<acronym>ISP</acronym>'s <acronym>FQDN</acronym> to
<filename>/etc/mail/relay-domains</filename>. If multiple
addresses are needed, add them one per
line:</para>
<programlisting>your.isp.example.com
other.isp.example.net
users-isp.example.org
www.example.org</programlisting>
<para>After creating or editing this file, restart
<application>Sendmail</application> with
<command>service sendmail restart</command>.</para>
<para>Now any mail sent through the system by any host in
this list, provided the user has an account on the system,
will succeed. This allows users to send mail from the
system remotely without opening the system up to relaying
<acronym>SPAM</acronym> from the Internet.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 xml:id="mail-changingmta">
<info>
<title>Changing the Mail Transfer Agent</title>
<authorgroup>
<author>
<personname>
<firstname>Andrew</firstname>
<surname>Boothman</surname>
</personname>
<contrib>Written by </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<personname>
<firstname>Gregory</firstname>
<surname>Neil Shapiro</surname>
</personname>
<contrib>Information taken from emails written by </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>email</primary>
<secondary>change mta</secondary>
</indexterm>
<para>&os; comes with <application>Sendmail</application> already
installed as the <acronym>MTA</acronym> which is in charge of
outgoing and incoming mail. However, the system administrator
can change the system's <acronym>MTA</acronym>. A wide choice
of alternative <acronym>MTA</acronym>s is available from the
<literal>mail</literal> category of the &os; Ports
Collection.</para>
<para>Once a new <acronym>MTA</acronym> is installed, configure
and test the new software before replacing
<application>Sendmail</application>. Refer to the documentation
of the new <acronym>MTA</acronym> for information on how to
configure the software.</para>
<para>Once the new <acronym>MTA</acronym> is working, use the
instructions in this section to disable
<application>Sendmail</application> and configure &os; to use
the replacement <acronym>MTA</acronym>.</para>
<sect2 xml:id="mail-disable-sendmail">
<title>Disable <application>Sendmail</application></title>
<warning>
<para>If <application>Sendmail</application>'s outgoing mail
service is disabled, it is important that it is replaced
with an alternative mail delivery system. Otherwise, system
functions such as &man.periodic.8; will be unable to deliver
their results by email. Many parts of the system expect a
functional <acronym>MTA</acronym>. If applications continue
to use <application>Sendmail</application>'s binaries to try
to send email after they are disabled, mail could go into an
inactive <application>Sendmail</application> queue and
never be delivered.</para>
</warning>
<para>In order to completely disable
<application>Sendmail</application>, add or edit the following
lines in <filename>/etc/rc.conf</filename>:</para>
<programlisting>sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"</programlisting>
<para>To only disable <application>Sendmail</application>'s
incoming mail service, use only this entry in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>sendmail_enable="NO"</programlisting>
<para>More information on <application>Sendmail</application>'s
startup options is available in &man.rc.sendmail.8;.</para>
</sect2>
<sect2>
<title>Replace the Default <acronym>MTA</acronym></title>
<para>When a new <acronym>MTA</acronym> is installed using the
Ports Collection, its startup script is also installed and
startup instructions are mentioned in its package message.
Before starting the new <acronym>MTA</acronym>, stop the
running <application>Sendmail</application> processes. This
example stops all of these services, then starts the
<application>Postfix</application> service:</para>
<screen>&prompt.root; <userinput>service sendmail stop</userinput>
&prompt.root; <userinput>service postfix start</userinput></screen>
<para>To start the replacement <acronym>MTA</acronym> at system
boot, add its configuration line to
<filename>/etc/rc.conf</filename>. This entry enables the
Postfix <acronym>MTA</acronym>:</para>
<programlisting>postfix_enable="YES"</programlisting>
<para>Some extra configuration is needed as
<application>Sendmail</application> is so ubiquitous that some
software assumes it is already installed and configured.
Check <filename>/etc/periodic.conf</filename> and make sure
that these values are set to <literal>NO</literal>. If this
file does not exist, create it with these entries:</para>
<programlisting>daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"</programlisting>
<para>Some alternative <acronym>MTA</acronym>s provide their own
compatible implementations of the
<application>Sendmail</application> command-line interface in
order to facilitate using them as drop-in replacements for
<application>Sendmail</application>. However, some
<acronym>MUA</acronym>s may try to execute standard
<application>Sendmail</application> binaries instead of the
new <acronym>MTA</acronym>'s binaries. &os; uses
<filename>/etc/mail/mailer.conf</filename> to map the expected
<application>Sendmail</application> binaries to the location
of the new binaries. More information about this mapping can
be found in &man.mailwrapper.8;.</para>
<para>The default <filename>/etc/mail/mailer.conf</filename>
looks like this:</para>
<programlisting># $FreeBSD$
#
# Execute the "real" sendmail program, named /usr/libexec/sendmail/sendmail
#
sendmail /usr/libexec/sendmail/sendmail
send-mail /usr/libexec/sendmail/sendmail
mailq /usr/libexec/sendmail/sendmail
newaliases /usr/libexec/sendmail/sendmail
hoststat /usr/libexec/sendmail/sendmail
purgestat /usr/libexec/sendmail/sendmail</programlisting>
<para>When any of the commands listed on the left are run, the
system actually executes the associated command shown on the
right. This system makes it easy to change what binaries are
executed when these default binaries are invoked.</para>
<para>Some <acronym>MTA</acronym>s, when installed using the
Ports Collection, will prompt to update this file for the new
binaries. For example, <application>Postfix</application>
will update the file like this:</para>
<programlisting>#
# Execute the Postfix sendmail program, named /usr/local/sbin/sendmail
#
sendmail /usr/local/sbin/sendmail
send-mail /usr/local/sbin/sendmail
mailq /usr/local/sbin/sendmail
newaliases /usr/local/sbin/sendmail</programlisting>
<para>If the installation of the <acronym>MTA</acronym> does
not automatically update
<filename>/etc/mail/mailer.conf</filename>, edit this file in
a text editor so that it points to the new binaries. This
example points to the binaries installed by
<package>mail/ssmtp</package>:</para>
<programlisting>sendmail /usr/local/sbin/ssmtp
send-mail /usr/local/sbin/ssmtp
mailq /usr/libexec/sendmail/sendmail
newaliases /usr/libexec/sendmail/sendmail
hoststat /usr/libexec/sendmail/sendmail
purgestat /usr/libexec/sendmail/sendmail</programlisting>
<para>Once everything is configured, it is recommended to reboot
the system. Rebooting provides the opportunity to ensure that
the system is correctly configured to start the new
<acronym>MTA</acronym> automatically on boot.</para>
</sect2>
</sect1>
<sect1 xml:id="mail-trouble">
<title>Troubleshooting</title>
<indexterm>
<primary>email</primary>
<secondary>troubleshooting</secondary>
</indexterm>
<qandaset>
<qandaentry>
<question>
<para>Why do I have to use the FQDN for hosts on my
site?</para>
</question>
<answer>
<para>The host may actually be in a different domain. For
example, in order for a host in <systemitem
class="fqdomainname">foo.bar.edu</systemitem> to reach a
host called <systemitem>mumble</systemitem> in the
<systemitem class="fqdomainname">bar.edu</systemitem>
domain, refer to it by the Fully-Qualified Domain Name
<acronym>FQDN</acronym>, <systemitem
class="fqdomainname">mumble.bar.edu</systemitem>,
instead of just <systemitem>mumble</systemitem>.</para>
<para>This is because the version of
<application>BIND</application><indexterm>
<primary>BIND</primary></indexterm> which ships with &os;
no longer provides default abbreviations for non-FQDNs
other than the local domain. An unqualified host such as
<systemitem>mumble</systemitem> must either be found as
<systemitem
class="fqdomainname">mumble.foo.bar.edu</systemitem>, or
it will be searched for in the root domain.</para>
<para>In older versions of <application>BIND</application>,
the search continued across <systemitem
class="fqdomainname">mumble.bar.edu</systemitem>, and
<systemitem class="fqdomainname">mumble.edu</systemitem>.
RFC 1535 details why this is considered bad practice or
even a security hole.</para>
<para>As a good workaround, place the line:</para>
<programlisting>search foo.bar.edu bar.edu</programlisting>
<para>instead of the previous:</para>
<programlisting>domain foo.bar.edu</programlisting>
<para>into <filename>/etc/resolv.conf</filename>. However,
make sure that the search order does not go beyond the
<quote>boundary between local and public
administration</quote>, as RFC 1535 calls it.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How can I run a mail server on a dial-up PPP
host?</para>
</question>
<answer>
<para>Connect to a &os; mail gateway on the LAN. The PPP
connection is non-dedicated.</para>
<para>One way to do this is to get a full-time Internet
server to provide secondary
<acronym>MX</acronym>
<indexterm><primary>MX record</primary></indexterm>
services for the domain. In this example, the domain is
<systemitem class="fqdomainname">example.com</systemitem>
and the ISP has configured
<systemitem class="fqdomainname">example.net</systemitem>
to provide secondary <acronym>MX</acronym> services to the
domain:</para>
<programlisting>example.com. MX 10 example.com.
MX 20 example.net.</programlisting>
<para>Only one host should be specified as the final
recipient. For <application>Sendmail</application>, add
<literal>Cw example.com</literal> in
<filename>/etc/mail/sendmail.cf</filename> on <systemitem
class="fqdomainname">example.com</systemitem>.</para>
<para>When the sending <acronym>MTA</acronym> attempts
to deliver mail, it will try to connect to the system,
<systemitem class="fqdomainname">example.com</systemitem>,
over the PPP link. This will time out if the destination
is offline. The <acronym>MTA</acronym> will automatically
deliver it to the secondary <acronym>MX</acronym> site at
the Internet Service Provider (<acronym>ISP</acronym>),
<systemitem class="fqdomainname">example.net</systemitem>.
The secondary <acronym>MX</acronym> site will periodically
try to connect to the primary <acronym>MX</acronym> host,
<systemitem
class="fqdomainname">example.com</systemitem>.</para>
<para>Use something like this as a login script:</para>
<programlisting>#!/bin/sh
# Put me in /usr/local/bin/pppmyisp
( sleep 60 ; /usr/sbin/sendmail -q ) &amp;
/usr/sbin/ppp -direct pppmyisp</programlisting>
<para>When creating a separate login script for users,
instead use <command>sendmail -qRexample.com</command> in
the script above. This will force all mail in the queue
for
<systemitem class="fqdomainname">example.com</systemitem>
to be processed immediately.</para>
<para>A further refinement of the situation can be seen from
this example from the &a.isp;:</para>
<programlisting>&gt; we provide the secondary MX for a customer. The customer connects to
&gt; our services several times a day automatically to get the mails to
&gt; his primary MX (We do not call his site when a mail for his domains
&gt; arrived). Our sendmail sends the mailqueue every 30 minutes. At the
&gt; moment he has to stay 30 minutes online to be sure that all mail is
&gt; gone to the primary MX.
&gt;
&gt; Is there a command that would initiate sendmail to send all the mails
&gt; now? The user has not root-privileges on our machine of course.
In the <quote>privacy flags</quote> section of sendmail.cf, there is a
definition Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
customers like this, and we have defined:
# If we are the best MX for a host, try directly instead of generating
# local config error.
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
<quote>hosts</quote>, so you need to get your customer to name their mail
machine <quote>customer.com</quote> as well as
<quote>hostname.customer.com</quote> in the DNS. Just put an A record in
the DNS for <quote>customer.com</quote>.</programlisting>
</answer>
</qandaentry>
</qandaset>
</sect1>
<sect1 xml:id="mail-advanced">
<title>Advanced Topics</title>
<para>This section covers more involved topics such as mail
configuration and setting up mail for an entire domain.</para>
<sect2 xml:id="mail-config">
<title>Basic Configuration</title>
<indexterm>
<primary>email</primary>
<secondary>configuration</secondary>
</indexterm>
<para>Out of the box, one can send email to external hosts as
long as <filename>/etc/resolv.conf</filename> is configured or
the network has access to a configured <acronym>DNS</acronym>
server. To have email delivered to the <acronym>MTA</acronym>
on the &os; host, do one of the following:</para>
<itemizedlist>
<listitem>
<para>Run a <acronym>DNS</acronym> server for the
domain.</para>
</listitem>
<listitem>
<para>Get mail delivered directly to the
<acronym>FQDN</acronym> for the machine.</para>
</listitem>
</itemizedlist>
<indexterm><primary>SMTP</primary></indexterm>
<para>In order to have mail delivered directly to a host, it
must have a permanent static IP address, not a dynamic IP
address. If the system is behind a firewall, it must be
configured to allow SMTP traffic. To receive mail directly at
a host, one of these two must be configured:</para>
<itemizedlist>
<listitem>
<para>Make sure that the lowest-numbered
<acronym>MX</acronym><indexterm><primary>MX
record</primary></indexterm> record in
<acronym>DNS</acronym> points to the host's static IP
address.</para>
</listitem>
<listitem>
<para>Make sure there is no <acronym>MX</acronym> entry in
the <acronym>DNS</acronym> for the host.</para>
</listitem>
</itemizedlist>
<para>Either of the above will allow mail to be received
directly at the host.</para>
<para>Try this:</para>
<screen>&prompt.root; <userinput>hostname</userinput>
example.FreeBSD.org
&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX</screen>
<para>In this example, mail sent directly to
<email role="nolink">yourlogin@example.FreeBSD.org</email>
should work without problems, assuming
<application>Sendmail</application> is running correctly on
<systemitem
class="fqdomainname">example.FreeBSD.org</systemitem>.</para>
<para>For this example:</para>
<screen>&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX
example.FreeBSD.org mail is handled (pri=10) by nevdull.FreeBSD.org</screen>
<para>All mail sent to <systemitem
class="fqdomainname">example.FreeBSD.org</systemitem> will
be collected on <systemitem>hub</systemitem> under the same
username instead of being sent directly to your host.</para>
<para>The above information is handled by the
<acronym>DNS</acronym> server. The <acronym>DNS</acronym>
record that carries mail routing information is the
<acronym>MX</acronym> entry. If no <acronym>MX</acronym>
record exists, mail will be delivered directly to the host by
way of its IP address.</para>
<para>The <acronym>MX</acronym> entry for <systemitem
class="fqdomainname">freefall.FreeBSD.org</systemitem> at
one time looked like this:</para>
<programlisting>freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com</programlisting>
<para><systemitem>freefall</systemitem> had many
<acronym>MX</acronym> entries. The lowest
<acronym>MX</acronym> number is the host that receives mail
directly, if available. If it is not accessible for some
reason, the next lower-numbered host will accept messages
temporarily, and pass it along when a lower-numbered host
becomes available.</para>
<para>Alternate <acronym>MX</acronym> sites should have separate
Internet connections in order to be most useful. Your
<acronym>ISP</acronym> can provide this service.</para>
</sect2>
<sect2 xml:id="mail-domain">
<title>Mail for a Domain</title>
<para>When configuring a <acronym>MTA</acronym> for a network,
any mail sent to hosts in its domain should be diverted to the
<acronym>MTA</acronym> so that users can receive their mail on
the master mail server.</para>
<indexterm><primary>DNS</primary></indexterm>
<para>To make life easiest, a user account with the same
<emphasis>username</emphasis> should exist on both the
<acronym>MTA</acronym> and the system with the
<acronym>MUA</acronym>. Use &man.adduser.8; to create the
user accounts.</para>
<para>The <acronym>MTA</acronym> must be the designated mail
exchanger for each workstation on the network. This is done
in the<acronym>DNS</acronym> configuration with an
<acronym>MX</acronym> record:</para>
<programlisting>example.FreeBSD.org A 204.216.27.XX ; Workstation
MX 10 nevdull.FreeBSD.org ; Mailhost</programlisting>
<para>This will redirect mail for the workstation to the
<acronym>MTA</acronym> no matter where the A record points.
The mail is sent to the <acronym>MX</acronym> host.</para>
<para>This must be configured on a <acronym>DNS</acronym>
server. If the network does not run its own
<acronym>DNS</acronym> server, talk to the
<acronym>ISP</acronym> or <acronym>DNS</acronym>
provider.</para>
<para>The following is an example of virtual email hosting.
Consider a customer with the domain <systemitem
class="fqdomainname">customer1.org</systemitem>, where all
the mail for <systemitem
class="fqdomainname">customer1.org</systemitem> should be
sent to <systemitem
class="fqdomainname">mail.myhost.com</systemitem>. The
<acronym>DNS</acronym> entry should look like this:</para>
<programlisting>customer1.org MX 10 mail.myhost.com</programlisting>
<para>An <literal>A</literal>&gt; record is
<emphasis>not</emphasis> needed for <systemitem
class="fqdomainname">customer1.org</systemitem> in order to
only handle email for that domain. However, running
<command>ping</command> against <systemitem
class="fqdomainname">customer1.org</systemitem> will not
work unless an <literal>A</literal> record exists for
it.</para>
<para>Tell the <acronym>MTA</acronym> which domains and/or
hostnames it should accept mail for. Either of the following
will work for <application>Sendmail</application>:</para>
<itemizedlist>
<listitem>
<para>Add the hosts to
<filename>/etc/mail/local-host-names</filename> when
using the <literal>FEATURE(use_cw_file)</literal>.</para>
</listitem>
<listitem>
<para>Add a <literal>Cwyour.host.com</literal> line to
<filename>/etc/sendmail.cf</filename>.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 xml:id="outgoing-only">
<info>
<title>Setting Up to Send Only</title>
<authorgroup>
<author>
<personname>
<firstname>Bill</firstname>
<surname>Moran</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
<para>There are many instances where one may only want to send
mail through a relay. Some examples are:</para>
<itemizedlist>
<listitem>
<para>The computer is a desktop machine that needs to use
programs such as &man.send-pr.1;, using the
<acronym>ISP</acronym>'s mail relay.</para>
</listitem>
<listitem>
<para>The computer is a server that does not handle mail
locally, but needs to pass off all mail to a relay for
processing.</para>
</listitem>
</itemizedlist>
<para>While any <acronym>MTA</acronym> is capable of filling
this particular niche, it can be difficult to properly configure
a full-featured <acronym>MTA</acronym> just to handle offloading
mail. Programs such as <application>Sendmail</application> and
<application>Postfix</application> are overkill for this
use.</para>
<para>Additionally, a typical Internet access service agreement
may forbid one from running a <quote>mail server</quote>.</para>
<para>The easiest way to fulfill those needs is to install the
<package>mail/ssmtp</package> port:</para>
<screen>&prompt.root; <userinput>cd /usr/ports/mail/ssmtp</userinput>
&prompt.root; <userinput>make install replace clean</userinput></screen>
<para>Once installed, <package>mail/ssmtp</package> can be
configured with
<filename>/usr/local/etc/ssmtp/ssmtp.conf</filename>:</para>
<programlisting>root=yourrealemail@example.com
mailhub=mail.example.com
rewriteDomain=example.com
hostname=_HOSTNAME_</programlisting>
<para>Use the real email address for <systemitem
class="username">root</systemitem>. Enter the
<acronym>ISP</acronym>'s outgoing mail relay in place of
<systemitem class="fqdomainname">mail.example.com</systemitem>.
Some <acronym>ISP</acronym>s call this the <quote>outgoing mail
server</quote> or <quote>SMTP server</quote>.</para>
<para>Make sure to disable <application>Sendmail</application>,
including the outgoing mail service. See <xref
linkend="mail-disable-sendmail"/> for details.</para>
<para><package>mail/ssmtp</package> has some other options
available. Refer to the examples in
<filename>/usr/local/etc/ssmtp</filename> or the manual page
of <application>ssmtp</application> for more information.</para>
<para>Setting up <application>ssmtp</application> in this manner
allows any software on the computer that needs to send mail to
function properly, while not violating the
<acronym>ISP</acronym>'s usage policy or allowing the computer
to be hijacked for spamming.</para>
</sect1>
<sect1 xml:id="SMTP-dialup">
<title>Using Mail with a Dialup Connection</title>
<para>When using a static IP address, one should not need to
adjust the default configuration. Set the hostname to the
assigned Internet name and <application>Sendmail</application>
will do the rest.</para>
<para>When using a dynamically assigned IP address and a dialup
PPP connection to the Internet, one usually has a mailbox on the
<acronym>ISP</acronym>'s mail server. In this example, the
<acronym>ISP</acronym>'s domain is <systemitem
class="fqdomainname">example.net</systemitem>, the user name
is <systemitem class="username">user</systemitem>, the hostname
is <systemitem class="fqdomainname">bsd.home</systemitem>, and
the <acronym>ISP</acronym> has allowed <systemitem
class="fqdomainname">relay.example.net</systemitem> as a mail
relay.</para>
<para>In order to retrieve mail from the <acronym>ISP</acronym>'s
mailbox, install a retrieval agent from the Ports Collection.
<package>mail/fetchmail</package> is a good choice as it
supports many different protocols. Usually, the
<acronym>ISP</acronym> will provide <acronym>POP</acronym>.
When using user <acronym>PPP</acronym>, email can be
automatically fetched when an Internet connection is established
with the following entry in
<filename>/etc/ppp/ppp.linkup</filename>:</para>
<programlisting>MYADDR:
!bg su user -c fetchmail</programlisting>
<para>When using <application>Sendmail</application> to deliver
mail to non-local accounts, configure
<application>Sendmail</application> to process the mail queue as
soon as the Internet connection is established. To do this, add
this line after the above <command>fetchmail</command> entry in
<filename>/etc/ppp/ppp.linkup</filename>:</para>
<programlisting> !bg su user -c "sendmail -q"</programlisting>
<para>In this example, there is an account for
<systemitem class="username">user</systemitem> on <systemitem
class="fqdomainname">bsd.home</systemitem>. In the home
directory of <systemitem class="username">user</systemitem> on
<systemitem class="fqdomainname">bsd.home</systemitem>, create a
<filename>.fetchmailrc</filename> which contains this
line:</para>
<programlisting>poll example.net protocol pop3 fetchall pass MySecret</programlisting>
<para>This file should not be readable by anyone except
<systemitem class="username">user</systemitem> as it contains
the password <literal>MySecret</literal>.</para>
<para>In order to send mail with the correct
<literal>from:</literal> header, configure
<application>Sendmail</application> to use
<email>user@example.net</email> rather than <email
role="nolink">user@bsd.home</email> and to send all mail via
<systemitem class="fqdomainname">relay.example.net</systemitem>,
allowing quicker mail transmission.</para>
<para>The following <filename>.mc</filename> should
suffice:</para>
<programlisting>VERSIONID(`bsd.home.mc version 1.0')
OSTYPE(bsd4.4)dnl
FEATURE(nouucp)dnl
MAILER(local)dnl
MAILER(smtp)dnl
Cwlocalhost
Cwbsd.home
MASQUERADE_AS(`example.net')dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(nocanonify)dnl
FEATURE(nodns)dnl
define(`SMART_HOST', `relay.example.net')
Dmbsd.home
define(`confDOMAIN_NAME',`bsd.home')dnl
define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
<para>Refer to the previous section for details of how to convert
this file into the <filename>sendmail.cf</filename> format. Do
not forget to restart <application>Sendmail</application> after
updating <filename>sendmail.cf</filename>.</para>
</sect1>
<sect1 xml:id="SMTP-Auth">
<info>
<title>SMTP Authentication</title>
<authorgroup>
<author>
<personname>
<firstname>James</firstname>
<surname>Gorham</surname>
</personname>
<contrib>Written by </contrib>
</author>
</authorgroup>
</info>
<para>Configuring <acronym>SMTP</acronym> authentication on the
<acronym>MTA</acronym> provides a number of benefits.
<acronym>SMTP</acronym> authentication adds a layer
of security to <application>Sendmail</application>, and provides
mobile users who switch hosts the ability to use the same
<acronym>MTA</acronym> without the need to reconfigure their
mail client's settings each time.</para>
<procedure>
<step>
<para>Install <package>security/cyrus-sasl2</package>
from the Ports Collection. This port supports a number of
compile-time options. For the SMTP authentication method
demonstrated in this example, make sure that
<option>LOGIN</option> is not disabled.</para>
</step>
<step>
<para>After installing
<package>security/cyrus-sasl2</package>, edit
<filename>/usr/local/lib/sasl2/Sendmail.conf</filename>,
or create it if it does not exist, and add the following
line:</para>
<programlisting>pwcheck_method: saslauthd</programlisting>
</step>
<step>
<para>Next, install
<package>security/cyrus-sasl2-saslauthd</package> and add
the following line to
<filename>/etc/rc.conf</filename>:</para>
<programlisting>saslauthd_enable="YES"</programlisting>
<para>Finally, start the saslauthd daemon:</para>
<screen>&prompt.root; <userinput>service saslauthd start</userinput></screen>
<para>This daemon serves as a broker for
<application>Sendmail</application> to authenticate against
the &os; &man.passwd.5; database. This saves the trouble of
creating a new set of usernames and passwords for each user
that needs to use <acronym>SMTP</acronym> authentication,
and keeps the login and mail password the same.</para>
</step>
<step>
<para>Next, edit <filename>/etc/make.conf</filename> and add
the following lines:</para>
<programlisting>SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2</programlisting>
<para>These lines provide <application>Sendmail</application>
the proper configuration options for linking to
<package>cyrus-sasl2</package> at compile time. Make sure
that <package>cyrus-sasl2</package> has been installed
before recompiling
<application>Sendmail</application>.</para>
</step>
<step>
<para>Recompile <application>Sendmail</application> by
executing the following commands:</para>
<screen>&prompt.root; <userinput>cd /usr/src/lib/libsmutil</userinput>
&prompt.root; <userinput>make cleandir &amp;&amp; make obj &amp;&amp; make</userinput>
&prompt.root; <userinput>cd /usr/src/lib/libsm</userinput>
&prompt.root; <userinput>make cleandir &amp;&amp; make obj &amp;&amp; make</userinput>
&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail</userinput>
&prompt.root; <userinput>make cleandir &amp;&amp; make obj &amp;&amp; make &amp;&amp; make install</userinput></screen>
<para>This compile should not have any problems if
<filename>/usr/src</filename> has not changed extensively
and the shared libraries it needs are available.</para>
</step>
<step>
<para>After <application>Sendmail</application> has been
compiled and reinstalled, edit
<filename>/etc/mail/freebsd.mc</filename> or the local
<filename>.mc</filename>. Many administrators choose
to use the output from &man.hostname.1; as the name of
<filename>.mc</filename> for uniqueness. Add these
lines:</para>
<programlisting>dnl set SASL options
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl</programlisting>
<para>These options configure the different methods available
to <application>Sendmail</application> for authenticating
users. To use a method other than
<application>pwcheck</application>, refer to the
<application>Sendmail</application> documentation.</para>
</step>
<step>
<para>Finally, run &man.make.1; while in
<filename>/etc/mail</filename>. That will run the new
<filename>.mc</filename> and create a
<filename>.cf</filename> named either
<filename>freebsd.cf</filename> or the name used for the
local <filename>.mc</filename>. Then, run <command>make
install restart</command>, which will copy the file to
<filename>sendmail.cf</filename>, and properly restart
<application>Sendmail</application>. For more information
about this process, refer to
<filename>/etc/mail/Makefile</filename>.</para>
</step>
</procedure>
<para>To test the configuration, use a <acronym>MUA</acronym> to
send a test message. For further investigation, set the
<option>LogLevel</option> of <application>Sendmail</application>
to <literal>13</literal> and watch
<filename>/var/log/maillog</filename> for any errors.</para>
<para>For more information, refer to <link
xlink:href="http://www.sendmail.org/~ca/email/auth.html">
<acronym>SMTP</acronym> authentication</link>.</para>
</sect1>
<sect1 xml:id="mail-agents">
<info>
<title>Mail User Agents</title>
<authorgroup>
<author>
<personname>
<firstname>Marc</firstname>
<surname>Silver</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>Mail User Agents</primary>
</indexterm>
<para>A <acronym>MUA</acronym> is an application that is used to
send and receive email. As email <quote>evolves</quote> and
becomes more complex, <acronym>MUA</acronym>s are becoming
increasingly powerful and provide users increased functionality
and flexibility. The <literal>mail</literal> category of the
&os; Ports Collection contains numerous <acronym>MUA</acronym>s.
These include graphical email clients such as
<application>Evolution</application> or
<application>Balsa</application> and console based clients such
as <application>mutt</application> or
<application>alpine</application>.</para>
<sect2 xml:id="mail-command">
<title><command>mail</command></title>
<para>&man.mail.1; is the default
<acronym>MUA</acronym> installed with &os;. It is a console
based <acronym>MUA</acronym> that offers the basic
functionality required to send and receive text-based email.
It provides limited attachment support and can only access
local mailboxes.</para>
<para>Although <command>mail</command> does not natively support
interaction with <acronym>POP</acronym> or
<acronym>IMAP</acronym> servers, these mailboxes may be
downloaded to a local <filename>mbox</filename> using an
application such as
<application>fetchmail</application>.</para>
<para>In order to send and receive email, run
<command>mail</command>:</para>
<screen>&prompt.user; <userinput>mail</userinput></screen>
<para>The contents of the user's mailbox in
<filename>/var/mail</filename> are automatically read by
<command>mail</command>. Should the mailbox be empty, the
utility exits with a message indicating that no mail could
be found. If mail exists, the application interface starts,
and a list of messages will be displayed. Messages are
automatically numbered, as can be seen in the following
example:</para>
<screen>Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/marcs": 3 messages 3 new
&gt;N 1 root@localhost Mon Mar 8 14:05 14/510 "test"
N 2 root@localhost Mon Mar 8 14:05 14/509 "user account"
N 3 root@localhost Mon Mar 8 14:05 14/509 "sample"</screen>
<para>Messages can now be read by typing <keycap>t</keycap>
followed by the message number. This example reads the first
email:</para>
<screen>&amp; <userinput>t 1</userinput>
Message 1:
From root@localhost Mon Mar 8 14:05:52 2004
X-Original-To: marcs@localhost
Delivered-To: marcs@localhost
To: marcs@localhost
Subject: test
Date: Mon, 8 Mar 2004 14:05:52 +0200 (SAST)
From: root@localhost (Charlie Root)
This is a test message, please reply if you receive it.</screen>
<para>As seen in this example, the message will be displayed
with full headers. To display the list of messages again,
press <keycap>h</keycap>.</para>
<para>If the email requires a reply, press either
<keycap>R</keycap> or <keycap>r</keycap>
<command>mail</command> keys. <keycap>R</keycap> instructs
<command>mail</command> to reply only to the sender of the
email, while <keycap>r</keycap> replies to all other
recipients of the message. These commands can be suffixed
with the mail number of the message to reply to. After typing
the response, the end of the message should be marked by a
single <keycap>.</keycap> on its own line. An example can be
seen below:</para>
<screen>&amp; <userinput>R 1</userinput>
To: root@localhost
Subject: Re: test
<userinput>Thank you, I did get your email.
.</userinput>
EOT</screen>
<para>In order to send a new email, press <keycap>m</keycap>,
followed by the recipient email address. Multiple recipients
may be specified by separating each address with the
<keycap>,</keycap> delimiter. The subject of the message may
then be entered, followed by the message contents. The end of
the message should be specified by putting a single
<keycap>.</keycap> on its own line.</para>
<screen>&amp; <userinput>mail root@localhost</userinput>
Subject: <userinput>I mastered mail
Now I can send and receive email using mail ... :)
.</userinput>
EOT</screen>
<para>While using <command>mail</command>, press
<keycap>?</keycap> to display help at any time. Refer to
&man.mail.1; for more help on how to use
<command>mail</command>.</para>
<note>
<para>&man.mail.1; was not designed to handle attachments and
thus deals with them poorly. Newer <acronym>MUA</acronym>s
handle attachments in a more intelligent way. Users who
prefer to use <command>mail</command> may find the
<package>converters/mpack</package> port to be of
considerable use.</para>
</note>
</sect2>
<sect2 xml:id="mutt-command">
<title><application>mutt</application></title>
<para><application>mutt</application> is a powerful
<acronym>MUA</acronym>, with many features, including:</para>
<itemizedlist>
<listitem>
<para>The ability to thread messages.</para>
</listitem>
<listitem>
<para>PGP support for digital signing and encryption of
email.</para>
</listitem>
<listitem>
<para>MIME support.</para>
</listitem>
<listitem>
<para>Maildir support.</para>
</listitem>
<listitem>
<para>Highly customizable.</para>
</listitem>
</itemizedlist>
<para>Refer to <uri
xlink:href="http://www.mutt.org">http://www.mutt.org</uri>
for more information on
<application>mutt</application>.</para>
<para><application>mutt</application> may be installed using the
<package>mail/mutt</package> port. After the port has been
installed, <application>mutt</application> can be started by
issuing the following command:</para>
<screen>&prompt.user; <userinput>mutt</userinput></screen>
<para><application>mutt</application> will automatically read
and display the contents of the user mailbox in
<filename>/var/mail</filename>. If no mails are found,
<application>mutt</application> will wait for commands from
the user. The example below shows
<application>mutt</application> displaying a list of
messages:</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/mutt1"/>
</imageobject>
</mediaobject>
<para>To read an email, select it using the cursor keys and
press <keycap>Enter</keycap>. An example of
<application>mutt</application> displaying email can be seen
below:</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/mutt2"/>
</imageobject>
</mediaobject>
<para>Similar to &man.mail.1;, <application>mutt</application>
can be used to reply only to the sender of the message as well
as to all recipients. To reply only to the sender of the
email, press <keycap>r</keycap>. To send a group reply
to the original sender as well as all the message recipients,
press <keycap>g</keycap>.</para>
<note>
<para>By default, <application>mutt</application> uses the
&man.vi.1; editor for creating and replying to emails. Each
user can customize this by creating or editing the
<filename>.muttrc</filename> in their home directory and
setting the <literal>editor</literal> variable or by setting
the <envar>EDITOR</envar> environment variable. Refer to
<uri
xlink:href="http://www.mutt.org/">http://www.mutt.org/</uri>
for more information about configuring
<application>mutt</application>.</para>
</note>
<para>To compose a new mail message, press
<keycap>m</keycap>. After a valid subject has been given,
<application>mutt</application> will start &man.vi.1; so the
email can be written. Once the contents of the email are
complete, save and quit from <command>vi</command>.
<application>mutt</application> will resume, displaying a
summary screen of the mail that is to be delivered. In
order to send the mail, press <keycap>y</keycap>. An example
of the summary screen can be seen below:</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/mutt3"/>
</imageobject>
</mediaobject>
<para><application>mutt</application> contains extensive help
which can be accessed from most of the menus by pressing
<keycap>?</keycap>. The top line also displays the keyboard
shortcuts where appropriate.</para>
</sect2>
<sect2 xml:id="alpine-command">
<title><application>alpine</application></title>
<para><application>alpine</application> is aimed at a beginner
user, but also includes some advanced features.</para>
<warning>
<para><application>alpine</application> has had several remote
vulnerabilities discovered in the past, which allowed remote
attackers to execute arbitrary code as users on the local
system, by the action of sending a specially-prepared email.
While <emphasis>known</emphasis> problems have been fixed,
<application>alpine</application> code is written in an
insecure style and the &os; Security Officer believes there
are likely to be other undiscovered vulnerabilities. Users
install <application>alpine</application> at their own
risk.</para>
</warning>
<para>The current version of <application>alpine</application>
may be installed using the <package>mail/alpine</package>
port. Once the port has installed,
<application>alpine</application> can be started by issuing
the following command:</para>
<screen>&prompt.user; <userinput>alpine</userinput></screen>
<para>The first time <application>alpine</application>
runs, it displays a greeting page with a brief introduction,
as well as a request from the
<application>alpine</application> development team to send
an anonymous email message allowing them to judge how many
users are using their client. To send this anonymous message,
press <keycap>Enter</keycap>. Alternatively, press
<keycap>E</keycap> to exit the greeting without sending an
anonymous message. An example of the greeting page is
shown below:</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/pine1"/>
</imageobject>
</mediaobject>
<para>The main menu is then presented, which can be navigated
using the cursor keys. This main menu provides shortcuts for
the composing new mails, browsing mail directories, and
administering address book entries. Below the main menu,
relevant keyboard shortcuts to perform functions specific to
the task at hand are shown.</para>
<para>The default directory opened by
<application>alpine</application> is
<filename>inbox</filename>. To view the message index, press
<keycap>I</keycap>, or select the
<guimenuitem>MESSAGE INDEX</guimenuitem> option shown
below:</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/pine2"/>
</imageobject>
</mediaobject>
<para>The message index shows messages in the current directory
and can be navigated by using the cursor keys. Highlighted
messages can be read by pressing
<keycap>Enter</keycap>.</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/pine3"/>
</imageobject>
</mediaobject>
<para>In the screenshot below, a sample message is displayed by
<application>alpine</application>. Contextual keyboard
shortcuts are displayed at the bottom of the screen. An
example of one of a shortcut is <keycap>r</keycap>, which
tells the <acronym>MUA</acronym> to reply to the current
message being displayed.</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/pine4"/>
</imageobject>
</mediaobject>
<para>Replying to an email in <application>alpine</application>
is done using the <application>pico</application> editor,
which is installed by default with
<application>alpine</application>.
<application>pico</application> makes it easy to navigate the
message and is easier for novice users to use than &man.vi.1;
or &man.mail.1;. Once the reply is complete, the message can
be sent by pressing <keycombo
action="simul"><keycap>Ctrl</keycap><keycap>X</keycap>
</keycombo>. <application>alpine</application> will ask for
confirmation before sending the message.</para>
<mediaobject>
<imageobject>
<imagedata fileref="mail/pine5"/>
</imageobject>
</mediaobject>
<para><application>alpine</application> can be customized using
the <guimenuitem>SETUP</guimenuitem> option from the main
menu. Consult <uri
xlink:href="http://www.washington.edu/alpine/">http://www.washington.edu/alpine/</uri>
for more information.</para>
</sect2>
</sect1>
<sect1 xml:id="mail-fetchmail">
<info>
<title>Using <application>fetchmail</application></title>
<authorgroup>
<author>
<personname>
<firstname>Marc</firstname>
<surname>Silver</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>fetchmail</primary>
</indexterm>
<para><application>fetchmail</application> is a full-featured
<acronym>IMAP</acronym> and <acronym>POP</acronym> client. It
allows users to automatically download mail from remote
<acronym>IMAP</acronym> and <acronym>POP</acronym> servers and
save it into local mailboxes where it can be accessed more
easily. <application>fetchmail</application> can be installed
using the <package>mail/fetchmail</package> port, and offers
various features, including:</para>
<itemizedlist>
<listitem>
<para>Support for the <acronym>POP3</acronym>,
<acronym>APOP</acronym>, <acronym>KPOP</acronym>,
<acronym>IMAP</acronym>, <acronym>ETRN</acronym> and
<acronym>ODMR</acronym> protocols.</para>
</listitem>
<listitem>
<para>Ability to forward mail using <acronym>SMTP</acronym>,
which allows filtering, forwarding, and aliasing to function
normally.</para>
</listitem>
<listitem>
<para>May be run in daemon mode to check periodically for new
messages.</para>
</listitem>
<listitem>
<para>Can retrieve multiple mailboxes and forward them, based
on configuration, to different local users.</para>
</listitem>
</itemizedlist>
<para>This section explains some of the basic features of
<application>fetchmail</application>. This utility requires a
<filename>.fetchmailrc</filename> configuration in the user's
home directory in order to run correctly. This file includes
server information as well as login credentials. Due to the
sensitive nature of the contents of this file, it is advisable
to make it readable only by the user, with the following
command:</para>
<screen>&prompt.user; <userinput>chmod 600 .fetchmailrc</userinput></screen>
<para>The following <filename>.fetchmailrc</filename> serves as an
example for downloading a single user mailbox using
<acronym>POP</acronym>. It tells
<application>fetchmail</application> to connect to
<systemitem class="fqdomainname">example.com</systemitem> using
a username of <systemitem class="username">joesoap</systemitem>
and a password of <literal>XXX</literal>. This example assumes
that the user <systemitem class="username">joesoap</systemitem>
exists on the local system.</para>
<programlisting>poll example.com protocol pop3 username "joesoap" password "XXX"</programlisting>
<para>The next example connects to multiple <acronym>POP</acronym>
and <acronym>IMAP</acronym> servers and redirects to different
local usernames where applicable:</para>
<programlisting>poll example.com proto pop3:
user "joesoap", with password "XXX", is "jsoap" here;
user "andrea", with password "XXXX";
poll example2.net proto imap:
user "john", with password "XXXXX", is "myth" here;</programlisting>
<para><application>fetchmail</application> can be run in daemon
mode by running it with <option>-d</option>, followed by the
interval (in seconds) that <application>fetchmail</application>
should poll servers listed in <filename>.fetchmailrc</filename>.
The following example configures
<application>fetchmail</application> to poll every 600
seconds:</para>
<screen>&prompt.user; <userinput>fetchmail -d 600</userinput></screen>
<para>More information on <application>fetchmail</application> can
be found at <uri
xlink:href="http://www.fetchmail.info/">http://www.fetchmail.info/</uri>.</para>
</sect1>
<sect1 xml:id="mail-procmail">
<info>
<title>Using <application>procmail</application></title>
<authorgroup>
<author>
<personname>
<firstname>Marc</firstname>
<surname>Silver</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>procmail</primary>
</indexterm>
<para><application>procmail</application> is a powerful
application used to filter incoming mail. It allows users to
define <quote>rules</quote> which can be matched to incoming
mails to perform specific functions or to reroute mail to
alternative mailboxes or email addresses.
<application>procmail</application> can be installed using the
<package>mail/procmail</package> port. Once installed, it can
be directly integrated into most <acronym>MTA</acronym>s.
Consult the <acronym>MTA</acronym> documentation for more
information. Alternatively, <application>procmail</application>
can be integrated by adding the following line to a
<filename>.forward</filename> in the home directory of the
user:</para>
<programlisting>"|exec /usr/local/bin/procmail || exit 75"</programlisting>
<para>The following section displays some basic
<application>procmail</application> rules, as well as brief
descriptions of what they do. Rules must be inserted into a
<filename>.procmailrc</filename>, which must reside in the
user's home directory.</para>
<para>The majority of these rules can be found in
&man.procmailex.5;.</para>
<para>To forward all mail from <email>user@example.com</email> to
an external address of <email
role="nolink">goodmail@example2.com</email>:</para>
<programlisting>:0
* ^From.*user@example.com
! goodmail@example2.com</programlisting>
<para>To forward all mails shorter than 1000 bytes to an external
address of <email
role="nolink">goodmail@example2.com</email>:</para>
<programlisting>:0
* &lt; 1000
! goodmail@example2.com</programlisting>
<para>To send all mail sent to
<email>alternate@example.com</email> to a mailbox called
<filename>alternate</filename>:</para>
<programlisting>:0
* ^TOalternate@example.com
alternate</programlisting>
<para>To send all mail with a subject of <quote>Spam</quote> to
<filename>/dev/null</filename>:</para>
<programlisting>:0
^Subject:.*Spam
/dev/null</programlisting>
<para>A useful recipe that parses incoming <systemitem
class="fqdomainname">&os;.org</systemitem> mailing lists and
places each list in its own mailbox:</para>
<programlisting>:0
* ^Sender:.owner-freebsd-\/[^@]+@FreeBSD.ORG
{
LISTNAME=${MATCH}
:0
* LISTNAME??^\/[^@]+
FreeBSD-${MATCH}
}</programlisting>
</sect1>
</chapter>