Place the following new rule after rule set 3 in the
client.cf
file:
S3 # preprocessing for all rule sets
R$* <> $* $n handle <> error address
R$* < $* < $* > $* > $* $2<$3>$4 de-nest brackets
R$* < $* > $* $2 basic RFC822 parsing
SHubset # Rewrite the sender for the hub
new
At this point you may be wondering why we can give this rule set
a symbolic name, when the earlier rule sets (0 and 3)
had numeric names. The answer lies inside
sendmail
. Recall that
rule set numbers 0 through 5 have special internal meaning to
sendmail
. Part of that meaning is their names.
The
sendmail
program recognizes those special rules only by number.
If you were to give them names instead of numbers,
sendmail
would not recognize them, and your configuration file
would cease to work.
On the other hand, beginning with V8.7
sendmail
, you may both
specify a rule set and give it a symbolic name. Internally,
sendmail
converts that name to a number (a high one such as 199)
and internally refers to it by number. The conversion process ensures
that each name will correspond to a unique number.
Now that we've named
Hubset
, let's put some rules in it.
The sender's address can take several forms. It can be a user's
login name, such as
gw
or
ben
. It can be a user at a
short hostname, such as
gw@wash
or
ben@fbi
. It can be
a user at a fully qualified name such as
gw@wash.dc.gov
or
ben@fbi.dc.gov
.
The
Hubset
rule set first looks for an address that is
just a simple user's name, such as
gw
, and makes it
appear as though it is from the mail hub. To do this, you need a
new LHS wildcard operator,
$-
.
The
$-
wildcard operator matches
exactly one
token
in the workspace.
The first rule in the
Hubset
rule set
uses the
$-
wildcard operator like this:
SHubset # Rewrite the sender for the hub
R$- $@ $1@${HUB} user -> user@hub
new
Because
$-
is the only wildcard operator
in the LHS, a match occurs only if the workspace contains a single
token:
$-
matches
"you"
$-
does not match
"you" "@" "localhost"
This LHS is used to look for an address that
contains only a user's login name. When such a match is found,
the RHS (
$@ $1@${HUB}
) rewrites that address by
appending an
@
and the name of the mail hub machine,
which was stored in the
${HUB}
macro.
The RHS contains two rewrite operators, one that you have seen
already and one that you haven't:
$1
positional operator (you have seen this)
$@
return immediately (new)
When
$@
begins (prefixes) the RHS of any rule, it tells
sendmail
to return (exit the current rule set)
immediately after it has rewritten the workspace. If the
$@
prefix did not appear at the start of the RHS,
sendmail
would rewrite the workspace and then evaluate the LHS again. The
$@
also prevents the workspace from being carried down to
any additional rules in the current rule set. An immediate return
from this rule is desirable because
additional rules might corrupt the now correct workspace.
The actual rewriting is done by
$1@${HUB}
.
The
$1
, which you have seen before,
takes the username matched by the LHS of
$-
(the
first and only wildcard operator, thus
$1
). Then an
@
character is appended. Then the
${HUB}
macro is appended
to the workspace.
The
${HUB}
macro contains the address of the mail hub machine
as it is known to the outside world. This is different from the
${REMOTE}
macro that you defined earlier, which contains the address
of the mail hub machine as it is known to the internal network.
Before you can use the value of
${HUB}
,
you need to define it in the
client.cf
file:
# Defined macros
D{REMOTE}mailhost # The name of the mail hub
D{HUB}mail.us.edu # Hub as known to the outside world
new
This new macro definition places the text
mail.us.edu
into the macro named
{HUB}
.
Now the RHS of
$1@${HUB}
will rewrite the workspace into
you @ mail . us . edu
$1
@
${HUB}
This is exactly what is wanted.
Remember that the
Hubset
rule set handles only sender addresses.
Any sender address that consists of nothing more
than the name of a user will be rewritten to appear to
come from the mail hub.
Table 11.1
shows the three LHS wildcard operators that you now know.
In the
client.cf
file,
${REMOTE}
is defined to be the name
of the hub machine as it is known internally to your network.
${HUB}
is defined to be the name of that same machine
as it is known to the outside world. Note that
both names could be (and probably will be) the same at your site.
The important point about
${REMOTE}
is that it contains a symbolic
name, such as
mailhost
. This allows the machine that is used as
the hub to be easily changed should the need arise. As
your site becomes larger and more complex,
you might want to have several hubs for routing messages to
the outside world. Or you might want to have one machine handle all
outgoing mail and another handle all incoming mail.
Using a symbolic name makes such changes easy.
The important point about
${HUB}
, on the other hand, is that
it contains a fully qualified domain name that is listed with the
Domain Name System or the UUCP maps and is known
to all other sites in the world. This is the host part of
the address that other sites will use when they reply to mail sent
from the hub.
Remember that a name such as
you@
with the value of
${HUB}
added
makes the address of the local sender (
you
)
look as though it is from the hub (
mail.us.edu
).
When someone at another site replies to this address,
the reply will go to the
hub
rather than to the local client.
This is an important distinction, because the client machine may (by design)
be unable to receive mail (more on this later).