Documentation for a newer release is available. View Latest

Mail Servers

Fedora offers many advanced applications to serve and access email. This chapter describes modern email protocols in use today, and some of the programs designed to send and receive email.

Email Protocols

Today, email is delivered using a client/server architecture. An email message is created using a mail client program. This program then sends the message to a server. The server then forwards the message to the recipient’s email server, where the message is then supplied to the recipient’s email client.

To enable this process, a variety of standard network protocols allow different machines, often running different operating systems and using different email programs, to send and receive email.

The following protocols discussed are the most commonly used in the transfer of email.

Mail Transport Protocols

Mail delivery from a client application to the server, and from an originating server to the destination server, is handled by the Simple Mail Transfer Protocol (SMTP).

SMTP

The primary purpose of SMTP is to transfer email between mail servers. However, it is critical for email clients as well. To send email, the client sends the message to an outgoing mail server, which in turn contacts the destination mail server for delivery. For this reason, it is necessary to specify an SMTP server when configuring an email client.

Under Fedora, a user can configure an SMTP server on the local machine to handle mail delivery. However, it is also possible to configure remote SMTP servers for outgoing mail.

One important point to make about the SMTP protocol is that it does not require authentication. This allows anyone on the Internet to send email to anyone else or even to large groups of people. It is this characteristic of SMTP that makes junk email or spam possible. Imposing relay restrictions limits random users on the Internet from sending email through your SMTP server, to other servers on the internet. Servers that do not impose such restrictions are called open relay servers.

Fedora provides the Postfix and Sendmail SMTP programs.

Mail Access Protocols

There are two primary protocols used by email client applications to retrieve email from mail servers: the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP).

POP

The default POP server under Fedora is Dovecot and is provided by the dovecot package.

Installing the dovecot package

In order to use Dovecot, first ensure the dovecot package is installed on your system by running, as root:

~]# dnf install dovecot

For more information on installing packages with DNF, see Installing Packages.

When using a POP server, email messages are downloaded by email client applications. By default, most POP email clients are automatically configured to delete the message on the email server after it has been successfully transferred, however this setting usually can be changed.

POP is fully compatible with important Internet messaging standards, such as Multipurpose Internet Mail Extensions (MIME), which allow for email attachments.

POP works best for users who have one system on which to read email. It also works well for users who do not have a persistent connection to the Internet or the network containing the mail server. Unfortunately for those with slow network connections, POP requires client programs upon authentication to download the entire content of each message. This can take a long time if any messages have large attachments.

The most current version of the standard POP protocol is POP3.

There are, however, a variety of lesser-used POP protocol variants:

APOP — POP3 with MD5 authentication. An encoded hash of the user’s password is sent from the email client to the server rather than sending an unencrypted password.
KPOP — POP3 with Kerberos authentication.
RPOP — POP3 with RPOP authentication. This uses a per-user ID, similar to a password, to authenticate POP requests. However, this ID is not encrypted, so RPOP is no more secure than standard POP.

For added security, it is possible to use Secure Socket Layer (SSL) encryption for client authentication and data transfer sessions. This can be enabled by using the pop3s service, or by using the stunnel application. For more information on securing email communication, see Securing Communication.

IMAP

The default IMAP server under Fedora is Dovecot and is provided by the dovecot package. See POP for information on how to install Dovecot.

When using an IMAP mail server, email messages remain on the server where users can read or delete them. IMAP also allows client applications to create, rename, or delete mail directories on the server to organize and store email.

IMAP is particularly useful for users who access their email using multiple machines. The protocol is also convenient for users connecting to the mail server via a slow connection, because only the email header information is downloaded for messages until opened, saving bandwidth. The user also has the ability to delete messages without viewing or downloading them.

For convenience, IMAP client applications are capable of caching copies of messages locally, so the user can browse previously read messages when not directly connected to the IMAP server.

IMAP, like POP, is fully compatible with important Internet messaging standards, such as MIME, which allow for email attachments.

For added security, it is possible to use SSL encryption for client authentication and data transfer sessions. This can be enabled by using the imaps service, or by using the stunnel program. For more information on securing email communication, see Securing Communication.

Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality.

Dovecot

The imap-login and pop3-login processes which implement the IMAP and POP3 protocols are spawned by the master dovecot daemon included in the dovecot package. The use of IMAP and POP is configured through the /etc/dovecot/dovecot.conf configuration file; by default dovecot runs IMAP and POP3 together with their secure versions using SSL. To configure dovecot to use POP, complete the following steps:

