The m4 technique uses a huge number of macros to accomplish the complex task of creating configuration files for all possible circumstances. Most are detailed in the reference section at the end of this chapter. Others are documented in chapters dedicated to particular subjects. Here, we summarize all m4 macros by classification or function.
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.
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).
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.
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.
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.
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 |
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.
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. Basic canonicalization (list syntax, delete local host, etc.)
1. Basic canonicalization (list syntax, delete local host, etc.)
1. Basic canonicalization (list syntax, delete local host, etc.)
2. LOCAL_RULE_0 (see Section 19.6.32)
3. FEATURE(mailertable) (see Section 19.6.14)
4. UUCP_RELAY, BITNET_RELAY, FAX_RELAY, DECNET_RELAY
5. LOCAL_NET_CONFIG (see Section 19.6.37)
6. SMART_HOST
7. SMTP, local, etc. delivery agents
The m4 configuration technique includes four UUCP options to choose from. They are listed in Table 19.8.
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
anduucp-old
are synonyms for the same agents, as aresuucp
anduucp-new
.
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.
If you are running an old version of UUCP, you may have to use this
delivery agent. All addresses are turned into the !
form even if
they were in domain form:
user becomes yourhost!user user@host.domain becomes yourhost!host.domain!user
This delivery agent can deliver only to one recipient at a time, so it can spend a lot of time transmitting duplicate messages. If at all possible, avoid using this delivery agent.
Newer releases of UUCP can send to multiple recipients at once.
If yours is such a release, you may use the uucp-new
delivery
agent. It is just like uucp-old
except that
it can perform multiple deliveries.
More modern implementations of UUCP can understand and correctly
handle domain style addresses in headers (although they still
require the !
form in the envelope). If yours is such an implementation,
you may use the uucp-uudom
delivery agent.
At the receiving end, the message mail arrives with the five character "From
"
line showing the sender address in the !
form. The "From
" line
reflects the envelope address.
The uucp-dom
is the most domain-correct form of the available
UUCP delivery agents. All addresses, envelope and header, no matter whether or not they began in the !
form, are sent out in domain form.
Essentially, this uses UUCP as a transport mechanism, but in all other respects it
adheres to the Internet standards.