 | Chapter 11 Rule Sets 1 and S= |  |
| Chapter 11 Rule Sets 1 and S= | |
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 parsingSHubset # Rewrite the sender for the hubnew
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 hubR$- $@ $1@${HUB} user -> user@hub
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:
$1positional 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 newThis 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
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.
| Wildcard | Description |
|---|---|
$+ | Match one or more tokens |
$* | Match zero or more tokens |
$- | Match exactly one token |
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).
|  | |
| 11.3 All Mail from the Hub |  | 11.5 Testing So Far |