Edit the /etc/dovecot/dovecot.conf configuration file to make sure the protocols variable is uncommented (remove the hash sign (#) at the beginning of the line) and contains the pop3 argument. For example:
```
protocols = imap pop3 lmtp
```
When the protocols variable is left commented out, dovecot will use the default values as described above.
Make the change operational for the current session by running the following command as root:
```
~]# systemctl restart dovecot
```
Make the change operational after the next reboot by running the command:
```
~]# systemctl enable dovecot
ln -s '/usr/lib/systemd/system/dovecot' '/etc/systemd/system/multi-user.target.wants/dovecot'
```
The dovecot service starts the POP3 server

Please note that dovecot only reports that it started the IMAP server, but also starts the POP3 server.

Unlike SMTP, both IMAP and POP3 require connecting clients to authenticate using a user name and password. By default, passwords for both protocols are passed over the network unencrypted.

To configure SSL on dovecot:

Edit the /etc/pki/dovecot/dovecot-openssl.cnf configuration file as you prefer. However, in a typical installation, this file does not require modification.
Rename, move or delete the files /etc/pki/dovecot/certs/dovecot.pem and /etc/pki/dovecot/private/dovecot.pem.
Execute the /usr/libexec/dovecot/mkcert.sh script which creates the dovecot self signed certificates. These certificates are copied in the /etc/pki/dovecot/certs and /etc/pki/dovecot/private directories. To implement the changes, restart dovecot by issuing the following command as root:
```
~]# systemctl restart dovecot
```

More details on dovecot can be found online at https://www.dovecot.org.

Email Program Classifications

In general, all email applications fall into at least one of three classifications. Each classification plays a specific role in the process of moving and managing email messages. While most users are only aware of the specific email program they use to receive and send messages, each one is important for ensuring that email arrives at the correct destination.

Mail Transport Agent

A Mail Transport Agent (MTA) transports email messages between hosts using SMTP. A message may involve several MTAs as it moves to its intended destination.

While the delivery of messages between machines may seem rather straightforward, the entire process of deciding if a particular MTA can or should accept a message for delivery is quite complicated. In addition, due to problems from spam, use of a particular MTA is usually restricted by the MTA’s configuration or the access configuration for the network on which the MTA resides.

Many modern email client programs can act as an MTA when sending email. However, this action should not be confused with the role of a true MTA. The sole reason email client programs are capable of sending email like an MTA is because the host running the application does not have its own MTA. This is particularly true for email client programs on non-UNIX-based operating systems. However, these client programs only send outbound messages to an MTA they are authorized to use and do not directly deliver the message to the intended recipient’s email server.

Since Fedora offers two MTAs, Postfix and Sendmail, email client programs are often not required to act as an MTA. Fedora also includes a special purpose MTA called Fetchmail.

For more information on Postfix, Sendmail, and Fetchmail, see Mail Transport Agents.

Mail Delivery Agent

A Mail Delivery Agent (MDA) is invoked by the MTA to file incoming email in the proper user’s mailbox. In many cases, the MDA is actually a Local Delivery Agent (LDA), such as mail or Procmail.

Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can fill the role of an MDA when they append new email messages to a local user’s mail spool file. In general, MDAs do not transport messages between systems nor do they provide a user interface; MDAs distribute and sort messages on the local machine for an email client application to access.

Mail User Agent

A Mail User Agent (MUA) is synonymous with an email client application. An MUA is a program that, at a minimum, allows a user to read and compose email messages. Many MUAs are capable of retrieving messages via the POP or IMAP protocols, setting up mailboxes to store messages, and sending outbound messages to an MTA.

MUAs may be graphical, such as Evolution, or have simple text-based interfaces, such as Mutt.

Mail Transport Agents

Fedora offers two primary MTAs: Postfix and Sendmail. Postfix is configured as the default MTA and Sendmail is considered deprecated. If required to switch the default MTA to Sendmail, you can either uninstall Postfix or use the following command as root to switch to Sendmail:

~]# alternatives --config mta

You can also use the following command to enable the desired service:

~]# systemctl enable service

Similarly, to disable the service, type the following at a shell prompt:

~]# systemctl disable service

For more information on how to manage system services in Fedora 39, see Services and Daemons.

Postfix

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 changed root 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.

The Default Postfix Installation

The Postfix executable is 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.
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.

The aliases file can be found in the /etc/ directory. This file is shared between Postfix and Sendmail. It is a configurable list required by the mail protocol that describes user ID aliases.

Configuring Postfix as a server for other clients

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, see Basic Postfix Configuration.

Restart the postfix service after changing any options in the configuration files under the /etc/postfix directory in order for those changes to take effect. To do so, run the following command as root:

~]# systemctl restart postfix

