Sendmail, 3rd Edition

Relays

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

The complete list of relays supported by the V8 sendmail mc technique is shown in Table 4-4.

Table 4-4. Relays

Relay	§	Version	Description
BITNET_RELAY	Section 4.5.1	V8.1 and above	The BITNET relay
DECNET_RELAY	Section 4.5.2	V8.7 and above	The DECnet relay
FAX_RELAY	Section 4.5.3	V8.6 and above	The FAX relay
LOCAL_RELAY	Section 4.5.4	V8.1 and above	Relay for unqualified users
LUSER_RELAY	Section 4.5.6	V8.7 and above	Relay for unknown local users
MAIL_HUB	Section 4.5.7	V8.6 and above	All local delivery on a central server
SMART_HOST	Section 4.3.3.6	V8.6 and above	The ultimate relay
UUCP_RELAY	Section 4.5.8	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 wildcard MX records (Section 9.3.4), you should specify it with a trailing dot, as, for example:

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

In Section 19.5 we deal with the flow of rules through the parse rule set 0. For now, merely note that relays fit into the flow of rules through the parse rule set 0 like this:

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

2. LOCAL_RULE_0 (Section 4.3.3.2)

3. FEATURE(ldap_routing) (See this section)

4. FEATURE(virtusertable) (FEATURE(virtusertable))

5. Addresses of the form “user@$=w” passed to local delivery agent (Section 19.5)

6. FEATURE(mailertable) (FEATURE(mailertable))

7. UUCP_RELAY, BITNET_RELAY, FAX_RELAY, DECNET_RELAY

8. LOCAL_NET_CONFIG

9. SMART_HOST (Section 4.3.3.6)

10. SMTP, local, etc. delivery agents

BITNET_RELAY mc Macro

When configuring with the mc method, you can specify a host that will transfer mail between the Internet and BITNET. Mail to BITNET can then be sent by appending the pseudodomain .BITNET to an address. For example:

[e-mail]

Here, ucbicsi is a BITNET host.

To allow your configuration file to handle this form of address, you need to declare the name of your BITNET relay using the BITNET_RELAY keyword:

