Introduction

Masquerading is sendmail-speak for rewriting the hostname in the address of outbound mail. The reasons for masquerading fall into two general categories:

Mail routing

Many networks are designed to route all inbound mail through a central mail hub. When a host sends out mail using its own hostname in the sender address, replies to that mail may well come back to the host. Replacing the sending system's hostname with the mail hub's hostname in the sender address guarantees that replies come back to the hub. Masquerading is not the only way to do this. An MX record can also route mail to the hub. However, maintenance of the DNS zone file is under the control of the domain administrator. The sendmail administrator maintains masquerading, and most sendmail administrators prefer to be in charge of their own fate. Also, hostnames change over time. Masquerading can provide more consistent email addresses and can simplify maintenance.

Organizational requirements

Some organizations simply have a policy of hiding hostnames. Management may think that "busy" hostnames project an image of disorganization. Marketing may think that "frivolous" hostnames project the wrong image to customers. Naive security people may even believe that hiding hostnames increases security. For whatever reason, management requires masquerading, which, in turn , creates the need for systems configured to receive replies to the masqueraded mail.

The MASQUERADE_AS macro enables masquerading. This macro stores a value in the sendmail.cf $M macro and adds code to the MasqHdr ruleset to rewrite the header sender address using the value returned by $M . ^[1] By default, masquerading applies to all of the mail that originates on the local host. All of the valid hostnames for the local host are stored in class $=w . When MASQUERADE_AS is used, sendmail replaces the hostname of the sender with the value of $M ”if the original address lacks a hostname or the hostname matches a value in class $=w .

^[1] Even configurations that don't use MASQUERADE_AS have a MasqHdr ruleset that adds the fully qualified name of the local host returned by $j to the sender address when the address lacks a hostname.

sendmail checks both class $=w and class $=M when masquerading. ^[2] Class $=M , however, starts out empty. Use the MASQUERADE_DOMAIN macro to add individual hostnames to class $=M . To add multiple hosts, create a file containing a list of hosts and use the MASQUERADE_DOMAIN_FILE macro to load the file into class $=M .

^[2] To force sendmail to ignore class $=w and use only class $=M for masquerading, use the limited_masquerade feature.

Normally, masquerading interprets the values in class $=M as hostnames and only exact matches are masqueraded. Use the masquerade_entire_domain feature to interpret the values in class $=M as domain names . When masquerade_entire_domain is used, every host in a domain listed in class $=M is masqueraded. masquerade_entire_domain is used in Recipe 4.8.

By default, masquerading is applied to the header sender address. The masquerade_envelope feature causes sendmail to also apply masquerading to the envelope sender address. Recipe Recipe 4.10 shows an example of how the masquerade_envelope feature is used. Using the allmasquerade feature applies masquerading to both sender and recipient addresses. Recipe 4.5 discusses the allmasquerade feature.

Masquerading is widely used and highly configurable, yet it is not the only way, or even the most powerful way, to rewrite the sender address in the From : header. Masquerading rewrites the hostname in the sender address; the genericstable rewrites the entire address ”both the username and the hostname. The genericstable is related to masquerading in that they both modify the sender address, however, there are distinct differences:

• Masquerading rewrites the hostname based on the input hostname. The genericstable is applied to addresses based on the input hostname but can rewrite the entire address based on all or part of the input address.

• Masquerading replaces each masqueraded hostname with the same value, whereas the genericstable can replace each input address with a different value.

The genericstable feature defines the generics database in the sendmail.cf file and adds code to the MasqHdr ruleset to use that database to rewrite the sender address in the From : header. The key to the genericstable database is a username or a full email address, and the value returned for the key is a complete email address. To use the genericstable , first construct a text file in which each line of the file is a key/value pair using the format: username, whitespace, email address. A sample input entry in the text file is:

 pat     [e-mail] 

In this example, pat is the key against which the input username is matched, and [e-mail] is the email address returned for that key. Before the genericstable can be used, the text file containing the key/value pairs must be converted to a hash type database using the sendmail makemap command. ^[3]

^[3] Recipe 4.11 provides an example of building a genericstable database.

Both the username and the hostname from the input sender address are used by the genericstable process. The key to the genericstable database always contains a username, either by itself or as part of a full email address. However, sendmail only searches for that key if the hostname in the input sender address matches a value in class $=G or if the input sender address contains no hostname.

By default, class $=G is empty. Use the GENERICS_DOMAIN macro to add individual hostnames to class $=G , or the GENERICS_DOMAIN_FILE macro to load class $=G from a file. Normally, the values in class $=G are interpreted as hostnames. Use the generics_entire_domain feature to make sendmail interpret the values in class $=G as domain names. When the generics_entire_domain feature is used, the genericstable is applied to mail sent from every host in every domain listed in class $=G .

Both masquerading and the genericstable are used in the recipes in this chapter. But first we start with a recipe that uses the always_add_domain feature. always_add_domain has nothing to do with the genericstable , and, strictly speaking, it is not a masquerading command. However, it does rewrite the sender address, which is the common thread running through this chapter.