|
|
While it's possible to administer Sendmail using nothing but guidance from the official program documentation, most administrators have collected shortcuts and ideas to help automate or streamline routine tasks. Since Sendmail has been around for so long and is so complex, new and experienced mail-admins alike just want a listing of the most commonly used tricks and shortcuts to do what they need to do with this powerful MTA. This section contains some useful Sendmail tricks used at Rackspace Managed Hosting to help customers out of tight.
When you set up a new system or a new mail server, there are several things that you should do right away to make your work life easier and your system more secure. One of these jobs is to redirect system mail so that it goes to someone other than the actual root user on the local system. This gets the system mail into the mailbox of a real person who can solve the problem, as well as keep the root mailbox from just sitting there and filling up the drive.
| Tip |
It's always a good idea to define your root alias so that it points both to your local administrative e-mail account and to a backup mail account on another server. If there are local problems such as a crashed mailbox, compromised root passwords, or other things that make it impossible for you to access root-related mail, you'll still be able to use the backup account to get system messages. |
If you're using Sendmail, system e-mail is redirected with the /etc/aliases file. If you've switched to PostFix, you'll need to work in the /etc/postfix/aliases file. The syntax is the same for both MTAs:
[...] # Person who should get root's mail #root: marc root: mylocalaccount, me@otherdomain.com [...]
Once you've added the new information and saved the file, you must rebuild the alias database. Use the newaliases command:
# newaliases /etc/aliases: 63 aliases, longest 10 bytes, 625 bytes total
| Note |
You should be able to use newaliases with Sendmail and with PostFix, even though the two MTAs use different newalias commands and configuration files. Why? It's the alternatives system at work again. Look at the output of alternatives-display mta and the results of ls -la $ (which newaliases) to see how alternatives handles this situation. |
Whether you're new to an existing Sendmail installation or you just want a quick overview, sometimes it's useful to get output that details every Sendmail configuration on the system. Get this information with the command:
Individual users can create .forward files to redirect their e-mail to another address without needing root access to do so. These .forward files are processed by the procmail program. If you use .forward files (or allow your users to create them), be sure that the file's permissions are set securely. Otherwise, a .Forward file will not work. Secure .forward files look like this:
$ cd /home/bob $ ls -la .forward -rwx------ 1 bob bob 27 Dec 25 00:04 .forward $ cat /home/bob/.forward bob@yahoo.com
This shows that the local user bob has all of his e-mail redirected to his Yahoo! account. Note that the file permissions must be set correctly, or it will not work. If you need to change the permissions of your .forward file, do so with the command chmod 700 .forward. Likewise, your home directory (/home/bob/ in this case) should also be locked down to at least rwxr-xr-x (755), or you may have .forward processing problems even if the file permissions are set properly.
If you want to take a quick look at your system's outgoing mail queue, use this command:
# mailq
This command is actually a symbolic link to the sendmail binary, which is run internally as sendmail -bp:
# ls -la /usr/bin/mailq
lrwxrwxrwx 1 root root 27 Dec 16 11:38 /usr/bin/mailq ->
/etc/alternatives/mta-mailq
To manage most Sendmail options, make changes in the /etc/mail/sendmail.mc macro configuration file. When the file has been saved, you must rebuild the .mc file down to the runtime configuration file /etc/mail/sendmail.cf with the m4 macro interpreter or processor. In this section, we describe three common Sendmail option changes and show the command sequences to accomplish each goal.
As we've said before, when you make a change to the sendmail.mc file, you must then follow up by rebuilding the sendmail.cf file with the m4 processor. First, we show you how to do this safely, and then show you how to make some common option changes to Sendmail.
Since you need to rebuild sendmail.cf each time you make configuration changes to the sendmail.mc file, here's an easy way to back up your critical system files, rebuild, and then restart Sendmail to take advantage of new settings. First, make a set of backup files:
Now that you have backup copies, you can make needed changes to the sendmail.mc file and then apply them to sendmail.cf:
# m4 sendmail.mc > sendmail.cf #
Next, restart Sendmail to use the changes:
# /etc/init.d/sendmail restart Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ] Starting sendmail: [ OK ] Starting sm-client: [ OK ]
Mail servers on Fedora Core and Red Hat Linux systems are bound, by default, only to the loopback IP address 127.0.0.1. This is done for security, since there are far more Linux machines out there that do not run as incoming mail servers than there are machines intended to accept incoming SMTP traffic. Leaving MTAs configured to loopback makes sense from a security perspective (fewer services exposed to the network means better security). If this were not the case, administrators would have to remember to turn off the mail server when configuring a nonmail server, which would make default Linux installations less secure everywhere.
However, if you need incoming Sendmail MTA services to run on a new machine, then you must manually configure Sendmail to listen on an external IP address.
| Caution |
Before you begin to configure Sendmail on a new machine, back up your existing /etc/mail/ directory and all its configuration files. We'll wait here while you do it. Doing a quick backup has saved more than one mail administrator's job. Here's an easy back-up method that works for us: # cp -a /etc/mail /etc/mail-BAK # ls -lad /etc/mail-* drwxr-xr-x 3 root root 4096 Dec 16 12:16 /etc/mail-BAK |
Once you have backed up your existing /etc/mail/dir and its configuration files, you can begin to work with sendmail.mc. Open /etc/mail/sendmail.mc in your favorite text editor and find the lines containing 127:
[...]
dnl This changes sendmail to only listen on the loopback
device 127.0.0.1 dnl and not on any other network devices.
Comment this out if you want dnl to accept email over the
network.
DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')
[...]
| Note |
The lines that start with dnl are comments, like those beginning with # in configuration files. The dnl component tells the m4 macro processor to skip from here to the next line. (The excerpt above is actually line-wrapped.) Every line that is not a specific command for the m4 processor needs to start with dnl, or m4 will try to interpret it. |
There are several ways to edit this file so that Sendmail will begin to listen for incoming SMTP traffic. You can add dnl to the beginning of the DAEMON_OPTIONS line, as in
dnl DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')
You can also leave the line as is, but change the IP address from 127.0.0,1 to the incoming IP address where you receive SMTP traffic. If you receive SMTP traffic on more than one IP address associated with this server, you can change 127.0.0.1 to 0.0.0.0 instead.
| Note |
Adding dnl to the start of the DAEMON_OPTIONS line is the same as changing the IP address to 0.0.0.0 (which means all IPs on the planet). Both methods bind SMTP to all IP addresses on the server. If you want a more restricted setting, set the IP address to a specific incoming IP address. Not every system should bind SMTP to all incoming IP addresses. If you run internal services such as DHCP or DNS on a machine that also serves as the local firewall and router, you should probably only bind SMTP to a specific internal or external IP address (depending on your security model). Unless you need to bind to multiple IP addresses for vhosting purposes, it's good security policy to restrict SMTP and other services to a single interface or specific IP address. |
Since you backed up the functioning sendmail.cf file before you edited sendmail.mc, it's safe to rebuild your sendmail.cf file now and test your new setting. Use the following commands to stop Sendmail, rebuild the sendmail.cf file from the edited sendmail.mc file, and restart Sendmail.
# cd /etc/mail # /etc/init.d/sendmail stop Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ] # m4 sendmail.mc > sendmail.cf # /etc/init.d/sendmail start Starting sendmail: [ OK ] Starting sm-client: [ OK ] # ps auxw| grep [s]endmail root 4478 0.0 1.1 7660 2552 ? S 23:25 0:00 sendmail: accepting connections smmsp 4487 0.0 1.0 7864 2252 ? S 23:25 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
The output from ps shows that Sendmail restarted successfully. Now, you can check to see what IP address, or addresses, Sendmail is using to listen for incoming SMTP traffic:
# netstat -antp | grep :25 tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 3780/sendmail: acce
Success! This shows us that Sendmail is bouncing to all IP addresses on port 25 (0.0.0.0:25), which is SMTP.
With the ever-growing mountain of spam that overwhelms mail servers daily, many administrators have begun to implement controls to limit mail relaying.
| Note |
Mail relaying is the way in which someone can send mail through your mail server and out to other recipients not on your system at all. If you run open relays on your mail server, then spammers (who are always scanning for such gold mines) will lock onto your server and use it to send millions of e-mail messages from your server until you're eventually blacklisted by outfits such as www.ordb.org and www.spamhaus.org. Once you've been blacklisted, all of your legitimate e-mail will be blocked by all the big ISPs and hosters such as AOL, MSN, and Earthlink, your users' e-mail will all bounce, and you'll be in hot water. It is very difficult to get off some of these blacklists, so do your best to stay off them by never allowing mail relaying, except from people who can provide a valid username/password. This type of username/password SMTP restriction is called SMTP-Auth, and it is much preferred to older antirelaying methods such as pop-locks and manually updated whitelists. |
If you have users who access their mail from dynamic IP addresses or who travel regularly so that you can't use IP-based access controls (or whitelists), you will probably want to enable SMTP-Auth on your Sendmail server. SMTP-Auth allows you to enforce client authentication before sending mail through your server.
To enable SMTP-Auth under Sendmail, open /etc/mail/sendmail.mc and make this edit:
define('confAUTH_OPTIONS', 'A')dnl
This should be the default on all newer Fedora Core and Red Hat based systems, but your mileage may vary on other distributions. After you have saved the file, rebuild sendmail.cf and restart Sendmail as described above.
| Tip |
Later in this chapter is an example of what SMTP-Auth will look like when you telnet directly into a Sendmail server's SMTP port. |
|
|