define(`BITNET_RELAY', `relayhost')dnl

This statement causes the rule for BITNET to be included in your configuration file and causes relayhost to become the host to which BITNET mail is sent.

See Section 4.5 for a description of how to include a delivery agent specification with relay_host. See also bitdomain FEATURE (FEATURE(bitdomain)) for a way to convert BITNET addresses to Internet addresses for hosts that have both.

DECNET_RELAY mc Macro

DECnet addresses are of the form node::user. They can be handled by defining a host that will relay them into your DECnet network. Using the mc configuration method, you enable DECnet like this:

define(`DECNET_RELAY', `relay_host')dnl

Mail addressed to node::user will then be forwarded to relay_host, as will any Internet-style addresses that end in the pseudodomain .DECNET, such as [e-mail].

FAX_RELAY mc Macro

At many sites, faxes can be sent via email. When the host that dispatches those faxes is not the local host, you need to relay FAX mail to the host that can dispatch faxes. This ability is enabled by defining that relay host with the FAX_RELAY mc configuration macro:

define(`FAX_RELAY', `relay_host')dnl

This causes all mail that ends with the pseudodomain .FAX to be forwarded to relay_host.

On the FAX relay machine you will also have to declare the fax delivery agent with the MAILER( ) mc command (Section 4.2.2.2).

LOCAL_RELAY mc Macro

Unless you specify otherwise, any address that is a username without any @host part is delivered using the local delivery agent. If you prefer to have all such mail handled by a different machine, you can define that other machine with the LOCAL_RELAY mc macro.

Note that a relay is different from the knowledgeable hub defined with MAIL_HUB. (See later in this chapter for an illustration of how MAIL_HUB and LOCAL_RELAY interact.)

This mc macro is deprecated because it doesn’t work well with some MUAs—for example, mh( ). This is because some MUAs put a host part on all addresses even if only the user part was specified.

LOCAL_USER mc Macro

Some unqualified usernames (names without an @host part) need to be delivered on the local machine even if LOCAL_RELAY is defined. The user root is one such example. By remaining local, aliasing is allowed to take place.

The LOCAL_USER mc macro is used to add additional usernames to the list of local users. Note that prior to V8.12, root was always a member of that list:

LOCAL_USER(`operator')
LOCAL_USER_FILE(`path')   ← V8.12 and above

Here, the first line causes the name operator to be appended to the list of local users. The second line causes the list of local users to be read from the file named path. The disposition of local usernames that include the domain of the local host is determined by the stickyhost feature (FEATURE(stickyhost)).

LUSER_RELAY mc Macro

A local user is one who evaluates to delivery on the local machine, even after aliasing. By defining LUSER_RELAY:

define(`LUSER_RELAY', `relay_host')dnl

any username that is not found in the passwd(5) file will be forwarded to relay_host. This check is made after aliasing but before processing of the ~/.forward file.

The mc method adds rules to the localaddr rule set 5 that cause the user to be looked up with the user database type (see the name keyword for that type in user). If the user’s name is not found, the message is forwarded to relay_host.

See Section 4.5 for a description of how to include a delivery agent specification with relay_host. Also see the V8.12 preserve_luser_host feature (FEATURE(preserve_luser_host)) for a way to preserve the recipient’s hostname when using this LUSER_RELAY m4 configuration macro.

MAIL_HUB mc Macro

One scheme for handling mail is to maintain one mail spool directory centrally and to mount that directory remotely on all clients. To avoid file-locking problems, delivery to such a spool should be performed only on the central server. The MAIL_HUB mc macro allows you to specify that all local mail be forwarded to the central server for delivery. The point is to let unqualified names be forwarded through a machine with a large aliases file.

If you define both LOCAL_RELAY and MAIL_HUB, unqualified names and names in the class $=L are sent to the LOCAL_RELAY and other local names are sent to MAIL_HUB. To illustrate, consider the result of various combinations for the user you on the machine here.our.site.

If LOCAL_RELAY is defined as relay.our.site and MAIL_HUB is not defined, mail addressed to you is forwarded to relay.our.site, but mail addressed to [e-mail] is delivered locally.

If MAIL_HUB is defined as hub.our.site and LOCAL_RELAY is not defined, mail addressed to you and mail addressed to [e-mail] is forwarded to hub.our.site for delivery.

If both LOCAL_RELAY and MAIL_HUB are defined as shown earlier, mail addressed to you is sent to relay.our.site for delivery, and mail addressed to [e-mail] is forwarded to hub.our.site.

If you want all outgoing mail to go to a central machine, use SMART_HOST too.

Note that LOCAL_RELAY is considered most useful when combined with the stickyhost feature (FEATURE(stickyhost)). Also note that the nullclient feature (FEATURE(nullclient)) can be used if you want all mail to be forwarded to a central machine no matter what.

UUCP_RELAY mc Macro

UUCP is usually modem-based, and typically connects two individual machines together. Unlike domain-based delivery, UUCP delivery is from one machine to the next, and then from that next machine to yet another (using addresses such as fbi!wash!gw).

If your site handles UUCP traffic, that handling can be in one of two forms. Either a given host has direct UUCP connections or it does not. If it does not, you might wish to have all UUCP mail forwarded to a host that can handle UUCP. This is done by defining a UUCP_RELAY, which is defined just as you would define any other relay (as described in Section 4.5).

If your machine or site does not support UUCP, we recommend disabling all UUCP with the nouucp feature (FEATURE(nouucp)).

If your machine has directly connected UUCP hosts, you might wish to use one or more of the UUCP techniques. But before doing so, be sure to declare the uucp delivery agent (Section 4.2.2.2).