Basic Postfix Configuration

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 sign (#), 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 host name 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.
Comment the inet_interfaces = localhost 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 the /etc/postfix/main.cf configuration file. Additional resources including information about Postfix configuration, SpamAssassin integration, or detailed descriptions of the /etc/postfix/main.cf parameters are available online at http://www.postfix.org/.

Using Postfix with LDAP

Postfix can use an LDAP directory as a source for various lookup tables (e.g.: aliases, virtual, canonical, etc.). This allows LDAP to store hierarchical user information and Postfix to only be given the result of LDAP queries when needed. By not storing this information locally, administrators can easily maintain it.

The /etc/aliases lookup example

The following is a basic example for using LDAP to look up the /etc/aliases file. Make sure your /etc/postfix/main.cf file contains the following:

alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf

Create a /etc/postfix/ldap-aliases.cf file if you do not have one already and make sure it contains the following:

server_host = ldap.example.com
search_base = dc=example, dc=com

where ldap.example.com, example, and com are parameters that need to be replaced with specification of an existing available LDAP server.

The /etc/postfix/ldap-aliases.cf file

The /etc/postfix/ldap-aliases.cf file can specify various parameters, including parameters that enable LDAP SSL and STARTTLS. For more information, see the ldap_table(5) man page.

For more information on LDAP, see OpenLDAP.

Sendmail

Sendmail’s core purpose, like other MTAs, is to safely transfer email among hosts, usually using the SMTP protocol. Note that Sendmail is considered deprecated and users are encouraged to use Postfix when possible. See Postfix for more information.

Purpose and Limitations

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. See the 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).

The Default Sendmail Installation

In order to use Sendmail, first ensure the sendmail package is installed on your system by running, as root:

~]# dnf install sendmail

In order to configure Sendmail, ensure the sendmail-cf package is installed on your system by running, as root:

~]# dnf install sendmail-cf

For more information on installing packages with DNF, see Installing Packages.

Before using Sendmail, the default MTA has to be switched from Postfix. For more information how to switch the default MTA refer to Mail Transport Agents.

The Sendmail executable is sendmail.

Sendmail’s lengthy and detailed configuration file is /etc/mail/sendmail.cf. Avoid editing the sendmail.cf file directly. To make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf file, and use the following alternatives to generate a new configuration file:

Use the included makefile in /etc/mail/ to create a new /etc/mail/sendmail.cf configuration file:
```
~]# make all -C /etc/mail/
```
All other generated files in /etc/mail (db files) will be regenerated if needed. The old makemap commands are still usable. The make command is automatically used whenever you start or restart the sendmail service.

More information on configuring Sendmail can be found in 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 the /etc/mail/ directory, 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 following commands, as root:

~]# cd /etc/mail/
~]# make all

This will update virtusertable.db, access.db, domaintable.db, mailertable.db, sendmail.cf, and submit.cf.

To update all the database files listed above and to update a custom database file, use a command in the following format:

make name.db all

where name represents the name of the custom database file to be updated.

To update a single database, use a command in the following format:

make name.db

where name.db represents the name of the database file to be updated.

You may also restart the sendmail service for the changes to take effect by running:

~]# systemctl restart sendmail

For example, to have all emails addressed to the example.com domain delivered to bob@other-example.com, add the following line to the virtusertable file:

@example.com bob@other-example.com

To finalize the change, the virtusertable.db file must be updated:

~]# make virtusertable.db all

Using the all option will result in the virtusertable.db and access.db being updated at the same time.

Common Sendmail Configuration Changes

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.

Backup the sendmail.cf file before changing its content

Before replacing or making any changes to the sendmail.cf file, create a backup copy.

To add the desired functionality to Sendmail, edit the /etc/mail/sendmail.mc file as root. Once you are finished, restart the sendmail service and, if the m4 package is installed, the m4 macro processor will automatically generate a new sendmail.cf configuration file:

~]# systemctl restart sendmail

Configuring Sendmail as a server for other clients

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 restarting the service:

~]# systemctl restart sendmail

The default configuration in Fedora works for most SMTP-only sites. However, it does not work for UUCP (UNIX-to-UNIX Copy Protocol) sites. If using UUCP mail transfers, the /etc/mail/sendmail.mc file must be reconfigured and a new /etc/mail/sendmail.cf file 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 the /etc/mail/sendmail.cf file.

Masquerading

One common Sendmail configuration is to have a single machine act as a mail gateway for all machines on the network. For example, 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 user@example.com instead of user@host.example.com.

To do this, add the following lines to /etc/mail/sendmail.mc:

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`allmasquerade')dnl
MASQUERADE_AS(`example.com.')dnl
MASQUERADE_DOMAIN(`example.com.')dnl
MASQUERADE_AS(example.com)dnl

After generating a new sendmail.cf file using the m4 macro processor, this configuration makes all mail from inside the network appear as if it were sent from example.com.

Stopping Spam

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 relati