Red Hat Enterprise Linux includes two primary MTAs, Sendmail and Postfix. Sendmail is
configured as the default MTA, although it is easy to switch the default
MTA to Postfix.
Tip
For information about how to switch the default MTA from Sendmail to
Postfix, refer to the chapter called Mail Transport Agent (MTA)
Configuration in the Red Hat Enterprise Linux System Administration Guide.
Sendmail's core purpose, like other MTAs, is to safely transfer email
among hosts, usually using the SMTP protocol. However, Sendmail is
highly configurable, allowing control over almost every aspect of how
email is handled, including the protocol used. Many system
administrators elect to use Sendmail as their MTA due to its power and
scalability.
It is important to be aware of what Sendmail is and what it can do,
as opposed to what it is not. In these days of monolithic
applications that fulfill multiple roles, Sendmail may seem like the
only application needed to run an email server within an
organization. Technically, this is true, as Sendmail can spool mail
to each users' directory and deliver outbound mail for
users. However, most users actually require much more than simple
email delivery. Users usually want to interact with their email using
an MUA, that uses POP or IMAP, to download their messages to their
local machine. Or, they may prefer a Web interface to gain access to
their mailbox. These other applications can work in conjunction with
Sendmail, but they actually exist for different reasons and can
operate separately from one another.
It is beyond the scope of this section to go into all that Sendmail
should or could be configured to do. With literally hundreds of
different options and rule sets, entire volumes have been dedicated
to helping explain everything that can be done and how to fix things
that go wrong. Refer to the Section 11.6 Additional Resources for a list of Sendmail
resources.
This section reviews the files installed with Sendmail by default
and reviews basic configuration changes, including how to stop
unwanted email (spam) and how to extend Sendmail with the
Lightweight Directory Access Protocol (LDAP).
Sendmail's lengthy and detailed configuration file is
/etc/mail/sendmail.cf. Avoid editing the
sendmail.cf file directly. Instead, to make
configuration changes to Sendmail, edit the
/etc/mail/sendmail.mc file, back up the
original /etc/mail/sendmail.cf, and then use
the included m4 macro processor to create a new
/etc/mail/sendmail.cf. More information on
configuring Sendmail can be found in Section 11.3.1.3 Common Sendmail Configuration Changes.
Various Sendmail configuration files are installed in
the /etc/mail/ directory including:
access — Specifies which systems can
use Sendmail for outbound email.
domaintable — Specifies domain name mapping.
local-host-names — Specifies
aliases for the host.
mailertable — Specifies instructions that
override routing for particular domains.
virtusertable — Specifies a
domain-specific form of aliasing, allowing multiple virtual
domains to be hosted on one machine.
Several of the configuration files in /etc/mail/,
such as access, domaintable,
mailertable and
virtusertable, 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 command
makemap hash /etc/mail/<name> < /etc/mail/<name>
where <name> is replaced with the
name of the configuration file to convert.
For example, to have all emails addressed to the
example.com domain delivered to
<[email protected]>, add the following line to the
virtusertable file:
When altering the Sendmail configuration file, it is best not to edit
an existing file, but to generate an entirely new
/etc/mail/sendmail.cf file.
Caution
Before changing the sendmail.cf file, it is a
good idea to create a backup copy.
To add the desired functionality to Sendmail, edit the
/etc/mail/sendmail.mc file as the root user. When
finished, use the m4 macro processor to generate a
new sendmail.cf by executing the following
command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
By default, the m4 macro processor is installed
with Sendmail but is part of the m4
package.
After creating a new /etc/mail/sendmail.cf
file, restart Sendmail for the changes to take effect. The easiest
way to do this is to type the following
command:
/sbin/service sendmail restart
Important
The default sendmail.cf file does not allow
Sendmail to accept network connections from any host other than
the local computer. To configure Sendmail as a server for other
clients, edit the /etc/mail/sendmail.mc file,
and either change the address specified in the
Addr= option of the
DAEMON_OPTIONS directive from
127.0.0.1 to the IP address of an active
network device or comment out the
DAEMON_OPTIONS directive all together by
placing dnl at the beginning of the line. When
finished, regenerate /etc/mail/sendmail.cf by
executing the following command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
The default configuration which ships with Red Hat Enterprise Linux works for most
SMTP-only sites. However, it does not work for UUCP (UNIX to UNIX
Copy) sites. If using UUCP mail transfers, the
/etc/mail/sendmail.mc file must be reconfigured
and a new /etc/mail/sendmail.cf must be
generated.
Consult the /usr/share/sendmail-cf/README file
before editing any files in the directories under the
/usr/share/sendmail-cf directory, as they can
affect the future configuration of
/etc/mail/sendmail.cf files.
One common Sendmail configuration is to have a single machine act as
a mail gateway for all machines on the network. For instance, a
company may want to have a machine called
mail.example.com that handles all of their
email and assigns a consistent return address to all outgoing mail.
In this situation, the Sendmail server must masquerade the machine
names on the company network so that their return address is
[email protected] instead of
[email protected].
To do this, add the following lines to
/etc/mail/sendmail.mc:
Email spam can be defined as unnecessary and unwanted email received
by a user who never requested the communication. It is a disruptive,
costly, and widespread abuse of Internet communication standards.
Sendmail makes it relatively easy to block new spamming techniques
being employed to send junk email. It even blocks many of the more
usual spamming methods by default.
For example, forwarding of SMTP messages, also called relaying, has
been disabled by default since Sendmail version 8.9. Before this
change occurred, Sendmail directed the mail host
(x.edu) to accept messages from one party
(y.com) and sent them to a different party
(z.net). Now, however, Sendmail must be
configured to permit any domain to relay mail through the server. To
configure relay domains, edit the
/etc/mail/relay-domains file and restart
Sendmail.
However, many times users are bombarded with spam from other servers
throughout the Internet. In these instances, Sendmail's access control
features available through the /etc/mail/access
file can be used to prevent connections from unwanted hosts. The
following example illustrates how this file can be used to both block
and specifically allow access to the Sendmail server:
badspammer.com ERROR:550 "Go away and do not spam us anymore"
tux.badspammer.com OK
10.0 RELAY
This example shows that any email sent from
badspammer.com is blocked with a 550 RFC-821
compliant error code, with a message sent back to the spammer. Email
sent from the tux.badspammer.com sub-domain,
is accepted. The last line shows that any email sent
from the 10.0.*.* network can be relayed through the mail server.
Because /etc/mail/access.db is a database, use
makemap to activate any changes. Do this using the
following command as root:
makemap hash /etc/mail/access < /etc/mail/access
This example only represents a small part of what Sendmail can
do in terms of allowing or blocking access. Refer to the
/usr/share/sendmail-cf/README for more
information and examples.
Since Sendmail calls the Procmail MDA when delivering mail, it is also
possible to use a spam filtering program, such as SpamAssassin, to
identify and file spam for users. Refer to Section 11.4.2.6 Spam Filters for
more about using SpamAssassin.
Using the Lightweight Directory Access Protocol
(LDAP) is a very quick and powerful way to find specific
information about a particular user from a much larger group. For
example, an LDAP server can be used to look up a particular email
address from a common corporate directory by the user's last
name. In this kind of implementation, LDAP is largely separate from
Sendmail, with LDAP storing the hierarchical user information and
Sendmail only being given the result of LDAP queries in
pre-addressed email messages.
However, Sendmail supports a much greater integration with LDAP,
where it uses LDAP to replace separately maintained files, such as
aliases and
virtusertables, on different mail servers that
work together to support a medium- to enterprise-level
organization. In short, LDAP abstracts the mail routing level from
Sendmail and its separate configuration files to a powerful LDAP
cluster that can be leveraged by many different applications.
The current version of Sendmail contains support for LDAP. To extend
the Sendmail server using LDAP, first get an LDAP server, such as
OpenLDAP, running and properly
configured. Then edit the /etc/mail/sendmail.mc
to include the following:
This is only for a very basic configuration of Sendmail with
LDAP. The configuration can differ greatly from this depending on
the implementation of LDAP, especially when configuring several
Sendmail machines to use a common LDAP server.
Consult /usr/share/sendmail-cf/README for
detailed LDAP routing configuration instructions and examples.
Originally developed at IBM by security expert and programmer Wietse
Venema, Postfix is a Sendmail-compatible MTA that is designed to be
secure, fast, and easy to configure.
To improve security, Postfix uses a modular design, where small
processes with limited privileges are launched by a
master daemon. The smaller, less privileged
processes perform very specific tasks related to the various stages of
mail delivery and run in a change rooted environment to limit the
effects of attacks.
Configuring Postfix to accept network connections from hosts other
than the local computer takes only a few minor changes in its
configuration file. Yet for those with more complex needs, Postfix
provides a variety of configuration options, as well as third party
add ons that make it a very versatile and full-featured MTA.
The configuration files for Postfix are human readable and support
upward of 250 directives. Unlike Sendmail, no macro processing is
required for changes to take effect and the majority of the most
commonly used options are described in the heavily commented files.
Important
Before using Postfix, the default MTA must be switched from Sendmail
to Postfix. Refer to the chapter called Mail Transport
Agent (MTA) Configuration in the
Red Hat Enterprise Linux System Administration Guide for further details.
The Postfix executable is
/usr/sbin/postfix. This daemon launches all
related processes needed to handle mail delivery.
Postfix stores its configuration files in the
/etc/postfix/ directory. The following is a
list of the more commonly used files:
access — Used for access control,
this file specifies which hosts are allowed to connect to
Postfix.
aliases — A configurable list
required by the mail protocol.
main.cf — The global Postfix
configuration file. The majority of configuration options are
specified in this file.
master.cf — Specifies how Postfix
interacts with various processes to accomplish mail delivery.
transport — Maps email addresses to
relay hosts.
Important
The default /etc/postfix/main.cf file does not allow
Postfix to accept network connections from a host other than the
local computer. For instructions on configuring Postfix as a server for other
clients, refer to Section 11.3.2.2 Basic Postfix Configuration.
When changing some options within files in the
/etc/postfix/ directory, it may be necessary to
restart the postfix service for the changes to
take effect. The easiest way to do this is to type the following
command:
By default, Postfix does not accept network connections from any host
other than the local host. Perform the following steps as root to
enable mail delivery for other hosts on the network:
Edit the /etc/postfix/main.cf
file with a text editor, such as vi.
Uncomment the mydomain line by removing the
hash mark (#), and replace
domain.tld with the domain the mail
server is servicing, such as example.com.
Uncomment the myorigin = $mydomain line.
Uncomment the myhostname line, and replace
host.domain.tld with the hostname for
the machine.
Uncomment the mydestination = $myhostname,
localhost.$mydomain line.
Uncomment the mynetworks line, and replace
168.100.189.0/28 with a valid network
setting for hosts that can connect to the server.
Uncomment the inet_interfaces = all line.
Restart the postfix service.
Once these steps are complete, the host accepts outside emails for
delivery.
Postfix has a large assortment of configuration options. One of the
best ways to learn how to configure Postfix is to read the comments
within /etc/postfix/main.cf. Additional resources
including information about LDAP and SpamAssassin integration are
available online at https://www.postfix.org/.
Fetchmail is an MTA which retrieves email from remote servers and
delivers it to the local MTA. Many users appreciate the ability to
separate the process of downloading their messages located on a remote
server from the process of reading and organizing their email in an
MUA. Designed with the needs of dial-up users in mind, Fetchmail
connects and quickly downloads all of the email messages to the mail
spool file using any number of protocols, including POP3 and IMAP. It
can even forward email messages to an SMTP server, if necessary.
Fetchmail is configured for each user through the use of a
.fetchmailrc file in the user's home directory.
Using preferences in the .fetchmailrc file,
Fetchmail checks for email on a remote server and downloads it. It then
delivers it to port 25 on the local machine, using the local MTA to
place the email in the correct user's spool file. If Procmail is
available, it is launched to filter the email and place it in a mailbox
so that it can be read by an MUA.
Although it is possible to pass all necessary options on the command
line to check for email on a remote server when executing Fetchmail,
using a .fetchmailrc file is much easier. Place
any desired configuration options in the
.fetchmailrc file for those options to be used
each time the fetchmail command is issued. It is
possible to override these at the time Fetchmail is run by specifying
that option on the command line.
A user's .fetchmailrc file contains three classes
of configuration options:
global options — Gives Fetchmail
instructions that control the operation of the program or provide
settings for every connection that checks for email.
server options — Specifies
necessary information about the server being polled, such as the
hostname, as well as preferences for specific email servers, such
as the port to check or number of seconds to wait before timing
out. These options affect every user using that server.
user options — Contains
information, such as username and password, necessary to
authenticate and check for email using a specified email server.
Global options appear at the top of the
.fetchmailrc file, followed by one or more server
options, each of which designate a different email server that
Fetchmail should check. User options follow server options for each
user account checking that email server. Like server options, multiple
user options may be specified for use with a particular server as well
as to check multiple email accounts on the same server.
Server options are called into service in the
.fetchmailrc file by the use of a special option
verb, poll or skip, that
precedes any of the server information. The poll
action tells Fetchmail to use this server option when it is run, which
checks for email using the specified user options. Any server options
after a skip action, however, are not checked
unless this server's hostname is specified when Fetchmail is
invoked. The skip option is useful when testing
configurations in .fetchmailrc because it only
checks skipped servers when specifically invoked, and does not affect
any currently working configurations.
A sample .fetchmailrc file looks similar to the
following example:
set postmaster "user1"
set bouncemail
poll pop.domain.com proto pop3
user 'user1' there with password 'secret' is user1 here
poll mail.domain2.com
user 'user5' there with password 'secret2' is user1 here
user 'user7' there with password 'secret3' is user1 here
In this example, the global options specify that the user is sent
email as a last resort (postmaster option) and all
email errors are sent to the postmaster instead of the sender
(bouncemail option). The set
action tells Fetchmail that this line contains a global option. Then,
two email servers are specified, one set to check using POP3, the
other for trying various protocols to find one that works. Two users
are checked using the second server option, but all email found for
any user is sent to user1's mail spool. This allows
multiple mailboxes to be checked on multiple servers, while appearing
in a single MUA inbox. Each user's specific information begins with
the user action.
Note
Users are not required to place their password in the
.fetchmailrc file. Omitting the with
password '<password>'
section causes Fetchmail to ask for a password when it is launched.
Fetchmail has numerous global, server, and local options. Many of
these options are rarely used or only apply to very specific
situations. The fetchmail man page explains each
option in detail, but the most common ones are listed here.
Each global option should be placed on a single line after a
set action.
daemon
<seconds> —
Specifies daemon-mode, where Fetchmail stays in the
background. Replace <seconds>
with the number of seconds Fetchmail is to wait before polling
the server.
postmaster — Specifies a local user
to send mail to in case of delivery problems.
syslog — Specifies the log file for
errors and status messages. By default, this is
/var/log/maillog.
Server options must be placed on their own line in
.fetchmailrc after a poll or
skip action.
auth
<auth-type> —
Replace <auth-type> with the
type of authentication to be used. By default,
password authentication is used, but some
protocols support other types of authentication, including
kerberos_v5, kerberos_v4,
and ssh. If the any
authentication type is used, Fetchmail first tries methods that
do not require a password, then methods that mask the password,
and finally attempts to send the password unencrypted to
authenticate to the server.
interval
<number> — Polls
the specified server every
<number> of
times that it checks for email on all configured servers. This
option is generally used for email servers where the user rarely
receives messages.
port
<port-number> —
Replace <port-number> with the
port number. This value overrides the default port number for
the specified protocol.
proto
<protocol> —
Replace <protocol> with the
protocol, such as pop3 or
imap, to use when checking for messages on
the server.
timeout
<seconds> —
Replace <seconds> with the
number of seconds of server inactivity after which Fetchmail
gives up on a connection attempt. If this value is not set, a
default of 300 seconds is assumed.
User options may be placed on their own lines beneath a server
option or on the same line as the server option. In either case, the
defined options must follow the user option
(defined below).
fetchall — Orders Fetchmail to download
all messages in the queue, including messages that have already
been viewed. By default, Fetchmail only pulls down new messages.
fetchlimit
<number> —
Replace <number> with the
number of messages to be retrieved before stopping.
flush — Deletes all previously
viewed messages in the queue before retrieving new messages.
limit
<max-number-bytes>
— Replace
<max-number-bytes> with the
maximum size in bytes that messages are allowed to be when
retrieved by Fetchmail. This option is useful with slow network
links, when a large message takes too long to download.
password
'<password>' —
Replace <password> with the
user's password.
preconnect
"<command>" —
Replace <command> with a
command to be executed before retrieving messages for the user.
postconnect
"<command>" —
Replace <command> with a
command to be executed after retrieving messages for the user.
ssl — Activates SSL encryption.
user
"<username>" —
Replace <username> with the
username used by Fetchmail to retrieve messages. This option
must precede all other user options.
Most Fetchmail options used on the command line when executing the
fetchmail command mirror the
.fetchmailrc configuration options. In this way,
Fetchmail may be used with or without a configuration file. These
options are not used on the command line by most users because it is
easier to leave them in the .fetchmailrc file.
There may be times when it is desirable to run the
fetchmail command with other options for a
particular purpose. It is possible to issue command options to
temporarily override a .fetchmailrc setting that
is causing an error, as any options specified at the command line
override configuration file options.
Certain options used after the fetchmail command
can supply important information.
--configdump — Displays every possible
option based on information from
.fetchmailrc and Fetchmail defaults. No
email is retrieved for any users when using this option.
-s — Executes Fetchmail in silent mode,
preventing any messages, other than errors, from appearing after
the fetchmail command.
-v — Executes Fetchmail in verbose
mode, displaying every communication between Fetchmail and
remote email servers.
-V — Displays detailed version
information, lists its global options, and shows settings to be
used with each user, including the email protocol and
authentication method. No email is retrieved for any users when
using this option.
These options are occasionally useful for overriding defaults often
found in the .fetchmailrc file.
-a — Fetchmail downloads all
messages from the remote email server, whether new or previously
viewed. By default, Fetchmail only downloads new messages.
-k — Fetchmail leaves the
messages on the remote email server after downloading them. This
option overrides the default behavior of deleting messages after
downloading them.
-l
<max-number-bytes>
— Fetchmail does not download any messages over a
particular size and leaves them on the remote email server.
--quit — Quits the Fetchmail daemon
process.
More commands and .fetchmailrc options can be
found in the fetchmail man page.
