Sun Java System Messaging Server 6.3 Administration Guide

11.3 Rewrite Rule Patterns and Tags

This section consists of the following subsections:

Most rewrite rule patterns consist either of a specific host name that will match only that host or of a subdomain pattern that will match any host/domain in the entire subdomain.

For example, the following rewrite rule pattern contains a specific host name that will match the specified host only:

host.siroe.com

The next rewrite rule pattern contains a subdomain pattern that will match any host or domain in the entire subdomain:

.siroe.com

This pattern will not, however, match the exact host name siroe.com; to match the exact host name siroe.com, a separate siroe.com pattern would be needed.

The MTA 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 example, assume the following rewrite rule patterns are present in the configuration file:

hosta.subnet.siroe.com
.subnet.siroe.com
.siroe.com

Based on the rewrite rule patterns, an address of jdoe@hosta.subnet.siroe.com will match the hosta.subnet.siroe.com rewrite rule pattern; an address of jdoe@hostb.subnet.siroe.com will match the .subnet.siroe.com rewrite rule pattern; and an address of jdoe@hostc.siroe.com will match the .siroe.com rewrite rule pattern.

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 domains into their configuration from the file internet.rules (msg-svr-base/config/internet.rules).

To ensure that messages to Internet destinations (other than to the internal host destinations handled via more specific rewrite rules) will be properly rewritten and routed to an outgoing TCP/IP channel, ensure that the imta.cnf file contains:


!    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 example, the following pattern matches only and exactly the IP literal [1.2.3.4]:

[1.2.3.4]

The next pattern matches anything in the 1.2.3.0 subnet:

[1.2.3.]

In addition to the more common sorts of host or subdomain rewrite rule patterns already discussed, rewrite rules may also make use of several special patterns, summarized in Table 11–1, and discussed in the following subsections.

Table 11–1 Summary of Special Patterns for Rewrite Rules

Pattern 

Description/Usage 

$* 

Matches any address. This rule, if specified, is tried first regardless of its position in the file. 

$% 

Percent Hack Rule. Matches any host/domain specification of the form A%B. 

$! 

Bang-style Rule. Matches any host/domain specification of the form B!A. 

[ ] 

IP literal match-all rule. Matches any IP domain literal. 

Matches any host/domain specification. For example, joe@[129.165.12.11]

In addition to these special patterns, Messaging Server 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 rewrites, distinctions must be made in subsequent rewrites by controlling which rewrite rules match the address. For more information, see 11.3.4 Tagged Rewrite Rule Sets

11.3.1 A Rule to Match Percent Hacks

If the MTA 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. (For more information about these address forms, see 11.4 Rewrite Rule Templates.) 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.

11.3.2 A Rule to Match Bang-Style (UUCP) Addresses

If the MTA 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.

11.3.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.


Note –

Regarding substitution sequences, 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!


11.3.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.