NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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.
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
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
The Sendmail executable is /usr/sbin/sendmail.
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 22.214.171.124
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
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
add the following line to the virtusertable file:
To finalize the change, the virtusertable.db file must be updated using the
following command as root:
makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable
This creates an updated virtusertable.db file containing the new
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.
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
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
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
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
To do this, add the following lines to /etc/mail/sendmail.mc:
After generating a new sendmail.cf
using m4, this configuration makes all
mail from inside the network appear as if it were sent from
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
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
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"
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
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
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
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.
for detailed LDAP routing configuration instructions and
Next, recreate the /etc/mail/sendmail.cf file by running m4 and restarting Sendmail. Refer to Section 126.96.36.199
Common Sendmail Configuration Changes for
For more information on LDAP, refer to Chapter 13 Lightweight Directory Access Protocol
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
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
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
transport — Maps email addresses
to relay hosts.
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 188.8.131.52
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
/sbin/service postfix restart
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
Uncomment the myhostname line, and
replace host.domain.tld with the
hostname for the machine.
Uncomment the mydestination = $myhostname,
Uncomment the mynetworks line, and
replace 184.108.40.206/28 with a
valid network setting for hosts that can connect to the server.
Uncomment the inet_interfaces = all
Restart the postfix service.
Once these steps are complete, the host accepts outside emails
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
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
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 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"
poll pop.domain.com proto pop3
user 'user1' there with password 'secret' is user1 here
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
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
Each global option should be placed on a single line after a
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
proto <protocol> — Replace
<protocol> with the protocol,
such as pop3 or imap, to use when checking for messages on the
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
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
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
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
--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
-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
More commands and .fetchmailrc options
can be found in the fetchmail man