| Previous | Next | Contents | Index |
Most rewrite rule patterns consist either of a specific host name that will match only and exactly that host, e.g.,
host.domain.com |
.domain.com |
Since as discussed in Section 2.2.3.2 PMDF attempts to rewrite host/domain names starting from the specific host name and then incrementally generalizing the name to make it less specific, this means that a more specific rewrite rule pattern will be preferentially used over more general rewrite rule patterns. For instance, if the rewrite rule patterns
hosta.subnet.domain.com .subnet.domain.com .domain.com |
In particular, the use of rewrite rules incorporating subdomain rewrite
rule patterns is common for sites on the Internet. Such a site will
typically have a number of rewrite rules for their own internal hosts
and subnets, and then will include rewrite rules for the top-level
Internet subdomains into their configuration from the file
internet.rules stored in the PMDF table directory. The
presence of such
! Ascension Island .AC $U%$H$D@TCP-DAEMON . [text . removed for . brevity] ! Zimbabwe .ZW $U%$H$D@TCP-DAEMON |
IP domain literals follow a similar hierarchical matching pattern, though with right-to-left (rather than left-to-right) matching. For instance, the pattern
[1.2.3.4] |
[1.2.3.] |
In addition to the more common sorts of host or subdomain rewrite rule patterns discussed above, rewrite rules may also make use of several special patterns, summarized in Table 2-1, and discussed in the following subsections.
| Pattern | Name | Section | Usage |
|---|---|---|---|
| $% | Percent hack rule | 2.2.4.1 | Matches any host/domain specification of the form A%B. |
| $! | Bang-style rule | 2.2.4.2 | Matches any host/domain specification of the form B!A. |
| [] | IP literal match-all rule | 2.2.3.7 | Match any IP domain literal. |
| . | Match-all rule | 2.2.4.3 | Matches any host/domain specification. |
In addition to these special patterns, PMDF also has the concept of "tags" which may appear in rewrite rule patterns. These tags are used in situations where an address may be rewritten several times and, based upon previous rewritings, distinctions must be made in subsequent rewritings by controlling which rewrite rules match the address.
2.2.4.1 A Rule to Match Percent Hacks
If PMDF tries to rewrite an address of the form A%B and fails, it tries
one extra rule before falling through and treating this address form as
A%B@localhost. This extra rule is the percent hack rule. The pattern is
$%. The pattern never changes. This rule is only activated when a local
part containing a percent sign has failed to rewrite any other way
(including the match all rule described below).
The percent hack rule is useful for assigning some special, internal meaning to percent hack addresses.
2.2.4.2 A Rule to Match Bang-style (UUCP) Addresses
If PMDF tries to rewrite an address of the form B!A and fails, it tries
one extra rule before falling through and treating this address form as
B!A@localhost. This extra rule is the bang-style rule. The pattern is
$!. The pattern never changes. This rule is only activated when a local
part containing an exclamation point has failed to rewrite any other
way (including the default rule described below).
The bang-style rule can be used to force UUCP style addresses to be routed to a system with comprehensive knowledge of UUCP systems and routing.
2.2.4.3 A Rule to Match Any Address
The special pattern "." (a single period) will match
any host/domain specification if no other rule matches and the
host/domain specification cannot be found anywhere in the channel
table. In other words, the "." rule is used as a last resort
when address rewriting would fail otherwise.
Using this very general rule can simplify some PMDF installations at the expense of propagating possibly bogus addresses. This special default rule should only be used when PMDF does not have complete routing information available and has to defer judgment of address validity to another system or systems. Care should be taken to insure that such unchecked addresses are only sent to systems that are capable of handling them.
When the match-all rule matches and its template is expanded, $H expands to the full host name and $D expands to a single dot ".". Thus, $D is of limited use in a match-all rule template! |
2.2.4.4 Tagged Rewrite Rule Sets
As the rewrite process proceeds it may be appropriate to bring
different sets of rules into play. This is accomplished by the use of
the rewrite rule tag. The current tag is prepended to each pattern
before looking it up in the configuration file or domain database. The
tag can be changed by any rewrite rule that matches by using the $T
substitution string in the rewrite rule template (described below).
Tags are somewhat sticky; once set they will continue to apply to all hosts that are extracted from a single address. This means that care must be taken to provide alternate rules that begin with the proper tag values once any tags are used. In practice this is rarely a problem since tags are usually used in only very specialized applications. Once the rewriting of the address is finished the tag is reset to the default tag --- an empty string.
By convention all tag values end in a vertical bar |. This character is not used in normal addresses and thus is free to delineate tags from the rest of the pattern.
See Section 2.2.6.14 for an example of using tagged rewrite rules.
a Note that the order of these rewrite rule patterns does not strictly matter, though a more specific to less specific ordering is commonly used for efficiency and esthetic reasons. |
| Previous | Next | Contents | Index |