Excerpt from Practical Guide to Ubuntu Linux (Versions 8.10 and 8.04), A, 2nd Edition.

 in
Cover image

By Mark G. Sobell
Published by Prentice Hall
ISBN-10: 0-13-700388-9
ISBN-13: 978-0-13-700388-4

Chapter 20: exim4: Setting Up Mail Servers, Clients, and More

Introduction to exim4

When the network that was to evolve into the Internet was first set up, it connected a few computers, each serving a large number of users and running several services. Each computer was capable of sending and receiving email and had a unique hostname, which was used as a destination for email.

Today the Internet has a large number of transient clients. Because these clients do not have fixed IP addresses or hostnames, they cannot receive email directly. Users on these systems usually maintain an account on an email server run by their employer or an ISP, and they collect email from this account using POP or IMAP. Unless you own a domain where you want to receive email, you will not need to set up exim4 to receive mail from nonlocal systems.

Smarthost

You can set up exim4 on a client system so it sends mail bound for nonlocal systems to an SMTP server that relays the mail to its destination. This type of server is called a smarthost. Such a configuration is required by organizations that use firewalls to prevent email from being sent out on the Internet from any system other than the company’s official mail servers. As a partial defense against spreading viruses, some ISPs block outbound port 25 to prevent their customers from sending email directly to a remote computer. This configuration is required by these ISPs.

You can also set up exim4 as a server that sends mail to nonlocal systems and does not use an ISP as a relay. In this configuration, exim4 connects directly to the SMTP servers for the domains receiving the email. An ISP set up as a smarthost is configured this way.

You can set up exim4 to accept email for a registered domain name as specified in the domain’s DNS MX record. However, most mail clients (MUAs) do not interact directly with exim4 to receive email. Instead, they use POP or IMAP— protocols that include features for managing mail folders, leaving messages on the server, and reading only the subject of an email without downloading the entire message. If you want to collect your email from a system other than the one running the incoming mail server, you may need to set up a POP or IMAP server, as discussed.

Setting Up a Mail Server (exim4)

This section explains how to set up an exim4 mail server.

Prerequisites

Install the following packages:

  • exim4 (a virtual package)

  • eximon4 (optional; monitors exim4)

  • mailx (optional; installs mail, which is handy for testing exim4 from the command line)

  • exim4-doc-html (optional; exim4 documentation in HTML format)

  • exim4-doc-info (optional; exim4 documentation in info format)

exim4 init script

When you install the exim4 package, the dpkg postinst script minimally configures exim4 and starts the exim4 daemon. After you configure exim4, call the exim4 init script to restart exim4:

$ sudo /etc/init.d/exim4 restart

After changing the exim4 configuration on an active server, use reload in place of restart to reload exim4 configuration files without interrupting the work exim4 is doing. The exim4 init script accepts several nonstandard arguments:

$ /etc/init.d/exim4
Usage: /etc/init.d/exim4 {start|stop|restart|reload|status|what|force-stop}

The status and what arguments display information about exim4. The force-stop argument immediately kills all exim4 processes.

Notes

Firewall

