Sendmail is a popular SMTP server that's flexible enough to provide support for just a few users or for thousands of employees in an enterprise environment. It is also a complex piece of software, and configuring Sendmail to run on your Linux server can be a little daunting. Although Sendmail's developers have tried to simplify the configuration process, the requirements of your organization will ultimately determine the level of difficulty involved in building a robust Sendmail server.
My article “Setting up a Sendmail server on Linux” reviewed the initial installation and some of the basic configuration files used in getting Sendmail up and running on Linux. This article will show you how to further master the basic config files and will explain the steps you need to take to make Sendmail a reliable SMTP server.
Since version 8.9, the directory /etc/mail/ has housed all of the configuration files necessary to make Sendmail function. There have also been a few changes in file naming. Table A should help if you are used to an older version.
|Pre-Sendmail 8.9 location||Sendmail 8.9+ location|
The main configuration file is still /etc/mail/sendmail.cf. This is the file you created during initial installation by processing sendmail.mc with the sh Build sendmail.cf command. This file allows Sendmail to extrapolate much of its initial configuration based on a few options such as OSTYPE and MAILER.
While many of you won't need to edit the main configuration file again, the rest of us must wade through the rather obfuscated syntax that makes new Sendmail administrators quiver. However, take heart; it’s not as bad as it initially appears.
First of all, by default, Sendmail now installs with spam protection automatically configured. It used to be that anyone installing Sendmail for the first time was running an open relay that spammers could easily target and use. Now you can easily specify which IP addresses are allowed to relay through you by modifying /etc/mail/relay-domains. This is a text file that lists the hostnames allowed to use your server to send e-mail. For most organizations, this should only be the localhost and its aliases, but larger organizations may need to add multiple off-site domains as well.
This step is important, given the proliferation of Realtime Blackhole Lists (RBLs). If spammers use your server and your site becomes marked on one of these lists as a source of spam, it could cause delivery failures and 550 errors until you can get it unlisted. Better to play it safe and list only those hosts that need to have access to Sendmail.
Setting up local-hosts-names
For servers that house more than one hostname, the /etc/mail/local-host-names file can be useful. With the inclusion of FEATURE(use_cw_file) in your sendmail.mc file, Sendmail will use local-host-names as a source for all your local aliases.
# local-host-names - aliases for your server
Sendmail will not accept delivery of mail if it does not recognize the hostname for the intended recipient. Remember that you must restart Sendmail after modifying this or any other configuration file. This can be done usually by script, as in /etc/init.d/sendmail restart or by sending a kill –1 <sendmail pid#>.
The file /etc/mail/aliases allows for mapping virtual mailboxes to local users, programs, or even other aliases:
# Basic system aliases
# General redirections for pseudo accounts
# Well-known aliases
webmaster: tnooning, bmarley, hsimpson
You’ll notice the webmaster alias has multiple recipients listed. This is fine. Just make sure to separate local user names with commas. Also, the alias complaints will write e-mails sent to that address into the file /var/log/complaints. This is something I recently discovered and have been using a great deal. And remember, after you modify the aliases file, you must run newaliases. This is a program that comes with Sendmail and creates the necessary database based on the aliases file.
There is an optional FEATURE in sendmail.mc named use_ct_file. This is basically a list of users who are allowed to change the sender on an e-mail. This is accomplished by placing one username per line in /etc/mail/trusted-users. This can be useful for scripts or programs that run on your server to mail information to certain people or groups. It makes it easier to quickly identify what an e-mail message is about. For example, a script you run to query DNS servers and e-mail failures can be sent from email@example.com.
The virtual user table
The virtual user table (/etc/mail/virtusertable) maps mail for virtual domains and mailboxes to real mailboxes on your server. These mailboxes can be local, remote, or an alias defined in /etc/mail/aliases. This is initially configured in your sendmail.mc with the command FEATURE(virtusertable). The file will look something like this:
In the above example, we have a file for example.com. The first line maps firstname.lastname@example.org to the local mailbox root. The next entry maps email@example.com to the remote e-mail address firstname.lastname@example.org. The @example.com line provides a wildcard match for anything that gets sent to any other username at @example.com. Thus, anything sent to example.com will be forwarded to the local mailbox tom.
RBLs are databases maintained by public organizations whose goal is to try and help stop the seemingly constant flood of spam. There are quite a few out there nowadays, including the popular http://www.orbz.org, http://relays.osirusoft.com/, and http://mail-abuse.org/rbl/. You can have Sendmail access these lists by using a command like:
FEATURE(rbl, `rbl.example.org’, `Rejected – see http://example.org/’)
If this feature is enabled, it will perform a test on every source address sending mail to your server. It will compare the address to the RBL to determine whether it will be accepted. In the example above, a failure message will appear when there is a bounce-back, and it will direct the user to go to http://example.org/ for an explanation. This can be especially useful for large sites that receive massive quantities of mail because it conserves disk space.
If you are used to running programs in Linux, you will probably also be used to checking the log files. Sendmail makes good use of its logs, and you can track down most problems there. The main files you should study are mail.log and mail.err. Also included are mail.warn and mail.info. There are some duplicates between these files, so I hardly ever go past the first two. As for location, you should be able to find them in /var/log/ or a similar location depending on your particular system and Linux distribution. If necessary, you can check /etc/syslog.conf. A typical entry for a successful e-mail will look something like this:
Oct 25 18:22:14 example sendmail: SAA29322: from=user, size=193, class=0, pri=60193, nrcpts=2, msgid=<200110260122.SAA29322@example.com>, relay=user@localhost
Oct 25 18:22:14 example sendmail: SAA29322: email@example.com, ctladdr=user (500/1000), delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent
You can also see rejection messages in mail.log similar to the following:
Oct 23 14:23:51 example sendmail: OAA27467: ruleset=check_rcpt, arg1=<firstname.lastname@example.org>, relay=west1.mail-abuse.org [220.127.116.11], reject=550 <email@example.com>... Relaying denied
Usually, all the information you will need is provided in these logs, including usernames, hostnames, and error codes. The error codes themselves can be useful, so be sure to familiarize yourself with them.
Sendmail is one of the most popular SMTP servers in use today. It has the flexibility to provide support for a handful of users or thousands of employees in an enterprise environment. The configuration has also been simplified through the use of a centralized configuration directory and increasingly intuitive nomenclature. You should now have a better understanding of the configuration and logging files used by Sendmail and should be ready to run it as an SMTP server for your organization.