A General Guide To Using The sendmail.mc File

The sendmail.mc file can seem jumbled. To make it less cluttered I usually create two easily identifiable sections in it with all the custom commands I’ve ever added.
The first section is near the top where the FEATURE statements usually are, and the second section is at the very bottom.
Sometimes sendmail will archive this file when you do a version upgrade. Having easily identifiable modifications in the file will make post upgrade reconfiguration much easier. Here is a sample:
dnl ***** Customised section 1 start *****
dnl
dnl
FEATURE(delay_checks)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_entire_domain)dnl
dnl
dnl
dnl ***** Customised section 1 end *****
The /etc/mail/relay-domains File
The /etc/mail/relay-domains file is used to determine domains from which it will relay mail. The contents of the relay-domains file should be limited to those domains that can be trusted not to originate spam. By default, this file does not exist in a standard RedHat / Fedora install. In this case, all mail sent from my-super-duper-site.com and not destined for this mail server will be forwarded:
my-super-duper-site.com
One disadvantage of this file is that controls mail based on the source domain only, and source domains can be spoofed by spam e-mail servers. The /etc/mail/access file has more capabilities, such as restricting relaying by IP address or network range and is more commonly used. If you delete /etc/mail/relay-domains, then relay access is fully determined by the /etc/mail/access file.
Be sure to run the restart sendmail script for these changes to take effect.
The /etc/mail/access File
You can make sure that only trusted PCs on your network have the ability to relay mail via your mail server by using the /etc/mail/access file. That is to say, the mail server will relay mail only for those PCs on your network that have their e-mail clients configured to use the mail server as their outgoing SMTP mail server. (In Outlook Express, you set this using: Tools>Accounts>Properties>Servers)
If you don’t take the precaution of using this feature, you may find your server being used to relay mail for spam e-mail sites. Configuring the /etc/mail/access file will not stop spam coming to you, only spam flowing through you.
The /etc/mail/access file has two columns. The first lists IP addresses and domains from which the mail is coming or going. The second lists the type of action to be taken when mail from these sources or destinations is received. Keywords include RELAY, REJECT, OK (not ACCEPT), and DISCARD. There is no third column to state whether the IP address or domain is the source or destination of the mail, sendmail assumes it could be either and tries to match both. All other attempted relayed mail that doesn’t match any of the entries in the /etc/mail/access file, sendmail will reject. Despite this, my experience has been that control on a per e-mail address basis is much more intuitive via the /etc/mail/virtusertable file.
The sample file that follows allows relaying for only the server itself (127.0.0.1, localhost), two client PCs on your home 192.168.1.X network, everyone on your 192.168.2.X network, and everyone passing e-mail through the mail server from servers belonging to my-site.com. Remember that a server will be considered a part of my-site.com only if its IP address can be found in a DNS reverse zone file:
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
192.168.1.16 RELAY
192.168.1.17 RELAY
192.168.2 RELAY
my-site.com RELAY
You’ll then have to convert this text file into a sendmail readable database file named /etc/mail/access.db. Here are the commands you need:
[root@bigboy tmp]# cd /etc/mail
[root@bigboy mail]# make
The sendmail restart script we configured at the beginning of the article does this for you too.
Remember that the relay security features of this file may not work if you don’t have a correctly configured /etc/hosts file.
The /etc/mail/local-host-names File
When sendmail receives mail, it needs a way of determining whether it is responsible for the mail it receives. It uses the /etc/mail/local-host-names file to do this. This file has a list of hostnames and domains for which sendmail accepts responsibility. For example, if this mail server was to accept mail for the domains my-site.com and another-site then the file would look like this:
my-site.com
another-site.com
In this case, remember to modify the MX record of the another-site.com DNS zonefile point to my-site.com. Here is an example (Remember each “.” is important):
; Primary Mail Exchanger for another-site.com
another-site.com. MX 10 mail.my-site.com.
Which User Should Really Receive The Mail?
After checking the contents of the virtusertable, sendmail checks the aliases files to determine the ultimate recipient of mail.
The /etc/mail/virtusertable file
The /etc/mail/virtusertable file contains a set of simple instructions on what to do with received mail. The first column lists the target email address and the second column lists the local user’s mail box, a remote email address, or a mailing list entry in the /etc/aliases file to which the email should be forwarded.
If there is no match in the virtusertable file, sendmail checks for the full email address in the /etc/aliases file.
webmaster@another-site.com webmasters
@another-site.com marc
sales@my-site.com sales@another-site.com
paul@my-site.com paul
finance@my-site.com paul
@my-site.com error:nouser User unknown
In this example, mail sent to:
webmaster@another-site.com will go to local user (or mailing list) webmasters, all other mail to another-site.com will go to local user marc.
sales at my-site.com will go to the sales department at my-othersite.com.
paul and finance at my-site.com goes to local user (or mailing list) paul
All other users at my-site.com receive a bounce back message stating “User unknown”.
After editing the /etc/mail/virtusertable file, you have to convert it into a sendmail-readable database file named /etc/mail/virtusertable.db with two commands:
[root@bigboy tmp]# cd /etc/mail
[root@bigboy mail]# make
If these lines look like you’ve seen them before, you have: They’re in your all-purpose sendmail restart script.
The /etc/aliases File
You can think of the /etc/aliases file as a mailing list file. The first column has the mailing list name (sometimes called a virtual mailbox), and the second column has the members of the mailing list separated by commas.
To start, sendmail searches the first column of the file for a match. If there is no match, then sendmail assumes the recipient is a regular user on the local server and deposits the mail in their mailbox.
If it finds a match in the first column, sendmail notes the nickname entry in the second column. It then searches for the nickname again in the first column to see if the recipient isn’t on yet another mailing list.
If sendmail doesn’t find a duplicate, it assumes the recipient is a regular user on the local server and deposits the mail in their mailbox.
If the recipient is a mailing list, then sendmail goes through the process all over again to determine if any of the members is on yet another list, and when it is all finished, they all get a copy of the e-mail message.
In the example that follows, you can see that mail sent to users bin, daemon, lp, shutdown, apache, named, and so on by system processes will all be sent to user (or mailing list) root. In this case, root is actually an alias for a mailing list consisting of user marc and webmaster@my-site.com.
# Basic system aliases — these MUST be present.
mailer-daemon: postmaster
postmaster: root
# General redirections for pseudo accounts.
bin: root
daemon: root
…
…
abuse: root
# trap decode to catch security attacks
decode: root
# Person who should get root’s mail
root: marc,webmaster@my-site.com
Notice that there are no spaces between the mailing list entries for root: You will get errors if you add spaces.
Note: The default /etc/aliases file installed with RedHat / Fedora has the last line of this sample commented out with a #, you may want to delete the comment and change user marc to another user. Also after editing this file, you’ll have to convert it into a sendmail readable database file named /etc/aliases.db. Here is the command to do that:
[root@bigboy tmp]# newaliases
In this simple mailing list example, mail sent to root actually goes to user account marc and webmaster@my-site.com. Because aliases can be very useful, here are a few more list examples for your /etc/aliases file.
Mail to “directors@my-site.com” goes to users “peter”, “paul” and “mary”.
# Directors of my SOHO company
directors: peter,paul,mary
Mail sent to “family@my-site.com” goes to users “grandma”, “brother” and “sister”
# My family
family: grandma,brother,sister
Mail sent to admin-list gets sent to all the users listed in the file /home/mailings/admin-list.
# My mailing list file
admin-list: “:include:/home/mailings/admin-list”
The advantage of using mailing list files is that the admin-list file can be a file that trusted users can edit, user root is only needed to update the aliases file. Despite this, there are some problems with mail reflectors. One is that bounce messages from failed attempts to broadcast go to all users. Another is that all subscriptions and unsubscriptions have to be done manually by the mailing list administrator. If either of these are a problem for you, then consider using a mailing list manager, such as majordomo.
One important note about the /etc/aliases file: By default your system uses sendmail to mail system messages to local user root. When sendmail sends e-mail to a local user, the mail has no To: in the e-mail header. If you then use a mail client with a spam mail filtering rule to reject mail with no To: in the header, such as Outlook Express or Evolution, you may find yourself dumping legitimate mail.
To get around this, try making root have an alias for a user with a fully qualified domain name, this forces sendmail to insert the correct fields in the header; for example:
# Person who should get root’s mail
root: webmaster@my-site.com