19.4.1 Options

Options may be set, unset, and changed in your mc file with simple define statements. For example, the following line sets the location of the alias file and thus the AliasFile ( A ) option:

define(`ALIAS_FILE', `nis:-N mail.aliases')

Configuring options with the m4 technique is described in Section 34.3, "Configuring with V8 m4 Options" (with the individual m4 option names listed in Table 34.3 of that section). Options are described in general in Chapter 34, Options .

19.4.2 Define Macros

Defined macros may be declared in your mc file. Those that are useful are listed in Table 31.5 of Section 31.8, "Macros with the m4 Technique" . That section also describes the general technique of defining macros via m4 . To illustrate, for example,

define(`BITNET_RELAY', `

host.domain

')

causes the value host.domain to be assigned to the $B macro. Non- m4 specific defined macros can be declared with the LOCAL_CONFIG technique (see Section 19.6.30 ).

19.4.3 Rules and rule sets

The m4 technique allows custom rules and rule sets to be inserted in a variety of convenient ways. The complete list of m4 keywords that affect rules is shown in Table 19.5 .

Table 19.5: Rule and Rule Set Keywords

Keyword		Sendmail Version	Description
LOCAL_CONFIG	Section 19.6.30	V8.1 and above	Add general information and rules
LOCAL_RULE_0	Section 19.6.32	V8.1 and above	Add rules to rule set 0
LOCAL_RULE_1	Section 19.6.34	V8.1 and above	Add rules to rule set 1
LOCAL_RULE_2	Section 19.6.34	V8.1 and above	Add rules to rule set 2
LOCAL_RULE_3	Section 19.6.35	V8.1 and above	Add rules to rule set 3
LOCAL_RULESETS	Section 19.6.36	V8.8 and above	Group local rules with others
LOCAL_NET_CONFIG	Section 19.6.37	V8.6 and above	Add rules for SMART_HOST

To illustrate, consider the following technique for adding a rule to rule set 0:

LOCAL_RULE_0
R$* <@ $=w . $=m> $*        $#local $: $1      @here.ourdomain

Here, we add a rule to rule set 0 that accepts any address with a host part in the class $=w (see Section 32.5.8, $=w ) that is also in one of the local domains as listed in the class $=m (see Section 32.5.3, $=m ) as local address.

19.4.4 Masquerading

Masquerading is the process of transforming the local hostname in addresses into that of another host. This results in the mail message appearing to come from that other host rather than from the local host. Masquerading is most often used in domains where email is addressed to the domain rather than to individual hosts inside the domain.

Masquerading usually rewrites header-sender addresses. Some m4 features allow you also to rewrite envelope addresses. The complete list of all definitions and features that affect masquerading is shown in Table 19.6 .

Table 19.6: Defines and Features Affecting Masquerading

What		Version	Masquerade
EXPOSED_USER	Section 19.6.4, EXPOSED-USER	V8.6 and above	All but these
FEATURE(allmasquerade)	Section 19.6.6	V8.2 and above	The recipient too
FEATURE(limited_masquerade)	Section 19.6.12	V8.8 and above	Only $=M hosts
FEATURE(masquerade_entire_domain)	Section 19.6.15	V8.8 and above	All of a domain
FEATURE(masquerade_envelope)	Section 19.6.16	V8.7 and above	The envelope too
MASQUERADE_AS	Section 19.6.42	V8.6 and above	Another host
MASQUERADE_DOMAIN	Section 19.6.43, MASQUERADE-DOMAIN	V8.6 and above	Other domains
MASQUERADE_DOMAIN_FILE	Section 19.6.44, MASQUERADE-DOMAIN-FILE	V8.6 and above	Other domains

19.4.5 Relays

A relay is a rule that sends all of one type of mail to a specific destination. One example would be email FAX transmissions. Clearly, even though local mail should be delivered locally, mail to the pseudo-user fax should always be sent to a special FAX-handling machine.

The complete list of relays supported by the V8 sendmail m4 technique is shown in Table 19.7 .

Table 19.7: Relays

Relay		Version	Description
BITNET_RELAY	Section 31.10.5, $B	V8.1 and above	The BITNET relay
DECNET_RELAY	Section 31.10.9, $C	V8.7 and above	The DECnet relay
FAX_RELAY	Section 31.10.15, $F	V8.6 and above	The FAX relay
LOCAL_RELAY	Section 19.6.31, LOCAL-RELAY	V8.1 and above	Relay for unqualified users
LUSER_RELAY	Section 31.10.23, $L	V8.7 and above	Relay for unknown local users
MAIL_HUB	Section 19.6.41, MAIL-HUB	V8.6 and above	All local delivery on a central server
SMART_HOST	Section 19.6.47, SMART-HOST	V8.6 and above	The ultimate relay
UUCP_RELAY	Section 19.6.48, UUCP-RELAY	V8.1 and above	The UUCP relay

All relays are declared in the same fashion. For example,

define(`LOCAL_RELAY',`

agent

:

host

')

Here, agent is the name of a delivery agent to use, and host is the name of the machine to which all such mail will be relayed. If agent : is missing, it defaults to a literal relay: .

If the host is listed under a domain that uses wild-card MX records (see Section 21.3.4, "Wildcard MX Records" ), you should specify it with a trailing dot; for example,

define(`LOCAL_RELAY', `smtp:relay.sub.domain.')
                                            


                                        
trailing dot

Relays fit into the flow of rules through rule set 0 like this:

1. 1. Basic canonicalization (list syntax, delete local host, etc.)

2. 1. Basic canonicalization (list syntax, delete local host, etc.)

3. 1. Basic canonicalization (list syntax, delete local host, etc.)

4. 2. LOCAL_RULE_0 (see Section 19.6.32 )

5. 3. FEATURE(mailertable) (see Section 19.6.14 )

6. 4. UUCP_RELAY, BITNET_RELAY, FAX_RELAY, DECNET_RELAY

7. 5. LOCAL_NET_CONFIG (see Section 19.6.37 )

8. 6. SMART_HOST

9. 7. SMTP, local, etc. delivery agents

19.4.6 UUCP

The m4 configuration technique includes four UUCP options to choose from. They are listed in Table 19.8 .

Table 19.8: UUCP Support

Relay		Version	Description
SITE	Section 19.6.45, SITE	V8.1 and above	Declare sites for SITECONFIG (obsolete)
SITECONFIG	Section 19.6.46, SITECONFIG	V8.1 and above	Local UUCP connections (obsolete)
UUCP_RELAY	Section 19.6.48	V8.1 and above	The UUCP relay
UUCPSMTP	Section 19.6.49, UUCPSMTP	V8.1 and above	Individual UUCP to network translations

Note that two items in the table are marked as obsolete. This is because all of their functions have been moved into the mailertable feature (see Section 19.6.14 ). They are included for backward compatibility with early configuration file versions.

Support for UUCP can be included in your mc file with the MAILER command (see Section 19.3.2 ):

MAILER(uucp)

This declares six [3] delivery agents and the rules to support them. They are listed in Table 19.9 .

[3] Actually, there are only four; uucp and uucp-old are synonyms for the same agents, as are suucp and uucp-new .

Table 19.9: UUCP Delivery Agents

Agent		Version	Description
uucp-old	Section 19.4.6.1, "uucp-old (aka uucp)"	V8.6 and above	Old-style, all ! form of UUCP
uucp	Section 19.4.6.1	V8.1 and above	Synonym for the above (obsolete)
uucp-new	Section 19.4.6.2, "uucp-new (aka suucp)"	V8.6 and above	Old-style with multiple recipients
suucp	Section 19.4.6.2	V8.1 and above	Synonym for the above (obsolete)
uucp-uudom	Section 19.4.6.3, "uucp-uudom"	V8.6 and above	Domain-form headers, old-form envelope
uucp-dom	Section 19.4.6.4, "uucp-dom"	V8.6 and above	Domain-form headers and envelope

If support for SMTP delivery agents is also included prior to UUCP, then the last two additional delivery agents are included ( uucp-dom and uucp-uudom ). Note that smtp must be first for this to happen:

MAILER(smtp)
MAILER(uucp)

If uucp is first, uucp-dom and uucp-uudom are excluded.

When processing UUCP mail (addresses that contain a ! and those that end in a .UUCP suffix), sendmail routes to those hosts on the basis of the class in which they were found. Hosts that are found in $=U deliver via uucp-old , hosts in $=Y deliver via uucp-new , and hosts in $=Z deliver via uucp-uudom .

The choice of which delivery agent to use for UUCP delivery is under the control of the SITECONFIG m4 macro described above (see Section 19.6.46 ). Which you choose depends on what version of UUCP you are running locally and what version is being run at the other end of the connection. There are far too many variations on UUCP to allow specific recommendations here. In general, you need to choose between a domain form of address ( gw@wash.dc.gov ) and a UUCP form ( wash!gw ) and then go with the delivery agent that makes the most sense for you. We recommend that you start with the most domain-correct agent, uucp-dom , and see if it works for you. If not, scale back to uucp-uudom , then to uucp-new and finally to uucp-old as a last resort.