Product SiteDocumentation Site

Chapter 13. Email

13.1. Email Protocols
13.1.1. Mail Transport Protocols
13.1.2. Mail Access Protocols
13.2. Email Program Classifications
13.2.1. Mail Transport Agent
13.2.2. Mail Delivery Agent
13.2.3. Mail User Agent
13.3. Mail Transport Agents
13.3.1. Sendmail
13.3.2. Postfix
13.3.3. Fetchmail
13.4. Mail Transport Agent (MTA) Configuration
13.5. Mail Delivery Agents
13.5.1. Procmail Configuration
13.5.2. Procmail Recipes
13.6. Mail User Agents
13.6.1. Securing Communication
13.7. Additional Resources
13.7.1. Installed Documentation
13.7.2. Useful Websites
13.7.3. Related Books
Email was born in the 1960s. The mailbox was a file in a user's home directory that was readable only by that user. Primitive mail applications appended new text messages to the bottom of the file, making the user wade through the constantly growing file to find any particular message. This system was only capable of sending messages to users on the same system.
The first network transfer of an electronic mail message file took place in 1971 when a computer engineer named Ray Tomlinson sent a test message between two machines via ARPANET—the precursor to the Internet. Communication via email soon became very popular, comprising 75 percent of ARPANET's traffic in less than two years.
Today, email systems based on standardized network protocols have evolved into some of the most widely used services on the Internet. Fedora offers many advanced applications to serve and access email.
This chapter reviews modern email protocols in use today, and some of the programs designed to send and receive email.

13.1. 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.

13.1.1. 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).

13.1.1.1. 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.

13.1.2. 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).

13.1.2.1. POP

The default POP server under Fedora is /usr/bin/dovecot and is provided by the dovecot package. 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 MDS authentication. An encoded hash of the user's password is sent from the email client to the server rather then sending an unencrypted password.
  • KPOP — POP3 with Kerberos authentication. Refer to for more information.
  • 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 ipop3s service or by using the /usr/sbin/stunnel program. Refer to Section 13.6.1, “Securing Communication” for more information.

13.1.2.2. IMAP

The default IMAP server under Fedora is /usr/bin/dovecot and is provided by the dovecot package. 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 those 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 /usr/sbin/stunnel program. Refer to Section 13.6.1, “Securing Communication” for more information.
Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality. A comprehensive list can be found online at http://en.wikipedia.org/wiki/List_of_mail_servers.

13.1.2.3. 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 dovecot.conf; by default dovecot runs IMAP and POP3 together with their secure versions using SSL. To configure dovecot to use POP:
  1. Edit /etc/dovecot.conf to make sure protocols variable contains pop3. For example:
    protocols = imap imaps pop3 pop3s
    
    
  2. Make that change operational for the current session by running the command:
    /sbin/service dovecot restart
    
    
  3. Make that change operational after the next reboot by running the command:
    chkconfig dovecot on
    
    
    Please note that dovecot only reports that it started the IMAP server, but also starts the POP3 server.
Unlike SMTP, both of these protocols require connecting clients to authenticate using a username and password. By default, passwords for both protocols are passed over the network unencrypted.
To configure SSL on dovecot:
  • Edit the dovecot configuration file /etc/pki/dovecot/dovecot-openssl.conf 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. The certificates are copied in the /etc/pki/dovecot/certs and /etc/pki/dovecot/private directories. To implement the changes, restart dovecot (/sbin/service dovecot restart).
More details on dovecot can be found online at http://www.dovecot.org.