Recipe 5.6 Routing Mail for Individual Virtual Hosts

Recipe 5.6 Routing Mail for Individual Virtual Hosts

Problem

You have been asked to configure sendmail to route mail for virtual hosts.

Solution

On the DNS server, the domain administrator adds MX records that route mail for each virtual domain to the sendmail system that is acting as the mail exchanger . These records must be added to the zone file for every domain that contains virtual hostnames.

On the mail exchanger, create an /etc/mail/ virtuser -domains file that lists each virtual hostname, one hostname per line.

Next, create an /etc/mail/virtusertable text file that defines the routing for the virtual hosts. The structure of a virtusertable entry is described in the Introduction to this chapter. Use makemap to build a hash database from the text file.

Create a sendmail configuration containing a VIRTUSER_DOMAIN_FILE macro that loads the virtuser-domains file into class $={VirtHost} and a FEATURE macro that enables the virtusertable feature. Here are sample lines that could be added to the sendmail configuration:

 dnl Load $={VirtHost} from a file VIRTUSER_DOMAIN_FILE(`/etc/mail/virtuser-domains') dnl Use the virtusertable for mail routing FEATURE(`virtusertable') 

Finally, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail , and restart sendmail, as shown in Recipe 1.8.

Discussion

The virtusertable routes mail for virtual hosts; however, the sendmail system that contains the virtusertable is not involved in the mail routing unless the mail is first routed to that sendmail system. The initial routing is accomplished via DNS MX records. For example, assume the DNS administrator adds the following MX records to the wrotethebook.com zone file:

 support.wrotethebook.com.       MX   5 mail.wrotethebook.com. sales.wrotethebook.com.         MX   5 mail.wrotethebook.com. 

The DNS administrator of techbooksrus.ora.com adds:

 techbooksRus.ora.com.           MX   5 mail.wrotethebook.com. 

and the administrator of the wrotethebook.org zone file adds:

 phd.wrotethebook.org.           MX   5 mail.wrotethebook.com. 

Given these MX records, the virtuser-domains file, the virtusertable database, and the sendmail configuration described in the Solution section all must be created on mail.wrotethebook.com . Here is a sample virtuser-domain file that might be created on mail.wrotethebook.com :

 #  cat > /etc/mail/virtuser-domains   support.wrotethebook.com   sales.wrotethebook.com   techbooksRus.ora.com   phd.wrotethebook.org   Ctrl-D  

And the following virtusertable is built on mail.wrotethebook.com to route mail for the virtual hosts listed in the virtuser-domains file:

 #  cd /etc/mail  #  cat > virtusertable   @support.wrotethebook.com       admin   @sales.wrotethebook.com         [e-mail]   [e-mail]      [e-mail]   @phd.wrotethebook.org           error:nohost:553 Invalid address   Ctrl-D  #  makemap hash virtusertable < virtusertable  

The virtuser-domains file is essential. Without it, mail addressed to the four hosts listed above is rejected with a "Relaying denied " error. With it, mail addressed to those hosts is accepted by mail.wrotethebook.com where it can then be processed against the virtusertable .

Mail must pass four hurdles before it is modified by the virtusertable :

1. Mail must be routed to the local host for processing.

   The DNS MX records handle this job. It is also possible for mail to be routed based on a DNS address (A) record. However, MX records take precedence over other DNS records when it comes to mail routing.

2. Mail must be accepted by the local host for processing.

   To meet this condition, the mail must be addressed to a host listed in class $=w or class $=R . When class $=w is used to identify virtual hosts, the mail is accepted because the values in class $=w are the hostnames aliases of the local host ”mail addressed to any host in class $=w is accepted as mail addressed to the local host. When class $={VirtHost} is used to identify virtual hosts, the mail is accepted because the values in $={VirtHost} are replicated in class $=R by the sendmail.cf command CR{VirtHost} . Relaying is allowed for any domain listed in class $=R . Therefore, mail to or from any host in a domain listed in class $={VirtHost} is accepted by the local host as mail for a valid relay client.

3. The hostname in the recipient address must be accepted for processing by the virtusertable .

   A recipient address is only processed against the virtusertable if the hostname in that address matches a value in class $=w or class $={VirtHost} . This check is similar to Step 2, except that hostnames listed in class $=R pass Step 2 but do not pass Step 3.

4. The recipient address must match a key in the virtusertable database.

   Matching a value in class $=w or class $={VirtHost} is no guarantee that there is a key for that value in the virtusertable . Only mail with a recipient address that matches a key is routed by the virtusertable .

The sendmail configuration in this recipe uses the VIRTUSER_DOMAIN_FILE macro to load class $={VirtHost} from an external file. Alternatively, individual values can be added to $={VirtHost} using the VIRTUSER_DOMAIN macro. The following macros would add the same values to $={VirtHost} as the sample virtuser-domains file shown above:

 VIRTUSER_DOMAIN_FILE(`support.wrotethebook.com') VIRTUSER_DOMAIN_FILE(`sales.wrotethebook.com') VIRTUSER_DOMAIN_FILE(`techbooksRus.ora.com') VIRTUSER_DOMAIN_FILE(`phd.wrotethebook.org') 

This alternative works, but it is more difficult to maintain when the list of virtual domains is large or changeable .

With this recipe's sendmail configuration installed, four sendmail -bv tests show the effects of the virtusertable :

 #  sendmail -bv [e-mail]  [e-mail]... deliverable: mailer esmtp, host crab.wrotethebook.com., user [e-mail] [e-mail]... deliverable: mailer esmtp, host rodent.wrotethebook. com., user [e-mail] [e-mail]... deliverable: mailer esmtp, host rodent.wrotethebook. com., user [e-mail] #  sendmail -bv [e-mail]  [e-mail]... deliverable: mailer esmtp, host orders.example.com,  user [e-mail] #  sendmail -bv [e-mail]  [e-mail]... deliverable: mailer esmtp, host orders.example.com,  user [e-mail] #  sendmail -bv [e-mail]  [e-mail]... Invalid address 

The first test shows that mail addressed to any user on the virtual host support.wrotethebook.com is delivered to the local user admin . In this case, admin is a mailing list defined in the aliases file. If a virtusertable entry routes mail to a local user, aliasing applies.

The second test shows that mail addressed to any username on the virtual host sales.wrotethebook.com is delivered to that username at orders.example.com . This test shows how the %1 variable is used to move the username from the input address to the output address. On the other hand, the third test preserves nothing from the input address. In that case, mail addressed to [e-mail] is delivered to [e-mail] .

The final sendmail -bv command tests the error message entry in the sample virtusertable . In this case, mail to any user at phd.wrotethebook.org returns the error message "Invalid address." This -bv test shows only the error message; it does not show all of the delivery triple. To see more details, you need to run more tests. Attaching to the SMTP port with telnet allows you to see the SMTP protocol interactions:

 #  telnet localhost smtp  Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 8 Nov 2002 14:53:13 - 0500  HELO chef.wrotethebook.com  250 chef.wrotethebook.com Hello localhost.localdomain [127.0.0.1], pleased to meet  you  MAIL From:<[e-mail]>  250 2.1.0 [e-mail]... Sender ok  RCPT To:<[e-mail]>  553 5.3.0 [e-mail]... Invalid address  QUIT  221 2.0.0 chef.wrotethebook.com closing connection Connection closed by foreign host. 

The server's response to the [e-mail] recipient address shows the error codes as well as the text of the error message. The 553 SMTP response code indicates an invalid mailbox, and the DSN code of 5.3.0 indicates a permanent error with the destination mail system. Both are very appropriate codes for the nohost error keyword we put in the virtusertable entry for phd.wrotethebook.org .

Alternatives

The aliases file is an alternative to using the virtusertable for username-to-username mappings. In the sample virtusertable shown earlier in this section, the following address maps one specific incoming address to one specific outbound address:

 [e-mail]          [e-mail] 

The user sales on techbooksRus.ora.com is mapped to the user jay on orders.example.com . The same result would be achieved by putting the following entry in the aliases database:

 [e-mail]:         [e-mail] 

This alternative only works if the mailer that handles mail bound for techbooksRus.ora.com has the F=A mailer flag set. By default, only the local mailer has this flag set. The alias shown above would require reconfiguring sendmail to set the F=A flag for the esmtp mailer. Setting the F=A flag on a mailer that delivers remote mail would mean that every remote address would be looked up in the aliases database, which would add lots of overhead.

The mailertable is also an alternative to the virtusertable , in some cases. Three of the entries in the virtusertable could be covered by the mailertable with the following entries:

 support.wrotethebook.com        local:admin sales.wrotethebook.com          esmtp:orders.example.com .wrotethebook.org               error:nohost Invalid address 

The primary disadvantage of the mailertable for this application is that it cannot handle the [e-mail] to [e-mail] mapping. The mailertable matches only hostnames; the username is not considered in the match. For this specific application, the virtusertable is the best choice.

See Also

Recipe 5.7 describes additional virtusertable features and should be reviewed for pertinent information. The sendmail book covers the virtusertable in Section 4.8.51. Linux Sendmail Administration , by Craig Hunt (Sybex), explains the numeric SMTP response code, error code keywords, and the DSN codes.