An SMTP server normally uses TCP port 25. If an SMTP server system that receives nonlocal mail is running a firewall, you need to open this port. To do so, use firestarter (o set a policy that allows SMTP service.

Log files

You must be a member of the adm group or work with root privileges to view the log files in /var/log/exim4.

sendmail and exim4

Although it does not work the same way sendmail does, Ubuntu configures exim4 as a drop-in replacement for sendmail. The exim4-daemon-light package, which is part of the exim4 virtual package, includes /usr/sbin/sendmail, which is a link to exim4. Because the exim4 daemon accepts many of sendmail’s options, programs that depend on sendmail will work with exim4 installed in place of sendmail.

Local and nonlocal systems

The exim4 daemon sends and receives email. A piece of email that exim4 receives can originate on a local system or on a nonlocal system. Similarly, email that exim4 sends can be destined for a local or a nonlocal system. The exim4 daemon processes each piece of email based on its origin and destination.

The local system versus local systems

The local system is the one exim4 is running on. Local systems are systems that are on the same LAN as the local system.

As it is installed, exim4 delivers mail to the local system only.

JumpStart I: Configuring exim4 to Use a Smarthost

This JumpStart configures an exim4 server that sends mail from users on local systems to local and nonlocal destinations and does not accept mail from nonlocal systems. This server

  • Accepts email originating on local systems for delivery to local systems.

  • Accepts email originating on local systems for delivery to nonlocal systems, delivering it using an SMTP server (a smarthost)—typically an ISP—to relay email to its destination.

  • Does not deliver email originating on nonlocal systems. As is frequently the case, you need to use POP or IMAP to receive email.

  • Does not forward email originating on nonlocal systems to other nonlocal systems (does not relay email).

To set up this server, you need to change the values of a few configuration variables in /etc/exim4/update-exim4.conf.conf and restart exim4. The dpkg-reconfigure utility guides you in editing this file; this JumpStart uses a text editor. Working with root privileges, use a text editor to make the following changes to update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
smarthost='mail.example.net'

Configuration type

Set the dc_eximconfig_configtype configuration variable to smarthost to cause exim4 to send mail bound for nonlocal systems to the system that the smarthost configuration variable specifies. This line should appear exactly as shown in the preceding example.

Smarthost

With dc_eximconfig_configtype set to smarthost, set smarthost to the FQDN or IP address (preferred) of the remote SMTP server (the smarthost) that exim4 uses to relay email to nonlocal systems. Replace mail.example.net with this FQDN or IP address. For Boolean variables in update-exim4.conf.conf, exim4 interprets the null value (specified by ' ') as a value of false. With these changes, the file should look similar to this:

$ cat /etc/exim4/update-exim4.conf.conf
...
dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='mail.example.net'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

The exim4 server does not use the value of the dc_local_interfaces variable in a smarthost configuration, so you can leave it blank. However, in other configurations, the value of 127.0.0.1 prevents exim4 from accepting email from nonlocal systems. It is a good idea to configure exim4 this way and change this variable only when you are ready to accept mail from other systems.

To minimize network accesses for DNS lookups, which can be helpful if you are using a dial-up line, change the value of the dc_minimaldns configuration variable to true.

/etc/mailname

The /etc/mailname file initially holds the node name (uname –n) of the server. The string stored in /etc/mailname appears as the name of the sending system on the envelope-from and From lines of email that originates on the local system. If you want email to appear to come from a different system, change the contents of this file. You can modify this file using a text editor; the dpkg-reconfigure utility can also change it.

The following file causes mail sent from the local system to appear to come from username@example.com, where username is the username of the user who is sending the email:

$ cat /etc/mailname
example.com

See page 688 for more information on exim4 configuration variables. After making these changes, restart exim4.

Test

Test exim4 with the following command:

$ echo "my exim4 test" | exim4 user@remote.host

Replace user@remote.host with an email address on another system where you receive email. You need to send email to a remote system to make sure that exim4 is sending email to the remote SMTP server (the smarthost). If the mail is not delivered, check the email of the user who sent the email (on the local system) for errors. Also check the log file(s) in the /var/log/exim4 directory.

JumpStart II: Configuring exim4 to Send and Receive Mail

To receive email sent from a nonlocal system to a registered domain (that you control), you need to configure exim4 to accept email from nonlocal systems. This JumpStart describes how to set up a server that

  • Accepts email from local and nonlocal systems.

  • Delivers email that originates on local systems to a local system or directly to a nonlocal system, without using a relay.

  • Delivers email that originates on nonlocal systems to a local system only.

  • Does not forward email originating on nonlocal systems to other nonlocal systems (does not relay email).

This server does not relay email originating on nonlocal systems. (You must set the dc_relay_domains variable for the local system to act as a relay.) For this configuration to work, you must be able to make outbound connections and receive inbound connections on port 25 (see “Firewall” ).

Working with root privileges, use a text editor to set the following configuration variables in /etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='internet'
dc_other_hostnames='mydom.example.com'
dc_local_interfaces=''

Configuration type

Set dc_eximconfig_configtype to internet to cause exim4 to send mail directly to nonlocal systems as specified by the DNS MX record for the domain the mail is addressed to and to accept email on the interfaces specified by dc_local_interfaces (next page). This line should appear exactly as shown above.

Other hostnames

The dc_other_hostnames configuration variable specifies the FQDNs or IP addresses that the local server receives mail addressed to. Replace mydom.example.com with these FQDN or IP addresses. You must separate multiple entries with semicolons. These values do not necessarily include the FQDN or the IP address of the local server.

Local interfaces

Set dc_local_interfaces to the interface you want exim4 to listen on. Set it to the null value (' ') to listen on all interfaces.

As in JumpStart I, you may need to change the value of /etc/mailname. For Boolean variables in this file, exim4 interprets the null value (specified by ' ') as false. The file should look similar to this:

$ cat /etc/exim4/update-exim4.conf.conf
...
dc_eximconfig_configtype='internet'
dc_other_hostnames='mydom.example.com'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

See page 688 for more information on exim4 configuration variables. Once you have restarted exim4, it will accept mail addressed to the local system. To receive email addressed to a domain, the DNS MX record (page 790) for that domain must point to the IP address of the local system. If you are not running a DNS server, you must ask your ISP to set up an MX record or else receive mail at the IP address of the server. If you receive email addressed to an IP address, set dc_other_hostnames to that IP address.

Working with exim4 Messages

When exim4 receives email, from both local and nonlocal systems, it creates in the /var/spool/exim4/input directory two files that hold the message while exim4 processes it. To identify a particular message, exim4 generates a 16-character message ID and uses that string in filenames pertaining to the email. The exim4 daemon stores the body of the message in a file named by the message ID followed by –D (data). It stores the headers and envelope information in a file named by the message ID followed by –H (header).

Frozen messages

If exim4 cannot deliver a message, it marks the message as frozen and makes no further attempt to deliver it. Once it has successfully delivered an email, exim4 removes all files pertaining to that email from /var/spool/exim4/input.

Mail addressed to the local system

By default, exim4 delivers email addressed to the local system to users’ files in the mail spool directory, /var/mail, in mbox format. Within this directory, each user has a mail file named with the user’s username. Mail remains in these files until it is collected, typically by an MUA. Once an MUA collects the mail from the mail spool, the MUA stores the mail as directed by the user, usually in the user’s home directory.

Mail addressed to nonlocal systems

The scheme that exim4 uses to process email addressed to a nonlocal system depends on how it is configured: It can send the email to a smarthost, it can send the email to the system pointed to by the DNS MX record of the domain the email is addressed to, or it can refuse to send the email.

mbox versus maildir

The mbox format holds all messages for a user in a single file. To prevent corruption, a process must lock this file while it is adding messages to or deleting messages from the file; thus the MUA cannot delete a message at the same time the MTA is adding messages. A competing format, maildir, holds each message in a separate file. This format does not use locks, allowing an MUA to delete messages from a user at the same time as mail is delivered to the same user. In addition, the maildir format is better able to handle larger mailboxes. The downside is that the maildir format adds overhead when you are using a protocol such as IMAP to check messages. The exim4 daemon supports both mbox and maildir formats (see dc_localdelivery). Qmail, an alternative to sendmail and exim4, uses maildir-format mailboxes.

Mail Logs

By default, exim4 sends normal log messages to /var/exim4/mainlog, with other messages going to other files in the same directory. The following lines in a mainlog file describe an email message sent directly to a remote system’s SMTP server. The exim4 daemon writes one line each time it receives a message and one line each time it attempts to deliver a message. The Completed line indicates that exim4 has completed its part in delivering the message. Each line starts with the date and time of the entry followed by the message ID.

$ tail -3 /var/log/exim4/mainlog
2007-07-19 23:13:12 1IBljk-0000t8-1Z <= zachs@example.com U=sam P=local S=304
2007-07-19 23:13:17 1IBljk-0000t8-1Z => zachs@example.com R=dnslookup T=remote_smtp
  H=filter.mx.meer.net  [64.13.141.12]
2007-07-19 23:13:17 1IBljk-0000t8-1Z Completed

The next entry on each line except the Completed line is a two-character status flag that tells you which kind of event the line describes:

<=

Received a message

=>

Delivered a message normally

–>

Delivered a message normally to an additional address (same delivery)

*>

Did not deliver because of a –N command-line option

**

Did not deliver because the address bounced

= =

Did not deliver because of a temporary problem

Information following the flag is preceded by one of the following letters, which indicates the type of the information, and an equal sign:

H

Name of remote system (host)

U

Username of the user who sent the message

P

Protocol used to receive the message

R

Router used to process the message

T

Transport used to process the message

S

Size of the message in bytes

The first line in the preceding example indicates that exim4 received a 304-byte message to be delivered to zachs@example.com from sam on the local system. The next line indicates that exim4 looked up the address using DNS (dnslookup) and delivered it to the remote SMTP server (remote_smtp) at filter.mx.meer.net, which has an IP address of 64.13.141.12.

The following log entries describe a message that exim4 received from a remote system and delivered to the local system:

2007-07-19 23:13:32 1IBlk4-0000tL-8L <= zachs@gmail.com H=wx-out-0506.google.com
  [66.249.82.229]  P=esmtp S=1913 id=7154255d0707192313y304a1b27t39f...@mail.gmail.com
2007-07-19 23:13:32 1IBlk4-0000tL-8L => sam <sams@example.com> R=local_user T=mail_spool
2007-07-19 23:13:32 1IBlk4-0000tL-8L Completed

See the exim4 specification for more information on log files. If you send and receive a lot of email, the mail logs can grow quite large. The logrotate exim4-base file archives and rotates these files regularly.

Working with Messages

You can call exim4 with many different options to work with mail that is on the system and to generate records of mail that has passed through the system. Most of these options begin with –M and require the message ID (see the preceding section) of the piece of email you want to work with. The following command removes a message from the queue:

$ sudo exim4 -Mrm 1IEKKj-0006CQ-LM
Message 1IEKKj-0006CQ-LM has been removed

Following are some of the exim4 options you can use to work with a message. Each of these options must be followed by a message ID. See the exim4 man page for a complete list.

–Mf

Mark message as frozen

–Mrm

Remove message

–Mt

Thaw message

–Mvb

Display message body

–Mvh

Display message header

Aliases and Forwarding

You can use the aliases and .forward files to forward email.

/etc/aliases

Most of the time when you send email, it goes to a specific person; the recipient, user@system, maps to a real user on the specified system. Sometimes, however, you may want email to go to a class of users and not to a specific recipient. Examples of classes of users include postmaster, webmaster, root, and tech_support. Different users may receive this email at different times or the email may go to a group of users. You can use the /etc/aliases file to map local addresses and classes to local users, files, commands, and local as well as to nonlocal addresses.

Each line in /etc/aliases contains the name of a local (pseudo)user, followed by a colon, whitespace, and a comma-separated list of destinations. Because email sent to the root account is rarely checked, the default installation includes an entry similar to the following that redirects email sent to root to the initial user:

root:		sam

You can set up an alias to forward email to more than one user. The following line forwards mail sent to abuse on the local system to sam and max:

abuse:		sam, max

You can create simple mailing lists with this type of alias. For example, the following alias sends copies of all email sent to admin on the local system to several users, including Zach, who is on a different system:

admin:		sam, helen, max, zach@example.com

You can direct email to a file by specifying an absolute pathname in place of a destination address. The following alias, which is quite popular among less conscientious system administrators, redirects email sent to complaints to /dev/null, where it disappears:

complaints:				/dev/null

You can also send email to standard input of a command by preceding the command with the pipe character (|). This technique is commonly used by mailing list software such as Mailman. For each list it maintains, Mailman has entries, such as the following one for painting_class, in the aliases file:

painting_class:   "|/var/lib/mailman/mail/mailman post painting_class"

See the exim4_files man page for information on exim4 files, including aliases.

newaliases

After you edit /etc/aliases, you must run newaliases while you are working with root privileges. The /usr/bin/newaliases file is a symbolic link to exim4. Running newaliases calls exim4, which rebuilds the exim4 alias database.

~/.forward

Systemwide aliases are useful in many cases, but nonroot users cannot make or change them. Sometimes you may want to forward your own mail: Maybe you want mail from several systems to go to one address or perhaps you want to forward your mail while you are working at another office. The ~/.forward file allows ordinary users to forward their email.

Lines in a .forward file are the same as the right column of the aliases file explained earlier in this section: Destinations are listed one per line and can be a local user, a remote email address, a filename, or a command preceded by the pipe character (|).

Mail that you forward does not go to your local mailbox. If you want to forward mail and keep a copy in your local mailbox, you must specify your local username preceded by a backslash to prevent an infinite loop. The following example sends Sam’s email to himself on the local system and on the system at example.com:

$cat ~sam/.forward
sams@example.com
\sam

Related Programs

exim4

The exim4 packages include several programs. The primary program, exim4, reads from standard input and sends an email to the recipient specified by its argument. You can use exim4 from the command line to check that the mail delivery system is working and to email the output of scripts. See “Test” for an example. The command apropos exim4 displays a list of exim4-related files and utilities. In addition, you can call exim4 with options or through links to cause it to perform various tasks.

exim4 –bp

When you call exim4 with the –bp option, or when you call the mailq utility (which is a symbolic link to exim4), it displays the status of the outgoing mail queue. When there are no messages in the queue, it displays nothing. Unless they are transient, messages in the queue usually indicate a problem with the local or remote MTA configuration or a network problem.

$ sudo exim4 -bp
24h 262 1IBhYI-0006iT-7Q <sam@> frozen
zachs@example.com

eximstats

The eximstats utility displays statistics based on exim4 log files. Call this utility with an argument of the name of a log file, such as /var/log/mainlog or /var/log/mainlog2.gz. Without any options, eximstats sends information based on the log file in text format to standard output. When you include the –html option, eximstats generates output in HTML format, suitable for viewing with a browser:

$ eximstats -html /var/log/exim4/mainlog.2.gz  > exim.0720.html

If you are not a member of the adm group, you must run the preceding command with root privileges. See the eximstats man page for more information.

eximon

Part of the eximon4 package, eximon displays a simple graphical representation of the exim4 queue and log files.


© Copyright Pearson Education. All rights reserved.

This excerpt is taken from Chapter 20 of the new 2nd Ed. of A Practical Guide to Ubuntu Linux, authored by Mark Sobell. The chapter continues with information on configuring an exim4 mail server (jump to page 56 here: http://www.informit.com/content/images/9780137003884/samplepages/0137003889_Sample.pdf) The book is published by Prentice Hall Professional, Jan. 2009, ISBN 0137003889 Copyright 2009 Mark G. Sobell. For more information on this book, please visit: www.informit.com/title/0137003889 and to learn more about Mark Sobell’s additional books, please visit: www.sobell.com Safari Books Online subscribers can access the book here: http://my.safaribooksonline.com/9780137003884?portal=informit

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState