To enable the feature, you add the following lines to your sendmail.mc file, if they're not already there:
FEATURE(access_db)
FEATURE(blacklist_recipients)
To disable receipt of mail for a local user, simply add his details into the access database. Usually you would use the ### entry style that would return a meaningful error message to the sender so they know why the mail is not being delivered. This feature applies equally well to users in virtual mail domains, and you must include the virtual mail domain in the access database specification. Some sample /etc/mail/access entries might look like:
daemon 550 Daemon does not accept or read mail.
flacco 550 Mail for this user has been administratively disabled.
grump@dairy.org 550 Mail disabled for this recipient.
Configuring Virtual Email Hosting
Virtual email hosting provides a host the capability of accepting and delivering mail on behalf of a number of different domains as though it were a number of separate mail hosts. Most commonly, virtual hosting is exploited by Internet Application Providers in combination with virtual web hosting, but it's simple to configure and you never know when you might be in a position to virtual host a mailing list for your favorite Linux project, so we'll describe it here.
Accepting mail for other domains
When sendmail receives an email message, it compares the destination host in the message headers to the local host name. If they match, sendmail accepts the message for local delivery; if they differ, sendmail may decide to accept the message and attempt to forward it on to the final destination (See "The access database" earlier in this chapter for details on how to configure sendmail to accept mail for forwarding).
If we wish to configure virtual email hosting, the first thing we need to do is to convince sendmail that it should also accept mail for the domains that we are hosting. Fortunately, this is a very simple thing to do.
The sendmail use_cw_file feature allows us to specify the name of a file where we store domain names for which sendmail accepts mail. To configure the feature, add the feature declaration to your sendmail.mc file:
FEATURE(use_cw_file)
The default name of the file will be /etc/mail/local-host-names for distributions using the /etc/mail/ configuration directory or /etc/sendmail.cw for those that don't. Alternatively, you can specify the name and location of the file by overriding the confCW_FILE macro using a variation on:
define(`confCW_FILE',`/etc/virtualnames')
To stick with the default filename, if we wished to offer virtual hosting to the bovine.net, dairy.org, and artist.org domains, we would create a /etc/mail/local-host-names that looks like:
bovine.net
dairy.org
artist.org
When this is done, and assuming appropriate DNS records exist that point those domain names to our host, sendmail will accept mail messages for those domains as though they were destined for our real domain name.
Forwarding virtual-hosted mail to other destinations
The sendmail virtusertable feature configures support for the virtual user table, where we configure virtual email hosting. The virtual user table maps incoming mail destined for some user@host to some otheruser@otherhost. You can think of this as an advanced mail alias feature, one that operates using not just the destination user, but also the destination domain.
To configure the virtusertable feature, add the feature to your sendmail.mc configuration as shown:
FEATURE(virtusertable)
By default, the file containing the rules to perform translations will be /etc/mail/virtusertable. You can override this by supplying an argument to the macro definition; consult a detailed sendmail reference to learn about what options are available.
The format of the virtual user table is very simple. The lefthand side of each line contains a pattern representing the original destination mail address; the righthand side has a pattern representing the mail address the virtual hosted address will be mapped to.
The following example shows three possible types of entries:
samiam@bovine.net colin
sunny@bovine.net darkhorse@mystery.net
@dairy.org mail@jhm.org
@artist.org $1@red.firefly.com
In this example, we are virtual hosting three domains: bovine.net, dairy.org, and artist.org.
The first entry redirects mail sent to a user in the bovine.net virtual domain to a local user on the machine. The second entry redirects mail to a user in the same virtual domain to a user in another domain. The third example redirects all mail addressed to any user in the dairly.org virtual domain to a single remote mail address. Finally, the last entry redirects any mail to a user in the artist.org virtual domain to the same user in another domain; for example, julie@artists.org would be redirected to julie@red.firefly.com.
Testing Your Configuration
The m4 command processes the macro definition files according to its own syntax rules without understanding anything about correct sendmail syntax; so there won't be any error messages if you've gotten anything wrong in your macro definition file. For this reason, it is very important that you thoroughly test your configuration. Fortunately, sendmail provides a relatively easy way of doing this.
sendmail supports an "address test" mode that allows us to test our configuration and identify any errors. In this mode of operation, we invoke sendmail from the command line, and it prompts us for a ruleset specification and a destination mail address. sendmail then processes that destination address using the rules specified, displaying the output of each rewrite rule as it proceeds. To place sendmail into this mode, we invoke it with the -bt argument:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter ‹ruleset› ‹address›
›
The default configuration file used is the /etc/mail/sendmail.cf file; you can specify an alternate configuration file using the -C argument. To test our configuration, we need to select a number of addresses to process that will tell us that each of our mail-handing requirements are met. To illustrate this, we'll work through a test of our more complicated UUCP configuration shown in Example 18.2.
First we'll test that sendmail is able to deliver mail to local users on the system. In these tests we expect all addresses to be rewritten to the local mailer on this machine:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>