UNIX System Administration Handbook - Evi Nemeth [345]
dn: uid=eric, o=sendmail.com, c=US
objectClass: inetLocalMailRecipient
mailLocalAddress: eric@sendmail.org
mailRoutingAddress: eric@eng.sendmail.com
would cause mail addressed to eric@sendmail.org (which DNS MX records caused to be delivered to sendmail.com) to be sent to eric@eng.sendmail.com. If the entry also contained the line
mailHost: mailserver.sendmail.com
then mail to eric@sendmail.org would be addressed to eric@eng.sendmail.com and sent to the host with the best MX record for mailserver.
LDAP database entries support a wild card entry, @domain, that reroutes mail addressed to anyone at the specified domain (as was done in the virtusertable).
Masquerading and the MASQUERADE_AS macro
The MASQUERADE_AS macro allows you to specify a single identity that other machines hide behind. All mail appears to emanate from the designated machine or domain. The sender’s address is rewritten to be user@masquerading-name instead of user@original-host.domain. Of course, those masqueraded addresses must be valid so that people can reply to the mail.
This configuration permits all users at a site to use a generic email address. For example, if all hosts at xor.com masquerade behind the domain xor.com, then mail from user@host.xor.com will be stamped as being from user@xor.com with no mention of the actual hostname from which the user sent the mail. The machine that represents xor.com must know how to deliver all users’ mail, even mail for users that do not have a login on the incoming mail server. Naturally, login names must be unique across the whole domain.
Some users and addresses (such as root, postmaster, hostmaster, trouble, operations, Mailer-Daemon, etc.) should be exempted from this behavior. They can be explicitly excluded with the EXPOSED_USER macro. For example, the sequence
MASQUERADE_AS('xor.com')
EXPOSED_USER('root')
EXPOSED_USER('Mailer-Daemon')
would stamp mail as coming from user@xor.com unless it was sent by root or the mail system; in these cases, the mail would carry the name of the originating host.
There are several extensions to the basic MASQUERADE_AS macro, both through other macros and through FEATUREs:
• The MASQUERADE_DOMAIN macro
• The MASQUERADE_DOMAIN_FILE macro
• The MASQUERADE_EXCEPTION macro
• The limited_masquerade FEATURE
• The allmasquerade FEATURE
• The masquerade_envelope FEATURE
• The masquerade_entire_domain FEATURE
We recommend using the MASQUERADE_AS macro described above along with the allmasquerade and masquerade_envelope features. The limited_masquerade feature modifies the behavior of MASQUERADE_DOMAIN and is useful for virtual hosting environments. MASQUERADE_DOMAIN lets you list domains that you want to masquerade; the list is preloaded from the w class that is typically defined with the use_cw_file feature and lists the hosts in your domain. limited_masquerade does not preinitialize the list with class w. All those domains will be hidden by the domain you are masquerading as.
The allmasquerade feature extends masquerading to the recipients of the message (as opposed to just the sender), and the masquerade_envelope feature extends it to the envelope as well as to the header addresses.22
With these two extensions, all addresses are hidden in a consistent fashion. The limited_masquerade feature extends masquerading to a specified list of other domains.
If you want to use other masquerading techniques, you can read about their behavior in the cf/README file or in the sendmail book. Read carefully; some of the masquerading primitives can hide too much.
The MAIL_HUB and SMART_HOST macros
Masquerading makes all mail appear to come from a single host or domain by rewriting the headers and, optionally, the envelope. Some sites may want all mail to really come from (or go to) a single machine. You can achieve this configuration with the macros MAIL_HUB for incoming mail and SMART_HOST for outgoing mail.
If you want to route