Forwarding Email with Aliases
Aliases enable you to have an infinite number of valid recipient addresses on your system, without having to worry about creating accounts or other support files for each address. For example, most systems have postmaster defined as a valid recipient, yet do not have an actual login account named postmaster. Aliases are configured in the file /etc/aliases. Here is an example of an alias entry:
postmaster: root
This entry forwards any mail received for postmaster to the root user. By default, almost all the aliases listed in the /etc/aliases file forward to root.
Reading email as root is a security hazard; a malicious email message can exploit an email client and cause it to execute arbitrary code as the user running the client. To avoid this danger, you can forward all of root's mail to another account and read it from there. You can choose one of two ways for doing this.
You can add an entry to the /etc/mail/aliases file that sends root's mail to a different account. For example, root: foobar would forward all mail intended for root to the account foobar.
The other way is to create a file named .forward in root's home directory that contains the address to which the mail should forward.
Any time you make a change to the /etc/mail/aliases file, you have to rebuild the aliases database before that change takes effect. This is done with the following:
# newaliases
Rejecting Email from Specified Sites
You read earlier in this chapter that you must be careful with mail relaying to avoid becoming a spam magnet. But what do you do if you are having problems with a certain site sending you spam? You can use the /etc/mail/access file to automatically reject mail from certain sites.
You can use several rules in the access file. Table 21.1 lists these rules.
TABLE 21.1 The Various Possible Options for Access Rules
| Option | Action |
|---|---|
OK | Accepts mail from this site, overriding any rules that would reject mail from this site. |
RELAY | Allows this domain to relay through the server. |
REJECT | Rejects mail from this site and sends a canned error message. |
DISCARD | Simply discards any message received from the site. |
ERROR: ' | Sends an error message back to the originating server, where n is an RFC 821- compliant error code number. The message itself can be anything you want. |
The following is an example of three rules used to control access to a Sendmail account. The first rejects messages from spam.com. The second rejects messages from lamer.com and displays an error message to that site. The third allows mail from the specific host user5.lamer.com, even though there is a rule that rejects mail from the site lamer.com.
For a more personal example of why you would bother to do this, I find that I get a lot of spam from the Hotmail domain, so I would just as soon reject it all. However, my wife uses a Hotmail account for her mail. If I did not allow her mail through, that would be a problem for me.
spam.com REJECT
lamer.com ERROR: '550 Mail from spammers is not accepted at this site.'
user5.lamer.com OK
Open the /etc/access file, enter the rules of your choice, and then restart Sendmail so that your changes to the access file take effect. That can be done with
# service sendmail restart
or any of the other ways discussed in Chapter 11, 'Automating Tasks.'
Introducing Postfix
Sendmail has been the de facto MTA of choice for the Internet for a long time. At one point, it was the power behind 90% of the email traffic across the world, although it has now become largely superseded by worthier programs.
One of the more popular programs that have become available is Postfix, which was developed and is exclusively maintained by Wietse Venema. Designed to be a drop-in replacement for Sendmail, Postfix allows the system administrator to replace Sendmail without any detriment to the system.
Postfix was designed from the ground up to retain compatibility with Sendmail but to work in a more efficient fashion. Sendmail is notoriously system intensive when handling either large volumes of mail or large numbers of clients. One command pretty much handles everything, making Sendmail something of a monolith. On
